I Switched My Network To IPV6 And Now Certain Domains Won't Resolve

[isaacthekind]

I currently have DHCPv4 and DHCPv6 enabled. If I disable DHCPv4, certain domains no longer resolve, some examples of such domains are:

openweathermap.org
discord.gg
forum.opnsense.org

However, others work just fine, like:

google.com
youtube.com
nextcloud.com

All of the sites that don't work give output like this when I run a command such as nslookup -query=AAAA openweathermap.com:

Non-authoritative answer:
*** Can't find openweathermap.com: No answer

The way I'm interpreting this is that these sites have no AAAA record and so I can't connect to them from my IPV6-only network. I'm wondering if there's some way to resolve this (no pun intended) by enabling some kind of IPV4 fallback on my network, or by some other means. Surely it's not right that switching to an IPV6-only setup makes large amounts of the internet inaccessible?

Thanks for your time.

[Maurice]

You'll need DNS64 + NAT64. DNS64 can be enabled in the Unbound settings. The easiest option is to enter a public NAT64 prefix, you can find some on e.g. nat64.xyz. If your WAN is dual-stack, you can also install the Tayga plugin and configure your own local NAT64.

If your WAN is IPv6-only, you should also configure Unbound Query Forwarding (or DNS over TLS) with an IPv6 DNS server. A recursive resolver needs dual-stack because some name servers still have no IPv6 connectivity.

Cheers
Maurice

[phoenix]

Before saying there's a problem with IPv6 on OPNsense I'd suggest the first thing you do is check if the site is actually active for IPv6 by using the following site:

https://dnschecker.org/

[isaacthekind]

Hey there, thanks very much for the replies.

So I've set up DNS64 and added a NAT64 prefix from the site supplied. I can now resolve IPV6 addresses for the sites in question in the terminal, however they still can not be access in any web browser even after clearing the cache. I tried setting up query forwarding using Google's IPV6 server, and this had no effect. So it seems like some progress has been made, but I still don't quite have it working and am a bit lost with how to troubleshoot it.

[Maurice]

Some of the NAT64s listed on that website are sometimes broken. From my experience, the ones hosted by Kasper Dupont and level66 are very reliable, while August Internet and Tuxis are essentially dead.

Also, make sure to enter the entire NAT64 prefix, including ::/96

[isaacthekind]

Sorry Bill, I missed your comment. If I gave the impression that I was blaming IPV6 or OPNsense, that was not my intention. To clarify: I'm not sure what the issue is. As for the site you linked it's saying these sites don't have AAAA records, which is what I expected and matches what i said in my initial comment. However I was under the impression that despite this there is still supposed to be a way to access them from within a purely IPV6 network, surely switching to IPV6 shouldn't make large swaths of the internet inaccessible.

As for your comment, Maurice, I tried some of the other NAT64s that you mentioned to no avail. Again, I'm able to use nslookup and get a synthesized AAAA record for the site once I set the NAT64 prefix in Unbound (and yes, I include the prefix size after the slash). But once I use a browser I can't get to these sites.

[Maurice]

The synthesized AAAA records are created by Unbound itself, so this is indeed expected to always work.

Can you ping a synthesized IPv6 address, both from OPNsense itself as well as from a host in your LAN? Try

ping 2001:67c:2960:6464::1.1.1.1

And make sure your browser actually uses your local DNS server (not a public one via DoT / DoH). You can also try accessing a website via IPv6 literal, e. g.

http://[2a00:1098:2c:0:0:5:65.108.75.112]/yaml

[isaacthekind]

The pinging behaviour for sites that won't load in the browser is inconsistent. openweathermap.org responds, but discord.com and forum.opnsense.org don't. This is the case regardless of whether I ping by domain name or IP, from desktop or from OPNsense. I included photos.

The browser behaviour is consistent across a range of browsers and I can't see any special DNS settings that have been enabled in the browser. You can see my Firefox configuration here if it's of interest: https://gitlab.com/askyourself/dotfiles/-/blob/main/home-manager/modules/firefox/default.nix?ref_type=heads

Accessing these sites by IPV6 address rather than domain name has no effect on the behaviour (har har funny IPV6 address you linked).

[Maurice]

Ah, I see. Some of the Kasper Dupont prefixes on that website aren't up to date. Try these:

2a00:1098:2b:0:0:1::/96 (England)
2a00:1098:2c:0:0:5::/96 (England)
2a01:4f8:c2c:123f:64:5::/96 (Germany)
2a01:4f9:c010:3f02:64::/96 (Finland)

ICMP can sometimes be unreliable when using NAT64, so a failing ping doesn't necessarily mean the host is actually unreachable.

[isaacthekind]

Haha awesome! It's working now. I didn't know this about ICMP, if you can explain why that unreliability is happening or point me to a source, I'd like to understand. This will affect my whole workflow because I have always unquestioningly assumed ping is a 100% reliable way to test connectivity. I find it funny that you just persistently got me to try the same solution until it worked, this has been a lesson to always try things repeatedly before assuming I've hit a dead end. I guess you were actually correct from the very first post. I'd also like to know how you were able to tell the NAT64s were no good and that the others would work. Don't worry about answering these further questions if not of interest, I just like to understand these things.

Thank you very much for your time, I really appreciate the help and I'm happy to now be set up 100% on IPV6.

[Maurice]

Glad it works and sorry for making this harder than necessary by posting a link to a somewhat outdated website. I should have just given you some known working public NAT64 prefixes straight away.

NAT64 is relatively easy for TCP and UDP, you essentially replace the IPv6 header with an IPv4 header and vice versa. But ICMPv4 and ICMPv6 have significant differences and can even include IP addresses in the payload. So translating ICMP packets between IP versions is not that straight forward and various NAT64 implementations handle it differently. Feel free to deep dive into the RFCs and discussions about them for more details.

How to figure out the prefix yourself: All of these public NAT64 providers also run DNS64 servers. We don't need these, because OPNsense / Unbound can do DNS64 itself (unlike a typical consumer router). But if you query such a DNS64 server, you can easily spot the prefix it uses.

Cheers
Maurice

[isaacthekind]

Ok, that all makes sense, thanks for all the help, glad to have this working! Have a good day.