In previous installments we’ve been looking at aspects of the design of the DNS (see part I, II, III, IV, V, VI and VII). In today’s grand finale we look at the the subtle but very knotty issue of names inside and outside the DNS.

In the early years of the DNS, domain names were typically resolved to A records which were used to identify a host running a service. With the notable exception of e-mail, once the host was identified, the name no longer mattered. Another way to look at it is that for traditional services like telnet and FTP, servers don’t know or care what their names are. If you want to give a Telnet server a new name, just point a new A or CNAME record at it, and it’ll work.

E-mail was and is different. While a mail server doesn’t need to know what its name is, it definitely needs to know for what domains it handles mail, i.e., what MX records should be pointing at it. This means that CNAMEs pointing at a name with an MX generally won’t do what you’d want.

In the early World Wide Web, servers didn’t need to know their names, since each logical server had a separate IP address. As the Web grew rapidly, the virtual server feature was added to conserve IP addresses. It allows many names to resolve to the same IP address, with the Web server returning different content for different names.

What mail and the Web have in common here is that even after all of the DNS queries are done, and the names are all resolved to IP addresses, and a TCP session is active to the Web or mail server, the domain names appear in the data stream. In some cases, particularly mail, this seems to be unavoidable, but it makes the provisioning much more difficult, as the DNS and the application configuration need to be kept in sync.

Prefixed names (which we mentioned in the last two installments: VI & VII) can present problems when a server has multiple names. The key observation is that CNAMEs work for servers that don’t know their names, and prefixes work for servers that do. We had an argument in the Anti-Spam Research Group a while ago about possible ways to tell a user mail program where to send spam button complaints. One possibility was to put the info in a record at a prefix of the POP or IMAP server name like _report.server.example. I didn’t think that would work very well because POP and IMAP servers don’t know their names, and it is common in hosted mail systems to use CNAMEs for the server names. A server can have thousands of CNAMEs pointing at it, all of which would need an extra manually configured CNAME for each prefix in use.

On the other hand, nobody ever points a CNAME at a name with an MX because it wouldn’t work without configuring the mail server to know about the CNAME, and once it’s that complicated, everyone uses another MX instead. Since there aren’t any CNAMEs, prefixed names for DKIM work just fine in practice.

Web servers are sort of a middle case. People use lots of CNAMEs to point to web servers, but in IPv4 at least, they use them in very stylized ways since most web servers use virtual names so again the DNS and the server have to be coordinated.

To the extent applications can avoid this need to coordinate DNS and non-DNS configuration, and have the results of the DNS queries completely identify the desired service, they will work much more smoothly with the DNS. Ways to do this are to have adequate IP addresses (there’s no need for virtual web servers in IPv6), to use SRV so that different services can be on different ports, or perhaps to use new RRTYPEs that include a token that the client can present to the server to tell which DNS record led it to the server.

The DNS technical community has been wrestling with the question of how to make two DNS trees “the same” for quite a while. ICANN now has a process to issue non-ASCII top-level domains in addition to the traditional two letter codes, such as .?? in addition to .HK. In many cases, the new domain is supposed to be the same as the existing one, for some version of “same”. After going through the arguments several times, I came to the conclusion, which I think was shared by most of the participants, that nobody has defined the sameness desired in that case, but whatever it is, it’s unlikely that even with some improved version of CNAME or DNAME that the DNS could provide it.

Since it’s now possible to have domain names in any script, the number of nominally equivalent domain trees is likely to increase, and if the equivalence is supposed to be component by component, the number of nominally equivalent names will become huge. (That is, if A and B are supposed to be equivalent to each other, and C and D to each other, then A.C, A.D, B.C, and B.D are all the same.) So what could we do in the DNS to make the configuration easier?

With no changes to the DNS at all, applications could handle CNAME or DNAME aliases. The result from a DNS lookup that’s redirected via CNAMEs includes all the CNAMEs in the chain, so it would be easy enough for an application getting a request for a domain it doesn’t recognize to do a suitable DNS lookup (MX for mail, A or AAAA for web, etc.) and see if the unknown name is a CNAME for one it does know. This has been possible for decades, but to my knowledge nobody’s ever done it, suggesting that whatever problem it solves isn’t worth solving. Beyond the programming effort, this also presents a security issue in that anyone can now point a CNAME at your server and make it handle a domain you might not have wanted to handle.

The most plausible solution so far to that problem is a new CLONE record that is sort of the inverse of CNAME, in which the primary name lists all of the other equivalent names, and the name server arranges to handle all of them. DNS lookups for any of the equivalent names also provide the primary name, and the DNSSEC signature is adequate to prove that the equivalence is authorized by the primary.

This would require new coordination whenever one server delegates a subtree to another, in that the second server would have to inherit all of the cloned names that apply to the name delegated from the first server, but it’s not hard to imagine ways that they could coordinate automatically. So far this is all hypothetical, and there’s still a lot of work to be done getting DNSSEC more widely deployed before anything like CLONE is likely to happen, but it’s one of the few ways in which the DNS has any chance of interesting extensions.