dns dname is almost useless

DNAME, if you are not aware, is a DNS record type defined in RFC 2672. If you are familiar with the DNS’s CNAME record, then think of DNAME as a sort of super CNAME. If not, well, I’ll try to explain how DNAME works.

A Brief DNAME Tutorial

Whereas CNAME is used to alias a single domain name to another, DNAME aliases an entire subtree to another. It accomplishes this in one of two ways: either it acts as a CNAME generator, or it is understood by the client and the client implements the same behavior without all the generated CNAMEs.

So, some examples. Imagine that this record exists in its proper place in the DNS:

www.bar.com IN CNAME www.foo.com.

This means that queries for www.bar.com, of any type (A, AAAA, MX, etc.) will get aliased to the same query for www.foo.com. But queries for mail.bar.com (for example) do not. Nor do queries for yyy.www.bar.com. Now imagine a similar usage of DNAME:

bar.com IN DNAME foo.com.

Now, the DNAME record will synthesize a CNAME for any query below bar.com. A query for www.bar.com will get aliased to www.foo.com. mail.bar.com will be aliased to mail.foo.com. x.y.a.b.c.bar.com will be aliased to x.y.a.b.c.foo.com. Everything. But, queries for bar.com won’t be aliased at all. DNAME only matches below the name, not at the name.

All in all, a pretty clever idea.

Using DNAME to Create IDN TLDs

So, let’s think of some ways that DNAME might be used. One idea that has been bandied about is to create IDN aliases for TLDs. So, for example, imagine a DNAME that maps ‘xn–c4m’ (somebody feel free to suggest a real punycoded com equivalent) to ‘com’:

xn--c4m. IN DNAME com.

The idea being that while the world wants native language versions of com, net, etc, the world doesn’t actually want them to be new TLDs (where amazon.xn–c4m could be different than amazon.com.) So, using DNAME in this way looks great: somebody who registered xn--b7r.com now gets to advertise their domain as bår.cøm (or whatever; I’m too lazy to actually use real unicode here, people). When somebody queries for www.bår.cøm, this gets converted to www.xn--b7r.xn--c4m IN CNAME www.xn--b7r.com. Not bad, not bad at all. However, what happens when the owner of xn--b7r.com starts thinking of his domain as actually “xn–b7r.xn–c4m” (or bår.cøm, since people don’t actually think in punycode…), and creates a subdomain:

xn--su9b.xn--b7r.com. IN NS ns1.xn--b7r.xn--c4m. xn--su9b.xn--b7r.com. IN NS ns2.xn--b7r.xn--c4m.

Well, what happens is that this delegation actually doesn’t work. And it doesn’t work because ns1.xn–b7r.xn–c4m doesn’t actually exist as a name in the DNS. Instead, it is gets converted into a CNAME, and NS record targets cannot be CNAMEs (This is pointed out in RFC 2181, but the real point is that resolvers won’t generally handle this case.) Note that it isn’t that the owner can’t have subdomains. It is that he can’t use the IDN TLD version of his domain the same way as the real one. So, the DNAME based IDN TLD is a second-class citizen, and will probably lead to operational problems as end users fail to realize that this IDN TLD isn’t actually a real TLD, and what the consequences of that are.

Using DNAMEs for Variants

OK, so how about another potential use, instantiating IDN variants? This is slightly different from the case above in that the idea here is to create aliases to existing second level domains as a courtesy. It isn’t really nearly as likely that someone down the road will mistake the DNAME for a real name; this is just to help people who enter a variant get to the right place.

Actually, this idea isn’t really about IDN variants at all. Imagine that you have a bunch of domains of which one is the “real” one, and the rest were just registered to keep other jackasses from registering them and defaming you. Or just registered because people might try to find you under the other domains. For an example, let’s imagine that Amazon has amazon.com (the main zone), amazon.co.uk, and amazonsucks.com, all of which Amazon wants to behave the same. Instead of maintaining a bunch of copies of the amazon.com zone, couldn’t you just leave one “real” and have the rest be DNAMEs? This would make managing these copies so much easier, wouldn’t it?

Well, yes, but…. Since the DNAME doesn’t match at itself, you haven’t aliased the entire zone, since you haven’t aliased the name “amazon.com” itself. Alas, there are always critical records stored at the apex. At the very least, an MX record. So, you haven’t really saved yourself much work, since you will (most likely) have manage the variant zones anyway, just to keep the zone apex in sync.

Another way to accomplish this task is to use the same zone file for all of the variants. BIND, at least, makes this easy: just make sure that everything in the zone is relative to the “origin”. When the file is loaded against different zones, the origin will be set to each zone in turn. (This is a bit like using all relative paths in your HTML and then having the freedom to move the pages around without changing the HTML.)

The Good News

So what is DNAME good for? The canonical use for DNAME is to move zones around in the reverse tree, typically for renumbering. This works better, because the zone apexes in the reverse tree aren’t used much (or at all). It is also useful (although not perfect) in cases where you do not control the zone that you wish to mirror.

I won’t say that DNAME is completely useless: a few people have certainly successfully used it. But, it doesn’t work adequately in situations where no other good solutions exist (IDN TLDs), And even where it does work, there is always another way to accomplish the same thing that, generally, isn’t much more work.

Also, that it has been around for six years and hasn’t seen any sort of widespread use is, at least, an indication that DNAME doesn’t solve any pressing problem.