Subject: [ietf-dkim] New Issue: ssp-04 DNS operational requirement

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Jul 2008 19:40:58 -0700

4.3.  ADSP Lookup Procedure
,--
|If a query results in a "SERVFAIL" error response, the algorithm
|terminates without returning a result; possible actions include
|queuing the message or returning an SMTP error indicating a
|temporary failure.
'--
The term "queuing" is rather vague.  In addition SERVFAIL may not be  
visible behind a caching resolver.  In this section it likely to imply  
a message is to be held (as in requeued) pending restoration of DNS  
services, and not that the message is to be queued for delivery to  
individual recipient email-addresses.  This section also imposes a new  
interoperability requirement for SMTP that previously did not exist.   
Prior to the imposition of this requirement, crucial systems with  
addresses assigned within a host address entry could sustain  
communications even in the event of DNS becoming inoperable.

Perhaps the following sentence could be added:
---

To ensure message reception remains viable for crucial systems when  
DNS fails, the IP addresses of crucial SMTP clients should be white- 
listed. This will allow ADSP and DKIM to be selectively bypassed  
during such events.

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jul 2008 07:16:42 +0200

> listed. This will allow ADSP and DKIM to be selectively bypassed  

NAK, I think "white lists of crucial IPs" are on the wrong side of
the WG charter, and "crucial system" is an undefined term.

 Frank

---

From: Roland Turner <[email-masked]>
Date: Thu, 03 Jul 2008 06:54:23 +0100

On Wed, 2008-07-02 at 19:40 -0700, Douglas Otis wrote:

> This section also imposes a new  

Surely the right and ability of administrators to make such arrangements
with respect to the relationships between machines under their control -
and/or that of others with whom they have private arrangements - is
implicit in _all_ RFCs?

That a spec doesn't give me permission to add whitelisting facilities
for communication between crucial hosts doesn't mean that I can't do so,
nor that my doing so creates interoperability problems.

- Roland

-- 
  Roland Turner | Product Manager, RealMail | BoxSentry Pte Ltd
  3 Phillip Street, #13-03 Commerce Point, Singapore 048693
  Mob: +65 96700022 | Skype: roland.turner | Fax. +65 65365463
  [email-masked] | www.boxsentry.com

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 3 Jul 2008 09:02:47 -0400

> listed. This will allow ADSP and DKIM to be selectively bypassed
Since the cited paragraph doesn't require any particular behavior, I don't see 
the value in this.  

I do wonder if it would be useful to return an error state as a result rather 
than requiring one to infer a protocol related error from no result.

Scott K

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Jul 2008 06:26:54 -0700

>>>>> On Wed, 2 Jul 2008 19:40:58 -0700, Douglas Otis <[email-masked]> 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)
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Jul 2008 11:06:57 -0700

On Jul 3, 2008, at 6:26 AM, Wes Hardaker wrote:

>>>>>> On Wed, 2 Jul 2008 19:40:58 -0700, Douglas Otis <[email-masked] 
>>>>>> > said:
>
> 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