OK add a TXT record:

gate.mtcc.com TXT "Here I am"

Problem solved.

> -----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

Reply via email to