Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  


Welcome to Hurricane Electric's forums!

Pages: 1 ... 3 4 [5] 6 7 ... 10
 on: November 29, 2019, 03:10:18 PM 
Started by thekrugers - Last post by engyak
Retried on both my /64 and /48 (allocated by

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

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

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

 on: November 29, 2019, 08:23:59 AM 
Started by cdanis - Last post by cdanis
I'm in the middle of moving one of my DNS zones from another provider onto

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.

 on: November 28, 2019, 09:48:31 AM 
Started by thekrugers - Last post by snarked
Isnít the test to see if you can run a mail server?  Therefore, it probably has to be in your netblock.

 on: November 28, 2019, 01:15:59 AM 
Started by thekrugers - Last post by thekrugers
Hmmmm... Actually, it's part of a different /64 (also a 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.

 on: November 27, 2019, 09:33:38 AM 
Started by thekrugers - Last post by engyak
thekrugers, is your MX server part of your /48 or /64?

 on: November 27, 2019, 09:21:24 AM 
Started by thekrugers - Last post by engyak
I'm just going to me-too this post. I am having the same exact issue - could this be at the application level?

ansible:~ # dig mx +short
ansible:~ # dig aaaa +short
ansible:~ # dig +short -x 2001:470:e8a3:e060::100

 on: November 26, 2019, 08:53:40 PM 
Started by thekrugers - Last post by thekrugers
The domain is I believe the checks done for the test are a mx, aaaa and -x dig, so I did some myself:

andy@ubuntu-srv:~$ dig mx +short
andy@ubuntu-srv:~$ dig aaaa +short
andy@ubuntu-srv:~$ dig -x 2001:470:1f23:fd:215:5dff:fe07:724 +short

I just tried the test again and it still says it can't find the MX for the domain. Since the domain doesn't carry any important email (it only has one address, the one I used for the Admin test), I've just deleted the MX RR referring to mail4, so now it only has an IPv6 MX server. I'll give it an hour or so and try the test button again.

 on: November 25, 2019, 07:34:43 AM 
Started by thekrugers - Last post by cholzhauer
Which domain?

 on: November 23, 2019, 11:25:21 PM 
Started by thekrugers - Last post by thekrugers
I'm a bit confused as to how this is even possible. My Professional level test is stuck on an error message Unable to find MX for domain right after the Administrator level test found the MX for the domain and sent an email to the domain.

I've even reset and started the tests over with a lower level domain after being stuck with this problem for a couple of days, I was doing the cert on a subdomain and moved it up to the main domain.

Now sure, I would expect the Professional level test to fail with something like RDNS does not match or something similar for a couple of hours because the old PTR RR has a TTL of 24 hours, but to be stuck on Unable to find MX for domain right after the Administrator test managed to find the MX and send mail via it seems a bit strange.

 on: November 23, 2019, 02:38:10 PM 
Started by holgersson - Last post by holgersson
Sorry, I didn't notice your reply as I forgot to turn on email notifications. The MTU is 1280. I did a tracepath MTU discovery and it also reports 1280 with an asymmetric return route, so no problems there. I teared down and rebuilt the tunnel multiple times to no avail.


New info: now while posting this reply, I decided to do some quick tests again after weeks of failure and testing IPv6 elsewhere where it worked. Without touching any of the related configs, sites that refused to work earlier now do work. Weird. I suspected an issue with the Budapest endpoint, it might have been fixed. I'll be testing more soon. Thanks for the help.

Pages: 1 ... 3 4 [5] 6 7 ... 10