#dns64

I got asked if I could create a #howto for creating a (public) #NAT64 service - just like I did recently for #BoxyBSD. With #DNS64 and #NAT64 you can also reach resource in the legacy internet (#IPv4) on #IPv6 only systems.

While this is based on #unbound and #tayga, there’s also a solution by using the #OpenBSD's native way which is also running on the other gateway. I’ll share a second how to how to do this in OpenBSD and pf.

https://gyptazy.com/howto-create-a-public-dns64-nat64-gateway/

Following Jen's presentation at #RIPE89 to stop using DNS ... DNS64 or #RFC7050, I started looking into this.

https://ripe89.ripe.net/wp-content/uploads/presentations/79-dep7050_ripe89_lt.pdf

Currently #Android12 and younger already values the existince of #RFC8781 PREF64 over any prefix discovered by DNS64.

- ChromeOS M130 does not yet.

@forwardingplane

#IPv6 #PREF64 #DNS64 #NAT64

@tschaefer
I was thinking how this title would continue. Knowing here previous talks and her area of work it was clear to me how it would continue and I was right. #DNS64

Using an #IPv6mostly setup I can clearly see why.

Yesterday I used nat64.net and everything was already working, but I wanted to do it all locally. So, I tried setting up a VLAN with only IPv6, using NAT64 and DNS64. I installed an OpenBSD VM on bhyve, mapped the ethernet ports, and configured unbound, pf, and rad in just three minutes - everything works. Without using any external packages.

The simplicity and completeness of OpenBSD and its base system is always a source of joy.

#OpenBSD #IPv6 #NAT64 #DNS64 #Networking #VLAN #SysAdmin #RunBSD #BSD

A good #dualstack network should still run #dns64 and #nat64, so that it can fully support #ipv6 only devices and allow them a way to connect to legacy (ipv4) internet sites. https://sgryphon.gamertheory.net/2022/12/running-nat64-in-a-dual-stack-network/

Anyone know if it's possible to generate #DNS64 entries locally on #OpenWRT? The service I use (at 2606:4700:4700::64) seems to be misbehaving, but DNS is reported to be fully functional on the Cloudflare status page. It seems like #dnsmasq ought to have all the information it needs to generate an AAAA record corresponding to the A record, so I could just use standard #DNS upstream, but I can't figure out how to do it.

@issackelly @tyler I rather like #NAT64 ; it's clever. So is #DNS64. Even the custom Bowtie routing is rather neat in its operation. That said, putting all three together does seem to be a lot of moving parts.

There will indeed be situations where the need is to access a legacy private IP network, but there will also be cases when enabling #IPv6 for that private network would reduce complexity for all its users. Native IPv6 could still leverage the Bowtie routing for multiple disparate subnets.

I've tried to summarize the current state of the art for IPv6-First and IPv6-Only Access Networks in my blog post here: https://blog.daknob.net/do-you-really-need-ipv4-anymore/

Let me know how it went for you, what problems you may have ran into, and whether something is missing! I'm also happy to answer questions or help with ideas.

#IPv6 #NAT64 #DNS64 #PREF64 #464XLAT #SIIT #Option108

Anyone have any ideas for squeezing a #CLAT into a container? My #homelab #k8s cluster is IPv6-only, and I've discovered this evening that steamcmd is not even asking for AAAA records, meaning my #NAT64 and #DNS64 setup is not effective here. I am not going to dual-stack the whole cluster network just to host one game server, so I'm looking for container-ed options.

IIRC, a requirement for CLAT is being able to carve out a /96 for translation, but k8s assigns a single #IPv6 per pod...

Introductory post: this is my public sub-account for #IPv6 content; my main account is linked in my profile.

I support the complete roll-out of IPv6, including intermediate efforts like dual-stack support and #NAT64 #DNS64 #CLAT, with the ultimate goal of native IPv6 support in all-new deployments, using RFC standards and best practices.

I support subnets no smaller than /64 (#SLAAC), ISPs should delegate prefixes of at least /56 or /48, and #ICMPv6 should be rate-limited, never blocked.

#ipv6only
#openwrt
#jool
#DNS64
#nat64
#ipv6

https://openwrt.org/docs/guide-user/network/ipv6/nat64

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

#DNS64 + #NAT64 is so cool

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

#dns64 not working :(

just not responding

Sympa, le résolveur #DNS64 de Google synthétise aussi des PTR pour ses ip6.arpa à partir des in-addr.arpa du domaine.

#ipv6only
#ipv6
#dns #dns64 #nat64 #bind

https://lists.isc.org/pipermail/bind-users/2023-January/107288.html

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

@revk Yes … AS29670 (Individual Network Berlin e.V.) in this case … our #in-berlin.de / #in-vpn.de users can use #NAT64 with the well-known prefix 64:ff9b::/96 and have #DNS64 at 2001:67c:1400:800:53:64::1 and 2001:67c:1400:800:53:64::2