New RRs | The Concise Guide to DNS and BIND

BIND 9 implements two new RRs, discussed in the following sections.

DNAME, Domain Alias

RFC2672 specifies the DNAME record. The RFC is titled "Non-Terminal DNS Name Redirection," which means that DNAME is similar to CNAME but does not alias a single name. Instead, it aliases a whole domain. It is non-terminal in the sense that when a DNAME is found, a new name is computed and then resolved. CNAME, on the other hand, is terminal in the sense that when the CNAME record has been found, the job is done.

DNAME is a simple enough record:

 [domainname]      DNAME [target]

The effect of this is that the entire subtree of DNS identified by the domain name can be mapped onto the target domain. The main purpose of this is to create a mechanism to help with network renumbering, but the result can also be used for domain renaming. And doubtless it can be abused in other new and exciting ways. Considering the work needed to be done by the lightweight resolver when using DNAME, I recommend using DNAME only when necessary and for the intended purposes only and then only for a limited, well-defined period of time.

Let's imagine that the good folks at Penguin Industries got venture capital and decided to buy Walruss. They decide to make Walruss a subsidiary of Penguin, and to make walruss.bv a subdomain of penguin.bv to create walruss.penguin.bv, in other words. In the interest of keeping things working and compatible, walruss.bv must be kept working while walruss.penguin.bv is phased in, announced, and made a part of everyday life. In the penguin.bv zone, the hostmaster would simply enter this command:

 walruss         DNAME walruss.bv.

From this point on, the lookup of names, such as http://www.walruss.penguin.bv, will result in a DNAME record being returned for walruss.penguin.bv. Additionally, the lightweight resolver will then translate the name to http://www.walruss.bv and then proceed to resolve that instead. This is shown in Figure 16.1. The answer returned consists of a CNAME record mapping the name asked for to the name arrived at by following DNAME records. A resolver that is not aware of DNAME will see this.

 $ dig www.walruss.penguin.bv any … ;; ANSWER SECTION: walruss.penguin.bv.     1H IN 39        \#(             ; unknown RR type         07 77 61 6c 72 75 73 73 02 62 76 00 )           ; .walruss.bv. www.walruss.penguin.bv.  1H IN CNAME  www.walruss.bv. www.walruss.bv.         1D IN A         10.1.0.3 www.walruss.bv.         1D IN MX        10 mail.walruss.bv. www.walruss.bv.         1D IN MX        20 mail.penguin.bv. www.walruss.bv.         1D IN HINFO     "i86" "Debian Linux" …

Figure 16.1. Making walruss.bv a subdomain of penguin.bv with a DNAME record, and resolving it.

graphics/16fig01.gif

The unknown record is the DNAME record, and the 39 is the DNAME RR type. As you can see, dig deciphers the contents, and the comment shows it as being .walruss.bv. A DNAME-aware dig shows this:

 $ dig www.walruss.penguin.bv any … ;; ANSWER SECTION: walruss.penguin.bv.     3600    IN      DNAME   walruss.bv. www.walruss.penguin.bv. 3600    IN      CNAME   www.walruss.bv. www.walruss.bv.         86400   IN      A       10.1.0.3 www.walruss.bv.         86400   IN      MX      10 mail.walruss.bv. www.walruss.bv.         86400   IN      MX      20 mail.penguin.bv. www.walruss.bv.         86400   IN      HINFO   "i86" "Debian Linux" …

If an A record is requested, the resolver still returns a DNAME record, a CNAME record, and finally the A record, as shown in the previous code. The returned DNAME record does not have any detrimental effect on other DNS tools, such as nslookup and host, either. Consider the following example:

 $ host -t A www.walruss.penguin.bv 127.0.0.1 Using domain server 127.0.0.1: walruss.penguin.bv 39 ??? www.walruss.penguin.bv is a nickname for www.walruss.bv www.walruss.bv has address 10.1.0.3 www.walruss.bv has address 10.1.0.3 $ nslookup www.walruss.penguin.bv 127.0.0.1 Answer crypto-validated by server: Server:  localhost Address:  127.0.0.1 Answer crypto-validated by server: Name:    www.walruss.bv Address:  10.1.0.3 Aliases:  www.walruss.penguin.bv

In the nslookup, the use of cryptography in BIND 9 is evident.

The approach used for network renumbering is the same, alias the in-addr.arpa zones for the affected networks.

Some restrictions do, of course, exist on DNAME records:

There can be other data for a name that has a DNAME record, but not another DNAME or a CNAME record.
There must not be any data for any subdomain of a DNAME record. This does not apply to data of classes other than the DNAME record. (Recall that IN [Internet] is a class, as is Chaos and Hesiod.)
This restriction is not found in the RFC, but avoid having DNAME aliased hostnames in SOA, MX, NS and records, as well as other places where CNAME is forbidden. This is because the DNAME results in a CNAME answer to the client and can have results you don't want.

A6, IPv6 Address

The A6 record is described in RFC 2874. It is an address record for IPv6 and is meant to replace the AAAA record. It has provisions, with the help of DNAME, for supporting network renumbering. A6 is intimately tied to IPv6 addressing schemes and hierarchies, and I refer the eager reader to the RFC for the details and use of this RR.