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:

1. Wildcards don’t match enough.
2. 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:

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:

where the expected behavior is that (_http ._tcp.foo.example.com, 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.