IPv6 Forward and Reverse Mapping (DNS and BIND, 4th Edition)

10.16. IPv6 Forward and Reverse Mapping

Clearly, the existing A record won't accommodate IPv6's 128-bit addresses; BIND expects an A record's record-specific data to be a 32-bit address in dotted-octet format.

The IETF came up with a simple solution to this problem, described in RFC 1886. A new address record, AAAA, is used to store a 128-bit IPv6 address, and there's a new IPv6 reverse-mapping domain, ip6.int. This solution was straightforward enough to implement in BIND 4.9. Unfortunately, not everyone liked the simple solution, so they came up with a much more complicated one. This solution, which we'll describe shortly, involves the new A6 and DNAME records and required a complete overhaul of the BIND name server to implement.

Use of the old AAAA record and ip6.int is now deprecated, but there's enough IPv6 software out there still using it -- and not the new stuff -- that it's important to understand both methods.

10.16.1. AAAA and ip6.int

Now the simple way to handle this, described in RFC 1886, is with an address record that's four times as long as an A record. That's the AAAA (pronounced "quad A") record. The AAAA record takes as its record-specific data the textual format of an IPv6 record as described earlier. So for example, you'd see AAAA records like this one:

ipv6-host    IN    AAAA    4321:0:1:2:3:4:567:89ab

RFC 1886 also established ip6.int , a new reverse-mapping name space for IPv6 addresses. Each level of subdomain under ip6.int represents four bits of the 128-bit address, encoded as a hexadecimal digit just like in the record-specific data of the AAAA record. The least significant (lowest order) bits appear at the far left of the domain name. Unlike the format of addresses in AAAA records, omitting leading zeros is not allowed, so there are always 32 hexadecimal digits and 32 levels of subdomain below ip6.int in a domain name corresponding to a full IPv6 address. The domain name that corresponds to the address in the previous example is:

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int.

These domain names have PTR records attached, just as the domain names under in-addr.arpa do:

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int.  IN  PTR  mash.ip6.movie.edu.

10.16.2. A6, DNAMEs, Bitstring Labels, and ip6.arpa

That's the easy way. The more difficult -- and now official -- way of handling IPv6 forward and reverse mapping uses two new record types, A6 and DNAME records. A6 and DNAME records are described in RFCs 2874 and 2672, respectively. Version 9.0.0 is the first version of BIND to support these records.

The main reason the AAAA record and the ip6.int reverse-mapping scheme were replaced was because they made network renumbering difficult. For example, if an organization were to change Next-Level Aggregators, it would have to change all the AAAA records in its zone data files since 24 of the bits of an IPv6 address are an identifier for the NLA.[80] Or imagine an NLA changing TLAs: this would wreak havoc with its customers' zone data.

[80]And, of course, the new NLA might use a different TLA, which would mean 16 more bits to change . . .

10.16.2.1. A6 records and forward mapping

To make renumbering easier, A6 records can specify only a part of an IPv6 address, such as the last 64 bits (the interface ID) assigned to a host's network interface, and then refer to the remainder of the address by a symbolic domain name. This allows zone administrators to specify only the part of the address under their control. To build an entire address, a resolver or name server must follow the chain of A6 records from a host's domain name to the TLA ID. And that chain may branch if a site network is connected to multiple NLAs or if an NLA is connected to multiple TLAs.

For example, the A6 record:

$ORIGIN movie.edu.
drunkenmaster  IN   A6   64  ::0210:4bff:fe10:0d24  subnet1.v6.movie.edu.

specifies the final 64 bits of drunkenmaster.movie.edu's IPv6 address (64 is the number of bits of the prefix not specified in this A6 record) and that the remaining 64 bits can be found by looking up an A6 record at subnet1.v6.movie.edu.

subnet1.v6.movie.edu, in turn, specifies the last 16 bits of the 64-bit prefix (the SLA ID) that we didn't specify in drunkenmaster.movie.edu's A6 address as well as the domain name of the next A6 record to look up:

$ORIGIN v6.movie.edu.
subnet1  IN  A6  48  0:0:0:1::  movie-u.nla-a.net.
subnet1  IN  A6  48  0:0:0:1::  movie.nlab.net.

The first 48 bits of the prefix in subnet1.v6.movie.edu's record-specific data are set to zero, since they're not significant here.

In fact, these records tell us to look up two A6 records next, one at movie-u.nla-a.net and one at movie.nlab.net. That's because Movie U. has connections to two NLAs, NLA A and NLA B. In NLA A's zone, we'd find:

$ORIGIN nla-a.net.
movie-u  IN  A6   40  0:0:21::  nla-a.tla-1.net.

indicating the eight-bit Site ID pattern within the NLA IDfield set by NLA A for the Movie University network. You see, the NLA ID field is hierarchical, too, comprising both an identifier for our Next-Level Aggregator assigned to it by its TLA, and its identifier for our network. Since the NLA assigns our Site ID but has the rest of their NLA ID assigned by its TLA, we'd expect to see only our Site ID in our NLA's zone data. The remainder of its NLA ID would appear in an A6 record in its TLA's zone.

In NLA B's zone, we'd find the following record showing us their Site ID for our network:

$ORIGIN nlab.net.
movie  IN  A6  40  0:0:42::  nlab.tla-2.net.

In the TLAs' zones, we'd find:

$ORIGIN tla-1.net.
nla-a  IN  A6  16  0:10:2500::  tla-1.top-level-v6.net.

and:

$ORIGIN tla-2.net.
nlab   IN  A6  16  0:19:6600::  tla-2.top-level-v6.net.

Finally, in the top-level IPv6 address registry's zone, we'd find this record showing us the TLA IDs assigned to TLA 1 and TLA 2:

$ORIGIN top-level-v6.net.
tla-1  IN  A6  0  222::
tla-2  IN  A6  0  242::

By following this chain of A6 records, a name server can assemble all 128 bits of drunkenmaster.movie.edu's two IPv6 addresses. These turn out to be:

222:10:2521:1:210:4bff:fe10:d24
242:19:6642:1:210:4bff:fe10:d24

The first of these uses a route through TLA 1 and NLA A to the Movie U. network, and the second uses a route through TLA 2 and NLA B. (We're connected to two NLAs for redundancy.) Note that if TLA 1 changes its NLA assignment for NLA A, it only needs to change the A6 record for nla-a.tla-1.net in its zone data; the change "cascades" into all A6 chains that go through NLA A. This makes the management of addressing on IPv6 networks very convenient, and makes changing NLAs easy, too.

TIP: If a name server appears in an NS record and owns one or more A6 records, those A6 records should specify all 128 bits of the IPv6 address. This helps avoid deadlock problems, where a resolver or name server needs to talk to a remote name server to resolve part of that name server's IPv6 address.

10.16.2.2. DNAME records and reverse mapping

Now that you've seen how forward mapping works with A6 records, let's look at how reverse mapping IPv6 addresses works. As with A6 records, unfortunately, this isn't nearly as simple as ip6.int.

Reverse mapping IPv6 addresses involves DNAME records, described in RFC 2672, and bitstring labels, introduced in RFC 2673. DNAME records are a little like wildcard CNAME records. They're used to substitute one suffix of a domain name with another. For example, if we had previously used the domain name movieu.edu at Movie University but had since changed to movie.edu, we could have replaced the old movieu.edu zone with this one:

$TTL 1d
@    IN  SOA    terminator.movie.edu.  root.movie.edu. ( 
	2000102300
	3h
	30m
	30d
	1h  )

	IN   NS     terminator.movie.edu.
	IN   NS     wormhole.movie.edu.

	IN   MX     10 postmanrings2x.movie.edu.

	IN   DNAME  movie.edu.

The DNAME record in the movieu.edu zone applies to any domain name that ends in movieu.edu except movieu.edu itself. Unlike the CNAME record, the DNAME record can coexist with other record types owned by the same domain name as long as they aren't CNAME or other DNAME records. The owner of the DNAME record may not have any subdomains, though.

When the movieu.edu name server receives a query for any domain name that ends in movieu.edu, say cuckoosnest.movieu.edu, the DNAME record tells it to "synthesize" an alias from cuckoosnest.movieu.edu to cuckoosnest.movie.edu, replacing movieu.edu with movie.edu:

cuckoosnest.movieu.edu.  IN  CNAME  cuckoosnest.movie.edu.

It's a little like sed 's "s" (substitute) command. The movieu.edu name server replies with this CNAME record. If it's responding to a newer name server, it also sends the DNAME record in the response, and the recipient name server can then synthesize its own CNAME records from the cached DNAME.

Bitstring labels are the other half of the magic involved in IPv6 reverse mapping. Bitstring labels are simply a compact way of representing a long sequence of binary (i.e., one-bit) labels in a domain name. Say you wanted to permit delegation between any two bits of an IP address. That might compel you to represent each bit of the address as a label in a domain name. But that would require over 128 labels for a domain name that represented an IPv6 address! Oy!

Bitstring labels concatenate the bits in successive labels into a shorter hexadecimal, octal, binary or dotted-octet string. The string is encapsulated between the tokens "\[" and "]" to distinguish it from a traditional label, and begins with one letter that determines the base of the string: b for binary, o for octal, and x for hexadecimal.

Here are the bitstring labels that correspond to drunkenmaster.movie.edu's two IPv6 addresses:

\[x022200102521000102104bfffe100d24]
\[x024200196642000102104bfffe100d24]

Notice that the most significant bit begins the string, as in the text representation of an IPv6 address, but in the opposite order of the labels in the in-addr.arpa domain. Despite this, these two bitstring labels are simply a different encoding of traditional domain names that begin:

0.0.1.0.0.1.0.0.1.0.1.1.0.0.0.0.0.0.0.0.1.0.0.0.0.1.1.1.1.1.1.1...

Also note that all 32 hex digits in the address are present -- you can't drop leading zeros, because there are no colons to separate groups of four digits.

Bitstring labels can also represent parts of IPv6 addresses, in which case you need to specify the number of significant bits in the string, separated from the string by a slash. So TLA 1's TLA ID is \[x0222/16].

Together, DNAMEs and bitstring labels are used to match portions of a long domain name that encodes an IPv6 address and to iteratively change the domain name looked up to a domain name in a zone under the control of the organization that manages the host with that IPv6 address.

Imagine we're reverse mapping \[x024200196642000102104bfffe100d24].ip6.arpa, the domain name that corresponds to drunkenmaster.movie.edu's network interface (when reached through TLA 2 and NLA B). The root name servers would probably refer our name server to the ip6.arpa name servers, which contain these records:

$ORIGIN ip6.arpa.
\[x0222/16]    IN     DNAME      ip6.tla-1.net.
\[x0242/16]    IN     DNAME      ip6.tla-2.net.

The first of these matches the beginning of the domain name we're looking up, so the ip6.arpa name servers reply to our name server with an alias that says:

\[x024200196642000102104bfffe100d24].ip6.arpa.  IN  CNAME  
\[x00196642000102104bfffe100d24].ip6.tla-2.net.

Notice that the first four hex digits (the most significant 16 bits) of the address are stripped off, and the end of the target of the alias is now ip6.tla-2.net, since we know this address belongs to TLA 2. In ip6.tla-2.net, we find:

$ORIGIN ip6.tla-2.net.
\[x00196600/24]   IN   DNAME     ip6.nlab.net.

This turns the domain name in our new query:

\[x00196642000102104bfffe100d24].ip6.tla-2.net

into:

\[x42000102104bfffe100d24].ip6.nlab.net

Next, our name server queries the ip6.nlab.net name servers for the new domain name. This record in the ip6.nlab.net zone:

$ORIGIN ip6.nlab.net.
\[x0042/8]    IN   DNAME    ip6.movie.edu.

turns the domain name we're looking up into:

\[x000102104bfffe100d24].ip6.movie.edu

The ip6.movie.edu zone, finally, contains the PTR record that gives us the domain name of the host we're after:

$ORIGIN ip6.movie.edu.
\[x000102104bfffe100d24/80]  IN   PTR   drunkenmaster.ip6.movie.edu.

Mercifully, as a zone administrator you'll probably only be responsible for maintaining PTR records like the ones in ip6.movie.edu. Even if you work for a Top-Level or Next-Level Aggregator, creating DNAME records that "extract" the appropriate NLA ID or Site ID from your customers' addresses isn't too tough. And you gain the convenience of using a single zone data file for your reverse-mapping information, even though each of your hosts has multiple addresses, and of being able to switch NLAs without changing all of your zone data files.