Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Pages: 1 2 [3] 4 5 ... 10
 21 
 on: May 04, 2020, 04:10:29 PM 
Started by dissy614 - Last post by dissy614
The first time I noticed this, I was using "dig" against ns1.he.net to query the SOA record, so as to check if the serial number incremented to match the master servers.  (I still use the serial format yyyymmddxx where xx starts at 01)

Specifically:  dig @ns1.he.net. example.net. soa

More recently I've also just looked at the records in the slave zone through HE's web interface.

My master server is bind 9, specifically 9.11.5.P4 (it is the default Debian stable package)

Right now the slave zone data is fully up to date, so this time it did not take 23 hours as it did the last time a year or so ago, but certainly far longer than 10 minutes.

At this point I'm thinking the quickest and safest solution for me would simply be to convert the HE slave zone into a master zone, and just remove my bind9 server from the mix entirely.

 22 
 on: May 04, 2020, 08:58:10 AM 
Started by dissy614 - Last post by passport123

> Still, the slave zone does not reflect the data just transferred for about 24 hours.

How do you check this?  What command do you run?   (you can use example.com instead of your domain)

 23 
 on: May 04, 2020, 08:23:39 AM 
Started by dissy614 - Last post by passport123

I use NSD as the master server.  When NSD notifies the he.net severs of a zone change, I see those changes  reflected on the he.net servers within ten minutes.  I have a script that runs ten minutes after the notification, and the script always sees the update on the he.net servers within that timeframe.


 24 
 on: May 03, 2020, 11:22:54 PM 
Started by dissy614 - Last post by dissy614
Is it normal for slave zone updates to take 24 hours?  Or is it just me?

My master server does send notifications to slave.he.net.
Watching logs in real time, clicking "validate" performs an AXFR within seconds.  Still, the slave zone does not reflect the data just transferred for about 24 hours.

With more services utilizing DNS records to verify domain ownership, it's starting to become a problem.  By the time the slave data updates to contain the TXT record token, it has already expired long ago.

I can certainly imagine a free service like this under enough of a load that limits are required to stay up and working.
But I don't quite get why the verify button performs an axfr and the data is seemingly discarded, only to be transferred again a day later.  That seems like doubling the data transfer.

That plus no similar issues being posted here leads me to believe this might be some problem with just me.
Any thoughts or suggestions or ideas?

 25 
 on: April 30, 2020, 07:29:31 AM 
Started by aarboard - Last post by alestanga
yes, now it works :)

 26 
 on: April 30, 2020, 03:37:01 AM 
Started by aarboard - Last post by broquea
This should be fixed now. Reminder that to open trouble tickets, you email ipv6@he.net

 - Alex

 27 
 on: April 30, 2020, 02:10:00 AM 
Started by aarboard - Last post by alestanga
and here, tunnel KO for me too.

 28 
 on: April 30, 2020, 01:15:53 AM 
Started by aarboard - Last post by irtech
Same here.

 29 
 on: April 29, 2020, 11:34:14 PM 
Started by aarboard - Last post by aarboard
Hello,

since about 00:00 GMT today the IPv6 routing on the node zrh1 seems to be broken.
The tunnel is up, and we reach the tunnel endpoint from our side of the tunnel.

2001:470:25:421::1


Routenverfolgung zu xxxxxxx.xxxxxxx.xxx [2a01:ab20:0:4::87]
über maximal 30 Hops:

  1     1 ms    <1 ms    <1 ms  2001:470:26:421::3
  2    39 ms    34 ms    33 ms  tunnel290165.tunnel.tserv23.zrh1.ipv6.he.net [2001:470:25:421::1]
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     *        *        *     Zeitüberschreitung der Anforderung.

Also a looking glass:
core3.fmt1.he.net> traceroute ipv6 2001:470:25:421::1  source 2001:470:0:427::1 numeric
 
Tracing the route to IPv6 node 2001:470:25:421::1 from 1 to 30 hops

  1    58 ms    3 ms   <1 ms 2001:470:0:1a7::2
  2    *       *       *     ?
  3    *       *       *     ?
  4    *       *       *     ?
  5    *       *       *     ?
  6    *       *       *     ?
  7    *       *       *     ?

 30 
 on: April 25, 2020, 04:38:37 PM 
Started by starvirus2 - Last post by cholzhauer
You would probably be best emailing ipv6@he.net

Pages: 1 2 [3] 4 5 ... 10