On Jun 8, 2007, at 5:41 PM, Michael Thomas wrote:
John Levine wrote:
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.
Yes, my screwup when cutting and pasting.
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.
Right, I just wanted remind people once again what wildcards do and
don't provide. Synthesizing the wildcard by mechanically populating
the record at existing nodes is possible, though extremely kludgey --
at least with the resolvers I'm familiar with.
One question though: is this an artifact of the actual protocol, or an
artifact of the resolvers themselves? I've never been clear on that.
As far as the bits on the wire, aren't wildcards actually invisible
to the querier?
Yes. Wildcards don't actually exist in DNS. The behavior
being discussed here is an implementation detail of one
(commonly used) authoritative server[1], though other
servers often have similar functionality, often mostly
compatible.
Wildcards are something of a hack, and I understand
there are significant incompatibilities in wildcard handling of
some records between different authoritative servers. I
think we'd be fine with simple usage, but anything subtle
should not[2] be suggested by anyone who isn't intimately
familiar with the operational issues with the various authoritative
servers out there.
Cheers,
Steve
[1] For the RFC lawyers, not of any actual operational value:
There are some RFCs that specify some of this behaviour,
I believe, in the context of zone transfers rather than DNS queries
but those RFCs really just document the behaviour of that
one authoritative server, and most people consider them
a mistake worth forgetting as far as being a Standard with
a capital S is concerned, rather than just documentation
of current practice with that one server.
[2] This email is RFC 2119 compliant.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html