Home / Blogs

The Design of the Domain Name System, Part VIII - Names Outside the DNS

John Levine

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.

By John Levine, Author, Consultant & Speaker. More blog posts from John Levine can also be read here.

Related topics: DNS

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

MX and CNAME Alessandro Vesely  –  Sep 24, 2011 1:33 AM PST

The phrase "a name with an MX" may sound ambiguous if it's not clear the distinction between the label and the content of the MX RR. I'd like to clarify that. Given the address user@example.org, the mail-domain example.org is an MX label. In theory, it may resolve to a CNAME:

example.org. CNAME example.com. example.com. MX 10 smtp-server.example.com. SMTP-compliant example

However, the MX content cannot resolve to a CNAME

example.com. MX 10 smtp-server.example.com.
smtp-server.example.com. CNAME other-server.example.com. bad example

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

Join Paul Vixie & Robert Edmonds at the Upcoming Distinguished Speaker Series

LogicBoxes Announces Automation Solutions for ccTLD

3 Questions to Ask Your DNS Host About DDoS

Introducing Our Special Edition Managed DNS Service for Top-Level Domain Operators

Afilias Partners With Internet Society to Sponsor Deploy360 ION Conference Series Through 2016

The Latest Internet Plague: Random Subdomain Attacks

Digging Deep Into DNS Data Discloses Damaging Domains

Nominum Announces Future Ready DNS

Video Interviews from ICANN 50 in London

Dyn Acquires Internet Intelligence Company, Renesys

Introducing getdns: a Modern, Extensible, Open Source API for the DNS

Why We Decided to Stop Offering Free Accounts

Tony Kirsch Announced As Head of Global Consulting of ARI Registry Services

24 Million Home Routers Expose ISPs to Massive DNS-Based DDoS Attacks

Dyn Acquires Managed DNS Provider Nettica

Why Managed DNS Means Secure DNS

SPECIAL: Video Interviews from NamesCon 2014 in Las Vegas

Rodney Joffe on Why DNS Has Become a Favorite Attack Vector

Motivated to Solve Problems at Verisign

Dyn Announces Largest Quarter In Company History

Sponsored Topics

dotMobi

Mobile

Sponsored by
dotMobi
Afilias

DNSSEC

Sponsored by
Afilias
Verisign

Security

Sponsored by
Verisign
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines