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
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.

Suggest a Test! / Ongoing daily tests?
« on: June 08, 2017, 04:46:34 PM »
How about changing it so that:
  • You can continue to do daily tests, even after 100, but only (the last) 100 count.
  • Your credits from the daily tests gradually fades.  Like after 1 year, a test is only worth 0.5 points, and after 2, 0.25 points.  (Fading should probably stop about there.)
These would combine to make the daily tests an ongoing activity, instead of something you do for 4-6 months and then can't do any more.  This could keep people's interest in  (Which would be particularly good if you had news to show.)


General Discussion / Re: "DIG PTR" problems?
« on: May 28, 2017, 10:39:57 PM »
Well, I reported this to, and in 20 minutes it was fixed.  Excellent work


General Discussion / "DIG PTR" problems?
« on: May 28, 2017, 10:04:08 PM »
Is anybody else having problems with the "DIG PTR" daily test today?  All the others worked fine for me, but not the reverse DNS lookup.  I've tried a number of addresses, and it always says (after correctly parsing the query), something like:
Summary of user's dig query
IPv6 Address: 2001:470:1f06:1356::2
Validating user's dig query
Result: Fail
Reason: Record mismatch

(It almost looks like the test machine can't do reverse DNS lookups as of today.)


P.S. FYI: I find tunnel broker transit networks to be a wonderful source of DNS lookups.  They may not ping, but they are all wonderfully filled in.  Thank you   :)

General Discussion / "DIG AAAA" test bug
« on: May 27, 2017, 12:24:25 PM »
I tried to submit the following result:
Code: [Select]
; <<>> DiG 9.9.5-4~bpo70+1-Debian <<>> AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33571
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5

; EDNS: version: 0, flags:; udp: 4096

;; ANSWER SECTION: 53 IN AAAA 2001:8b0:0:30::68 53 IN AAAA 2001:8b0:0:30::65


;; ADDITIONAL SECTION: 172793 IN A 172793 IN AAAA 2001:8b0:0:30::51bb:1e29 172793 IN A 172793 IN AAAA 2001:8b0:0:81::51bb:5120

;; Query time: 1 msec
;; WHEN: Sat May 27 15:11:03 EDT 2017
;; MSG SIZE  rcvd: 239

It was refused, on the basis that "2001:8b0:0:30::68" did not match "2001:8b0:0:30::65".  It turns out that the server side DNS lookup gets the first address, and the parser gets the last address, so any hostname with two IPv6 addresses is rejected unless you cherry pick the submitted results.

Pages: [1] 2 3