ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree

2008-04-08 11:07:50
I'm going to see whether we can actually have some constructive dialogue in 
this 
thread, by posting a message responding to a point that Eliot raised in a 
message that had a different focus:


Dave Crocker wrote:
3.  At least one of the sub-tree mechanisms is attempting to glean 
information 
from the absence of publisher action.  Let me explain:
...

         c) Checking for the presence of an A record is intended to try tell 
you 
something in the absence of an explicit action by the domain owner.  That's 
it's 
flaw: It is intuiting ADSP information from non-ADSP action.

     While there is nothing wrong with checking the A record, it's semantics 
have literally nothing (directly) to do with ADSP.

(and, for completeness, please modify the above:  s/ A / NXDOMAIN /.)


Eliot said:
     the fundamental basis for your 
concern is that there are two independent systems that have no basis for 
interdependency.  

The semantics of a non-ADSP DNS record certainly were not intended to be 
relevant to ADSP. And I doubt anyone is going to claim that non-ADSP DNS 
records 
were created for the purose of ADSP use.

Whether ADSP can reasonably extract some semantics is an entirely reasonable 
line of question.

What we need to see is discussion and consensus that it can and does and that 
the benefits outweighs the costs.

An nice example of a counter-argument is:

Wietse Venema wrote:
The problem is that "valid email origin" is a subset of all the
names that resolve in the DNS. In other words, there are false
positives in the algorithm that continues when [any DNS] record
lookup succeeds.

One interpretation of this point is that the presence of a DNS entry (that is, 
a 
'failure' to get an NXDomain) might be meaningful, but the scope of its meaning 
is much broader than ADSP.  Once again:  A mechanism possibly worth pursuing, 
but outside of ADSP.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>