Child pages
  • IPv6 DNS
Skip to end of metadata
Go to start of metadata


IPv6 addresses are represented in DNS using AAAA records (called "quad-A records"). Reverse DNS is rooted in the tree. See RFC 3596 for additional information. Most modern DNS software supports AAAA records. Supported software includes BIND 9, Windows 2003's DNS server, and the stub resolvers on Windows XP, Mac OS X, Linux, AIX and Solaris.

Nameservers providing AAAA and records do not need to listen on IPv6, but doing so is recommended. The IETF recommends against running IPv6-only DNS servers. Instead they recommend that nameservers be accessible over both IPv4 and IPv6.

Not all IPv6-enabled operating systems can transmit IPv6-related queries over IPv6. For example, Windows XP can only perform DNS queries over IPv4, but it can query for AAAA and records.

IPv6-enabled clients will use IPv6 in preference to IPv4. If a client finds both AAAA and A records for a hostname, it will attempt to connect via IPv6 first. If a service is advertised in the DNS with a AAAA record, but is not listening on IPv6, clients will experience delays as their IPv6 connection attempts must timeout. For this reason, administrators should ensure that their IPv6 transport, routing, security and monitoring systems are in place before adding AAAA records to the DNS.


"Can a machine have both a v4 and a v6 name in DNS?"

Yes. A machine can have multiple A (IPv4) and AAAA (IPv6) records in DNS. An IPv4-only client will only try to connect over IPv4. An IPv6-enabled client will first try to connect over IPv6. If that connection fails, it will fall back to IPv4 (if IPv4 is available).

No. The IETF forbids this in RFC 4472, section 2.1.

Example configuration

Getting BIND to listen on IPv6

In named.conf make the following changes:

options { 
    listen-on { any; }; 
    listen-on-v6 { any; }; // add this line to make named listen on IPv6
controls { 
    inet port 953 allow { any; } 
        keys { "rndc-key"; }; 
    inet ::1 port 953 allow { any; } // add these lines
        keys { "rndc-key"; };        // if you use rndc

Please do not make your DNS server listen only on IPv6. It should listen on both IPv4 and IPv6, according to IETF recommendations (RFC 3901).

Forward DNS

Just add the AAAA records to your existing forward zone files:

$TTL 6h
@	IN	SOA (
			2008080200	; serial
			1h		; refresh
			30m		; retry
			14d		; expiration
			1h )		; minimum
		MX			10
www		A
		AAAA			2610:8:6800:1::7

Reverse DNS

First, define the new reverse zone in named.conf. For example, if TNS assigned 2610:8:6800:1::/64 to you, your reverse zone is So you would add the following zone:

 zone "" { 
  type master; 
  file "2610:8:6800:1"; 

Next, define a new zone file:

$TTL 6h
@	IN	SOA (
				2008080500	; serial
				1h		; refresh
				30m		; retry
				14d		; expiration
				1h )		; minimum

In this example, we've added the reverse entry to 2610:8:6800:1::7, which we used above for

Miscellaneous Issues

Extra load on DNS servers

IPv6-enabled clients will send queries for AAAA records for every hostname they need to resolve. This may cause additional latency and place additional load on recursive nameservers. During the transition to an IPv6-dominant Internet, many hosts will not have AAAA records. It is therefore vital that recursive nameservers implement negative caching (RFC 2308) to cache the non-existance of these records.

Increased message size

DNS usually runs over UDP. The DNS standard (RFC 1035) normally limits UDP replies to 512 bytes. In most cases, this limit does not post a problem for IPv6. In some cases, however, it may not be possible to fit sufficient AAAA records into a reply, as IPv6 addresses are significantly larger than IPv4 addresses (128 bits -vs- 32 bits).

There are two solutions to this problem. One is to use TCP, which allows much larger messages. The other is EDNS-0 (RFC 2671), a DNS extension which allows larger UDP messages. Firewall administrators should ensure that their equipment passes one or both of these mechanisms. ICANN has a document on vendor support for these features.

The IETF has documented issues with DNS response sizes in this draft RFC.

Bugs in early IPv6 implementations

Many early implementations of IPv6-enabled resolvers were buggy. The most common of these bugs are documented in RFC 4074, RFC 4472, section 3 and RFC 4697. Administrators should ensure that their resolvers are not susceptible to these issues.


Relevant RFCs

RFC 3901 - DNS IPv6 Transport Operational Guidelines

RFC 4339 - IPv6 Host Configuration of DNS Server Information Approaches

RFC 4472 - Operational Considerations and Issues with IPv6 DNS