Let’s talk about IPv6 DNS64 & DNSSEC

By on 9 Jun 2016

Category: Tech matters

Tags: , , , ,

12 Comments

Blog home

Jen Linkova at RIPE 72. Image Credit: RIPE NCC
Jen Linkova at RIPE 72. Image Credit: RIPE NCC

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.
DNS64

Fig. 1 NAT64/DNS64 in Action

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).

DNSSEC clients and zones-all

Fig. 2 Problem space for Validating Stub Resolvers in NAT64/DNS64 networks

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).

DNSSEC-V6(3)

Figure 3. 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.

12 Comments

  1. 22decembre

    One other thing interesting could be to intently use 64:ff9b::/96 addresses along with ipv4.

    That way, ipv6 client with dnssec enabled and nat64 can reach the ipv4 only host.

    It is obviously bad solution and lazyness, but not only, as some internet still refuse to serve ipv6. So the host (server) may not be able to deploy/serve on ipv6.

    Reply
    1. Jen Linkova

      22decembre: Are you suggesting that Ipv4-only sites public AAAA from 64:ff9b::/96 in addition to their A? It would cause issues for IPv6-enabled clients which are not behind NAT64 – they will try to use that AAAA first. Happy Eyeballs would help a bit indeed, but…

      Reply
        1. 22decembre

          No guarantee, except usage. Which is quite something, we all know that.

          I think organisations using something else than the common 64:ff9b::/96 just want to fuck up.

          Reply
          1. Jen Linkova

            Organizations using something else than the common 64:ff9b::/96 might just want to use NAT64 for internal access to RFC1918 address space.

  2. Geoff Huston

    Your section on “How many angels can dance on the head of a pin?” which appears to argue that this form of DNS lying (the synthetic AAAA record) will not be seen as invalid by many clients seems to argue that nobody uses DNSSEC validation because few sites have signed names. But these are unrelated concepts – if you want to know how many clients would be affected by synthetic records in the DNS then you need to look at the extent to which clients use DNSSEC validation. Luckily thats a question we have an answer for (http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=1&g=0) and the answer is that IF the domain is DNSSEC signed then 15% of users will be unable to resolve the name. This is too big a number to ignore, and the corollary is that transitional mechanisms that rely on protocol translation and tricks (lies) in the DNS have passed their Use By date.

    What does that mean? Simple. If you want V6, then deploy V6!

    Reply
    1. Tore Anderson

      Geoff, but do you know exactly where is the validation is performed for those 15%? If it’s in the ISP’s resolvers, it’s probably not a problem because that’s where you’d do the DNS64 synthesis too. Validating resolvers in hosts (or CPEs) would on the other hand be problematic, but how common are those?

      Reply
    2. 22decembre

      There are also cases where ipv6 deployment is not your job. You don’t have the keys. It is someone else’s job and they don’t see the point of doing it now.

      Reply
  3. Jan Schermer

    Why not just leave the DNSSEC-enabled reply as-is, and let the client translate the IPv4 address into IPv6 space?

    1. client asks for http://www.example.com (AAAA)
    2. dns resolver sees no AAAA record (and can forward this to the client, including a validated “doesn’t exist” reply)
    3. client asks for A record
    4. dns resolver forwards a validated A reply pointing to 1.1.1.1
    5. client is happy with the DNS reply
    6. client connects to 64:ff9b::101:101

    Am I missing something?

    Reply
    1. Jan Schermer

      Btw this solves the problem of non-DNS64 enabled client not reaching sites (as was suggested above) – the client knows (or can know) that it has no IPv4 route to the host, so it can try connecting via IPv6 64:ff9b:…

      If it works – good.
      If it doesn’t work – nothing broke that wasn’t broken already, there’s obviously no way to contact the site.

      Reply
  4. Kasper D

    The steps you describe is roughly what eventually made it into RFC 8305. It can work in principle, but it’s still not widely implemented.

    It does have one major drawback. It requires the client to learn the NAT64 prefix some other way. And this will break if the DNS64 server is configured to use different NAT64 prefixes for different hosts.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Top