Internet and e-mail policy and practice
including Notes on Internet E-mail


Click the comments link on any story to see comments or add your own.

Subscribe to this blog

RSS feed

Home :: Internet

06 Sep 2011

The design of the Domain Name System (Part VII) - Related names are not related Internet

In previous installments we've been looking at aspects of the design of the DNS. 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 and 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 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 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.

  posted at: 00:44 :: permanent link to this entry :: 0 comments
Stable link is


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

It turns out you don’t need a license to hunt for spam.
62 days ago

A keen grasp of the obvious
Italian Apple Cake
620 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse

My Mastodon feed

© 2005-2024 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.