Print

[snarked]

OK, so why am I failing?

To complete the Guru Test you will need: ...

Help Step Description Data
* 1 If you need to edit off any subdomains to make it work do so here: snarked.org 
* 2 Check to see that the nameservers associated with www.snarked.org/ have IPv6 AAAA's
      Success
* 3 Check to see that the nameservers associated with www.snarked.org/ are IPv6 accessible
      Couldnt query name server

From the looking glass (Los Angeles POP):

Sending 1, 16-byte ICMPv6 Echo to 2607:f350:1::1:1
timeout 5000 msec, Hop Limit 64
Reply from 2607:f350:1::1:1: bytes=16 time<1ms Hop Limit=63
Success rate is 100 percent (1/1), round-trip min/avg/max=0/0/0 ms.

Dig reveals that the server is there, etc:

;; QUESTION SECTION:
;snarked.org.                   IN      NS

;; ANSWER SECTION:
snarked.org.            172800  IN      NS      ns.snarked.org.
... + other servers (all IPv4 only).

;; ADDITIONAL SECTION:
ns.snarked.org.         172800  IN      AAAA    2607:f350:1::1:1
ns.snarked.org.         172800  IN      A       ...

;; Query time: 7 msec
;; SERVER: 2607:f350:1::1:1#53(2607:f350:1::1:1)
;; WHEN: Wed Jan 14 21:03:37 2009
;; MSG SIZE  rcvd: 311

So why is this failing?
The AAAA record is returned.  (Step 2 - Success)
The IPv6 is reachable (the ping).  (Step 3 - FAIL???)
The name server replies on the IPv6 given address.  (Step 3 - FAIL???)

It's not a routing problem - as it's even reachable from sixxs.org in europe:

IPv6 traceroute from noc.sixxs.net @ SixXS NOC, AS12871 to 2607:f350:1::1:1 :

Hop  Node                         Loss%  Sent   Last   Avg  Best Worst StDev       ASN        Organisation
  1. 2001:838:1:1::1               0.0%     5    0.5   0.5   0.4   0.5   0.0     12871      Concepts ICT
     ge-1-3-0.breda.ipv6.concepts-ict.net.
  2. 2001:838:0:10::1              0.0%     5    2.5   2.5   2.4   2.8   0.1     12871      Concepts ICT
  3. 2001:838:5:4::2               0.0%     5    2.6   4.1   2.3  10.3   3.5     12871      Concepts ICT
  4. 2001:7f8:1::a500:6939:1       0.0%     5    2.9   3.0   2.9   3.3   0.2                AMS-IX-IPV6
     ams-ix.he.net.
  5. 2001:470:0:3f::1              0.0%     5   10.8  10.9  10.7  11.1   0.2     6939       Hurricane Electric
     10gigabitethernet1-4.core1.lon1.he.net.
  6. 2001:470:0:3e::1              0.0%     5   79.7  80.5  79.7  83.3   1.6     6939       Hurricane Electric
     10gigabitethernet2-3.core1.nyc4.he.net.
  7. 2001:470:0:36::1              0.0%     5   85.8  85.9  85.8  86.0   0.1     6939       Hurricane Electric
     10gigabitethernet2-3.core1.ash1.he.net.
  8. 2001:470:0:3b::1              0.0%     5  120.9 121.4 120.9 122.4   0.6     6939       Hurricane Electric
     10gigabitethernet1-1.core1.dal1.he.net.
  9. 2001:470:0:3a::1              0.0%     5  154.3 154.1 153.9 154.4   0.2     6939       Hurricane Electric
     10gigabitethernet1-2.core1.lax1.he.net.
 10. 2001:470:1:1b::2              0.0%     5  154.3 154.4 154.2 154.7   0.2     6939       Hurricane Electric
 11. 2607:f350:1::1:1              0.0%     5  154.2 154.2 154.2 154.4   0.1     27630      Premier Innovations, LLC
     ns.snarked.org.

It's not a firewall problem.  IP6tables indictates packets received (ip6tables -v -L):

   89  8148 ACCEPT     udp      any    any     anywhere             ns.snarked.org/128  udp spts:1024:65535 dpt:domain
    0     0 ACCEPT     tcp      any    any     anywhere             ns.snarked.org/128  tcp spts:1024:65535 dpt:domain
    0     0 ACCEPT     tcp      any    any     anywhere             ns.snarked.org/128  tcp spt:domain dpt:domain
    0     0 ACCEPT     udp      any    any     anywhere             ns.snarked.org/128  udp spt:domain dpt:domain

The packet count on the first rule does increase when I execute the test.

   90  8230 ACCEPT     udp      any    any     anywhere             ns.snarked.org/128  udp spts:1024:65535 dpt:domain

Your query is 82 bytes.  An EDNS0 reply of 553 bytes is generated to your query.  I don't know why you're getting a longer reply.

IN= OUT=eth0 SRC=2607:f350:0001:0000:0000:0000:0001:0001 DST=2001:0470:0000:0064:0000:0000:0000:0002 LEN=553 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=53 DPT=45548 LEN=513

BTW, dig query for www.snarked.org

; <<>> DiG 9.6.0-P1 <<>> www.snarked.org aaaa @2607:f350:1::1:1
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26102
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 11, ADDITIONAL: 2

;; QUESTION SECTION:
;www.snarked.org.               IN      AAAA

;; ANSWER SECTION:
www.snarked.org.        172800  IN      AAAA    2607:f350:1::1:2

;; AUTHORITY SECTION:
snarked.org.            172800  IN      NS      ns.snarked.org.
... + 10 others.

;; ADDITIONAL SECTION:
ns.snarked.org.         172800  IN      AAAA    2607:f350:1::1:1
ns.snarked.org.         172800  IN      A       ...

;; Query time: 6 msec
;; SERVER: 2607:f350:1::1:1#53(2607:f350:1::1:1)
;; WHEN: Wed Jan 14 21:17:15 2009
;; MSG SIZE  rcvd: 343

Are you getting a truncated reply and not re-querying via TCP?

Additional:  There is an IPv6 glue record at the parent's servers:

; <<>> DiG 9.6.0-P1 <<>> snarked.org ns @a0.org.afilias-nst.info.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10765
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;snarked.org.                   IN      NS

;; AUTHORITY SECTION:
snarked.org.            86400   IN      NS      ns.snarked.org.
... +10 other servers

;; ADDITIONAL SECTION:
... 4 IPv4 glue records, then:
ns.snarked.org.         86400   IN      AAAA    2607:f350:1::1:1

;; Query time: 32 msec
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Wed Jan 14 21:51:38 2009
;; MSG SIZE  rcvd: 359

[broquea]

Ah, the trailing "/" that was entered at Enthusiast is screwing it up.
It was trying to do: dig AAAA www.snarked.org/ @2607:f350:1::1:1 +short

I removed it from the DB, please retest.

[snarked]

I think that did the trick.  When the test asked me for the web site, I entered a full URL (I think), and your system stripped off the leading "http://" but not the trailing "/".  I'm now on a screen that's asking questions.

[broquea]

I think that did the trick.  When the test asked me for the web site, I entered a full URL (I think), and your system stripped off the leading "http://" but not the trailing "/".  I'm now on a screen that's asking questions.

Awesome, and thanks for bringing this up. I'm going through and removing any trailing "/" for other people.

[snarked]

This part concerns me - IPv6 Glue Test:

NS Records: ns.snarked.org.
-TLD: org
-Server: d0.org.afilias-nst.org.
-Output: No Record
-Server: a0.org.afilias-nst.info.
-Output: No Record
-Server: b0.org.afilias-nst.org.
-Output: No Record
-Server: c0.org.afilias-nst.info.
-Output: No Record
-Server: a2.org.afilias-nst.info.
-Output: No Record
-Server: b2.org.afilias-nst.org.
-Output: No Record

However, as noted 4 posts above, "a0.org.afilias-nst.info" did in fact return an IPv6 glue record when queried (in the additional section where it belongs).  I've checked and the other .ORG servers also return it.  Yet, your test is saying "No Record"?

The test is correct for my other servers as they are IPv4 only.  I note the other comments regarding this issue - so I'll try again in 48+ hours to see if it were a caching problem.

[broquea]

dig aaaa ns.snarked.org @a0.org.afilias-nst.info +short

I don't get an answer, and we aren't considering Additional an answer, as it isn't a host record the TLD has, but rather reaching out to the NS in Authority and asking.

I'm still looking into this, because it makes no sense why registering with someone like GoDaddy (or other places, but I use them) for .com and .net get glue (host records in the TLDs) and .org doesn't even seem to do this with ipv4, which would be a .org TLD thing and probably not the registrar.

Not sure why .ORG TLDs don't reply for either IPv4/6 host records, unless they do some whacky internal referencing just to fill in the AUTHORITY section which then fills in ADDITIONAL. I suppose I'll send an email in hopes of a reply for an answer from them.

Last edit for a while, I've emailed pir.org directly asking them about glue etc. If/when I get a reply, hopefully that will either resolve issues, or at least give us better direction for testing .ORG domains for glue. Until then .COM and .NET do not appear to have issues and should get to Sage.

[snarked]

Well, where would you expect glue records to be in an DNS reply?

I agree with them that it should be in the additional section - because the parent is NOT authoritative for the domain's zone itself.  Only the domain's own servers have authoritative answers - and when they get queried (reached there by the additional glue), the authoritative answers will replace the additional (glue)answers in the cache.  The parent zone is authoritative for the names of the domain's servers - because that's delegation.  I believe that there's a problem with non-authoritative answers vs. additional data accompanying authoritative answers - which one should have priority in the cache?  I don't recall offhand what the RFCs say about this, but what they do say will imply whether HE's method for the test is correct or not.

You seem correct in that the .com/.net servers do seem to return an answer (as an answer with the authority bit off) when queried for a glue record while .org doesn't.  .info and .name seem to act the same as .org, while .edu is like .com and .net (because all 3 of the latter are using the same 13 servers).

What .org and the others like it are doing are issuing a REFERRAL type answer.  I don't see that as wrong.  Glue records at the parent are not authorative - and the source of glue is from the domain registration - outside of DNS.  I believe that your assumption that a parent-zone (TLD) server can be queried for glue and return a non-referral answer universally is wrong.  It "happens to work" for a few (at least 3 TLDs).

I note that the ROOT servers (*.root-servers.net) act like .org/.info/.name with respect to NOT putting glue in the answer section - and they supposedly run a modified version of BIND.  Perhaps the variation of answers is due to the software the name servers for the TLDs use.

[snarked]

RE - URL:  http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-03

Section 3. "Terms":
It is clear that "glue" records are expected to be in the additional section of a DNS response - ONLY.

Granted, it is only a draft of a potential BCP-type RFC, it still states the expectations - and such are inconsistent with the way HE is performing the glue record test.

Section 6.2. - A precise demonstration of the problem.  Some implementations will answer with the glue while others will create only a referral answer.  The latter might answer with the glue (as a non-referral) only if the answer is already cached.

I think that this makes it clear:  HE must check for glue in the "additional" section of an "NS" querytype and pass those that return reachable addresses via AAAA records.  The queries for direct answers from the parent zone's servers are a red herring that can generate false negatives.

[broquea]

Yup, this was discussed at length over the weekend. We've modified it so we can also examine ADDITIONAL and made sure that no recursion is happening. If you are at Guru with a .org, try for Sage and please see if it completes now.

I'm still curious as to why the difference in replies when comparing .edu/com/net to .org, so hoping for a reply form pir.org but not holding my breath.

[snarked]

Well, that did it.  Using my .org, I was successfully promoted from Guru to Sage.  Can anyone out there with a .info or .name (or another TLD not recently mentioned) confirm the same?

[broquea]

Well, that did it.  Using my .org, I was successfully promoted from Guru to Sage.  Can anyone out there with a .info or .name (or another TLD not recently mentioned) confirm the same?

Speaking of which, what is the current list/count of TLDs that support ipv6 glue?

[snarked]

Just checked at Go-Daddy (the largest registrar):

.INFO - Yes.  This is recent.
.NAME - No.

(.COM, .NET, and .ORG supported in 2008).

[haundh]

.CX (Christmas Island) supports IPv6 glue in the Additional section. The Sage test works for me now with your change. Thanks!