ietf-dkim
[Top] [All Lists]

[ietf-dkim] Issue #1547: MX records (was: ASP 4.2.2, Step 2: name existence check)

2008-03-03 17:57:54
Douglas Otis wrote:

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. : )

You have proposed that domains publishing ASP records be required to 
publish MX records.  But in this case, we have a domain (or perhaps a 
host) that has not published an ASP record, so there could be no 
requirement for an MX.

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?

Perhaps, if there were a clear advantage to checking for the existence 
of the domain vs. querying the parent, which I explore in the following 
paragraph.

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.

In this case, the query that would benefit from negative caching occurs 
immediately (within milliseconds) of the first query, so there shouldn't 
be significant TTL issues.

-Jim

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