Home / Blogs

The Design of the Domain Name System, Part VII - Related Names Are Not Related

John Levine

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.

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.


To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Dig Deeper


Sponsored by Verisign

DNS Security

Sponsored by Afilias

Mobile Internet

Sponsored by Afilias Mobile & Web Services

IP Addressing

Sponsored by Avenue4 LLC

Promoted Posts

Buying or Selling IPv4 Addresses?

ACCELR/8 is a transformative IPv4 market solution developed by industry veterans Marc Lindsey and Janine Goodman that enables organizations buying or selling blocks as small as /20s to keep pace with the evolving demands of the market by applying processes that have delivered value for many of the largest market participants. 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