[ Pobierz całość w formacie PDF ]
26 | Chapter 3: Resolver Configuration
CHAPTER 4
DNS64
During the (likely very long) transition from IPv4 to IPv6, ISPs and other organizations
will implement new networks that only support IPv6. For the foreseeable future,
though, clients on those networks will still need access to services (e.g., websites) that
don t yet support IPv6. NAT64 and DNS64* are a pair of complementary transition
technologies that help provide that access.
NAT64 is a function run on a dual-stack host. A NAT64 server accepts connections
from clients that only speak IPv6 and then uses its own IPv4 connectivity to commu-
nicate with IPv4-only servers on those clients behalf, then copies data between the IPv4
and IPv6 connections, effectively bridging the IPv4 and IPv6 networks. The clients
don t actually realize they re connecting through NAT64 they re led to believe that
the IPv4-only servers they want to communicate with support IPv6 and that they re
talking directly to them.
How is that misdirection achieved? Through DNS DNS64, in particular. The IPv6-
only clients are configured to use one or more special name servers that support the
DNS64 function. When one of these name servers receives a query from a client for
AAAA (IPv6 address) records for some domain name, it looks for an answer, as it
normally would. If it doesn t find any such records, it tries looking up A records for the
same domain name. If it finds one or more A records, it doesn t return them to the
client (which can t use them, anyway, and wouldn t accept them, since it asked spe-
cifically for AAAA records). It synthesizes an equal number of AAAA records from
those A records, embedding the 32-bit IPv4 addresses in 128-bit IPv6 addresses. Now
the client believes the server supports IPv6 and that it can communicate with it directly.
The client, then, tries to connect to one of these fictional er, synthesized IPv6 ad-
dresses. How does the NAT64 server intercept this traffic? Easy! The route to the net-
work on which the synthesized IPv6 address lies leads right to the NAT64 server. The
NAT64 server terminates the IPv6 connection, extracts the embedded IPv4 address,
* NAT64 and DNS64 are pronounced as NAT six four and DNS six four, respectively not NAT sixty-
four and DNS sixty-four.
27
and connects to the IPv4 server on the IPv6 client s behalf. This process is illustrated
in Figure 4-1.
Figure 4-1. DNS64 and NAT64 at Work
BIND versions 9.8.0 and later support DNS64 with the dns64 options substatement.
dns64 supports the configuration of an IPv6 prefix to which the embedded IPv4 address
is appended, as well as an optional suffix that is then appended to the IPv4 address to
complete the 128-bit address. (The prefix is often 96 bits long, in which case no suffix
is required, or even possible.) Here s a basic example:
dns64 64:ff9b::/96 {
suffix ::;
};
::, an all-zeroes suffix, is the default, so you can leave that substatement out if you like.
Now, there are good reasons that you may not want to apply DNS64 to every querier.
For instance, you may have a community of dual-stack clients on your network. When
asked by an application to find the address of a server, many stub resolvers on dual-
stack clients will send AAAA queries before they send A queries. With DNS64 enabled,
such clients would never see the A records of IPv4-only servers; DNS64 would always
return synthesized AAAA records to them, even though the clients were perfectly
28 | Chapter 4: DNS64
capable of using the servers A records. This, in turn, would shunt traffic through your
NAT64 infrastructure unnecessarily.
The dns64 statement supports a clients substatement that allows you to select which
clients the DNS64 function applies to. By default, DNS64 applies to all clients; that is:
dns64 64:ff9b::/96 {
clients { any; };
};
But you can specify any ACL you like as an argument. Here s an example:
dns64 64:ff9b::/96 {
clients { 2001:db8:cafe:1::/64; };
};
As always, it s a good idea to use named ACLs whenever possible for clarity.
There are also IPv4 networks that you may not want mapped into IPv6 addresses by
DNS64. For example, if you run a DNS64 function to give your IPv6-only clients access
to the IPv4 Internet, you don t want to embed any RFC 1918 addresses that name
servers on the Internet might inadvertently return. To avoid that, use the dns64 map-
ped substatement. This dns64 statement would prevent DNS64 from mapping 10/8
addresses, for example:
dns64 64:ff9b://96 {
mapped { !10/8; any; };
};
Of course, RFC 1918 includes more than just 10/8.
You may notice that I use the prefix 64:ff9b:://96 liberally in my DNS64
examples. That s because that network is reserved for mapping IPv4
[ Pobierz całość w formacie PDF ]