• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Are there any public NAT64 nodes?

Started by deags, August 19, 2016, 05:32:06 PM

Previous topic - Next topic

deags

In this new day do these exist or have they all been ended (from what I can assume is abuse).

aandaluz

a long time ago Andrews And Anorld Ltd had a dns64 gateway which was reacable from HE.net.  (2001:8b0:6464::1 and 2001:8b0:6464::2). I haven't checked lately if it still still operating for current tunnels:

http://aa.net.uk/kb-broadband-ipv6-nat64.html

tjeske

There's still go6lab.si running since 2013. Works fine, albeit not the fastest. But perfect for testing, I'd say. Since they're using a public prefix, just set their DNS64 in your IPv6-only network as your DNS-resolver and you're good to go!

Though remember: all unencrypted traffic will pass their node unencrypted!

kasperd

I don't know if the A&A NAT64 was a public NAT64 at some point. But these days it's not. Even for their own customers the NAT64 was not particular reliable, which I find a bit odd for an otherwise excellent ISP.

Of still operational public NAT64s I knew of only http://www.trex.fi/2011/dns64.html and https://go6lab.si/current-ipv6-tests/nat64dns64-public-test/ of which the TREX NAT64 was the most reliable even though it only had a single NAT64 prefix compared to the four which Go6lab has.

I eventually wrote a health checker that one can run along with a BIND DNS server to achieve redundancy across multiple NAT64 prefixes: https://v6tools.kasperd.dk/nat64health

Finally I took this futher and implemented my own public DNS64+NAT64 service: https://nat64.net/

Unlike the others I have redundancy across four geographical locations and two hosting providers. Each of my DNS64 health checks the NAT64 prefixes to ensure it's handing out AAAA records for NAT64s that are operational.

Unlike other NAT64 mine does not let you completely hide your real IPv6 address. I hope that will help prevent abuse. I also have a few other tricks up my sleeve to deal with abuse.

rahulparekh

@Kasper Dupont - I am impressed with your public DNS64+NAT64 service! Thanks

tjeske

Since a couple of weeks ago there's also nat64.tuxis.nl. At the moment only reachable via IPv6, but supports DoH and DoT so you can even set it on Android 9+ as Private-DNS.

kasperd

Is DoH and DoT something which BIND on Ubuntu Sever 18.04 LTS can be configured to do? If it is, I'd happily support it on the DNS64 servers in my pool.

My searches so far have only lead to suggestions which involve an additional proxy layer and I suspect that would interfere with BIND's ability to choose a NAT64 close to the client.

tjeske

#7
For DoH you'll obviously need an https-server with a valid certificate (LetsEncrypt?) next to bind. Don't know what's needed for DoT.

For DoH, I found this tut:
https://terminaladdict.com/networking/linux/2019/09/13/DoH.html

(late edit: I somehow overlooked what you did there. Really amazing stuff you did with your NAT64 gateway!)

snarked

DNS over TLS is done with BIND using stunned as a front end.  Too bad it doesn't have native TLS as it does use the OpenSSL library.

kasperd

I have taken a look at that doh document. From the document I cannot tell if it is compatible with the clients directive in a dns64 block in a BIND 9 configuration. I suspect what's going to happen is that BIND 9 will see all requests as originating from ::1 and any attempt to direct clients to a nearby NAT64 would be futile as BIND 9 would have no idea which client it is responding to.

The installation instructions involved downloading source code, so I figured at least I should try downloading that source and look for myself if there was anything in the code to deal with that issue. Alas the repository mentioned in the document requires authentication and I don't have credentials for that service.

As for DoT I have serious doubt it's going to work with a separate daemon implementing SSL. If that separate daemon only handles the SSL part and doesn't itself understand the inner protocol (in this case DNS), it also cannot insert any information about the client IP address into the DNS communication. And again I wouldn't know which NAT64 would be closest to the client.

Since I am writing this post anyway I just wanted to mention a couple of things which has been happening.

  • I have made some performance improvements. So now my NAT64 gateways can handle a little more traffic than before. And the abusive traffic that everyone with IPv4 access is receiving I am now able to drop 10 times faster than before.
  • In January I decided it was time to create a page with a list of all the public NAT64 gateways I know about: https://nat64.net/public-providers
  • I am looking into the possibility of bringing up some NAT64 gateways in North America as well. To do that I want to find two cheap providers (nobody is paying me for operating this service). I'll probably use Dreamhost as one of the providers, I'm happy to hear suggestions for a second hosting provider.

tjeske

@kasperd
We also made a list of public NAT64 gateways: https://nat64.xyz

kasperd

Quote from: tjeske on April 05, 2020, 03:13:52 AM
@kasperd
We also made a list of public NAT64 gateways: https://nat64.xyz
I found that list already. On Tuesday I added a link to it from my list and also sent some updates for that list.

kasperd

I have added DoT support to my NAT64 service. The DoT servers have the name dot.nat64.dk.

gator6

Quote from: kasperd on August 02, 2020, 01:57:20 AMI have added DoT support to my NAT64 service. The DoT servers have the name dot.nat64.dk.

Hi Kasper, is your DoT still active?

snarked

Response #8 is no longer true.  BIND now supports DoH and DoT natively. Whether such additions have propagated to software packagers is a different issue, but that does not prevent one from compiling BIND from its source.