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
