On Mar 3, 2008, at 4:54 PM, Jim Fenton wrote:
Douglas Otis wrote:
On Mar 3, 2008, at 1:51 PM, Jim Fenton wrote:
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.
Requiring MX records be coupled with DKIM/SMTP policy records means
"existing" domains without MX and policy records thereby indicate they
do not have policy asserted for the domain. Importantly, this result
can be reached without climbing the domain tree. Conversely, when a
policy record is discovered without an MX record, checks against
parent domains are also prevented. Both of these important safety
features are missing from the present DKIM policy discovery algorithm.
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.
Second or third level domains might be above millions of email-address
domains which could cause DKIM policy discovery processes to be
invoked. An algorithm that makes requests for non-existent records
within parent domains will generate a fair amount of new and highly
distributed overhead of non-beneficial traffic that will cause
unnecessary processing delays.
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.
Agreed, the SOA record TTL should not represent a significant
concern. However, a fairly significant percentage of DNS resolvers do
not fully adhere to RFC 2308 and as such, reliance upon negative
caching should be minimized. In other words, negative caching should
not be expected to terminate walks up the domain tree when searching
for seldom published records.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html