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

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


To post comments, please login or create an account.

Related Blogs

Related News


Industry Updates – Sponsored Posts

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

Help Ensure the Availability and Security of Your Enterprise DNS with Verisign Recursive DNS

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

Sponsored Topics