[ietf-dkim] DNS wildcarding behavior scenarios

[Steve Atkins]

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.