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?

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

Reply via email to