ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] DNS wildcarding behavior scenarios

2007-06-11 13:44:05
On the contrary, most DNS servers can handle it today.

The only difficulty is if you also have DNSSEC, and that is not much of a 
problem since your signer process can do the expansion.


-----Original Message-----
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com] 
Sent: Friday, June 08, 2007 10:09 PM
To: Hallam-Baker, Phillip
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] DNS wildcarding behavior scenarios

Hallam-Baker, Phillip wrote:
OK add a TXT record:

gate.mtcc.com TXT "Here I am"

Problem solved.
  

Having spent time with our enterprise management folks who 
manage our DNS, I can safely say "were it so simple". This is 
not a straightforward proposition for sites who have 100 and 
1000's of labels under their top domain. This would require 
significant investment in a wildcard
synthesis infrastructure that does not currently exist.        

       Mike
  
-----Original Message-----
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
Sent: Friday, June 08, 2007 3:45 PM
To: Hallam-Baker, Phillip
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] DNS wildcarding behavior scenarios

Hallam-Baker, Phillip wrote:
    
I don't quite understand the point here.

Why do you think it is necessary to define a signing policy
      
for a node that does not exist and does not therefore send mail?
    
case 4 demonstrates that a wildcard DOES NOT cover a node 
that DOES 
EXIST. This is absolutely and explicitly in scope of requirement 
5.1.4

           Mike

    
You certainly need to define a signature policy but its not
      
a signing policy.
    
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of 
Michael Thomas
Sent: Friday, June 08, 2007 12:26 PM
To: IETF-DKIM
Subject: [ietf-dkim] DNS wildcarding behavior scenarios


Hi all,

I think that there is a huge amount of confusion about how DNS 
wildcards work, and in particular how they might come to
        
bear on the
    
discovery problem for ssp-requirements, 5.1.4.

Executive summary: Wildcards, either TXT of a new one DO 
NOT meet 
this requirement.

Here is the proof using my own zone (using bind 9.3):

0) Pertinent Parts of my Zone:

mtcc.com.         IN      TXT     "v=spf1 a mx include:cisco.com 
include:volcano.net ~
all"
mtcc.com.*.       IN      TXT     "v=spf1 a mx include:cisco.com 
include:volcano.net ~
all"
gate              IN      A       64.142.29.1

alltheway.kirkwood._domainkey.mtcc.com.   3600   IN    TXT   
"v=DKIM1;
k=rsa; g=*; s
=email; t=y; " 

        

"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCo0kNKsffbCSZ8mqsaApvPYyDzRf
    
GYXZBmg4VhvugbQ4wYrZXMGn9m/V7XJxKpJj9cHE2VHUemZUPlOto8FgerCrQM
aQC0tHgBw0DRjFCurMtS+4
EOfXcjn5LQ308BmVr2lUwl7QHuIFBE9Ls/66xld4AJxLrb9+" 
"yeTIAUZdX7WwIDAQAB;"

1) Top level query

    fugu$ host -t txt mtcc.com
    mtcc.com descriptive text "v=spf1 a mx include:cisco.com 
include:volcano.net ~all"

    As you would expect: the exact match worked.

2) Query for nonexistent node adjacent to top level

    fugu$ host -t txt asdfasd.mtcc.com
     asdfasd.mtcc.com descriptive text "v=spf1 a mx
        
include:cisco.com
    
include:volcano.net ~all"

    This works as expected because of the top level wildcard.

3) Query for nonexistent node arbitrarily far from the top node

    fugu$ host -t txt asdfsdf.asdf.mtcc.com
    asdfsdf.asdf.mtcc.com descriptive text "v=spf1 a mx 
include:cisco.com include:volcano.net ~all"

    This works as you'd expect since there is a clear line
        
to the top
    
    of the wildcard.

4) Node which has a valid A record

    fugu$ host -t txt gate.mtcc.com
    gate.mtcc.com has no TXT record

    Here, the wildcard ceases to work and the resolver 
returns an 
ancount of zero.
    This case still *must* be handled somehow by SSP.

5) Subnode from a valid non-TXT bearing node

    fugu$ host -t txt asdfsdf.gate.mtcc.com
    Host asdfsdf.gate.mtcc.com not found: 3(NXDOMAIN)

    Here it returns NXDOMAIN. This the behavior you expect
        
if there
    
wasn't
    the *.mtcc.com wildcard.

6) As it relates to the _domainkey subnode

    fugu$ host -t txt _domainkey.mtcc.com
    _domainkey.mtcc.com has no TXT record

    Note again that the wildcard at mtcc.com does not cover this 
since there are
    subnodes that bear RR's. This is really another case
        
of 4 but it
    
works even
    when it's an interior node that bears no RR's at its node.

7) A TXT record that overrides the top level wildcard

    fugu$ host -t txt alltheway.kirkwood._domainkey.mtcc.com
    alltheway.kirkwood._domainkey.mtcc.com descriptive text 
"v=DKIM1\; k=rsa\; g=*\; s=email\; t=y\; "
"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCo0kNKsffbCSZ8mqsaApv
PYyDzRfGYXZBmg4VhvugbQ4wYrZXMGn9m/V7XJxKpJj9cHE2VHUemZUPlOto8F
gerCrQMaQC0tHgBw0DRjFCurMtS+4EOfXcjn5LQ308BmVr2lUwl7QHuIFBE9Ls
        
/66xld4AJxLrb9+" 
      
"yeTIAUZdX7WwIDAQAB\;"

    Note that here, we can take the place of the top level
        
wildcard by
    
    simply putting a TXT record in. This is true of any
        
place we might
    
    want to put a TXT record.

8) Subnodes of valid TXT nodes

    fugu$ host -t txt asdf.alltheway.kirkwood._domainkey.mtcc.com
    Host asdf.alltheway.kirkwood._domainkey.mtcc.com not
found: 3(NXDOMAIN)

    This is nothing more than case 5 again.




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

        
    



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

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