In previous installments we’ve been looking at aspects of the design of the DNS (see part I, II, III, IV, V and VI). Today we look at the relationship of similar names in the DNS.

A poorly appreciated aspect of the DNS is that there is no inherent relationship between similar looking names. That is, to a person the names example.com and www.example.com may look obviously related, but to the DNS, they’re just two different names. Names do exist in a tree, and as we saw in part III, if a name exists in a tree, all names above it (closer to the root) exist, even if there is no data at some of those names, and conversely, if a name does not exist, all possible names below it don’t exist either. But if two names both exist, the DNS has no good way to describe the relationship between them.

The way to make two names “the same” in the DNS is to use a CNAME, for a single name, or a DNAME, for all the names below a name. When a DNS cache receives a CNAME result in response to a non-CNAME query, it will repeat the query for the target of the CNAME, and return both the CNAME and the target record in the response to the original request. A DNAME is sort of a generalized CNAME, and says that the names in the tree below one name are aliases for the tree below another name. That is, if a is a DNAME for b, then x.a is an alias for x.b. DNAMEs have been around since 1999, but for the benefit of caches that still don’t understand them, when a server returns a DNAME answer, it also synthesizes suitable CNAMEs as needed when replying for a name below the DNAME.

CNAMEs have been around since the dawn of the DNS, but they can only partially make one name a synonym for another. A CNAME only provides an alias for its own name, and not for any prefixed name. So if foo.example is a CNAME pointing to bar.example, queries for _prefix.foo.example won’t work unless there are additional CNAMEs for every prefix defined for bar.example. This makes the provisioning considerably more difficult, since it means every time you add or change a prefixed name record, you have to know everyone who’s pointing a CNAME at your name, and tell them to add or change the prefix, exactly the sort of error-prone manual processing that computers were supposed to avoid.

When a DNS request is satisfied via CNAMEs, the client can see the chain of CNAMEs. So when a DNS client or cache looks up a prefixed name and finds nothing, it could, in principle, make a query for the base name, see if there’s a CNAME, and if so make a prefixed query for the target, in this case _prefix.bar.example. Prefixed names have been around for 15 years (since the invention of SRV records,) and nobody to my knowledge has done anything special about CNAMEs and prefixes, so it seems a little late to start now. DNAMEs alias the entire subtree below a name, which deals with the prefixed names, but doesn’t alias the name itself, limiting its utility for aliasing specific names and their variants.

In the next and final installment, we’ll look at ways the DNS interacts more or less successfully with other applications.