• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Guru test - Couldn't get AAAA for NS

Started by jnojr, April 11, 2014, 01:58:04 PM

Previous topic - Next topic

jnojr

But...

flamingo:~ joliver$ dig -6 aaaa ns2.sdsitehosting.net

; <<>> DiG 9.8.5-P1 <<>> -6 aaaa ns2.sdsitehosting.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21205
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;ns2.sdsitehosting.net. IN AAAA

;; ANSWER SECTION:
ns2.sdsitehosting.net. 476 IN AAAA 2600:3c01::f03c:91ff:fe96:bbec

;; AUTHORITY SECTION:
sdsitehosting.net. 163029 IN NS puck.nether.net.
sdsitehosting.net. 163029 IN NS ns2.sdsitehosting.net.

;; ADDITIONAL SECTION:
puck.nether.net. 9093 IN A 204.42.254.5
puck.nether.net. 79745 IN AAAA 2001:418:3f4::5
ns2.sdsitehosting.net. 476 IN A 173.230.157.122

;; Query time: 2 msec
;; SERVER: 2001:480:10:4::2#53(2001:480:10:4::2)
;; WHEN: Fri Apr 11 13:14:30 PDT 2014
;; MSG SIZE  rcvd: 167

flamingo:~ joliver$ dig -6 aaaa puck.nether.net

; <<>> DiG 9.8.5-P1 <<>> -6 aaaa puck.nether.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63474
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;puck.nether.net. IN AAAA

;; ANSWER SECTION:
puck.nether.net. 79736 IN AAAA 2001:418:3f4::5

;; AUTHORITY SECTION:
nether.net. 92962 IN NS puck.nether.net.
nether.net. 92962 IN NS anyns.pch.net.
nether.net. 92962 IN NS thorn.blackrose.org.

;; ADDITIONAL SECTION:
puck.nether.net. 9084 IN A 204.42.254.5
thorn.blackrose.org. 79736 IN A 204.42.254.7
anyns.pch.net. 86933 IN A 204.61.216.4
anyns.pch.net. 533 IN AAAA 2001:500:14:6004:ad::1

;; Query time: 37 msec
;; SERVER: 2001:480:10:4::2#53(2001:480:10:4::2)
;; WHEN: Fri Apr 11 13:14:39 PDT 2014
;; MSG SIZE  rcvd: 208


I did search, and there are several threads about this, but a plethora of possible causes.  One of these name servers I have no control over, and if there's no glue record for it, there's nothing I can do.  My IPv6 has been set up for months now, so this shouldn't (famous last words!) have to do with caches.  I did just get the reverse DNS for my v6 address set, and that record has a TTL of 10800, but that shouldn't be the issue here...

tsprinzing

Quote from: jnojr on April 11, 2014, 01:58:04 PM


I did search, and there are several threads about this, but a plethora of possible causes.  One of these name servers I have no control over, and if there's no glue record for it, there's nothing I can do.  My IPv6 has been set up for months now, so this shouldn't (famous last words!) have to do with caches.  I did just get the reverse DNS for my v6 address set, and that record has a TTL of 10800, but that shouldn't be the issue here...

I found one test, reset the certification, re-did everything up to sage status, but then... same thing here. How did this guy get over it 2 years ago?

Any hints?

shdwdrgn

Since I just went through this myself, I thought I'd offer up some hints...

First off, OP's dig query is reading information from their own DNS server, and not from the glue records.  To get the glue records, you first need to know the nameservers for your domain's TLD.  We'll work with OP's .net domain as an example:

# dig +short NS net.

l.gtld-servers.net.
f.gtld-servers.net.
i.gtld-servers.net.
m.gtld-servers.net.
b.gtld-servers.net.
a.gtld-servers.net.
g.gtld-servers.net.
e.gtld-servers.net.
d.gtld-servers.net.
c.gtld-servers.net.
k.gtld-servers.net.
h.gtld-servers.net.
j.gtld-servers.net.


Pick any one of the servers from the list, it doesn't matter which.  Now we can read the glue record directly from the TLD:

# dig +norec NS ns2.sdsitehosting.net @d.gtld-servers.net

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norec NS ns2.sdsitehosting.net @d.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27100
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;ns2.sdsitehosting.net.         IN      NS

;; AUTHORITY SECTION:
sdsitehosting.net.      172800  IN      NS      puck.nether.net.
sdsitehosting.net.      172800  IN      NS      ns2.sdsitehosting.net.

;; ADDITIONAL SECTION:
puck.nether.net.        172800  IN      A       204.42.254.5
puck.nether.net.        172800  IN      AAAA    2001:418:3f4::5
ns2.sdsitehosting.net.  172800  IN      A       173.230.157.122
ns2.sdsitehosting.net.  172800  IN      AAAA    2600:3c01::f03c:91ff:fe96:bbec

;; Query time: 22 msec
;; SERVER: 192.31.80.30#53(192.31.80.30)
;; WHEN: Thu Jun  1 09:42:51 2017
;; MSG SIZE  rcvd: 167


The information you are looking for is in the Additional section, and this shows that OP has been able to successfully add IPv6 glue records since their original post.

The important thing here is that YOU cannot add glue records simply by adding AAAA records to your domain's DNS.  This is something you need to handle through your domain registrar, and not all of them are capable of working with IPv6.  For example, my domains are through NameCheap -- two weeks ago I asked them to add glue records for two of my domains.  The .us domain was updated within a few hours, but I'm still waiting for the .net domain to be updated.  What you want to look for at your registrar's web site is the ability to add nameservers to your domain.  This is not the same as your registrar managing DNS records, this is something that should be directly within management of your domain.  In the case of NameCheap there is a tab for Advanced DNS, and under that it allows me to add new IPv4 nameservers by entering the domain (such as ns1.example.com) and IP address (the actual IP of my own DNS servers).  Some registrars may allow you to directly enter IPv6 records here, but NameCheap required me to submit a trouble ticket.  The nameservers you enter in this location are the same entries you will see when you perform a 'whois' on your domain.  Additionally, you can add nameservers from other domains.  In my case I had nameserver entries from both my .net and .us domain entered, so when HE tried checking my .net domain for IPv6 glue records, it successfully found the .us IPv6 glue records allowing me to pass the Sage test.

malcolmpdx

I'm in a similar situation and I've run out of things to try.

$ dig +short NS net.
i.gtld-servers.net.
c.gtld-servers.net.
f.gtld-servers.net.
b.gtld-servers.net.
m.gtld-servers.net.
k.gtld-servers.net.
l.gtld-servers.net.
j.gtld-servers.net.
e.gtld-servers.net.
g.gtld-servers.net.
d.gtld-servers.net.
a.gtld-servers.net.
h.gtld-servers.net.


; <<>> DiG 9.8.3-P1 <<>> @c.gtld-servers.net. -t NS indeterminate.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59682
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 10
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;indeterminate.net. IN NS

;; AUTHORITY SECTION:
indeterminate.net. 172800 IN NS ns.indeterminate.net.
indeterminate.net. 172800 IN NS ns4.he.net.
indeterminate.net. 172800 IN NS ns3.he.net.
indeterminate.net. 172800 IN NS ns2.he.net.
indeterminate.net. 172800 IN NS ns1.he.net.

;; ADDITIONAL SECTION:
ns.indeterminate.net. 172800 IN A 69.168.54.75
ns.indeterminate.net. 172800 IN AAAA 2001:470:a:501::2
ns4.he.net. 172800 IN AAAA 2001:470:400::2
ns4.he.net. 172800 IN A 216.66.1.2
ns3.he.net. 172800 IN AAAA 2001:470:300::2
ns3.he.net. 172800 IN A 216.218.132.2
ns2.he.net. 172800 IN AAAA 2001:470:200::2
ns2.he.net. 172800 IN A 216.218.131.2
ns1.he.net. 172800 IN AAAA 2001:470:100::2
ns1.he.net. 172800 IN A 216.218.130.2

;; Query time: 58 msec
;; SERVER: 192.26.92.30#53(192.26.92.30)
;; WHEN: Thu Jul 13 09:54:20 2017
;; MSG SIZE  rcvd: 347


; <<>> DiG 9.8.3-P1 <<>> @indeterminate.net -t NS indeterminate.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49830
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;indeterminate.net. IN NS

;; ANSWER SECTION:
indeterminate.net. 86400 IN NS ns1.he.net.
indeterminate.net. 86400 IN NS ns2.he.net.
indeterminate.net. 86400 IN NS ns3.he.net.
indeterminate.net. 86400 IN NS ns4.he.net.
indeterminate.net. 86400 IN NS ns.indeterminate.net.

;; ADDITIONAL SECTION:
ns.indeterminate.net. 86400 IN A 69.168.54.75
ns.indeterminate.net. 86400 IN AAAA 2001:470:a:501::2



; <<>> DiG 9.8.3-P1 <<>> @ns.indeterminate.net -t AAAA ns.indeterminate.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21077
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns.indeterminate.net. IN AAAA

;; ANSWER SECTION:
ns.indeterminate.net. 86400 IN AAAA 2001:470:a:501::2

;; AUTHORITY SECTION:
indeterminate.net. 86400 IN NS ns.indeterminate.net.
indeterminate.net. 86400 IN NS ns1.he.net.
indeterminate.net. 86400 IN NS ns2.he.net.
indeterminate.net. 86400 IN NS ns3.he.net.
indeterminate.net. 86400 IN NS ns4.he.net.

;; ADDITIONAL SECTION:
ns.indeterminate.net. 86400 IN A 69.168.54.75

;; Query time: 55 msec
;; SERVER: 69.168.54.75#53(69.168.54.75)
;; WHEN: Thu Jul 13 09:56:01 2017
;; MSG SIZE  rcvd: 171


The fact that the additional section only lists IPv4 A record for ns.indeterminate.net is due to the queries being done via ipv4 (cite: https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html "preferred-glue
If specified, the listed type (A or AAAA) will be emitted before other glue in the additional section of a query response. The default is to prefer A records when responding to queries that arrived via IPv4 and AAAA when responding to queries that arrived via IPv6."

But even with the above results, the certification tool complains that I don't have AAAA records for (at least?) one of my nameservers.  I'm out of ideas.

Any thoughts?

malcolmpdx

And, it turned out that the script is apparently checking if www.indeterminate.net is an AAAA NS.  removing the www. from the string fixed my issue.

Not to nitpick, but www in this case isn't a "subdomain".  You might want to look at changing the testing page to make this more clear.