Network Working Group P. Koch Internet-Draft DENIC eG Expires: September 7, 2006 March 6, 2006 DNS Glue RR Survey and Terminology Clarification draft-koch-dns-glue-clarifications-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document presents a survey of the use of the term "glue record" in DNS related RFCs and proposes a terminology for the various glue policies seen in different TLDs. Koch Expires September 7, 2006 [Page 1] Internet-Draft DNS Glue Clarification March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 2. RFC Survey . . . . . . . . . . . . . . . . . . . . . . 3 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Glue Policies . . . . . . . . . . . . . . . . . . . . 4 5. Open Issues . . . . . . . . . . . . . . . . . . . . . 5 5.1. Root Server "Glue" in the Root Zone File . . . . . . . 5 5.2. Using Glue records in responses . . . . . . . . . . . 6 6. DNSSEC Considerations . . . . . . . . . . . . . . . . 6 7. IPv6 Considerations . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Document Revision History . . . . . . . . . . . . . . 9 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . 12 Koch Expires September 7, 2006 [Page 2] Internet-Draft DNS Glue Clarification March 2006 1. Introduction When delegating zones from a TLD or other DNS zone, some additional information is needed when resolving a name server's (as per an NS RR) address would involve the particular name server itself. Such a dependency on itself, direct or indirect, may effectively shadow a part of a zone's NS RRSet, reducing redundancy, or even render the zone completely unresolvable. This additional information is attached to a delegation by means of glue address records. In the real life DNS multiple strategies to determine necessity or acceptance of glue records co-exist. This document lists a subset of those approaches. This document also tries to clarify when and where to call an address record "glue record". Comments should be directed at the author. {This is an early version and thus will not pass the ID nits test.} Domain names and IP addresses herein are for explanatory purposes only and should not be expected to lead to useful information in real life [RFC2606],[RFC3330]). 2. RFC Survey To find out more about early motivations and strategies for DNS glue records, all existing RFCs were automatically searched for the term "glue" (case insensitive, no word boundaries) and those matching were inspected on a case by case basis. Whenever the term was used in a DNS context, the RFC was added to the list which can be found in the References section. 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. 3. Terms When the term "glue record" was introduced in [RFC0973], it was meant to denominate both data origin and purpose. Data origin is related to the zone, although the glue records do not belong to the authoritative zone data. 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). Koch Expires September 7, 2006 [Page 3] Internet-Draft DNS Glue Clarification March 2006 There is sometimes confusion when data in a DNS response is also called "glue" data, e.g. [RFC2010] starts speaking of "fetching" glue. In a DNS response packet (answer or referral) the address information for name servers is carried in the additional section. This address information might have originated from glue records but might also come from cached or authoritative data. DNS data in response packets should only be called "glue data" when it is certain and needs to be emphasized that it originates from glue records. [I-D.ietf-dnsop-ipv6-dns-issues] introduces the concept of 'critical' and 'courtesy' additional data. 4. Glue Policies In the DNS tree different policies are applied with respect to registering glue with the delegating zone. "Registering" in this case means that the respective glue information is accepted, requested or required and then attached to the zone data so that it is available at all authoritative servers, i.e. the glue travels with the zone data by AXFR, IXFR or other means. However, it does not make the glue data part of the zone's authoritative data. This is a list of existing glue policies: "never" or "null" Glue RRs are never registered. This currently applies to larger parts of the IN-ADDR.ARPA reverse tree. "narrow" Glue RRs are registered if and only if the name server resides within or below the delegated (child) zone (that is, within the delegated domain). This was suggested by [RFC1034]. "wide" Glue RRs are registered if and only if the name server resides below the delegating (parent) zone. There is no need to register glue RRs if the name server's name belongs into the parent zone. This was suggested by [RFC1033]. It is used for the root zone. "case by case" Glue RRs are registered following the "narrow" policy except where there are (circular) dependencies that demand additional glue RRs. "mandatory" Glue RRs are always registered for all name servers. This was suggested by [RFC0973]. "other" Combinations of the above may exist, e.g. if a registry runs multiple sibling domains and decides to register glue RRs whenever a name server resides in or below one of the siblings. This category would also include other policies like "random" or Koch Expires September 7, 2006 [Page 4] Internet-Draft DNS Glue Clarification March 2006 "arbitrary". Glue RRs are needed only in the delegating zone, regardless of glue policy. See Section 5.1 for a discussion of root zone issues. Various RFCs have identified extraneous glue RRs as sources of error and confusion ([RFC1713], [RFC1912]). 5. Open Issues Future versions of this document will expand on these topics: o Software issues when following NS RRs [I-D.minda-dnsop-using-in- bailiwick-nameservers] o Mixed IPv4 and IPv6 environments, following the example of [I-D.ietf-dnsop-ipv6-dns-issues]. o TTL considerations: glue data vs. authoritative data as well as NS RRSet TTLs vs A RRSet TTLs o Glue RRs for multihomed name servers o Grandchild Glue: a nameserver's name maybe well within a delegated domain but still not belong to the delegated zone. 5.1. Root Server "Glue" in the Root Zone File 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. However, with the current setup the root servers also serve the ARPA domain and with the root zone's "wide" glue policy this means that there should be glue RRs for this particular set of nameservers, but only in their capacity as ARPA TLD servers. [The position of the A RRs in the root zone file (which has just editorial value) as well as their TTLs suggest that historically there will have been a different reason]. Also, per operational practice, all root servers are authoritative for the zone they reside in (even if that is not officially delegated to all the 13 servers) [this may not be true for all instances]. So, they have the authoritative data present and do not need to rely upon the data transported with the root zone. [To have a complete trust chain available at the root servers leading to their own names, it would be useful to have them configured Koch Expires September 7, 2006 [Page 5] Internet-Draft DNS Glue Clarification March 2006 authoritative for all intermediate zones. It has been suggested before to move the root server's names to a distinct TLD. Another option would be to move their names to e.g. ROOT-SERVERS.ARPA instead.] 5.2. Using Glue records in responses Some implementations use Glue information not only during additional section processing, but also in the answer section of responses. Given an excerpt of the "example" TLD zone file ... one.example. NS dns.one.example. NS dns.two.example. dns.one.example. A 192.0.2.53 What should a name server authoritative for the example TLD do when asked for the A RR for dns.one.example? Some implementations will put the A RR in the answer section of the response, others will respond with a referral and only copy the glue A RR into the additional section (the handling of dns.two.example's A RR is not considered here). Step 4 of the algorithm in 4.3.2 of [RFC1034] suggests that after copying the NS RRs into the authority section (in step 3b) the cache should be consulted and used to fill the answer section. Depending on whether or not Glue data is considered to reside in the cache (it is definitely not authoritative), one or the other response type will be preferred. With DNSSEC an A RRSet response originating from glue data will always miss the appropriate signature, because neither does the delegating zone sign the glue RRSet nor does a glue RRSIG exist in that delegating zone. [discuss levels of indirection and operational reasons the lead to the "gluepot response"] 6. DNSSEC Considerations DNSSEC signatures do not cover glue records [RFC3833], [RFC4033]. 7. IPv6 Considerations While this document makes no explicit statements about AAAA RRs, similar logic applies except in cases where A and AAAA glue RR Koch Expires September 7, 2006 [Page 6] Internet-Draft DNS Glue Clarification March 2006 interaction requires specific consideration (size, TTL, namespace fragmentation). The specification of the no longer preferred A6 RR [RFC2874] includes a detailed discussion due to the variable representation of IPv6 addresses in A6. 8. References [I-D.ietf-dnsext-axfr-clarify] Gustafsson, A., "DNS Zone Transfer Protocol Clarifications", draft-ietf-dnsext-axfr-clarify-05 (work in progress), December 2002. [I-D.ietf-dnsop-ipv6-dns-issues] Durand, A., "Operational Considerations and Issues with IPv6 DNS", draft-ietf-dnsop-ipv6-dns-issues-12 (work in progress), October 2005. [I-D.ietf-dnsop-respsize] Vixie, P. and A. Kato, "DNS Response Size Issues", draft-ietf-dnsop-respsize-02 (work in progress), July 2005. [I-D.minda-dnsop-using-in-bailiwick-nameservers] Minda, M., "Using In-Bailiwick Namesevers in .ARPA", draft-minda-dnsop-using-in-bailiwick-nameservers-01 (work in progress), July 2005. [RFC0973] Mockapetris, P., "Domain system changes and observations", RFC 973, January 1986. [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1207] Malkin, G., Marine, A., and J. Reynolds, "FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions", RFC 1207, February 1991. [RFC1386] Cooper, A. and J. Postel, "The US Domain", RFC 1386, December 1992. Koch Expires September 7, 2006 [Page 7] Internet-Draft DNS Glue Clarification March 2006 [RFC1537] Beertema, P., "Common DNS Data File Configuration Errors", RFC 1537, October 1993. [RFC1637] Manning, B. and R. Colella, "DNS NSAP Resource Records", RFC 1637, June 1994. [RFC1713] Romao, A., "Tools for DNS debugging", RFC 1713, November 1994. [RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996. [RFC2010] Manning, B. and P. Vixie, "Operational Criteria for Root Name Servers", RFC 2010, October 1996. [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. Koch Expires September 7, 2006 [Page 8] Internet-Draft DNS Glue Clarification March 2006 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002. [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002. [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002. [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003. [RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004. [RFC3732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", RFC 3732, March 2004. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4183] Warnicke, E., "A Suggested Scheme for DNS Resolution of Networks and Gateways", RFC 4183, September 2005. Appendix A. Document Revision History This section is to be removed should the draft be published. Koch Expires September 7, 2006 [Page 9] Internet-Draft DNS Glue Clarification March 2006 A.1. Changes from -00 to -01 Mentioned RFC survey Added text about root server glue New text for using glue in responses Koch Expires September 7, 2006 [Page 10] Internet-Draft DNS Glue Clarification March 2006 Author's Address Peter Koch DENIC eG Wiesenhuettenplatz 26 Frankfurt 60329 DE Phone: +49 69 27235 0 Email: pk@DENIC.DE Koch Expires September 7, 2006 [Page 11] Internet-Draft DNS Glue Clarification March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koch Expires September 7, 2006 [Page 12]