From your OP it sounds like you couldn't find a good explanation of glue. FYI, here's a quick explanation of glue. Suppose this situation:
| Domain: | bar.org |
| Name servers for bar.org: | ns1 and ns2.bar.org |
| Host to look up: | foo.bar.org |
Here are roughly the steps a querying name server would take in the resolution process (leaving out some detail and intermediate steps, and presuming no cached entries):
| 1. | Name server queries a root name server for foo.bar.org (a list of root name servers is of course kept in the named.root or named.cache files). |
| 2. | Root name server returns NS records for .org Top Level Domain (TLD). |
| 3. | Name server queries .org name servers for foo.bar.org. |
| 4. | .org name server returns a list of name servers for bar.org (ns1 and ns2.bar.org).
Name server now has a conundrum: It needs to query ns1.bar.org or ns2.bar.org, but it doesn't have A or AAAA records (e.g. IP addresses) for either. But in order to get the IP addresses, it needs to query a name server for bar.org ... which it still doesn't have an IP address for. Endless loop. This is a circular dependency, or a "chicken vs. egg situation". The solution: Glue records. |
|
|
| 5. | The .org name server returns A and/or AAAA records for ns1.bar.org and/or ns2.bar.org. Note carefully that these are host records that should only be living in the bar.org domain's name servers, but the .org name server is actually returning them. These are called glue records. It provides the informational glue between a parent and child domain, gluing them together, if you will, thus solving the circular dependency. |
| 6. | Name server queries ns1 or ns2.bar.org for the A or AAAA for foo.bar.org. |
Note that the info need
not be in a TLD name server to be considered glue. Glue is required in any domain for which this circular dependency exists. For instance, in the above example, if you replace the host "foo.bar.com" with "baz.foo.bar.com", and the NS for the domain "foo.bar.com" is "ns.foo.bar.com", then the "bar.com" name server must list an A or AAAA (glue) record for the NS "ns.foo.bar.com" for resolution to succeed.
Now, as far as the sage test goes, I'm not sure how it differs from that above definition/explanation. Broquea
did say that the name server could be out of
bailiwick, which means that it doesn't have to be under the "eu.org" domain in your case. So I believe that means that the test script enumerates a list of name servers for your domain, and that one of those servers must have IPv6 glue records in its parent domain's name servers. I'm not sure if this parent domain
must be a TLD or not. Whether it enumerates the list of name servers by directly calling the TLD name servers, or whether it does it with a normal recursive query is the question here. If the former, then it means that your domain must be a second level domain, since the TLD servers wont have any information about subdomains of second-level domain (i.e. xyz.eu.org). If the latter, it means that you just need to get IPv6 glue for your subdomain's name servers on your parent domain's name severs and you're golden. In other words, if this is true, you need to get an AAAA record for your name server (say, ns.xyz.eu.org) onto the name servers for "eu.org".
I notice that the "eu.org" domain
does have an IPv6 name server called "ns-v6.eu.org", and that this server
does have an IPv6 AAAA glue record on the ".org" name servers. So, it may be possible to list "ns-v6.eu.org" as a name server for your domain (which I believe would technically be an "out of bailiwick" situation?), if you can get the eu.org people to be a secondary (slave) NS for your subdomain.
Actually, I'm not even sure if the HE sage test script will even attempt to query that name server. It may be happy simply seeing an NS record for your domain which has IPv6 glue in its parent domain's name servers, period. But that'd be a bit of a cheat, IMHO.
Hope this helps.
Author
Topic: Adding "glue" to BIND (Read 20612 times)