Executive summary: Wildcards, either TXT of a new one DO NOT meet this
requirement.
Wildcards only cover nodes with no records at all. You need to put an
explicit record at any node that has any other kind of node. This is
a well-documented aspect of DNS wildcards that we usually assume will
be addressed by some sort of semi-automated process for generating all
the required records.
0) Pertinent Parts of my Zone: ...
mtcc.com.*. IN TXT "v=spf1 a mx include:cisco.com
I sure hope that was supposed to be *.mtcc.com. since a trailing star
only matches a literal star.
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.
This is a case where you need an explicit record.
5) Subnode from a valid non-TXT bearing node
Here it returns NXDOMAIN. This the behavior you expect if there wasn't
the *.mtcc.com wildcard.
This is the other case where you need an explicit record as well as a
wildcard to cover subdomains.
6) As it relates to the _domainkey subnode
Since host names can't contain underscores, that's not a valid e-mail
domain name, so it doesn't matter.
7) A TXT record that overrides the top level wildcard
Somewhat similar to #4, although if the SSP record is a TXT record,
you're depending on clients that use anything encoded as a TXT record,
including SPF/S-ID and dkim-base to look at the version strings and
throw away the ones that aren't the right kind.
Nearly everyone agrees that in retrospect, it would have been better
to design DNS wildcards differently. But if you control the whole
zone, particularly if it's a new RR so it doesn't contaminate existing
uses of TXT records, you can mechanically add extra records to get the
effect of the wildcards you actually want.
Personally, I agree that this is really klunky, and this problem is
one of the reasons that SSP is unlikely to be of practical use to mail
receivers.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html