Last week we visited the RIPE 66 conference in Dublin where Bert Hubert presented on “how to make an application fully IPv6 compliant”. After the presentation, Terry Froy from Spilsby Internet Solutions approached us about his experiences with PowerDNS and DNS64.
DNS64 is a trick to provide IPv4 services on IPv6 only networks. Quoting from our documentation:
DNS64 is a technology to allow IPv6-only clients to receive special IPv6 addresses that are proxied to IPv4 addresses. This proxy service is then called NAT64.
So, as an example, let’s say an IPv6 only client would want to connect to http://www.example.com, it would request the AAAA records for that name. However, if example.com does not actually have an IPv6 address, what we do is ‘fake up’ an IPv6 address. We do this by retrieving the A records for http://www.example.com, and translating them to AAAA records.
Elsewhere, a NAT64 device listens on these IPv6 addresses, and extracts the IPv4 address from each packet, and proxies it on.
And it turns out that this works pretty well. It also turned out that while PowerDNS has had support for DNS64 for years now, we never actually properly documented how, so while at RIPE, we rectified this.
Setting up DNS64 in PowerDNS is highly flexible, and a configuration is included that will do the right thing for most people, and that can be expanded to for example take into account the geographic location of your user, and make sure their traffic heads to the closest IPv4 gateway available.
However, at RIPE, Terry told us that while his DNS64 setup worked, his traceroutes over IPv6 to IPv4 addresses looked bad, as our DNS64 implementation did not also attempt to convert back reverse PTR queries for ipv6.arpa to in-addr.arpa queries!
Luckily, especially in the right place, it turns out we can easily be convinced to add a feature. We wrote the support for also matching up reverse lookups yesterday, and earlier today Terry reported back that the feature works as intended, as exemplified by the traceroute:
$ traceroute6 www.netherlabs.nl traceroute to www.netherlabs.nl (2a01:568::6464:525e:d522), 30 hops max, 80 byte packets 1 2a01:568:1000:f::1 (2a01:568:1000:f::1) 0.281 ms 0.302 ms 0.363 ms 2 eoip256.thn-gw1.lon.spilsby.net.uk (2a01:568:0:256::2) 1.566 ms 1.570 ms 1.561 ms 3 giana.spilsby.net.uk (2a01:568:400:67::2) 2.214 ms 2.184 ms 2.183 ms 4 host79-98-33-64.uk.spilsby.net (2a01:568::6464:4f62:2140) 2.163 ms 2.156 ms 1.632 ms 5 host79-98-33-64.uk.spilsby.net (2a01:568::6464:4f62:2140) 1.627 ms 2.068 ms 2.101 ms 6 vlan67.thn-gw1.lon.spilsby.net.uk (2a01:568::6464:4f62:21f9) 2.087 ms 1.265 ms 1.391 ms 7 vl423-spilsby-partial-sup-tfm1.jump.net.uk (2a01:568::6464:c299:a961) 1.736 ms 1.864 ms 1.711 ms 8 vl429-sup-tfm23.jump.net.uk (2a01:568::6464:c299:a901) 1.619 ms 1.992 ms 1.980 ms 9 2a01:568::6464:c342:e015 (2a01:568::6464:c342:e015) 1.870 ms 2.073 ms 2.046 ms 10 10gigabitethernet1-1.core1.ams1.he.net (2a01:568::6464:4834:5c52) 13.383 ms 13.353 ms 13.375 ms 11 xs4all.10gigabitethernet3-3.core1.ams1.he.net (2a01:568::6464:d842:543a) 9.817 ms 9.817 ms 8.867 ms 12 0.ge-1-0-0.xr3.3d12.xs4all.net (2a01:568::6464:c26d:505) 9.124 ms 9.625 ms 8.980 ms 13 te5-4.swcolo1.3d12.xs4all.net (2a01:568::6464:c26d:c1e) 9.822 ms 9.089 ms 10.169 ms 14 xs.powerdns.com (2a01:568::6464:525e:d522) 9.867 ms 9.164 ms 10.133 ms
Presented like this, a functioning DNS64/NAT64 setup does indeed look quite magical!
We want to thank Terry for nagging us about this (in a friendly way!) and his rapid testing.
And if you too need a PowerDNS feature, don’t hesitate to let us know!
