Home > Articles > Networking

BIND 9's New Resource Records

  • Print
  • + Share This
DNS's new version of BIND, BIND 9, implements two new Resource Records to help you take DNS to an advanced level. Learn about them quickly in this article.
From the author of

DNAME, Domain Alias

RFC2672 specifies the DNAME record. The RFC is titled "Non-Terminal DNS Name Redirection," which means that DNAME is like CNAME, but it does not alias a single name—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 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 is to create a mechanism to help with network renumbering, but the result can also be used for domain renaming—and there's no doubt that it can be abused in other new and exciting ways. Considering the work that needed to be done by the lightweight resolver when using DNAME, it is recommended to use DNAME only when needed and only for the intended purposes—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 make walruss.penguin.bv, in other words. In the interest of keeping everything working and compatible, walruss.bv needs to 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 the following:

walruss         DNAME walruss.bv.

This lookup of names, such as www.walruss.penguin.bv, will result in a DNAME record being returned for walruss.penguin.bv; the lightweight resolver will then translate the name to www.walruss.bv and proceed to resolve that instead. This process is shown in Figure 1. The answer returned consists of a CNAME record that maps the requested name to the name arrived at by following DNAME records. A resolver that is not aware of DNAME will see this:

Figure 1

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

$ dig www.walruss.penguin.bv any
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
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"

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

$ dig www.walruss.penguin.bv any
walruss.penguin.bv.     3600    IN      DNAME   walruss.bv.
www.walruss.penguin.bv. 3600    IN      CNAME   www.walruss.bv.
www.walruss.bv.         86400   IN      A
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 asked for, the resolver still returns a DNAME record, a CNAME record, and finally the A record, as shown above. In addition, the returned DNAME record does not have any detrimental effect on other DNS tools, such as nslookup and host:

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

Answer crypto-validated by server:
Name:    www.walruss.bv
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. There are, of course, some restrictions on DNAME records:

  • There may 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.

  • This restriction is not found in the RFC, but avoid having DNAME-aliased hostnames in SOA, MX, NS records, and other places where CNAME is forbidden, because the DNAME results in a CNAME answer to the client. This may produce undesirable results.

  • + Share This
  • 🔖 Save To Your Account