UNIX System Administration Handbook - Evi Nemeth [271]
DNAME records delegate address chunks to other name servers. Their format is:
bitstring-label [ttl] IN DNAME domain-delegated-to
The idea is that different organizations can control the different pieces of an address or address prefix. You control the local 80 bits, your ISP controls a chunk, your ISP’s ISP controls a chunk, and so on. The excerpts below demonstrate the delegation that DNAME records can do. We use the address above in its four-pieces incarnation, in which the delegation path is from the root to my-isp to my-domain.
In this example, the $ORIGIN statements identify the context of each record. These excerpts are from the zone files at three different sites: the root of the ip6.arpa tree, my-isp.net, and my-domain.com—they do not represent a consistent configuration for a single site.
The root of the ip6.arpa tree, \[x2/3].ip6.arpa, delegates a particular 13-bit address to my-isp.net by entering the following lines into its zone file:
; delegate prefix to my-isp.net
$ORIGIN \[x2/3].ip6.arpa.
\[xfff0/13] IN DNAME ip6.my-isp.net.
These records create a sort of nickname for \[xfff0/13].\[x2/3].ip6.arpa that points to the string “ip6.my-isp.net.”. The ISP in turn delegates a 32-bit segment of address space to my-domain.com by including these lines in its ip6.my-isp.net zone file:
; delegate prefix to my-domain.com
$ORIGIN ip6.my-isp.net.
\[x80500201/32] IN DNAME ip6.my-domain.com.
This line forms a name, “\[x80500201/32].ip6.my-isp.net.”, which when expanded from the previous DNAME record becomes the 48-bit prefix of the IPv6 address. Those 48 bits are nicknamed ip6.my-domain.com.
In the zone files for ip6.my-domain.com, the rest of the address is mapped with a PTR record:
$ORIGIN ip6.my-domain.com.
\[x00090a0020fffe812b32/80] IN PTR host.my-domain.com.
We suggest that you not bother with the DNAME delegations if you have only one ISP and are not multihomed. Just list the whole 128-bit address in both forward and reverse zones. You still get some bits from your upstream ISP, but you can put them in your own zone files as long as your ISP tells you when it changes the prefix.
IPv6 is still young, at least from the deployment point of view. The registries are just starting to assign addresses, and the process will become smoother with experience. The local part of the IPv6 address never needs to change, and that’s great—no renumbering. But at many organizations, upstream ISPs don’t change frequently either, and so putting the ISP’s bits into your own data files seems like a good thing. A quick Perl script could change the prefix of all your addresses if you ever switched ISPs.
Commands in zone files
Now that we have looked at all the basic resource records, let’s look at the commands that can be embedded in a zone file to modify the records that follow them. There are four:
$ORIGIN domain-name
$INCLUDE filename
$TTL default-ttl
$GENERATE lots-of-args
Commands must start in the first column and be on a line by themselves.
As named reads a zone file, it adds the default domain (or “origin”) to any names that are not already fully qualified. The origin is initially set to the domain name specified in the corresponding zone statement in named.conf. However, you can set the origin by hand within a zone file by using the $ORIGIN directive.
The use of relative names where fully qualified names are expected saves lots of typing and makes zone files much easier to read. For example, the reverse records for a subnetted class B site might all be in one zone file, with $ORIGIN statements setting the context for each subnet. A statement such as
$ORIGIN 243.138.128.in-addr.arpa
could precede the records for the 243 subnet.
Many sites use the $INCLUDE directive in their zone database files to separate overhead records from data records, to separate logical pieces of a zone file, or to keep cryptographic keys in a file with restricted