dns wildcard musings
There has been a rather interesting, although frustrating, discussion on namedroppers about wildcards. I woke up early this morning and thought some about them, and why folks consistently complain about DNS wildcards. It seems to me that when non-experts look at wildcards they come to one of two conclusions:
- Wildcards don’t match enough.
- Wildcards match too much.
Don’t match enough
My experience has generally shown that when a naive user is introduced to wildcards, they generally expect the wildcards to apply in more situations than they actually do, leading to long-standing common errors (c.f. RFC 1034, section 4.3.3). The classic wildcard MX:
$ORIGIN example.com. * IN MX 10 a a IN A 126.96.36.199 b IN A 188.8.131.52 mail IN MX 20 b
The naive user generally expects the wildcard to match
(c.example.com, MX) (which it will),
(a.example.com, MX) (which it
won’t), and possibly even
(b.a.example.com, MX), but not
(mail.example.com, MX). That is, a possibly more natural
interpretation of the wildcard is one of: this is the default MX
record for the zone, use it when no other MX in the zone applies.
Match too much
This typically comes up when folks struggle with wildcards interacting with DNS records that use so-called “name hacks”, like the SRV record. “Why can’t I have a wildcard SRV?”, they ask. Why cannot a DNS server exhibit a great deal of control over how a wildcard matches? So we see proposals that look like:
_http._tcp.*.example.com. IN SRV ....
where the expected behavior is that
SRV) matches, but
(bar.example.com., SRV) does not, and
(_smtp._tcp.foo.example.com., SRV) certainly does not. The limits of
how much control this wildcard mechanism should have are not typically
well explored by such proposals. However, the example above might be
considered a lower bound of control. An upper bound might be to use
regular expressions as wildcard matching rules. (Not that regular
expressions represent a real upper limit – any arbitrarily complex
language could be defined). While I personally cannot think of many
interesting uses for an expressive (say regular expression-based)
selectively matching wildcard, my gut feeling is that there would
be. I do not necessarily think that there is a call for multiple new
wildcard mechanisms. The first issue (match too little) could be
handled by a zone pre-processor (by which I mean that the desired
semantics are expressible using current DNS, but just verbose),
and/or a single new mechanism could encompass both behavioral issues.