## page was renamed from DNS/glue/survey ## page was renamed from DNS/グルーレコード/survey 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. == 疑問 == root zone には例外があるというのか。 (.arpa ドメインのサーバに対する A レコードか) [RFC5855] により、無用になるとの記述もある。 circular dependency はいまも認められているのか。 == glue policies == [[/glue-policy]] == 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. }}}