[ietf-dkim] DNS wildcarding behavior scenarios

[Michael Thomas]

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.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.org 
>>>> [mailto:ietf-dkim-bounces at mipassoc.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
>>>>
>>>>         
>>