DNS/用語/glue/Arendsについて、ここに記述してください。

https://www.ietf.org/mail-archive/web/dnsop/current/msg07881.html

1. GLUE RECORDS

The concept of glue records (address records such as A and AAAA) exists _solely_ in zones and are related to delegations. The term is not used to refer to address records that appear in DNS requests and responses. Glue records are useful to a resolver so it can locate the delegated nameserver. I'll try to explain the terminology involved and the process of determining which records are called glue. Glue addresses are related to delegation point NS records.

We need three properties of a delegation point NS record to determine if an associated address is glue:

All these properties are fully qualified domain names.

We can describes 4 classes of NSDNAME:

An NSDNAME is the hostname of the nameserver. Nameservers’ addresses are stored in A or AAAA records. If NSDNAME is of class 1 or 2, the corresponding addresses are NOT glue. In class 1, the addresses are not even in the zonefile. In class 2, the addresses are in the zone, and are authoritative data. Note that for the root zone, class 1 simply does not exist, since the entire dns tree are subdomains of root.

If NSDNAME is in class 3 or 4, the corresponding addresses are glue addresses.

2. GLUE TYPES

In class 3 (’in-bailiwick’) it is required to have that address in the zone. As an example, assume the following NS record:

The alpha.tld zone resides on nameserver ns1.alpha.tld. A resolver can’t reach alpha.tld without the address of ns1.alpha.tld. To resolve ns1.alpha.tld, it needs to reach alpha.tld. To route around this chicken and egg problem, the tld zone needs to have an address for ns1.alpha.tld. So, class 3 ‘in-bailiwick’ requires glue. We call this glue ‘in-bailiwick glue’.

In class 4 (’sibling’), it is not required to have that address in the zone, unless there are circular dependencies. As an example of a circular dependency, assume the following NS records:

The ‘foo’ and ‘bar’ delegation have a circular dependency. Foo resides on a server under bar, bar resides on a server under foo. A resolver can’t reach foo without the address for ns1.bar which is in the bar zone, and it can’t reach bar without the address of ns1.foo which is in the foo zone. Hence the ‘tld’ zone needs, in this specific case, address records for both ns1.foo and ns1.bar. Note that circular depenency graphs can be complex, and paths in the graph can be long. A resolver will more than likely have measures against looping and long path lengths.

3. Orphan Glue Phenomenon

An interesting phenomenon occurs when a delegation NS record set is removed from the zone while the glue records that reside under it, are not removed. These glue records are now class 2 (authoritative) records. We call these addresses 'orphan glue' records, though they are not glue anymore (they've been adopted)

4. DNSSEC and Glue

Glue addresses are not signed. They are supposed to be signed in the zone that is authoritative for the address record. They also do not appear in NSEC or NSEC3 chains. However, when glue addresses become orphan (see 'orphan glue phenomenon') they are now authoritative data, and subsequently need to be signed.

5. Wide and narrow glue policy.

These policies determine what types of glue (class 3 or class 4) are allowed in a zone.

Wide glue policy allows both class 3 (in-bailiwick glue) and class 4 (sibling glue) to be registered in the zone. Narrow glue policy allows class 3 only. A combination of the two policies ‘case-by-case policy’ exists where sibling glue is only registered to avoid circular dependencies.

The dependency problem exists not only with missing glue. It can be that foo.tld resides on a nameserver ‘ns1.cow.moo’ and ‘cow.moo’ resides on a nameserver ‘ns1.foo.tld’. Both the moo and tld registries are not allowed (by dns-protocol) to serve off-tree addresses. So, while gluelessness can be avoided for class 4, it can not be avoided for class 1.

Kind regards,

Roy Arends Sr Researcher Nominet UK