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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > >> 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: [EMAIL PROTECTED] > >>>> [mailto:[EMAIL PROTECTED] 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
