DNS/グルーレコード/surveyについて、ここに記述してください。

DNS Glue RR Survey and Terminology Clarification

• http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-04

../arpa

Table of Contents

   1.          Introduction . . . . . . . . . . . . . . . . . . . . .  3
   2.          RFC Survey . . . . . . . . . . . . . . . . . . . . . .  3
   3.          Terms  . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.          Name Server Naming Strategies  . . . . . . . . . . . .  4
   5.          Glue Policies  . . . . . . . . . . . . . . . . . . . .  5
   6.          Open Issues  . . . . . . . . . . . . . . . . . . . . .  5
   6.1.        Root Server "Glue" in the Root Zone File . . . . . . .  6
   6.2.        Using Glue records in responses  . . . . . . . . . . .  6
   6.3.        Registry considerations for maintaining Glue RRs . . .  7
   6.4.        Glue RRs for multihomed name servers . . . . . . . . .  8
   6.5.        Grandchild Glue  . . . . . . . . . . . . . . . . . . .  8
   7.          DNSSEC Considerations  . . . . . . . . . . . . . . . .  9
   8.          IPv6 Considerations  . . . . . . . . . . . . . . . . .  9
   9.          Security Considerations  . . . . . . . . . . . . . . .  9
   10.         IANA Considerations  . . . . . . . . . . . . . . . . .  9
   11.         References . . . . . . . . . . . . . . . . . . . . . .  9
  ...

当初は目的まではっきりしていたようだ。 [RFC0973]

The purpose is constrained to providing
   address information for name servers mentioned in NS RRs, which would
   otherwise not be resolvable.  Glue records are address information
   accompanying a delegation (in the delegating zone).

• [RFC4472] introduces the concept of 'critical' and 'courtesy' additional data.

委譲に付随するAレコードをglueと呼んでいるようだ。

• それを細分化するために「グルーポリシー」という説明をしている。(5章)

It turned out that, while all early RFCs are consistent in using "glue" only for type A address records for NS RR targets, 
they apply slightly different logic as to when a glue A RR should be present.

As said before, Glue is meant to be present in the delegating zone only.

• The only exception seems to be root zone which also contains the address records for its authoritative name servers.

Glue RRs are needed only in the delegating zone, regardless of glue   policy.

[RFC4472] introduces the concept of 'critical' and 'courtesy' additional data.

1. 疑問

root zone には例外があるというのか。 (.arpa ドメインのサーバに対する A レコードか)

• [RFC5855] により、無用になるとの記述もある。

circular dependency はいまも認められているのか。

2. glue policies

/glue-policy

3. 6 章 Open Issues

6.2. Using Glue records in responses

• 権威のあるAだと思っていたが、ゾーンカットを考慮すると、 glue はglueであり、権威のない返答に含めるべきなのだろう。

6.3. Registry considerations for maintaining Glue RRs

   As explained in [RFC5936], Glue address records are "registered with"
   a zone, but since they fall underneath (or, sometimes, onto) the next
   zone cut, they are not part of that zone.  Depending on the data
   model and glue policy in use for a TLD ([RFC5731], [RFC5732]),
   different side effects may be the consequence of undelegating a
   domain. 

  The standard zone file format does not allow for the
   explicit dedication of address records as glue information.  Instead,
   the distinction is made based on the presence or absence of zone
   cuts.  If, for example, the "del.example" domain was delegated to,
   amongst others, the "dns.del.example" name server an address record
   for "dns.del.example" in the "example" TLD zone will be interpreted
   as glue record. 

   After deleting the "del.example" NS RRSet (the
   delegation) from the "example" zone, the corresponding address record
   would have to be deleted, as well. 

   Should it remain, it would be
   elevated to authoritative data, since there no longer is a zone cut.
   Such an effect might be highly undesirable and should be avoided.

   Custom or proprietary name server software may be able to keep
   delegation and glue data separate from the delegation data so that
   "dns.del.example" would still exist but would not be elevated to
   authoritative status.  However, this effect is similarily undesirable
   since the address might be used to fill the additional section for
   referrals containing NS RRs pointing to "dns.del.example", as if
   "wide" glue policy was in effect.

   With the "wide" glue policy, a glue address record registered with
   some delegation might not even be related to the delegation of its
   own second level domain, i.e., the corresponding name server does not
   have to be part of the NS RRSet for that domain.

  Therefore, broader
   checks have to be applied to avoid the aforementioned undesired
   effects.