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


Don't miss a thing – get the Weekly Wrap delivered to your inbox.


MX and CNAME Alessandro Vesely  –  Sep 24, 2011 2:33 AM PDT

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

Explore Topics

Dig Deeper


DNS Security

Sponsored by Afilias


Sponsored by Verisign
Afilias Mobile & Web Services

Mobile Internet

Sponsored by Afilias Mobile & Web Services

Promoted Posts

Now Is the Time for .eco

.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»

Industry Updates – Sponsored Posts

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Don't Gamble With Your DNS

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

How Savvy DDoS Attackers Are Using DNSSEC Against Us

Radix Adds Dyn as a DNS Service Provider

Dyn Partners with the Internet Systems Consortium to Host Global F-Root Nameservers

Is Your TLD Threat Mitigation Strategy up to Scratch?

Domain Management Handbook from MarkMonitor

What Holds Firms Back from Choosing Cloud-Based External DNS?

Computerworld Names Afilias' Ram Mohan a Premier 100 Technology Leader

Protect Your Privacy - Opt Out of Public DNS Data Collection

Measuring DNS Performance for the User Experience

Introducing Verisign Public DNS: A Free Recursive DNS Service That Respects Your Privacy

Internet Grows to 296 Million Domain Names in Q2 2015

Protect Your Network From BYOD Malware Threats With The Verisign DNS Firewall

Introducing the Verisign DNS Firewall

Verisign Named to the Online Trust Alliance's 2015 Honor Roll

3 Key Steps for SMBs to Protect Their Website and Critical Internet Services

Key Considerations for Selecting a Managed DNS Provider