Glue Record Search Recommendation

[BlueMatt]

Although it is important for nameservers to have IPv6 "glue" upstream to allow dns to be executed fully via IPv6, however for nameservers that are on a different TLD than the domain for which they are answering a query and do not have any glue at the TLD for which they are being queried, it is still possible for a domain to be queried entirely using IPv6.  

Take my domain for example, although it is a .me, its nameservers are .us.  The nameservers have no glue in the .me authoritative servers (IPv6 or v4), and don't even have any glue in the .us authoritative servers.  However, they can be looked up using IPv6 only (their nameservers have IPv6 glue) and can be queried using IPv6.  

Thus I believe the DNS Glue Search should be amended to allow for DNS Servers which are from a different domain, and still allow full resolution using IPv6.

Although maybe I'm being thick and am misunderstanding the reason for this test (probably more likely).

Either way, thanks for the great FREE service HE.

[patrickdk]

at some point along the line, one of the servers will need glue.

In your example, if I lookup a .me domain, I will get redirected to the .us server, I will then restart the dns request to lookup the .us server, using the glue for the .us server. If the .us server doesn't serve itself, then I would instead not get glue, but be redirected a 2nd time and start over. I will then lookup that new tld, (.com for example), and get glue for that server in .com, hopefully not getting redirected again, as each time causes things to get slower and slower.

[BlueMatt]

Sadly, you example is similar to what my DNS is :(.  
Yes you are right, at some point there has to be glue, but assuming the test was meant to test for full resolution of DNS using only IPv6 the test should support testing for glue at any point.

[snarked]

It's clear to me that the OP doesn't understand what glue is.  It's not the mere presence of an address record for a name server.

A glue record is an address record for a name server's label which is a subzone of the current zone.

If a label is not a subzone of the current zone, its address record will not a glue record.

[BlueMatt]

OK, thanks for clearing that up, however that does not change anything, at some point in the chain glue record will have to exist, and if the test is really designed to test whether the DNS for a domain is resolvable using IPv6, it should test for glue at any point and then the reachability of subsequent nameservers. 

[snarked]

Glue records, other than for the DNS root, do not have to exist.

[BlueMatt]

As the earlier example pointed out, for individual domains, glue records do not have to exist, but at some point a glue record has to point from one level to the next.  Take this example:

look up example.com.
Need a bind "hint" file for the root.
1.  a.root-servers.net responds with a.gtld-servers.net.  Assuming glue is required only from root servers we are given an IP.
2.  a.gtld-servers.net responds with a hostname say ns.a.com, assuming no glue is required we start over.
  2a. .com is cached as a.gtld-servers.net
  2b. a.gtld-servers.net responds with a hostname, assuming no glue is required we start over...

This can happen over and over again until a dns server gives up.  Although glue was not required originally, it will eventually be required to get to the next step.

[BlueMatt]

Now that that is cleared up, does it sound like a good idea to amend the test to allow domains which have no glue for themselves, but are fully resolvable via IPv6?

[snarked]

BlueMatt:  Your understanding of the resolver process is wrong.

Target:  X.example.com.  example.com is served by ns.example.net, which does NOT serve example.net.

Query starts at the root.
Root, where glue is required (since everything is under it), has a hints file with the glue and NS records defining *.root-servers.net, so the addresses for those "13" servers are always available.

Query for ".com" - gets "*.gtld-servers.net" NS records.
 - Subquery for ".net" - gets "*.gtld-servers.net" NS records and their glue.
Query for "example.com" - gets "ns.example.net" NS record.
 - Subquery for "example.net" - gets NS records (from cached "*.gtld-servers.net" records for ".net").
    - Subquery for those NS records, eventually resolves.
 - Subquery for "ns.example.net" - gets address record(s) - not glue.
Query for "x.example.com" - gets final answer.

Note that I did not say that glue doesn't exist elsewhere.  I only said that it is required to exist for the DNS root and that it's not required elsewhere, but that's not the same as saying it's forbidden elsewhere.

GLUE records exist ONLY where the label is UNDER the zone it is listed under.  An address record for a name server included in the additional section of a DNS response is not glue when such is not met.

[BlueMatt]

Yes, glue is not required for all domains, in fact most domains don't have glue, however your line
- Subquery for those NS records, eventually resolves.
will not resolve if no glue exists anywhere but root.

When looking up the ns servers for example.net, we can start your queries all over, but with different TLDs. It will continue to spawn sub queries until the dns resolver gives up, or some nameserver has glue. 
Here is an example using my domain bluematt.me

1. We have a hints file so we lookup @ *.root-servers.net bluematt.me and get ns.nic.me, ns2.nic.me...Here we have glue so we continue
1a. We lookup @ ns.nic.me bluematt.me and get ns*-auth.rollernet.us. We have no glue so we have to start over with rollernet.us
  1ai. We lookup @*.root-servers.net ns*-auth.rollernet.us and get *.cctld.us.  Once again we are given glue, so we move on.
  1aii. We lookup @*.cctld.us ns*-auth.rollernet.us and get ns*-i.rollernet.us, ns3-i.rollernet.net.  Although here we are actually given glue, lets assume we are not. Because we cannot continue for ns*-i.rollernet.us, we have to start again on ns3-i.rollernet.net.
   1aii,a. We lookup @*.root-servers.net ns3-i.rollernet.net and get *.gtld-servers.net.  Because we are given glue we can continue.
   1aii,b. We lookup @*.gtld-servers.net ns3-i.rollernet.net and get ns*-i.rollernet.us, ns3-i.rollernet.net.  Without glue we simply could not continue here.  However, we could point our namservers elsewhere and continue this chain.

This chain can continue for ever without resolving.  Without glue at some point in the chain we will have to eventually give up.  Because without glue we will never be able to resolve the namserver.  If at any point in the chain (before recursive nameservers start timing out or maxing the number of subqueries allowed) a nameserver has glue at its parent servers, we can continue and resolve the whole chain. 

Your example simply is this chain but your "eventually resolves" will not resolve unless a nameserver somewhere has glue. 

This whole talk of glue, however has brought this topic way off track.  Whether glue is required or not is irrelevant as to whether the test should be amended to allow for domains who do not have glue for themselves but are still fully resolvable via ipv6.

[patrickdk]

Ya, what he is saying, currently the test checks if your domain you entered has glue or not, directly, and not via indirect route.

so my domain, patdk.us has direct glue, and passes the test. But if I used a dns server outside of the .us domain, it wouldn't have glue, and fail.

Or I think that is how the test currently works, I don't believe I could get my domain to work before I setup local glue.

[snarked]

That's correct.  The glue test only looks to see if you have glue for your domain and doesn't care about any other glue record.

Except for the root zone itself (including the TLDs and their name servers), it's possible to resolve a label without glue for any lower zone.

[broquea]

More specifically, the domain the authoritative NS are in, be they of the same domain or out of bailiwick.

[BlueMatt]

So I guess the question is, should the test ultimately test for full DNS resolvability via IPv6, or should it continue to test for glue?
I guess thus the question is, do we care whether the client is running their own nameservers (and have IPv6 support with glue) or if it is acceptable to use a 3rd part nameserver (or nameservers on another domain) that are resolvable via IPv6?

[broquea]

I'm still trying to figure out what question remains...

The guru stage tests that the authoritative NS listed for $SUBMITTED_URL have IPv6 addresses and can be queried over IPv6 on that address and provide an answer when asking for the AAAA of $SUBMITTED_URL.

The sage test checks, via IPv6, if the TLDs, for the domain those authoritative NS are in, can provide the v6 addresses for those NS (usually found in the ADDITIONAL section of a dig query for example).