Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  


Welcome to Hurricane Electric's forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - divad27182

Pages: [1] 2 3
Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: August 01, 2017, 05:26:30 PM »
I wrote in, talked a bit, and they found out the problem I was having.  It turns out that
  • You should send the NOTIFYs to  The other I don't think matter, or work at all. does not work at all.
  • You MUST send the NOTIFYs with a source address equal to one of the registered master addresses.  This I had to be told by staff, and is apparently what causes a "Refused" error.

Yes, IPv6 notifications do work, at least if you get your source address correct.  IPv6 transfers do work.


Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: August 01, 2017, 11:19:52 AM »
At this point, I would suggest packet sniffing the network connection to determine if the request is being lost or ignored, or if it has an error.  If the former, I would suspect you have network problems.  If the later, I would suspect DNS configuration problems.  Since the error talks of retries, I suspect the network problems.

OK, I decided to test before posting, and now I am really confused.  I can't seem to get an update to go through, though I have seen the transfer to slave happen.
I can report that returns error "refused" (5), ns2 through ns5 return error "not implemented" (4), and seems to not respond at all.

At this point, I suspect a problem inside's DNS, and plan to write in.

One possible solution to the deadlock:
  • setup your own temporary DNS server for the domain in question.  Make sure it lists the DNS servers. (It will only need to be there for a few minutes.)
  • create a slave zone pointing to your DNS server.
  • convert the slave zone to a master.
  • get rid if the temporary DNS server.
At this point, the DNS zone exists, even without being delegated to.   :-)

I think there was a note about writing to one of the support addresses ( or as an alternative.


I did some debugging with wireshark:
What is wrong here?

Well, several packets from the remote server were lost.  The remote webserver tried to end the connection normally after 5 seconds of inactivity.  A TCP retransmission was initiated, and some (but not all) data was successfully resent.  Then (assuming TCP's rules haven't changed since IPv4) either the remote machine was rebooted, or it's TCP stack is broken or at least poorly configured, as those are the only way you get a RST in 120 seconds.  [I wouldn't bother with this issue.] 

Both ends seem to be sending a payload length (inside all the headers) of 1208, with an overall packet length of 1280, and you did receive such a packet.

Well, TCP did always require only a non-zero probability of successful delivery from it's lower level, but it never really behaves well unless it gets a very high probability of successful delivery.  Maybe you have a noisy connection (which seems unlikely with current technology).  Most of the dropped packets appear to be incoming.  If so, you might be able to tune your TCP stack to be more aggressive at sending and requesting retransmissions.  Unfortunately, that is just a workaround.

As for the underling problem?  Your guess is as good as mine, but I would suspect it isn't MTU, as the payload 1208 overall 1280 packets went both ways successfully (#4, #10).

General Questions & Suggestions / Re: certificate
« on: June 23, 2017, 08:44:17 PM »
-1 on this.  If you want to check the certificate, install CACert's root certificate.

(Personally, I don't understand how "Let's Encrypt" got into the lists... but then that could apply to most of the listed CAs.)

By the way... it looks like Let's Encrypt does not use a Let's Encrypt certificate.  Should anyone?

Questions & Answers / Re: MTU Issue?
« on: June 22, 2017, 07:25:32 PM »
1424 is the maximum size of a packet that can go through.
MTU of the link is 1472.

Close, but not quite.  1424 is the maximum payload length that, with the addition of 48 bytes of header, can fit in an MTU of 1472.  1424+48=1472  Specifying 1424 actually gets you a packet length of 1472.

What's wrong with the 1472 MTU uplink. How can I debug it?

Myself, I would probably start by "tcpdump"ing to a file on both end, and then analyzing the files with wireshark.  Look for what differs.  Look of ICMP messages.

Code: [Select]
# tcpdump -i eth0 -s 9999 -w first_end.tcpdump tcp port 22 and host otherhostname

Questions & Answers / Re: MTU Issue?
« on: June 22, 2017, 08:04:15 AM »
Truncation?  Well, I think it is because google's box is truncating the reply to 64 bytes of data.
Try pinging instead.

Truncating the reply is a reasonable sanity measure.  It allows you do send a 64 byte reply to a 64000 byte request, thus no clogging up your own outgoing packets.  It also makes it more likely for the reply to get through an asymetric MTU problem.  On the other hand, one gets problems like what you are seeing.

My issue with all this is that wireshark doesn't manage to pair up the truncated reply with the request.  Somebody never saw a truncated reply.

edit: That 48 byte discrepancy is the IPv6 header (40 bytes) and the ICMPv6 header (8 bytes).  The byte count specified is the payload length.

so i should just simply push the update button and not alter the ns1 through in any way there? in the name area and just in the nameserver area?

OK. First off, "" is not a registered domain.  If you are actually trying to use that, you should register and pay the fees first.  I currently use, but there are hundreds of registrars available.

If you were using unafunk as an example, you should write "".

Second, I'm afraid you've lost me.  Sorry.


newbie at this, but how do i delegate my domain name with nameserver?

Delegation is part of domain name registration.  Having registered "" at some registrar, you go back to the regiistrars website and tell them that you want to specify the name servers.  (Many registrars expect to host your DNS too, so this can be tough, or out of the way.)  Then you specify through as your nameservers.  Then you may have to wait up to two days for things to propagate (or maybe not).  Then you should be able to get HE.NET's dns support working for you.


General Questions & Suggestions / Re: DNS types
« on: June 20, 2017, 07:43:49 AM »
But with numeric input, at least you get an output.....

The output could only be "Unknown record of type n with undecodable content".  The content bytes could be output, but domain names would often be undecipherable due to trailing domain compression.  OK, there might be some value to showing the unknown records. 

Note that you really are better off with an ANY query to fetch this.  (Frankly, if you are trying to browse DNS, I would always recommend "ANY", except if you are trying to deal with a partially expired cache.)

Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: June 18, 2017, 10:54:35 AM »
You might try seeing if sending your notification to works any better.  That machine does all the slave transfers anyway.

Failing that, you might write to


Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: June 18, 2017, 10:42:44 AM »
I think it is supported.  My DNS slave zones on have an IPv6 address listed as the master, and have successfully downloaded.

The bit that you are showing, that might still not be supported, is notification to the slave that the master has changed. 


General Questions & Suggestions / Re: DNS types
« on: June 17, 2017, 02:50:13 PM »
Actually, any DNS lookup software should also accept numeric types so that new entries can be looked up prior to full support for them.
Wouldn't work.  The necessary part is decoding the reply.  An unknown type could only be reported as hex bytes or just "undecodable".  This is the same reason unknown types can't even be forwarded by caching server or slave server.  I suspect this is why many new things are encoded in TXT fields.

Of course, a DNS lookup software should support "ANY".  (Maybe I should make a DNS server that returns weird or random data, just to see what the clients make of it. ;))

Questions & Answers / Re: ahem... 'multi-homed' via 2 tunnels?
« on: June 13, 2017, 08:04:38 PM »
Third possibility:
Make one tunnel.  Use it normally over the better IPv4 connection.  When/if that fails, use the dynamic address capabilities of the tunnel to reconfigure it to the other IPv4 connection.  If the monitoring is good enough, you probably won't even lose IPv6 connections.


Questions & Answers / Re: ahem... 'multi-homed' via 2 tunnels?
« on: June 13, 2017, 07:59:00 PM »
You can definitely set two /64 networks in each building.  I'm not sure if you can prioritize them differently, or get any sort of failover.

In any case, I don't think that is what you want.  I think you may want a pair of BGP tunnels to route one network through paths with different priorities.  I'm not sure of the details there, or where you get the assignments.  This would allow you to have one netblock, two tunnels, and automatic failover and sharing between them.

Alternatively, if you already have a public IPv4 netblock that can route through either connection, then you could just have one tunnel routed over the existing IPv4 infrastructure.

My suggestion: write to, describe your situation, and ask for advice.

Pages: [1] 2 3