ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] ASP 4.2.2, Step 2: name existence check

2008-03-03 16:01:59

On Mar 3, 2008, at 1:51 PM, Jim Fenton wrote:

Dave Crocker wrote:
G'day,

While reviewing the posts in response to the iab draft, I am  
finding myself unclear about the reasons for Step 2, of the query  
procedure in ASP's Section 4.2.2.  I'm pretty sure this is not  
merely a caffeine-deficiency-based question...

     What is the functional or security reason for verifying that  
the domain exists, in terms of ASP.

I can imagine obvious reasons, outside of ASP, but those would not  
need to be documented in the ASP.

At the least, it would help to have the document include text that  
explains the benefit of this step.

Where this came from, as I remember, is the translation from a new  
RR type to a prefixed TXT query.  If ASP is published using its own  
RR type, one can do a query that gets the ASP record, and find out  
whether the domain exists at all.  If you substitute a prefixed TXT  
query, you need to do a query for the domain itself, without the  
prefix, if you want to find this out.

A test should be made querying an MX record at the domain in  
question.  If the domain does not exist, there is no reason to check  
the parent domain for policy records.  By mandating use of MX records  
when publishing the policy records, this climb up the domain tree can  
be completely avoided. : )

Checking for the existence of the domain is clearly a useful thing  
to do, but it could be considered out of scope for ASP to check for  
the existence of the domain, since a non-existent domain naturally  
does not have a signing practices record (and we already know that).

But avoiding a policy check at the parent would be in scope, would it  
not?

Another justification might be caching, but I'd need to find out  
more about how negative caching works:  would a negative response to  
_asp._domainkey.nonexistent.example.com result in a negative cache  
entry for nonexistent.example.com?  If so, step 2 might occur very  
quickly (and locally), potentially eliminating the step 3 query for  
the parent, which would probably not be cached.

See RFC 2308.  Negative caching is not as certain as positive  
caching.  This is why the MX record should be checked prior to walking  
up the domain tree.  Negative caching should be retrained as long as  
the MINIMUM field of the SOA record or the TTL of the SOA itself,  
whichever is less.  Not all resolvers are RFC 2308 compliant.  Some  
truncate the duration of negative caching to limit the effects of  
transient network failures.

-Doug



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html