With so much information on IPv6 focusing on connectivity, it’s sometimes important to remember that deploying IPv6 for actual use requires changes to the Domain Name System(DNS) as well. DNS has become even more important for IPv6 than it was for IPv4 due to the length of IPv6 addresses and difficulty in remembering them. This post is going to focus on those changes to DNS that accompany IPv6 deployments. If you’re an operator, website owner or content creator these are the things you need to understand about DNS to ensure your IPv6 deployment is sucessful.
A good place to start understanding the operational considerations of DNS in IPv6 deployments is RFC 4472, entitled “Operational Considerations and Issues with IPv6 DNS”. RFC 4472 provides a good high level overview of common DNS considerations for IPv6 deployments.
Software
The Internet Systems Consortium(ISC)s Berkeley Internet Name Domain(BIND) is by far the most popular DNS software in use. Usually just referred to as BIND, it is available for almost every operating system. Starting with the release of BIND 9 in 2000, IPv6 support is built-in.
Here is a good tutorial for configuring BIND 9 for IPv6 support on Debian Linux. Even if you’re not using Linux it’s useful for its comprehensive treatment of DNS and IPv6.
Another tutorial from Penn State provides a more high level overview of what’s required for IPv6 in DNS.
DNS Records
IPv4 uses ‘A’ records to store IP addresses where IPv6 uses ‘AAAA’ records to store IPv6 addresses. ‘AAAA’ records, or quad-A records as they’re sometimes called, are functionally equivalent to ‘A’ records and are written in the same basic way. Reverse DNS records for IPv6 use PTR records just like in IPv4, but the trailing domain ‘in-addr.arpa’ for IPv4 has been changed to ‘ip6.arpa’ for IPv6. For PTR records the IPv6 address is still written in reverse nibble format just like in IPv4, only this time it’s much longer.
Matthew Roy has written a simple tool to help administrators create BIND file entries for IPv6. It can help you create ‘A’ records, ‘PTR’ records, and also entire zone entry files.
DDNS with DHCP and IPv6
Dynamic DNS(DDNS) is a means of updating DNS with information from a Dynamic Host Configuration Protocol(DHCP) server. After the DHCP server assigns an IP address it communicates the assignment to the DNS server. This mechanism is called DDNS, and it’s described in RFC 2136. DDNS also exists for IPv6 with very little difference.
Dhcpy6d, a DHCPv6 server written in Python, stores its leases in MySQL for easy interfacing with BIND 9.
dhcpcd and ISC DHCPv6 are two other DHCP servers which can support DDNS.
Zytrax has written an indepth tutorial on how to get DHCPv6 working with DDNS. It explains DDNS and how to configure ISC DHCPv6 in combination with ISC BIND.
DNS considerations for IPv6 SLAAC
IPv4 has two ways for clients to receive IP addresses; static configuration and DHCP. IPv6 has both those methods and an additional method called Stateless Address Autoconfiguration(SLAAC). SLAAC allows IPv6 end-nodes to choose their own addresses and is defined in RFC 4862. This concerns DNS because when clients create their own IPv6 addresses via SLAAC DNS still needs to have reverse DNS records for these addresses. However, how can a DNS server respond to queries about addresses it knows nothing about?
RFC 4472 recommends a few options for solving this problem. One option is to configure wildcard records for the entire range of IPv6 clients using SLAAC. This causes the DNS resolver to generate PTR records dynamically as reverse DNS queries arrive.
The AllKnowingDNS server was written for this purpose. IPv6 subnets configured for SLAAC can be configured with wildcard entries and AllKnowingDNS will respond to PTR queries for those addresses.
As of this writing BIND 9 does not support wildcard entries in PTR records. If you know of an interesting solution to the problem of populating DNS PTR records in IPv6 SLAAC environments please let me know by posting in the comments section.
When using IPv6 SLAAC it is a good idea to configure Router Advertisements(RAs) to include the option for DNS configuration as described in RFC 6106. RFC 6106 defines a mechanism for distributing DNS configuration information in RAs.
Client Behavior
Just because a server has an IPv6 address and a ‘AAAA’ record does not mean it will always use it. Clients must request an ‘AAAA’ record in order to use IPv6. Also, sometimes clients can experience faster IPv4 connectivity than IPv6. RFC 6555, entitled “Happy Eyeballs: Success with Dual-Stack Hosts” addresses these problems by suggesting client behavior which aims to maximize the user experience. The basic premise is to open connections over both IPv4 and IPv6, then use which ever is faster.
DNSSEC
Once you have DNS configured for IPv6, we would also of course suggest that you proceed on to secure DNS with DNSSEC!
If you would like to get started with IPv6, please visit our IPv6 resources or begin with our “Start Here” page to help find resources most appropriate for your type of organization. If you have an IPv6 case study you think we should consider for inclusion on our site, please contact us – we are always looking for more!