This document assumes you already understand IPv4 DNS configuration. This page will discuss implementation of BIND9 and IPv6 for Domain Name Resolution. If you'd like to contribute, please let me know, and we'll get you an account. I only use BIND, but I'm sure others use the other options out there.
Forward DNS resolution with IPv6 isn't any different from IPv4, apart from the record type in your zone configuration file. We aren't going to discuss full DNS configuration, as we're assuming understanding of the BIND9 configuration of at least IPv4 forward resolution.
To create an IPv6 forward resolution record, use record type AAAA. If you've been browsing around the internet, you've probably seen mention of A6 records. These have been deprecated in favor of a standard of AAAA records.
Here is the IPv6 record for www.secure-computing.net:
www IN AAAA 2001:4980:1:111::150
It's really as simple as that!
Reverse DNS resolution is a little different animal from IPv4. There's a new provision for delegation of reverse DNS, due to the HUGE number of IP addresses a single network is allocated. 18,446,744,073,709,551,615 IP addresses huge. I'm not sure about your needs, but that's more than I'm, personally, going to need. To put that in perspective, that is 18 quitrillion, 446 quadrillion, 774 trillion, 73 billion, 709 million, 551 thousand, 615 IP addresses. That, for one single network, is actually enough IPs for every person in the world to have 2,837,960,626. Hrm, two BILLION addresses each. That's a lot. For the record, a /64 in IPv6 is the smallest allocation of IP addresses per the protocol. That's quite a few for your ISP to worry about if you want proper reverse DNS.
All of that being said, your ISP is probably more than willing to delegate reverse DNS to your servers. IPv6 delegates based on nibbles. Without getting into too much detail, let's break it down a bit.
Brief IP Explanation
With reverse DNS, IPs are written in reverse order, so 184.108.40.206 is 220.127.116.11.in-addr.arpa. In this case, things are broken up by the octet, or by each . in the address. With IPv6, things are broken up into each byte. This means an IP address of 2001:4980:1:111::150 is expanded and written out as: 0.5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.18.104.22.168.22.214.171.124.0.8.9.4.126.96.36.199. There's a distinct difference here, between version 4 and version 6. With version 4, you can only delegate reverse DNS by the class C block, and it's delegated by ARIN (or whomever your local authority is). With IPv6, I can delegate a single IP's reverse DNS. AKA nibble. :)
We're going to build the secure-computing.net reverse DNS file, and I'll do my best to explain as we go.
First, you need to put all the file header information that exists in an IPv4 file, such as ORIGIN, TTL, and other timeouts. The $ORIGIN portion should be the part of your IPv6 block that describes your network. If you've been assigned a /64, it will be the first 16 numbers, expanded, of your entire IPv6 address. Secure Computing Networks has been assigned 2001:4980:1:0111/64, so our $ORIGIN will be 188.8.131.52.184.108.40.206.0.8.9.4.220.127.116.11.ip6.arpa. Note that .ip6.arpa is appended to the end of all IPv6 reverse IPs:
$ORIGIN 18.104.22.168.22.214.171.124.0.8.9.4.126.96.36.199.ip6.arpa. $TTL 86400 @ IN SOA pri-ns.secure-computing.net. domain-services.secure-computing.net. ( 2007070501 ; Serial 3600 ; Refresh 3600 ; Retry 1209600 ; Expire 7200 ) ; Minimum TTL
Next, I add a few comments so that, as I'm typing, I can remember my IP block and $ORIGIN:
; 2001:4980:1:111::/64 ; 188.8.131.52.184.108.40.206.0.8.9.4.220.127.116.11.ip6.arpa.
At this point, we can start adding our static reverse definitions. These should be in the same nibble format we've already been discussing. Similar to IPv4, you'll use the PTR record type, followed by your host name. REMEMBER to add the trailing period to the end of your host name, or it WILL NOT work!
To construct your record, you need to put, in reverse order, the remaining digits of your version 6 address. Using our example for www.secure-computing.net of 2001:4980:1:111::150, we reverse that into nibbles as:
To make things easier, we simply remove the ORIGIN portion of that address, giving us:
Our records, then, will appear as so:
... 18.104.22.168.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR core.ip6.secure-computing.net. 22.214.171.124.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ghost.ip6.secure-computing.net. 126.96.36.199.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR gimp.ip6.secure-computing.net. 188.8.131.52.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR chunk.ip6.secure-computing.net. 184.108.40.206.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR snort.ip6.secure-computing.net. ...
- Note: The ... lines above simply indicate that there are more records before, and more records after. This is simply an excerpt from our configuration file to give you an idea as to your format.
- At this point, you should be able to save, restart your BIND9 server, and, provided reverse DNS has been delegated to your servers, resolve your reverse DNS.
There is much more to learn about reverse DNS
, such as $GENERATE records, but I don't even know how to do that, yet. As it turns out, BIND $GENERATE statements don't work very well with IPv6. Basically, delegation is key, and you only have reverse lookup for systems that you care about having reverse lookup for.
A email from someone I'd consider knowledgeable:
On Thu, Sep 20, 2007 at 08:10:30PM -0500, Eric F Crist wrote: >With my reverse DNS for my IPv6 block, you mentioned that I could use >the ISC BIND $GENERATE statement. Can you give me a brief example? >There is zero documentation relative to IPv6 available. Kind of >surprising. I probably misspoke that time then. $GENERATE isn't too useful for IPv6. It does a very simple variable/text substitution, it has no provisions in it to generate the numbers involved in IPv6 IP addresses. -- Doug McIntyre <email@example.com> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades