IPv6, dnsutils and dig

The biggest problem we faced is that an IPv6 network cannot communicate directly with an IPv4 network. You might be thinking, "So ... ? πŸ€·πŸ»β€β™‚οΈ" until you realise that our second biggest problem, is that IPv6 isn't very well adopted across the internet

IPv6, dnsutils and dig

One of the most useful command line tools we came across whilst setting up our IPv6-only Raspberry Pi server, was the dig command. We had never set up a server on a solely IPv6 network before and although we had a bit of experience with IPv6, the majority of our time is spent (like everybody else on the internet) on IPv4.

The biggest problem we faced is that an IPv6 network cannot communicate directly with an IPv4 network. You might be thinking, "So ... ? πŸ€·πŸ»β€β™‚οΈ" until you realise that our second biggest problem, is that IPv6 isn't very well adopted across the internet. So when we're trying to setup services on an IPv6-only server, such as Mailgun; that don't support IPv6 – it becomes a problem. Nothing connects how it should. Stripe, Mailgun, you name it. Nothing was working.

But before all of that, we had a bigger problem. Nobody could access our blog here over IPv6 from an IPv4 network, not even our DNS server. Which meant our domain name wasn't resolving, and nobody could access the blog. Thankfully our Pi4 host Mythic Beasts had a solution.

NAT64

You may well be wondering what NAT64 is. Don't worry, so were we. Essentially, NAT64 is a proxy server that bridges the gap between IPv4 and IPv6 services, allowing them to talk to each other. Think of it (without too much complexity) as a "Zapier" service for protocols.

The network translates DNS A responses (IPv4) into AAAA responses (IPv6) pointing at a range of IPv6 addresses that are routed to stateful NAT64 boxes. The NAT64 boxes translate the traffic from IPv6 to IPv4 allowing clients to reach servers on the IPv4 internet. An extension of this is 464XLAT where the client has a stateless NAT46 allowing IPv4 only applications to send requests via the NAT64.

Mythic Beasts advised us to set a CNAME record for our domain to point to their NAT64 proxy server at proxy.mythic-beasts.com.

CNAME record
our CNAME record for banoffee.brightwork.uk connecting to NAT64

That's great. Our domain connected through fine, we could now view and access our blog via a regular browser and our domain. But what about our services?

npm refused to connect to the repo to even beginning to install Ghost, for example.

npm ERR! code ECONNREFUSED
npm ERR! syscall connect
npm ERR! errno ECONNREFUSED
npm ERR! FetchError: request to http://registry.npmjs.org/ghost-cli failed, reason: connect ECONNREFUSED

This was quickly resolved by adding the IPv6 address of the repo and the hostname in our /etc/hosts file, allowing the NAT64 server to do its thing. After this, we realised we'd need to do that for practically all of our service. Mailgun, Stripe, the yarn repo, Zapier. You name it. Any service we want to use, we will have to add a line into Β /etc/hosts Β with it's corresponding IPv6 address. No biggie.

The right tools for the job

So, how do we get the IPv6 address to begin with? Well, that's where dig comes in. dig is a command that is part of a package of useful tools called dnsutils on Linux.

You can install dnsutils on Ubuntu yourself by running the below command

root@brightwork-pi:~# apt update
root@brightwork-pi:~# apt install dnsutils -y

On CentOS/RHEL it's actually called "bind-utils". You can install it the same way, except you'll be using yum.

root@brightwork-pi:~# yum update
root@brightwork-pi:~# yum install bind-utils -y

After installing the DNS tools, you'll be able to use the dig command. In order the dig for the IPv6 address associated with a hostname, set up the command as follows:

root@brightwork-pi:~# dig aaaa api.stripe.com +short

For example, this will return all the IPv6 addresses for the Stripe API. AAAA tells dig to look for IPv6 addresses. If you wanted IPv6 you would use a single A.

Adding just one of the returned addresses into /etc/hosts along with the hostname fixed the issues for us and allowed the services to connect to our server and vice versa.