Network Working Group P. Koch
Internet-Draft DENIC eG
Expires: April 20, 2006 October 17, 2005
DNS Glue RR Survey and Terminology Clarification
draft-koch-dns-glue-clarifications-00
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 April 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 April 20, 2006 [Page 1]
Internet-Draft DNS Glue Clarification October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Glue Policies . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Koch Expires April 20, 2006 [Page 2]
Internet-Draft DNS Glue Clarification October 2005
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 my 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 clerify when and where to call an address
record "glue record".
Comments should be directed at the author.
{This is a -00 version and thus will not pass the ID nits test.}
2. 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).
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.
3. 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 than attached to the zone data so that it
is available at all authoritative servers, i.e. the glue travels with
Koch Expires April 20, 2006 [Page 3]
Internet-Draft DNS Glue Clarification October 2005
the zone data by AXFR, IXFR or otherwise. 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
"arbitrary".
Glue RRs are needed only in the delegating zone, regardless of glue
policy.
Various RFCs have identified extraneous glue RRs as sources of error
and confusion ([RFC1713], [RFC1912]).
4. 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 Should glue RRs be used in responses?
o TTL considerations
Koch Expires April 20, 2006 [Page 4]
Internet-Draft DNS Glue Clarification October 2005
o Glue RRs for multihomed name servers
5. DNSSEC Considerations
DNSSEC signatures do not cover glue records [RFC3833], [RFC4033].
6. IPv6 Considerations
While this document makes no explicit statements about AAAA RRs,
similar logic applies except in cases where A and AAAA glue RR
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.
7. 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.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,
Koch Expires April 20, 2006 [Page 5]
Internet-Draft DNS Glue Clarification October 2005
December 1992.
[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.
[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.
[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.
Koch Expires April 20, 2006 [Page 6]
Internet-Draft DNS Glue Clarification October 2005
[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.
Koch Expires April 20, 2006 [Page 7]
Internet-Draft DNS Glue Clarification October 2005
Author's Address
Peter Koch
DENIC eG
Wiesenhuettenplatz 26
Frankfurt 60329
DE
Phone: +49 69 27235 0
Email: pk@DENIC.DE
Koch Expires April 20, 2006 [Page 8]
Internet-Draft DNS Glue Clarification October 2005
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 (2005). 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 April 20, 2006 [Page 9]