On Mar 3, 2008, at 6:35 PM, Douglas Otis wrote:
> On Mar 3, 2008, at 4:54 PM, Jim Fenton wrote:
>> Douglas Otis wrote:
>>
>> 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.
>>> 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.
To expand upon this concept a bit. A requirement to publish MX
records in conjunction with DKIM/SMTP policy records benefits:
1- Slightly increased percentage of MX records positively answering
existence probes.
2- Within existing domains, a DKIM/SMTP Policy Record absent MX
records signifies disavowal of DKIM/SMTP.
3- DKIM/SMTP policy records signifying disavowal of DKIM/SMTP can be
empty and not require content interpretation.
4- Asserting policy does not depend upon walking up the domain, but
instead requires publishing empty policy records at existing nodes.
5- This Discovery/Policy assertion strategy safely extends to other
protocols.
6- Does not depend upon wildcards.
7- Expects domains establishing policy to use a strategy that protects
parent domains.
8- Does not modify what is permitted by the parent domain.
Item 1 moves SMTP closer to a general mandate of requiring MX records
for message acceptance. At that time, a need to publish an empty
policy record at every existing domain node would be precluded.
Item 2 affords actionable responses to abuse or forgery, as this
offers stronger evidence than invalid or missing signatures provide.
Item 3 can terminate even one level domain searches for policy, which
would be highly recommended of any domain utilizing DKIM when such
searching is adopted.
Item 4 minimizes memory required, and eliminates impact of changes to
the policy record structure used in conjunction with MX records.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
