On Jul 3, 2008, at 6:26 AM, Wes Hardaker wrote:
On Wed, 2 Jul 2008 19:40:58 -0700, Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org
said:
DO> 4.3. ADSP Lookup Procedure
DO> ,--
DO> |If a query results in a "SERVFAIL" error response, the algorithm
DO> |terminates without returning a result; possible actions include
DO> |queuing the message or returning an SMTP error indicating a
DO> |temporary failure.
DO> '--
DO> In addition SERVFAIL may not be visible behind a caching resolver.
Speaking only about the SERVFAIL part: I don't think it's
appropriate to discuss particular failure reasons behind DNS.
Simply indicating that DNS failed to look something up is a better
way to form the text since it's entirely possible that other issues
may cause similar results. EG, if a lookup fails to validate via
DNSSEC and related policies then effectively you're in a similar
boat: you're not sure about the results and you've failed to
retrieve the needed data (but for yet another reason). (It's even
possible that DNS itself could be updated in the future to return
new error codes because of DNSSEC or other technologies that need to
introduce new negative results).
How about "If a DNS query fails to succeed in returning a valid
positive or negative result (such as indicated by a SERVFAIL or
DNSSEC validation failure) then the algorithm...
(This only deals, as I said, with the usage of the "SERVFAIL" term;
I'll defer about the other half of this issue)
When an inbound MTA is behind a caching resolver, a cause for
unavailable data is not likely discernible. Based upon section 6.2,
motivations for the draft making this distinction is to reduce a bad
actor's incentive for DDoSing a domain's DNS as a method that
overrides DKIM/ADSP protections. Unfortunately, most MTAs share a
caching resolver to minimize DNS overhead and related traffic.
Implementing an email architecture to conform to a recommendation that
inbound MTAs distinguish different DNS failure modes may actually
increase DDoS concerns. The added DDoS traffic would be the result of
every inbound MTA individually implementing their own recursive DNS.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html