I can confirm it's now fixed - thekrugers, you will probably need to reset to explorer as well - it wouldn't take without it for me.

This should be fixed.  If you still see the error, you may need to reset down to Explorer level by visiting https://ipv6.he.net/certification/reset_explorer.php.

Many name server hosting providers will have a way to "purge cache" either automated or by submitting a ticket. Google for example.

But also there's nothing that stops you from having more than one authoritative ns for a domain, so as long as you have NS delegation records for ns1, ns2, ... .he.net at the root in addition to what you have now, you should be able to add your domain as primary. There still may be some interruption if you don't replicate the RRs by hand quickly, so it would be better to add it as a slave, and when the records are automatically replicated, convert it to primary (kind of like "promoting") and remove the old NS records after everything is working, but this would require the current DNS provider to allow axfr, may be issues if your domain is DNSSEC signed, etc.

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.

Hello,
I have the same problem: "Status: Pending" and Prefix with "No auth on file"

I send loa through e-mail like ipv6@he.net for review
But I didn't get any reply.

How log does it normaly take to setup BGP after sending the LOA and can I check if something is wrong with my IRR?

Thanks

Retried on both my /64 and /48 (allocated by HE.net).

Reset to explorer, made it back to Administrator without any issues...so mail transfer is working...

Still getting "unable to find MX for domain," which is odd, because my postfix server is receiving emails from he.net without any issues.

Whatever it is, it's failing quickly. I guess we'll wait and see on our respective support tickets...

I'm in the middle of moving one of my DNS zones from another provider onto dns.he.net.

However, it looks like the old NS and SOA records have quite a long TTL (1 day), and I can't do anything to decrease the TTL at the old provider.

These records seem to have been cached by HE.  So now, despite the authoritative servers for the TLD serving the new delegation, I'm still unable to get HE to serve the zone, which means my site is down.

It'd be really really nice if there was a way to ask HE to ignore its cache of such records when re-checking delegation, to avoid this scenario.

Isn’t the test to see if you can run a mail server?  Therefore, it probably has to be in your netblock.

Hmmmm... Actually, it's part of a different /64 (also a tunnelbroker.net one, but on a different account). I might install a small mail server on my own /64 and reset/redo the certification again to see if that fixes it.

I have logged a ticket with HE support, but no reply on that yet.

thekrugers, is your MX server part of your /48 or /64?