Documentation > Basic Tutorials > DNS64

DNS64 Tutorial


  1. Introduction
  2. Network
  3. Configuration
    1. BIND
    2. Everything else
  4. Outcome


This document focuses on DNS64, the last key to have a fully-sensical NAT64 installation.

Any correct DNS64 implementation is supposed to work; BIND will be used for illustration here. I expect you to be already familiarized with DNS and have at least an idea of what BIND’s configuration looks like.


Fig.1 - Setup

Though Jool and the DNS64 are portrayed as separate nodes, there’s nothing (aside from port collision) preventing you from joining them in a single machine.



First, I will clarify what we want to achieve. is a domain that is available from both the IPv4 and the IPv6 internets, and hence it has both kinds of records:

$ dig A

$ dig AAAA
;; ANSWER SECTION:		86040	IN	AAAA	2606:2800:220:6d:26bf:1447:1097:aa7
(...) is an example of a domain available only from IPv4:

$ dig A

$ dig AAAA
;; AUTHORITY SECTION:	240	IN	SOA 2013070801 3600 900 604800 1800

There’s no need for an IPv6 node to access via the NAT64. On the other hand, cannot be accessed from IPv6 without one.

In other words, we want the DNS64 service to return 2606:2800:220:6d:26bf:1447:1097:aa7 when asked for the AAAA record of (which is what it normally does), and 64:ff9b:: (i.e. the NAT64 prefix plus the IPv4 address) when asked for the AAAA record of (which is the whole NAT64 hack).

First, have a working BIND server. On Ubuntu, the only thing you have to do (assuming you don’t already have one) is run

user@B:~# apt-get install bind9

The most basic configuration is very minimalistic. In order to turn on DNS64, the options section from the named.conf file (in my case, /etc/bind/named.conf.options) is the only one in which statements must be updated:

options {

	# Listening on IPv6 is off by default.
	listen-on-v6 { any; };

	# This is the key. Note that you can write multiple of these if you need
	# more IPv6 prefixes.
	# "64:ff9b::/96" has to be the same as Jool's `pool6`.
	dns64 64:ff9b::/96 {
		# Options per prefix (if you need them) here.
		# More info here:

And remember to reload.

user@B:~# service bind9 restart

That’s it!

Everything else

The outermost networks changed, and that should probably be reflected in everyone’s routing tables:

user@J:~# /sbin/ip -6 route del 2001:db8:1::/64
user@J:~# /sbin/ip -6 route add default via 2001:db8:2::1 dev eth0

(Similar instructions should be echoed in the routers and the nodes)

Jool and J don’t need to be aware of the DNS64 because domain names are completely transparent to NAT64, so you don’t need to do anything else in J.

As for the leaf nodes, any IPv6 node which needs to access IPv4-only content should use the DNS64 as its default name server (unless you want to specify it manually in your dig commands, I guess).


From one of those IPv6 nodes:

$ dig AAAA
;; ANSWER SECTION:		86040	IN	AAAA	2606:2800:220:6d:26bf:1447:1097:aa7

$ dig AAAA
;; AUTHORITY SECTION:	86040	IN	AAAA	64:ff9b::c85e:b624

If you sniff the traffic, you should see packets towards on R, and packets towards via S:

Fig.2 - Arrows

Happy ending!