Let’s talk about IPv6 DNS64 & DNSSEC

While some people still cannot see any reason to deploy IPv6 – ignoring IPv6 adoption of 10% – others have gone as far as deploying IPv6-only networks, removing all dependencies on IPv4 address space in their networks. How can they do this? How can IPv6-only hosts access IPv4-only parts of the Internet?

One possible way is to use NAT64 (RFC 6146) in conjunction with DNS64 (RFC 6147). Let’s look at a simplified example of how it works.

Let’s talk about IPv6

Alice connected her laptop to an IPv6-only network and now she’d like to open a connection to a server www.example.net, which is IPv4-only (if www.example.net has an IPv6 address, there is no problem to solve as Alice will reach the server over IPv6). Alice’s laptop got configured with an IPv6 address (e.g. 2001:db8::2) and a special DNS server, which supports DNS extensions called DNS64. Then:

1. Alice’s machine sends a DNS request to the DNS64 server asking for the AAAA resource record for www.example.net.
2. The DNS64 server performs the standard DNS procedure for obtaining the AAAA DNS Resource Record (RR) from an authoritative NS (e.g. ‘.net’). If www.example.net is an IPv4-only site and has an A RR only, then the DNS64 server synthesizes a response to a AAAA Query using a special NAT64/96 prefix (well-known prefix 64:ff9b::/96 or any other 96 prefix allocated by a network administrator) and combines it with an IPv4 address obtained from the A RR. So, if www.example.net IPv4 address is 192.0.2.10 and the well-known prefix 64:ff9b::/96 is used for NAT64, then DNS64 returns to the host X a synthesized AAAA record 64:ff9b::192.0.2.10.
3. Then, Alice’s laptop sends a packet from its IPv6 address (2001:db8::2) to the IPv6 address of www.example.net (64:ff9b::192.0.2.10). The trick is that the NAT64/96 prefix (64:ff9b::/96 in our case) is routed to a network device that performs network address and protocol translation between IPv6 and IPv4 (the same way NAT44 performed in many networks, translating a client’s private IP4 addresses into public IPv4 addresses from the NAT pool).
4. The NAT64 device translates the IPv6 packet into an IPv4 packet by translating the source IPv6 address 2001:db8::2 and source port X to a public IPv4 address from the NAT64 pool (e.g. 198.51.100.2) and a port Y (the corresponding mapping entry is created) and extracting the destination IPv4 address (192.0.2.10) directly from the destination IPv6 address 64:ff9b::192.0.2.10 by stripping the /96 prefix.
5. The response from www.example.net, coming over IPv4 to the NAT64 device, will be translated using the same logic and sent to Alice’s laptop over IPv6.

It all looks great and generally works quite well. However, there is one very important thing about NAT64/DNS64 – the DNS64 server is lying to its clients returning AAAA RRs even if no such RRs exist. Well, one might call it ‘pious fraud’, but it is still a lie.

Is it a problem? It might be, as there has been some work done to improve the security of the DNS in general, and ensure integrity and validity of DNS information, called DNSSEC.

Let’s talk about DNSSEC

DNSSEC is quite a complicated set of DNS extensions allowing data origin authentication of DNS responses. In other words, the client can:

• Verify that the DNS response has not been modified
• Authenticate the source of the message, and more importantly, in our case
• Verify the denial of existence

In the context of DNSSEC, a resolver can be “security-aware”, which means it is able to accept DNSSEC RRs in case the server returns it. Security-aware resolvers may be non-validating (not using DNSSEC RRs to validate the information provided) or validating (actually using DNSSEC RRs to verify the authenticity of the DNS replies). The resolver indicates its ability to accept DNSSEC information and its intention to validate data by setting specific bits in DNS requests (DO, “DNSSEC OK” for security-aware resolvers and CD, “Checking Disabled” bit for validating resolvers).

Currently, it looks like most of the DNSSEC validation happens on recursive DNS servers, while validating stub resolvers (such as resolvers on end hosts etc) are not so common. However, DNSSEC brings the most benefit when the validation happens on end hosts, ensuring that DNS information passed to applications is verified.

So the question is what happens if a validating stub resolver is connected to a NAT64 network and uses DNS64 as its recursive DNS server?

Let’s talk about IPv6-only and DNSSEC

Oh, East is East, and West is West, and never the twain shall meet.
Rudyard Kipling

Now let’s put two and two together and look at the situation when Alice’s laptop is running validating stub resolvers and is connected to a NAT64/DNS64 network.

If a client resolver running on Alice’s laptop is capable of performing DNSSEC validation, it can easily detect that the DNS64 server lies (remember that DNSSEC allows us to prove that a particular RR does not exist) and might discard that information as invalid. As per the DNS64 standard (RFC 6147) the security-aware DNS64 server might not return synthesized AAAA RRs to security-aware or validating resolvers. As such, two scenarios are possible:

1. Alice’s laptop resolver is security-aware but non-validating. In this case, the DNS64 server returns synthesized AAAA RRs if there is no DNSSEC information available to prove its non-existence. If such information exists (in the form of NSEC/NSEC3 DNSSEC RRs), the DNS64 server behaviour is implementation-dependant and it might or might not synthesize AAAA.
2. Alice’s laptop resolver is validating: no AAAA is returned by the DNS64 server, so IPv4-only destinations would not be reachable from Alice’s machine.

What is particularly interesting here is that the DNS64 specification is not very clear about if the second scenario applies to a case when non-existence of AAAA RRs cannot be validated. Therefore, depending on the particular implementation, a validating resolver would not receive the synthesized AAAA RRs from DNS64 either for DNSSEC-enabled, IPv4-only names or for any IPv4-only names (the problem scope is illustrated in Figure 2).

There is a big difference between “failing for IPv4-only, DNSSEC-enabled names” and “all IPv4-only names”, and arguments could be made to support both options. On the one hand, not performing synthesis for signed zones only decreases the failure domain significantly. On the other hand, such behavior means that enabling DNSSEC for IPv4-only names might break access to those names from IPv6-only networks and therefore create a significant disincentive for DNSSEC adoption.

But wait, what is the DNSSEC adoption rate anyway?

How many angels can dance on the head of a pin?

We have discussed the theory and standards but what about real-world data? How many complaints should NOC expect if a network is converted from dual-stack to IPv6-only? How many sites can users not reach? Let’s introduce some metrics and look at DNSSEC and IPv6 adoption together.

Actually, there is something in common between these two technologies: they have been around for a while but we still cannot finish the deployment. Maybe it is because people adopting IPv6 are also adopting DNSSEC? Or is it because people interested in IPv6 are not interested in DNSSEC at all?

The easiest way to look at the adoption of a new protocol is to look at the Alexa 1M websites list; so I did exactly that. The results I got suggest that DNSSEC seems to be even harder to deploy than IPv6. Out of 1,000,000 names:

• 56610 (5.7%) have AAAA RR
• 16788 (1.7%) have DNSSEC enabled (signed AAAA or A RR)
• 13324 are IPv4-only (have A RR only)
• 3436 have signed AAAA RR

If we compare IPv6 adoption with DNSSEC adoption among Alexa 1M websites:

IPv6 adoption

• 5.7% of all Alexa 1M websites
• 21% of DNSSEC-enabled Alexa 1M websites

DNSSEC adoption

• 1.7% of all Alexa 1M websites
• 6% of IPv6-enabled Alexa 1M websites

Taking into account the DNS64 implementation details I mentioned earlier, it looks like that for a validating stub resolver placed in a NAT64 network behind a DNS64 recursive server, the failure rate will be at least 1.3% (13324 IPv4-only DNSSEC enabled names) but for some DNS64 implementation the failure rate might be up to 94% (943390 IPv4-only names).

Moral of the story

The main conclusion is quite clear: if you deploy IPv6 for your website all those issues with validating resolvers immediately disappear.

However, I’d like to go further and point out that enabling IPv6 for a site allows the site owner to get the most DNSSEC benefit – validating end clients, not just recursive servers. One more reason to deploy IPV6, isn’t it?

P.S. One more thing to remember: there is no guarantee that the DNS server used by a host/stub resolver is not a DNS64 server. IPv6-only networks are already here, they are just not very evenly distributed. Therefore validating resolvers should be aware of it and perform DNS64 functions if needed, as there is a way to discover a NAT64 prefix used in the network as described in RFC 7050.

Jen Linkova is a Network Engineer at Google and Co-Chair of the RIPE IPv6 Working Group.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.