Hello! I am trying to perform the Guru DNS tests, and it seems to be failing, even though my authoritative DNS servers are IPv6 enabled and have AAAA records for them.
When I perform the test, it immediately bounces back with Couldn't get AAAA for NS. It would be very helpful if it produced a little more output so that maybe I could figure out what is going on. Everything seems OK here, and I can see everything using dig from several networks.
I am trying to test neillt.com... here is some dig output from my end, querying my upstream Time Warner Business Class DNS servers...
$ dig neillt.com any
; <<>> DiG 9.4.2-P2 <<>> neillt.com any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6407
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; QUESTION SECTION:
;neillt.com. IN ANY
;; ANSWER SECTION:
neillt.com. 30039 IN NS xen-server.neillt.com.
;; AUTHORITY SECTION:
neillt.com. 30039 IN NS xen-server.neillt.com.
;; ADDITIONAL SECTION:
xen-server.neillt.com. 30039 IN A 67.52.144.205
xen-server.neillt.com. 30039 IN AAAA 2001:470:1f05:216:21c:c0ff:fe77:64b4
;; Query time: 21 msec
;; SERVER: 66.75.160.15#53(66.75.160.15)
;; WHEN: Sun Nov 23 08:56:47 2008
;; MSG SIZE rcvd: 111
I also looked at what is coming across from my AT&T Cell Data card...
Neill:~ neillt$ dig neillt.com any
; <<>> DiG 9.4.2-P2 <<>> neillt.com any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34408
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;neillt.com. IN ANY
;; ANSWER SECTION:
neillt.com. 172731 IN NS dns2.thorconsulting.org.
neillt.com. 172731 IN NS xen-server.neillt.com.
;; AUTHORITY SECTION:
neillt.com. 172731 IN NS xen-server.neillt.com.
neillt.com. 172731 IN NS dns2.thorconsulting.org.
;; ADDITIONAL SECTION:
xen-server.neillt.com. 172731 IN A 67.52.144.205
xen-server.neillt.com. 172731 IN AAAA 2001:470:1f05:216:21c:c0ff:fe77:64b4
;; Query time: 142 msec
;; SERVER: 209.183.54.151#53(209.183.54.151)
;; WHEN: Sun Nov 23 09:05:04 2008
;; MSG SIZE rcvd: 162
And just in case it's the secondary DNS server record screwing it up there... here is the dig for that server.
; <<>> DiG 9.4.2-P2 <<>> dns2.thorconsulting.org any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26843
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;dns2.thorconsulting.org. IN ANY
;; ANSWER SECTION:
dns2.thorconsulting.org. 3600 IN A 67.52.144.204
dns2.thorconsulting.org. 3600 IN AAAA 2001:470:1f05:216:21c:c0ff:fe77:64b4
;; AUTHORITY SECTION:
thorconsulting.org. 3600 IN NS ns17.domaincontrol.com.
thorconsulting.org. 3600 IN NS ns18.domaincontrol.com.
;; ADDITIONAL SECTION:
ns17.domaincontrol.com. 8877 IN A 216.69.185.9
;; Query time: 2189 msec
;; SERVER: 209.183.54.151#53(209.183.54.151)
;; WHEN: Sun Nov 23 09:05:54 2008
;; MSG SIZE rcvd: 156
If anyone has any clue on what might be screwing this up, I am all ears. To be honest, I don't know what it is.
From those 3 digs, the NS records in the authority section differ.
dig @A.GTLD-SERVERS.NET ns neillt.com
; <<>> DiG 9.4.2-P2 <<>> @A.GTLD-SERVERS.NET ns neillt.com
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29925
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;neillt.com. IN NS
;; ANSWER SECTION:
neillt.com. 172800 IN NS dns2.thorconsulting.org.
neillt.com. 172800 IN NS xen-server.neillt.com.
;; ADDITIONAL SECTION:
xen-server.neillt.com. 172800 IN A 67.52.144.205
xen-server.neillt.com. 172800 IN AAAA 2001:470:1f05:216:21c:c0ff:fe77:64b4
One NS appears to have ipv6 glue if I read this correctly...
QuoteOne NS appears to have ipv6 glue if I read this correctly...
I believe that ALL name servers must have IPv6 addresses in order to pass the test.
Well, I didn't change a thing, and just tried re-running the test today. Worked just fine, and I am all the way to Sage now.
Maybe something was cached on a DNS server somewhere that wasn't right.... ???
It would be nice to hear from the test designer.
An earlier poster suggested that there had to be glue records for ALL of your NSs in order to pass. Maybe that's no longer true (seems unrealistic at this point). There is no glue AAAA record for dns2.thorconsulting.org (in fact, there's no IPv4 glue record, either; see below). To see the output showing what it needs to look like if there really is a glue record try "host -ra speakup.octothorp.org c0.org.afilias-nst.info". You need to go directly to the root server for the proper TLD of the NAME SERVER (not the domain itself), and it's best to shut off recursion.
If the earlier poster WAS correct, then it appears that the test has been changed to only require ONE NS to actually have AAAA glue.
/john
$ host -ra dns2.thorconsulting.org c0.org.afilias-nst.info
Trying "dns2.thorconsulting.org"
Using domain server:
Name: c0.org.afilias-nst.info
Address: 2001:500:b::1#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50482
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;dns2.thorconsulting.org. IN ANY
;; AUTHORITY SECTION:
thorconsulting.org. 86400 IN NS ns18.domaincontrol.com.
thorconsulting.org. 86400 IN NS ns17.domaincontrol.com.
Received 96 bytes from 2001:500:b::1#53 in 111 ms
Quote from: jrcovert on December 28, 2008, 10:05:37 PM
If the earlier poster WAS correct, then it appears that the test has been changed to only require ONE NS to actually have AAAA glue.
Yes, the Sage/glue test only needs 1 name server to have IPv6 glue. The issue was earlier we were still using a database of TLD servers that wasn't up to date. We no longer do that.
Now it's my turn to ask if there isn't still a bug with this test.
I transferred my domain to a registrar who would let me set up IPv6 glue myself, and I created the glue for ns1.covert.org:
$ host -ra ns1.covert.org a0.org.afilias-nst.info
Trying "ns1.covert.org"
Using domain server:
Name: a0.org.afilias-nst.info
Address: 2001:500:e::1#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34860
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 3
;; QUESTION SECTION:
;ns1.covert.org. IN ANY
;; AUTHORITY SECTION:
covert.org. 86400 IN NS ns2.easydns.com.
covert.org. 86400 IN NS remote2.easydns.com.
covert.org. 86400 IN NS ns1.easydns.com.
covert.org. 86400 IN NS ns1.covert.org.
covert.org. 86400 IN NS remote1.easydns.com.
covert.org. 86400 IN NS ns3.easydns.org.
covert.org. 86400 IN NS mejac.palo-alto.ca.us.
;; ADDITIONAL SECTION:
ns1.covert.org. 86400 IN A 72.93.205.54
ns1.covert.org. 86400 IN AAAA 2001:470:8944:0:20d:93ff:fe3e:52
92
ns3.easydns.org. 86400 IN A 209.200.177.4
Received 258 bytes from 2001:500:e::1#53 in 428 ms
------
I waited nearly 48 hours to be sure caches were flushed.
Domain: covert.org
Domains TLD: org
NS Records: ns1.covert.org.
-TLD: org
-Server: c0.org.afilias-nst.info.
-Output: No Record
-Server: b2.org.afilias-nst.org.
-Output: No Record
-Server: d0.org.afilias-nst.org.
-Output: No Record
-Server: a2.org.afilias-nst.info.
-Output: No Record
-Server: b0.org.afilias-nst.org.
-Output: No Record
-Server: a0.org.afilias-nst.info.
-Output: No Record
Ooops? What's wrong?
Thanks/john
Looks like its working...
dig @a0.org.afilias-nst.info covert.org ns
; <<>> DiG 9.4.2-P2 <<>> @a0.org.afilias-nst.info covert.org ns
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11287
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;covert.org. IN NS
;; AUTHORITY SECTION:
covert.org. 86400 IN NS ns1.covert.org.
covert.org. 86400 IN NS ns1.easydns.com.
covert.org. 86400 IN NS ns2.easydns.com.
covert.org. 86400 IN NS ns3.easydns.org.
covert.org. 86400 IN NS mejac.palo-alto.ca.us.
covert.org. 86400 IN NS remote1.easydns.com.
covert.org. 86400 IN NS remote2.easydns.com.
;; ADDITIONAL SECTION:
ns1.covert.org. 86400 IN A 72.93.205.54
ns3.easydns.org. 86400 IN A 209.200.177.4
ns1.covert.org. 86400 IN AAAA 2001:470:8944:0:20d:93ff:fe3e:5292
;; Query time: 155 msec
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Sun Jan 4 12:52:08 2009
;; MSG SIZE rcvd: 258
TLD servers do not answer for host records when queried directly, which is the test. ADDITIONAL isn't a trusted answer for this test.
dig AAAA nameserver @tldserver +short
works for HE: dig aaaa ns2.he.net @B.GTLD-SERVERS.net +short (Network Solutions registered)
works for me personally: dig aaaa ns1.deus-exmachina.net @M.GTLD-SERVERS.net. +short (GoDaddy registered)
Whoa! It's my understanding that ORG only returns the glue records
in the additional section, and it does it this way whether they are
A or AAAA records.
Note that I explicitly requested "no recursion" (which a TLD server
wouldn't have done anyway, so it wouldn't have been cached from a
previous request, and thus nothing in the additional section COULD
have come from any non-authoritative location).
And besides, the whole point of returning the A and AAAA records for
name servers in the additional section is for efficiency's sake, so
that you get what you want with a single query for the NS records
to the TLD server.
Here's a screen shot of how I set it up in the domain manager last
Friday morning. http://www6.covert.org/ipv6_glue.jpg
/john
Quote from: yozh on January 12, 2009, 06:33:42 PM
So for the guru test the register has to support AAAA records ? Or can the name servers just have the records ? My domain yozh.us has the servers for the AAAA but not the tld servers. DO I have to find a new register ?
For guru, we first look up the NS for your domain: dig +short NS $website
Then we ask for AAAA records: dig +short AAAA $ns_entry
Then for part 2, we query the NS' IPv6 address for the website: dig AAAA @$AAAA_record $website +short
Having an IPv6 host record in the TLD server (dig AAAA $ns_entry @TLD +short) isn't until Sage testing.
OK, but using "$website" for both parts may not work - thus fail domains that are properly reachable.
$ORIGIN example.com.
@ IN SOA etc...
NS whatever (assume IPv6 address exists).
NO A or AAAA record.
www IN AAAA whatever.
No NS records.
Such a domain, properly set up, will fail your test because both parts of the test, although individually passing, will never be done together.
The DOMAIN (or zone cut) will have the NS records.
The HOSTNAME www under the domain is the web server.
Testing "example.com" passes the DNS but fails the web server part.
Testing "www.example.com" fails the DNS but passes the web server part.
Not everyone puts an address record at the domain's/zone's apex.
Spooky. I made this exact comment when the certs started, and had issues because I don't A/AAAA/CNAME the actual domain itself, just hosts on it :)
Ok I was perhaps too generic about $website.
If you entered www.example.com to test your website at Enthusiast, at Guru, you can set the edited domain to example.com.
Then it looks up the NS for example.com
Then it looks up the AAAA for those NS.
Then it queries the IPv6 address of the NS, for the AAAA of www.example.com, not example.com.
Unless all you entered was "example.com" at enthusiast, it won't query for a subdomainless hostname.
OK, so why am I failing?
QuoteTo 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):
QuoteSending 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:
Quote;; 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:
QuoteIPv6 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):
Quote89 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.
Quote90 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.
QuoteIN= 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
Quote
; <<>> 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:
Quote; <<>> 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
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.
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.
Quote from: snarked on January 14, 2009, 02:05:09 PM
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.
This part concerns me - IPv6 Glue Test:
QuoteNS 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.
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.
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.
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.
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.
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?
Quote from: snarked on January 20, 2009, 03:01:51 AM
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?
Just checked at Go-Daddy (the largest registrar):
.INFO - Yes. This is recent.
.NAME - No.
(.COM, .NET, and .ORG supported in 2008).
.CX (Christmas Island) supports IPv6 glue in the Additional section. The Sage test works for me now with your change. Thanks!