Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net 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] 4
31
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 slave.dns.he.net works any better.  That machine does all the slave transfers anyway.

Failing that, you might write to dnsadmin@he.net.

--David

32
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 dns.he.net 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. 

--David

33
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. ;))

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

--David

35
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 ipv6@he.net, describe your situation, and ask for advice.

36
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 he.net.  (Which would be particularly good if you had news to show.)

--David

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

--David

38
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
Status: NOERROR
Reverse ip6.arpa:
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.5.3.1.6.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa.
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.)

--David

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 he.net.   :)

39
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 <<>> aa.net.uk 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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;aa.net.uk. IN AAAA

;; ANSWER SECTION:
aa.net.uk. 53 IN AAAA 2001:8b0:0:30::68
aa.net.uk. 53 IN AAAA 2001:8b0:0:30::65

;; AUTHORITY SECTION:
aa.net.uk. 172793 IN NS primary-dns.co.uk.
aa.net.uk. 172793 IN NS secondary-dns.co.uk.

;; ADDITIONAL SECTION:
primary-dns.co.uk. 172793 IN A 81.187.30.41
primary-dns.co.uk. 172793 IN AAAA 2001:8b0:0:30::51bb:1e29
secondary-dns.co.uk. 172793 IN A 81.187.81.32
secondary-dns.co.uk. 172793 IN AAAA 2001:8b0:0:81::51bb:5120

;; Query time: 1 msec
;; SERVER: 192.168.222.47#53(192.168.222.47)
;; 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.

40
General Discussion / Re: Unexpected Banner
« on: May 24, 2017, 08:05:09 AM »
On the enthusiast level test, upon sending my mail to my postfix configured email server, I'm given the error "Unexpected banner:". Any idea what this could be?
Banner probably refers to the first line of text that the SMTP server outputs.  It should probably look like:
Code: [Select]
220 [i]hostname[/i] ESMTP [i]packagename[/i]There might legitimately be several lines all but the last start with "220-".  If, when you connect to port 25, you see anything other than these, then that is probably the problem.  Typically, test this with something like "telnet -6 hostname 25"

--David


41
General Questions & Suggestions / Re: HTTP GET request of what file
« on: May 23, 2017, 08:59:43 AM »
You gave them a webserver, like "www.example.com".  They gave you filename, like "feefiefoefum.txt".  You are to make it so that "http://www.example.com/feefiefoefum".txt works.  The content doesn't really matter, though should probably be small.  A word, a sentence, a copy of their instructions on making the file, etc...

>Create a file with the name listed below on the website you entered above.

What is this file that is being referenced on the enthusiast level test? Where can I find it?

42
whois says that my domain is using ns1.he.net and ns2.he.net. These are the namservers which I configured at my registrar.

Well, you should probably be using ns1.he.net through ns5.he.net inclusive.  Your registrar should have the ability to add additional nameservers. If that is the actual cause of the error, I don't know.

43
I don't know if it is relevant, but I just used your ns1.sharktech.network for my daily tests, and the ping gave double replies.

ping6 -c4 2001:470:d:117e:c01d:b00b:babe:fb1
PING 2001:470:d:117e:c01d:b00b:babe:fb1(2001:470:d:117e:c01d:b00b:babe:fb1) 56 data bytes
64 bytes from 2001:470:d:117e:c01d:b00b:babe:fb1: icmp_seq=1 ttl=55 time=172 ms
64 bytes from 2001:470:d:117e:c01d:b00b:babe:fb1: icmp_seq=1 ttl=55 time=172 ms (DUP!)
64 bytes from 2001:470:d:117e:c01d:b00b:babe:fb1: icmp_seq=2 ttl=55 time=186 ms
64 bytes from 2001:470:d:117e:c01d:b00b:babe:fb1: icmp_seq=2 ttl=55 time=186 ms (DUP!)
64 bytes from 2001:470:d:117e:c01d:b00b:babe:fb1: icmp_seq=3 ttl=55 time=167 ms
64 bytes from 2001:470:d:117e:c01d:b00b:babe:fb1: icmp_seq=3 ttl=55 time=167 ms (DUP!)
64 bytes from 2001:470:d:117e:c01d:b00b:babe:fb1: icmp_seq=4 ttl=55 time=167 ms

--- 2001:470:d:117e:c01d:b00b:babe:fb1 ping statistics ---
4 packets transmitted, 4 received, +3 duplicates, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 167.258/174.216/186.226/7.829 ms

44
I fear I get different results for that domain:

host -v -t ns sharktech.network.
Trying "sharktech.network"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65336
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;sharktech.network.             IN      NS

;; ANSWER SECTION:
sharktech.network.      3217    IN      NS      ns2.sharktech.network.
sharktech.network.      3217    IN      NS      ns1.sharktech.network.

;; ADDITIONAL SECTION:
ns1.sharktech.network.  86016   IN      AAAA    2001:470:d:117e:c01d:b00b:babe:fb1
ns2.sharktech.network.  86016   IN      AAAA    2001:470:d:117e:c01d:b00b:babe:c1a

Received 127 bytes from 192.168.222.47#53 in 3 ms


I also checked the network. nameservers, and both your listed nameservers, and everything was consistent.

I suspect the difference between what I see and what you showed either means you have a split horizon DNS, or you've changed it since then (which the SOA tends to deny).

I would expect what I see to work... except that maybe they are checking for IPv6 and IPv4?

45
A few thoughts occur:
  • It might be cached on their side.  Have you waited until the TTL expires?
  • There might be glue issues.  Have you updated the glue on the upstream nameservers?
  • Did you remember to update the SOA record?
  • If you want anyone else to look, you should consider identifying your domain.
--David

(I will admit I found this test ridiculously simple.  he.net is my DNS host.)

Pages: 1 2 [3] 4