BIND 9's New Resource Records
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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:
){kind=link}
Making walruss.bv a subdomain of penguin.bv with a DNAME record, and then resolving it.
$ 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"
...
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 ... ;; 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 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 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. 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.