I've successfully installed a #NAT64 server and a #DNS64 Bind9 server in my homelab.
I set the DHCP Option 108 and observed my #iOS and #Android devices immediatly going #IPv6-only and enabling its #CLAT engine.
The most surprising part though was that #macOS did the same.
I've read online multiple times, that it also requires an option in the Router Advertisement, which I currently can't set. But no, it didn't need it and also started CLAT.
Now if only #Windows would do the same...
#nat64 #dns64 #ios #android #ipv6 #clat #macos #windows
Having a VPN with #NAT64 and #DNS64 is a great way to see what software is still broken in 2023. Ridiculous.
Hey, popular game store! It's 2023! Migrating from gethostbyname to getaddrinfo really isn't that hard. Do you need to hire me so that I can do those 10 minutes of trivial work for you, since apparently you have been unable to since 2014(!!!) when people reported it.
@doachs i've put the dns64 on my computer and haven't had any problem with #NAT64 in particular--seems to work just as well as any other NAT.
The problem with #DNS64 is that it won't work for IPv4 literals, which bypass DNS completely. And of course you have to use the right DNS servers, which might cause problems with customers that have their own manually set or whatever; hence, my ISP uses #464XLAT instead to simulate a real IPv4 connection.
huh so that's interesting, my ISP has a #DNS64 gateway and through that the IP is 172.56.208.221 when otherwise it's 172.56.209.216, interesting
Sympa, le résolveur #DNS64 de Google synthétise aussi des PTR pour ses ip6.arpa à partir des in-addr.arpa du domaine.
So far we have only deployed #IPv6 in dual-stack mode. I really want to push for IPv6-only now, but I'm not sure if we have all the necessary pieces in place. We can set up #DNS64 on our #Infoblox cluster, but I'm not sure if any of our Cisco routers are actually capable of doing #NAT64.
#CiscoLiveEMEA
#ipv6 #dns64 #infoblox #nat64 #ciscoliveemea
ExecStart=/usr/sbin/dnsmasq --filter-A --log-async --enable-dbus --keep-in-foreground
works for me, but unfortunately dnsmasq doesn't provide dns64, so my all day solution for home stays unbound with
module-config: "respip dns64 validator iterator"
#dns64-prefix: 64:ff9b::/96
# well-known prefix (default)
## remove A-Records
response-ip: 0.0.0.0/0 redirect
May be the next time I try the bind work around or the patches for unbound. The patch for bind seems to be disappeared 😦
You should set up and run #NAT64 + #DNS64 in you #dualstack environment. Benefits are that it allows #IPv6 only devices a way to connect to IPv4 only servers, and provides valuable experience with IPv6, with no downsides. It does mean that dual stack devices will use NAT64 instead of NAT44, but you are still using NAT either way (and IPv4 devices always have to use NAT). See my article for more details and network diagrams https://sgryphon.gamertheory.net/2022/12/14/running-nat64-in-a-dual-stack-network/
#nat64 #dns64 #dualstack #ipv6
@alexband @nlnetlabs
Thank you for the tip about tags for RPZ policies. I haven't read the documentation carefully.
Regarding #NAT64 I was really asking about #DNS64. Tags or views support seems to be missing here. In my case, the L3 switch can announce only one set of DNS servers via RDNSS. It can't be changed per network. So the introduction of such a feature in the upcoming versions of #Unbound might be warmly appreciated, at least on Fediverse. 😃
@mzar @nlnetlabs #RPZ yes. With access control options instead of defining a view, a tag can be defined (`access-control-tag:`, `interface-tag:`) and used in `rpz: tags:`. https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/rpz.html
I am not sure what you want to achieve with NAT64, but Unbound does not support it (yet). #DNS64 on the other hand is an always on module. It does not synthesise for clients that come with the CD bit as per the RFC; maybe that is useful. #DNS