+++ /dev/null
-
-
-Network Working Group D. Blacka
-Internet-Draft Verisign, Inc.
-Expires: August 3, 2005 February 2, 2005
-
-
- DNSSEC Experiments
- draft-ietf-dnsext-dnssec-experiments-00
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 August 3, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- In the long history of the development of the DNS security [1]
- extensions (DNSSEC), a number of alternate methodologies and
- modifications have been proposed and rejected for practical, rather
- than strictly technical, reasons. There is a desire to be able to
- experiment with these alternate methods in the public DNS. This
- document describes a methodology for deploying alternate,
- non-backwards-compatible, DNSSEC methodologies in an experimental
- fashion without disrupting the deployment of standard DNSSEC.
-
-
-
-Blacka Expires August 3, 2005 [Page 1]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8
- 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9
- 7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10
- 8. Security Considerations . . . . . . . . . . . . . . . . . . 11
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13
- 10.2 Informative References . . . . . . . . . . . . . . . . . . 13
- Editorial Comments . . . . . . . . . . . . . . . . . . . . . 14
- Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 2]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system (RFC 1035
- [4]) and the DNS security extensions ([1], [2], and [3].
-
- The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 3]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-2. Overview
-
- Historically, experimentation with DNSSEC alternatives has been a
- problematic endeavor. There has typically been a desire to both
- introduce non-backwards-compatible changes to DNSSEC, and to try
- these changes on real zones in the public DNS. This creates a
- problem when the change to DNSSEC would make all or part of the zone
- using those changes appear bogus or otherwise broken to existing
- DNSSEC-aware resolvers.
-
- This document describes a standard methodology for setting up public
- DNSSEC experiments. This methodology addresses the issue of
- co-existence with standard DNSSEC and DNS by using unknown algorithm
- identifiers to hide the experimental DNSSEC protocol modifications
- from standard DNSSEC-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 4]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-3. Experiments
-
- When discussing DNSSEC experiments, it is necessary to classify these
- experiments into two broad categories:
-
- Backwards-Compatible: describes experimental changes that, while not
- strictly adhering to the DNSSEC standard, are nonetheless
- interoperable with clients and server that do implement the DNSSEC
- standard.
- Non-Backwards-Compatible: describes experiments that would cause a
- standard DNSSEC-aware resolver to (incorrectly) determine that all
- or part of a zone is bogus, or to otherwise not interoperable with
- standard DNSSEC clients and servers.
-
- Not included in these terms are experiments with the core DNS
- protocol itself.
-
- The methodology described in this document is not necessary for
- backwards-compatible experiments, although it certainly could be used
- if desired.
-
- Note that, in essence, this metholodolgy would also be used to
- introduce a new DNSSEC algorithm, independently from any DNSSEC
- experimental protocol change.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 5]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-4. Method
-
- The core of the methodology is the use of only "unknown" algorithms
- to sign the experimental zone, and more importantly, having only
- unknown algorithm DS records for the delegation to the zone at the
- parent.
-
- This technique works because of the way DNSSEC-compliant validators
- are expected to work in the presence of a DS set with only unknown
- algorithms. From [3], Section 5.2:
-
- If the validator does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
- And further:
-
- If the resolver does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver will not be able to
- verify the authentication path to the child zone. In this case,
- the resolver SHOULD treat the child zone as if it were unsigned.
-
- While this behavior isn't strictly mandatory (as marked by MUST), it
- is unlikely that a validator would not implement the behavior, or,
- more to the point, it will not violate this behavior in an unsafe way
- (see below (Section 6).)
-
- Because we are talking about experiments, it is recommended that
- private algorithm numbers be used (see [2], appendix A.1.1
- [Comment.1].) Normally, instead of actually inventing new signing
- algorithms, the recommended path is to create alternate algorithm
- identifiers that are aliases for the existing, known algorithms.
- While, strictly speaking, it is only necessary to create an alternate
- identifier for the mandatory algorithms (currently, this is only
- algorithm 5, RSASHA1), it is RECOMMENDED that all OPTIONAL defined
- algorithms be aliased as well.
-
- It is RECOMMENDED that for a particular DNSSEC experiment, a
- particular domain name base is chosen for all new algorithms, then
- the algorithm number (or name) is prepended to it. For example, for
- experiment A, the base name of "dnssec-experiment-a.example.com" is
- chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
- defined to be "3.dnssec-experiment-a.example.com" and
- "5.dnssec-experiment-a.example.com". However, any unique identifier
- will suffice.
-
-
-
-Blacka Expires August 3, 2005 [Page 6]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
- Using this method, resolvers (or, more specificially, DNSSEC
- validators) essentially indicate their ability to understand the
- DNSSEC experiment's semantics by understanding what the new algorithm
- identifiers signify.
-
- This method creates two classes of DNSSEC-aware servers and
- resolvers: servers and resolvers that are aware of the experiment
- (and thus recognize the experiments algorithm identifiers and
- experimental semantics), and servers and resolvers that are unware of
- the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 7]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-5. Defining an Experiment
-
- The DNSSEC experiment must define the particular set of (previously
- unknown) algorithms that identify the experiment, and define what
- each unknown algorithm identifier means. Typically, unless the
- experiment is actually experimenting with a new DNSSEC algorithm,
- this will be a mapping of private algorithm identifiers to existing,
- known algorithms.
-
- Typically, the experiment will choose a DNS name as the algorithm
- identifier base. This DNS name SHOULD be under the control of the
- authors of the experiment. Then the experiment will define a mapping
- between known mandatory and optional algorithms into this private
- algorithm identifier space. Alternately, the experiment MAY use the
- OID private algorithm space instead (using algorithm number 254), or
- may choose non-private algorithm numbers, although this would require
- an IANA allocation (see below (Section 9).)
-
- For example, an experiment might specify in its description the DNS
- name "dnssec-experiment-a.example.com" as the base name, and provide
- the mapping of "3.dnssec-experiment-a.example.com" is an alias of
- DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
- an alias of DNSSEC algorithm 5 (RSASHA1).
-
- Resolvers MUST then only recognize the experiment's semantics when
- present in a zone signed by one or more of these private algorithms.
-
- In general, however, resolvers involved in the experiment are
- expected to understand both standard DNSSEC and the defined
- experimental DNSSEC protocol, although this isn't, strictly speaking,
- required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 8]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-6. Considerations
-
- There are a number of considerations with using this methodology.
-
- 1. Under some circumstances, it may be that the experiment will not
- be sufficiently masked by this technique and may cause resolution
- problem for resolvers not aware of the experiment. For instance,
- the resolver may look at the not validatable response and
- conclude that the response is bogus, either due to local policy
- or implementation details. This is not expected to be the common
- case, however.
- 2. It will, in general, not be possible for DNSSEC-aware resolvers
- not aware of the experiment to build a chain of trust through an
- experimental zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 9]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-7. Transitions
-
- If an experiment is successful, there may be a desire to move the
- experiment to a standards-track extension. One way to do so would be
- to move from private algorithm numbers to IANA allocated algorithm
- numbers, with otherwise the same meaning. This would still leave a
- divide between resolvers that understood the extension versus
- resolvers that did not. It would, in essence, create an additional
- version of DNSSEC.
-
- An alternate technique might be to do a typecode rollover, thus
- actually creating a definitive new version of DNSSEC. There may be
- other transition techniques available, as well.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 10]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-8. Security Considerations
-
- Zones using this methodology will be considered insecure by all
- resolvers except those aware of the experiment. It is not generally
- possible to create a secure delegation from an experimental zone that
- will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 11]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-9. IANA Considerations
-
- IANA may need to allocate new DNSSEC algorithm numbers if that
- transition approach is taken, or the experiment decides to use
- allocated numbers to begin with. No IANA action is required to
- deploy an experiment using private algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 12]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-10. References
-
-10.1 Normative References
-
- [1] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
- "DNS Security Introduction and Requirements",
- draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
- 2004.
-
- [2] Arends, R., "Resource Records for the DNS Security Extensions",
- draft-ietf-dnsext-dnssec-records-11 (work in progress), October
- 2004.
-
- [3] Arends, R., "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in
- progress), October 2004.
-
-10.2 Informative References
-
- [4] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 13]
-\f
-Internet-Draft DNSSEC Experiments February 2005
-
-
-Editorial Comments
-
- [Comment.1] Note: how private algorithms work in DNSSEC is not well
- explained in the DNSSECbis RFCs. In particular, how to
- validate that the DS records contain only unknown
- algorithms is not explained at all.
-
-
-Author's Address
-
- David Blacka
- Verisign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- EMail: davidb@verisign.com
- URI: http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires August 3, 2005 [Page 14]
-\f
-Internet-Draft DNSSEC Experiments February 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.
-
-
-
-
-Blacka Expires August 3, 2005 [Page 15]
-\f
-
+++ /dev/null
-
-
-DNSEXT R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 4, 2005 M. Kosters
- D. Blacka
- Verisign, Inc.
- February 3, 2005
-
-
- DNSSEC Opt-In
- draft-ietf-dnsext-dnssec-opt-in-06
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 August 4, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- In the DNS security extensions (DNSSEC, defined in RFC 2535bis, [3],
- [4], and [5]), delegations to unsigned subzones are cryptographically
- secured. Maintaining this cryptography is not practical or
- necessary. This document describes an experimental "Opt-In" model
- that allows administrators to omit this cryptography and manage the
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 1]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
- cost of adopting DNSSEC with large zones.
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 5
- 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 6
- 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 7
- 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7
- 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 7
- 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 7
- 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 8
- 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 8
- 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 8
- 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 8
- 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 9
- 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 9
- 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 13
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
- 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
- 11.2 Informative References . . . . . . . . . . . . . . . . . . . 18
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
- A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 20
- Intellectual Property and Copyright Statements . . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 2]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system (RFC 1035
- [1]), DNS security extensions ([3], [4], and [5], referred to in this
- document as "RFC 2535bis"), and DNSSEC terminology (RFC 3090 [10]) is
- assumed.
-
- The following abbreviations and terms are used in this document:
-
- RR: is used to refer to a DNS resource record.
- RRset: refers to a Resource Record Set, as defined by [8]. In this
- document, the RRset is also defined to include the covering RRSIG
- records, if any exist.
- signed name: refers to a DNS name that has, at minimum, a (signed)
- NSEC record.
- unsigned name: refers to a DNS name that does not (at least) have a
- NSEC record.
- covering NSEC record/RRset: is the NSEC record used to prove
- (non)existence of a particular name or RRset. This means that for
- a RRset or name 'N', the covering NSEC record has the name 'N', or
- has an owner name less than 'N' and "next" name greater than 'N'.
- delegation: refers to a NS RRset with a name different from the
- current zone apex (non-zone-apex), signifying a delegation to a
- subzone.
- secure delegation: refers to a signed name containing a delegation
- (NS RRset), and a signed DS RRset, signifying a delegation to a
- signed subzone.
- insecure delegation: refers to a signed name containing a delegation
- (NS RRset), but lacking a DS RRset, signifying a delegation to an
- unsigned subzone.
- Opt-In insecure delegation: refers to an unsigned name containing
- only a delegation NS RRset. The covering NSEC record uses the
- Opt-In methodology described in this document.
-
- The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [7].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 3]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-2. Overview
-
- The cost to cryptographically secure delegations to unsigned zones is
- high for large delegation-centric zones and zones where insecure
- delegations will be updated rapidly. For these zones, the costs of
- maintaining the NSEC record chain may be extremely high relative to
- the gain of cryptographically authenticating existence of unsecured
- zones.
-
- This document describes an experimental method of eliminating the
- superfluous cryptography present in secure delegations to unsigned
- zones. Using "Opt-In", a zone administrator can choose to remove
- insecure delegations from the NSEC chain. This is accomplished by
- extending the semantics of the NSEC record by using a redundant bit
- in the type map.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 4]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-3. Experimental Status
-
- This document describes an EXPERIMENTAL extension to DNSSEC. It
- interoperates with non-experimental DNSSEC using the technique
- described in [6]. This experiment is identified with the following
- private algorithms (using algorithm 253):
-
- "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
- and
- "4.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
- RSASHA1.
-
- Servers wishing to sign and serve zones that utilize Opt-In MUST sign
- the zone with one or more of these private algorithms. This requires
- the signing tools and servers to support private algorithms, as well
- as Opt-In.
-
- Resolvers wishing to validate Opt-In zones MUST only do so when the
- zone is signed using one or more of these private algorithms.
-
- The remainder of this document assumes that the servers and resolvers
- involved are aware of and are involved in this experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 5]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-4. Protocol Additions
-
- In RFC 2535bis, delegation NS RRsets are not signed, but are instead
- accompanied by a NSEC RRset of the same name and a DS record. The
- security status of the subzone is determined by the presence or
- absence of the DS RRset, cryptographically proven by the NSEC record.
- Opt-In expands this definition by allowing insecure delegations to
- exist within an otherwise signed zone without the corresponding NSEC
- record at the delegation's owner name. These insecure delegations
- are proven insecure by using a covering NSEC record.
-
- Since this represents a change of the interpretation of NSEC records,
- resolvers must be able to distinguish between RFC 2535bis NSEC
- records and Opt-In NSEC records. This is accomplished by "tagging"
- the NSEC records that cover (or potentially cover) insecure
- delegation nodes. This tag is indicated by the absence of the NSEC
- bit in the type map. Since the NSEC bit in the type map merely
- indicates the existence of the record itself, this bit is redundant
- and safe for use as a tag.
-
- An Opt-In tagged NSEC record does not assert the (non)existence of
- the delegations that it covers (except for a delegation with the same
- name). This allows for the addition or removal of these delegations
- without recalculating or resigning records in the NSEC chain.
- However, Opt-In tagged NSEC records do assert the (non)existence of
- other RRsets.
-
- An Opt-In NSEC record MAY have the same name as an insecure
- delegation. In this case, the delegation is proven insecure by the
- lack of a DS bit in type map and the signed NSEC record does assert
- the existence of the delegation.
-
- Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
- records and RFC 2535bis NSEC records. If a NSEC record is not
- Opt-In, there MUST NOT be any insecure delegations (or any other
- records) between it and the RRsets indicated by the 'next domain
- name' in the NSEC RDATA. If it is Opt-In, there MUST only be
- insecure delegations between it and the next node indicated by the
- 'next domain name' in the NSEC RDATA.
-
- In summary,
-
- o An Opt-In NSEC type is identified by a zero-valued (or
- not-specified) NSEC bit in the type bit map of the NSEC record.
- o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
- the type bit map of the NSEC record.
-
- and,
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 6]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
- o An Opt-In NSEC record does not assert the non-existence of a name
- between its owner name and "next" name, although it does assert
- that any name in this span MUST be an insecure delegation.
- o An Opt-In NSEC record does assert the (non)existence of RRsets
- with the same owner name.
-
-4.1 Server Considerations
-
- Opt-In imposes some new requirements on authoritative DNS servers.
-
-4.1.1 Delegations Only
-
- This specification dictates that only insecure delegations may exist
- between the owner and "next" names of an Opt-In tagged NSEC record.
- Signing tools SHOULD NOT generate signed zones that violate this
- restriction. Servers SHOULD refuse to load and/or serve zones that
- violate this restriction.
-
-4.1.2 Insecure Delegation Responses
-
- When returning an Opt-In insecure delegation, the server MUST return
- the covering NSEC RRset in the Authority section.
-
- In RFC 2535bis, NSEC records already must be returned along with the
- insecure delegation. The primary difference that this proposal
- introduces is that the Opt-In tagged NSEC record will have a
- different owner name from the delegation RRset. This may require
- implementations to do a NSEC search on cached responses.
-
-4.1.3 Wildcards and Opt-In
-
- RFC 2535bis describes the practice of returning NSEC records to prove
- the non-existence of an applicable wildcard in non-existent name
- responses. This NSEC record can be described as a "negative wildcard
- proof". The use of Opt-In NSEC records changes the necessity for
- this practice. For non-existent name responses when the query name
- (qname) is covered by an Opt-In tagged NSEC record, servers MAY
- choose to omit the wildcard proof record, and clients MUST NOT treat
- the absence of this NSEC record as a validation error.
-
- The intent of the RFC 2535bis negative wildcard proof requirement is
- to prevent malicious users from undetectably removing valid wildcard
- responses. In order for this cryptographic proof to work, the
- resolver must be able to prove:
-
- 1. The exact qname does not exist. This is done by the "normal"
- NSEC record.
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 7]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
- 2. No applicable wildcard exists. This is done by returning a NSEC
- record proving that the wildcard does not exist (this is the
- negative wildcard proof).
-
- However, if the NSEC record covering the exact qname is an Opt-In
- NSEC record, the resolver will not be able to prove the first part of
- this equation, as the qname might exist as an insecure delegation.
- Thus, since the total proof cannot be completed, the negative
- wildcard proof NSEC record is not useful.
-
- The negative wildcard proof is also not useful when returned as part
- of an Opt-In insecure delegation response for a similar reason: the
- resolver cannot prove that the qname does or does not exist, and
- therefore cannot prove that a wildcard expansion is valid.
-
- The presence of an Opt-In tagged NSEC record does not change the
- practice of returning a NSEC along with a wildcard expansion. Even
- though the Opt-In NSEC will not be able to prove that the wildcard
- expansion is valid, it will prove that the wildcard expansion is not
- masking any signed records.
-
-4.1.4 Dynamic Update
-
- Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In
- particular, it introduces the need for rules that describe when to
- add or remove a delegation name from the NSEC chain. This document
- does not attempt to define these rules. Until these rules are
- defined, servers MUST NOT process DNS Dynamic Update requests against
- zones that use Opt-In NSEC records.
-
-4.2 Client Considerations
-
- Opt-In imposes some new requirements on security-aware resolvers
- (caching or otherwise).
-
-4.2.1 Delegations Only
-
- As stated in the "Server Considerations" section above, this
- specification restricts the namespace covered by Opt-In tagged NSEC
- records to insecure delegations only. Thus, resolvers MUST reject as
- invalid any records that fall within an Opt-In NSEC record's span
- that are not NS records or corresponding glue records.
-
-4.2.2 Validation Process Changes
-
- This specification does not change the resolver's resolution
- algorithm. However, it does change the DNSSEC validation process.
- Resolvers MUST be able to use Opt-In tagged NSEC records to
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 8]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
- cryptographically prove the validity and security status (as
- insecure) of a referral. Resolvers determine the security status of
- the referred-to zone as follows:
-
- o In RFC 2535bis, the security status is proven by the existence or
- absence of a DS RRset at the same name as the delegation. The
- existence of the DS RRset indicates that the referred-to zone is
- signed. The absence of the DS RRset is proven using a verified
- NSEC record of the same name that does not have the DS bit set in
- the type map. This NSEC record MAY also be tagged as Opt-In.
- o Using Opt-In, the security status is proven by the existence of a
- DS record (for signed) or the presence of a verified Opt-In tagged
- NSEC record that covers the delegation name. That is, the NSEC
- record does not have the NSEC bit set in the type map, and the
- delegation name falls between the NSEC's owner and "next" name.
-
- Using Opt-In does not substantially change the nature of following
- referrals within DNSSEC. At every delegation point, the resolver
- will have cryptographic proof that the subzone is signed or unsigned.
-
- When receiving either an Opt-In insecure delegation response or a
- non-existent name response where that name is covered by an Opt-In
- tagged NSEC record, the resolver MUST NOT require proof (in the form
- of a NSEC record) that a wildcard did not exist.
-
-4.2.3 NSEC Record Caching
-
- Caching resolvers MUST be able to retrieve the appropriate covering
- Opt-In NSEC record when returning referrals that need them. This
- requirement differs from RFC 2535bis in that the covering NSEC will
- not have the same owner name as the delegation. Some implementations
- may have to use new methods for finding these NSEC records.
-
-4.2.4 Use of the AD bit
-
- The AD bit, as defined by [2] and [5], MUST NOT be set when:
-
- o sending a non-existent name (NXDOMAIN) response where the covering
- NSEC is tagged as Opt-In.
- o sending an Opt-In insecure delegation response, unless the
- covering (Opt-In) NSEC record's owner name equals the delegation
- name.
-
- This rule is based on what the Opt-In NSEC record actually proves:
- for names that exist between the Opt-In NSEC record's owner and
- "next" names, the Opt-In NSEC record cannot prove the non-existence
- or existence of the name. As such, not all data in the response has
- been cryptographically verified, so the AD bit cannot be set.
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 9]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-5. Benefits
-
- Using Opt-In allows administrators of large and/or changing
- delegation-centric zones to minimize the overhead involved in
- maintaining the security of the zone.
-
- Opt-In accomplishes this by eliminating the need for NSEC records for
- insecure delegations. This, in a zone with a large number of
- delegations to unsigned subzones, can lead to substantial space
- savings (both in memory and on disk). Additionally, Opt-In allows
- for the addition or removal of insecure delegations without modifying
- the NSEC record chain. Zones that are frequently updating insecure
- delegations (e.g., TLDs) can avoid the substantial overhead of
- modifying and resigning the affected NSEC records.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 10]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-6. Example
-
- Consider the zone EXAMPLE, shown below. This is a zone where all of
- the NSEC records are tagged as Opt-In.
-
- Example A: Fully Opt-In Zone.
-
- EXAMPLE. SOA ...
- EXAMPLE. RRSIG SOA ...
- EXAMPLE. NS FIRST-SECURE.EXAMPLE.
- EXAMPLE. RRSIG NS ...
- EXAMPLE. DNSKEY ...
- EXAMPLE. RRSIG DNSKEY ...
- EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS RRSIG DNSKEY
- EXAMPLE. RRSIG NSEC ...
-
- FIRST-SECURE.EXAMPLE. A ...
- FIRST-SECURE.EXAMPLE. RRSIG A ...
- FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG
- FIRST-SECURE.EXAMPLE. RRSIG NSEC ...
-
- NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
- NS.NOT-SECURE.EXAMPLE. A ...
-
- NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
- NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG
- NOT-SECURE-2.EXAMPLE RRSIG NSEC ...
-
- SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE.
- SECOND-SECURE.EXAMPLE. DS ...
- SECOND-SECURE.EXAMPLE. RRSIG DS ...
- SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY
- SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
-
- UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE.
- NS.UNSIGNED.EXAMPLE. A ...
-
-
- In this example, a query for a signed RRset (e.g.,
- "FIRST-SECURE.EXAMPLE A"), or a secure delegation
- ("WWW.SECOND-SECURE.EXAMPLE A") will result in a normal RFC 2535bis
- response.
-
- A query for a nonexistent RRset will result in a response that
- differs from RFC 2535bis by: the NSEC record will be tagged as
- Opt-In, there may be no NSEC record proving the non-existence of a
- matching wildcard record, and the AD bit will not be set.
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 11]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
- A query for an insecure delegation RRset (or a referral) will return
- both the answer (in the Authority section) and the corresponding
- Opt-In NSEC record to prove that it is not secure.
-
- Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
-
-
- RCODE=NOERROR, AD=0
-
- Answer Section:
-
- Authority Section:
- UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE
- SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS
- SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
-
- Additional Section:
- NS.UNSIGNED.EXAMPLE. A ...
-
- In the Example A.1 zone, the EXAMPLE. node MAY use either style of
- NSEC record, because there are no insecure delegations that occur
- between it and the next node, FIRST-SECURE.EXAMPLE. In other words,
- Example A would still be a valid zone if the NSEC record for EXAMPLE.
- was changed to the following RR:
-
- EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS
- RRSIG DNSKEY NSEC )
-
- However, the other NSEC records (FIRST-SECURE.EXAMPLE. and
- SECOND-SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are
- insecure delegations in the range they define. (NOT-SECURE.EXAMPLE.
- and UNSIGNED.EXAMPLE., respectively).
-
- NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that
- is part of the NSEC chain and also covered by an Opt-In tagged NSEC
- record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot
- be removed from the zone without modifying and resigning the prior
- NSEC record. Delegations with names that fall between
- NOT-SECURE-2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or
- removed without resigning any NSEC records.
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 12]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-7. Transition Issues
-
- Opt-In is not backwards compatible with RFC 2535bis. RFC 2535bis
- compliant DNSSEC implementations will not recognize Opt-In tagged
- NSEC records as different from RFC 2535bis NSEC records. Because of
- this, RFC 2535bis implementations will reject all Opt-In insecure
- delegations within a zone as invalid.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 13]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-8. Security Considerations
-
- Opt-In allows for unsigned names, in the form of delegations to
- unsigned subzones, to exist within an otherwise signed zone. All
- unsigned names are, by definition, insecure, and their validity or
- existence cannot by cryptographically proven.
-
- In general:
-
- o Records with unsigned names (whether existing or not) suffer from
- the same vulnerabilities as records in an unsigned zone. These
- vulnerabilites are described in more detail in [12] (note in
- particular sections 2.3, "Name Games" and 2.6, "Authenticated
- Denial").
- o Records with signed names have the same security whether or not
- Opt-In is used.
-
- Note that with or without Opt-In, an insecure delegation may have its
- contents undetectably altered by an attacker. Because of this, the
- primary difference in security that Opt-In introduces is the loss of
- the ability to prove the existence or nonexistence of an insecure
- delegation within the span of an Opt-In NSEC record.
-
- In particular, this means that a malicious entity may be able to
- insert or delete records with unsigned names. These records are
- normally NS records, but this also includes signed wildcard
- expansions (while the wildcard record itself is signed, its expanded
- name is an unsigned name).
-
- For example, if a resolver received the following response from the
- example zone above:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 14]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
- Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
-
- RCODE=NOERROR
-
- Answer Section:
-
- Authority Section:
- DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
- EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
- RRSIG DNSKEY
- EXAMPLE. RRSIG NSEC ...
-
- Additional Section:
-
-
- The resolver would have no choice but to believe that the referral to
- NS.FORGED. is valid. If a wildcard existed that would have been
- expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
- have undetectably removed it and replaced it with the forged
- delegation.
-
- Note that being able to add a delegation is functionally equivalent
- to being able to add any record type: an attacker merely has to forge
- a delegation to nameserver under his/her control and place whatever
- records needed at the subzone apex.
-
- While in particular cases, this issue may not present a significant
- security problem, in general it should not be lightly dismissed.
- Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
- In particular, zone signing tools SHOULD NOT default to Opt-In, and
- MAY choose to not support Opt-In at all.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 15]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-9. IANA Considerations
-
- None.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 16]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-10. Acknowledgments
-
- The contributions, suggestions and remarks of the following persons
- (in alphabetic order) to this draft are acknowledged:
-
- Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
- Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
- Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
- Wellington.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 17]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-11. References
-
-11.1 Normative References
-
- [1] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
- Authenticated Data (AD) bit", RFC 3655, November 2003.
-
- [3] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
- "DNS Security Introduction and Requirements",
- draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
- 2004.
-
- [4] Arends, R., "Resource Records for the DNS Security Extensions",
- draft-ietf-dnsext-dnssec-records-11 (work in progress), October
- 2004.
-
- [5] Arends, R., "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in
- progress), October 2004.
-
- [6] Blacka, D., "DNSSEC Experiments",
- draft-blacka-dnssec-experiments-00 (work in progress), December
- 2004.
-
-11.2 Informative References
-
- [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [9] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
- 2137, April 1997.
-
- [10] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
- December 2001.
-
- [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 18]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Mark Kosters
- Verisign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- EMail: markk@verisign.com
- URI: http://www.verisignlabs.com
-
-
- David Blacka
- Verisign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- EMail: davidb@verisign.com
- URI: http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 19]
-\f
-Internet-Draft DNSSEC Opt-In February 2005
-
-
-Appendix A. Implementing Opt-In using "Views"
-
- In many cases, it may be convenient to implement an Opt-In zone by
- combining two separately maintained "views" of a zone at request
- time. In this context, "view" refers to a particular version of a
- zone, not to any specific DNS implementation feature.
-
- In this scenario, one view is the secure view, the other is the
- insecure (or legacy) view. The secure view consists of an entirely
- signed zone using Opt-In tagged NSEC records. The insecure view
- contains no DNSSEC information. It is helpful, although not
- necessary, for the secure view to be a subset (minus DNSSEC records)
- of the insecure view.
-
- In addition, the only RRsets that may solely exist in the insecure
- view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and
- the zone apex NS RRset) MUST be signed and in the secure view.
-
- These two views may be combined at request time to provide a virtual,
- single Opt-In zone. The following algorithm is used when responding
- to each query:
- V_A is the secure view as described above.
- V_B is the insecure view as described above.
- R_A is a response generated from V_A, following RFC 2535bis.
- R_B is a response generated from V_B, following DNS resolution as
- per RFC 1035 [1].
- R_C is the response generated by combining R_A with R_B, as
- described below.
- A query is DNSSEC-aware if it either has the DO bit [11] turned
- on, or is for a DNSSEC-specific record type.
-
-
-
- 1. If V_A is a subset of V_B and the query is not DNSSEC-aware,
- generate and return R_B, otherwise
- 2. Generate R_A.
- 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise
- 4. Generate R_B and combine it with R_A to form R_C:
- For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
- records from R_A into R_B, EXCEPT the AUTHORITY section SOA
- record, if R_B's RCODE = NOERROR.
- 5. Return R_C.
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 20]
-\f
-Internet-Draft DNSSEC Opt-In February 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.
-
-
-
-
-Arends, et al. Expires August 4, 2005 [Page 21]
-\f
-
+++ /dev/null
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-Expires: June 2005 December 2004
-
-
-
- Elliptic Curve KEYs in the DNS
- -------- ----- ---- -- --- ---
- <draft-ietf-dnsext-ecc-key-06.txt>
-
- Richard C. Schroeppel
- Donald Eastlake 3rd
-
-
-Status of This Document
-
- By submitting this Internet-Draft, I certify that any applicable
- patent or other IPR claims of which I am aware have been disclosed,
- or will be disclosed, and any of which I become aware will be
- disclosed, in accordance with RFC 3668.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNS mailing list <namedroppers@ops.ietf.org>.
-
- 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 a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for storing elliptic curve cryptographic keys and
- signatures in the Domain Name System is specified.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society. All Rights Reserved.
-
-
-
-
-
-R. Schroeppel, et al [Page 1]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-Acknowledgement
-
- The assistance of Hilarie K. Orman in the production of this document
- is greatfully acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Acknowledgement............................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. Elliptic Curve Data in Resource Records.................3
- 3. The Elliptic Curve Equation.............................9
- 4. How do I Compute Q, G, and Y?..........................10
- 5. Elliptic Curve SIG Resource Records....................11
- 6. Performance Considerations.............................13
- 7. Security Considerations................................13
- 8. IANA Considerations....................................13
- Copyright and Disclaimer..................................14
-
- Informational References..................................15
- Normative Refrences.......................................15
-
- Author's Addresses........................................16
- Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 2]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. The DNS has been extended to include digital
- signatures and cryptographic keys as described in [RFC intro,
- protocol, records].
-
- This document describes how to store elliptic curve cryptographic
- (ECC) keys and signatures in the DNS so they can be used for a
- variety of security purposes. Familiarity with ECC cryptography is
- assumed [Menezes].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-
-2. Elliptic Curve Data in Resource Records
-
- Elliptic curve public keys are stored in the DNS within the RDATA
- portions of key RRs, such as RRKEY and KEY [RFC records] RRs, with
- the structure shown below.
-
- The research world continues to work on the issue of which is the
- best elliptic curve system, which finite field to use, and how to
- best represent elements in the field. So, representations are
- defined for every type of finite field, and every type of elliptic
- curve. The reader should be aware that there is a unique finite
- field with a particular number of elements, but many possible
- representations of that field and its elements. If two different
- representations of a field are given, they are interconvertible with
- a tedious but practical precomputation, followed by a fast
- computation for each field element to be converted. It is perfectly
- reasonable for an algorithm to work internally with one field
- representation, and convert to and from a different external
- representation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 3]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S M -FMT- A B Z|
- +-+-+-+-+-+-+-+-+
- | LP |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | P (length determined from LP) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LF |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | F (length determined from LF) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEG |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGI |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGJ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | TRDV |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | H (length determined from LH) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LK |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | K (length determined from LK) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LQ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Q (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | A (length determined from LA) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | ALTA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LB |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | B (length determined from LB) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LC |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | C (length determined from LC) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LG |
-
-
-R. Schroeppel, et al [Page 4]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | G (length determined from LG) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LY |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Y (length determined from LY) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- SMFMTABZ is a flags octet as follows:
-
- S = 1 indicates that the remaining 7 bits of the octet selects
- one of 128 predefined choices of finite field, element
- representation, elliptic curve, and signature parameters.
- MFMTABZ are omitted, as are all parameters from LP through G.
- LY and Y are retained.
-
- If S = 0, the remaining parameters are as in the picture and
- described below.
-
- M determines the type of field underlying the elliptic curve.
-
- M = 0 if the field is a GF[2^N] field;
-
- M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
-
- FMT is a three bit field describing the format of the field
- representation.
-
- FMT = 0 for a (mod P) field.
- > 0 for an extension field, either GF[2^D] or GF[P^D].
- The degree D of the extension, and the field polynomial
- must be specified. The field polynomial is always monic
- (leading coefficient 1.)
-
- FMT = 1 The field polynomial is given explicitly; D is implied.
-
- If FMT >=2, the degree D is given explicitly.
-
- = 2 The field polynomial is implicit.
- = 3 The field polynomial is a binomial. P>2.
- = 4 The field polynomial is a trinomial.
- = 5 The field polynomial is the quotient of a trinomial by a
- short polynomial. P=2.
- = 6 The field polynomial is a pentanomial. P=2.
-
- Flags A and B apply to the elliptic curve parameters.
-
-
-
-
-
-
-R. Schroeppel, et al [Page 5]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- A = 1 When P>=5, the curve parameter A is negated. If P=2, then
- A=1 indicates that the A parameter is special. See the
- ALTA parameter below, following A. The combination A=1,
- P=3 is forbidden.
-
- B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
- then B=1 indicates an alternate elliptic curve equation is
- used. When P=2 and B=1, an additional curve parameter C
- is present.
-
- The Z bit SHOULD be set to zero on creation of an RR and MUST be
- ignored when processing an RR (when S=0).
-
- Most of the remaining parameters are present in some formats and
- absent in others. The presence or absence of a parameter is
- determined entirely by the flags. When a parameter occurs, it is in
- the order defined by the picture.
-
- Of the remaining parameters, PFHKQABCGY are variable length. When
- present, each is preceded by a one-octet length field as shown in the
- diagram above. The length field does not include itself. The length
- field may have values from 0 through 110. The parameter length in
- octets is determined by a conditional formula: If LL<=64, the
- parameter length is LL. If LL>64, the parameter length is 16 times
- (LL-60). In some cases, a parameter value of 0 is sensible, and MAY
- be represented by an LL value of 0, with the data field omitted. A
- length value of 0 represents a parameter value of 0, not an absent
- parameter. (The data portion occupies 0 space.) There is no
- requirement that a parameter be represented in the minimum number of
- octets; high-order 0 octets are allowed at the front end. Parameters
- are always right adjusted, in a field of length defined by LL. The
- octet-order is always most-significant first, least-significant last.
- The parameters H and K may have an optional sign bit stored in the
- unused high-order bit of their length fields.
-
- LP defines the length of the prime P. P must be an odd prime. The
- parameters LP,P are present if and only if the flag M=1. If M=0, the
- prime is 2.
-
- LF,F define an explicit field polynomial. This parameter pair is
- present only when FMT = 1. The length of a polynomial coefficient is
- ceiling(log2 P) bits. Coefficients are in the numerical range
- [0,P-1]. The coefficients are packed into fixed-width fields, from
- higher order to lower order. All coefficients must be present,
- including any 0s and also the leading coefficient (which is required
- to be 1). The coefficients are right justified into the octet string
- of length specified by LF, with the low-order "constant" coefficient
- at the right end. As a concession to storage efficiency, the higher
- order bits of the leading coefficient may be elided, discarding high-
- order 0 octets and reducing LF. The degree is calculated by
-
-
-R. Schroeppel, et al [Page 6]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- determining the bit position of the left most 1-bit in the F data
- (counting the right most bit as position 0), and dividing by
- ceiling(log2 P). The division must be exact, with no remainder. In
- this format, all of the other degree and field parameters are
- omitted. The next parameters will be LQ,Q.
-
- If FMT>=2, the degree of the field extension is specified explicitly,
- usually along with other parameters to define the field polynomial.
-
- DEG is a two octet field that defines the degree of the field
- extension. The finite field will have P^DEG elements. DEG is
- present when FMT>=2.
-
- When FMT=2, the field polynomial is specified implicitly. No other
- parameters are required to define the field; the next parameters
- present will be the LQ,Q pair. The implicit field poynomial is the
- lexicographically smallest irreducible (mod P) polynomial of the
- correct degree. The ordering of polynomials is by highest-degree
- coefficients first -- the leading coefficient 1 is most important,
- and the constant term is least important. Coefficients are ordered
- by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
- degree D is X^D (which is not irreducible). The next is X^D+1, which
- is sometimes irreducible, followed by X^D-1, which isn't. Assuming
- odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
- X, X^D + X + 1, X^D + X - 1, etc.
-
- When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
- odd. The polynomial is determined by the degree and the low order
- term K. Of all the field parameters, only the LK,K parameters are
- present. The high-order bit of the LK octet stores on optional sign
- for K; if the sign bit is present, the field polynomial is X^DEG - K.
-
- When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
- K. When P=2, the H and K parameters are implicitly 1, and are
- omitted from the representation. Only DEG and DEGH are present; the
- next parameters are LQ,Q. When P>2, then LH,H and LK,K are
- specified. Either or both of LH, LK may contain a sign bit for its
- parameter.
-
- When FMT=5, then P=2 (only). The field polynomial is the exact
- quotient of a trinomial divided by a small polynomial, the trinomial
- divisor. The small polynomial is right-adjusted in the two octet
- field TRDV. DEG specifies the degree of the field. The degree of
- TRDV is calculated from the position of the high-order 1 bit. The
- trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
- DEGH is 0, the middle term is omitted from the trinomial. The
- quotient must be exact, with no remainder.
-
- When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
- with the degrees of the middle terms given by the three 2-octet
-
-
-R. Schroeppel, et al [Page 7]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
- X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
- > DEGJ > 0.
-
- DEGH, DEGI, DEGJ are two-octet fields that define the degree of
- a term in a field polynomial. DEGH is present when FMT = 4,
- 5, or 6. DEGI and DEGJ are present only when FMT = 6.
-
- TRDV is a two-octet right-adjusted binary polynomial of degree <
- 16. It is present only for FMT=5.
-
- LH and H define the H parameter, present only when FMT=4 and P
- is odd. The high bit of LH is an optional sign bit for H.
-
- LK and K define the K parameter, present when FMT = 3 or 4, and
- P is odd. The high bit of LK is an optional sign bit for K.
-
- The remaining parameters are concerned with the elliptic curve and
- the signature algorithm.
-
- LQ defines the length of the prime Q. Q is a prime > 2^159.
-
- In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
- member of the pair is an element from the finite field defined
- earlier. The length field defines a long octet string. Field
- elements are represented as (mod P) polynomials of degree < DEG, with
- DEG or fewer coefficients. The coefficients are stored from left to
- right, higher degree to lower, with the constant term last. The
- coefficients are represented as integers in the range [0,P-1]. Each
- coefficient is allocated an area of ceiling(log2 P) bits. The field
- representation is right-justified; the "constant term" of the field
- element ends at the right most bit. The coefficients are fitted
- adjacently without regard for octet boundaries. (Example: if P=5,
- three bits are used for each coefficient. If the field is GF[5^75],
- then 225 bits are required for the coefficients, and as many as 29
- octets may be needed in the data area. Fewer octets may be used if
- some high-order coefficients are 0.) If a flag requires a field
- element to be negated, each non-zero coefficient K is replaced with
- P-K. To save space, 0 bits may be removed from the left end of the
- element representation, and the length field reduced appropriately.
- This would normally only happen with A,B,C, because the designer
- chose curve parameters with some high-order 0 coefficients or bits.
-
- If the finite field is simply (mod P), then the field elements are
- simply numbers (mod P), in the usual right-justified notation. If
- the finite field is GF[2^D], the field elements are the usual right-
- justified polynomial basis representation.
-
-
-
-
-
-R. Schroeppel, et al [Page 8]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- LA,A is the first parameter of the elliptic curve equation.
- When P>=5, the flag A = 1 indicates A should be negated (mod
- P). When P=2 (indicated by the flag M=0), the flag A = 1
- indicates that the parameter pair LA,A is replaced by the two
- octet parameter ALTA. In this case, the parameter A in the
- curve equation is x^ALTA, where x is the field generator.
- Parameter A often has the value 0, which may be indicated by
- LA=0 (with no A data field), and sometimes A is 1, which may
- be represented with LA=1 and a data field of 1, or by setting
- the A flag and using an ALTA value of 0.
-
- LB,B is the second parameter of the elliptic curve equation.
- When P>=5, the flag B = 1 indicates B should be negated (mod
- P). When P=2 or 3, the flag B selects an alternate curve
- equation.
-
- LC,C is the third parameter of the elliptic curve equation,
- present only when P=2 (indicated by flag M=0) and flag B=1.
-
- LG,G defines a point on the curve, of order Q. The W-coordinate
- of the curve point is given explicitly; the Z-coordinate is
- implicit.
-
- LY,Y is the user's public signing key, another curve point of
- order Q. The W-coordinate is given explicitly; the Z-
- coordinate is implicit. The LY,Y parameter pair is always
- present.
-
-
-
-3. The Elliptic Curve Equation
-
- (The coordinates of an elliptic curve point are named W,Z instead of
- the more usual X,Y to avoid confusion with the Y parameter of the
- signing key.)
-
- The elliptic curve equation is determined by the flag octet, together
- with information about the prime P. The primes 2 and 3 are special;
- all other primes are treated identically.
-
- If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
- + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
- If A and/or B is negative (i.e., in the range from P/2 to P), and
- P>=5, space may be saved by putting the sign bit(s) in the A and B
- bits of the flags octet, and the magnitude(s) in the parameter
- fields.
-
- If M=1 and P=3, the B flag has a different meaning: it specifies an
- alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
- the right-hand-side is different. When P=3, this equation is more
-
-
-R. Schroeppel, et al [Page 9]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- commonly used.
-
- If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
- A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
- parameter can often be 0 or 1, or be chosen as a single-1-bit value.
- The flag B is used to select an alternate curve equation, Z^2 + C*Z =
- W^3 + A*W + B. This is the only time that the C parameter is used.
-
-
-
-4. How do I Compute Q, G, and Y?
-
- The number of points on the curve is the number of solutions to the
- curve equation, + 1 (for the "point at infinity"). The prime Q must
- divide the number of points. Usually the curve is chosen first, then
- the number of points is determined with Schoof's algorithm. This
- number is factored, and if it has a large prime divisor, that number
- is taken as Q.
-
- G must be a point of order Q on the curve, satisfying the equation
-
- Q * G = the point at infinity (on the elliptic curve)
-
- G may be chosen by selecting a random [RFC 1750] curve point, and
- multiplying it by (number-of-points-on-curve/Q). G must not itself
- be the "point at infinity"; in this astronomically unlikely event, a
- new random curve point is recalculated.
-
- G is specified by giving its W-coordinate. The Z-coordinate is
- calculated from the curve equation. In general, there will be two
- possible Z values. The rule is to choose the "positive" value.
-
- In the (mod P) case, the two possible Z values sum to P. The smaller
- value is less than P/2; it is used in subsequent calculations. In
- GF[P^D] fields, the highest-degree non-zero coefficient of the field
- element Z is used; it is chosen to be less than P/2.
-
- In the GF[2^N] case, the two possible Z values xor to W (or to the
- parameter C with the alternate curve equation). The numerically
- smaller Z value (the one which does not contain the highest-order 1
- bit of W (or C)) is used in subsequent calculations.
-
- Y is specified by giving the W-coordinate of the user's public
- signature key. The Z-coordinate value is determined from the curve
- equation. As with G, there are two possible Z values; the same rule
- is followed for choosing which Z to use.
-
-
-
-
-
-
-R. Schroeppel, et al [Page 10]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- During the key generation process, a random [RFC 1750] number X must
- be generated such that 1 <= X <= Q-1. X is the private key and is
- used in the final step of public key generation where Y is computed
- as
-
- Y = X * G (as points on the elliptic curve)
-
- If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
- in the (mod P) case, or the high-order non-zero coefficient of Z >
- P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
- GF[2^N] case), then X must be replaced with Q-X. This will
- correspond to the correct Z-coordinate.
-
-
-
-5. Elliptic Curve SIG Resource Records
-
- The signature portion of an RR RDATA area when using the EC
- algorithm, for example in the RRSIG and SIG [RFC records] RRs is
- shown below.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | R, (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | S, (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- R and S are integers (mod Q). Their length is specified by the LQ
- field of the corresponding KEY RR and can also be calculated from the
- SIG RR's RDLENGTH. They are right justified, high-order-octet first.
- The same conditional formula for calculating the length from LQ is
- used as for all the other length fields above.
-
- The data signed is determined as specified in [RFC 2535]. Then the
- following steps are taken where Q, P, G, and Y are as specified in
- the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate random [RFC 1750] K such that 0 < K < Q. (Never sign two
- different messages with the same K. K should be chosen from a
- very large space: If an opponent learns a K value for a single
- signature, the user's signing key is compromised, and a forger
- can sign arbitrary messages. There is no harm in signing the
- same message multiple times with the same key or different
- keys.)
-
- R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
-
-
-R. Schroeppel, et al [Page 11]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- as an integer, and reduced (mod Q). (R must not be 0. In
- this astronomically unlikely event, generate a new random K
- and recalculate R.)
-
- S = ( K^(-1) * (hash + X*R) ) mod Q.
-
- S must not be 0. In this astronomically unlikely event, generate a
- new random K and recalculate R and S.
-
- If S > Q/2, set S = Q - S.
-
- The pair (R,S) is the signature.
-
- Another party verifies the signature as follows:
-
- Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
- valid EC sigature.
-
- hash = SHA-1 ( data )
-
- Sinv = S^(-1) mod Q.
-
- U1 = (hash * Sinv) mod Q.
-
- U2 = (R * Sinv) mod Q.
-
- (U1 * G + U2 * Y) is computed on the elliptic curve.
-
- V = (the W-coordinate of this point) interpreted as an integer
- and reduced (mod Q).
-
- The signature is valid if V = R.
-
- The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
- (R,Q-S) would be valid signatures for the same data. Note that a
- signature that is valid for hash(data) is also valid for
- hash(data)+Q or hash(data)-Q, if these happen to fall in the range
- [0,2^160-1]. It's believed to be computationally infeasible to
- find data that hashes to an assigned value, so this is only a
- cosmetic blemish. The blemish can be eliminated by using Q >
- 2^160, at the cost of having slightly longer signatures, 42 octets
- instead of 40.
-
- We must specify how a field-element E ("the W-coordinate") is to be
- interpreted as an integer. The field-element E is regarded as a
- radix-P integer, with the digits being the coefficients in the
- polynomial basis representation of E. The digits are in the ragne
- [0,P-1]. In the two most common cases, this reduces to "the
- obvious thing". In the (mod P) case, E is simply a residue mod P,
- and is taken as an integer in the range [0,P-1]. In the GF[2^D]
-
-
-R. Schroeppel, et al [Page 12]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- case, E is in the D-bit polynomial basis representation, and is
- simply taken as an integer in the range [0,(2^D)-1]. For other
- fields GF[P^D], it's necessary to do some radix conversion
- arithmetic.
-
-
-
- 6. Performance Considerations
-
- Elliptic curve signatures use smaller moduli or field sizes than
- RSA and DSA. Creation of a curve is slow, but not done very often.
- Key generation is faster than RSA or DSA.
-
- DNS implementations have been optimized for small transfers,
- typically less than 512 octets including DNS overhead. Larger
- transfers will perform correctly and and extensions have been
- standardized to make larger transfers more efficient [RFC 2671].
- However, it is still advisable at this time to make reasonable
- efforts to minimize the size of RR sets stored within the DNS
- consistent with adequate security.
-
-
-
- 7. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- Some specific key generation considerations are given in the body
- of this document.
-
-
-
- 8. IANA Considerations
-
- The key and signature data structures defined herein correspond to
- the value 4 in the Algorithm number field of the IANA registry
-
- Assignment of meaning to the remaining ECC data flag bits or to
- values of ECC fields outside the ranges for which meaning in
- defined in this document requires an IETF consensus as defined in
- [RFC 2434].
-
-
-
-
-
-R. Schroeppel, et al [Page 13]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- Copyright and Disclaimer
-
- Copyright (C) The Internet Society 2004. 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.
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 14]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- Informational References
-
- [RFC 1034] - P. Mockapetris, "Domain names - concepts and
- facilities", 11/01/1987.
-
- [RFC 1035] - P. Mockapetris, "Domain names - implementation and
- specification", 11/01/1987.
-
- [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness
- Recommendations for Security", 12/29/1994.
-
- [RFC intro] - "DNS Security Introduction and Requirements", R.
- Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in
- progress, draft-ietf-dnsext-dnssec-intro-*.txt.
-
- [RFC protocol] - "Protocol Modifications for the DNS Security
- Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
- work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
-
- [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
- August 1999.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C", 1996, John Wiley and Sons
-
- [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
- Cryptosystems", 1993 Kluwer.
-
- [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
- Curves", 1986, Springer Graduate Texts in mathematics #106.
-
-
-
- Normative Refrences
-
- [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", March 1997.
-
- [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", October 1998.
-
- [RFC records] - "Resource Records for the DNS Security Extensions",
- R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
- progress, draft-ietf-dnsext-dnssec-records- *.txt.
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 15]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- Author's Addresses
-
- Rich Schroeppel
- 500 S. Maple Drive
- Woodland Hills, UT 84653 USA
-
- Telephone: +1-505-844-9079(w)
- +1-801-423-7998(h)
- Email: rschroe@sandia.gov
-
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-786-7554 (w)
- +1 508-634-2066 (h)
- EMail: Donald.Eastlake@motorola.com
-
-
-
- Expiration and File Name
-
- This draft expires in June 2004.
-
- Its file name is draft-ietf-dnsext-ecc-key-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 16]
-\f
-
+++ /dev/null
-\r
-INTERNET-DRAFT Donald E. Eastlake 3rd\r
-Updates RFC 1034, 1035 Motorola Laboratories\r
-Expires July 2005 January 2005\r
-\r
-\r
-\r
- Domain Name System (DNS) Case Insensitivity Clarification\r
- ------ ---- ------ ----- ---- ------------- -------------\r
- <draft-ietf-dnsext-insensitive-05.txt>\r
-\r
- Donald E. Eastlake 3rd\r
-\r
-\r
-\r
-Status of This Document\r
-\r
- By submitting this Internet-Draft, I certify that any applicable\r
- patent or other IPR claims of which I am aware have been disclosed,\r
- or will be disclosed, and any of which I become aware will be\r
- disclosed, in accordance with RFC 3668.\r
-\r
- Distribution of this document is unlimited. Comments should be sent\r
- to the DNSEXT working group at namedroppers@ops.ietf.org.\r
-\r
- Internet-Drafts are working documents of the Internet Engineering\r
- Task Force (IETF), its areas, and its working groups. Note that\r
- other groups may also distribute working documents as Internet-\r
- Drafts.\r
-\r
- Internet-Drafts are draft documents valid for a maximum of six months\r
- and may be updated, replaced, or obsoleted by other documents at any\r
- time. It is inappropriate to use Internet-Drafts as reference\r
- material or to cite them other than a "work in progress."\r
-\r
- The list of current Internet-Drafts can be accessed at\r
- http://www.ietf.org/1id-abstracts.html\r
-\r
- The list of Internet-Draft Shadow Directories can be accessed at\r
- http://www.ietf.org/shadow.html\r
-\r
-\r
-\r
-Copyright Notice\r
-\r
- Copyright (C) The Internet Society. All Rights Reserved.\r
-\r
-\r
-\r
-Abstract\r
-\r
- Domain Name System (DNS) names are "case insensitive". This document\r
- explains exactly what that means and provides a clear specification\r
- of the rules. This clarification updates RFCs 1034 and 1035.\r
-\r
-\r
-D. Eastlake 3rd [Page 1]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-Acknowledgements\r
-\r
- The contributions to this document of Rob Austein, Olafur\r
- Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,\r
- Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman\r
- are gratefully acknowledged.\r
-\r
-\r
-\r
-Table of Contents\r
-\r
- Status of This Document....................................1\r
- Copyright Notice...........................................1\r
- Abstract...................................................1\r
-\r
- Acknowledgements...........................................2\r
- Table of Contents..........................................2\r
-\r
- 1. Introduction............................................3\r
- 2. Case Insensitivity of DNS Labels........................3\r
- 2.1 Escaping Unusual DNS Label Octets......................3\r
- 2.2 Example Labels with Escapes............................4\r
- 3. Name Lookup, Label Types, and CLASS.....................4\r
- 3.1 Original DNS Label Types...............................5\r
- 3.2 Extended Label Type Case Insensitivity Considerations..5\r
- 3.3 CLASS Case Insensitivity Considerations................5\r
- 4. Case on Input and Output................................6\r
- 4.1 DNS Output Case Preservation...........................6\r
- 4.2 DNS Input Case Preservation............................6\r
- 5. Internationalized Domain Names..........................7\r
- 6. Security Considerations.................................7\r
-\r
- Full Copyright Notice and Disclaimer.......................9\r
- Normative References.......................................9\r
- Informative References....................................10\r
- -02 to -03 Changes........................................10\r
- -03 to -04 Changes........................................11\r
- -04 to -05 Changes........................................11\r
- Author's Address..........................................11\r
- Expiration and File Name..................................12\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 2]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-1. Introduction\r
-\r
- The Domain Name System (DNS) is the global hierarchical replicated\r
- distributed database system for Internet addressing, mail proxy, and\r
- other information. Each node in the DNS tree has a name consisting of\r
- zero or more labels [STD 13][RFC 1591, 2606] that are treated in a\r
- case insensitive fashion. This document clarifies the meaning of\r
- "case insensitive" for the DNS. This clarification updates RFCs 1034\r
- and 1035 [STD 13].\r
-\r
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
- document are to be interpreted as described in [RFC 2119].\r
-\r
-\r
-\r
-2. Case Insensitivity of DNS Labels\r
-\r
- DNS was specified in the era of [ASCII]. DNS names were expected to\r
- look like most host names or Internet email address right halves (the\r
- part after the at-sign, "@") or be numeric as in the in-addr.arpa\r
- part of the DNS name space. For example,\r
-\r
- foo.example.net.\r
- aol.com.\r
- www.gnu.ai.mit.edu.\r
- or 69.2.0.192.in-addr.arpa.\r
-\r
- Case varied alternatives to the above would be DNS names like\r
-\r
- Foo.ExamplE.net.\r
- AOL.COM.\r
- WWW.gnu.AI.mit.EDU.\r
- or 69.2.0.192.in-ADDR.ARPA.\r
-\r
- However, the individual octets of which DNS names consist are not\r
- limited to valid ASCII character codes. They are 8-bit bytes and all\r
- values are allowed. Many applications, however, interpret them as\r
- ASCII characters.\r
-\r
-\r
-\r
-2.1 Escaping Unusual DNS Label Octets\r
-\r
- In Master Files [STD 13] and other human readable and writable ASCII\r
- contexts, an escape is needed for the byte value for period (0x2E,\r
- ".") and all octet values outside of the inclusive range of 0x21\r
- ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in\r
- the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 3]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- One typographic convention for octets that do not correspond to an\r
- ASCII printing graphic is to use a back-slash followed by the value\r
- of the octet as an unsigned integer represented by exactly three\r
- decimal digits.\r
-\r
- The same convention can be used for printing ASCII characters so that\r
- they will be treated as a normal label character. This includes the\r
- back-slash character used in this convention itself which can be\r
- expressed as \092 or \\ and the special label separator period (".")\r
- which can be expressed as and \046 or \. respectively. It is\r
- advisable to avoid using a backslash to quote an immediately\r
- following non-printing ASCII character code to avoid implementation\r
- difficulties.\r
-\r
- A back-slash followed by only one or two decimal digits is undefined.\r
- A back-slash followed by four decimal digits produces two octets, the\r
- first octet having the value of the first three digits considered as\r
- a decimal number and the second octet being the character code for\r
- the fourth decimal digit.\r
-\r
-\r
-\r
-2.2 Example Labels with Escapes\r
-\r
- The first example below shows embedded spaces and a period (".")\r
- within a label. The second one show a 5-octet label where the second\r
- octet has all bits zero, the third is a backslash, and the fourth\r
- octet has all bits one.\r
-\r
- Donald\032E\.\032Eastlake\0323rd.example.\r
- and a\000\\\255z.example.\r
-\r
-\r
-\r
-3. Name Lookup, Label Types, and CLASS\r
-\r
- The design decision was made that comparisons on name lookup for all\r
- DNS queries should be case insensitive [STD 13]. That is to say, a\r
- lookup string octet with a value in the inclusive range of 0x41 to\r
- 0x5A, the upper case ASCII letters, MUST match the identical value\r
- and also match the corresponding value in the inclusive range 0x61 to\r
- 0x7A, the lower case ASCII letters. And a lookup string octet with a\r
- lower case ASCII letter value MUST similarly match the identical\r
- value and also match the corresponding value in the upper case ASCII\r
- letter range.\r
-\r
- (Historical Note: the terms "upper case" and "lower case" were\r
- invented after movable type. The terms originally referred to the\r
- two font trays for storing, in partitioned areas, the different\r
- physical type elements. Before movable type, the nearest equivalent\r
-\r
-\r
-D. Eastlake 3rd [Page 4]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- terms were "majuscule" and "minuscule".)\r
-\r
- One way to implement this rule would be, when comparing octets, to\r
- subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A\r
- before the comparison. Such an operation is commonly known as "case\r
- folding" but implementation via case folding is not required. Note\r
- that the DNS case insensitivity does NOT correspond to the case\r
- folding specified in [iso-8859-1] or [iso-8859-2]. For example, the\r
- octets 0xDD (\221) and 0xFD (\253) do NOT match although in other\r
- contexts, where they are interpreted as the upper and lower case\r
- version of "Y" with an acute accent, they might.\r
-\r
-\r
-\r
-3.1 Original DNS Label Types\r
-\r
- DNS labels in wire-encoded names have a type associated with them.\r
- The original DNS standard [RFC 1035] had only two types. ASCII\r
- labels, with a length of from zero to 63 octets, and indirect labels\r
- which consist of an offset pointer to a name location elsewhere in\r
- the wire encoding on a DNS message. (The ASCII label of length zero\r
- is reserved for use as the name of the root node of the name tree.)\r
- ASCII labels follow the ASCII case conventions described herein and,\r
- as stated above, can actually contain arbitrary byte values. Indirect\r
- labels are, in effect, replaced by the name to which they point which\r
- is then treated with the case insensitivity rules in this document.\r
-\r
-\r
-\r
-3.2 Extended Label Type Case Insensitivity Considerations\r
-\r
- DNS was extended by [RFC 2671] to have additional label type numbers\r
- available. (The only such type defined so far is the BINARY type [RFC\r
- 2673].)\r
-\r
- The ASCII case insensitivity conventions only apply to ASCII labels,\r
- that is to say, label type 0x0, whether appearing directly or invoked\r
- by indirect labels.\r
-\r
-\r
-\r
-3.3 CLASS Case Insensitivity Considerations\r
-\r
- As described in [STD 13] and [RFC 2929], DNS has an additional axis\r
- for data location called CLASS. The only CLASS in global use at this\r
- time is the "IN" or Internet CLASS.\r
-\r
- The handling of DNS label case is not CLASS dependent.\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 5]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-4. Case on Input and Output\r
-\r
- While ASCII label comparisons are case insensitive, [STD 13] says\r
- case MUST be preserved on output, and preserved when convenient on\r
- input. However, this means less than it would appear since the\r
- preservation of case on output is NOT required when output is\r
- optimized by the use of indirect labels, as explained below.\r
-\r
-\r
-\r
-4.1 DNS Output Case Preservation\r
-\r
- [STD 13] views the DNS namespace as a node tree. ASCII output is as\r
- if a name was marshaled by taking the label on the node whose name is\r
- to be output, converting it to a typographically encoded ASCII\r
- string, walking up the tree outputting each label encountered, and\r
- preceding all labels but the first with a period ("."). Wire output\r
- follows the same sequence but each label is wire encoded and no\r
- periods inserted. No "case conversion" or "case folding" is done\r
- during such output operations, thus "preserving" case. However, to\r
- optimize output, indirect labels may be used to point to names\r
- elsewhere in the DNS answer. In determining whether the name to be\r
- pointed to, for example the QNAME, is the "same" as the remainder of\r
- the name being optimized, the case insensitive comparison specified\r
- above is done. Thus such optimization may easily destroy the output\r
- preservation of case. This type of optimization is commonly called\r
- "name compression".\r
-\r
-\r
-\r
-4.2 DNS Input Case Preservation\r
-\r
- Originally, DNS input came from an ASCII Master File as defined in\r
- [STD 13] or a zone transfer. DNS Dynamic update and incremental zone\r
- transfers [RFC 1995] have been added as a source of DNS data [RFC\r
- 2136, 3007]. When a node in the DNS name tree is created by any of\r
- such inputs, no case conversion is done. Thus the case of ASCII\r
- labels is preserved if they are for nodes being created. However,\r
- when a name label is input for a node that already exist in DNS data\r
- being held, the situation is more complex. Implementations may retain\r
- the case first input for such a label or allow new input to override\r
- the old case or even maintain separate copies preserving the input\r
- case.\r
-\r
- For example, if data with owner name "foo.bar.example" is input and\r
- then later data with owner name "xyz.BAR.example" is input, the name\r
- of the label on the "bar.example" node, i.e. "bar", might or might\r
- not be changed to "BAR" or the actual input case could be preserved.\r
- Thus later retrieval of data stored under "xyz.bar.example" in this\r
- case can easily return data with "xyz.BAR.example". The same\r
-\r
-\r
-D. Eastlake 3rd [Page 6]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- considerations apply when inputting multiple data records with owner\r
- names differing only in case. For example, if an "A" record is stored\r
- as the first resourced record under owner name "xyz.BAR.example" and\r
- then a second "A" record is stored under "XYZ.BAR.example", the\r
- second MAY be stored with the first (lower case initial label) name\r
- or the second MAY override the first so that only an upper case\r
- initial label is retained or both capitalizations MAY be kept.\r
-\r
- Note that the order of insertion into a server database of the DNS\r
- name tree nodes that appear in a Master File is not defined so that\r
- the results of inconsistent capitalization in a Master File are\r
- unpredictable output capitalization.\r
-\r
-\r
-\r
-5. Internationalized Domain Names\r
-\r
- A scheme has been adopted for "internationalized domain names" and\r
- "internationalized labels" as described in [RFC 3490, 3454, 3491, and\r
- 3492]. It makes most of [UNICODE] available through a separate\r
- application level transformation from internationalized domain name\r
- to DNS domain name and from DNS domain name to internationalized\r
- domain name. Any case insensitivity that internationalized domain\r
- names and labels have varies depending on the script and is handled\r
- entirely as part of the transformation described in [RFC 3454] and\r
- [RFC 3491] which should be seen for further details. This is not a\r
- part of the DNS as standardized in STD 13.\r
-\r
-\r
-\r
-6. Security Considerations\r
-\r
- The equivalence of certain DNS label types with case differences, as\r
- clarified in this document, can lead to security problems. For\r
- example, a user could be confused by believing two domain names\r
- differing only in case were actually different names.\r
-\r
- Furthermore, a domain name may be used in contexts other than the\r
- DNS. It could be used as a case sensitive index into some data base\r
- system. Or it could be interpreted as binary data by some integrity\r
- or authentication code system. These problems can usually be handled\r
- by using a standardized or "canonical" form of the DNS ASCII type\r
- labels, that is, always mapping the ASCII letter value octets in\r
- ASCII labels to some specific pre-chosen case, either upper case or\r
- lower case. An example of a canonical form for domain names (and also\r
- a canonical ordering for them) appears in Section 8 of [RFC 2535].\r
- See also [RFC 3597].\r
-\r
- Finally, a non-DNS name may be stored into DNS with the false\r
- expectation that case will always be preserved. For example, although\r
-\r
-\r
-D. Eastlake 3rd [Page 7]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- this would be quite rare, on a system with case sensitive email\r
- address local parts, an attempt to store two "RP" records that\r
- differed only in case would probably produce unexpected results that\r
- might have security implications. That is because the entire email\r
- address, including the possibly case sensitive local or left hand\r
- part, is encoded into a DNS name in a readable fashion where the case\r
- of some letters might be changed on output as described above.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 8]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-Full Copyright Notice and Disclaimer\r
-\r
- Copyright (C) The Internet Society 2005. This document is subject to\r
- the rights, licenses and restrictions contained in BCP 78 and except\r
- as set forth therein, the authors retain all their rights.\r
-\r
-\r
- This document and the information contained herein are provided on an\r
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS\r
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET\r
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,\r
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE\r
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\r
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
-\r
-\r
-\r
-Normative References\r
-\r
- [ASCII] - ANSI, "USA Standard Code for Information Interchange",\r
- X3.4, American National Standards Institute: New York, 1968.\r
-\r
- [RFC 1034, 1035] - See [STD 13].\r
-\r
- [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August\r
- 1996.\r
-\r
- [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate\r
- Requirement Levels", March 1997.\r
-\r
- [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,\r
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.\r
-\r
- [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",\r
- March 1999.\r
-\r
- [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic\r
- Update", November 2000.\r
-\r
- [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",\r
- draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.\r
-\r
- [STD 13]\r
- - P. Mockapetris, "Domain names - concepts and facilities", RFC\r
- 1034, November 1987.\r
- - P. Mockapetris, "Domain names - implementation and\r
- specification", RFC 1035, November 1987.\r
-\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 9]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-Informative References\r
-\r
- [ISO 8859-1] - International Standards Organization, Standard for\r
- Character Encodings, Latin-1.\r
-\r
- [ISO 8859-2] - International Standards Organization, Standard for\r
- Character Encodings, Latin-2.\r
-\r
- [RFC 1591] - J. Postel, "Domain Name System Structure and\r
- Delegation", March 1994.\r
-\r
- [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",\r
- June 1999.\r
-\r
- [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain\r
- Name System (DNS) IANA Considerations", September 2000.\r
-\r
- [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August\r
- 1999.\r
-\r
- [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",\r
- August 1999.\r
-\r
- [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of\r
- Foo", 1 April 2001.\r
-\r
- [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of\r
- Internationalized String ("stringprep")", December 2002.\r
-\r
- [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,\r
- "Internationalizing Domain Names in Applications (IDNA)", March 2003.\r
-\r
- [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile\r
- for Internationalized Domain Names (IDN)", March 2003.\r
-\r
- [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode\r
- for Internationalized Domain Names in Applications (IDNA)", March\r
- 2003.\r
-\r
- [UNICODE] - The Unicode Consortium, "The Unicode Standard",\r
- <http://www.unicode.org/unicode/standard/standard.html>.\r
-\r
-\r
-\r
--02 to -03 Changes\r
-\r
- The following changes were made between draft version -02 and -03:\r
-\r
- 1. Add internationalized domain name section and references.\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 10]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- 2. Change to indicate that later input of a label for an existing DNS\r
- name tree node may or may not be normalized to the earlier input or\r
- override it or both may be preserved.\r
-\r
- 3. Numerous minor wording changes.\r
-\r
-\r
-\r
--03 to -04 Changes\r
-\r
- The following changes were made between draft versions -03 and -04:\r
-\r
- 1. Change to conform to the new IPR, Copyright, etc., notice\r
- requirements.\r
-\r
- 2. Change in some section headers for clarity.\r
-\r
- 3. Drop section on wildcards.\r
-\r
- 4. Add emphasis on loss of case preservation due to name compression.\r
-\r
- 5. Add references to RFCs 1995 and 3092.\r
-\r
-\r
-\r
--04 to -05 Changes\r
-\r
- The following changes were made between draft versions -04 and -05:\r
-\r
- 1. More clearly state that this draft updates RFCs 1034, 1035 [STD\r
- 13].\r
-\r
- 2. Add informative references to ISO 8859-1 and ISO 8859-2.\r
-\r
- 3. Fix hyphenation and capitalization nits.\r
-\r
-\r
-\r
-Author's Address\r
-\r
- Donald E. Eastlake 3rd\r
- Motorola Laboratories\r
- 155 Beaver Street\r
- Milford, MA 01757 USA\r
-\r
- Telephone: +1 508-786-7554 (w)\r
- +1 508-634-2066 (h)\r
- EMail: Donald.Eastlake@motorola.com\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 11]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-Expiration and File Name\r
-\r
- This draft expires July 2005.\r
-\r
- Its file name is draft-ietf-dnsext-insensitive-05.txt.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 12]\r
-\f\r
-\r
+++ /dev/null
-
-DNS Extensions Working Group J. Schlyter
-Internet-Draft August 24, 2004
-Expires: February 22, 2005
-
-
- RFC 3597 Interoperability Report
- draft-ietf-dnsext-interop3597-01.txt
-
-Status of this Memo
-
- By submitting this Internet-Draft, I certify that any applicable
- patent or other IPR claims of which I am aware have been disclosed,
- and any of which I become aware will be disclosed, in accordance with
- RFC 3667.
-
- 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 February 22, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This memo documents the result from the RFC 3597 (Handling of Unknown
- DNS Resource Record Types) interoperability testing.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires February 22, 2005 [Page 1]
-
-Internet-Draft RFC 3597 Interoperability Report August 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1 Authoritative Primary Name Server . . . . . . . . . . . . . . 3
- 3.2 Authoritative Secondary Name Server . . . . . . . . . . . . . 3
- 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . . . 3
- 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4
- 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- Normative References . . . . . . . . . . . . . . . . . . . . . 4
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
- A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5
- Intellectual Property and Copyright Statements . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires February 22, 2005 [Page 2]
-
-Internet-Draft RFC 3597 Interoperability Report August 2004
-
-
-1. Introduction
-
- This memo documents the result from the RFC 3597 (Handling of Unknown
- DNS Resource Record Types) interoperability testing. The test was
- performed during June and July 2004 by request of the IETF DNS
- Extensions Working Group.
-
-2. Implementations
-
- The following is a list, in alphabetic order, of implementations for
- compliance of RFC 3597:
-
- DNSJava 1.6.4
- ISC BIND 8.4.5rc4
- ISC BIND 9.3.0rc2
- NSD 2.1.1
- Net::DNS 0.47 patchlevel 1
- Nominum ANS 2.2.1.0.d
-
- These implementations covers the following functions (number of
- implementations tested for each function in paranthesis):
-
- Authoritative Name Servers (4)
- Full Recursive Resolver (2)
- Stub Resolver (4)
- DNSSEC Zone Signers (2)
-
-3. Tests
-
-3.1 Authoritative Primary Name Server
-
- The test zone data (Appendix A) was loaded into the name server
- implementation and the server was queried for the loaded information.
-
-3.2 Authoritative Secondary Name Server
-
- The test zone data (Appendix A) was transferred using AXFR from
- another name server implementation and the server was queried for the
- transferred information.
-
-3.3 Full Recursive Resolver
-
- A recursive resolver was queried for resource records from a domain
- with the test zone data (Appendix A).
-
-3.4 Stub Resolver
-
- A stub resolver was used to query resource records from a domain with
-
-
-
-Schlyter Expires February 22, 2005 [Page 3]
-
-Internet-Draft RFC 3597 Interoperability Report August 2004
-
-
- the test zone data (Appendix A).
-
-3.5 DNSSEC Signer
-
- A DNSSEC signer was used to sign a zone with test zone data (Appendix
- A).
-
-4. Problems found
-
- Two implementations had problems with text presentation of zero
- length RDATA.
-
- One implementation had problems with text presentation of RR type
- code and classes >= 4096.
-
- Bug reports were filed for problems found.
-
-5. Summary
-
- Unknown type codes works in the tested authoritative servers,
- recursive resolvers and stub clients.
-
- No changes are needed to advance RFC 3597 to draft standard.
-
-Normative References
-
- [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
-
-Author's Address
-
- Jakob Schlyter
-
- EMail: jakob@rfc.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires February 22, 2005 [Page 4]
-
-Internet-Draft RFC 3597 Interoperability Report August 2004
-
-
-Appendix A. Test zone data
-
- ; A-record encoded as TYPE1
- a TYPE1 \# 4 7f000001
- a TYPE1 192.0.2.1
- a A \# 4 7f000002
-
- ; draft-ietf-secsh-dns-05.txt
- sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
-
- ; bogus test record (from RFC 3597)
- type731 TYPE731 \# 6 abcd (
- ef 01 23 45 )
-
- ; zero length RDATA (from RFC 3597)
- type62347 TYPE62347 \# 0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires February 22, 2005 [Page 5]
-
-Internet-Draft RFC 3597 Interoperability Report August 2004
-
-
-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 IETF's procedures with respect to rights in IETF 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 (2004). 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.
-
-
-
-
-Schlyter Expires February 22, 2005 [Page 6]
-
+++ /dev/null
-
-DNSEXT Working Group Levon Esibov
-INTERNET-DRAFT Bernard Aboba
-Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-38.txt> Microsoft
-19 February 2005
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
- By submitting this Internet-Draft, I certify that any applicable
- patent or other IPR claims of which I am aware have been disclosed,
- and any of which I become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 August 22, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005. All rights reserved.
-
-Abstract
-
- Today, with the rise of home networking, there are an increasing
- number of ad-hoc networks operating without a Domain Name System
- (DNS) server. The goal of Link-Local Multicast Name Resolution
- (LLMNR) is to enable name resolution in scenarios in which
- conventional DNS name resolution is not possible. LLMNR supports all
- current and future DNS formats, types and classes, while operating on
- a separate port from DNS, and with a distinct resolver cache. Since
- LLMNR only operates on the local link, it cannot be considered a
- substitute for DNS.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 3
- 1.2 Terminology ..................................... 4
-2. Name resolution using LLMNR ........................... 4
- 2.1 LLMNR packet format ............................. 6
- 2.2 Sender behavior ................................. 8
- 2.3 Responder behavior .............................. 9
- 2.4 Unicast queries ................................. 11
- 2.5 Off-link detection .............................. 12
- 2.6 Responder responsibilities ...................... 13
- 2.7 Retransmission and jitter ....................... 13
- 2.8 DNS TTL ......................................... 14
- 2.9 Use of the authority and additional sections .... 14
-3. Usage model ........................................... 15
- 3.1 LLMNR configuration ............................. 16
-4. Conflict resolution ................................... 17
- 4.1 Uniqueness Verification ......................... 18
- 4.2 Conflict Detection and Defense .................. 18
- 4.3 Considerations for multiple interfaces .......... 20
- 4.4 API issues ...................................... 21
-5. Security considerations ............................... 21
- 5.1 Scope restriction ............................... 22
- 5.2 Usage restriction ............................... 23
- 5.3 Cache and port separation ....................... 23
- 5.4 Authentication .................................. 24
-6. IANA considerations ................................... 24
-7. Constants ............................................. 24
-8. References ............................................ 24
- 8.1 Normative References ............................ 24
- 8.2 Informative References .......................... 25
-Acknowledgments .............................................. 26
-Authors' Addresses ........................................... 27
-Intellectual Property Statement .............................. 27
-Disclaimer of Validity ....................................... 28
-Copyright Statement .......................................... 28
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which utilizes the DNS packet format and supports all current and
- future DNS formats, types and classes. LLMNR operates on a separate
- port from the Domain Name System (DNS), with a distinct resolver
- cache.
-
- The goal of LLMNR is to enable name resolution in scenarios in which
- conventional DNS name resolution is not possible. These include
- scenarios in which hosts are not configured with the address of a DNS
- server, where configured DNS servers do not reply to a query, or
- where they respond with errors, as described in Section 2. Since
- LLMNR only operates on the local link, it cannot be considered a
- substitute for DNS.
-
- Link-scope multicast addresses are used to prevent propagation of
- LLMNR traffic across routers, potentially flooding the network.
- LLMNR queries can also be sent to a unicast address, as described in
- Section 2.4.
-
- Propagation of LLMNR packets on the local link is considered
- sufficient to enable name resolution in small networks. The
- assumption is that if a network has a gateway, then the network is
- able to provide DNS server configuration. Configuration issues are
- discussed in Section 3.1.
-
- In the future, it may be desirable to consider use of multicast name
- resolution with multicast scopes beyond the link-scope. This could
- occur if LLMNR deployment is successful, the need arises for
- multicast name resolution beyond the link-scope, or multicast routing
- becomes ubiquitous. For example, expanded support for multicast name
- resolution might be required for mobile ad-hoc networks.
-
- Once we have experience in LLMNR deployment in terms of
- administrative issues, usability and impact on the network, it will
- be possible to reevaluate which multicast scopes are appropriate for
- use with multicast name resolution.
-
- Service discovery in general, as well as discovery of DNS servers
- using LLMNR in particular, is outside of the scope of this document,
- as is name resolution over non-multicast capable media.
-
-1.1. Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- and "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-1.2. Terminology
-
- This document assumes familiarity with DNS terminology defined in
- [RFC1035]. Other terminology used in this document includes:
-
-Positively Resolved
- Responses with RCODE set to zero are referred to in this document
- as "positively resolved".
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An LLMNR responder considers one of its addresses reachable over a
- link if it will respond to an ARP or Neighbor Discovery query for
- that address sent over the link.
-
-Responder
- A host that listens to LLMNR queries, and responds to those for
- which it is authoritative.
-
-Sender
- A host that sends an LLMNR query.
-
-UNIQUE
- There are some scenarios when multiple responders may respond to
- the same query. There are other scenarios when only one responder
- may respond to a query. Resource records for which only a single
- responder is anticipated are referred to as UNIQUE. Resource
- record uniqueness is configured on the responder, and therefore
- uniqueness verification is the responder's responsibility.
-
-2. Name resolution using LLMNR
-
- LLMNR is a peer-to-peer name resolution protocol that is not intended
- as a replacement for DNS. LLMNR queries are sent to and received on
- port 5355. IPv4 administratively scoped multicast usage is specified
- in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-
- scope multicast address a given responder listens to, and to which a
- sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
- address a given responder listens to, and to which a sender sends all
- queries, is FF02:0:0:0:0:0:1:3.
-
- Typically a host is configured as both an LLMNR sender and a
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- responder. A host MAY be configured as a sender, but not a
- responder. However, a host configured as a responder MUST act as a
- sender to verify the uniqueness of names as described in Section 4.
- This document does not specify how names are chosen or configured.
- This may occur via any mechanism, including DHCPv4 [RFC2131] or
- DHCPv6 [RFC3315].
-
- LLMNR usage MAY be configured manually or automatically on a per
- interface basis. By default, LLMNR responders SHOULD be enabled on
- all interfaces, at all times. Enabling LLMNR for use in situations
- where a DNS server has been configured will result in a change in
- default behavior without a simultaneous update to configuration
- information. Where this is considered undesirable, LLMNR SHOULD NOT
- be enabled by default, so that hosts will neither listen on the link-
- scope multicast address, nor will they send queries to that address.
-
- An LLMNR sender may send a request for any name. However, by
- default, LLMNR requests SHOULD be sent only when one of the following
- conditions are met:
-
- [1] No manual or automatic DNS configuration has been
- performed. If DNS server address(es) have been
- configured, then LLMNR SHOULD NOT be used as the
- primary name resolution mechanism, although it MAY
- be used as a secondary name resolution mechanism.
-
- [2] DNS servers do not respond.
-
- [3] DNS servers respond to a DNS query with RCODE=3
- (Authoritative Name Error) or RCODE=0, and an empty
- answer section.
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] DNS servers are not configured or do not respond to a
- DNS query, or respond with RCODE=3, or RCODE=0 and an
- empty answer section.
-
- [b] An LLMNR sender sends an LLMNR query to the link-scope
- multicast address(es) defined in Section 2, unless a
- unicast query is indicated. A sender SHOULD send LLMNR
- queries for PTR RRs via unicast, as specified in Section 2.4.
-
- [c] A responder responds to this query only if it is authoritative
- for the domain name in the query. A responder responds to a
- multicast query by sending a unicast UDP response to the sender.
- Unicast queries are responded to as indicated in Section 2.4.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- [d] Upon reception of the response, the sender processes it.
-
- Further details of sender and responder behavior are provided in the
- sections that follow.
-
-2.1. LLMNR packet format
-
- LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4
- for both queries and responses. LLMNR implementations SHOULD send
- UDP queries and responses only as large as are known to be
- permissible without causing fragmentation. When in doubt a maximum
- packet size of 512 octets SHOULD be used. LLMNR implementations MUST
- accept UDP queries and responses as large as the smaller of the link
- MTU or 8192 octets.
-
-2.1.1. LLMNR header format
-
- LLMNR queries and responses utilize the DNS header format defined in
- [RFC1035] with exceptions noted below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode | Z|TC| U| C| Z| Z| Z| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value. For advice on generation of pseudo-random values, please
- consult [RFC1750].
-
-QR A one bit field that specifies whether this message is an LLMNR
- query (0), or an LLMNR response (1).
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set in an LLMNR response,
- then the sender SHOULD discard the response and resend the LLMNR
- query over TCP using the unicast address of the responder as the
- destination address. See [RFC2181] and Section 2.4 of this
- specification for further discussion of the TC bit.
-
-U UNIQUE - specifies that this message is a UNIQUEness query. The U
- bit MUST NOT be set in an LLMNR response, and if set is ignored by
- an LLMNR sender. If the U bit is set in an LLMNR query, this
- indicates that the sender believes that it is authoritative for the
- name. See Section 4.1 and 4.2 for discussion of name conflict
- detection.
-
-C Conflict - specifies that a sender has previously received multiple
- LLMNR responses to this query. The C bit MUST NOT be set in an
- LLMNR response, and if set is ignored by an LLMNR sender.
- Responders do not respond to LLMNR queries with the 'C' bit set;
- since no response is expected, LLMNR senders do not retransmit.
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the RCODE MUST be zero, and is
- ignored by the responder. The response to a multicast LLMNR query
- MUST have RCODE set to zero. A sender MUST silently discard an
- LLMNR response with a non-zero RCODE sent in response to a
- multicast query.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferable to not
- sending a response, since it enables errors to be diagnosed.
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender behavior
-
- A sender may send an LLMNR query for any legal resource record type
- (e.g., A, AAAA, SRV, etc.) to the link-scope multicast address.
-
- As described in Section 2.4, a sender may also send a unicast query.
- Sections 2 and 3 describe the circumstances in which LLMNR queries
- may be sent.
-
- The sender MUST anticipate receiving no replies to some LLMNR
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- queries, in the event that no responders are available within the
- link-scope or in the event no positive non-null responses exist for
- the transmitted query. If no positive response is received, a
- resolver treats it as a response that no records of the specified
- type and class exist for the specified name (it is treated the same
- as a response with RCODE=0 and an empty answer section).
-
- Since the responder may order the RRs in the response so as to
- indicate preference, the sender SHOULD preserve ordering in the
- response to the querying application.
-
- The sender MUST anticipate receiving multiple replies to the same
- LLMNR query, in the event that several LLMNR enabled computers
- receive the query and respond with valid answers. When multiple
- valid answers are received, they may first be concatenated, and then
- treated in the same manner that multiple RRs received from the same
- DNS server would; the sender perceives no inherent conflict in the
- receipt of multiple responses.
-
-2.3. Responder behavior
-
- An LLMNR response MUST be sent to the sender via unicast.
-
- Upon configuring an IP address, responders typically will synthesize
- corresponding A, AAAA and PTR RRs so as to be able to respond to
- LLMNR queries for these RRs. An SOA RR is synthesized only when a
- responder has another RR as well; the SOA RR MUST NOT be the only RR
- that a responder has. However, in general whether RRs are manually
- or automatically created is an implementation decision.
-
- For example, a host configured to have computer name "host1" and to
- be a member of the "example.com" domain, and with IPv4 address
- 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
- authoritative for the following records:
-
- host1. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- host1.example.com. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- 1.2.0.192.in-addr.arpa. IN PTR host1.
- IN PTR host1.example.com.
-
- 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
- ip6.arpa IN PTR host1. (line split for formatting reasons)
- IN PTR host1.example.com.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- An LLMNR responder might be further manually configured with the name
- of a local mail server with an MX RR included in the "host1." and
- "host1.example.com." records.
-
- In responding to queries:
-
-[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
- address(es) defined in Section 2, and on UDP and TCP port 5355 on
- the unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses MUST always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups, with the exception of queries with the 'C' bit
- set, which do not elicit a response.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-[e] Responders MUST NOT respond using data from the LLMNR or DNS
- resolver cache.
-
-[f] If a DNS server is running on a host that supports LLMNR, the DNS
- server MUST respond to LLMNR queries only for the RRSets relating
- to the host on which the server is running, but MUST NOT respond
- for other records for which the server is authoritative. DNS
- servers also MUST NOT send LLMNR queries in order to resolve DNS
- queries.
-
-[g] If a responder is authoritative for a name, it SHOULD respond with
- RCODE=0 and an empty answer section, if the type of query does not
- match a RR that the responder has.
-
- As an example, a host configured to respond to LLMNR queries for the
- name "foo.example.com." is authoritative for the name
- "foo.example.com.". On receiving an LLMNR query for an A RR with the
- name "foo.example.com." the host authoritatively responds with A
- RR(s) that contain IP address(es) in the RDATA of the resource
- record. If the responder has a AAAA RR, but no A RR, and an A RR
- query is received, the responder would respond with RCODE=0 and an
- empty answer section.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- In conventional DNS terminology a DNS server authoritative for a zone
- is authoritative for all the domain names under the zone apex except
- for the branches delegated into separate zones. Contrary to
- conventional DNS terminology, an LLMNR responder is authoritative
- only for the zone apex.
-
- For example the host "foo.example.com." is not authoritative for the
- name "child.foo.example.com." unless the host is configured with
- multiple names, including "foo.example.com." and
- "child.foo.example.com.". As a result, "foo.example.com." cannot
- reply to an LLMNR query for "child.foo.example.com." with RCODE=3
- (authoritative name error). The purpose of limiting the name
- authority scope of a responder is to prevent complications that could
- be caused by coexistence of two or more hosts with the names
- representing child and parent (or grandparent) nodes in the DNS tree,
- for example, "foo.example.com." and "child.foo.example.com.".
-
- In this example (unless this limitation is introduced) an LLMNR query
- for an A resource record for the name "child.foo.example.com." would
- result in two authoritative responses: RCODE=3 (authoritative name
- error) received from "foo.example.com.", and a requested A record -
- from "child.foo.example.com.". To prevent this ambiguity, LLMNR
- enabled hosts could perform a dynamic update of the parent (or
- grandparent) zone with a delegation to a child zone. In this example
- a host "child.foo.example.com." would send a dynamic update for the
- NS and glue A record to "foo.example.com.", but this approach
- significantly complicates implementation of LLMNR and would not be
- acceptable for lightweight hosts.
-
-2.4. Unicast queries and responses
-
- Unicast queries SHOULD be sent when:
-
- [a] A sender repeats a query after it received a response
- with the TC bit set to the previous LLMNR multicast query, or
-
- [b] The sender queries for a PTR RR of a fully formed IP address
- within the "in-addr.arpa" or "ip6.arpa" zones.
-
- Unicast LLMNR queries MUST be done using TCP and the responses MUST
- be sent using the same TCP connection as the query. Senders MUST
- support sending TCP queries, and responders MUST support listening
- for TCP queries. If the sender of a TCP query receives a response to
- that query not using TCP, the response MUST be silently discarded.
-
- Unicast UDP queries MUST be silently discarded.
-
- If TCP connection setup cannot be completed in order to send a
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- unicast TCP query, this is treated as a response that no records of
- the specified type and class exist for the specified name (it is
- treated the same as a response with RCODE=0 and an empty answer
- section).
-
-2.5. "Off link" detection
-
- For IPv4, an "on link" address is defined as a link-local address
- [IPv4Link] or an address whose prefix belongs to a subnet on the
- local link. For IPv6 [RFC2460] an "on link" address is either a
- link-local address, defined in [RFC2373], or one belonging to a
- prefix that a Router Advertisement indicates is on-link [RFC2461].
-
- A sender MUST select a source address for LLMNR queries that is "on
- link". The destination address of an LLMNR query MUST be a link-
- scope multicast address or an "on link" unicast address.
-
- A responder MUST select a source address for responses that is "on
- link". The destination address of an LLMNR response MUST be an "on
- link" unicast address.
-
- On receiving an LLMNR query, the responder MUST check whether it was
- sent to a LLMNR multicast addresses defined in Section 2. If it was
- sent to another multicast address, then the query MUST be silently
- discarded.
-
- Section 2.4 discusses use of TCP for LLMNR queries and responses. In
- composing an LLMNR query using TCP, the sender MUST set the Hop Limit
- field in the IPv6 header and the TTL field in the IPv4 header of the
- response to one (1). The responder SHOULD set the TTL or Hop Limit
- settings on the TCP listen socket to one (1) so that SYN-ACK packets
- will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
- prevents an incoming connection from off-link since the sender will
- not receive a SYN-ACK from the responder.
-
- For UDP queries and responses, the Hop Limit field in the IPv6 header
- and the TTL field in the IPV4 header MAY be set to any value.
- However, it is RECOMMENDED that the value 255 be used for
- compatibility with Apple Rendezvous.
-
- Implementation note:
-
- In the sockets API for IPv4 [POSIX], the IP_TTL and
- IP_MULTICAST_TTL socket options are used to set the TTL of
- outgoing unicast and multicast packets. The IP_RECVTTL socket
- option is available on some platforms to retrieve the IPv4 TTL of
- received packets with recvmsg(). [RFC2292] specifies similar
- options for setting and retrieving the IPv6 Hop Limit.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
-2.6. Responder responsibilities
-
- It is the responsibility of the responder to ensure that RRs returned
- in LLMNR responses MUST only include values that are valid on the
- local interface, such as IPv4 or IPv6 addresses valid on the local
- link or names defended using the mechanism described in Section 4.
- In particular:
-
- [a] If a link-scope IPv6 address is returned in a AAAA RR,
- that address MUST be valid on the local link over which
- LLMNR is used.
-
- [b] If an IPv4 address is returned, it MUST be reachable
- through the link over which LLMNR is used.
-
- [c] If a name is returned (for example in a CNAME, MX
- or SRV RR), the name MUST be resolvable on the local
- link over which LLMNR is used.
-
- Where multiple addresses represent valid responses to a query, the
- order in which the addresses are returned is as follows:
-
- [d] If the source address of the query is a link-scope address,
- then the responder SHOULD include a link-scope address first
- in the response, if available.
-
- [e] If the source address of the query is a routable address,
- then the responder MUST include a routable address first
- in the response, if available.
-
-2.7. Retransmission and jitter
-
- An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
- when to retransmit an LLMNR query and how long to collect responses
- to an LLMNR query.
-
- If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
- then a sender SHOULD repeat the transmission of the query in order to
- assure that it was received by a host capable of responding to it.
- Retransmission of UDP queries SHOULD NOT be attempted more than 3
- times. Where LLMNR queries are sent using TCP, retransmission is
- handled by the transport layer. Queries with the 'C' bit set MUST be
- sent over UDP and MUST NOT be retransmitted.
-
- Because an LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
- collect all possible responses, rather than considering the multicast
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- query answered after the first response is received. A unicast query
- sender considers the query answered after the first response is
- received, so that it only waits for LLMNR_TIMEOUT if no response has
- been received.
-
- An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
- for each transmission. For example, the algorithms described in RFC
- 2988 [RFC2988] (including exponential backoff) compute an RTO, which
- is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used
- for the initial RTO (discussed in Section 2 of [RFC2988], paragraph
- 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph
- 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988],
- paragraph 2.5).
-
- In order to avoid synchronization, the transmission of each LLMNR
- query and response SHOULD delayed by a time randomly selected from
- the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
- responders responding with RRs which they have previously determined
- to be UNIQUE (see Section 4 for details).
-
- Recommended values for constants (including LLMNR_TIMEOUT if it is
- set statically) are given in Section 7.
-
-2.8. DNS TTL
-
- The responder should insert a pre-configured TTL value in the records
- returned in an LLMNR response. A default value of 30 seconds is
- RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
- networks), the TTL value may need to be reduced.
-
- Due to the TTL minimalization necessary when caching an RRset, all
- TTLs in an RRset MUST be set to the same value.
-
-2.9. Use of the authority and additional sections
-
- Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
- concept of delegation. In LLMNR, the NS resource record type may be
- stored and queried for like any other type, but it has no special
- delegation semantics as it does in the DNS. Responders MAY have NS
- records associated with the names for which they are authoritative,
- but they SHOULD NOT include these NS records in the authority
- sections of responses.
-
- Responders SHOULD insert an SOA record into the authority section of
- a negative response, to facilitate negative caching as specified in
- [RFC2308]. The owner name of this SOA record MUST be equal to the
- query name.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- In LLMNR, the additional section is primarily intended for use by
- EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
- senders MAY only include pseudo RR-types in the additional section of
- a query; unless the 'C' bit is set, responders MUST ignore the
- additional section of queries containing other RR types.
-
- In queries where the 'C' bit is set, the sender SHOULD include the
- conflicting RRs in the additional section. Since conflict
- notifications are advisory, responders SHOULD log information from
- the additional section, but otherwise MUST ignore the additional
- section.
-
- Senders MUST NOT cache RRs from the authority or additional section
- of a response as answers, though they may be used for other purposes
- such as negative caching.
-
-3. Usage model
-
- Since LLMNR is a secondary name resolution mechanism, its usage is in
- part determined by the behavior of DNS implementations. This
- document does not specify any changes to DNS resolver behavior, such
- as searchlist processing or retransmission/failover policy. However,
- robust DNS resolver implementations are more likely to avoid
- unnecessary LLMNR queries.
-
- As noted in [DNSPerf], even when DNS servers are configured, a
- significant fraction of DNS queries do not receive a response, or
- result in negative responses due to missing inverse mappings or NS
- records that point to nonexistent or inappropriate hosts. This has
- the potential to result in a large number of unnecessary LLMNR
- queries.
-
- [RFC1536] describes common DNS implementation errors and fixes. If
- the proposed fixes are implemented, unnecessary LLMNR queries will be
- reduced substantially, and so implementation of [RFC1536] is
- recommended.
-
- For example, [RFC1536] Section 1 describes issues with retransmission
- and recommends implementation of a retransmission policy based on
- round trip estimates, with exponential backoff. [RFC1536] Section 4
- describes issues with failover, and recommends that resolvers try
- another server when they don't receive a response to a query. These
- policies are likely to avoid unnecessary LLMNR queries.
-
- [RFC1536] Section 3 describes zero answer bugs, which if addressed
- will also reduce unnecessary LLMNR queries.
-
- [RFC1536] Section 6 describes name error bugs and recommended
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- searchlist processing that will reduce unnecessary RCODE=3
- (authoritative name) errors, thereby also reducing unnecessary LLMNR
- queries.
-
-3.1. LLMNR configuration
-
- Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
- possible for a dual stack host to be configured with the address of a
- DNS server over IPv4, while remaining unconfigured with a DNS server
- suitable for use over IPv6.
-
- In these situations, a dual stack host will send AAAA queries to the
- configured DNS server over IPv4. However, an IPv6-only host
- unconfigured with a DNS server suitable for use over IPv6 will be
- unable to resolve names using DNS. Automatic IPv6 DNS configuration
- mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
- deployed, and not all DNS servers support IPv6. Therefore lack of
- IPv6 DNS configuration may be a common problem in the short term, and
- LLMNR may prove useful in enabling linklocal name resolution over
- IPv6.
-
- Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
- IPv6-only hosts may not be configured with a DNS server. Where there
- is no DNS server authoritative for the name of a host or the
- authoritative DNS server does not support dynamic client update over
- IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
- be able to do DNS dynamic update, and other hosts will not be able to
- resolve its name.
-
- For example, if the configured DNS server responds to a AAAA RR query
- sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
- RCODE=0 and an empty answer section, then a AAAA RR query sent using
- LLMNR over IPv6 may be successful in resolving the name of an
- IPv6-only host on the local link.
-
- Similarly, if a DHCPv4 server is available providing DNS server
- configuration, and DNS server(s) exist which are authoritative for
- the A RRs of local hosts and support either dynamic client update
- over IPv4 or DHCPv4-based dynamic update, then the names of local
- IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
- DNS server is authoritative for the names of local hosts, or the
- authoritative DNS server(s) do not support dynamic update, then LLMNR
- enables linklocal name resolution over IPv4.
-
- Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
- configure LLMNR on an interface. The LLMNR Enable Option, described
- in [LLMNREnable], can be used to explicitly enable or disable use of
- LLMNR on an interface. The LLMNR Enable Option does not determine
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- whether or in which order DNS itself is used for name resolution.
- The order in which various name resolution mechanisms should be used
- can be specified using the Name Service Search Option (NSSO) for DHCP
- [RFC2937], using the LLMNR Enable Option code carried in the NSSO
- data.
-
- It is possible that DNS configuration mechanisms will go in and out
- of service. In these circumstances, it is possible for hosts within
- an administrative domain to be inconsistent in their DNS
- configuration.
-
- For example, where DHCP is used for configuring DNS servers, one or
- more DHCP servers can fail. As a result, hosts configured prior to
- the outage will be configured with a DNS server, while hosts
- configured after the outage will not. Alternatively, it is possible
- for the DNS configuration mechanism to continue functioning while
- configured DNS servers fail.
-
- An outage in the DNS configuration mechanism may result in hosts
- continuing to use LLMNR even once the outage is repaired. Since
- LLMNR only enables linklocal name resolution, this represents a
- degradation in capabilities. As a result, hosts without a configured
- DNS server may wish to periodically attempt to obtain DNS
- configuration if permitted by the configuration mechanism in use. In
- the absence of other guidance, a default retry interval of one (1)
- minute is RECOMMENDED.
-
-4. Conflict resolution
-
- The uniqueness of a resource record depends on the nature of the name
- in the query and type of the query. For example it is expected that:
-
- - multiple hosts may respond to a query for an SRV type record
- - multiple hosts may respond to a query for an A or AAAA type
- record for a cluster name (assigned to multiple hosts in
- the cluster)
- - only a single host may respond to a query for an A or AAAA
- type record for a name.
-
- By default, a responder SHOULD be configured to behave as though all
- RRs are UNIQUE on each interface on which LLMNR is enabled.
-
- When name conflicts are detected, they SHOULD be logged. To detect
- duplicate use of a name, an administrator can use a name resolution
- utility which employs LLMNR and lists both responses and responders.
- This would allow an administrator to diagnose behavior and
- potentially to intervene and reconfigure LLMNR responders who should
- not be configured to respond to the same name.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
-4.1. Uniqueness Verification
-
- Prior to including a UNIQUE resource record in a response, for each
- UNIQUE resource record in a given interface's configuration, the host
- MUST verify that there is no other host within the scope of LLMNR
- query propagation that can return a resource record for the same
- name, type and class on that interface.
-
- Once a responder has verified the uniqueness of a UNIQUE resource
- record, if it receives an LLMNR query for that resource record, with
- the 'C' bit clear, it MUST respond.
-
- Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive
- during sleep)
- - is configured to respond to LLMNR queries on an interface
- enabled for transmission and reception of IP traffic
- - is configured to respond to LLMNR queries using additional
- UNIQUE resource records
- - verifies the acquisition of a new IP address and configuration
- on an interface
-
- To verify uniqueness, a responder MUST send an LLMNR query with the
- 'U' bit set for each UNIQUE resource record. If no response is
- received, the sender retransmits the query, as specified in Section
- 2.7. If a response is received, the responder MUST NOT use the UNIQUE
- resource record in response to LLMNR queries.
-
- Periodically carrying out uniqueness verification in an attempt to
- detect name conflicts is not necessary, wastes network bandwidth, and
- may actually be detrimental. For example, if network links are
- joined only briefly, and are separated again before any new
- communication is initiated, temporary conflicts are benign and no
- forced reconfiguration is required. Triggering a reconfiguration in
- this case would not serve any useful purpose. LLMNR responders
- SHOULD NOT periodically attempt uniqueness verification.
-
-4.2. Conflict Detection and Defense
-
- Hosts on disjoint network links may configure the same name for use
- with LLMNR. If these separate network links are later joined or
- bridged together, then there may be multiple hosts which are now on
- the same link, trying to use the same name.
-
- There are several mechanisms by which ongoing name conflicts may be
- detected:
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
-[a] Receipt of a query with the 'U' bit set. Whenever an LLMNR
- responder receives an LLMNR query for a UNIQUE resource record with
- the 'U' bit set, if the source IP address does not match an IP
- address configured on that interface, this indicates a conflict.
-
-[b] Conflict notification queries. When an LLMNR sender receives
- multiple LLMNR responses to a query, it MUST send another query for
- the same resource record, this time with the 'C' bit set, with the
- answers received included in the Additional section.
-
- Queries with the 'C' bit set are considered advisory and responders
- MUST verify the existence of a conflict by other means before
- acting on it. A responder receiving a query with the 'C' bit set
- MUST NOT respond. If the resource record is not UNIQUE, then the
- responder MUST ignore the query. If the resource record is UNIQUE,
- then the responder MUST send its own query for the same resource
- record, with the 'U' bit set. If a response is received, or if a
- query with the 'U' bit set is received, then a conflict has been
- detected.
-
-An LLMNR responder MUST NOT ignore conflicts once detected. An LLMNR
-responder MUST respond to a conflict as described in either [1] or [2]
-below:
-
-[1] Upon detecting a conflict, an LLMNR responder MAY elect to
- immediately stop using the conflicting UNIQUE resource record in
- response to LLMNR queries.
-
- The responder MAY also elect to configure a new name. However,
- since name reconfiguration may be disruptive, this is not required,
- and a responder may have been configured to respond to multiple
- names so that alternative names may already be available.
-
-[2] If a responder currently has reasons to prefer using the name, and
- it has not seen any other conflicting LLMNR queries within the last
- DEFEND_INTERVAL seconds, then it MAY elect to defend its name, by
- recording the time that the conflicting LLMNR query was received,
- and then sending multicast queries for its UNIQUE resource records,
- with the 'U' bit set.
-
- Having done this, an LLMNR responder can then continue to use the
- name normally without any further special action. However, if this
- is not the first conflicting LLMNR query the responder has seen,
- and the time recorded for the previous conflicting LLMNR query is
- recent, within DEFEND_INTERVAL, then the LLMNR responder MUST
- immediately cease using the conflicting resource records.
-
- This is necessary to ensure that two hosts do not get stuck in an
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- endless loop with both hosts trying to defend the same name.
-
-4.3. Considerations for Multiple Interfaces
-
- A multi-homed host may elect to configure LLMNR on only one of its
- active interfaces. In many situations this will be adequate.
- However, should a host need to configure LLMNR on more than one of
- its active interfaces, there are some additional precautions it MUST
- take. Implementers who are not planning to support LLMNR on multiple
- interfaces simultaneously may skip this section.
-
- Where a host is configured to issue LLMNR queries on more than one
- interface, each interface maintains its own independent LLMNR
- resolver cache, containing the responses to LLMNR queries.
-
- A multi-homed host checks the uniqueness of UNIQUE records as
- described in Section 4. The situation is illustrated in figure 1.
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
- In this situation, the multi-homed myhost will probe for, and defend,
- its host name on both interfaces. A conflict will be detected on one
- interface, but not the other. The multi-homed myhost will not be
- able to respond with a host RR for "myhost" on the interface on the
- right (see Figure 1). The multi-homed host may, however, be
- configured to use the "myhost" name on the interface on the left.
-
- Since names are only unique per-link, hosts on different links could
- be using the same name. If an LLMNR client sends requests over
- multiple interfaces, and receives replies from more than one, the
- result returned to the client is defined by the implementation. The
- situation is illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
- If host myhost is configured to use LLMNR on both interfaces, it will
- send LLMNR queries on both interfaces. When host myhost sends a
- query for the host RR for name "A" it will receive a response from
- hosts on both interfaces.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- Host myhost cannot distinguish between the situation shown in Figure
- 2, and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
- This illustrates that the proposed name conflict resolution mechanism
- does not support detection or resolution of conflicts between hosts
- on different links. This problem can also occur with unicast DNS
- when a multi-homed host is connected to two different networks with
- separated name spaces. It is not the intent of this document to
- address the issue of uniqueness of names within DNS.
-
-4.4. API issues
-
- [RFC2553] provides an API which can partially solve the name
- ambiguity problem for applications written to use this API, since the
- sockaddr_in6 structure exposes the scope within which each scoped
- address exists, and this structure can be used for both IPv4 (using
- v4-mapped IPv6 addresses) and IPv6 addresses.
-
- Following the example in Figure 2, an application on 'myhost' issues
- the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
- ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
- interfaces and the resolver library will return a list containing
- multiple addrinfo structures, each with an associated sockaddr_in6
- structure. This list will thus contain the IPv4 and IPv6 addresses
- of both hosts responding to the name 'A'. Link-local addresses will
- have a sin6_scope_id value that disambiguates which interface is used
- to reach the address. Of course, to the application, Figures 2 and 3
- are still indistinguishable, but this API allows the application to
- communicate successfully with any address in the list.
-
-5. Security Considerations
-
- LLMNR is by nature a peer-to-peer name resolution protocol. It is
- therefore inherently more vulnerable than DNS, since existing DNS
- security mechanisms are difficult to apply to LLMNR. While tools
- exist to allow an attacker to spoof a response to a DNS query,
- spoofing a response to an LLMNR query is easier since the query is
- sent to a link-scope multicast address, where every host on the
- logical link will be made aware of it.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- In order to address the security vulnerabilities, the following
- mechanisms are contemplated:
-
- [1] Scope restrictions.
- [2] Usage restrictions.
- [3] Cache and port separation.
- [4] Authentication.
-
- These techniques are described in the following sections.
-
-5.1. Scope restriction
-
- With LLMNR it is possible that hosts will allocate conflicting names
- for a period of time, or that attackers will attempt to deny service
- to other hosts by allocating the same name. Such attacks also allow
- hosts to receive packets destined for other hosts.
-
- Since LLMNR is typically deployed in situations where no trust model
- can be assumed, it is likely that LLMNR queries and responses will be
- unauthenticated. In the absence of authentication, LLMNR reduces the
- exposure to such threats by utilizing UDP queries sent to a link-
- scope multicast address, as well as setting the TTL (IPv4) or Hop
- Limit (IPv6) fields to one (1) on TCP queries and responses.
-
- Using a TTL of one (1) to set up a TCP connection in order to send a
- unicast LLMNR query reduces the likelihood of both denial of service
- attacks and spoofed responses. Checking that an LLMNR query is sent
- to a link-scope multicast address should prevent spoofing of
- multicast queries by off-link attackers.
-
- While this limits the ability of off-link attackers to spoof LLMNR
- queries and responses, it does not eliminate it. For example, it is
- possible for an attacker to spoof a response to a query (such as an A
- or AAAA query for a popular Internet host), and by using a TTL or Hop
- Limit field larger than one (1), for the forged response to reach the
- LLMNR sender.
-
- When LLMNR queries are sent to a link-scope multicast address, it is
- possible that some routers may not properly implement link-scope
- multicast, or that link-scope multicast addresses may leak into the
- multicast routing system.
-
- Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than
- one in an LLMNR UDP response may enable denial of service attacks
- across the Internet. However, since LLMNR responders only respond to
- queries for which they are authoritative, and LLMNR does not provide
- wildcard query support, it is believed that this threat is minimal.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- There also are scenarios such as public "hotspots" where attackers
- can be present on the same link. These threats are most serious in
- wireless networks such as 802.11, since attackers on a wired network
- will require physical access to the home network, while wireless
- attackers may reside outside the home. Link-layer security can be of
- assistance against these threats if it is available.
-
-5.2. Usage restriction
-
- As noted in Sections 2 and 3, LLMNR is intended for usage in a
- limited set of scenarios.
-
- If an LLMNR query is sent whenever a DNS server does not respond in a
- timely way, then an attacker can poison the LLMNR cache by responding
- to the query with incorrect information. To some extent, these
- vulnerabilities exist today, since DNS response spoofing tools are
- available that can allow an attacker to respond to a query more
- quickly than a distant DNS server.
-
- Since LLMNR queries are sent and responded to on the local-link, an
- attacker will need to respond more quickly to provide its own
- response prior to arrival of the response from a legitimate
- responder. If an LLMNR query is sent for an off-link host, spoofing a
- response in a timely way is not difficult, since a legitimate
- response will never be received.
-
- The vulnerability is more serious if LLMNR is given higher priority
- than DNS among the enabled name resolution mechanisms. In such a
- configuration, a denial of service attack on the DNS server would not
- be necessary in order to poison the LLMNR cache, since LLMNR queries
- would be sent even when the DNS server is available. In addition,
- the LLMNR cache, once poisoned, would take precedence over the DNS
- cache, eliminating the benefits of cache separation. As a result,
- LLMNR is only used as a name resolution mechanism of last resort.
-
-5.3. Cache and port separation
-
- In order to prevent responses to LLMNR queries from polluting the DNS
- cache, LLMNR implementations MUST use a distinct, isolated cache for
- LLMNR on each interface. The use of separate caches is most effective
- when LLMNR is used as a name resolution mechanism of last resort,
- since this minimizes the opportunities for poisoning the LLMNR cache,
- and decreases reliance on it.
-
- LLMNR operates on a separate port from DNS, reducing the likelihood
- that a DNS server will unintentionally respond to an LLMNR query.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
-5.4. Authentication
-
- LLMNR implementations MAY support TSIG and/or SIG(0) security
- mechanisms. Since LLMNR does not support "delegated trust" (CD or AD
- bits), and LLMNR senders are unlikely to be DNSSEC-aware, in practice
- LLMNR is not compatible with DNSSEC.
-
- Since LLMNR implementations MAY NOT support TSIG or SIG(0), responses
- to LLMNR queries may be unauthenticated. If authentication is
- desired, and a pre-arranged security configuration is possible, then
- IPsec ESP with a null-transform MAY be used to authenticate unicast
- LLMNR queries and responses or LLMNR responses to multicast queries.
- In a small network without a certificate authority, this can be most
- easily accomplished through configuration of a group pre-shared key
- for trusted hosts.
-
-6. IANA Considerations
-
- This specification creates one new name space: the reserved bits in
- the LLMNR header. These are allocated by IETF Consensus, in
- accordance with BCP 26 [RFC2434].
-
- LLMNR requires allocation of port 5355 for both TCP and UDP.
-
- LLMNR requires allocation of link-scope multicast IPv4 address
- 224.0.0.252, as well as link-scope multicast IPv6 address
- FF02:0:0:0:0:0:1:3.
-
-7. Constants
-
- The following timing constants are used in this protocol; they are
- not intended to be user configurable.
-
- DEFEND_INTERVAL 10 seconds (minimum interval between
- defensive LLMNR queries).
- JITTER_INTERVAL 100 ms
- LLMNR_TIMEOUT 1 second (only if set statically)
- RTOinit 500 ms (initial value of LLMNR_TIMEOUT)
- RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT)
- RTOmin 100 ms (minimum value of LLMNR_TIMEOUT)
-
-8. References
-
-8.1. Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
-[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 2460, December 1998.
-
-[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
- for IP Version 6 (IPv6)", RFC 2461, December 1998.
-
-[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
- Timer", RFC 2988, November 2000.
-
-8.2. Informative References
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
-[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
- Caching", IEEE/ACM Transactions on Networking, Volume 10,
- Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- Internet draft (work in progress), draft-ietf-ipv6-dns-
- discovery-07.txt, October 2002.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[NodeInfo]
- Crawford, M., "IPv6 Node Information Queries", Internet draft
- (work in progress), draft-ietf-ipn-gwg-icmp-name-
- lookups-09.txt, May 2002.
-
-Acknowledgments
-
- This work builds upon original work done on multicast DNS by Bill
- Manning and Bill Woodcock. Bill Manning's work was funded under
- DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
- their contribution to the current specification. Constructive input
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 26]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- has also been received from Mark Andrews, Rob Austein, Randy Bush,
- Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
- Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
- Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
- Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
- St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 706 6605
- EMail: bernarda@microsoft.com
-
- Dave Thaler
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 703 8835
- EMail: dthaler@microsoft.com
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property 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; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 27]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 19 February 2005
-
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-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.
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 28]
-
-
-
-
+++ /dev/null
-
-
-Network Working Group B. Laurie
-Internet-Draft G. Sisson
-Expires: August 2, 2005 Nominet
- R. Arends
- Telematica Instituut
- february 2005
-
-
- DNSSEC Hash Authenticated Denial of Existence
- draft-ietf-dnsext-nsec3-01
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 August 2, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be
- used to provide authenticated denial of existence of DNS ownernames
- and types; however, it permits any user to traverse a zone and obtain
- a listing of all ownernames.
-
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 1]
-\f
-Internet-Draft nsec3 february 2005
-
-
- A complete zone file can be used either directly as a source of
- probable e-mail addresses for spam, or indirectly as a key for
- multiple WHOIS queries to reveal registrant data which many
- registries (particularly in Europe) may be under strict legal
- obligations to protect. Many registries therefore prohibit copying
- of their zone file; however the use of NSEC RRs makes renders
- policies unenforceable.
-
- This document proposes a scheme which obscures original ownernames
- while permitting authenticated denial of existence of non-existent
- names. Non-authoritative delegation point NS RR types may be
- excluded.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5
- 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5
- 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6
- 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6
- 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 6
- 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 6
- 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 6
- 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7
- 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 7
- 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 8
- 3. Creating Additional NSEC3 RR for Empty Non Terminals . . . . . 9
- 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 9
- 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 9
- 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 10
- 6.1 delegation points . . . . . . . . . . . . . . . . . . . . 10
- 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11
- 6.2 Additional Complexity Caused by Wildcards . . . . . . . . 11
- 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 12
- 6.4.1 Avoiding Hash Collisions during generation . . . . . . 12
- 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 12
- 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 13
- 7. Performance Considerations . . . . . . . . . . . . . . . . . . 13
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
- 10. Requirements notation . . . . . . . . . . . . . . . . . . . 14
- 11. Security Considerations . . . . . . . . . . . . . . . . . . 14
- A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 2]
-\f
-Internet-Draft nsec3 february 2005
-
-
- 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 15
- 12.2 Informative References . . . . . . . . . . . . . . . . . . . 16
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
- Intellectual Property and Copyright Statements . . . . . . . . 18
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 3]
-\f
-Internet-Draft nsec3 february 2005
-
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) introduced the NSEC Resource
- Record (RR) for Authenticated Denial of Existence. This document
- introduces a new RR as an alternative to NSEC that provides measures
- against zone traversal and allows for gradual expansion of
- delegation-centric zones.
-
-1.1 Rationale
-
- The DNS Security Extensions included the NSEC RR to provide
- authenticated denial of existence. Though the NSEC RR meets the
- requirements for authenticated denial of Existence, it introduced a
- side-effect in that the contents of a zone can be enumerated. This
- property introduces undesired policy issues.
-
- A second requirement was that the existence of all record types in a
- zone -including delegation point NS record types- can be accounted
- for, despite the fact that delegation point NS RRsets are not
- authoritative and not signed. This requirement has a side-effect
- that the overhead of delegation centric signed zones is not related
- to the increase in security of subzones. This requirement does not
- allow delegation centric zones size to grow in relation to the growth
- of signed subzones.
-
- In the past, solutions have been proposed as a measure against these
- side effects but at the time were regarded as secondary over the need
- to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter)
- a graceful transition path to future enhancements is introduced,
- while current DNSSEC deployment can continue. This document
- accumulates measures against the side effects introduced by NSEC, and
- presents the NSEC3 Resource Record.
-
- The reader is assumed to be familiar with the basic DNS concepts
- described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs
- that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308
- [RFC2308].
-
-1.2 Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1.3 Terminology
-
- In this document the term "original ownername" refers to a standard
- ownername. Because this proposal uses the result of a hash function
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 4]
-\f
-Internet-Draft nsec3 february 2005
-
-
- over the original (unmodified) ownername, this result is referred to
- as "hashed ownername".
-
-2. The NSEC3 Resource Record
-
- The NSEC3 RR provides Authenticated Denial of Existence for DNS
- Resource Record Sets.
-
- The NSEC3 Resource Record lists RR types present at the NSEC3 RR's
- original ownername. It includes the next hashed ownername in the
- canonical ordering of the zone. The complete set of NSEC3 RRs in a
- zone indicates which RRsets exist for the original ownername of the
- RRset and form a chain of hashed ownernames in the zone. This
- information is used to provide authenticated denial of existence for
- DNS data, as described in RFC 2535 [RFC2535]. Unsigned delegation
- point NS RR sets can optionally be excluded. To provide protection
- against zone traversal, the ownernames used in the NSEC3 RR are
- cryptographic hash-value prepended to the name of the zone. The
- NSEC3 RR record indicates which Hash Function is used to construct to
- hash, which Salt is used, and how many iterations of the Hash
- Function are performed over the original ownername.
-
- The type value for the NSEC3 RR is XX.
-
- The NSEC3 RR RDATA format is class independent.
-
- The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
- field. This is in the spirit of negative caching [RFC2308].
-
-2.1 NSEC3 RDATA Wire Format
-
- The RDATA of the NSEC3 RR is as shown below:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |A|Hash Function| Iterations |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Salt Length | Salt /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Next Hashed Ownername /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Type Bit Maps /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 5]
-\f
-Internet-Draft nsec3 february 2005
-
-
-2.1.1 The Authoritative Only Flag Field
-
- The Authoritative Only Flag field indicates whether the Type Bit Maps
- include delegation point NS record types.
-
- If the flag is set to 1, the NS RR type bit for a delegation point
- ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR
- type bit MUST be ignored during processing of the NSEC3 RR. The NS
- RR type bit has no meaning in this context (it is not authoritative),
- hence the NSEC3 does not contest the existence of a NS RR type record
- for this ownername. When a delegation is not secured, there exist no
- DS RR type nor any other authoritative types for this delegation,
- hence the unsecured delegation has no NSEC3 record associated.
- Please see the Special Consideration section for implications for
- unsigned delegations.
-
- If the flag is set to 0, the NS RR type bit for a delegation point
- ownername MUST be set if the NSEC3 covers a delegation, even though
- the NS RR itself is not authoritative. This implies that all
- delegations, signed or unsigned, have an NSEC3 record associated.
- This behaviour is identical to NSEC behaviour.
-
-2.1.2 The Hash Function Field
-
- The Hash Function field identifies the cryptographic hash function
- used to construct the hash-value.
-
- This document defines Value 1 for SHA-1 and Value 127 for
- Experimental. All other values are reserved.
-
- On reception, a resolver MUST discard an NSEC3 RR with an unknown
- Hash Function value.
-
-2.1.3 The Iterations Field
-
- The Iterations field defines the number of times the hash has been
- iterated. More iterations results in greater resiliency of the hash
- value against dictionary attacks, but at a higher cost for both the
- server and resolver.
-
-2.1.4 The Salt Length Field
-
- The Salt Length Field defines the length of the salt in octets.
-
-2.1.5 The Salt Field
-
- The salt field is not present when the Salt Length Field has a value
- of 0.
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 6]
-\f
-Internet-Draft nsec3 february 2005
-
-
- The salt field is prepended to the original ownername before hashing
- in order to defend against precalculated dictionary attacks.
-
- The salt is not prepended during iterations of the hash function.
-
- The Salt field value MUST be identical for all NSEC3 RRs generated
- for the zone. If the salt were different for each NSEC3 RR,
- collisions could occur where an NSEC3 denies the existence of
- existing RRs due to the application of different salt values.
-
-2.1.6 The Next Hashed Ownername Field
-
- The Next Hashed Ownername Field contains the hash of the ownername of
- the next RR in the canonical ordering of the hashed ownernames of the
- zone. The value of the Next Hashed Ownername Field in the last NSEC3
- record in the zone is the same as the ownername of the first NSEC3 RR
- in the zone in canonical order.
-
- A sender MUST NOT use DNS name compression on the Next Hashed
- Ownername field when transmitting an NSEC3 RR.
-
- Hashed ownernames of RRsets not authoritative for the given zone
- (such as glue records) MUST NOT be listed in the Hash of Next Domain
- Name unless at least one authoritative RRset exists at the same owner
- name.
-
-2.1.7 The list of Type Bit Map(s) Field
-
- The Type Bit Maps field identifies the RRset types which exist at the
- NSEC3 RR's ownername.
-
- The Type bit for the NSEC3 and RRSIG MUST be set during generation,
- and MUST be ignored during processing.
-
- The RR type space is split into 256 window blocks, each representing
- the low-order 8 bits of the 16-bit RR type space. Each block that
- has at least one active RR type is encoded using a single octet
- window number (from 0 to 255), a single octet bitmap length (from 1
- to 32) indicating the number of octets used for the window block's
- bitmap, and up to 32 octets (256 bits) of bitmap.
-
- Blocks are present in the NSEC3 RR RDATA in increasing numerical
- order.
-
- "|" denotes concatenation
-
- Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 7]
-\f
-Internet-Draft nsec3 february 2005
-
-
- Each bitmap encodes the low-order 8 bits of RR types within the
- window block, in network bit order. The first bit is bit 0. For
- window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
- to RR type 2 (NS), and so forth. For window block 1, bit 1
- corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
- 1, it indicates that an RRset of that type is present for the NSEC3
- RR's ownername. If a bit is set to 0, it indicates that no RRset of
- that type is present for the NSEC3 RR's ownername.
-
- The RR type 2 (NS) is authoritative at the apex of a zone and is not
- authoritative at delegation points. If the Authoritative Only Flag
- is set to 1, the delegation point NS RR type MUST NOT be included in
- the type bit maps. If the Authoritative Only Flag is set to 0, the
- NS RR type at a delegation point MUST be included in the type bit
- maps.
-
- Since bit 0 in window block 0 refers to the non-existing RR type 0,
- it MUST be set to 0. After verification, the validator MUST ignore
- the value of bit 0 in window block 0.
-
- Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4]
- (section 3.1) or within the range reserved for assignment only to
- QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
- zone data. If encountered, they must be ignored upon reading.
-
- Blocks with no types present MUST NOT be included. Trailing zero
- octets in the bitmap MUST be omitted. The length of each block's
- bitmap is determined by the type code with the largest numerical
- value, within that block, among the set of RR types present at the
- NSEC3 RR's actual ownername. Trailing zero octets not specified MUST
- be interpreted as zero octets.
-
-2.2 The NSEC3 RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Authoritative Only Field is represented as an unsigned decimal
- integer. The value are either 0 or 1.
-
- The Hash field is presented as the name of the hash or as an unsigned
- decimal integer. The value has a maximum of 127.
-
- The Iterations field is presented as an unsigned decimal integer.
-
- The Salt Length field is not presented.
-
- The Salt field is represented as a sequence of case-insensitive
- hexadecimal digits. Whitespace is not allowed within the sequence.
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 8]
-\f
-Internet-Draft nsec3 february 2005
-
-
- The Salt Field is represented as 00 when the Salt Length field has
- value 0.
-
- The Hash of Next Domain Name field is represented as a sequence of
- case-insensitive base32 digits. Whitespace is allowed within the
- sequence.
-
- The List of Type Bit Map(s) Field is represented as a sequence of RR
- type mnemonics. When the mnemonic is not known, the TYPE
- representation as described in RFC 3597 [5] (section 5) MUST be used.
-
-3. Creating Additional NSEC3 RR for Empty Non Terminals
-
- In order to prove the non-existence of a record that might be covered
- by a wildcard, it is necessary to prove the existence of its closest
- encloser. A closest encloser might be an Empty Non Terminal.
-
- Additional NSEC3 RRs cover every existing intermediate label level.
- Additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
- existing RRs in the zone. The difference is that the type-bit-maps
- only indicate the existence of an NSEC3 RR and a RRSIG type.
-
-4. Calculation of the Hash
-
- Define H(x) to be the hash of x using the hash function selected by
- the NSEC3 record and || to indicate concatenation. Then define:
-
- IH(salt,x,0)=H(x || salt)
-
- IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
-
- Then the calculated hash of an ownername is
- IH(salt,ownername,iterations-1), where the ownername is the canonical
- form.
-
- The canonical form of the ownername is the wire format of the
- ownername where:
- 1. The ownername is fully expanded (no DNS name compression) and
- fully qualified;
- 2. All uppercase US-ASCII letters are replaced by the corresponding
- lowercase US-ASCII letters;
- 3. If the ownername is a wildcard name, the ownername is in its
- original unexpanded form, including the "*" label (no wildcard
- substitution);
-
-5. Including NSEC3 RRs in a Zone
-
- Each owner name in the zone which has authoritative data or a secured
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 9]
-\f
-Internet-Draft nsec3 february 2005
-
-
- delegation point NS RRset MUST have an NSEC3 resource record.
-
- An unsecured delegation point NS RRset MAY have an NSEC3 resource
- record. This is different from NSEC records where an unsecured
- delegation point NS RRset MUST have an NSEC record.
-
- The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
- value field in the zone SOA RR.
-
- The type bitmap of every NSEC3 resource record in a signed zone MUST
- indicate the presence of both the NSEC3 record itself and its
- corresponding RRSIG record.
-
- The bitmap for the NSEC3 RR at a delegation point requires special
- attention. Bits corresponding to the delegation NS RRset and any
- RRsets for which the parent zone has authoritative data MUST be set;
- bits corresponding to any non-NS RRset for which the parent is not
- authoritative MUST be clear.
-
- The following steps describe the proper construction of NSEC3
- records.
- 1. Sort the zone in canonical order.
- 2. For each unique original owner name, add a NSEC3 RRset, where the
- ownername of the NSEC3 RR is the hashed equivalent of the
- original owner name, prepended to the zone name.
- 3. For each RRset at the original owner, set the corresponding bit
- in the type bit map. If the RRset signifies an unsecured
- delegation point, and the policy is to have Authoritative Only
- RRsets, mark this NSEC3 RR.
- 4. If the difference in labels between the apex and the original
- ownername is greater then 1, additional NSEC3 need to be added
- for every intermediate label level between the apex and the
- original ownername.
- 5. sort the set of NSEC3 RRs.
- 6. In each NSEC3 RR, insert the Next Hashed Ownername. If the next
- hashed ownername is a marked NSEC3 (from step 3), delete the
- marked NSEC3 from the zone, set the Authoritative Only bit in the
- current NSEC3 RRs, and repeat this step. The last NSEC3 in the
- zone will contain the value of the first NSEC3 in the zone.
-
-6. Special Considerations
-
- The following paragraphs clarify specific behaviour explain special
- considerations for implementations.
-
-6.1 delegation points
-
- This proposal introduces the Authoritative Only Flag which indicates
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 10]
-\f
-Internet-Draft nsec3 february 2005
-
-
- whether non authoritative delegation point NS records are included in
- the type bit Maps. As discussed in paragraph 2.1.1, a flag value of
- 0 indicates that the interpretation of the type bit maps is identical
- to NSEC records.
-
- The following subsections describe behaviour when the flag value is
- 1.
-
-6.1.1 Unsigned Delegations
-
- Delegation point NS records are not authoritative. They are
- authoritative in the delegated zone. No other data exists at the
- ownername of an unsigned delegation point.
-
- Since no authoritative data exist at this ownername, it is excluded
- from the NSEC3 chain. This is an optimization since it relieves the
- zone of including an NSEC3 record and its associated signature for
- this name.
-
- An NSEC3 that denies existence of ownernames between X and X' with
- the Authoritative Only Flag set to 1 can not be used to proof
- presence nor absence of the delegation point NS records for unsigned
- delegations in the interval X, X'. The Authoritative Only Flag
- effectively states No Contest on the presence of delegation point NS
- resource records.
-
- Since proof is absent, there exists a new attack vector. Unsigned
- delegation point NS records can be deleted during a man in the middle
- attack, effectively denying existence of the delegation. This is a
- form of Denial of Service, where the victim has no information it is
- under attack, since all signatures are valid and the fabricated
- response form is a known type of response.
-
- The only possible mitigation is to either not use this method, hence
- proving existence or absence of unsigned delegations, or signing the
- delegated zone, changing the unsigned delegation into a signed
- delegation.
-
- A second attack vector exists in that an adversary is able to
- successfully fabricate a response claiming a not existent delegation
- to exist, though unsigned.
-
- The only possible mitigation is to either not use this method, hence
- proving absence of unsigned delegations.
-
-6.2 Additional Complexity Caused by Wildcards
-
- If a wildcard ownername appears in a zone, the wildcard label ("*")
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 11]
-\f
-Internet-Draft nsec3 february 2005
-
-
- is treated as a literal symbol and is treated in the same way as any
- other ownername for purposes of generating NSEC3 RRs. RFC 2535
- [RFC2525] describes the impact of wildcards on authenticated denial
- of existence.
-
- In order to prove there are no wildcards for a domain, as well as no
- RRs that match directly, an RR must be shown for the closest
- encloser, and non-existence must be shown for all enclosers that
- could be closer.
-
-6.3 Salting
-
- Augmenting original ownernames with salt before hashing increases the
- cost of a dictionary of pre-generated hash-values. For every bit of
- salt, the cost of the dictionary doubles. The NSEC3 RR can use
- maximum 2040 bits of salt, multiplying the cost by 2^2040.
-
- The salt value for each NSEC3 RR MUST be equal for a single version
- of the zone.
-
-6.4 Hash Collision
-
- Hash collisions occur when different messages have the same hash
- value. The expected number of domain names needed to give a 1 in 2
- chance of a single collision is about 2^80. Though this probability
- is extremely low, the following paragraphs deal with avoiding
- collisions and assessing possible damage in the event of an attack
- using Hash collisions.
-
-6.4.1 Avoiding Hash Collisions during generation
-
- During generation of NSEC3 RRs, hash values are supposedly unique.
- In the (academic) case of a collision occurring, an alternative salt
- SHOULD be chosen and all hash values SHOULD be regenerated.
-
- If hash values are not regenerated on collision, the NSEC3 RR MUST
- list all authoritative RR types that exist for both owners, to avoid
- a replay attack, spoofing an existing type as non-existent.
-
-6.4.2 Second Preimage Requirement Analysis
-
- A collision resistant hash function has a second-preimage resistance
- property. The second-preimage resistance property means that it is
- computationally infeasible to find another message with the same hash
- value as a given message, i.e. given preimage X, to find a second
- preimage X' <> X such that hash(X) = hash(X'). The probability of
- finding a second preimage is 1 in 2^160 for SHA-1 on average. To
- mount an attack using an existing NSEC3 RR, an adversary needs to
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 12]
-\f
-Internet-Draft nsec3 february 2005
-
-
- find a second preimage.
-
- Assuming an adversary is capable of mounting such an extreme attack,
- the actual damage is that a response message can be generated which
- claims that a certain QNAME (i.e. the second pre-image) does exist,
- while in reality QNAME does not exist (a false positive), which will
- either cause a security aware resolver to re-query for the
- non-existent name, or to fail the initial query. Note that the
- adversary can't mount this attack on an existing name but only on a
- name that the adversary can't choose and does not yet exist.
-
-6.4.3 Possible Hash Value Truncation Method
-
- The previous sections outlined the low probability and low impact of
- a second-preimage attack. When impact and probability are low, while
- space in a DNS message is costly, truncation is tempting. Truncation
- might be considered to allow for shorter ownernames and rdata for
- hashed labels. In general, if a cryptographic hash is truncated to n
- bits, then the expected number of domains required to give a 1 in 2
- probability of a single collision is approximately 2^(n/2) and the
- work factor to produce a second preimage resistance is 2^n.
-
- An extreme hash value truncation would be truncating to the shortest
- possible unique label value. Considering that hash values are
- presented in base32, which represents 5 bits per label character,
- truncation must be done on a 5 bit boundary. This would be unwise,
- since the work factor to produce collisions would then approximate
- the size of the zone.
-
- Though the mentioned truncation can be maximized to a certain
- extreme, the probability of collision increases exponentially for
- every truncated bit. Given the low impact of hash value collisions
- and limited space in DNS messages, the balance between truncation
- profit and collision damage may be determined by local policy.
-
-7. Performance Considerations
-
- Iterated hashes will obviously impose a performance penalty on both
- authoritative servers and resolvers. Therefore, the number of
- iterations should be carefully chosen.
-
-8. IANA Considerations
-
- IANA has to create a new registry for NSEC3 Hash Functions. The
- range for this registry is 0-127. Value 1 is marked as SHA-1.
- Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is
- marked as Experimental.
-
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 13]
-\f
-Internet-Draft nsec3 february 2005
-
-
-9. Security Considerations
-
- The NSEC3 records are still susceptible to dictionary attacks (i.e.
- the attacker retrieves all the NSEC3 records, then calculates the
- hashes of all likely domain names, comparing against the hashes found
- in the NSEC3 records, and thus enumerating the zone). These are
- substantially more expensive than traversing the original NSEC
- records would have been, and in any case, such an attack could also
- be used directly against the name server itself by performing queries
- for all likely names. The expense of this attack can be chosen by
- setting the iterations in the NSEC3 RR.
-
- High-value domains are also susceptible to a precalculated dictionary
- attack - that is, a list of hashes for all likely names is computed
- once, then NSEC3 is scanned periodically and compared against the
- precomputed hashes. This attack is prevented by changing the salt on
- a regular basis.
-
- Walking the NSEC3 RRs will reveal the total number of records in the
- zone, and also what types they are. This could be mitigated by
- adding dummy entries, but certainly an upper limit can always be
- found.
-
- Hash collisions may occur. If they do, it will be impossible to
- prove the non-existence of the colliding domain - however, this is
- fantastically unlikely, and, in any case, DNSSEC already relies on
- SHA-1 to not collide.
-
-10. Requirements notation
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-11. Security Considerations
-
-Appendix A. Example Zone
-
- This is a zone showing its NSEC3 records. They can also be used as
- test vectors for the hash algorithm. RRSIG records have been elided.
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 14]
-\f
-Internet-Draft nsec3 february 2005
-
-
- example.com. 1000 IN SOA localhost.
- postmaster.localhost.example.com. (
- 1 ; serial
- 3600 ; refresh (1 hour)
- 1800 ; retry (30 minutes)
- 604800 ; expire (1 week)
- 3600 ; minimum (1 hour)
- )
- 1000 NS ns1.example.com.
- 1000 NS ns2.example.com.
- f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC3 \
- SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \
- NS SOA RRSIG DNSKEY NSEC3
- a.example.com. 1000 IN A 1.2.3.4
- 1000 IN A 1.2.3.5
- 1000 TXT "An example"
- bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \
- SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \
- A TXT RRSIG NSEC3
- b.example.com. 1000 IN A 1.2.3.7
- 83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC3 \
- SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \
- A RRSIG NSEC3
- a.b.c.example.com. 1000 IN A 1.2.3.6
- a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \
- SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \
- A RRSIG NSEC3
- ns1.example.com. 1000 IN A 1.2.3.8
- 4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC3 \
- SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \
- A RRSIG NSEC3
- ns2.example.com. 1000 IN A 1.2.3.9
- 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \
- SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \
- A RRSIG NSEC3
-
-
-12. References
-
-12.1 Normative References
-
- [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.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 15]
-\f
-Internet-Draft nsec3 february 2005
-
-
- Requirement Levels", BCP 14, RFC 2119, March 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.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
-12.2 Informative References
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
- [RFC2418] Bradner, S., "IETF Working Group Guidelines and
- Procedures", BCP 25, RFC 2418, September 1998.
-
- [rollover]
- Ihren, J., Kolkman, O. and B. Manning, "An In-Band
- Rollover Algorithm and a Out-Of-Band Priming Method for
- DNS Trust Anchors.", July 2004.
-
-
-Authors' Addresses
-
- Ben Laurie
- Nominet
- 17 Perryn Road
- London W3 7LR
- England
-
- Phone: +44 (20) 8735 0686
- EMail: ben@algroup.co.uk
-
-
- Geoffrey Sisson
- Nominet
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 16]
-\f
-Internet-Draft nsec3 february 2005
-
-
- Roy Arends
- Telematica Instituut
- Brouwerijstraat 1
- 7523 XC Enschede
- The Netherlands
-
- Phone: +31 (53) 485 0485
- EMail: roy.arends@telin.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 17]
-\f
-Internet-Draft nsec3 february 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.
-
-
-
-
-Laurie, et al. Expires August 2, 2005 [Page 18]
-\f
-
+++ /dev/null
-
-
-INTERNET-DRAFT DSA Information in the DNS
-OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2005 March 2005
-
-
- DSA Keying and Signature Information in the DNS
- --- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-05.txt>
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- By submitting this Internet-Draft, I certify that any applicable
- patent or other IPR claims of which I am aware have been disclosed,
- or will be disclosed, and any of which I become aware will be
- disclosed, in accordance with RFC 3668.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- 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 a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method of encoding US Government Digital Signature
- Algorithm keying and signature information for use in the Domain Name
- System is specified.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DSA Keying Information..................................3
- 3. DSA Signature Information...............................4
- 4. Performance Considerations..............................4
- 5. Security Considerations.................................5
- 6. IANA Considerations.....................................5
- Copyright and Disclaimer...................................5
-
- Normative References.......................................7
- Informative References.....................................7
- Authors Address............................................8
- Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC intro, proto, records] and additional work is underway which
- would require the storage of keying and signature information in the
- DNS.
-
- This document describes how to encode US Government Digital Signature
- Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
- US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
- When DSA public keys are stored in the DNS, the structure of the
- relevant part of the RDATA part of the RR being used is the fields
- listed below in the order given.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- Field Size
- ----- ----
- T 1 octet
- Q 20 octets
- P 64 + T*8 octets
- G 64 + T*8 octets
- Y 64 + T*8 octets
-
- As described in [FIPS 186-2] and [Schneier], T is a key size
- parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
- is greater than 8 is reserved and the remainder of the data may have
- a different format in that case.) Q is a prime number selected at
- key generation time such that 2**159 < Q < 2**160. Thus Q is always
- 20 octets long and, as with all other fields, is stored in "big-
- endian" network order. P, G, and Y are calculated as directed by the
- [FIPS 186-2] key generation algorithm [Schneier]. P is in the range
- 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
- and Y are quantities modulo P and so can be up to the same length as
- P and are allocated fixed size fields with the same number of octets
- as P.
-
- During the key generation process, a random number X must be
- generated such that 1 <= X <= Q-1. X is the private key and is used
- in the final step of public key generation where Y is computed as
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
- The portion of the RDATA area used for US Digital Signature Algorithm
- signature information is shown below with fields in the order they
- are listed and the contents of each multi-octet field in "big-endian"
- network order.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- First, the data signed must be determined. Then the following steps
- are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
- specified in the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate a random K such that 0 < K < Q.
-
- R = ( G**K mod P ) mod Q
-
- S = ( K**(-1) * (hash + X*R) ) mod Q
-
- For information on the SHA-1 hash function see [FIPS 180-1] and [RFC
- 3174].
-
- Since Q is 160 bits long, R and S can not be larger than 20 octets,
- which is the space allocated.
-
- T is copied from the public key. It is not logically necessary in
- the SIG but is present so that values of T > 8 can more conveniently
- be used as an escape for extended versions of DSA or other algorithms
- as later standardized.
-
-
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA [RFC
- 3110] and DSA. With sufficient pre-computation, signature generation
- with DSA is faster than RSA. Key generation is also faster for DSA.
- However, signature verification is an order of magnitude slower than
- RSA when the RSA public exponent is chosen to be small, as is
- recommended for some applications.
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying and/or signature
- inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
- current DSA standard may limit the security of DSA. For particular
- applications, implementors are encouraged to consider the range of
- available algorithms and key sizes.
-
- DSA assumes the ability to frequently generate high quality random
- numbers. See [random] for guidance. DSA is designed so that if
- biased rather than random numbers are used, high bandwidth covert
- channels are possible. See [Schneier] and more recent research. The
- leakage of an entire DSA private key in only two DSA signatures has
- been demonstrated. DSA provides security only if trusted
- implementations, including trusted random number generation, are
- used.
-
-
-
-6. IANA Considerations
-
- Allocation of meaning to values of the T parameter that are not
- defined herein (i.e., > 8 ) requires an IETF standards actions. It
- is intended that values unallocated herein be used to cover future
- extensions of the DSS standard.
-
-
-
-Copyright and Disclaimer
-
- 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.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Normative References
-
- [FIPS 180-1] - U.S. Federal Information Processing Standard: Secure
- Hash Standard, April 1995.
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, 27 January 2000.
-
- [RFC records] - "Resource Records for the DNS Security Extensions",
- R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
- progress, draft-ietf-dnsext-dnssec-records- *.txt.
-
-
-
-Informative References
-
- [random] - "Randomness Recommendations for Security", D. Eastlake, S.
- Crocker, J. Schiller, work in progress, draft-eastlake-
- randomness2-*.txt currently in RFC Editor's queue.
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, 11/01/1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, 11/01/1987.
-
- [RFC intro] - "DNS Security Introduction and Requirements", R.
- Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
- draft-ietf-dnsext-dnssec-intro-*.txt.
-
- [RFC protocol] - "Protocol Modifications for the DNS Security
- Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
- work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS)", D. Eastlake 3rd. May 2001.
-
- [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
- Jones, September 2001.
-
- [Schneier] - "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C" (second edition), Bruce Schneier,
- 1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Authors Address
-
- Donald E. Eastlake 3rd
- Motorola Labortories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554(w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2005.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-05.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
+++ /dev/null
-
-
-Network Working Group S. Josefsson
-Internet-Draft January 2005
-Expires: July 2, 2005
-
-
- Storing Certificates in the Domain Name System (DNS)
- draft-ietf-dnsext-rfc2538bis-01
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 July 2, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- Cryptographic public key are frequently published and their
- authenticity demonstrated by certificates. A CERT resource record
- (RR) is defined so that such certificates and related certificate
- revocation lists can be stored in the Domain Name System (DNS).
-
-
-
-
-
-
-
-Josefsson Expires July 2, 2005 [Page 1]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3
- 2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4
- 2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5
- 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6
- 3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
- 3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8
- 3.3 Content-based OpenPGP CERT RR Names . . . . . . . . . . . 8
- 3.4 Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9
- 3.5 Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9
- 4. Performance Considerations . . . . . . . . . . . . . . . . . . 9
- 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
- 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12
- A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12
- Intellectual Property and Copyright Statements . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires July 2, 2005 [Page 2]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
-1. Introduction
-
- Public keys are frequently published in the form of a certificate and
- their authenticity is commonly demonstrated by certificates and
- related certificate revocation lists (CRLs). A certificate is a
- binding, through a cryptographic digital signature, of a public key,
- a validity interval and/or conditions, and identity, authorization,
- or other information. A certificate revocation list is a list of
- certificates that are revoked, and incidental information, all signed
- by the signer (issuer) of the revoked certificates. Examples are
- X.509 certificates/CRLs in the X.500 directory system or OpenPGP
- certificates/revocations used by OpenPGP software.
-
- Section 2 below specifies a CERT resource record (RR) for the storage
- of certificates in the Domain Name System.
-
- Section 3 discusses appropriate owner names for CERT RRs.
-
- Sections 4, 5, and 6 below cover performance, IANA, and security
- considerations, respectively.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [10].
-
-2. The CERT Resource Record
-
- The CERT resource record (RR) has the structure given below. Its RR
- type code is 37.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | type | key tag |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | algorithm | /
- +---------------+ certificate or CRL /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
- The type field is the certificate type as define in section 2.1
- below.
-
- The algorithm field has the same meaning as the algorithm field in
- DNSKEY and RRSIG RRs [9] except that a zero algorithm field indicates
- the algorithm is unknown to a secure DNS, which may simply be the
- result of the algorithm not having been standardized for DNSSEC.
-
-
-
-
-Josefsson Expires July 2, 2005 [Page 3]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- The key tag field is the 16 bit value computed for the key embedded
- in the certificate, using the RRSIG Key Tag Algorithm described in
- Appendix B of [9]. This field is used as an efficiency measure to
- pick which CERT RRs may be applicable to a particular key. The key
- tag can be calculated for the key in question and then only CERT RRs
- with the same key tag need be examined. However, the key must always
- be transformed to the format it would have as the public key portion
- of a DNSKEY RR before the key tag is computed. This is only possible
- if the key is applicable to an algorithm (and limits such as key size
- limits) defined for DNS security. If it is not, the algorithm field
- MUST BE zero and the tag field is meaningless and SHOULD BE zero.
-
-2.1 Certificate Type Values
-
- The following values are defined or reserved:
-
- Value Mnemonic Certificate Type
- ----- -------- ----------- ----
- 0 reserved
- 1 PKIX X.509 as per PKIX
- 2 SPKI SPKI certificate
- 3 PGP OpenPGP packet
- 4 IPKIX The URL of an X.509 data object
- 5 ISPKI The URL of an SPKI certificate
- 6 IPGP The URL of an OpenPGP packet
- 7-252 available for IANA assignment
- 253 URI URI private
- 254 OID OID private
- 255-65534 available for IANA assignment
- 65535 reserved
-
- The PKIX type is reserved to indicate an X.509 certificate conforming
- to the profile being defined by the IETF PKIX working group. The
- certificate section will start with a one byte unsigned OID length
- and then an X.500 OID indicating the nature of the remainder of the
- certificate section (see 2.3 below). (NOTE: X.509 certificates do
- not include their X.500 directory type designating OID as a prefix.)
-
- The SPKI type is reserved to indicate a certificate formated as to be
- specified by the IETF SPKI working group.
-
- The PGP type indicates an OpenPGP packet as described in [5] and its
- extensions and successors. Two uses are to transfer public key
- material and revocation signatures. The data is binary, and MUST NOT
- be encoded into an ASCII armor. An implementation SHOULD process
- transferable public keys as described in section 10.1 of [5], but it
- MAY handle additional OpenPGP packets.
-
-
-
-
-Josefsson Expires July 2, 2005 [Page 4]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
- content that would have been in the "certificate, CRL or URL" field
- of the corresponding (PKIX, SPKI or PGP) packet types. These types
- are known as "indirect". These packet types MUST be used when the
- content is too large to fit in the CERT RR, and MAY be used at the
- implementations discretion. They SHOULD NOT be used where the entire
- UDP packet would have fit in 512 bytes.
-
- The URI private type indicates a certificate format defined by an
- absolute URI. The certificate portion of the CERT RR MUST begin with
- a null terminated URI [4] and the data after the null is the private
- format certificate itself. The URI SHOULD be such that a retrieval
- from it will lead to documentation on the format of the certificate.
- Recognition of private certificate types need not be based on URI
- equality but can use various forms of pattern matching so that, for
- example, subtype or version information can also be encoded into the
- URI.
-
- The OID private type indicates a private format certificate specified
- by a an ISO OID prefix. The certificate section will start with a
- one byte unsigned OID length and then a BER encoded OID indicating
- the nature of the remainder of the certificate section. This can be
- an X.509 certificate format or some other format. X.509 certificates
- that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
- type, not the OID private type. Recognition of private certificate
- types need not be based on OID equality but can use various forms of
- pattern matching such as OID prefix.
-
-2.2 Text Representation of CERT RRs
-
- The RDATA portion of a CERT RR has the type field as an unsigned
- decimal integer or as a mnemonic symbol as listed in section 2.1
- above.
-
- The key tag field is represented as an unsigned decimal integer.
-
- The algorithm field is represented as an unsigned decimal integer or
- a mnemonic symbol as listed in [9].
-
- The certificate / CRL portion is represented in base 64 [11] and may
- be divided up into any number of white space separated substrings,
- down to single base 64 digits, which are concatenated to obtain the
- full signature. These substrings can span lines using the standard
- parenthesis.
-
- Note that the certificate / CRL portion may have internal sub-fields
- but these do not appear in the master file representation. For
- example, with type 254, there will be an OID size, an OID, and then
-
-
-
-Josefsson Expires July 2, 2005 [Page 5]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- the certificate / CRL proper. But only a single logical base 64
- string will appear in the text representation.
-
-2.3 X.509 OIDs
-
- OIDs have been defined in connection with the X.500 directory for
- user certificates, certification authority certificates, revocations
- of certification authority, and revocations of user certificates.
- The following table lists the OIDs, their BER encoding, and their
- length prefixed hex format for use in CERT RRs:
-
- id-at-userCertificate
- = { joint-iso-ccitt(2) ds(5) at(4) 36 }
- == 0x 03 55 04 24
- id-at-cACertificate
- = { joint-iso-ccitt(2) ds(5) at(4) 37 }
- == 0x 03 55 04 25
- id-at-authorityRevocationList
- = { joint-iso-ccitt(2) ds(5) at(4) 38 }
- == 0x 03 55 04 26
- id-at-certificateRevocationList
- = { joint-iso-ccitt(2) ds(5) at(4) 39 }
- == 0x 03 55 04 27
-
-
-3. Appropriate Owner Names for CERT RRs
-
- It is recommended that certificate CERT RRs be stored under a domain
- name related to their subject, i.e., the name of the entity intended
- to control the private key corresponding to the public key being
- certified. It is recommended that certificate revocation list CERT
- RRs be stored under a domain name related to their issuer.
-
- Following some of the guidelines below may result in the use in DNS
- names of characters that require DNS quoting which is to use a
- backslash followed by the octal representation of the ASCII code for
- the character such as \000 for NULL.
-
- The choice of name under which CERT RRs are stored is important to
- clients that perform CERT queries. In some situations, the client
- may not know all information about the CERT RR object it wishes to
- retrieve. For example, a client may not know the subject name of an
- X.509 certificate, or the e-mail address of the owner of an OpenPGP
- key. Further, the client might only know the hostname of a service
- that uses X.509 certificates or the Key ID of an OpenPGP key.
-
- This motivates describing two different owner name guidelines. We
- call the two rules content-based owner names and purpose-based owner
-
-
-
-Josefsson Expires July 2, 2005 [Page 6]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- names. A content-based owner name is derived from the content of the
- CERT RR data; for example the Subject field in an X.509 certificate
- or the User ID field in OpenPGP keys. A purpose-based owner name is
- selected to be a name that clients that wishes to retrieve CERT RRs
- are expected to know; for example the host name of a X.509 protected
- service or a Key ID of an OpenPGP key. Note that in some situations,
- the content-based and purpose-based owner name can be the same; for
- example when a client look up keys based on e-mail addresses for
- incoming e-mail.
-
- Implementations SHOULD use the purpose-based owner name guidelines
- described in this document, and MAY use CNAMEs at content-based owner
- names (or other names), pointing to the purpose-based owner name.
-
-3.1 Content-based X.509 CERT RR Names
-
- Some X.509 versions permit multiple names to be associated with
- subjects and issuers under "Subject Alternate Name" and "Issuer
- Alternate Name". For example, x.509v3 has such Alternate Names with
- an ASN.1 specification as follows:
-
- GeneralName ::= CHOICE {
- otherName [0] INSTANCE OF OTHER-NAME,
- rfc822Name [1] IA5String,
- dNSName [2] IA5String,
- x400Address [3] EXPLICIT OR-ADDRESS.&Type,
- directoryName [4] EXPLICIT Name,
- ediPartyName [5] EDIPartyName,
- uniformResourceIdentifier [6] IA5String,
- iPAddress [7] OCTET STRING,
- registeredID [8] OBJECT IDENTIFIER
- }
-
- The recommended locations of CERT storage are as follows, in priority
- order:
- 1. If a domain name is included in the identification in the
- certificate or CRL, that should be used.
- 2. If a domain name is not included but an IP address is included,
- then the translation of that IP address into the appropriate
- inverse domain name should be used.
- 3. If neither of the above it used but a URI containing a domain
- name is present, that domain name should be used.
- 4. If none of the above is included but a character string name is
- included, then it should be treated as described for OpenPGP
- names below.
- 5. If none of the above apply, then the distinguished name (DN)
- should be mapped into a domain name as specified in [3].
-
-
-
-
-Josefsson Expires July 2, 2005 [Page 7]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- Example 1: Assume that an X.509v3 certificate is issued to /CN=John
- Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
- names of (a) string "John (the Man) Doe", (b) domain name john-
- doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>. Then
- the storage locations recommended, in priority order, would be
- 1. john-doe.com,
- 2. www.secure.john-doe.com, and
- 3. Doe.com.xy.
-
- Example 2: Assume that an X.509v3 certificate is issued to /CN=James
- Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
- of (a) domain name widget.foo.example, (b) IPv4 address
- 10.251.13.201, and (c) string "James Hacker
- <hacker@mail.widget.foo.example>". Then the storage locations
- recommended, in priority order, would be
- 1. widget.foo.example,
- 2. 201.13.251.10.in-addr.arpa, and
- 3. hacker.mail.widget.foo.example.
-
-3.2 Purpose-based X.509 CERT RR Names
-
- It is difficult for clients that do not already posses a certificate
- to reconstruct the content-based owner name that should be used to
- retrieve the certificate. For this reason, purpose-based owner names
- are recommended in this section. Because purpose-based owner names
- by nature depend on the specific scenario, or purpose, for which the
- certificate will be used, there are more than one recommendation.
- The following table summarize the purpose-based X.509 CERT RR owner
- name guidelines.
-
- Scenario Owner name
- -------------------------------------------------------------------
- S/MIME Certificate Standard translation of RFC 822 email address.
- Example: A S/MIME certificate for
- "postmaster@example.org" will use a standard
- hostname translation of the owner name,
- i.e. "postmaster.example.org".
-
- SSL Certificate Hostname of the SSL server.
-
- IPSEC Certificate Hostname of the IPSEC machine, and/or
- for the in-addr.arpa reverse lookup IP address.
-
- An alternative approach for IPSEC is to store raw public keys [12].
-
-3.3 Content-based OpenPGP CERT RR Names
-
- OpenPGP signed keys (certificates) use a general character string
-
-
-
-Josefsson Expires July 2, 2005 [Page 8]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- User ID [5]. However, it is recommended by OpenPGP that such names
- include the RFC 2822 [7] email address of the party, as in "Leslie
- Example <Leslie@host.example>". If such a format is used, the CERT
- should be under the standard translation of the email address into a
- domain name, which would be leslie.host.example in this case. If no
- RFC 2822 name can be extracted from the string name no specific
- domain name is recommended.
-
- If a user has more than one email address, the CNAME type can be used
- to reduce the amount of data stored in the DNS. For example:
-
- $ORIGIN example.org.
- smith IN CERT PGP 0 0 <OpenPGP binary>
- john.smith IN CNAME smith
- js IN CNAME smith
-
-
-3.4 Purpose-based OpenPGP CERT RR Names
-
- Applications that receive an OpenPGP packet containing encrypted or
- signed data but do not know the email address of the sender will have
- difficulties constructing the correct owner name and cannot use the
- content-based owner name guidelines. However, these clients commonly
- know the key fingerprint or the Key ID. The key ID is found in
- OpenPGP packets, and the key fingerprint is commonly found in
- auxilliary data that may be available. For these situations, it is
- recommended to use an owner name identical to the key fingerprint and
- key ID expressed in hexadecimal [11]. For example:
-
- $ORIGIN example.org.
- 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
- F835EDA21E94B565716F IN CERT PGP ...
- B565716F IN CERT PGP ...
-
- If the same key material is stored at several owner names, the use of
- CNAME may be used to avoid data duplication. Note that CNAME is not
- always applicable, because it map an owner names to the other for all
- purposes, and this may be sub-optimal when two keys with the same Key
- ID are stored.
-
-3.5 Owner names for IPKIX, ISPKI, and IPGP
-
- These types are stored under the same owner names, both purpose- and
- content-based, as the PKIX, SPKI and PGP types, respectively.
-
-4. Performance Considerations
-
- Current Domain Name System (DNS) implementations are optimized for
-
-
-
-Josefsson Expires July 2, 2005 [Page 9]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- small transfers, typically not more than 512 bytes including
- overhead. While larger transfers will perform correctly and work is
- underway to make larger transfers more efficient, it is still
- advisable at this time to make every reasonable effort to minimize
- the size of certificates stored within the DNS. Steps that can be
- taken may include using the fewest possible optional or extensions
- fields and using short field values for variable length fields that
- must be included.
-
- The RDATA field in the DNS protocol may only hold data of size 65535
- octets (64kb) or less. This means that each CERT RR cannot contain
- more than 64kb worth of payload, even if the corresponding
- certificate or certificate revocation list is larger. This document
- address this by defining "indirect" data types for each normal type.
-
-5. Acknowledgements
-
- The majority of this document is copied verbatim from RFC 2538, by
- Donald Eastlake 3rd and Olafur Gudmundsson.
-
- The author wishes to thank David Shaw and Michael Graff for their
- contributions to the earlier work that motivated this revised
- document.
-
- This document was improved by suggestions and comments from Olivier
- Dubuisson, Ben Laurie, Samuel Weiler, and Florian Weimer. No doubt
- the list is incomplete. We apologize to anyone we left out.
-
-6. Security Considerations
-
- By definition, certificates contain their own authenticating
- signature. Thus it is reasonable to store certificates in non-secure
- DNS zones or to retrieve certificates from DNS with DNS security
- checking not implemented or deferred for efficiency. The results MAY
- be trusted if the certificate chain is verified back to a known
- trusted key and this conforms with the user's security policy.
-
- Alternatively, if certificates are retrieved from a secure DNS zone
- with DNS security checking enabled and are verified by DNS security,
- the key within the retrieved certificate MAY be trusted without
- verifying the certificate chain if this conforms with the user's
- security policy.
-
- When the URI type is used, it should be understood that it introduces
- an additional indirection that may allow for a new attack vector.
- One method to secure that indirection is to include a hash of the
- certificate in the URI itself.
-
-
-
-
-Josefsson Expires July 2, 2005 [Page 10]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- CERT RRs are not used by DNSSEC [8] so there are no security
- considerations related to CERT RRs and securing the DNS itself.
-
- If DNSSEC [8] is used then the non-existence of a CERT RR, and
- consequently certificates or revocation lists, can be securely
- asserted. Without DNSSEC, this is not possible.
-
-7. IANA Considerations
-
- Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
- only be assigned by an IETF standards action [6]. This document
- assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate
- types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
- based on RFC documentation of the certificate type. The availability
- of private types under 0x00FD and 0x00FE should satisfy most
- requirements for proprietary or private types.
-
-8. Changes since RFC 2538
-
- 1. Editorial changes to conform with new document requirements,
- including splitting reference section into two parts and updating
- the references to point at latest versions, and to add some
- additional references.
- 2. Improve terminology. For example replace "PGP" with "OpenPGP",
- to align with RFC 2440.
- 3. In section 2.1, clarify that OpenPGP public key data are binary,
- not the ASCII armored format, and reference 10.1 in RFC 2440 on
- how to deal with OpenPGP keys, and acknowledge that
- implementations may handle additional packet types.
- 4. Clarify that integers in the representation format are decimal.
- 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
- terminology. Improve reference for Key Tag Algorithm
- calculations.
- 6. Add examples that suggest use of CNAME to reduce bandwidth.
- 7. In section 3, appended the last paragraphs that discuss
- "content-based" vs "purpose-based" owner names. Add section 3.2
- for purpose-based X.509 CERT owner names, and section 3.4 for
- purpose-based OpenPGP CERT owner names.
- 8. Added size considerations.
- 9. Added indirect types IPKIX, ISPKI, and IPGP.
-
-9. References
-
-9.1 Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
-
-
-
-Josefsson Expires July 2, 2005 [Page 11]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri,
- "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
- January 1998.
-
- [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
- Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
- [5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
- Message Format", RFC 2440, November 1998.
-
- [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
- [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
- [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
- "DNS Security Introduction and Requirements",
- draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
- 2004.
-
- [9] Arends, R., "Resource Records for the DNS Security Extensions",
- draft-ietf-dnsext-dnssec-records-11 (work in progress), October
- 2004.
-
-9.2 Informative References
-
- [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
- RFC 3548, July 2003.
-
- [12] Richardson, M., "A method for storing IPsec keying material in
- DNS", draft-ietf-ipseckey-rr-11 (work in progress), July 2004.
-
-
-Author's Address
-
- Simon Josefsson
-
- EMail: simon@josefsson.org
-
-Appendix A. Copying conditions
-
- Regarding the portion of this document that was written by Simon
-
-
-
-Josefsson Expires July 2, 2005 [Page 12]
-\f
-Internet-Draft Storing Certificates in the DNS January 2005
-
-
- Josefsson ("the author", for the remainder of this section), the
- author makes no guarantees and is not responsible for any damage
- resulting from its use. The author grants irrevocable permission to
- anyone to use, modify, and distribute it in any way that does not
- diminish the rights of anyone else to use, modify, and distribute it,
- provided that redistributed derivative works do not contain
- misleading author or version information. Derivative works need not
- be licensed under similar terms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires July 2, 2005 [Page 13]
-\f
-Internet-Draft Storing Certificates in the DNS January 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.
-
-
-
-
-Josefsson Expires July 2, 2005 [Page 14]
-\f
-
+++ /dev/null
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2005 March 2005
-
-
-
-
- Storage of Diffie-Hellman Keying Information in the DNS
- ------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-05.txt>
-
-
-
-Status of This Document
-
- By submitting this Internet-Draft, I certify that any applicable
- patent or other IPR claims of which I am aware have been disclosed,
- or will be disclosed, and any of which I become aware will be
- disclosed, in accordance with RFC 3668.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- 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 a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for encoding Diffie-Hellman keys in the Domain
- Name System is specified.
-
-
-
-Copyright
-
- Copyright (C) The Internet Society 2005.
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
- Part of the format for Diffie-Hellman keys and the description
- thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
- and Hemma Prafullchandra. In addition, the following persons
- provided useful comments that were incorporated into the predecessor
- of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright..................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 1.1 About This Document....................................3
- 1.2 About Diffie-Hellman...................................3
- 2. Encoding Diffie-Hellman Keying Information..............4
- 3. Performance Considerations..............................5
- 4. IANA Considerations.....................................5
- 5. Security Considerations.................................5
- Copyright and Disclaimer...................................5
-
- Normative References.......................................7
- Informative Refences.......................................7
- Author Address.............................................7
- Expiration and File Name...................................8
-
- Appendix A: Well known prime/generator pairs...............9
- A.1. Well-Known Group 1: A 768 bit prime..................9
- A.2. Well-Known Group 2: A 1024 bit prime.................9
- A.3. Well-Known Group 3: A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- similar information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC intro, proto, records] and additonal work is underway which
- would use the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
- This document describes how to store Diffie-Hellman keys in the DNS.
- Familiarity with the Diffie-Hellman key exchange algorithm is assumed
- [Schneier, RFC 2631].
-
-
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Thus Diffie-
- Hellman is inherently a key agreement algorithm. As a result, no
- format is defined for Diffie-Hellman "signature information". For
- example, assume that two parties have local secrets "i" and "j".
- Assume they each respectively calculate X and Y as follows:
-
- X = g**i ( mod p )
-
- Y = g**j ( mod p )
-
- They exchange these quantities and then each calculates a Z as
- follows:
-
- Zi = Y**i ( mod p )
-
- Zj = X**j ( mod p )
-
- Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
- secret between the two parties that an adversary who does not know i
- or j will not be able to learn from the exchanged messages (unless
- the adversary can derive i or j by performing a discrete logarithm
- mod p which is hard for strong p and g).
-
- The private key for each party is their secret i (or j). The public
- key is the pair p and g, which must be the same for the parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
- When Diffie-Hellman keys appear within the RDATA portion of a RR,
- they are encoded as shown below.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | KEY flags | protocol | algorithm=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | prime length (or flag) | prime (p) (or special) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / prime (p) (variable length) | generator length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | generator (g) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | public value length | public value (variable length)/
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / public value (g^i mod p) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Prime length is the length of the Diffie-Hellman prime (p) in bytes
- if it is 16 or greater. Prime contains the binary representation of
- the Diffie-Hellman prime with most significant byte first (i.e., in
- network order). If "prime length" field is 1 or 2, then the "prime"
- field is actually an unsigned index into a table of 65,536
- prime/generator pairs and the generator length SHOULD be zero. See
- Appedix A for defined table entries and Section 4 for information on
- allocating additional table entries. The meaning of a zero or 3
- through 15 value for "prime length" is reserved.
-
- Generator length is the length of the generator (g) in bytes.
- Generator is the binary representation of generator with most
- significant byte first. PublicValueLen is the Length of the Public
- Value (g**i (mod p)) in bytes. PublicValue is the binary
- representation of the DH public value with most significant byte
- first.
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient. But
- it is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying information consistent
- with adequate security.
-
-
-
-4. IANA Considerations
-
- Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
- an IETF consensus as defined in [RFC 2434].
-
- Well known prime/generator pairs number 0x0000 through 0x07FF can
- only be assigned by an IETF standards action. [RFC 2539], the
- Proposed Standard predecessor of this document, assigned 0x0001
- through 0x0002. This document additionally assigns 0x0003. Pairs
- number 0s0800 through 0xBFFF can be assigned based on RFC
- documentation. Pairs number 0xC000 through 0xFFFF are available for
- private use and are not centrally coordinated. Use of such private
- pairs outside of a closed environment may result in conflicts and/or
- security failures.
-
-
-
-5. Security Considerations
-
- Keying information retrieved from the DNS should not be trusted
- unless (1) it has been securely obtained from a secure resolver or
- independently verified by the user and (2) this secure resolver and
- secure obtainment or independent verification conform to security
- policies acceptable to the user. As with all cryptographic
- algorithms, evaluating the necessary strength of the key is important
- and dependent on security policy.
-
- In addition, the usual Diffie-Hellman key strength considerations
- apply. (p-1)/2 should also be prime, g should be primitive mod p, p
- should be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright and Disclaimer
-
- 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.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Normative References
-
- [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
- 1999.
-
- [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
- in RFCs", T. Narten, H. Alvestrand, October 1998.
-
- [RFC records] - "Resource Records for the DNS Security Extensions",
- R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
- progress, draft-ietf-dnsext-dnssec-records- *.txt.
-
-
-
-Informative Refences
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, November 1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, November 1987.
-
- [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC intro] - "DNS Security Introduction and Requirements", R.
- Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
- draft-ietf-dnsext-dnssec-intro-*.txt.
-
- [RFC protocol] - "Protocol Modifications for the DNS Security
- Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
- work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
- and Sons.
-
-
-
-Author Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2005.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-05.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
- These numbers are copied from the IPSEC effort where the derivation of
- these values is more fully explained and additional information is
- available.
- Richard Schroeppel performed all the mathematical and computational
- work for this appendix.
-
-
-
-A.1. Well-Known Group 1: A 768 bit prime
-
- The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
- decimal value is
- 155251809230070893513091813125848175563133404943451431320235
- 119490296623994910210725866945387659164244291000768028886422
- 915080371891804634263272761303128298374438082089019628850917
- 0691316593175367469551763119843371637221007210577919
-
- Prime modulus: Length (32 bit words): 24, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2: A 1024 bit prime
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its decimal value is
- 179769313486231590770839156793787453197860296048756011706444
- 423684197180216158519368947833795864925541502180565485980503
- 646440548199239100050792877003355816639229553136239076508735
- 759914822574862575007425302077447712589550957937778424442426
- 617334727629299387668709205606050270810842907692932019128194
- 467627007
-
- Prime modulus: Length (32 bit words): 32, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
- FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3: A 1536 bit prime
-
- The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
- Its decimal value is
- 241031242692103258855207602219756607485695054850245994265411
- 694195810883168261222889009385826134161467322714147790401219
- 650364895705058263194273070680500922306273474534107340669624
- 601458936165977404102716924945320037872943417032584377865919
- 814376319377685986952408894019557734611984354530154704374720
- 774996976375008430892633929555996888245787241299381012913029
- 459299994792636526405928464720973038494721168143446471443848
- 8520940127459844288859336526896320919633919
-
- Prime modulus Length (32 bit words): 48, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
- C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
- 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
- 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
-
+++ /dev/null
-
-
-Network Working Group M. StJohns
-Internet-Draft Nominum, Inc.
-Expires: April 14, 2005 October 14, 2004
-
-
- Automated Updates of DNSSEC Trust Anchors
- draft-ietf-dnsext-trustupdate-timers-00
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 14, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004).
-
-Abstract
-
- This document describes a means for automated, authenticated and
- authorized updating of DNSSEC "trust anchors". The method provides
- protection against single key compromise of a key in the trust point
- key set. Based on the trust established by the presence of a current
- anchor, other anchors may be added at the same place in the
- hierarchy, and, ultimately, supplant the existing anchor.
-
- This mechanism, if adopted, will require changes to resolver
-
-
-
-StJohns Expires April 14, 2005 [Page 1]
-
-Internet-Draft trustanchor-update October 2004
-
-
- management behavior (but not resolver resolution behavior), and the
- addition of a single flag bit to the DNSKEY record.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
- 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
- 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
- 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
- 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
- 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
- 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
- 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
- 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6
- 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
- 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8
- 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
- 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
- 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9
- 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
- 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
- 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10
- 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
- Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
- Intellectual Property and Copyright Statements . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires April 14, 2005 [Page 2]
-
-Internet-Draft trustanchor-update October 2004
-
-
-1. Introduction
-
- As part of the reality of fielding DNSSEC (Domain Name System
- Security Extensions) [RFC2535][DSINTRO][DSPROT][DSREC], the community
- has come to the realization that there will not be one signed name
- space, but rather islands of signed name space each originating from
- specific points (i.e. 'trust points') in the DNS tree. Each of
- those islands will be identified by the trust point name, and
- validated by at least one associated public key. For the purpose of
- this document we'll call the association of that name and a
- particular key a 'trust anchor'. A particular trust point can have
- more than one key designated as a trust anchor.
-
- For a DNSSEC-aware resolver to validate information in a DNSSEC
- protected branch of the hierarchy, it must have knowledge of a trust
- anchor applicable to that branch. It may also have more than one
- trust anchor for any given trust point. Under current rules, a chain
- of trust for DNSSEC-protected data that chains its way back to ANY
- known trust anchor is considered 'secure'.
-
- Because of the probable balkanization of the DNSSEC tree due to
- signing voids at key locations, a resolver may need to know literally
- thousands of trust anchors to perform its duties. (e.g. Consider an
- unsigned ".COM".) Requiring the owner of the resolver to manually
- manage this many relationships is problematic. It's even more
- problematic when considering the eventual requirement for key
- replacement/update for a given trust anchor. The mechanism described
- herein won't help with the initial configuration of the trust anchors
- in the resolvers, but should make trust point key
- replacement/rollover more viable.
-
- As mentioned above, this document describes a mechanism whereby a
- resolver can update the trust anchors for a given trust point, mainly
- without human intervention at the resolver. There are some corner
- cases discussed (e.g. multiple key compromise) that may require
- manual intervention, but they should be few and far between. This
- document DOES NOT discuss the general problem of the initial
- configuration of trust anchors for the resolver.
-
-1.1 Compliance Nomenclature
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14, [RFC2119].
-
-1.2 Changes since -00
-
- Resubmitted draft-stjohns-dnssec-trustupdate as a working group
-
-
-
-StJohns Expires April 14, 2005 [Page 3]
-
-Internet-Draft trustanchor-update October 2004
-
-
- draft.
-
- Added the concept of timer triggered resolver queries to refresh the
- resolvers view of the trust anchor key RRSet.
-
-2. Theory of Operation
-
- The general concept of this mechanism is that existing trust anchors
- can be used to authenticate new trust anchors at the same point in
- the DNS hierarchy. When a new SEP key is added to a trust point
- DNSKEY RRSet, and when that RRSet is validated by an existing trust
- anchor, then the new key can be added to the set of trust anchors.
-
- There are some issues with this approach which need to be mitigated.
- For example, a compromise of one of the existing keys could allow an
- attacker to add their own 'valid' data. This implies a need for a
- method to revoke an existing key regardless of whether or not that
- key is compromised. As another example assuming a single key
- compromise, an attacker could add a new key and revoke all the other
- old keys.
-
-2.1 Revocation
-
- Assume two trust anchor keys A and B. Assume that B has been
- compromised. Without a specific revocation bit, B could invalidate A
- simply by sending out a signed trust point key set which didn't
- contain A. To fix this, we add a mechanism which requires knowledge
- of the private key of a DNSKEY to revoke that DNSKEY.
-
- A key is considered revoked when the resolver sees the key in a
- self-signed RRSet and the key has the REVOKE bit set to '1'. Once
- the resolver sees the REVOKE bit, it MUST NOT use this key as a trust
- anchor or for any other purposes except validating the RRSIG over the
- DNSKEY RRSet specifically for the purpose of validating the
- revocation. Unlike the 'Add' operation below, revocation is
- immediate and permanent upon receipt of a valid revocation at the
- resolver.
-
- N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
- than one without the bit set. This affects the matching of a DNSKEY
- to DS records in the parent, or the fingerprint stored at a resolver
- used to configure a trust point. [msj3]
-
- In the given example, the attacker could revoke B because it has
- knowledge of B's private key, but could not revoke A.
-
-
-
-
-
-
-StJohns Expires April 14, 2005 [Page 4]
-
-Internet-Draft trustanchor-update October 2004
-
-
-2.2 Add Hold-Down
-
- Assume two trust point keys A and B. Assume that B has been
- compromised. An attacker could generate and add a new trust anchor
- key - C (by adding C to the DNSKEY RRSet and signing it with B), and
- then invalidate the compromised key. This would result in the both
- the attacker and owner being able to sign data in the zone and have
- it accepted as valid by resolvers.
-
- To mitigate, but not completely solve, this problem, we add a
- hold-down time to the addition of the trust anchor. When the
- resolver sees a new SEP key in a validated trust point DNSKEY RRSet,
- the resolver starts an acceptance timer, and remembers all the keys
- that validated the RRSet. If the resolver ever sees the DNSKEY RRSet
- without the new key but validly signed, it stops the acceptance
- process and resets the acceptance timer. If all of the keys which
- were originally used to validate this key are revoked prior to the
- timer expiring, the resolver stops the acceptance process and resets
- the timer.
-
- Once the timer expires, the new key will be added as a trust anchor
- the next time the validated RRSet with the new key is seen at the
- resolver. The resolver MUST NOT treat the new key as a trust anchor
- until the hold down time expires AND it has retrieved and validated a
- DNSKEY RRSet after the hold down time which contains the new key.
-
- N.B.: Once the resolver has accepted a key as a trust anchor, the key
- MUST be considered a valid trust anchor by that resolver until
- explictly revoked as described above.
-
- In the given example, the zone owner can recover from a compromise by
- revoking B and adding a new key D and signing the DNSKEY RRSet with
- both A and B.
-
- The reason this does not completely solve the problem has to do with
- the distributed nature of DNS. The resolver only knows what it sees.
- A determined attacker who holds one compromised key could keep a
- single resolver from realizing that key had been compromised by
- intercepting 'real' data from the originating zone and substituting
- their own (e.g. using the example, signed only by B). This is no
- worse than the current situation assuming a compromised key.
-
-2.3 Remove Hold-down
-
- A new key which has been seen by the resolver, but hasn't reached
- it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
- zone owner. If the resolver sees a validated DNSKEY RRSet without
- this key, it waits for the remove hold-down time and then, if the key
-
-
-
-StJohns Expires April 14, 2005 [Page 5]
-
-Internet-Draft trustanchor-update October 2004
-
-
- hasn't reappeared, SHOULD discard any information about the key.
-
-2.4 Active Refresh
-
- A resolver which has been configured for automatic update of keys
- from a particular trust point MUST query that trust point (e.g. do a
- lookup for the DNSKEY RRSet and related RRSIG records) no less often
- than the lesser of 15 days or half the original TTL for the DNSKEY
- RRSet or half the RRSIG expiration interval. The expiration interval
- is the amount of time from when the RRSIG was last retrieved until
- the expiration time in the RRSIG.
-
- If the query fails, the resolver MUST repeat the query until
- satisfied no more often than once an hour and no less often than the
- lesser of 1 day or 10% of the original TTL or 10% of the original
- expiration interval.
-
-2.5 Resolver Parameters
-
-2.5.1 Add Hold-Down Time
-
- The add hold-down time is 30 days or the expiration time of the TTL
- of the first trust point DNSKEY RRSet which contained the key,
- whichever is greater. This ensures that at least two validated
- DNSKEY RRSets which contain the new key MUST be seen by the resolver
- prior to the key's acceptance.
-
-2.5.2 Remove Hold-Down Time
-
- The remove hold-down time is 30 days.
-
-2.5.3 Minimum Trust Anchors per Trust Point
-
- A compliant resolver MUST be able to manage at least five SEP keys
- per trust point.
-
-3. Changes to DNSKEY RDATA Wire Format
-
- Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
- flag. If this bit is set to '1', AND the resolver sees an
- RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
- consider this key permanently invalid for all purposes except for
- validing the revocation.
-
-4. State Table
-
- The most important thing to understand is the resolver's view of any
- key at a trust point. The following state table describes that view
-
-
-
-StJohns Expires April 14, 2005 [Page 6]
-
-Internet-Draft trustanchor-update October 2004
-
-
- at various points in the key's lifetime. The table is a normative
- part of this specification. The initial state of the key is 'Start'.
- The resolver's view of the state of the key changes as various events
- occur.
-
- [msj1] This is the state of a trust point key as seen from the
- resolver. The column on the left indicates the current state. The
- header at the top shows the next state. The intersection of the two
- shows the event that will cause the state to transition from the
- current state to the next.
-
- NEXT STATE
- --------------------------------------------------
- FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
- ----------------------------------------------------------
- Start | |NewKey | | | | |
- ----------------------------------------------------------
- AddPend |KeyRem | |AddTime| | |
- ----------------------------------------------------------
- Valid | | | |KeyRem |Revbit | |
- ----------------------------------------------------------
- Missing | | |KeyPres| |Revbit | |
- ----------------------------------------------------------
- Revoked | | | | | |RemTime|
- ----------------------------------------------------------
- Removed | | | | | | |
- ----------------------------------------------------------
-
-
-4.1 Events
- NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
- That key will become a new trust anchor for the named trust point
- after its been present in the RRSet for at least 'add time'.
- KeyPres The key has returned to the valid DNSKEY RRSet.
- KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
- this key.
- AddTime The key has been in every valid DNSKEY RRSet seen for at
- least the 'add time'.
- RemTime A revoked key has been missing from the trust point DNSKEY
- RRSet for sufficient time to be removed from the trust set.
- RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
- "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
- signed by this key.
-
-4.2 States
-
-
-
-
-
-
-StJohns Expires April 14, 2005 [Page 7]
-
-Internet-Draft trustanchor-update October 2004
-
-
- Start The key doesn't yet exist as a trust anchor at the resolver.
- It may or may not exist at the zone server, but hasn't yet been
- seen at the resolver.
- AddPend The key has been seen at the resolver, has its 'SEP' bit set,
- and has been included in a validated DNSKEY RRSet. There is a
- hold-down time for the key before it can be used as a trust
- anchor.
- Valid The key has been seen at the resolver and has been included in
- all validated DNSKEY RRSets from the time it was first seen up
- through the hold-down time. It is now valid for verifying RRSets
- that arrive after the hold down time. Clarification: The DNSKEY
- RRSet does not need to be continuously present at the resolver
- (e.g. its TTL might expire). If the RRSet is seen, and is
- validated (i.e. verifies against an existing trust anchor), this
- key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
- Missing This is an abnormal state. The key remains as a valid trust
- point key, but was not seen at the resolver in the last validated
- DNSKEY RRSet. This is an abnormal state because the zone operator
- should be using the REVOKE bit prior to removal. [Discussion
- item: Should a missing key be considered revoked after some
- period of time?]
- Revoked This is the state a key moves to once the resolver sees an
- RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
- this key with its REVOKE bit set to '1'. Once in this state, this
- key MUST permanently be considered invalid as a trust anchor.
- Removed After a fairly long hold-down time, information about this
- key may be purged from the resolver. A key in the removed state
- MUST NOT be considered a valid trust anchor.
-
-5. Scenarios
-
- The suggested model for operation is to have one active key and one
- stand-by key at each trust point. The active key will be used to
- sign the DNSKEY RRSet. The stand-by key will not normally sign this
- RRSet, but the resolver will accept it as a trust anchor if/when it
- sees the signature on the trust point DNSKEY RRSet.
-
- Since the stand-by key is not in active signing use, the associated
- private key may (and SHOULD) be provided with additional protections
- not normally available to a key that must be used frequently. E.g.
- locked in a safe, split among many parties, etc. Notionally, the
- stand-by key should be less subject to compromise than an active key,
- but that will be dependent on operational concerns not addressed
- here.
-
-5.1 Adding A Trust Anchor
-
- Assume an existing trust anchor key 'A'.
-
-
-
-StJohns Expires April 14, 2005 [Page 8]
-
-Internet-Draft trustanchor-update October 2004
-
-
- 1. Generate a new key pair.
- 2. Create a DNSKEY record from the key pair and set the SEP and Zone
- Key bits.
- 3. Add the DNSKEY to the RRSet.
- 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
- 'A'.
- 5. Wait a while.
-
-5.2 Deleting a Trust Anchor
-
- Assume existing trust anchors 'A' and 'B' and that you want to revoke
- and delete 'A'.
- 1. Set the revolcation bit on key 'A'.
- 2. Sign the DNSKEY RRSet with both 'A' and 'B'.
- 'A' is now revoked. The operator SHOULD include the revoked 'A' in
- the RRSet for at least the remove hold-down time, but then may remove
- it from the DNSKEY RRSet.
-
-5.3 Key Roll-Over
-
- Assume existing keys A and B. 'A' is actively in use (i.e. has been
- signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has
- been in the DNSKEY RRSet and is a valid trust anchor, but wasn't
- being used to sign the RRSet.)
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'A'.
- 4. Sign the RRSet with 'A' and 'B'.
- 'A' is now revoked, 'B' is now the active key, and 'C' will be the
- stand-by key once the hold-down expires. The operator SHOULD include
- the revoked 'A' in the RRSet for at least the remove hold-down time,
- but may then remove it from the DNSKEY RRSet.
-
-5.4 Active Key Compromised
-
- This is the same as the mechanism for Key Roll-Over (Section 5.3)
- above assuming 'A' is the active key.
-
-5.5 Stand-by Key Compromised
-
- Using the same assumptions and naming conventions as Key Roll-Over
- (Section 5.3) above:
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'B'.
- 4. Sign the RRSet with 'A' and 'B'.
- 'B' is now revoked, 'A' remains the active key, and 'C' will be the
- stand-by key once the hold-down expires. 'B' SHOULD continue to be
-
-
-
-StJohns Expires April 14, 2005 [Page 9]
-
-Internet-Draft trustanchor-update October 2004
-
-
- included in the RRSet for the remove hold-down time.
-
-6. Security Considerations
-
-6.1 Key Ownership vs Acceptance Policy
-
- The reader should note that, while the zone owner is responsible
- creating and distributing keys, it's wholly the decision of the
- resolver owner as to whether to accept such keys for the
- authentication of the zone information. This implies the decision
- update trust anchor keys based on trust for a current trust anchor
- key is also the resolver owner's decision.
-
- The resolver owner (and resolver implementers) MAY choose to permit
- or prevent key status updates based on this mechanism for specific
- trust points. If they choose to prevent the automated updates, they
- will need to establish a mechanism for manual or other out-of-band
- updates outside the scope of this document.
-
-6.2 Multiple Key Compromise
-
- This scheme permits recovery as long as at least one valid trust
- anchor key remains uncompromised. E.g. if there are three keys, you
- can recover if two of them are compromised. The zone owner should
- determine their own level of comfort with respect to the number of
- active valid trust anchors in a zone and should be prepared to
- implement recovery procedures once they detect a compromise. A
- manual or other out-of-band update of all resolvers will be required
- if all trust anchor keys at a trust point are compromised.
-
-6.3 Dynamic Updates
-
- Allowing a resolver to update its trust anchor set based in-band key
- information is potentially less secure than a manual process.
- However, given the nature of the DNS, the number of resolvers that
- would require update if a trust anchor key were compromised, and the
- lack of a standard management framework for DNS, this approach is no
- worse than the existing situation.
-
-7 Normative References
-
- [DSINTRO] Arends, R., "DNS Security Introduction and Requirements",
- ID draft-ietf-dnsext-dnssec-intro-09.txt, October 2004,
- <http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
- sec-intro-13.txt>.
-
- [DSPROT] Arends, R., "Protocol Modifications for the DNS Security
- Extensions", ID draft-ietf-dnsext-dnssec-protocol-05.txt,
-
-
-
-StJohns Expires April 14, 2005 [Page 10]
-
-Internet-Draft trustanchor-update October 2004
-
-
- October 2004,
- <http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
- sec-protocol-09.txt>.
-
- [DSREC] Arends, R., "Resource Records for the DNS Security
- Extensions", ID draft-ietf-dnsext-dnssec-records-07.txt,
- October 2004,
- <http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
- sec-records-11.txt>.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
-Editorial Comments
-
- [msj1] msj: N.B. This table is preliminary and will be revised to
- match implementation experience. For example, should there
- be a state for "Add hold-down expired, but haven't seen the
- new RRSet"?
-
- [msj2] msj: To be assigned.
-
- [msj3] msj: For discussion: What's the implementation guidance for
- resolvers currently with respect to the non-assigned flag
- bits? If they consider the flag bit when doing key matching
- at the trust anchor, they won't be able to match.
-
-
-Author's Address
-
- Michael StJohns
- Nominum, Inc.
- 2385 Bay Road
- Redwood City, CA 94063
- USA
-
- Phone: +1-301-528-4729
- EMail: Mike.StJohns@nominum.com
- URI: www.nominum.com
-
-
-
-
-
-
-
-
-
-StJohns Expires April 14, 2005 [Page 11]
-
-Internet-Draft trustanchor-update October 2004
-
-
-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.
-
- The IETF has been notified of intellectual property rights claimed in
- regard to some or all of the specification contained in this
- document. For more information consult the online list of claimed
- rights.
-
-
-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 (2004). 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.
-
-
-
-
-
-StJohns Expires April 14, 2005 [Page 12]
-
-Internet-Draft trustanchor-update October 2004
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires April 14, 2005 [Page 13]
-
-
+++ /dev/null
-
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-UPDATES RFC 2845 Motorola Laboratories
-Expires: October 2005 April 2005
-
-
- HMAC SHA TSIG Algorithm Identifiers
- ---- --- ---- --------- -----------
- <draft-ietf-dnsext-tsig-sha-03.txt>
-
-
-Status of This Document
-
- By submitting this Internet-Draft, I certify that any applicable
- patent or other IPR claims of which I am aware have been disclosed,
- or will be disclosed, and any of which I become aware will be
- disclosed, in accordance with RFC 3668.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
-
- 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 a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- Use of the TSIG DNS resource record requires specification of a
- cryptographic message authentication code. Currently identifiers
- have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
- This document standardizes identifiers and implementation
- requirements for additional HMAC SHA TSIG algorithms and standardizes
- how to specify and handle the truncation of HMAC values.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
-
- 2. Algorithms and Identifiers..............................4
-
- 3. Specifying Truncation...................................5
- 3.1 Truncation Specification...............................5
-
- 4. TSIG Policy Provisions and Truncation Error.............7
-
- 5. IANA Considerations.....................................8
- 6. Security Considerations.................................8
- 6. Copyright and Disclaimer................................8
-
- 7. Normative References....................................9
- 8. Informative References..................................9
-
- Author's Address..........................................10
- Expiration and File Name..................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
- [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
- authenticate DNS queries and responses. This RR contains a domain
- name syntax data item which names the authentication algorithm used.
- [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
- authentication codes using the HMAC [RFC 2104] algorithm with the MD5
- [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
- identifier for TSIG authentication where the cryptographic operations
- are delegated to GSS [RFC 3645].
-
- In Section 2, this document specifies additional names for TSIG
- authentication algorithms based on US NIST SHA algorithms and HMAC
- and specifies the implementation requirements for those algorithms.
-
- In Section 3, this document specifies the meaning of inequality
- between the normal output size of the specified hash function and the
- length of MAC (message authentication code) data given in the TSIG
- RR. In particular, it specifies that a shorter length field value
- specifies truncation and a longer length field is an error.
-
- In Section 4, policy restrictions and implications related to
- truncation and a new error code to indicate truncation shorter than
- permitted by policy are described and specified.
-
- The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
- defined in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
- TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
- queries and responses. They are intended to be efficient symmetric
- authentication codes based on a shared secret. (Asymmetric signatures
- can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
- can be used for transaction signatures.) Used with a strong hash
- function, HMAC [RFC 2104] provides a way to calculate such symmetric
- authentication codes. The only specified HMAC based TSIG algorithm
- identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
- The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as
- compared with the 128 bits for MD5, and additional hash algorithms in
- the SHA family [FIPS 180-2, RFC 3874] with 224, 256, 384, and 512
- bits, may be preferred in some cases particularly since increasingly
- successful cryptanalytic attacks are being made on the shorter
- hashes. Use of TSIG between a DNS resolver and server is by mutual
- agreement. That agreement can include the support of additional
- algorithms and may specify policies as to which algorithms and
- truncations are acceptable subject to the restrication and guidelines
- in Section 3 and 4 below.
-
- The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the
- table below for convenience. Implementations which support TSIG MUST
- also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig
- and the other algorithms listed below.
-
- Mandatory HMAC-MD5.SIG-ALG.REG.INT
- Mandatory hmac-sha1
- Optional hmac-sha224
- Mandatory hmac-sha256
- Optional hamc-sha384
- Optional hmac-sha512
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
- When space is at a premium and the strength of the full length of an
- HMAC is not needed, it is reasonable to truncate the HMAC output and
- use the truncated value for authentication. HMAC SHA-1 truncated to
- 96 bits is an option available in several IETF protocols including
- IPSEC and TLS.
-
- The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
- size of the MAC field in octets. But [RFC 2845] does not specify what
- to do if this MAC size differs from the length of the output of HMAC
- for a particular hash function. Truncation is indicated by a MAC size
- less than the HMAC size as specified below.
-
-
-
-3.1 Truncation Specification
-
- The specification for TSIG handling is changed as follows:
-
- 1. If "MAC size" field is greater than HMAC output length:
- This case MUST NOT be generated and if received MUST cause the
- packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
- 2. If "MAC size" field equals HMAC output length:
- Operation is as described in [RFC 2845] with the entire output
- HMAC output present.
-
- 3. "MAC size" field is less than HMAC output length but greater than
- that specified in case 4 below:
- This is sent when the signer has truncated the HMAC output to
- an allowable length, as described in RFC 2104, taking initial
- octets and discarding trailing octets. TSIG truncation can only be
- to an integral number of octets. On receipt of a packet with
- truncation thus indicated, the locally calculated MAC is similarly
- truncated and only the truncated values compared for
- authentication. The request MAC used when calculating the TSIG MAC
- for a reply is the trucated request MAC.
-
- 4. "MAC size" field is less than the larger of 10 (octets) and half
- the length of the hash function in use:
- With the exception of certain TSIG error messages described in
- RFC 2845 section 3.2 where it is permitted that the MAC size be
- zero, this case MUST NOT be generated and if received MUST cause
- the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
- size limit for this case can also, for the hash functions
- mentioned in this document, be stated as less than half the hash
- function length for hash functions other than MD5 and less than 10
- octets for MD5.
-
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
- SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-4. TSIG Policy Provisions and Truncation Error
-
- Use of TSIG is by mutual agreement between a resolver and server.
- Implicit in such "agreement" are policies as to acceptable keys and
- algorithms and, with the extensions in this doucment, truncations. In
- particular note the following:
-
- Such policies MAY require the rejection of TSIGs even though they
- use an algorithm for which implementation is mandatory.
-
- When a policy calls for the acceptance of a TSIG with a particular
- algorithm and a particular non-zero amount of trunction it SHOULD
- also permit the use of that algorithm with lesser truncation (a
- longer MAC) up to the full HMAC output.
-
- Regardless of a lower acceptable truncated MAC length specified by
- policy, a reply SHOULD be sent with a MAC at least as long as that in
- the corresponding request unless the request specified a MAC length
- longer than the HMAC output.
-
- Implementations permitting policies with multiple acceptable
- algorithms and/or truncations SHOULD permit this list to be ordered
- by presumed strength and SHOULD allow different truncations for the
- same algorithm to be treatred as spearate entities in this list. When
- so implemented, policies SHOULD accept a presumed stronger algorithm
- and truncation than the minimum strength required by the policy.
-
- If a TSIG is received with truncation which is permitted under
- Section 3 above but the MAC is too short for the policy in force, an
- RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-5. IANA Considerations
-
- This document, on approval for publication as a standards track RFC,
- (1) registers the new TSIG algorithm identifiers listed in Section 2
- with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22
- suggested].
-
-
-
-
-6. Security Considerations
-
- For all of the message authentication code algorithms listed herein,
- those producing longer values are believed to be stronger; however,
- while there have been some arguments that mild truncation can
- strengthen a MAC by reducing the information available to an
- attacker, excessive truncation clearly weakens authentication by
- reducing the number of bits an attacker has to try to brute force
- [RFC 2104].
-
- Significant progress has been made recently in cryptanalysis of hash
- function of the type used herein, all of which ultimately derive from
- the design of MD4. While the results so far should not effect HMAC,
- the stronger SHA-1 and SHA-256 algorithms are being made mandatory
- due to caution.
-
- See also the Security Considerations section of [RFC 2845] from which
- the limits on truncation in this RFC were taken.
-
-
-
-6. Copyright and Disclaimer
-
- 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.
-
-
- 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.
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-7. Normative References
-
- [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
- Federal Information Processing Standard, with Change Notice 1,
- February 2004.
-
- [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
- 1321, April 1992.
-
- [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104, February 1997.
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
-
-
-8. Informative References.
-
- [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
- Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
- [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
- 1 (SHA1)", RFC 3174, September 2001.
-
- [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
- J., and R. Hall, "Generic Security Service Algorithm for Secret Key
- Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
- 2003.
-
- [RFC 3874] - "A 224-bit One-way Hash Function: SHA-224", R. Housley,
- September 2004,
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554 (w)
-
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in October 2005.
-
- Its file name is draft-ietf-dnsext-tsig-sha-03.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
-
+++ /dev/null
-DNSEXT Working Group E. Lewis
-INTERNET DRAFT NeuStar
-Expiration Date: November 16, 2005 May 16, 2005
-
- The Role of Wildcards
- in the Domain Name System
- draft-ietf-dnsext-wcard-clarify-07.txt
-
-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 November 16, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This is an update to the wildcard definition of RFC 1034. The
- interaction with wildcards and CNAME is changed, an error
- condition removed, and the words defining some concepts central
- to wildcards are changed. The overall goal is not to change
- wildcards, but to refine the definition of RFC 1034.
-
-1 Introduction
-
- In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
- synthesis of answers from special resource records called
- wildcards. The definition in RFC 1034 is incomplete and has
- proven to be confusing. This document describes the wildcard
- synthesis by adding to the discussion and making limited
- modifications. Modifications are made to close inconsistencies
- that have led to interoperability issues. This description
- does not expand the service intended by the original definition.
-
- Staying within the spirit and style of the original documents,
- this document avoids specifying rules for DNS implementations
- regarding wildcards. The intention is to only describe what is
- needed for interoperability, not restrict implementation choices.
- In addition, consideration has been given to minimize any
- backwards compatibility with implementations that have complied
- with RFC 1034's definition.
-
- This document is focused on the concept of wildcards as defined
- in RFC 1034. Nothing is implied regarding alternative approaches,
- nor are alternatives discussed.
-
-1.1 Motivation
-
- Many DNS implementations have diverged with respect to wildcards
- in different ways from the original definition, or at from least
- what had been intended. Although there is clearly a need to
- clarify the original documents in light of this alone, the impetus
- for this document lay in the engineering of the DNS security
- extensions [RFC4033]. With an unclear definition of wildcards
- the design of authenticated denial became entangled.
-
- This document is intended to limit changes, only those based on
- implementation experience, and to remain as close to the original
- document as possible. To reinforce this, relevant sections of RFC
- 1034 are repeated verbatim to help compare the old and new text.
-
-1.2 The Original Definition
-
- The context of the wildcard concept involves the algorithm by
- which a name server prepares a response (in RFC 1034's section
- 4.3.2) and the way in which a resource record (set) is identified
- as being a source of synthetic data (section 4.3.3).
-
- The beginning of the discussion ought to start with the definition
- of the term "wildcard" as it appears in RFC 1034, section 4.3.3.
-
-# In the previous algorithm, special treatment was given to RRs with
-# owner names starting with the label "*". Such RRs are called
-# wildcards. Wildcard RRs can be thought of as instructions for
-# synthesizing RRs. When the appropriate conditions are met, the name
-# server creates RRs with an owner name equal to the query name and
-# contents taken from the wildcard RRs.
-
- This passage appears after the algorithm in which the term wildcard
- is first used. In this definition, wildcard refers to resource
- records. In other usage, wildcard has referred to domain names,
- and it has been used to describe the operational practice of
- relying on wildcards to generate answers. It is clear from this
- that there is a need to define clear and unambiguous terminology
- in the process of discussing wildcards.
-
- The mention of the use of wildcards in the preparation of a
- response is contained in step 3c of RFC 1034's section 4.3.2
- entitled "Algorithm." Note that "wildcard" does not appear in
- the algorithm, instead references are made to the "*" label.
- The portion of the algorithm relating to wildcards is
- deconstructed in detail in section 3 of this document, this is
- the beginning of the passage.
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if [...]
-# the "*" label exists.
-
- The scope of this document is the RFC 1034 definition of
- wildcards and the implications of updates to those documents,
- such as DNSSEC. Alternate schemes for synthesizing answers are
- not considered. (Note that there is no reference listed. No
- document is known to describe any alternate schemes, although
- there has been some mention of them in mailing lists.)
-
-1.3 This Document
-
- This document accomplishes these three items.
- o Defines new terms
- o Makes minor changes to avoid conflicting concepts
- o Describes the actions of certain resource records as wildcards
-
-1.3.1 New Terms
-
- To help in discussing what resource records are wildcards, two
- terms will be defined - "asterisk label" and "wild card domain
- name". These are defined in section 2.1.1.
-
- To assist in clarifying the role of wildcards in the name server
- algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
- encloser" are defined. These definitions are in section 3.3.2.
- "Label match" is defined in section 3.2.
-
- The introduction of new terms ought not have an impact on any
- existing implementations. The new terms are used only to make
- discussions of wildcards clearer.
-
-1.3.2 Changed Text
-
- The definition of "existence" is changed, superficially. This
- change will not be apparent to implementations; it is needed to
- make descriptions more precise. The change appears in section
- 2.2.3.
-
- RFC 1034, section 4.3.3., seems to prohibit having two asterisk
- labels in a wildcard owner name. With this document the
- restriction is removed entirely. This change and its implications
- are in section 2.1.3.
-
- The actions when a source of synthesis owns a CNAME RR are
- changed to mirror the actions if an exact match name owns a
- CNAME RR. This is an addition to the words in RFC 1034,
- section 4.3.2, step 3, part c. The discussion of this is in
- section 3.3.3.
-
- Only the latter change represents an impact to implementations.
- The definition of existence is not a protocol impact. The change
- to the restriction on names is unlikely to have an impact, as
- there was no discussion of how to enforce the restriction.
-
-1.3.3 Considerations with Special Types
-
- This document describes semantics of wildcard CNAME RRSets
- [RFC2181], wildcard NS RRSets, wildcard SOA RRSets, wildcard
- DNAME RRSets [RFC2672], wildcard DS RRSets [RFC TBD], and empty
- non-terminal wildcards. Understanding these types in the context
- of wildcards has been clouded because these types incur special
- processing if they are the result of an exact match. This
- discussion is in section 4.
-
- These discussions do not have an implementation impact, they cover
- existing knowledge of the types, but to a greater level of detail.
-
-1.4 Standards Terminology
-
- This document does not use terms as defined in "Key words for use
- in RFCs to Indicate Requirement Levels." [RFC2119]
-
- Quotations of RFC 1034 are denoted by a '#' in the leftmost
- column.
-
-2 Wildcard Syntax
-
- The syntax of a wildcard is the same as any other DNS resource
- record, across all classes and types. The only significant
- feature is the owner name.
-
- Because wildcards are encoded as resource records with special
- names, they are included in zone transfers and incremental zone
- transfers[RFC1995]. This feature has been underappreciated until
- discussions on alternative approaches to wildcards appeared on
- mailing lists.
-
-2.1 Identifying a Wildcard
-
- To provide a more accurate description of "wildcards", the
- definition has to start with a discussion of the domain names
- that appear as owners. Two new terms are needed, "Asterisk
- Label" and "Wild Card Domain Name."
-
-2.1.1 Wild Card Domain Name and Asterisk Label
-
- A "wild card domain name" is defined by having its initial
- (i.e., left-most or least significant) label be, in binary format:
-
- 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
- The first octet is the normal label type and length for a 1 octet
- long label, the second octet is the ASCII representation [RFC20]
- for the '*' character.
-
- A descriptive name of a label equaling that value is an "asterisk
- label."
-
- RFC 1034's definition of wildcard would be "a resource record
- owned by a wild card domain name."
-
-2.1.2 Asterisks and Other Characters
-
- No label values other than that in section 2.1.1 are asterisk
- labels, hence names beginning with other labels are never wild
- card domain names. Labels such as 'the*' and '**' are not
- asterisk labels, they do not start wild card domain names.
-
-2.1.3 Non-terminal Wild Card Domain Names
-
- In section 4.3.3, the following is stated:
-
-# .......................... The owner name of the wildcard RRs is of
-# the form "*.<anydomain>", where <anydomain> is any domain name.
-# <anydomain> should not contain other * labels......................
-
- This restriction is lifted because the original documentation of it
- is incomplete and the restriction does not serve any purpose given
- years of operational experience.
-
- Indirectly, the above passage raises questions about wild card
- domain names having subdomains and possibly being an empty
- non-terminal. By thinking of domain names such as
- "*.example.*.example." and "*.*.example." and focusing on the
- right-most asterisk label in each, the issues become apparent.
-
- Although those example names have been restricted per RFC 1034,
- a name such as "example.*.example." illustrates the same problems.
- The sticky issue of subdomains and empty non-terminals is not
- removed by the restriction. With that conclusion, the restriction
- appears to be meaningless, worse yet, it implies that an
- implementation would have to perform checks that do little more
- than waste CPU cycles.
-
- A wild card domain name can have subdomains. There is no need
- to inspect the subdomains to see if there is another asterisk
- label in any subdomain.
-
- A wild card domain name can be an empty non-terminal. (See the
- upcoming sections on empty non-terminals.) In this case, any
- lookup encountering it will terminate as would any empty
- non-terminal match.
-
-2.2 Existence Rules
-
- The notion that a domain name 'exists' is mentioned in the
- definition of wildcards. In section 4.3.3 of RFC 1034:
-
-# Wildcard RRs do not apply:
-#
-...
-# - When the query name or a name between the wildcard domain and
-# the query name is know[n] to exist. For example, if a wildcard
-
- RFC 1034 also refers to non-existence in the process of generating
- a response that results in a return code of "name error."
- NXDOMAIN is introduced in RFC 2308, section 2.1 says "In this
- case the domain ... does not exist." The overloading of the term
- "existence" is confusing.
-
- For the purposes of this document, a domain name is said to
- exist if it plays a role in the execution of the algorithms in
- RFC 1034. This document avoids discussion determining when an
- authoritative name error has occurred.
-
-2.2.1 An Example
-
- To illustrate what is meant by existence consider this complete
- zone:
-
- $ORIGIN example.
- example. 3600 IN SOA <SOA RDATA>
- example. 3600 NS ns.example.com.
- example. 3600 NS ns.example.net.
- *.example. 3600 TXT "this is a wild card"
- *.example. 3600 MX 10 host1.example.
- sub.*.example. 3600 TXT "this is not a wild card"
- host1.example. 3600 A 192.0.4.1
- _ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
- _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
- subdel.example. 3600 NS ns.example.com.
- subdel.example. 3600 NS ns.example.net.
-
- A look at the domain names in a tree structure is helpful:
-
- |
- -------------example------------
- / / \ \
- / / \ \
- / / \ \
- * host1 host2 subdel
- | | |
- | | |
- sub _tcp _tcp
- | |
- | |
- _ssh _ssh
-
- The following queries would be synthesized from one of the
- wildcards:
-
- QNAME=host3.example. QTYPE=MX, QCLASS=IN
- the answer will be a "host3.example. IN MX ..."
-
- QNAME=host3.example. QTYPE=A, QCLASS=IN
- the answer will reflect "no error, but no data"
- because there is no A RR set at '*.example.'
-
- QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
- the answer will be "foo.bar.example. IN TXT ..."
- because bar.example. does not exist, but the wildcard
- does.
-
- The following queries would not be synthesized from any of the
- wildcards:
-
- QNAME=host1.example., QTYPE=MX, QCLASS=IN
- because host1.example. exists
-
- QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
- because *.example. exists
-
- QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
- because sub.*.example. exists
-
- QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
- because _tcp.host1.example. exists (without data)
-
- QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
- because subdel.example. exists (and is a zone cut)
-
-2.2.2 Empty Non-terminals
-
- Empty non-terminals [RFC2136, Section 7.16] are domain names
- that own no resource records but have subdomains that do. In
- section 2.2.1, "_tcp.host1.example." is an example of a empty
- non-terminal name. Empty non-terminals are introduced by this
- text in section 3.1 of RFC 1034:
-
-# The domain name space is a tree structure. Each node and leaf on
-# the tree corresponds to a resource set (which may be empty). The
-# domain system makes no distinctions between the uses of the
-# interior nodes and leaves, and this memo uses the term "node" to
-# refer to both.
-
- The parenthesized "which may be empty" specifies that empty non-
- terminals are explicitly recognized, and that empty non-terminals
- "exist."
-
- Pedantically reading the above paragraph can lead to an
- interpretation that all possible domains exist - up to the
- suggested limit of 255 octets for a domain name [RFC1035].
- For example, www.example. may have an A RR, and as far as is
- practically concerned, is a leaf of the domain tree. But the
- definition can be taken to mean that sub.www.example. also
- exists, albeit with no data. By extension, all possible domains
- exist, from the root on down. As RFC 1034 also defines "an
- authoritative name error indicating that the name does not exist"
- in section 4.3.1, this is not the intent of the original document.
-
-2.2.3 Yet Another Definition of Existence
-
- RFC1034's wording is fixed by the following paragraph:
-
- The domain name space is a tree structure. Nodes in the tree
- either own at least one RRSet and/or have descendants that
- collectively own at least on RRSet. A node may have no RRSets
- if it has descendents that do, this node is a empty non-terminal.
- A node may have its own RRSets and have descendants with RRSets
- too.
-
- A node with no descendants is a leaf node. Empty leaf nodes do
- not exist.
-
- Note that at a zone boundary, the domain name owns data,
- including the NS RR set. At the delegating server, the NS RR
- set is not authoritative, but that is of no consequence here.
- The domain name owns data, therefore, it exists.
-
-2.3 When does a Wild Card Domain Name is not Special
-
- When a wild card domain name appears in a message's query section,
- no special processing occurs. An asterisk label in a query name
- only (label) matches an asterisk label in the existing zone tree
- when the 4.3.2 algorithm is being followed.
-
- When a wild card domain name appears in the resource data of a
- record, no special processing occurs. An asterisk label in that
- context literally means just an asterisk.
-
-3. Impact of a Wild Card Domain Name On a Response
-
- The description of how wildcards impact response generation is in
- RFC 1034, section 4.3.2. That passage contains the algorithm
- followed by a server in constructing a response. Within that
- algorithm, step 3, part 'c' defines the behavior of the wild card.
-
- The algorithm in RFC 1034, section 4.3.2. is not intended to be
- pseudo code, i.e., its steps are not intended to be followed in
- strict order. The "algorithm" is a suggestion. As such, in
- step 3, parts a, b, and c, do not have to be implemented in
- that order.
-
-3.1 Step 2
-
- Step 2 of the RFC 1034's section 4.3.2 reads:
-
-# 2. Search the available zones for the zone which is the nearest
-# ancestor to QNAME. If such a zone is found, go to step 3,
-# otherwise step 4.
-
- In this step, the most appropriate zone for the response is
- chosen. The significance of this step is that it means all of
- step 3 is being performed within one zone. This has significance
- when considering whether or not an SOA RR can be ever be used for
- synthesis.
-
-3.2 Step 3
-
- Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
- But the beginning of the step is important and needs explanation.
-
-# 3. Start matching down, label by label, in the zone. The
-# matching process can terminate several ways:
-
- The word 'matching' refers to label matching. The concept
- is based in the view of the zone as the tree of existing names.
- The query name is considered to be an ordered sequence of
- labels - as if the name were a path from the root to the owner
- of the desired data. (Which it is - 3rd paragraph of RFC 1034,
- section 3.1.)
-
- The process of label matching a query name ends in exactly one of
- three choices, the parts 'a', 'b', and 'c'. Either the name is
- found, the name is below a cut point, or the name is not found.
-
- Once one of the parts is chosen, the other parts are not
- considered. (E.g., do not execute part 'c' and then change
- the execution path to finish in part 'b'.) The process of label
- matching is also done independent of the query type (QTYPE).
-
- Parts 'a' and 'b' are not an issue for this clarification as they
- do not relate to record synthesis. Part 'a' is an exact match
- that results in an answer, part 'b' is a referral. It is
- possible, from the description given, that a query might fit
- into both part a and part b, this is not within the scope of
- this document.
-
-3.3 Part 'c'
-
- The context of part 'c' is that the process of label matching the
- labels of the query name has resulted in a situation in which
- there is no corresponding label in the tree. It is as if the
- lookup has "fallen off the tree."
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if [...]
-# the "*" label exists.
-
- To help describe the process of looking 'to see if [...] the "*"
- label exists' a term has been coined to describe the last domain
- (node) matched. The term is "closest encloser."
-
-3.3.1 Closest Encloser and the Source of Synthesis
-
- The closest encloser is the node in the zone's tree of existing
- domain names that has the most labels matching the query name
- (consecutively, counting from the root label downward). Each match
- is a "label match" and the order of the labels is the same.
-
- The closest encloser is, by definition, an existing name in the
- zone. The closest encloser might be an empty non-terminal or even
- be a wild card domain name itself. In no circumstances is the
- closest encloser to be used to synthesize records for the current
- query.
-
- The source of synthesis is defined in the context of a query
- process as that wild card domain name immediately descending
- from the closest encloser, provided that this wild card domain
- name exists. "Immediately descending" means that the source
- of synthesis has a name of the form:
- <asterisk label>.<closest encloser>.
- A source of synthesis does not guarantee having a RRSet to use
- for synthesis. The source of synthesis could be an empty
- non-terminal.
-
- If the source of synthesis does not exist (not on the domain
- tree), there will be no wildcard synthesis. There is no search
- for an alternate.
-
- The important concept is that for any given lookup process, there
- is at most one place at which wildcard synthetic records can be
- obtained. If the source of synthesis does not exist, the lookup
- terminates, the lookup does not look for other wildcard records.
-
-3.3.2 Closest Encloser and Source of Synthesis Examples
-
- To illustrate, using the example zone in section 2.2.1 of this
- document, the following chart shows QNAMEs and the closest
- enclosers.
-
- QNAME Closest Encloser Source of Synthesis
- host3.example. example. *.example.
- _telnet._tcp.host1.example. _tcp.host1.example. no source
- _telnet._tcp.host2.example. host2.example. no source
- _telnet._tcp.host3.example. example. *.example.
- _chat._udp.host3.example. example. *.example.
- foobar.*.example. *.example. no source
-
-3.3.3 Type Matching
-
- RFC 1034 concludes part 'c' with this:
-
-# If the "*" label does not exist, check whether the name
-# we are looking for is the original QNAME in the query
-# or a name we have followed due to a CNAME. If the name
-# is original, set an authoritative name error in the
-# response and exit. Otherwise just exit.
-#
-# If the "*" label does exist, match RRs at that node
-# against QTYPE. If any match, copy them into the answer
-# section, but set the owner of the RR to be QNAME, and
-# not the node with the "*" label. Go to step 6.
-
- The final paragraph covers the role of the QTYPE in the lookup
- process.
-
- Based on implementation feedback and similarities between step
- 'a' and step 'c' a change to this passage has been made.
-
- The change is to add the following text to step 'c':
-
- If the data at the source of synthesis is a CNAME, and
- QTYPE doesn't match CNAME, copy the CNAME RR into the
- answer section of the response changing the owner name
- to the QNAME, change QNAME to the canonical name in the
- CNAME RR, and go back to step 1.
-
- This is essentially the same text in step a covering the
- processing of CNAME RRSets.
-
-4. Considerations with Special Types
-
- Sections 2 and 3 of this document discuss wildcard synthesis
- with respect to names in the domain tree and ignore the impact
- of types. In this section, the implication of wildcards of
- specific types are discussed. The types covered are those
- that have proven to be the most difficult to understand. The
- types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
- "none," i.e., empty non-terminal wild card domain names.
-
-4.1 SOA RRSet at a Wild Card Domain Name
-
- A wild card domain name owning an SOA RRSet means that the
- domain is at the root of the zone (apex). The domain can not
- be a source of synthesis because that is, by definition, a
- descendent node (of the closest encloser) and a zone apex is
- at the top of the zone.
-
- Although a wild card domain name owning an SOA RRSet can never
- be a source of synthesis, there is no reason to forbid the
- ownership of an SOA RRSet.
-
- E.g., given this zone:
- $ORIGIN *.example.
- @ 3600 IN SOA <SOA RDATA>
- 3600 NS ns1.example.com.
- 3600 NS ns1.example.net.
- www 3600 TXT "the www txt record"
-
- A query for www.*.example.'s TXT record would still find the
- "the www txt record" answer. The reason is that the asterisk
- label only becomes significant when RFC 1034's 4.3.2, step 3
- part 'c' in in effect.
-
- Of course, there would need to be a delegation in the parent
- zone, "example." for this to work too. This is covered in the
- next section.
-
-4.2 NS RRSet at a Wild Card Domain Name
-
- With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
- in place, the semantics of a wild card domain name owning an
- NS RR has come to be poorly defined. The dilemma relates to
- a conflict between the rules for synthesis in part 'c' and the
- fact that the resulting synthesis generates a record for which
- the zone is not authoritative. In a DNSSEC signed zone, the
- mechanics of signature management (generation and inclusion
- in a message) become unclear.
-
- After some lengthy discussions, there has been no clear "best
- answer" on how to document the semantics of such a situation.
- Barring such records from the DNS would require definition of
- rules for that, as well as introducing a restriction on records
- that were once legal. Allowing such records and amending the
- process of signature management would entail complicating the
- DNSSEC definition.
-
- Combining these observations with thought that a wild card
- domain name owning an NS record is an operationally uninteresting
- scenario, i.e., it won't happen in the normal course of events,
- accomodating this situation in the specification would also be
- categorized as "needless complication." Further, expending more
- effort on this topic has proven to be an exercise in diminishing
- returns.
-
- In summary, there is no definition given for wild card domain
- names owning an NS RRSet. The semantics are left undefined until
- there is a clear need to have a set defined, and until there is
- a clear direction to proceed. Operationally, inclusion of wild
- card NS RRSets in a zone is discouraged, but not barred.
-
-4.3 CNAME RRSet at a Wild Card Domain Name
-
- The issue of a CNAME RRSet owned by a wild card domain name has
- prompted a suggested change to the last paragraph of step 3c of
- the algorithm in 4.3.2. The changed text appears in section
- 3.3.3 of this document.
-
-4.4 DNAME RRSet at a Wild Card Domain Name
-
- Ownership of a DNAME RRSet by a wild card domain name
- represents a threat to the coherency of the DNS and is to be
- avoided or outright rejected. Such a DNAME RRSet represents
- non-deterministic synthesis of rules fed to different caches.
- As caches are fed the different rules (in an unpredictable
- manner) the caches will cease to be coherent. ("As caches
- are fed" refers to the storage in a cache of records obtained
- in responses by recursive or iterative servers.)
-
- For example, assume one cache, responding to a recursive request,
- obtains the record "a.b.example. DNAME foo.bar.tld." and another
- cache obtains "b.example. DNAME foo.bar.tld.", both generated
- from the record "*.example. DNAME foo.bar.tld." by an
- authoritative server.
-
- The DNAME specification is not clear on whether DNAME records
- in a cache are used to rewrite queries. In some interpretations,
- the rewrite occurs, in some, it is not. Allowing for the
- occurrence of rewriting, queries for "sub.a.b.example. A" may
- be rewritten as "sub.foo.bar.tld. A" by the former caching
- server and may be rewritten as "sub.a.foo.bar.tld. A" by the
- latter. Coherency is lost, an operational nightmare ensues.
-
- Another justification for banning or avoiding wildcard DNAME
- records is the observation that such a record could synthesize
- a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
- There is a restriction in the DNAME definition that no domain
- exist below a DNAME-owning domain, hence, the wildcard DNAME
- is not to be permitted.
-
-4.5 SRV RRSet at a Wild Card Domain Name
-
- The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
- definition of the record, there is some confusion over the term
- "Name." The definition reads as follows:
-
-# The format of the SRV RR
-...
-# _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-...
-# Name
-# The domain this RR refers to. The SRV RR is unique in that the
-# name one searches for is not this name; the example near the end
-# shows this clearly.
-
- Do not confuse the definition "Name" with a domain name. I.e.,
- once removing the _Service and _Proto labels from the owner name
- of the SRV RRSet, what remains could be a wild card domain name
- but this is immaterial to the SRV RRSet.
-
- E.g., If an SRV record is:
- _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
-
- *.example is a wild card domain name and although it it the Name
- of the SRV RR, it is not the owner (domain name). The owner
- domain name is "_foo._udp.*.example." which is not a wild card
- domain name.
-
- The confusion is likely based on the mixture of the specification
- of the SRV RR and the description of a "use case."
-
-4.6 DS RRSet at a Wild Card Domain Name
-
- A DS RRSet owned by a wild card domain name is meaningless and
- harmless.
-
-4.7 NSEC RRSet at a Wild Card Domain Name
-
- Wild card domain names in DNSSEC signed zones will have an NSEC
- RRSet. Synthesis of these records will only occur when the
- query exactly matches the record. Synthesized NSEC RR's will not
- be harmful as they will never be used in negative caching or to
- generate a negative response.
-
-4.8 RRSIG at a Wild Card Domain Name
-
- RRSIG records will be present at a wild card domain name in a
- signed zone, and will be synthesized along with data sought in a
- query. The fact that the owner name is synthesized is not a
- problem as the label count in the RRSIG will instruct the
- verifying code to ignore it.
-
-4.9 Empty Non-terminal Wild Card Domain Name
-
- If a source of synthesis is an empty non-terminal, then the
- response will be one of no error in the return code and no RRSet
- in the answer section.
-
-5. Security Considerations
-
- This document is refining the specifications to make it more
- likely that security can be added to DNS. No functional
- additions are being made, just refining what is considered
- proper to allow the DNS, security of the DNS, and extending
- the DNS to be more predictable.
-
-6. IANA Considerations
-
- None.
-
-7. References
-
- Normative References
-
- [RFC20] ASCII Format for Network Interchange, V.G. Cerf,
- Oct-16-1969
-
- [RFC1034] Domain Names - Concepts and Facilities,
- P.V. Mockapetris, Nov-01-1987
-
- [RFC1035] Domain Names - Implementation and Specification, P.V
- Mockapetris, Nov-01-1987
-
- [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
-
- [RFC2119] Key Words for Use in RFCs to Indicate Requirement
- Levels, S Bradner, March 1997
-
- [RFC2181] Clarifications to the DNS Specification, R. Elz and
- R. Bush, July 1997
-
- [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
- M. Andrews, March 1998
-
- [RFC2782] A DNS RR for specifying the location of services (DNS
- SRV), A. Gulbrandsen, et.al., February 2000
-
- [RFC4033] DNS Security Introduction and Requirements, R. Arends,
- et.al., March 2005
-
- [RFC4034] Resource Records for the DNS Security Extensions,
- R. Arends, et.al., March 2005
-
- [RFC4035] Protocol Modifications for the DNS Security Extensions,
- R. Arends, et.al., March 2005
-
- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
- August 1999
-
- Informative References
-
- [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
- P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
- April 1997
-
-8. Editor
-
- Name: Edward Lewis
- Affiliation: NeuStar
- Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
- Phone: +1-571-434-5468
- Email: ed.lewis@neustar.biz
-
- Comments on this document can be sent to the editor or the mailing
- list for the DNSEXT WG, namedroppers@ops.ietf.org.
-
-9. Others Contributing to the Document
-
- This document represents the work of a large working group. The
- editor merely recorded the collective wisdom of the working group.
-
-10. Trailing Boilerplate
-
- 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.
-
- 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.
-
-Intellectual Property
-
- 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-Expiration
-
- This document expires on or about November 16, 2005.
\ No newline at end of file
+++ /dev/null
-
-
-
-DNS Operations M. Larson
-Internet-Draft P. Barber
-Expires: April 27, 2005 VeriSign
- October 27, 2004
-
-
- Observed DNS Resolution Misbehavior
- draft-ietf-dnsop-bad-dns-res-03
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 27, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004).
-
-Abstract
-
- This memo describes DNS name server and resolver behavior that
- results in a significant query volume sent to the root and top-level
- domain (TLD) name servers. In some cases we recommend minor
- additions to the DNS protocol specification and corresponding changes
- in iterative resolver implementations to alleviate these unnecessary
- queries. The recommendations made in this document are a direct
- byproduct of observation and analysis of abnormal query traffic
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 1]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- patterns seen at two of the thirteen root name servers and all
- thirteen com/net TLD name servers.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [1].
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 A note about terminology in this memo . . . . . . . . . . 3
- 2. Observed iterative resolver misbehavior . . . . . . . . . . 5
- 2.1 Aggressive requerying for delegation information . . . . . 5
- 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6
- 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 6
- 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7
- 2.3 Inability to follow multiple levels of out-of-zone glue . 7
- 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 8
- 2.4 Aggressive retransmission when fetching glue . . . . . . . 8
- 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9
- 2.5 Aggressive retransmission behind firewalls . . . . . . . . 9
- 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10
- 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 10
- 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11
- 2.7 Name server records with zero TTL . . . . . . . . . . . . 11
- 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12
- 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 12
- 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13
- 2.9 Queries for domain names resembling IP addresses . . . . . 13
- 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13
- 2.10 Misdirected recursive queries . . . . . . . . . . . . . 14
- 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 14
- 2.11 Suboptimal name server selection algorithm . . . . . . . 14
- 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . 15
- 3. IANA considerations . . . . . . . . . . . . . . . . . . . . 16
- 4. Security considerations . . . . . . . . . . . . . . . . . . 17
- 5. Internationalization considerations . . . . . . . . . . . . 18
- 6. Normative References . . . . . . . . . . . . . . . . . . . . 18
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
- Intellectual Property and Copyright Statements . . . . . . . 20
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 2]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
-1. Introduction
-
- Observation of query traffic received by two root name servers and
- the thirteen com/net TLD name servers has revealed that a large
- proportion of the total traffic often consists of "requeries". A
- requery is the same question (<qname, qtype, qclass>) asked
- repeatedly at an unexpectedly high rate. We have observed requeries
- from both a single IP address and multiple IP addresses (i.e., the
- same query received simultaneously from multiple IP addresses).
-
- By analyzing requery events we have found that the cause of the
- duplicate traffic is almost always a deficient iterative resolver,
- stub resolver or application implementation combined with an
- operational anomaly. The implementation deficiencies we have
- identified to date include well-intentioned recovery attempts gone
- awry, insufficient caching of failures, early abort when multiple
- levels of glue records must be followed, and aggressive retry by stub
- resolvers or applications. Anomalies that we have seen trigger
- requery events include lame delegations, unusual glue records, and
- anything that makes all authoritative name servers for a zone
- unreachable (DoS attacks, crashes, maintenance, routing failures,
- congestion, etc.).
-
- In the following sections, we provide a detailed explanation of the
- observed behavior and recommend changes that will reduce the requery
- rate. Some of the changes recommended affect the core DNS protocol
- specification, described principally in RFC 1034 [2], RFC 1035 [3]
- and RFC 2181 [4].
-
-1.1 A note about terminology in this memo
-
- To recast an old saying about standards, the nice thing about DNS
- terms is that there are so many of them to choose from. Writing or
- talking about DNS can be difficult and cause confusion resulting from
- a lack of agreed-upon terms for its various components. Further
- complicating matters are implementations that combine multiple roles
- into one piece of software, which makes naming the result
- problematic. An example is the entity that accepts recursive
- queries, issues iterative queries as necessary to resolve the initial
- recursive query, caches responses it receives, and which is also able
- answer questions about certain zones authoritatively. Often called a
- "recursive name server" or a "caching name server", it is in fact an
- iterative resolver combined with an authoritative name server.
-
- This memo is concerned principally with the behavior of iterative
- resolvers, which are typically found as part of a recursive name
- server. This memo uses the more precise term "iterative resolver",
- because the focus is usually on that component. In instances where
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 3]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- the name server role of this entity requires mentioning, this memo
- uses the term "recursive name server". For example, the name server
- component of a recursive name server receives DNS queries and the
- iterative resolver component sends queries.
-
- The advent of IPv6 requires mentioning AAAA records as well as A
- records when discussing glue. To avoid continuous repetition and
- qualification, this memo uses the general term "address records" to
- encompass both A and AAAA records when a particular situation is
- relevant to both types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 4]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
-2. Observed iterative resolver misbehavior
-
-2.1 Aggressive requerying for delegation information
-
- There can be times when every name server in a zone's NS RRset is
- unreachable (e.g., during a network outage), unavailable (e.g., the
- name server process is not running on the server host) or
- misconfigured (e.g., the name server is not authoritative for the
- given zone, also known as "lame"). Consider an iterative resolver
- that attempts to resolve a query for a domain name in such a zone and
- discovers that none of the zone's name servers can provide an answer.
- We have observed a recursive name server implementation whose
- iterative resolver then verifies the zone's NS RRset in its cache by
- querying for the zone's delegation information: it sends a query for
- the zone's NS RRset to one of the parent zone's name servers.
-
- For example, suppose that "example.com" has the following NS RRset:
-
- example.com. IN NS ns1.example.com.
- example.com. IN NS ns2.example.com.
-
- Upon receipt of a query for "www.example.com" and assuming that
- neither "ns1.example.com" nor "ns2.example.com" can provide an
- answer, this iterative resolver implementation immediately queries a
- "com" zone name server for the "example.com" NS RRset to verify it
- has the proper delegation information. This implementation performs
- this query to a zone's parent zone for each recursive query it
- receives that fails because of a completely unresponsive set of name
- servers for the target zone. Consider the effect when a popular zone
- experiences a catastrophic failure of all its name servers: now every
- recursive query for domain names in that zone sent to this recursive
- name server implementation results in a query to the failed zone's
- parent name servers. On one occasion when several dozen popular
- zones became unreachable, the query load on the com/net name servers
- increased by 50%.
-
- We believe this verification query is not reasonable. Consider the
- circumstances: When an iterative resolver is resolving a query for a
- domain name in a zone it has not previously searched, it uses the
- list of name servers in the referral from the target zone's parent.
- If on its first attempt to search the target zone, none of the name
- servers in the referral is reachable, a verification query to the
- parent is pointless: this query to the parent would come so quickly
- on the heels of the referral that it would be almost certain to
- contain the same list of name servers. The chance of discovering any
- new information is slim.
-
- The other possibility is that the iterative resolver successfully
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 5]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- contacts one of the target zone's name servers and then caches the NS
- RRset from the authority section of a response, the proper behavior
- according to section 5.4.1 of RFC 2181 [4], because the NS RRset from
- the target zone is more trustworthy than delegation information from
- the parent zone. If, while processing a subsequent recursive query,
- the iterative resolver discovers that none of the name servers
- specified in the cached NS RRset is available or authoritative,
- querying the parent would be wrong. An NS RRset from the parent zone
- would now be less trustworthy than data already in the cache.
-
- For this query of the parent zone to be useful, the target zone's
- entire set of name servers would have to change AND the former set of
- name servers would have to be deconfigured or decommissioned AND the
- delegation information in the parent zone would have to be updated
- with the new set of name servers, all within the TTL of the target
- zone's NS RRset. We believe this scenario is uncommon:
- administrative best practices dictate that changes to a zone's set of
- name servers happen gradually when at all possible, with servers
- removed from the NS RRset left authoritative for the zone as long as
- possible. The scenarios that we can envision that would benefit from
- the parent requery behavior do not outweigh its damaging effects.
-
-2.1.1 Recommendation
-
- An iterative resolver MUST NOT send a query for the NS RRset of a
- non-responsive zone to any of the name servers for that zone's parent
- zone. For the purposes of this injunction, a non-responsive zone is
- defined as a zone for which every name server listed in the zone's NS
- RRset:
- 1. is not authoritative for the zone (i.e., lame), or,
- 2. returns a server failure response (RCODE=2), or,
- 3. is dead or unreachable according to section 7.2 of RFC 2308 [5].
-
-2.2 Repeated queries to lame servers
-
- Section 2.1 describes a catastrophic failure: when every name server
- for a zone is unable to provide an answer for one reason or another.
- A more common occurrence is when a subset of a zone's name servers
- are unavailable or misconfigured. Different failure modes have
- different expected durations. Some symptoms indicate problems that
- are potentially transient; for example, various types of ICMP
- unreachable messages because a name server process is not running or
- a host or network is unreachable, or a complete lack of a response to
- a query. Such responses could be the result of a host rebooting or
- temporary outages; these events don't necessarily require any human
- intervention and can be reasonably expected to be temporary.
-
- Other symptoms clearly indicate a condition requiring human
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 6]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- intervention, such as lame server: if a name server is misconfigured
- and not authoritative for a zone delegated to it, it is reasonable to
- assume that this condition has potential to last longer than
- unreachability or unresponsiveness. Consequently, repeated queries
- to known lame servers are not useful. In this case of a condition
- with potential to persist for a long time, a better practice would be
- to maintain a list of known lame servers and avoid querying them
- repeatedly in a short interval.
-
-2.2.1 Recommendation
-
- Iterative resolvers SHOULD cache name servers that they discover are
- not authoritative for zones delegated to them (i.e. lame servers).
- Lame servers MUST be cached against the specific query tuple <zone
- name, class, server IP address>. Zone name can be derived from the
- owner name of the NS record that was referenced to query the name
- server that was discovered to be lame. Implementations that perform
- lame server caching MUST refrain from sending queries to known lame
- servers based on a time interval from when the server is discovered
- to be lame. A minimum interval of thirty minutes is RECOMMENDED.
-
-2.3 Inability to follow multiple levels of out-of-zone glue
-
- Some iterative resolver implementations are unable to follow more
- than one level of out-of-zone glue. For example, consider the
- following delegations:
-
- foo.example. IN NS ns1.example.com.
- foo.example. IN NS ns2.example.com.
-
- example.com. IN NS ns1.test.example.net.
- example.com. IN NS ns2.test.example.net.
-
- test.example.net. IN NS ns1.test.example.net.
- test.example.net. IN NS ns2.test.example.net.
-
- An iterative resolver resolving the name "www.foo.example" must
- follow two levels of indirection, first obtaining address records for
- "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
- address records for "ns1.example.com" or "ns2.example.com" in order
- to query those name servers for the address records of
- "www.foo.example". While this situation may appear contrived, we
- have seen multiple similar occurrences and expect more as new generic
- top-level domains (gTLDs) become active. We anticipate many zones in
- new gTLDs will use name servers in other gTLDs, increasing the amount
- of inter-zone glue.
-
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 7]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
-2.3.1 Recommendation
-
- Clearly constructing a delegation that relies on multiple levels of
- out-of-zone glue is not a good administrative practice. This issue
- could be mitigated with an operational injunction in an RFC to
- refrain from construction of such delegations. In our opinion the
- practice is widespread enough to merit clarifications to the DNS
- protocol specification to permit it on a limited basis.
-
- Iterative resolvers SHOULD be able to handle at least three levels of
- indirection resulting from out-of-zone glue.
-
-2.4 Aggressive retransmission when fetching glue
-
- When an authoritative name server responds with a referral, it
- includes NS records in the authority section of the response.
- According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
- server should also "put whatever addresses are available into the
- additional section, using glue RRs if the addresses are not available
- from authoritative data or the cache." Some name server
- implementations take this address inclusion a step further with a
- feature called "glue fetching". A name server that implements glue
- fetching attempts to include address records for every NS record in
- the authority section. If necessary, the name server issues multiple
- queries of its own to obtain any missing address records.
-
- Problems with glue fetching can arise in the context of
- "authoritative-only" name servers, which only serve authoritative
- data and ignore requests for recursion. Such an entity will not
- normally generate any queries of its own. Instead it answers
- non-recursive queries from iterative resolvers looking for
- information in zones it serves. With glue fetching enabled, however,
- an authoritative server invokes an iterative resolver to look up an
- unknown address record to complete the additional section of a
- response.
-
- We have observed situations where the iterative resolver of a
- glue-fetching name server can send queries that reach other name
- servers, but is apparently prevented from receiving the responses.
- For example, perhaps the name server is authoritative-only and
- therefore its administrators expect it to receive only queries and
- not responses. Perhaps unaware of glue fetching and presuming that
- the name server's iterative resolver will generate no queries, its
- administrators place the name server behind a network device that
- prevents it from receiving responses. If this is the case, all
- glue-fetching queries will go answered.
-
- We have observed name server implementations whose iterative
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 8]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- resolvers retry excessively when glue-fetching queries are
- unanswered. A single com/net name server has received hundreds of
- queries per second from a single such source. Judging from the
- specific queries received and based on additional analysis, we
- believe these queries result from overly aggressive glue fetching.
-
-2.4.1 Recommendation
-
- Implementers whose name servers support glue fetching SHOULD take
- care to avoid sending queries at excessive rates. Implementations
- SHOULD support throttling logic to detect when queries are sent but
- no responses are received.
-
-2.5 Aggressive retransmission behind firewalls
-
- A common occurrence and one of the largest sources of repeated
- queries at the com/net and root name servers appears to result from
- resolvers behind misconfigured firewalls. In this situation, an
- iterative resolver is apparently allowed to send queries through a
- firewall to other name servers, but not receive the responses. The
- result is more queries than necessary because of retransmission, all
- of which are useless because the responses are never received. Just
- as with the glue-fetching scenario described in Section 2.4, the
- queries are sometimes sent at excessive rates. To make matters
- worse, sometimes the responses, sent in reply to legitimate queries,
- trigger an alarm on the originator's intrusion detection system. We
- are frequently contacted by administrators responding to such alarms
- who believe our name servers are attacking their systems.
-
- Not only do some resolvers in this situation retransmit queries at an
- excessive rate, but they continue to do so for days or even weeks.
- This scenario could result from an organization with multiple
- recursive name servers, only a subset of whose iterative resolvers'
- traffic is improperly filtered in this manner. Stub resolvers in the
- organization could be configured to query multiple recursive name
- servers. Consider the case where a stub resolver queries a filtered
- recursive name server first. The iterative resolver of this
- recursive name server sends one or more queries whose replies are
- filtered, so it can't respond to the stub resolver, which times out.
- Then the stub resolver retransmits to a recursive name server that is
- able to provide an answer. Since resolution ultimately succeeds the
- underlying problem might not be recognized or corrected. A popular
- stub resolver implementation has a very aggressive retransmission
- schedule, including simultaneous queries to multiple recursive name
- servers, which could explain how such a situation could persist
- without being detected.
-
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 9]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
-2.5.1 Recommendation
-
- The most obvious recommendation is that administrators SHOULD take
- care not to place iterative resolvers behind a firewall that allows
- queries to pass through but not the resulting replies.
-
- Iterative resolvers SHOULD take care to avoid sending queries at
- excessive rates. Implementations SHOULD support throttling logic to
- detect when queries are sent but no responses are received.
-
-2.6 Misconfigured NS records
-
- Sometimes a zone administrator forgets to add the trailing dot on the
- domain names in the RDATA of a zone's NS records. Consider this
- fragment of the zone file for "example.com":
-
- $ORIGIN example.com.
- example.com. 3600 IN NS ns1.example.com ; Note missing
- example.com. 3600 IN NS ns2.example.com ; trailing dots
-
- The zone's authoritative servers will parse the NS RDATA as
- "ns1.example.com.example.com" and "ns2.example.com.example.com" and
- return NS records with this incorrect RDATA in responses, including
- typically the authority section of every response containing records
- from the "example.com" zone.
-
- Now consider a typical sequence of queries. An iterative resolver
- attempting to resolve address records for "www.example.com" with no
- cached information for this zone will query a "com" authoritative
- server. The "com" server responds with a referral to the
- "example.com" zone, consisting of NS records with valid RDATA and
- associated glue records. (This example assumes that the
- "example.com" zone delegation information is correct in the "com"
- zone.) The iterative resolver caches the NS RRset from the "com"
- server and follows the referral by querying one of the "example.com"
- authoritative servers. This server responds with the
- "www.example.com" address record in the answer section and,
- typically, the "example.com" NS records in the authority section and,
- if space in the message remains, glue address records in the
- additional section. According to Section 5.4 of RFC 2181 [4], NS
- records in the authority section of an authoritative answer are more
- trustworthy than NS records from the authority section of a
- non-authoritative answer. Thus the "example.com" NS RRset just
- received from the "example.com" authoritative server overrides the
- "example.com" NS RRset received moments ago from the "com"
- authoritative server.
-
- But the "example.com" zone contains the erroneous NS RRset as shown
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 10]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- in the example above. Subsequent queries for names in "example.com"
- will cause the iterative resolver to attempt to use the incorrect NS
- records and so it will try to resolve the nonexistent names
- "ns1.example.com.example.com" and "ns2.example.com.example.com". In
- this example, since all of the zone's name servers are named in the
- zone itself (i.e., "ns1.example.com.example.com" and
- "ns2.example.com.example.com" both end in "example.com") and all are
- bogus, the iterative resolver cannot reach any "example.com" name
- servers. Therefore attempts to resolve these names result in address
- record queries to the "com" authoritative servers. Queries for such
- obviously bogus glue address records occur frequently at the com/net
- name servers.
-
-2.6.1 Recommendation
-
- An authoritative server can detect this situation. A trailing dot
- missing from an NS record's RDATA always results by definition in a
- name server name that exists somewhere under the SOA of the zone the
- NS record appears in. Note that further levels of delegation are
- possible, so a missing trailing dot could inadvertently create a name
- server name that actually exists in a subzone. But in any case, the
- address record must still be present in this zone, either as
- authoritative data or glue.
-
- An authoritative name server SHOULD report an error when one of a
- zone's NS records references a name server below the zone's SOA when
- a corresponding address record does not exist in the zone.
-
-2.7 Name server records with zero TTL
-
- Sometimes a popular com/net subdomain's zone is configured with a TTL
- of zero on the zone's NS records, which prohibits these records from
- being cached and will result in a higher query volume to the zone's
- authoritative servers. The zone's administrator should understand
- the consequences of such a configuration and provision resources
- accordingly. A zero TTL on the zone's NS RRset, however, carries
- additional consequences beyond the zone itself: if an iterative
- resolver cannot cache a zone's NS records because of a zero TTL, it
- will be forced to query that zone's parent's name servers each time
- it resolves a name in the zone. The com/net authoritative servers do
- see an increased query load when a popular com/net subdomain's zone
- is configured with a TTL of zero on the zone's NS records.
-
- A zero TTL on an RRset expected to change frequently is extreme but
- permissible. A zone's NS RRset is a special case, however, because
- changes to it must be coordinated with the zone's parent. In most
- zone parent/child relationships we are aware of, there is typically
- some delay involved in effecting changes. Further, changes to the
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 11]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- set of a zone's authoritative name servers (and therefore to the
- zone's NS RRset) are typically relatively rare: providing reliable
- authoritative service requires a reasonably stable set of servers.
- Therefore an extremely low or zero TTL on a zone's NS RRset rarely
- makes sense, except in anticipation of an upcoming change. In this
- case, when the zone's administrator has planned a change and does not
- want iterative resolvers throughout the Internet to cache the NS
- RRset for a long period of time, a low TTL is reasonable.
-
-2.7.1 Recommendation
-
- Because of the additional load placed on a zone's parent's
- authoritative servers resulting from a zero TTL on a zone's NS RRset,
- under such circumstances authoritative name servers SHOULD issue a
- warning when loading a zone or refuse to load the zone altogether.
-
-2.8 Unnecessary dynamic update messages
-
- The UPDATE message specified in RFC 2136 [6] allows an authorized
- agent to update a zone's data on an authoritative name server using a
- DNS message sent over the network. Consider the case of an agent
- desiring to add a particular resource record. Because of zone cuts,
- the agent does not necessarily know the proper zone to which the
- record should be added. The dynamic update process requires that the
- agent determine the appropriate zone so the UPDATE message can be
- sent to one of the zone's authoritative servers (typically the
- primary master as specified in the zone's SOA MNAME field).
-
- The appropriate zone to update is the closest enclosing zone, which
- cannot be determined only by inspecting the domain name of the record
- to be updated, since zone cuts can occur anywhere. One way to
- determine the closest enclosing zone entails walking up the name
- space tree by sending repeated UPDATE messages until success. For
- example, consider an agent attempting to add an address record with
- the name "foo.bar.example.com". The agent could first attempt to
- update the "foo.bar.example.com" zone. If the attempt failed, the
- update could be directed to the "bar.example.com" zone, then the
- "example.com" zone, then the "com" zone, and finally the root zone.
-
- A popular dynamic agent follows this algorithm. The result is many
- UPDATE messages received by the root name servers, the com/net
- authoritative servers, and presumably other TLD authoritative
- servers. A valid question is why the algorithm proceeds to send
- updates all the way to TLD and root name servers. This behavior is
- not entirely unreasonable: in enterprise DNS architectures with an
- "internal root" design, there could conceivably be private,
- non-public TLD or root zones that would be the appropriate targets
- for a dynamic update.
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 12]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- A significant deficiency with this algorithm is that knowledge of a
- given UPDATE message's failure is not helpful in directing future
- UPDATE messages to the appropriate servers. A better algorithm would
- be to find the closest enclosing zone by walking up the name space
- with queries for SOA or NS rather than "probing" with UPDATE
- messages. Once the appropriate zone is found, an UPDATE message can
- be sent. In addition, the results of these queries can be cached to
- aid in determining closest enclosing zones for future updates. Once
- the closest enclosing zone is determined with this method, the update
- will either succeed or fail and there is no need to send further
- updates to higher-level zones. The important point is that walking
- up the tree with queries yields cacheable information, whereas
- walking up the tree by sending UPDATE messages does not.
-
-2.8.1 Recommendation
-
- Dynamic update agents SHOULD send SOA or NS queries to progressively
- higher-level zones to find the closest enclosing zone for a given
- name to update. Only after the appropriate zone is found should the
- client send an UPDATE message to one of the zone's authoritative
- servers. Update clients SHOULD NOT "probe" using UPDATE messages by
- walking up the tree to progressively higher-level zones.
-
-2.9 Queries for domain names resembling IP addresses
-
- The root name servers receive a significant number of A record
- queries where the qname is an IP address. The source of these
- queries is unknown. It could be attributed to situations where a
- user believes an application will accept either a domain name or an
- IP address in a given configuration option. The user enters an IP
- address, but the application assumes any input is a domain name and
- attempts to resolve it, resulting in an A record lookup. There could
- also be applications that produce such queries in a misguided attempt
- to reverse map IP addresses.
-
- These queries result in Name Error (RCODE=3) responses. An iterative
- resolver can negatively cache such responses, but each response
- requires a separate cache entry, i.e., a negative cache entry for the
- domain name "192.0.2.1" does not prevent a subsequent query for the
- domain name "192.0.2.2".
-
-2.9.1 Recommendation
-
- It would be desirable for the root name servers not to have to answer
- these queries: they unnecessarily consume CPU resources and network
- bandwidth. One possibility is for iterative resolver implementations
- to produce the Name Error response directly. We suggest that
- implementors consider the option of synthesizing Name Error responses
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 13]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- at the iterative resolver. The server could claim authority for
- synthesized TLD zones corresponding to the first octet of every
- possible IP address, e.g. 1., 2., through 255. This behavior could
- be configurable in the (probably unlikely) event that numeric TLDs
- are ever put into use.
-
- Another option is to delegate these numeric TLDs from the root zone
- to a separate set of servers to absorb the traffic. The "black hole
- servers" used by the the AS 112
-Project [8], which are currently
- delegated the in-addr.arpa zones corresponding to RFC 1918 [7]
- private use address space, would be a possible choice to receive
- these delegations.
-
-2.10 Misdirected recursive queries
-
- The root name servers receive a significant number of recursive
- queries (i.e., queries with the RD bit set in the header). Since
- none of the root servers offers recursion, the servers' response in
- such a situation ignores the request for recursion and the response
- probably does not contain the data the querier anticipated. Some of
- these queries result from users configuring stub resolvers to query a
- root server. (This situation is not hypothetical: we have received
- complaints from users when this configuration does not work as
- hoped.) Of course, users should not direct stub resolvers to use name
- servers that do not offer recursion, but we are not aware of any stub
- resolver implementation that offers any feedback to the user when so
- configured, aside from simply "not working".
-
-2.10.1 Recommendation
-
- When the IP address of a name server that supposedly offers recursion
- is configured in a stub resolver using an interactive user interface,
- the resolver could send a test query to verify that the server indeed
- supports recursion (i.e., verify that the response has the RA bit set
- in the header). The user could be immediately notified if the server
- is non-recursive.
-
- The stub resolver could also report an error, either through a user
- interface or in a log file, if the queried server does not support
- recursion. Error reporting SHOULD be throttled to avoid a
- notification or log message for every response from a non-recursive
- server.
-
-2.11 Suboptimal name server selection algorithm
-
- An entire document could be devoted to the topic of problems with
- different implementations of the recursive resolution algorithm. The
- entire process of recursion is woefully under specified, requiring
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 14]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- each implementor to design an algorithm. Sometimes implementors make
- poor design choices that could be avoided if a suggested algorithm
- and best practices were documented, but that is a topic for another
- document.
-
- Some deficiencies cause significant operational impact and are
- therefore worth mentioning here. One of these is name server
- selection by an iterative resolver. When an iterative resolver wants
- to contact one of a zone's authoritative name servers, how does it
- choose from the NS records listed in the zone's NS RRset? If the
- selection mechanism is suboptimal, queries are not spread evenly
- among a zone's authoritative servers. The details of the selection
- mechanism are up to the implementor, but we offer some suggestions.
-
-2.11.1 Recommendation
-
- This list is not conclusive, but reflects the changes that would
- produce the most impact in terms of reducing disproportionate query
- load among a zone's authoritative servers. I.e., these changes would
- help spread the query load evenly.
- o Do not make assumptions based on NS RRset order: all NS RRs SHOULD
- be treated equally. (In the case of the "com" zone, for example,
- most of the root servers return the NS record for
- "a.gtld-servers.net" first in the authority section of referrals.
- Apparently as a result, this server receives disproportionately
- more traffic than the other 12 authoritative servers for "com".)
- o Use all NS records in an RRset. (For example, we are aware of
- implementations that hard-coded information for a subset of the
- root servers.)
- o Maintain state and favor the best-performing of a zone's
- authoritative servers. A good definition of performance is
- response time. Non-responsive servers can be penalized with an
- extremely high response time.
- o Do not lock onto the best-performing of a zone's name servers. An
- iterative resolver SHOULD periodically check the performance of
- all of a zone's name servers to adjust its determination of the
- best-performing one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 15]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
-3. IANA considerations
-
- There are no new IANA considerations introduced by this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 16]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
-4. Security considerations
-
- Name server and resolver misbehaviors identical or similar to those
- discussed in this document expose the root and TLD name servers to
- increased risk of both intentional and unintentional denial of
- service.
-
- We believe that implementation of the recommendations offered in this
- document will reduce the amount of unnecessary traffic seen at root
- and TLD name servers, thus reducing the opportunity for an attacker
- to use such queries to his or her advantage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 17]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
-5. Internationalization considerations
-
- We do not believe this document introduces any new
- internationalization considerations to the DNS protocol
- specification.
-
-6 Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [3] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
- 2308, March 1998.
-
- [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
- 1997.
-
- [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E.
- Lear, "Address Allocation for Private Internets", BCP 5, RFC
- 1918, February 1996.
-
- [8] <http://www.as112.net>
-
-
-Authors' Addresses
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
-
-
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 18]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
- Piet Barber
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: pbarber@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 19]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior October 2004
-
-
-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 (2004). 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.
-
-
-
-
-Larson & Barber Expires April 27, 2005 [Page 20]
-\f
-
+++ /dev/null
-
-draft-ietf-dnsop-inaddr-required-06.txt
-
-INTERNET-DRAFT D. Senie
-Category: BCP Amaranth Networks Inc.
-Expires in six months February 2005
-
- Encouraging the use of DNS IN-ADDR Mapping
-
-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 RFC 3668.
-
- 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>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>http://www.ietf.org/shadow.html
-
-Abstract
-
- Mapping of addresses to names has been a feature of DNS. Many sites,
- implement it, many others don't. Some applications attempt to use it
- as a part of a security strategy. The goal of this document is to
- encourage proper deployment of address to name mappings, and provide
- guidance for their use.
-
-Copyright Notice
-
- Copyright (C) The Internet Society. (2005)
-
-1. Introduction
-
- The Domain Name Service has provision for providing mapping of IP
- addresses to host names. It is common practice to ensure both name to
- address, and address to name mappings are provided for networks. This
- practice, while documented, has never been required, though it is
- generally encouraged. This document both encourages the presence of
-
-
-
-Senie [Page 1]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- these mappings and discourages reliance on such mappings for security
- checks.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-2. Discussion
-
-
- From the early days of the Domain Name Service [RFC883] a special
- domain has been set aside for resolving mappings of IP addresses to
- domain names. This was refined in [RFC1035], describing the .IN-
- ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA
- was added [RFC3152]. This document uses IPv4 CIDR block sizes and
- allocation strategy where there are differences and uses IPv4
- terminology. Aside from these differences, this document can and
- should be applied to both address spaces.
-
- The assignment of blocks of IP address space was delegated to three
- regional registries. Guidelines for the registries are specified in
- [RFC2050], which requires regional registries to maintain IN-ADDR
- records on the large blocks of space issued to ISPs and others.
-
- ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
- allocations. For smaller allocations, ARIN can provide IN-ADDR for
- /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to
- update IN-ADDR, however the present version of its policy document
- for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
- copies of this document. As of this writing, it appears APNIC has no
- actual policy on IN-ADDR. RIPE appears to have the strongest policy
- in this area [RIPE302] indicating Local Internet Registries should
- provide IN-ADDR services, and delegate those as appropriate when
- address blocks are delegated.
-
- As we can see, the regional registries have their own policies for
- recommendations and/or requirements for IN-ADDR maintenance. It
- should be noted, however, that many address blocks were allocated
- before the creation of the regional registries, and thus it is
- unclear whether any of the policies of the registries are binding on
- those who hold blocks from that era.
-
- Registries allocate address blocks on CIDR [RFC1519] boundaries.
- Unfortunately the IN-ADDR zones are based on classful allocations.
- Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
- exist, but are not always implemented.
-
-3. Examples of impact of missing IN-ADDR
-
-
-
-Senie [Page 2]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- These are some examples of problems that may be introduced by
- reliance on IN-ADDR.
-
- Some applications use DNS lookups for security checks. To ensure
- validity of claimed names, some applications will look up IN-ADDR
- records to get names, and then look up the resultant name to see if
- it maps back to the address originally known. Failure to resolve
- matching names is seen as a potential security concern.
-
- Some FTP sites will flat-out reject users, even for anonymous FTP, if
- the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
- itself resolved, does not match. Some Telnet servers also implement
- this check.
-
- Web sites are in some cases using IN-ADDR checks to verify whether
- the client is located within a certain geopolitical entity. This
- approach has been employed for downloads of crypto software, for
- example, where export of that software is prohibited to some locales.
- Credit card anti-fraud systems also use these methods for geographic
- placement purposes.
-
- The popular TCP Wrappers program found on most Unix and Linux systems
- has options to enforce IN-ADDR checks and to reject any client that
- does not resolve. This program also has a way to check to see that
- the name given by a PTR record then resolves back to the same IP
- address. This method provdes more comfort but no appreciable
- additional security.
-
- Some anti-spam (anti junk email) systems use IN-ADDR to verify the
- presence of a PTR record, or validate the PTR value points back to
- the same address.
-
- Many web servers look up the IN-ADDR of visitors to be used in log
- analysis. This adds to the server load, but in the case of IN-ADDR
- unavailability, it can lead to delayed responses for users.
-
- Traceroutes with descriptive IN-ADDR naming proves useful when
- debugging problems spanning large areas. When this information is
- missing, the traceroutes take longer, and it takes additional steps
- to determine that network is the cause of problems.
-
- Wider-scale implementation of IN-ADDR on dialup, wireless access and
- other such client-oriented portions of the Internet would result in
- lower latency for queries (due to lack of negative caching), and
- lower name server load and DNS traffic.
-
-4. Recommendations
-
-
-
-
-Senie [Page 3]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- 4.1 Delegation Recommendations
-
-
- Regional Registries and any Local Registries to whom they delegate
- should establish and convey a policy to those to whom they delegate
- blocks that IN-ADDR mappings are recommended. Policies should
- recommend those receiving delegations to provide IN-ADDR service
- and/or delegate to downstream customers.
-
- Network operators should define and implement policies and procedures
- which delegate IN-ADDR to their clients who wish to run their own IN-
- ADDR DNS services, and provide IN-ADDR services for those who do not
- have the resources to do it themselves. Delegation mechanisms should
- permit the downstream customer to implement and comply with IETF
- recommendations application of IN-ADDR to CIDR [RFC2317].
-
- All IP address space assigned and in use should be resolved by IN-
- ADDR records. All PTR records must use canonical names.
-
- All IP addresses in use within a block should have an IN-ADDR
- mapping. Those addresses not in use, and those that are not valid for
- use (zeros or ones broadcast addresses within a CIDR block) need not
- have mappings.
-
- It should be noted that due to CIDR, many addresses that appear to be
- otherwise valid host addresses may actually be zeroes or ones
- broadcast addresses. As such, attempting to audit a site's degree of
- compliance may only be done with knowledge of the internal subnet
- architecture of the site. It can be assumed, however, any host that
- originates an IP packet necessarily will have a valid host address,
- and must therefore have an IN-ADDR mapping.
-
-4.2 Application Recommendations
-
-
- Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
- of IN-ADDR, sometimes in conjunction with a lookup of the name
- resulting from the PTR record provides no real security, can lead to
- erroneous results and generally just increases load on DNS servers.
- Further, in cases where address block holders fail to properly
- configure IN-ADDR, users of those blocks are penalized.
-
-5. Security Considerations
-
- This document has no negative impact on security. While it could be
- argued that lack of PTR record capabilities provides a degree of
- anonymity, this is really not valid. Trace routes, whois lookups and
- other sources will still provide methods for discovering identity.
-
-
-
-Senie [Page 4]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- By recommending applications avoid using IN-ADDR as a security
- mechanism this document points out that this practice, despite its
- use by many applications, is an ineffective form of security.
- Applications should use better mechanisms of authentication.
-
-6. IANA Considerations
-
- There are no IANA considerations for this document.
-
-7. References
-
-7.1 Normative References
-
- [RFC883] P.V. Mockapetris, "Domain names: Implementation
- specification," RFC883, November 1983.
-
- [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
- Specification," RFC 1035, November 1987.
-
- [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
- an Address Assignment and Aggregation Strategy," RFC 1519, September
- 1993.
-
- [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
- RFC 2026, BCP 9, October 1996.
-
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, BCP 14, March 1997.
-
- [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
- Guidelines", RFC2050, BCP 12, Novebmer 1996.
-
- [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
- RFC 2317, March 1998.
-
- [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
- 2001.
-
-7.2 Informative References
-
- [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
- unknown,
-<http://www.arin.net/regserv/initial-isp.html>http://www.arin.net/regserv/initial-isp.html
-
- [APNIC] "Policies For IPv4 Address Space Management in the Asia
- Pacific Region," APNIC-086, 13 January 2003.
-
- [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
- Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
-
-
-
-Senie [Page 5]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- 2004.
-<http://www.ripe.net//ripe/docs/rev-del.html>http://www.ripe.net//ripe/docs/rev-del.html
-
-
-
-8. Acknowledgements
-
- Thanks to Peter Koch and Gary Miller for their input, and to many
- people who encouraged me to write this document.
-
-9. Author's Address
-
- Daniel Senie
- Amaranth Networks Inc.
- 324 Still River Road
- Bolton, MA 01740
-
- Phone: (978) 779-5100
-
- EMail: <mailto:dts@senie.com>dts@senie.com
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). 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.
-
- 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.
-
-Intellectual Property
-
- 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
-
-
-
-Senie [Page 6]
-
-
-
-
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
-
-
- 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>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 <mailto:ietf-ipr@ietf.org>ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Senie [Page 7]
-
-
-
-
-
-
-
+++ /dev/null
-DNS Operations WG
-Internet-Draft J. Jeong (ed.)
- ETRI/University of Minnesota
-
-Expires: August 2005 19 February 2005
-
-
- IPv6 Host Configuration of DNS Server Information Approaches
- draft-ietf-dnsop-ipv6-dns-configuration-05.txt
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html"
-
- This Internet-Draft will expire on August 19, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-Abstract
-
- This document describes three approaches for IPv6 recursive DNS
- server address configuration. It details the operational
- attributes of three solutions: RA option, DHCPv6 option, and
- Well-known anycast addresses for recursive DNS servers.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 1]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- Additionally, it suggests four deployment scenarios considering
- multi-solution resolution. Therefore, this document will give the
- audience a guideline for IPv6 DNS configuration to select the
- approaches suitable for their host DNS configuration.
-
-Table of Contents
-
- 1. Introduction...................................................3
- 2. Terminology....................................................3
- 3. IPv6 DNS Configuration Approaches..............................3
- 3.1. RA Option..................................................3
- 3.1.1. Advantages...........................................4
- 3.1.2. Disadvantages........................................5
- 3.1.3. Observations.........................................6
- 3.2. DHCPv6 Option..............................................6
- 3.2.1. Advantages...........................................8
- 3.2.2. Disadvantages........................................8
- 3.2.3. Observations.........................................9
- 3.3. Well-known Anycast Addresses...............................9
- 3.3.1. Advantages..........................................10
- 3.3.2. Disadvantages.......................................10
- 3.3.3. Observations........................................11
- 4. Interworking among IPv6 DNS Configuration Approaches..........11
- 5. Deployment Scenarios..........................................12
- 5.1. ISP Network...............................................13
- 5.1.1. RA Option Approach..................................13
- 5.1.2. DHCPv6 Option Approach..............................13
- 5.1.3. Well-known Addresses Approach.......................14
- 5.2. Enterprise Network........................................14
- 5.3. 3GPP Network..............................................15
- 5.3.1. Currently Available Mechanisms and Recommendations..15
- 5.3.2. RA Extension........................................16
- 5.3.3. Stateless DHCPv6....................................17
- 5.3.4. Well-known Addresses................................18
- 5.3.5. Recommendations.....................................18
- 5.4. Unmanaged Network.........................................18
- 5.4.1. Case A: Gateway does not provide IPv6 at all........18
- 5.4.2. Case B: A dual-stack gateway connected to a dual-stack
- ISP.................................................19
- 5.4.3. Case C: A dual-stack gateway connected to an IPv4-only
- ISP.................................................19
- 5.4.4. Case D: A gateway connected to an IPv6-only ISP.....19
- 6. Security Considerations.......................................19
- 7. Acknowledgements..............................................20
- 8. Normative References..........................................20
- 9. Informative References........................................21
- 10. Appendix A - Link-layer Multicast Acknowledgements with RA
- Option.......................................................23
-
-
-Jeong, et al. Expires - August 2005 [Page 2]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- 11. Authors' Addresses...........................................23
- 12. Intellectual Property Statement..............................25
- 13. Full Copyright Statement.....................................25
- Acknowledgement..................................................26
-
-1. Introduction
-
- Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
- Autoconfiguration provide the ways to configure either fixed or
- mobile nodes with one or more IPv6 addresses, default routes and
- some other parameters [3][4]. To support the access to additional
- services in the Internet that are identified by a DNS name, such as
- a web server, the configuration of at least one recursive DNS
- server is also needed for DNS name resolution.
-
- This document describes three approaches of recursive DNS server
- address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
- option [5]-[7], and (c) Well-known anycast addresses for recursive
- DNS servers [9]. Also, it suggests the applicable scenarios for
- four kinds of networks: (a) ISP network, (b) Enterprise network,
- (c) 3GPP network, and (d) Unmanaged network.
-
- This document is just an analysis of each possible approach, and
- does not make any recommendation on particular one or on a
- combination of particular ones. Some approaches may even not be
- adopted at all as a result of further discussion.
-
- Therefore, the objective of this document is to help the audience
- select the approaches suitable for IPv6 host configuration of
- recursive DNS server.
-
-2. Terminology
-
- This document uses the terminology described in [3]-[9]. In
- addition, a new term is defined below:
-
- Recursive DNS Server (RDNSS) A Recursive DNS Server is a name
- server that offers the recursive
- service of DNS name resolution.
-
-3. IPv6 DNS Configuration Approaches
-
- In this section, the operational attributes of three solutions are
- described in detail.
-
-3.1. RA Option
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 3]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- RA approach is to define a new ND option called RDNSS option that
- contains a recursive DNS server address. Existing ND transport
- mechanisms (i.e., advertisements and solicitations) are used. This
- works in the same way that nodes learn about routers and prefixes.
- An IPv6 host can configure the IPv6 addresses of one or more
- RDNSSes via RA message periodically sent by router or solicited by
- a Router Solicitation (RS) [8].
-
- This approach needs RDNSS information to be configured in the
- routers doing the advertisements. The configuration of RDNSS
- address can be performed manually by operator or other ways, such
- as automatic configuration through DHCPv6 client running on the
- router. When advertising more than one RDNSS option, an RA message
- includes as many RDNSS options as RDNSSes.
-
- Through ND protocol and RDNSS option along with prefix information
- option, an IPv6 host can perform its network configuration of its
- IPv6 address and RDNSS simultaneously [3][4]. The RA option for
- RDNSS can be used on any network that supports the use of ND.
-
- However, it is worth noting that some link layers (e.g., WLAN) need
- to acknowledge multicast packets, which may increase the amount of
- link-layer traffic [25]-[28]. This is discussed in Appendix A.
-
- The RA approach is useful in some mobile environments where the
- addresses of the RDNSSes are changing because the RA option
- includes a lifetime field that allows client to use RDNSSes nearer
- to the client. This can be configured to a value that will require
- the client to time out the entry and switch over to another RDNSS
- address [8]. However, from the viewpoint of implementation, the
- lifetime would seem to make matters a bit more complex. Instead of
- just writing DNS configuration file, such as resolv.conf for the
- list of RDNSS addresses, we have to have a daemon around (or a
- program that is called at the defined intervals) that keeps
- monitoring the lifetime of RDNSSes all the time.
-
- The preference value of RDNSS, included in RDNSS option, allows
- IPv6 hosts to select primary RDNSS among several RDNSSes; this can
- be used for load balancing of RDNSSes [8].
-
-3.1.1. Advantages
-
- The RA option for RDNSS has a number of advantages. These include:
-
- 1) The RA option is an extension of existing ND/Autoconfig
- mechanisms [3][4], and does not require a change in the base ND
- protocol.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 4]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- 2) This approach, like ND, works well on a variety of link types
- including point-to-point links, point-to-multipoint, and
- multi-point (i.e., Ethernet LANs), etc. RFC2461 [3] states,
- however, that there may be some link types on which ND is not
- possible; on such links, some other mechanisms will be needed for
- DNS configuration.
-
- 3) All of the information a host needs to run the basic Internet
- applications such as the email, web, ftp, etc., can be obtained
- with the addition of this option to ND and address autoconfiguration
- The use of a single mechanism is more reliable and easier to provide
- than when the RDNSS information is learned via another protocol
- mechanism. Debugging problems when multiple protocol mechanisms are
- being used is harder and much more complex.
-
- 4) This mechanism works over a broad range of scenarios and
- leverages IPv6 ND. This works well on links that support broadcast
- reliably (e.g., Ethernet LANs) but not necessarily on other links
- (e.g., Wireless LANs): Refer to Appendix A. Also, this works well
- on links that are high performance (e.g., Ethernet LANs) and low
- performance (e.g., Cellular networks). In the latter case,
- combining the RDNSS information with the other information in the
- RA, the host can learn all of the information needed to use most
- Internet applications, such as the web in a single packet. This
- not only saves bandwidth where this is an issue, but also minimizes
- the delay needed to learn the RDNSS information.
-
- 5) The RA approach could be used as a model for other similar types
- of configuration information. New RA options for other server
- addresses, such as NTP server address, that are common to all
- clients on a subnet would be easy to define.
-
-3.1.2. Disadvantages
-
- 1) ND is mostly implemented in the kernel part of operating system.
- Therefore, if ND supports the configuration of some additional
- services, such as DNS servers, ND should be extended in the kernel
- part, and complemented by a user-land process. DHCPv6, however,
- has more flexibility for the extension of service discovery because
- it is an application layer protocol.
-
- 2) The current ND framework should be modified due to the
- synchronization between another ND cache for RDNSSes in the kernel
- space and the DNS configuration file in the user space. Because it
- is unacceptable to write and rewrite the DNS configuration file
- (e.g., resolv.conf) from the kernel, another approach is needed.
- One simple approach to solve this is to have a daemon listening to
-
-
-
-Jeong, et al. Expires - August 2005 [Page 5]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- what the kernel conveys, and to have the daemon do these steps, but
- such a daemon is not needed with the current ND framework.
-
- 3) It is necessary to configure RDNSS addresses at least at one
- router on every link where this information needs to be configured
- by RA option.
-
-3.1.3. Observations
-
- The proposed RDNSS RA option along with the IPv6 ND and
- Autoconfiguration allows a host to obtain all of the information it
- needs to access the basic Internet services like the web, email,
- ftp, etc. This is preferable in the environments where hosts use
- RAs to autoconfigure their addresses and all the hosts on the
- subnet share the same router and server addresses. If the
- configuration information can be obtained from a single mechanism,
- it is preferable because it does not add additional delay, and it
- uses a minimum of bandwidth. The environments like this include
- the homes, public cellular networks, and enterprise environments
- where no per host configuration is needed, but exclude public WLAN
- hot spots.
-
- DHCPv6 is preferable where it is being used for address
- configuration and if there is a need for host specific
- configuration [5]-[7]. The environments like this are most likely
- the enterprise environments where the local administration chooses
- to have per host configuration control.
-
- Note: the observation section is based on what the proponents of
- each approach think makes a good overall solution.
-
-3.2. DHCPv6 Option
-
- DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
- which a host can obtain a list of IP addresses of recursive DNS
- servers [7]. The DNS Recursive Name Server option carries a list
- of IPv6 addresses of RDNSSes to which the host may send DNS queries.
- The DNS servers are listed in the order of preference for use by
- the DNS resolver on the host.
-
- The DNS Recursive Name Server option can be carried in any DHCPv6
- Reply message, in response to either a Request or an Information
- request message. Thus, the DNS Recursive Name Server option can be
- used either when DHCPv6 is used for address assignment, or when
- DHCPv6 is used only for other configuration information as
- stateless DHCPv6 [6].
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 6]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- Stateless DHCPv6 can be deployed either using DHCPv6 servers
- running on general-purpose computers, or on router hardware.
- Several router vendors currently implement stateless DHCPv6 servers.
- Deploying stateless DHCPv6 in routers has the advantage that no
- special hardware is required, and should work well for networks
- where DHCPv6 is needed for very straightforward configuration of
- network devices.
-
- However, routers can also act as DHCPv6 relay agents. In this case,
- the DHCPv6 server need not be on the router - it can be on a
- general purpose computer. This has the potential to give the
- operator of the DHCPv6 server more flexibility in how the DHCPv6
- server responds to individual clients - clients can easily be given
- different configuration information based on their identity, or for
- any other reason. Nothing precludes adding this flexibility to a
- router, but generally in current practice, DHCP servers running on
- general-purpose hosts tend to have more configuration options than
- those that are embedded in routers.
-
- DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
- clients that use stateful configuration assignment. To do this,
- the DHCPv6 server sends a Reconfigure message to the client. The
- client validates the Reconfigure message, and then contacts the
- DHCPv6 server to obtain updated configuration information. Using
- this mechanism, it is currently possible to propagate new
- configuration information to DHCPv6 clients as this information
- changes.
-
- The DHC Working Group is currently studying an additional mechanism
- through which configuration information, including the list of
- RDNSSes, can be updated. The lifetime option for DHCPv6 [10]
- assigns a lifetime to configuration information obtained through
- DHCPv6. At the expiration of the lifetime, the host contacts the
- DHCPv6 server to obtain updated configuration information,
- including the list of RDNSSes. This lifetime gives the network
- administrator another mechanism to configure hosts with new RDNSSes
- by controlling the time at which the host refreshes the list.
-
- The DHC Working Group has also discussed the possibility of
- defining an extension to DHCPv6 that would allow the use of
- multicast to provide configuration information to multiple hosts
- with a single DHCPv6 message. Because of the lack of deployment
- experience, the WG has deferred consideration of multicast DHCPv6
- configuration at this time. Experience with DHCPv4 has not
- identified a requirement for multicast message delivery, even in
- large service provider networks with tens of thousands of hosts
- that may initiate a DHCPv4 message exchange simultaneously.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 7]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-3.2.1. Advantages
-
- The DHCPv6 option for RDNSS has a number of advantages. These
- include:
-
- 1) DHCPv6 currently provides a general mechanism for conveying
- network configuration information to clients. So configuring
- DHCPv6 servers allows the network administrator to configure
- RDNSSes along with the addresses of other network services, as well
- as location-specific information like time zones.
-
- 2) As a consequence, when the network administrator goes to
- configure DHCPv6, all the configuration information can be managed
- through a single service, typically with a single user interface
- and a single configuration database.
-
- 3) DHCPv6 allows for the configuration of a host with information
- specific to that host, so that hosts on the same link can be
- configured with different RDNSSes as well as other configuration
- information. This capability is important in some network
- deployments such as service provider networks or WiFi hot spots.
-
- 4) A mechanism exists for extending DHCPv6 to support the
- transmission of additional configuration that has not yet been
- anticipated.
-
- 5) Hosts that require other configuration information such as the
- addresses of SIP servers and NTP servers are likely to need DHCPv6
- for other configuration information.
-
- 6) The specification for configuration of RDNSSes through DHCPv6 is
- available as an RFC. No new protocol extensions such as new
- options are necessary.
-
- 7) Interoperability among independent implementations has been
- demonstrated.
-
-3.2.2. Disadvantages
-
- The DHCPv6 option for RDNSS has a few disadvantages. These
- include:
-
- 1) Update currently requires message from server (however, see
- [10]).
-
- 2) Because DNS information is not contained in RA message, the host
- must receive two messages from the router, and must transmit at
- least one message to the router. On networks where bandwidth is at
-
-
-Jeong, et al. Expires - August 2005 [Page 8]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- a premium, this is a disadvantage, although on most networks it is
- not a practical concern.
-
- 3) Increased latency for initial configuration - in addition to
- waiting for an RA message, the client must now exchange packets
- with a DHCPv6 server; even if it is locally installed on a router,
- this will slightly extend the time required to configure the client.
- For clients that are moving rapidly from one network to another,
- this will be a disadvantage.
-
-3.2.3. Observations
-
- In the general case, on general-purpose networks, stateless DHCPv6
- provides significant advantages and no significant disadvantages.
- Even in the case where bandwidth is at a premium and low latency is
- desired, if hosts require other configuration information in
- addition to a list of RDNSSes or if hosts must be configured
- selectively, those hosts will use DHCPv6 and the use of the DHCPv6
- DNS recursive name server option will be advantageous.
-
- However, we are aware of some applications where it would be
- preferable to put the RDNSS information into an RA packet; for
- example, on a cell phone network, where bandwidth is at a premium
- and extremely low latency is desired. The final DNS configuration
- draft should be written so as to allow these special applications
- to be handled using DNS information in the RA packet.
-
-3.3. Well-known Anycast Addresses
-
- Anycast uses the same routing system as unicast [11]. However,
- administrative entities are local ones. The local entities may
- accept unicast routes (including default routes) to anycast servers
- from adjacent entities. The administrative entities should not
- advertise their peers routes to their internal anycast servers, if
- they want to prohibit external access from some peers to the
- servers. If some advertisement is inevitable (such as the case
- with default routes), the packets to the servers should be blocked
- at the boundary of the entities. Thus, for this anycast, not only
- unicast routing but also unicast ND protocols can be used as is.
-
- First of all, the well-known anycast addresses approach is much
- different from that discussed at IPv6 Working Group in the past [9].
- It should be noted that "anycast" in this memo is simpler than that
- of RFC1546 [11] and RFC3513 [12] where it is assumed to be
- prohibited to have multiple servers on a single link sharing an
- anycast address. That is, on a link, anycast address is assumed to
- be unique. DNS clients today already have redundancy by having
- multiple well-known anycast addresses configured as RDNSS addresses.
-
-
-Jeong, et al. Expires - August 2005 [Page 9]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- There is no point in having multiple RDNSSes sharing an anycast
- address on a single link.
-
- The approach with well-known anycast addresses is to set multiple
- well-known anycast addresses in clients' resolver configuration
- files from the beginning, say, as factory default. Thus, there is
- no transport mechanism and no packet format [9].
-
- An anycast address is an address shared by multiple servers (in
- this case, the servers are RDNSSes). Request from a client to the
- anycast address is routed to a server selected by the routing
- system. However, it is a bad idea to mandate "site" boundary on
- anycast addresses, because most users just do not have their own
- servers and want to access their ISPs' across their site boundaries.
- Larger sites may also depend on their ISPs or may have their own
- RDNSSes within "site" boundaries.
-
-3.3.1. Advantages
-
- The basic advantage of the well-known addresses approach is that it
- uses no transport mechanism. Thus,
-
- 1) There is no delay to get the response and no further delay by
- packet losses.
-
- 2) The approach can be combined with any other configuration
- mechanisms, such as RA-based approach and DHCP based approach, as
- well as factory default configuration.
-
- 3) The approach works over any environment where DNS works.
-
- Another advantage is that the approach needs to configure DNS
- servers as a router, but nothing else. Considering that DNS
- servers do need configuration, the amount of overall configuration
- effort is proportional to the number of the DNS servers and scales
- linearly. It should be noted that, in the simplest case where a
- subscriber to an ISP does not have any DNS server, the subscriber
- naturally accesses DNS servers of the ISP even though the
- subscriber and the ISP do nothing and there is no protocol to
- exchange DNS server information between the subscriber and the ISP.
-
-3.3.2. Disadvantages
-
- Well-known anycast addresses approach requires that DNS servers (or
- routers near it as a proxy) act as routers to advertise their
- anycast addresses to the routing system, which requires some
- configuration (see the last paragraph of the previous section on
- the scalability of the effort).
-
-
-Jeong, et al. Expires - August 2005 [Page 10]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-
-3.3.3. Observations
-
- If other approaches are used in addition, the well-known anycast
- addresses should also be set in RA or DHCP configuration files to
- reduce the configuration effort of users.
-
- The redundancy by multiple RDNSSes is better provided by multiple
- servers having different anycast addresses than multiple servers
- sharing the same anycast address because the former approach allows
- stale servers to still generate routes to their anycast addresses.
- Thus, in a routing domain (or domains sharing DNS servers), there
- will be only one server having an anycast address unless the domain
- is so large that load distribution is necessary.
-
- Small ISPs will operate one RDNSS at each anycast address which is
- shared by all the subscribers. Large ISPs may operate multiple
- RDNSSes at each anycast address to distribute and reduce load,
- where boundary between RDNSSes may be fixed (redundancy is still
- provided by multiple addresses) or change dynamically. DNS packets
- with the well-known anycast addresses are not expected (though not
- prohibited) to cross ISP boundaries, as ISPs are expected to be
- able to take care of themselves.
-
- Because "anycast" in this memo is simpler than that of RFC1546 [11]
- and RFC3513 [12] where it is assumed to be administratively
- prohibited to have multiple servers on a single link sharing an
- anycast address, anycast in this memo should be implemented as
- UNICAST of RFC2461 [3] and RFC3513 [12]. As a result, ND-related
- instability disappears. Thus, anycast in well-known anycast
- addresses approach can and should use the anycast address as a
- source unicast (according to RFC3513 [12]) address of packets of
- UDP and TCP responses. With TCP, if route flips and packets to an
- anycast address are routed to a new server, it is expected that the
- flip is detected by ICMP or sequence number inconsistency and the
- TCP connection is reset and retried.
-
-4. Interworking among IPv6 DNS Configuration Approaches
-
- Three approaches can work together for IPv6 host configuration of
- RDNSS. This section shows a consideration on how these approaches
- can interwork each other.
-
- For ordering between RA and DHCP approaches, O (Other stateful
- configuration) flag in RA message can be used [8]. If no RDNSS
- option is included, an IPv6 host may perform DNS configuration
- through DHCPv6 [5]-[7] regardless of whether the O flag is set or
- not.
-
-
-Jeong, et al. Expires - August 2005 [Page 11]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-
- The well-known anycast addresses approach fully interworks with the
- other approaches. That is, the other approaches can remove the
- configuration effort on servers by using the well-known addresses
- as the default configuration. Moreover, the clients preconfigured
- with the well-known anycast addresses can be further configured to
- use other approaches to override the well-known addresses, if the
- configuration information from other approaches are available.
- That is, all the clients should have the well-known anycast
- addresses preconfigured, in the case where there are no other
- mechanisms available. In order to fly anycast approach with the
- other solutions, there are three options as follows:
-
- 1) The first option is that well-known addresses are used as last
- resort, when an IPv6 host can not get RDNSS information through RA
- and DHCP. The well-known anycast addresses have to be preconfigured
- in IPv6 hosts' resolver configuration files.
-
- 2) The second is that an IPv6 host can configure well-known
- addresses as the most preferable in its configuration file even
- though either RA option or DHCP option is available.
-
- 3) The last is that the well-known anycast addresses can be set in
- RA or DHCP configuration to reduce configuration effort of users.
- According to either RA or DHCP mechanism, the well-known addresses
- can be obtained by IPv6 host. Because this approach is the most
- convenient for users, the last option is recommended.
-
- Note: this section does not necessarily mean this document suggests
- adopting all these three approaches and making them interwork in
- the way described here. In fact, some approaches may even not be
- adopted at all as a result of further discussion.
-
-5. Deployment Scenarios
-
- Regarding the DNS configuration on the IPv6 host, several
- mechanisms are being considered at the DNSOP Working Group such as
- RA option, DHCPv6 option and well-known preconfigured anycast
- addresses as of today, and this document is a final result from the
- long thread. In this section, we suggest four applicable scenarios
- of three approaches for IPv6 DNS configuration.
-
- Note: in the applicable scenarios, authors do not implicitly push
- any specific approaches into the restricted environments. No
- enforcement is in each scenario and all mentioned scenarios are
- probable. The main objective of this work is to provide a useful
- guideline for IPv6 DNS configuration.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 12]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-5.1. ISP Network
-
- A characteristic of ISP network is that multiple Customer Premises
- Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
- routers and each PE connects multiple CPE devices to the backbone
- network infrastructure [13]. The CPEs may be hosts or routers.
-
- In the case where the CPE is a router, there is a customer network
- that is connected to the ISP backbone through the CPE. Typically,
- each customer network gets a different IPv6 prefix from an IPv6 PE
- router, but the same RDNSS configuration will be distributed.
-
- This section discusses how the different approaches to distributing
- DNS information are compared in an ISP network.
-
-5.1.1. RA Option Approach
-
- When the CPE is a host, the RA option for RDNSS can be used to
- allow the CPE to get RDNSS information as well as /64 prefix
- information for stateless address autoconfiguration at the same
- time when the host is attached to a new subnet [8]. Because an
- IPv6 host must receive at least one RA message for stateless
- address autoconfiguration and router configuration, the host could
- receive RDNSS configuration information in that RA without the
- overhead of an additional message exchange.
-
- When the CPE is a router, the CPE may accept the RDNSS information
- from the RA on the interface connected to the ISP, and copy that
- information into the RAs advertised in the customer network.
-
- This approach is more valuable in the mobile host scenario, in
- which the host must receive at least an RA message for detecting a
- new network, than in other scenarios generally although
- administrator should configure RDNSS information on the routers.
- Secure ND [14] can provide extended security when using RA message.
-
-5.1.2. DHCPv6 Option Approach
-
- DHCPv6 can be used for RDNSS configuration through the use of the
- DNS option, and can provide other configuration information in the
- same message with RDNSS configuration [5]-[7]. DHCPv6 DNS option
- is already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite
- or stateless DHCP [6] is nowhere as complex as a full DHCPv6
- implementation. DHCP is a client-server model protocol, so ISP can
- handle user identification on its network intentionally, and also
- authenticated DHCP [15] can be used for secure message exchange.
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 13]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- The expected model for deployment of IPv6 service by ISPs is to
- assign a prefix to each customer, which will be used by the
- customer gateway to assign a /64 prefix to each network in the
- customer's network. Prefix delegation with DHCP (DHCPv6 PD) has
- already been adopted by ISPs for automating the assignment of the
- customer prefix to the customer gateway [17]. DNS configuration
- can be carried in the same DHCPv6 message exchange used for DHCPv6
- to efficiently provide that information, along with any other
- configuration information needed by the customer gateway or
- customer network. This service model can be useful to Home or SOHO
- subscribers. The Home or SOHO gateway, which is a customer gateway
- for ISP, can then pass that RDNSS configuration information to the
- hosts in the customer network through DHCP.
-
-5.1.3. Well-known Addresses Approach
-
- Well-known anycast addresses approach is also a feasible and simple
- mechanism for ISP [9]. The use of well-known anycast addresses
- avoids some of the security risks in rogue messages sent through an
- external protocol like RA or DHCPv6. The configuration of hosts
- for the use of well-known anycast addresses requires no protocol or
- manual configuration, but the configuration of routing for the
- anycast addresses requires intervention on the part of the network
- administrator. Also, the number of special addresses would be
- equal to the number of RDNSSes that could be made available to
- subscribers.
-
-5.2. Enterprise Network
-
- Enterprise network is defined as a network that has multiple
- internal links, one or more router connections, to one or more
- Providers and is actively managed by a network operations entity
- [16]. An enterprise network can get network prefixes from ISP by
- either manual configuration or prefix delegation [17]. In most
- cases, because an enterprise network manages its own DNS domains,
- it operates its own DNS servers for the domains. These DNS servers
- within enterprise network process recursive DNS name resolution
- requests from IPv6 hosts as RDNSSes. The RDNSS configuration in
- the enterprise network can be performed like in Section 4, in which
- three approaches can be used together as follows:
-
- 1) IPv6 host can decide which approach is or may be used in its
- subnet with O flag in RA message [8]. As the first option in
- Section 4, well-known anycast addresses can be used as a last
- resort when RDNSS information can not be obtained through either RA
- option or DHCP option. This case needs IPv6 hosts to preconfigure
- the well-known anycast addresses in their DNS configuration files.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 14]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- 2) When the enterprise prefers well-known anycast approach to the
- others, IPv6 hosts should preconfigure the well-known anycast
- addresses like in the first option.
-
- 3) The last option, a more convenient and transparent way, does not
- need IPv6 hosts to preconfigure the well-known anycast addresses
- because the addresses are delivered to IPv6 hosts through either RA
- option or DHCPv6 option as if they were unicast addresses. This
- way is most recommended for the sake of user's convenience.
-
-5.3. 3GPP Network
-
- IPv6 DNS configuration is a missing part of IPv6 autoconfiguration
- and an important part of the basic IPv6 functionality in the 3GPP
- User Equipment (UE). Higher level description of the 3GPP
- architecture can be found in [18], and transition to IPv6 in 3GPP
- networks is analyzed in [19] and [20].
-
- In 3GPP architecture, there is a dedicated link between the UE and
- the GGSN called the Packet Data Protocol (PDP) Context. This link
- is created through the PDP Context activation procedure [21].
- There is a separate PDP context type for IPv4 and IPv6 traffic. If
- a 3GPP UE user is communicating using IPv6 (having an active IPv6
- PDP context), it can not be assumed that (s)he has simultaneously
- active IPv4 PDP context, and DNS queries could be done using IPv4.
- A 3GPP UE can thus be an IPv6 node, and it needs to somehow
- discover the address of the RDNSS. Before IP-based services (e.g.,
- web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS
- addresses need to be discovered in the 3GPP UE.
-
- Section 5.3.1 briefly summarizes currently available mechanisms in
- 3GPP networks and recommendations. 5.3.2 analyzes the Router
- Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
- mechanism, and 5.3.4 analyzes the Well-known addresses approach.
- Section 5.3.5 finally summarizes the recommendations.
-
-5.3.1. Currently Available Mechanisms and Recommendations
-
- 3GPP has defined a mechanism, in which RDNSS addresses can be
- received in the PDP context activation (a control plane mechanism).
- That is called the Protocol Configuration Options Information
- Element (PCO-IE) mechanism [22]. The RDNSS addresses can also be
- received over the air (using text messages), or typed in manually
- in the UE. Note that the two last mechanisms are not very well
- scalable. The UE user most probably does not want to type IPv6
- RDNSS addresses manually in his/her UE. The use of well-known
- addresses is briefly discussed in section 5.3.4.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 15]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- It is seen that the mechanisms above most probably are not
- sufficient for the 3GPP environment. IPv6 is intended to operate
- in a zero-configuration manner, no matter what the underlying
- network infrastructure is. Typically, the RDNSS address is needed
- to make an IPv6 node operational - and the DNS configuration should
- be as simple as the address autoconfiguration mechanism. It must
- also be noted that there will be additional IP interfaces in some
- near future 3GPP UEs, e.g., WLAN, and 3GPP-specific DNS
- configuration mechanisms (such as PCO-IE [22]) do not work for
- those IP interfaces. In other words, a good IPv6 DNS configuration
- mechanism should also work in a multi-access network environment.
-
- From 3GPP point of view, the best IPv6 DNS configuration solution
- is feasible for a very large number of IPv6-capable UEs (can be
- even hundreds of millions in one operator's network), is automatic
- and thus requires no user action. It is suggested to standardize a
- lightweight, stateless mechanism that works in all network
- environments. The solution could then be used for 3GPP, 3GPP2,
- WLAN and other access network technologies. A light, stateless
- IPv6 DNS configuration mechanism is thus not only needed in 3GPP
- networks, but also 3GPP networks and UEs would certainly benefit
- from the new mechanism.
-
-5.3.2. RA Extension
-
- Router Advertisement extension [8] is a lightweight IPv6 DNS
- configuration mechanism that requires minor changes in 3GPP UE IPv6
- stack and Gateway GPRS Support Node (GGSN, the default router in
- the 3GPP architecture) IPv6 stack. This solution can be specified
- in the IETF (no action needed in the 3GPP) and taken in use in 3GPP
- UEs and GGSNs.
-
- In this solution, an IPv6-capable UE configures DNS information
- via RA message sent by its default router (GGSN), i.e., RDNSS
- option for recursive DNS server is included in the RA message.
- This solution is easily scalable for a very large number of UEs.
- The operator can configure the RDNSS addresses in the GGSN as a
- part of normal GGSN configuration. The IPv6 RDNSS address is
- received in the Router Advertisement, and an extra Round Trip Time
- (RTT) for asking RDNSS addresses can be avoided.
-
- If thinking about cons, this mechanism still requires
- standardization effort in the IETF, and the end nodes and routers
- need to support this mechanism. The equipment software update
- should, however, be pretty straightforward, and new IPv6 equipment
- could support RA extension already from the beginning.
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 16]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-5.3.3. Stateless DHCPv6
-
- DHCPv6-based solution needs the implementation of Stateless DHCP
- [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in
- the operator's network. A possible configuration is such that the
- GGSN works as a DHCP relay.
-
- Pros for Stateless DHCPv6-based solution are
-
- 1) Stateless DHCPv6 is a standardized mechanism.
-
- 2) DHCPv6 can be used for receiving other configuration information
- than RDNSS addresses, e.g., SIP server addresses.
-
- 3) DHCPv6 works in different network environments.
-
- 4) When DHCPv6 service is deployed through a single, centralized
- server, the RDNSS configuration information can be updated by the
- network administrator at a single source.
-
- Some issues with DHCPv6 in 3GPP networks are listed below:
-
- 1) DHCPv6 requires an additional server in the network unless the
- (Stateless) DHCPv6 functionality is integrated into an existing
- router already, and it is one box more to be maintained.
-
- 2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
- (3GPP Stateless Address Autoconfiguration is typically used), and
- not automatically implemented in 3GPP IPv6 UEs.
-
- 3) Scalability and reliability of DHCPv6 in very large 3GPP
- networks (with tens or hundreds of millions of UEs) may be an issue,
- at least the redundancy needs to be taken care of. However, if the
- DHCPv6 service is integrated into the network elements, such as
- router operating system, scalability and reliability is comparable
- with other DNS configuration approaches.
-
- 4) It is sub-optimal to utilize the radio resources in 3GPP
- networks for DHCPv6 messages if there is a simpler alternative
- available.
-
- a) Use of Stateless DHCPv6 adds one round trip delay to the case
- in which the UE can start transmitting data right after the
- Router Advertisement.
-
- 5) If the DNS information (suddenly) changes, Stateless DHCPv6 can
- not automatically update the UE, see [23].
-
-
-
-Jeong, et al. Expires - August 2005 [Page 17]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-5.3.4. Well-known Addresses
-
- Using well-known addresses is also a feasible and a light mechanism
- for 3GPP UEs. Those well-known addresses can be preconfigured in
- the UE software and the operator makes the corresponding
- configuration on the network side. So this is a very easy
- mechanism for the UE, but requires some configuration work in the
- network. When using well-known addresses, UE forwards queries to
- any of the preconfigured addresses. In the current proposal [9],
- IPv6 anycast addresses are suggested.
-
- Note: IPv6 DNS configuration proposal based on the use of
- well-known site-local addresses developed at the IPv6 Working Group
- was seen as a feasible mechanism for 3GPP UEs, but opposition by
- some people in the IETF and finally deprecating IPv6 site-local
- addresses made it impossible to standardize it. Note that this
- mechanism is implemented in some existing operating systems today
- (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration.
-
-5.3.5. Recommendations
-
- It is suggested that a lightweight, stateless DNS configuration
- mechanism is specified as soon as possible. From 3GPP UE's and
- networks' point of view, Router Advertisement based mechanism looks
- most promising. The sooner a light, stateless mechanism is
- specified, the sooner we can get rid of using well-known site-local
- addresses for IPv6 DNS configuration.
-
-5.4. Unmanaged Network
-
- There are 4 deployment scenarios of interest in unmanaged networks
- [24]:
-
- 1) A gateway which does not provide IPv6 at all;
-
- 2) A dual-stack gateway connected to a dual-stack ISP;
-
- 3) A dual-stack gateway connected to an IPv4-only ISP; and
-
- 4) A gateway connected to an IPv6-only ISP.
-
-5.4.1. Case A: Gateway does not provide IPv6 at all
-
- In this case, the gateway does not provide IPv6; the ISP may or may
- not provide IPv6. Automatic or Configured tunnels are the
- recommended transition mechanisms for this scenario.
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 18]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- The case where dual-stack hosts behind an NAT, that need access to
- an IPv6 RDNSS, can not be entirely ruled out. The DNS
- configuration mechanism has to work over the tunnel, and the
- underlying tunneling mechanism could be implementing NAT traversal.
- The tunnel server assumes the role of a relay (both for DHCP and
- Well-known anycast addresses approaches).
-
- RA-based mechanism is relatively straightforward in its operation,
- assuming the tunnel server is also the IPv6 router emitting RAs.
- Well-known anycast addresses approach seems also simple in
- operation across the tunnel, but the deployment model using
- Well-known anycast addresses in a tunneled environment is unclear or
- not well understood.
-
-5.4.2. Case B: A dual-stack gateway connected to a dual-stack ISP
-
- This is similar to a typical IPv4 home user scenario, where DNS
- configuration parameters are obtained using DHCP. Except that
- Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
- DHCP server is stateful (maintains the state for clients).
-
-5.4.3. Case C: A dual-stack gateway connected to an IPv4-only ISP
-
- This is similar to Case B. If a gateway provides IPv6 connectivity
- by managing tunnels, then it is also supposed to provide access to
- an RDNSS. Like this, the tunnel for IPv6 connectivity originates
- from the dual-stack gateway instead of the host.
-
-5.4.4. Case D: A gateway connected to an IPv6-only ISP
-
- This is similar to Case B.
-
-6. Security Considerations
-
- As security requirements depend solely on applications and are
- different application by application, there can be no generic
- requirement defined at higher IP or lower application layer of DNS.
-
- However, it should be noted that cryptographic security requires
- configured secret information that full autoconfiguration and
- cryptographic security are mutually exclusive. People insisting on
- secure full autoconfiguration will get false security, false
- autoconfiguration or both.
-
- In some deployment scenarios [19], where cryptographic security is
- required for applications, the secret information for the
- cryptographic security is preconfigured through which application
- specific configuration data, including those for DNS, can be
-
-
-Jeong, et al. Expires - August 2005 [Page 19]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- securely configured. It should be noted that if applications
- requiring cryptographic security depend on DNS, the applications
- also require cryptographic security to DNS. Therefore, the full
- autoconfiguration of DNS is not acceptable.
-
- However, with full autoconfiguration, weaker but still reasonable
- security is being widely accepted and will continue to be
- acceptable. That is, with full autoconfiguration, which means
- there is no cryptographic security for the autoconfiguration, it is
- already assumed that the local environment is secure enough that
- the information from the local autoconfiguration server has
- acceptable security even without cryptographic security. Thus, the
- communication between the local DNS client and local DNS server has
- the acceptable security.
-
- In autoconfiguring recursive servers, DNSSEC may be overkill,
- because DNSSEC [29] needs the configuration and reconfiguration of
- clients at root key roll-over [30][31]. Even if additional keys
- for secure key roll-over are added at the initial configuration,
- they are as vulnerable as the original keys to some forms of
- attacks, such as social hacking. Another problem of using DNSSEC
- and autoconfiguration together is that DNSSEC requires secure time,
- which means secure communication with autoconfigured time servers,
- which requires configured secret information. Therefore, in order
- that the autoconfiguration may be secure, it requires configured
- secret information.
-
- If DNSSEC [29] is used and the signatures are verified on the
- client host, the misconfiguration of a DNS server may be simply
- denial of service. Also, if local routing environment is not
- reliable, clients may be directed to a false resolver with the same
- IP address as the true one.
-
- For security considerations of each approach, refer to the
- corresponding drafts [5]-[9].
-
-7. Acknowledgements
-
- This draft has greatly benefited from inputs by David Meyer, Rob
- Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
- Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
- The authors appreciate their contributions.
-
-8. Normative References
-
- [1] S. Bradner, "Intellectual Property Rights in IETF Technology",
- RFC 3668, February 2004.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 20]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February
- 2004.
-
- [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for
- IP Version 6 (IPv6)", RFC 2461, December 1998.
-
- [4] S. Thomson and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC 2462, December 1998.
-
- [5] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [6] R. Droms, "Stateless Dynamic Host Configuration Protocol
- (DHCP) Service for IPv6", RFC 3736, April 2004.
-
- [7] R. Droms et al., "DNS Configuration options for Dynamic Host
- Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
- 2003.
-
-9. Informative References
-
- [8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS
- Discovery based on Router Advertisement",
- draft-jeong-dnsop-ipv6-dns-discovery-04.txt, February 2005,
- Work in Progress.
-
- [9] M. Ohta, "Preconfigured DNS Server Addresses",
- draft-ohta-preconfigured-dns-01.txt, February 2004, Work in
- Progress.
-
- [10] S. Venaas, T. Chown and B. Volz, "Information Refresh Time
- Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt, January
- 2005, Work in Progress.
-
- [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting
- Service", RFC 1546, November 1993.
-
- [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
- Addressing Architecture", RFC 3513, April 2003.
-
- [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6
- into ISP Networks",
- draft-ietf-v6ops-isp-scenarios-analysis-03.txt, June 2004,
- Work in Progress.
-
- [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)",
- draft-ietf-send-ndopt-06.txt, July 2004, Work in Progress.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 21]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages",
- RFC 3118, June 2001.
-
- [16] J. Bound et al., "IPv6 Enterprise Network Scenarios",
- draft-ietf-v6ops-ent-scenarios-05.txt, July 2004, Work in
- Progress.
-
- [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host
- Configuration Protocol (DHCP) version 6", RFC 3633, December
- 2003.
-
- [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP
- Standards", RFC 3314, September 2002.
-
- [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks",
- RFC 3574, August 2003.
-
- [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP
- Networks", draft-ietf-v6ops-3gpp-analysis-11.txt, October 2004,
- Work in Progress.
-
- [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
- Service description; Stage 2 (Release 5)", December 2002.
-
- [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
- specification; Core network protocols; Stage 3 (Release 5)",
- June 2003.
-
- [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering
- Requirements for Stateless DHCPv6",
- draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt, October
- 2004, Work in Progress.
-
- [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition
- Scenarios", RFC 3750, April 2004.
-
- [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access
- Control (MAC) and Physical Layer (PHY) Specifications", March
- 1999.
-
- [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control
- (MAC) and Physical Layer (PHY) specifications: High-speed
- Physical Layer in the 5 GHZ Band", September 1999.
-
- [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control
- (MAC) and Physical Layer (PHY) specifications: Higher-Speed
- Physical Layer Extension in the 2.4 GHz Band", September 1999.
-
-
-
-Jeong, et al. Expires - August 2005 [Page 22]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access
- Control (MAC) and Physical Layer (PHY) specifications: Further
- Higher Data Rate Extension in the 2.4 GHz Band", April 2003.
-
- [29] D. Eastlake, "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [30] O. Kolkman and R. Gieben, "DNSSEC Operational Practices",
- draft-ietf-dnsop-dnssec-operational-practices-03.txt,
- December 2004.
-
- [31] G. Guette and O. Courtay, "Requirements for Automated Key
- Rollover in DNSSEC",
- draft-ietf-dnsop-key-rollover-requirements-02.txt, January
- 2005.
-
-10. Appendix A - Link-layer Multicast Acknowledgements with RA Option
-
- One benefit of RA option is to be able to multicast the
- advertisements, reducing the need for duplicated unicast
- communications.
-
- However, some link-layers may not support this as well as others.
- Consider, for example, WLAN networks where multicast is unreliable.
- The unreliability problem is caused by lack of ACK for multicast,
- especially on the path from the Access Point (AP) to the Station
- (STA), which is specific to CSMA/CA of WLAN [25]-[28]. Namely,
- multicast packet is unacknowledged on the path from the AP to the
- STA, but acknowledged in the reverse direction from the STA to the
- AP [25]. For example, when a router is placed at wired network
- connected to an AP, a host may sometimes not receive RA message
- advertised through the AP.
-
- The fact that this problem has not been addressed in Neighbor
- Discovery [3] indicates that the extra link-layer acknowledgements
- have not been considered a serious problem till now.
-
- A possible mitigation technique could be to map all-nodes link-local
- multicast address to the link-layer broadcast address, and to rely
- on the ND retransmissions for message delivery.
-
-11. Authors' Addresses
-
- Jaehoon Paul Jeong, Editor
- ETRI/University of Minnesota at Twin Cities
- 117 Pleasant Street SE
- Minneapolis, MN 55455
- USA
-
-
-Jeong, et al. Expires - August 2005 [Page 23]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-
- Phone: +1 651 587 7774
- EMail: jjeong@cs.umn.edu
-
- Ralph Droms
- Cisco Systems
- 1414 Massachusetts Ave.
- Boxboro, MA 01719
- USA
-
- Phone: +1 978 936 1674
- EMail: rdroms@cisco.com
-
- Robert M. Hinden
- Nokia
- 313 Fairchild Drive
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 625 2004
- EMail: bob.hinden@nokia.com
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter Street
- Redwood City, CA 94043
- USA
-
- EMail: Ted.Lemon@nominum.com
-
- Masataka Ohta
- Graduate School of Information Science and Engineering
- Tokyo Institute of Technology
- 2-12-1, O-okayama, Meguro-ku
- Tokyo 152-8552
- Japan
-
- Phone: +81 3 5734 3299
- Fax: +81 3 5734 3299
- EMail: mohta@necom830.hpcl.titech.ac.jp
-
- Soohong Daniel Park
- Mobile Platform Laboratory, SAMSUNG Electronics
- 416, Maetan-3dong, Paldal-gu, Suwon
- Gyeonggi-Do
- Korea
-
- Phone: +82 31 200 4508
-
-
-Jeong, et al. Expires - August 2005 [Page 24]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
- EMail: soohong.park@samsung.com
-
- Suresh Satapati
- Cisco Systems, Inc.
- San Jose, CA 95134
- USA
-
- EMail: satapati@cisco.com
-
- Juha Wiljakka
- Nokia
- Visiokatu 3
- FIN-33720 TAMPERE
- Finland
-
- Phone: +358 7180 48372
- EMail: juha.wiljakka@nokia.com
-
-12. 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.
-
-13. Full 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.
-
-
-Jeong, et al. Expires - August 2005 [Page 25]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server February 2005
-
-
-
- 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong, et al. Expires - August 2005 [Page 26]
-\f
+++ /dev/null
-
-DNS Operations WG A. Durand
-Internet-Draft SUN Microsystems, Inc.
-Expires: April 24, 2005 J. Ihren
- Autonomica
- P. Savola
- CSC/FUNET
- October 24, 2004
-
-
-
- Operational Considerations and Issues with IPv6 DNS
- draft-ietf-dnsop-ipv6-dns-issues-10.txt
-
-
-Status of this Memo
-
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
- RFC 3668.
-
-
- 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 24, 2005.
-
-
-Copyright Notice
-
-
- Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
- This memo presents operational considerations and issues with IPv6
- Domain Name System (DNS), including a summary of special IPv6
- addresses, documentation of known DNS implementation misbehaviour,
- recommendations and considerations on how to perform DNS naming for
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 1]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- service provisioning and for DNS resolver IPv6 support,
- considerations for DNS updates for both the forward and reverse
- trees, and miscellaneous issues. This memo is aimed to include a
- summary of information about IPv6 DNS considerations for those who
- have experience with IPv4 DNS.
-
-
-Table of Contents
-
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4
- 1.2 Independence of DNS Transport and DNS Records . . . . . . 4
- 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5
- 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5
- 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5
- 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6
- 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6
- 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6
- 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6
- 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7
- 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7
- 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7
- 4. Recommendations for Service Provisioning using DNS . . . . . . 8
- 4.1 Use of Service Names instead of Node Names . . . . . . . . 8
- 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8
- 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9
- 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10
- 4.4.1 Description of Additional Data Scenarios . . . . . . . 10
- 4.4.2 Which Additional Data to Keep, If Any? . . . . . . . . 11
- 4.4.3 Discussion of the Problems . . . . . . . . . . . . . . 12
- 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 13
- 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 14
- 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 15
- 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 15
- 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 16
- 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 17
- 6. Considerations about Forward DNS Updating . . . . . . . . . . 17
- 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17
- 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 18
- 7. Considerations about Reverse DNS Updating . . . . . . . . . . 19
- 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 19
- 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 20
- 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 20
- 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 21
- 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 22
- 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 23
- 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 23
- 8.2 Renumbering Procedures and Applications' Use of DNS . . . 23
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 2]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- 10. Security Considerations . . . . . . . . . . . . . . . . . . 24
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
- 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 24
- 11.2 Informative References . . . . . . . . . . . . . . . . . . . 26
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
- A. Site-local Addressing Considerations for DNS . . . . . . . . . 29
- Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 3]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-1. Introduction
-
-
- This memo presents operational considerations and issues with IPv6
- DNS; it is meant to be an extensive summary and a list of pointers
- for more information about IPv6 DNS considerations for those with
- experience with IPv4 DNS.
-
-
- The purpose of this document is to give information about various
- issues and considerations related to DNS operations with IPv6; it is
- not meant to be a normative specification or standard for IPv6 DNS.
-
-
- The first section gives a brief overview of how IPv6 addresses and
- names are represented in the DNS, how transport protocols and
- resource records (don't) relate, and what IPv4/IPv6 name space
- fragmentation means and how to avoid it; all of these are described
- at more length in other documents.
-
-
- The second section summarizes the special IPv6 address types and how
- they relate to DNS. The third section describes observed DNS
- implementation misbehaviours which have a varying effect on the use
- of IPv6 records with DNS. The fourth section lists recommendations
- and considerations for provisioning services with DNS. The fifth
- section in turn looks at recommendations and considerations about
- providing IPv6 support in the resolvers. The sixth and seventh
- sections describe considerations with forward and reverse DNS
- updates, respectively. The eighth section introduces several
- miscellaneous IPv6 issues relating to DNS for which no better place
- has been found in this memo. Appendix A looks briefly at the
- requirements for site-local addressing.
-
-
-1.1 Representing IPv6 Addresses in DNS Records
-
-
- In the forward zones, IPv6 addresses are represented using AAAA
- records. In the reverse zones, IPv6 address are represented using
- PTR records in the nibble format under the ip6.arpa. tree. See
- [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
- for background information.
-
-
- In particular one should note that the use of A6 records in the
- forward tree or Bitlabels in the reverse tree is not recommended
- [RFC3363]. Using DNAME records is not recommended in the reverse
- tree in conjunction with A6 records; the document did not mean to
- take a stance on any other use of DNAME records [RFC3364].
-
-
-1.2 Independence of DNS Transport and DNS Records
-
-
- DNS has been designed to present a single, globally unique name space
- [RFC2826]. This property should be maintained, as described here and
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 4]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- in Section 1.3.
-
-
- The IP version used to transport the DNS queries and responses is
- independent of the records being queried: AAAA records can be queried
- over IPv4, and A records over IPv6. The DNS servers must not make
- any assumptions about what data to return for Answer and Authority
- sections based on the underlying transport used in a query.
-
-
- However, there is some debate whether the addresses in Additional
- section could be selected or filtered using hints obtained from which
- transport was being used; this has some obvious problems because in
- many cases the transport protocol does not correlate with the
- requests, and because a "bad" answer is in a way worse than no answer
- at all (consider the case where the client is led to believe that a
- name received in the additional record does not have any AAAA records
- at all).
-
-
- As stated in [RFC3596]:
-
-
- The IP protocol version used for querying resource records is
- independent of the protocol version of the resource records; e.g.,
- IPv4 transport can be used to query IPv6 records and vice versa.
-
-
-
-1.3 Avoiding IPv4/IPv6 Name Space Fragmentation
-
-
- To avoid the DNS name space from fragmenting into parts where some
- parts of DNS are only visible using IPv4 (or IPv6) transport, the
- recommendation is to always keep at least one authoritative server
- IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
- See DNS IPv6 transport guidelines [RFC3901] for more information.
-
-
-1.4 Query Type '*' and A/AAAA Records
-
-
- QTYPE=* is typically only used for debugging or management purposes;
- it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
- any available RRsets, not *all* the RRsets, because the caches do not
- necessarily have all the RRsets and have no way of guaranteeing that
- they have all the RRsets. Therefore, to get both A and AAAA records
- reliably, two separate queries must be made.
-
-
-2. DNS Considerations about Special IPv6 Addresses
-
-
- There are a couple of IPv6 address types which are somewhat special;
- these are considered here.
-
-
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 5]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-2.1 Limited-scope Addresses
-
-
- The IPv6 addressing architecture [RFC3513] includes two kinds of
- local-use addresses: link-local (fe80::/10) and site-local
- (fec0::/10). The site-local addresses have been deprecated
- [RFC3879], and are only discussed in Appendix A.
-
-
- Link-local addresses should never be published in DNS (whether in
- forward or reverse tree), because they have only local (to the
- connected link) significance
- [I-D.ietf-dnsop-dontpublish-unreachable].
-
-
-2.2 Temporary Addresses
-
-
- Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
- "privacy addresses") use a random number as the interface identifier.
- Having DNS AAAA records that are updated to always contain the
- current value of a node's temporary address would defeat the purpose
- of the mechanism and is not recommended. However, it would still be
- possible to return a non-identifiable name (e.g., the IPv6 address in
- hexadecimal format), as described in [RFC3041].
-
-
-2.3 6to4 Addresses
-
-
- 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
- a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
-
-
- If the reverse DNS population would be desirable (see Section 7.1 for
- applicability), there are a number of possible ways to do so
- [I-D.moore-6to4-dns], some more applicable than the others.
-
-
- The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
- autonomous reverse-delegation system that anyone being capable of
- communicating using a specific 6to4 address would be able to set up a
- reverse delegation to the corresponding 6to4 prefix. This could be
- deployed by e.g., Regional Internet Registries (RIRs). This is a
- practical solution, but may have some scalability concerns.
-
-
-2.4 Other Transition Mechanisms
-
-
- 6to4, above, is mentioned as a case of an IPv6 transition mechanism
- requiring special considerations. In general, mechanisms which
- include a special prefix may need a custom solution; otherwise, for
- example when IPv4 address is embedded as the suffix or not embedded
- at all, special solutions are likely not needed. This is why only
- 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.
-
-
- Note that it does not seem feasible to provide reverse DNS with
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 6]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- another automatic tunneling mechanism, Teredo; this is because the
- IPv6 address is based on the IPv4 address and UDP port of the current
- NAT mapping which is likely to be relatively short-lived.
-
-
-3. Observed DNS Implementation Misbehaviour
-
-
- Several classes of misbehaviour in DNS servers, load-balancers and
- resolvers have been observed. Most of these are rather generic, not
- only applicable to IPv6 -- but in some cases, the consequences of
- this misbehaviour are extremely severe in IPv6 environments and
- deserve to be mentioned.
-
-
-3.1 Misbehaviour of DNS Servers and Load-balancers
-
-
- There are several classes of misbehaviour in certain DNS servers and
- load-balancers which have been noticed and documented
- [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations
- silently drop queries for unimplemented DNS records types, or provide
- wrong answers to such queries (instead of a proper negative reply).
- While typically these issues are not limited to AAAA records, the
- problems are aggravated by the fact that AAAA records are being
- queried instead of (mainly) A records.
-
-
- The problems are serious because when looking up a DNS name, typical
- getaddrinfo() implementations, with AF_UNSPEC hint given, first try
- to query the AAAA records of the name, and after receiving a
- response, query the A records. This is done in a serial fashion --
- if the first query is never responded to (instead of properly
- returning a negative answer), significant timeouts will occur.
-
-
- In consequence, this is an enormous problem for IPv6 deployments, and
- in some cases, IPv6 support in the software has even been disabled
- due to these problems.
-
-
- The solution is to fix or retire those misbehaving implementations,
- but that is likely not going to be effective. There are some
- possible ways to mitigate the problem, e.g., by performing the
- lookups somewhat in parallel and reducing the timeout as long as at
- least one answer has been received; but such methods remain to be
- investigated; slightly more on this is included in Section 5.
-
-
-3.2 Misbehaviour of DNS Resolvers
-
-
- Several classes of misbehaviour have also been noticed in DNS
- resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem
- to directly impair IPv6 use, and are only referred to for
- completeness.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 7]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-4. Recommendations for Service Provisioning using DNS
-
-
- When names are added in the DNS to facilitate a service, there are
- several general guidelines to consider to be able to do it as
- smoothly as possible.
-
-
-4.1 Use of Service Names instead of Node Names
-
-
- It makes sense to keep logically separate services by a node separate
- in the DNS, due to a number of reasons, for example:
-
-
- o It allows more flexibility and ease for migration of (only a part
- of) services from one node to another,
-
-
- o It allows configuring different properties (e.g., TTL) for each
- service, and
-
-
- o It allows deciding separately for each service whether to publish
- the IPv6 addresses or not (in cases if some services are more
- IPv6-ready than others).
-
-
- Using SRV records [RFC2782] would avoid these problems.
- Unfortunately, those are not sufficiently widely used to be
- applicable in most cases. Hence an operation technique is to use
- service names instead of node names (or, "hostnames"). This
- operational technique is not specific to IPv6, but required to
- understand the considerations described in Section 4.2 and Section
- 4.3.
-
-
- For example, assume a node named "pobox.example.com" provides both
- SMTP and IMAP service. Instead of configuring the MX records to
- point at "pobox.example.com", and configuring the mail clients to
- look up the mail via IMAP from "pobox.example.com", one could use
- e.g., "smtp.example.com" for SMTP (for both message submission and
- mail relaying between SMTP servers) and "imap.example.com" for IMAP.
- Note that in the specific case of SMTP relaying, the server itself
- must typically also be configured to know all its names to ensure
- loops do not occur. DNS can provide a layer of indirection between
- service names and where the service actually is, and using which
- addresses. (Obviously, when wanting to reach a specific node, one
- should use the hostname rather than a service name.)
-
-
-4.2 Separate vs the Same Service Names for IPv4 and IPv6
-
-
- The service naming can be achieved in basically two ways: when a
- service is named "service.example.com" for IPv4, the IPv6-enabled
- service could be either added to "service.example.com", or added
- separately under a different name, e.g., in a sub-domain, like,
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 8]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- "service.ipv6.example.com".
-
-
- These two methods have different characteristics. Using a different
- name allows for easier service piloting, minimizing the disturbance
- to the "regular" users of IPv4 service; however, the service would
- not be used transparently, without the user/application explicitly
- finding it and asking for it -- which would be a disadvantage in most
- cases. When the different name is under a sub-domain, if the
- services are deployed within a restricted network (e.g., inside an
- enterprise), it's possible to prefer them transparently, at least to
- a degree, by modifying the DNS search path; however, this is a
- suboptimal solution. Using the same service name is the "long-term"
- solution, but may degrade performance for those clients whose IPv6
- performance is lower than IPv4, or does not work as well (see Section
- 4.3 for more).
-
-
- In most cases, it makes sense to pilot or test a service using
- separate service names, and move to the use of the same name when
- confident enough that the service level will not degrade for the
- users unaware of IPv6.
-
-
-4.3 Adding the Records Only when Fully IPv6-enabled
-
-
- The recommendation is that AAAA records for a service should not be
- added to the DNS until all of following are true:
-
-
- 1. The address is assigned to the interface on the node.
-
-
- 2. The address is configured on the interface.
-
-
- 3. The interface is on a link which is connected to the IPv6
- infrastructure.
-
-
- In addition, if the AAAA record is added for the node, instead of
- service as recommended, all the services of the node should be
- IPv6-enabled prior to adding the resource record.
-
-
- For example, if an IPv6 node is isolated from an IPv6 perspective
- (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
- that it should not have an address in the DNS.
-
-
- Consider the case of two dual-stack nodes, which both have IPv6
- enabled, but the server does not have (global) IPv6 connectivity. As
- the client looks up the server's name, only A records are returned
- (if the recommendations above are followed), and no IPv6
- communication, which would have been unsuccessful, is even attempted.
-
-
- The issues are not always so black-and-white. Usually it's important
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 9]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- if the service offered using both protocols is of roughly equal
- quality, using the appropriate metrics for the service (e.g.,
- latency, throughput, low packet loss, general reliability, etc.) --
- this is typically very important especially for interactive or
- real-time services. In many cases, the quality of IPv6 connectivity
- may not yet be equal to that of IPv4, at least globally -- this has
- to be taken into consideration when enabling services
- [I-D.savola-v6ops-6bone-mess].
-
-
-4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
-
-
- DNS responses do not always fit in a single UDP packet. We'll
- examine the cases which happen when this is due to too much data in
- the Additional Section.
-
-
-4.4.1 Description of Additional Data Scenarios
-
-
- There are two kinds of additional data:
-
-
- 1. "critical" additional data; this must be included in all
- scenarios, with all the RRsets, and
-
-
- 2. "courtesy" additional data; this could be sent in full, with only
- a few RRsets, or with no RRsets, and can be fetched separately as
- well, but at the cost of additional queries.
-
-
- The responding server can algorithmically determine which type the
- additional data is by checking whether it's at or below a zone cut.
-
-
- Only those additional data records (even if sometimes carelessly
- termed "glue") are considered "critical" or real "glue" if and only
- if they meet the abovementioned condition, as specified in Section
- 4.2.1 of [RFC1034].
-
-
- Remember that resource record sets (RRsets) are never "broken up", so
- if a name has 4 A records and 5 AAAA records, you can either return
- all 9, all 4 A records, all 5 AAAA records or nothing. In
- particular, notice that for the "critical" additional data getting
- all the RRsets can be critical.
-
-
- In particular, [RFC2181] specifies (in Section 9) that:
-
-
- a. if all the "critical" RRsets do not fit, the sender should set
- the TC bit, and the recipient should discard the whole response
- and retry using mechanism allowing larger responses such as TCP.
-
-
- b. "courtesy" additional data should not cause the setting of TC
- bit, but instead all the non-fitting additional data RRsets
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 10]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- should be removed.
-
-
- An example of the "courtesy" additional data is A/AAAA records in
- conjunction of MX records is shown in Section 4.5; an example of the
- "critical" additional data is shown below (where getting both the A
- and AAAA RRsets is critical):
-
-
- child.example.com. IN NS ns.child.example.com.
- ns.child.example.com. IN A 192.0.2.1
- ns.child.example.com. IN AAAA 2001:db8::1
-
-
- When there is too much courtesy additional data, at least the
- non-fitting RRsets should be removed [RFC2181]; however, as the
- additional data is not critical, even all of it could be safely
- removed.
-
-
- When there is too much critical additional data, TC bit will have to
- be set, and the recipient should ignore the response and retry using
- TCP; if some data were to be left in the UDP response, the issue is
- which data could be retained.
-
-
- Failing to discard the response with TC bit set leads to a protocol
- problem. Omitting only some of the RRsets if all would not fit leads
- to a performance problem. These are discussed in Section 4.4.3.
-
-
-4.4.2 Which Additional Data to Keep, If Any?
-
-
- If the implementation decides to keep as much data (whether
- "critical" or "courtesy") as possible in the UDP responses, it might
- be tempting to use the transport of the DNS query as a hint in either
- of these cases: return the AAAA records if the query was done over
- IPv6, or return the A records if the query was done over IPv4.
- However, this breaks the model of independence of DNS transport and
- resource records, as noted in Section 1.2.
-
-
- With courtesy additional data, as long as enough RRsets will be
- removed so that TC will not be set, it is allowed to send as many
- complete RRsets as the implementations prefers. However, the
- implementations are also free to omit all such RRsets, even if
- complete. Removing all the RRsets if some would not fit obviates a
- performance problem, which would require the users to issue second
- queries to obtain consistent information.
-
-
- With critical additional data, the alternatives are either returning
- nothing (and absolutely requiring a retry with TCP) or returning
- something (working also in the case if the recipient does not discard
- the response and retry using TCP) in addition to setting the TC bit.
- If the process for selecting "something" from the critical data would
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 11]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- otherwise be practically "flipping the coin" between A and AAAA
- records, it could be argued that if one looked at the transport of
- the query, it would have a larger possibility of being right than
- just 50/50. In other words, if the returned critical additional data
- would have to be selected somehow, using something more sophisticated
- than a random process would seem justifiable.
-
-
- That is, leaving in some intelligently selected critical additional
- data is a tradeoff between creating an optimization for those
- resolvers which ignore the "should discard" recommendation, and a
- causing a protocol problem by propagating inconsistent information
- about "critical" records in the caches.
-
-
- Similarly, leaving in the complete courtesy additional data RRsets
- instead of removing all the RRsets is a performance tradeoff as
- described in the next section.
-
-
-4.4.3 Discussion of the Problems
-
-
- As noted above, the temptation for omitting only some of the
- additional data based on the transport of the query could be
- problematic. In particular, there appears to be little justification
- for doing so in the case of "courtesy" data.
-
-
- For courtesy additional data, this causes a performance problem as
- this requires that the clients issue re-query for the potentially
- omitted RRsets. For critical additional data, this causes a
- potential protocol problem if the response is not discarded and the
- query not re-tried with TCP, as the nameservers might be reachable
- only through the omitted RRsets.
-
-
- If an implementation would look at the transport used for the query,
- it is worth remembering that often the host using the records is
- different from the node requesting them from the authoritative DNS
- server (or even a caching resolver). So, whichever version the
- requestor (e.g., a recursive server in the middle) uses makes no
- difference to the ultimate user of the records, whose transport
- capabilities might differ from those of the requestor. This might
- result in e.g., inappropriately returning A records to an IPv6-only
- node, going through a translation, or opening up another IP-level
- session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
- Therefore, at least in many scenarios, it would be very useful if the
- information returned would be consistent and complete -- or if that
- is not feasible, return no misleading information but rather leave it
- to the client to query again.
-
-
- The problem of too much additional data seems to be an operational
- one: the zone administrator entering too many records which will be
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 12]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- returned either truncated (or missing some RRsets, depending on
- implementations) to the users. A protocol fix for this is using
- EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
- pushing up the relevant threshold. Further, DNS server
- implementations should rather omit courtesy additional data
- completely rather than including only some RRsets [RFC2181]. An
- operational fix for this is having the DNS server implementations
- return a warning when the administrators create zones which would
- result in too much additional data being returned. Further, DNS
- server implementations should warn of or disallow such zone
- configurations which are recursive or otherwise difficult to manage
- by the protocol.
-
-
- Additionally, to avoid the case where an application would not get an
- address at all due to some of "courtesy" additional data being
- omitted, the resolvers should be able to query the specific records
- of the desired protocol, not just rely on getting all the required
- RRsets in the additional section.
-
-
-4.5 The Use of TTL for IPv4 and IPv6 RRs
-
-
- In the previous section, we discussed a danger with queries,
- potentially leading to omitting RRsets from the additional section;
- this could happen to both critical and "courtesy" additional data
- (however, both of these are recommended against in [RFC2181]). This
- section discusses another problem with courtesy additional data,
- leading to omitting RRsets in cached data, highlighted in the
- IPv4/IPv6 environment.
-
-
- The behaviour of DNS caching when different TTL values are used for
- different RRsets of the same name requires explicit discussion. For
- example, let's consider a part of a zone:
-
-
- example.com. 300 IN MX foo.example.com.
- foo.example.com. 300 IN A 192.0.2.1
- foo.example.com. 100 IN AAAA 2001:db8::1
-
-
- When a caching resolver asks for the MX record of example.com, it
- gets back "foo.example.com". It may also get back either one or both
- of the A and AAAA records in the additional section. So, there are
- three cases about returning records for the MX in the additional
- section:
-
-
- 1. We get back no A or AAAA RRsets: this is the simplest case,
- because then we have to query which information is required
- explicitly, guaranteeing that we get all the information we're
- interested in.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 13]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- 2. We get back all the RRsets: this is an optimization as there is
- no need to perform more queries, causing lower latency. However,
- it is impossible to guarantee that in fact we would always get
- back all the records (the only way to ensure that is to send a
- AAAA query for the name after getting the cached reply with A
- records or vice versa).
-
-
- 3. We only get back A or AAAA RRsets even if both existed: this is
- indistinguishable from the previous case, and may have
- performance problems at least in certain environments as
- described in the previous section.
-
-
- As the third case was considered in the previous section, we assume
- we get back both A and AAAA records of foo.example.com, or the stub
- resolver explicitly asks, in two separate queries, both A and AAAA
- records.
-
-
- After 100 seconds, the AAAA record is removed from the cache(s)
- because its TTL expired. It could be argued to be useful for the
- caching resolvers to discard the A record when the shorter TTL (in
- this case, for the AAAA record) expires; this would avoid the
- situation where there would be a window of 200 seconds when
- incomplete information is returned from the cache. Further argument
- for discarding is that in the normal operation, the TTL values are so
- high that very likely the incurred additional queries would not be
- noticeable, compared to the obtained performance optimization. The
- behaviour in this scenario is unspecified.
-
-
- To simplify the situation, it might help to use the same TTL for all
- the resource record sets referring to the same name, unless there is
- a particular reason for not doing so. However, there are some
- scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
- a different strategy is preferable.
-
-
- Thus, applications that use the response should not rely on a
- particular TTL configuration. For example, even if an application
- gets a response that only has the A record in the example described
- above, it should be still aware that there could be a AAAA record for
- "foo.example.com". That is, the application should try to fetch the
- missing records itself if it needs the record.
-
-
-4.6 IPv6 Transport Guidelines for DNS Servers
-
-
- As described in Section 1.3 and [RFC3901], there should continue to
- be at least one authoritative IPv4 DNS server for every zone, even if
- the zone has only IPv6 records. (Note that obviously, having more
- servers with robust connectivity would be preferable, but this is the
- minimum recommendation; also see [RFC2182].)
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 14]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-5. Recommendations for DNS Resolver IPv6 Support
-
-
- When IPv6 is enabled on a node, there are several things to consider
- to ensure that the process is as smooth as possible.
-
-
-5.1 DNS Lookups May Query IPv6 Records Prematurely
-
-
- The system library that implements the getaddrinfo() function for
- looking up names is a critical piece when considering the robustness
- of enabling IPv6; it may come in basically three flavours:
-
-
- 1. The system library does not know whether IPv6 has been enabled in
- the kernel of the operating system: it may start looking up AAAA
- records with getaddrinfo() and AF_UNSPEC hint when the system is
- upgraded to a system library version which supports IPv6.
-
-
- 2. The system library might start to perform IPv6 queries with
- getaddrinfo() only when IPv6 has been enabled in the kernel.
- However, this does not guarantee that there exists any useful
- IPv6 connectivity (e.g., the node could be isolated from the
- other IPv6 networks, only having link-local addresses).
-
-
- 3. The system library might implement a toggle which would apply
- some heuristics to the "IPv6-readiness" of the node before
- starting to perform queries; for example, it could check whether
- only link-local IPv6 address(es) exists, or if at least one
- global IPv6 address exists.
-
-
- First, let us consider generic implications of unnecessary queries
- for AAAA records: when looking up all the records in the DNS, AAAA
- records are typically tried first, and then A records. These are
- done in serial, and the A query is not performed until a response is
- received to the AAAA query. Considering the misbehaviour of DNS
- servers and load-balancers, as described in Section 3.1, the look-up
- delay for AAAA may incur additional unnecessary latency, and
- introduce a component of unreliability.
-
-
- One option here could be to do the queries partially in parallel; for
- example, if the final response to the AAAA query is not received in
- 0.5 seconds, start performing the A query while waiting for the
- result (immediate parallelism might be unoptimal, at least without
- information sharing between the look-up threads, as that would
- probably lead to duplicate non-cached delegation chain lookups).
-
-
- An additional concern is the address selection, which may, in some
- circumstances, prefer AAAA records over A records even when the node
- does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
- In some cases, the implementation may attempt to connect or send a
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 15]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
- incurring very long protocol timeouts, instead of quickly failing
- back to IPv4.
-
-
- Now, we can consider the issues specific to each of the three
- possibilities:
-
-
- In the first case, the node performs a number of completely useless
- DNS lookups as it will not be able to use the returned AAAA records
- anyway. (The only exception is where the application desires to know
- what's in the DNS, but not use the result for communication.) One
- should be able to disable these unnecessary queries, for both latency
- and reliability reasons. However, as IPv6 has not been enabled, the
- connections to IPv6 addresses fail immediately, and if the
- application is programmed properly, the application can fall
- gracefully back to IPv4 [I-D.ietf-v6ops-application-transition].
-
-
- The second case is similar to the first, except it happens to a
- smaller set of nodes when IPv6 has been enabled but connectivity has
- not been provided yet; similar considerations apply, with the
- exception that IPv6 records, when returned, will be actually tried
- first which may typically lead to long timeouts.
-
-
- The third case is a bit more complex: optimizing away the DNS lookups
- with only link-locals is probably safe (but may be desirable with
- different lookup services which getaddrinfo() may support), as the
- link-locals are typically automatically generated when IPv6 is
- enabled, and do not indicate any form of IPv6 connectivity. That is,
- performing DNS lookups only when a non-link-local address has been
- configured on any interface could be beneficial -- this would be an
- indication that either the address has been configured either from a
- router advertisement, DHCPv6 [RFC3315], or manually. Each would
- indicate at least some form of IPv6 connectivity, even though there
- would not be guarantees of it.
-
-
- These issues should be analyzed at more depth, and the fixes found
- consensus on, perhaps in a separate document.
-
-
-5.2 Obtaining a List of DNS Recursive Resolvers
-
-
- In scenarios where DHCPv6 is available, a host can discover a list of
- DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
- option [RFC3646]. This option can be passed to a host through a
- subset of DHCPv6 [RFC3736].
-
-
- The IETF is considering the development of alternative mechanisms for
- obtaining the list of DNS recursive name servers when DHCPv6 is
- unavailable or inappropriate. No decision about taking on this
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 16]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- development work has been reached as of this writing (Aug 2004)
- [I-D.ietf-dnsop-ipv6-dns-configuration].
-
-
- In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
- under consideration for development include the use of well-known
- addresses [I-D.ohta-preconfigured-dns] and the use of Router
- Advertisements to convey the information
- [I-D.jeong-dnsop-ipv6-dns-discovery].
-
-
- Note that even though IPv6 DNS resolver discovery is a recommended
- procedure, it is not required for dual-stack nodes in dual-stack
- networks as IPv6 DNS records can be queried over IPv4 as well as
- IPv6. Obviously, nodes which are meant to function without manual
- configuration in IPv6-only networks must implement the DNS resolver
- discovery function.
-
-
-5.3 IPv6 Transport Guidelines for Resolvers
-
-
- As described in Section 1.3 and [RFC3901], the recursive resolvers
- should be IPv4-only or dual-stack to be able to reach any IPv4-only
- DNS server. Note that this requirement is also fulfilled by an
- IPv6-only stub resolver pointing to a dual-stack recursive DNS
- resolver.
-
-
-6. Considerations about Forward DNS Updating
-
-
- While the topic how to enable updating the forward DNS, i.e., the
- mapping from names to the correct new addresses, is not specific to
- IPv6, it should be considered especially due to the advent of
- Stateless Address Autoconfiguration [RFC2462].
-
-
- Typically forward DNS updates are more manageable than doing them in
- the reverse DNS, because the updater can often be assumed to "own" a
- certain DNS name -- and we can create a form of security relationship
- with the DNS name and the node which is allowed to update it to point
- to a new address.
-
-
- A more complex form of DNS updates -- adding a whole new name into a
- DNS zone, instead of updating an existing name -- is considered out
- of scope for this memo as it could require zone-wide authentication.
- Adding a new name in the forward zone is a problem which is still
- being explored with IPv4, and IPv6 does not seem to add much new in
- that area.
-
-
-6.1 Manual or Custom DNS Updates
-
-
- The DNS mappings can also be maintained by hand, in a semi-automatic
- fashion or by running non-standardized protocols. These are not
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 17]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- considered at more length in this memo.
-
-
-6.2 Dynamic DNS
-
-
- Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized
- mechanism for dynamically updating the DNS. It works equally well
- with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
- address configuration. It is important to consider how each of these
- behave if IP address-based authentication, instead of stronger
- mechanisms [RFC3007], was used in the updates.
-
-
- 1. manual addresses are static and can be configured
-
-
- 2. DHCPv6 addresses could be reasonably static or dynamic, depending
- on the deployment, and could or could not be configured on the
- DNS server for the long term
-
-
- 3. SLAAC addresses are typically stable for a long time, but could
- require work to be configured and maintained.
-
-
- As relying on IP addresses for Dynamic DNS is rather insecure at
- best, stronger authentication should always be used; however, this
- requires that the authorization keying will be explicitly configured
- using unspecified operational methods.
-
-
- Note that with DHCP it is also possible that the DHCP server updates
- the DNS, not the host. The host might only indicate in the DHCP
- exchange which hostname it would prefer, and the DHCP server would
- make the appropriate updates. Nonetheless, while this makes setting
- up a secure channel between the updater and the DNS server easier, it
- does not help much with "content" security, i.e., whether the
- hostname was acceptable -- if the DNS server does not include
- policies, they must be included in the DHCP server (e.g., a regular
- host should not be able to state that its name is "www.example.com").
- DHCP-initiated DDNS updates have been extensively described in
- [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
- [I-D.ietf-dnsext-dhcid-rr].
-
-
- The nodes must somehow be configured with the information about the
- servers where they will attempt to update their addresses, sufficient
- security material for authenticating themselves to the server, and
- the hostname they will be updating. Unless otherwise configured, the
- first could be obtained by looking up the authoritative name servers
- for the hostname; the second must be configured explicitly unless one
- chooses to trust the IP address-based authentication (not a good
- idea); and lastly, the nodename is typically pre-configured somehow
- on the node, e.g., at install time.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 18]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- Care should be observed when updating the addresses not to use longer
- TTLs for addresses than are preferred lifetimes for the addresses, so
- that if the node is renumbered in a managed fashion, the amount of
- stale DNS information is kept to the minimum. That is, if the
- preferred lifetime of an address expires, the TTL of the record needs
- be modified unless it was already done before the expiration. For
- better flexibility, the DNS TTL should be much shorter (e.g., a half
- or a third) than the lifetime of an address; that way, the node can
- start lowering the DNS TTL if it seems like the address has not been
- renewed/refreshed in a while. Some discussion on how an
- administrator could manage the DNS TTL is included in
- [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to
- (smart) hosts as well.
-
-
-7. Considerations about Reverse DNS Updating
-
-
- Updating the reverse DNS zone may be difficult because of the split
- authority over an address. However, first we have to consider the
- applicability of reverse DNS in the first place.
-
-
-7.1 Applicability of Reverse DNS
-
-
- Today, some applications use reverse DNS to either look up some hints
- about the topological information associated with an address (e.g.
- resolving web server access logs), or as a weak form of a security
- check, to get a feel whether the user's network administrator has
- "authorized" the use of the address (on the premises that adding a
- reverse record for an address would signal some form of
- authorization).
-
-
- One additional, maybe slightly more useful usage is ensuring that the
- reverse and forward DNS contents match (by looking up the pointer to
- the name by the IP address from the reverse tree, and ensuring that a
- record under the name in the forward tree points to the IP address)
- and correspond to a configured name or domain. As a security check,
- it is typically accompanied by other mechanisms, such as a
- user/password login; the main purpose of the reverse+forward DNS
- check is to weed out the majority of unauthorized users, and if
- someone managed to bypass the checks, he would still need to
- authenticate "properly".
-
-
- It may also be desirable to store IPsec keying material corresponding
- to an IP address to the reverse DNS, as justified and described in
- [I-D.ietf-ipseckey-rr].
-
-
- It is not clear whether it makes sense to require or recommend that
- reverse DNS records be updated. In many cases, it would just make
- more sense to use proper mechanisms for security (or topological
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 19]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- information lookup) in the first place. At minimum, the applications
- which use it as a generic authorization (in the sense that a record
- exists at all) should be modified as soon as possible to avoid such
- lookups completely.
-
-
- The applicability is discussed at more length in
- [I-D.ietf-dnsop-inaddr-required].
-
-
-7.2 Manual or Custom DNS Updates
-
-
- Reverse DNS can of course be updated using manual or custom methods.
- These are not further described here, except for one special case.
-
-
- One way to deploy reverse DNS would be to use wildcard records, for
- example, by configuring one name for a subnet (/64) or a site (/48).
- As a concrete example, a site (or the site's ISP) could configure the
- reverses of the prefix 2001:db8:f00::/48 to point to one name using a
- wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
- site.example.com." Naturally, such a name could not be verified from
- the forward DNS, but would at least provide some form of "topological
- information" or "weak authorization" if that is really considered to
- be useful. Note that this is not actually updating the DNS as such,
- as the whole point is to avoid DNS updates completely by manually
- configuring a generic name.
-
-
-7.3 DDNS with Stateless Address Autoconfiguration
-
-
- Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
- some regard, while being more difficult in another, as described
- below.
-
-
- The address space administrator decides whether the hosts are trusted
- to update their reverse DNS records or not. If they are trusted and
- deployed at the same site (e.g., not across the Internet), a simple
- address-based authorization is typically sufficient (i.e., check that
- the DNS update is done from the same IP address as the record being
- updated); stronger security can also be used [RFC3007]. If they
- aren't allowed to update the reverses, no update can occur. However,
- such address-based update authorization operationally requires that
- ingress filtering [RFC3704] has been set up at the border of the site
- where the updates occur, and as close to the updater as possible.
-
-
- Address-based authorization is simpler with reverse DNS (as there is
- a connection between the record and the address) than with forward
- DNS. However, when a stronger form of security is used, forward DNS
- updates are simpler to manage because the host can be assumed to have
- an association with the domain. Note that the user may roam to
- different networks, and does not necessarily have any association
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 20]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- with the owner of that address space -- so, assuming stronger form of
- authorization for reverse DNS updates than an address association is
- generally unfeasible.
-
-
- Moreover, the reverse zones must be cleaned up by an unspecified
- janitorial process: the node does not typically know a priori that it
- will be disconnected, and cannot send a DNS update using the correct
- source address to remove a record.
-
-
- A problem with defining the clean-up process is that it is difficult
- to ensure that a specific IP address and the corresponding record are
- no longer being used. Considering the huge address space, and the
- unlikelihood of collision within 64 bits of the interface
- identifiers, a process which would remove the record after no traffic
- has been seen from a node in a long period of time (e.g., a month or
- year) might be one possible approach.
-
-
- To insert or update the record, the node must discover the DNS server
- to send the update to somehow, similar to as discussed in Section
- 6.2. One way to automate this is looking up the DNS server
- authoritative (e.g., through SOA record) for the IP address being
- updated, but the security material (unless the IP address-based
- authorization is trusted) must also be established by some other
- means.
-
-
- One should note that Cryptographically Generated Addresses
- [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of
- treatment. CGAs are addresses where the interface identifier is
- calculated from a public key, a modifier (used as a nonce), the
- subnet prefix, and other data. Depending on the usage profile, CGAs
- might or might not be changed periodically due to e.g., privacy
- reasons. As the CGA address is not predicatable, a reverse record
- can only reasonably be inserted in the DNS by the node which
- generates the address.
-
-
-7.4 DDNS with DHCP
-
-
- With DHCPv4, the reverse DNS name is typically already inserted to
- the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One
- can assume similar practice may become commonplace with DHCPv6 as
- well; all such mappings would be pre-configured, and would require no
- updating.
-
-
- If a more explicit control is required, similar considerations as
- with SLAAC apply, except for the fact that typically one must update
- a reverse DNS record instead of inserting one (if an address
- assignment policy that reassigns disused addresses is adopted) and
- updating a record seems like a slightly more difficult thing to
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 21]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- secure. However, it is yet uncertain how DHCPv6 is going to be used
- for address assignment.
-
-
- Note that when using DHCP, either the host or the DHCP server could
- perform the DNS updates; see the implications in Section 6.2.
-
-
- If disused addresses were to be reassigned, host-based DDNS reverse
- updates would need policy considerations for DNS record modification,
- as noted above. On the other hand, if disused address were not to be
- assigned, host-based DNS reverse updates would have similar
- considerations as SLAAC in Section 7.3. Server-based updates have
- similar properties except that the janitorial process could be
- integrated with DHCP address assignment.
-
-
-7.5 DDNS with Dynamic Prefix Delegation
-
-
- In cases where a prefix, instead of an address, is being used and
- updated, one should consider what is the location of the server where
- DDNS updates are made. That is, where the DNS server is located:
-
-
- 1. At the same organization as the prefix delegator.
-
-
- 2. At the site where the prefixes are delegated to. In this case,
- the authority of the DNS reverse zone corresponding to the
- delegated prefix is also delegated to the site.
-
-
- 3. Elsewhere; this implies a relationship between the site and where
- DNS server is located, and such a relationship should be rather
- straightforward to secure as well. Like in the previous case,
- the authority of the DNS reverse zone is also delegated.
-
-
- In the first case, managing the reverse DNS (delegation) is simpler
- as the DNS server and the prefix delegator are in the same
- administrative domain (as there is no need to delegate anything at
- all); alternatively, the prefix delegator might forgo DDNS reverse
- capability altogether, and use e.g., wildcard records (as described
- in Section 7.2). In the other cases, it can be slighly more
- difficult, particularly as the site will have to configure the DNS
- server to be authoritative for the delegated reverse zone, implying
- automatic configuration of the DNS server -- as the prefix may be
- dynamic.
-
-
- Managing the DDNS reverse updates is typically simple in the second
- case, as the updated server is located at the local site, and
- arguably IP address-based authentication could be sufficient (or if
- not, setting up security relationships would be simpler). As there
- is an explicit (security) relationship between the parties in the
- third case, setting up the security relationships to allow reverse
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 22]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- DDNS updates should be rather straightforward as well (but IP
- address-based authentication might not be acceptable). In the first
- case, however, setting up and managing such relationships might be a
- lot more difficult.
-
-
-8. Miscellaneous DNS Considerations
-
-
- This section describes miscellaneous considerations about DNS which
- seem related to IPv6, for which no better place has been found in
- this document.
-
-
-8.1 NAT-PT with DNS-ALG
-
-
- The DNS-ALG component of NAT-PT mangles A records to look like AAAA
- records to the IPv6-only nodes. Numerous problems have been
- identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues].
- This is a strong reason not to use NAT-PT in the first place.
-
-
-8.2 Renumbering Procedures and Applications' Use of DNS
-
-
- One of the most difficult problems of systematic IP address
- renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
- an application which looks up a DNS name disregards information such
- as TTL, and uses the result obtained from DNS as long as it happens
- to be stored in the memory of the application. For applications
- which run for a long time, this could be days, weeks or even months;
- some applications may be clever enough to organize the data
- structures and functions in such a manner that look-ups get refreshed
- now and then.
-
-
- While the issue appears to have a clear solution, "fix the
- applications", practically this is not reasonable immediate advice;
- the TTL information is not typically available in the APIs and
- libraries (so, the advice becomes "fix the applications, APIs and
- libraries"), and a lot more analysis is needed on how to practically
- go about to achieve the ultimate goal of avoiding using the names
- longer than expected.
-
-
-9. Acknowledgements
-
-
- Some recommendations (Section 4.3, Section 5.1) about IPv6 service
- provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
- Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided
- useful feedback and improvements. Scott Rose, Rob Austein, Masataka
- Ohta, and Mark Andrews helped in clarifying the issues regarding
- additional data and the use of TTL. Jefsey Morfin, Ralph Droms,
- Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
- Rob Austein provided useful feedback during the WG last call. Thomas
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 23]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- Narten provided extensive feedback during the IESG evaluation.
-
-
-10. Security Considerations
-
-
- This document reviews the operational procedures for IPv6 DNS
- operations and does not have security considerations in itself.
-
-
- However, it is worth noting that in particular with Dynamic DNS
- Updates, security models based on the source address validation are
- very weak and cannot be recommended -- they could only be considered
- in the environments where ingress filtering [RFC3704] has been
- deployed. On the other hand, it should be noted that setting up an
- authorization mechanism (e.g., a shared secret, or public-private
- keys) between a node and the DNS server has to be done manually, and
- may require quite a bit of time and expertise.
-
-
- To re-emphasize which was already stated, the reverse+forward DNS
- check provides very weak security at best, and the only
- (questionable) security-related use for them may be in conjunction
- with other mechanisms when authenticating a user.
-
-
-11. References
-
-
-11.1 Normative References
-
-
- [I-D.ietf-dnsop-ipv6-dns-configuration]
- Jeong, J., "IPv6 Host Configuration of DNS Server
- Information Approaches",
- draft-ietf-dnsop-ipv6-dns-configuration-04 (work in
- progress), September 2004.
-
-
- [I-D.ietf-dnsop-misbehavior-against-aaaa]
- Morishita, Y. and T. Jinmei, "Common Misbehavior against
- DNS Queries for IPv6 Addresses",
- draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in
- progress), April 2004.
-
-
- [I-D.ietf-v6ops-application-transition]
- Shin, M., "Application Aspects of IPv6 Transition",
- draft-ietf-v6ops-application-transition-03 (work in
- progress), June 2004.
-
-
- [I-D.ietf-v6ops-renumbering-procedure]
- Baker, F., Lear, E. and R. Droms, "Procedures for
- Renumbering an IPv6 Network without a Flag Day",
- draft-ietf-v6ops-renumbering-procedure-01 (work in
- progress), July 2004.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 24]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
-
- [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.
-
-
- [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
- and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
- July 1997.
-
-
- [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC 2462, December 1998.
-
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
-
- [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
- Stateless Address Autoconfiguration in IPv6", RFC 3041,
- January 2001.
-
-
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
- via IPv4 Clouds", RFC 3056, February 2001.
-
-
- [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
- August 2001.
-
-
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
- M. Carney, "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
-
- [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.
-
-
- [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
- (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 25]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
- Extensions to Support IP Version 6", RFC 3596, October
- 2003.
-
-
- [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
- Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
- December 2003.
-
-
- [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
- (DHCP) Service for IPv6", RFC 3736, April 2004.
-
-
- [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
- Addresses", RFC 3879, September 2004.
-
-
- [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
- Guidelines", BCP 91, RFC 3901, September 2004.
-
-
-11.2 Informative References
-
-
- [I-D.durand-v6ops-natpt-dns-alg-issues]
- Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
- draft-durand-v6ops-natpt-dns-alg-issues-00 (work in
- progress), February 2003.
-
-
- [I-D.huitema-v6ops-teredo]
- Huitema, C., "Teredo: Tunneling IPv6 over UDP through
- NATs", draft-huitema-v6ops-teredo-02 (work in progress),
- June 2004.
-
-
- [I-D.huston-6to4-reverse-dns]
- Huston, G., "6to4 Reverse DNS Delegation",
- draft-huston-6to4-reverse-dns-03 (work in progress),
- October 2004.
-
-
- [I-D.ietf-dhc-ddns-resolution]
- Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
- Clients", draft-ietf-dhc-ddns-resolution-08 (work in
- progress), October 2004.
-
-
- [I-D.ietf-dhc-fqdn-option]
- Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
- draft-ietf-dhc-fqdn-option-07 (work in progress), July
- 2004.
-
-
- [I-D.ietf-dnsext-dhcid-rr]
- Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for
- encoding DHCP information (DHCID RR)",
- draft-ietf-dnsext-dhcid-rr-08 (work in progress), July
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 26]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- 2004.
-
-
- [I-D.ietf-dnsop-bad-dns-res]
- Larson, M. and P. Barber, "Observed DNS Resolution
- Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in
- progress), July 2004.
-
-
- [I-D.ietf-dnsop-dontpublish-unreachable]
- Hazel, P., "IP Addresses that should never appear in the
- public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
- (work in progress), February 2002.
-
-
- [I-D.ietf-dnsop-inaddr-required]
- Senie, D., "Requiring DNS IN-ADDR Mapping",
- draft-ietf-dnsop-inaddr-required-05 (work in progress),
- April 2004.
-
-
- [I-D.ietf-ipseckey-rr]
- Richardson, M., "A method for storing IPsec keying
- material in DNS", draft-ietf-ipseckey-rr-11 (work in
- progress), July 2004.
-
-
- [I-D.ietf-ipv6-unique-local-addr]
- Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
- Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in
- progress), September 2004.
-
-
- [I-D.ietf-send-cga]
- Aura, T., "Cryptographically Generated Addresses (CGA)",
- draft-ietf-send-cga-06 (work in progress), April 2004.
-
-
- [I-D.ietf-v6ops-3gpp-analysis]
- Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
- Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
- progress), May 2004.
-
-
- [I-D.ietf-v6ops-mech-v2]
- Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
- for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06
- (work in progress), September 2004.
-
-
- [I-D.ietf-v6ops-onlinkassumption]
- Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
- On-Link Assumption Considered Harmful",
- draft-ietf-v6ops-onlinkassumption-02 (work in progress),
- May 2004.
-
-
- [I-D.ietf-v6ops-v6onbydefault]
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 27]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack
- IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
- (work in progress), July 2004.
-
-
- [I-D.jeong-dnsop-ipv6-dns-discovery]
- Jeong, J., "IPv6 DNS Discovery based on Router
- Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02
- (work in progress), July 2004.
-
-
- [I-D.moore-6to4-dns]
- Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
- in progress), October 2002.
-
-
- [I-D.ohta-preconfigured-dns]
- Ohta, M., "Preconfigured DNS Server Addresses",
- draft-ohta-preconfigured-dns-01 (work in progress),
- February 2004.
-
-
- [I-D.savola-v6ops-6bone-mess]
- Savola, P., "Moving from 6bone to IPv6 Internet",
- draft-savola-v6ops-6bone-mess-01 (work in progress),
- November 2002.
-
-
- [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
- Translation - Protocol Translation (NAT-PT)", RFC 2766,
- February 2000.
-
-
- [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
-
- [RFC2826] Internet Architecture Board, "IAB Technical Comment on the
- Unique DNS Root", RFC 2826, May 2000.
-
-
- [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
- Networks", BCP 84, RFC 3704, March 2004.
-
-
-
-Authors' Addresses
-
-
- Alain Durand
- SUN Microsystems, Inc.
- 17 Network circle UMPL17-202
- Menlo Park, CA 94025
- USA
-
-
- EMail: Alain.Durand@sun.com
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 28]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
- Johan Ihren
- Autonomica
- Bellmansgatan 30
- SE-118 47 Stockholm
- Sweden
-
-
- EMail: johani@autonomica.se
-
-
-
- Pekka Savola
- CSC/FUNET
- Espoo
- Finland
-
-
- EMail: psavola@funet.fi
-
-
-Appendix A. Site-local Addressing Considerations for DNS
-
-
- As site-local addressing has been deprecated, the considerations for
- site-local addressing are discussed briefly here. Unique local
- addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed
- as a replacement, but being work-in-progress, it is not considered
- further.
-
-
- The interactions with DNS come in two flavors: forward and reverse
- DNS.
-
-
- To actually use site-local addresses within a site, this implies the
- deployment of a "split-faced" or a fragmented DNS name space, for the
- zones internal to the site, and the outsiders' view to it. The
- procedures to achieve this are not elaborated here. The implication
- is that site-local addresses must not be published in the public DNS.
-
-
- To faciliate reverse DNS (if desired) with site-local addresses, the
- stub resolvers must look for DNS information from the local DNS
- servers, not e.g. starting from the root servers, so that the
- site-local information may be provided locally. Note that the
- experience of private addresses in IPv4 has shown that the root
- servers get loaded for requests for private address lookups in any
- case.
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 29]
-Internet-Draft Considerations and Issues with IPv6 DNS October 2004
-
-
-
-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 (2004). 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.
-
-
-
-
-
-Durand, et al. Expires April 24, 2005 [Page 30]
\ No newline at end of file
+++ /dev/null
- DNSOP Working Group Paul Vixie, ISC (Ed.)
- INTERNET-DRAFT Akira Kato, WIDE
- <draft-ietf-dnsop-respsize-01.txt> July, 2004
-
-
- DNS Response Size Issues
-
-
- Status of this Memo
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which we are aware have been or will be disclosed, and any of which
- we become aware will be disclosed, in accordance with RFC 3668.
-
-
- 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.
-
-
- Copyright Notice
-
-
- Copyright (C) The Internet Society (2003-2004). All Rights Reserved.
-
-
-
-
-
- Abstract
-
-
- With a mandated default minimum maximum message size of 512 octets,
- the DNS protocol presents some special problems for zones wishing to
- expose a moderate or high number of authority servers (NS RRs). This
- document explains the operational issues caused by, or related to
- this response size limit.
-
-
-
-
-
-
- Expires December 2004 [Page 1]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- 1 - Introduction and Overview
-
-
- 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
- octets. Even though this limitation was due to the required minimum UDP
- reassembly limit for IPv4, it is a hard DNS protocol limit and is not
- implicitly relaxed by changes in transport, for example to IPv6.
-
-
- 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
- responses by mutual agreement of the requestor and responder. However,
- deployment of EDNS0 cannot be expected to reach every Internet resolver
- in the short or medium term. The 512 octet message size limit remains
- in practical effect at this time.
-
-
- 1.3. Since DNS responses include a copy of the request, the space
- available for response data is somewhat less than the full 512 octets.
- For negative responses, there is rarely a space constraint. For
- positive and delegation responses, though, every octet must be carefully
- and sparingly allocated. This document specifically addresses
- delegation response sizes.
-
-
- 2 - Delegation Details
-
-
- 2.1. A delegation response will include the following elements:
-
-
- Header Section: fixed length (12 octets)
- Question Section: original query (name, class, type)
- Answer Section: (empty)
- Authority Section: NS RRset (nameserver names)
- Additional Section: A and AAAA RRsets (nameserver addresses)
-
-
- 2.2. If the total response size would exceed 512 octets, and if the data
- that would not fit was in the question, answer, or authority section,
- then the TC bit will be set (indicating truncation) which may cause the
- requestor to retry using TCP, depending on what information was present
- and what was omitted. If a retry using TCP is needed, the total cost of
- the transaction is much higher.
-
-
- 2.3. RRsets are never sent partially, so if truncation occurs, entire
- RRsets are omitted. Note that the authority section consists of a
- single RRset. It is absolutely essential that truncation not occur in
- the authority section.
-
-
-
-
-
-
-
-
- Expires December 2004 [Page 2]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- 2.4. DNS label compression allows a domain name to be instantiated only
- once per DNS message, and then referenced with a two-octet "pointer"
- from other locations in that same DNS message. If all nameserver names
- in a message are similar (for example, all ending in ".ROOT-
- SERVERS.NET"), then more space will be available for uncompressable data
- (such as nameserver addresses).
-
-
- 2.5. The query name can be as long as 255 characters of presentation
- data, which can be up to 256 octets of network data. In this worst case
- scenario, the question section will be 260 octets in size, which would
- leave only 240 octets for the authority and additional sections (after
- deducting 12 octets for the fixed length header.)
-
-
- 2.6. Average and maximum question section sizes can be predicted by the
- zone owner, since they will know what names actually exist, and can
- measure which ones are queried for most often. For cost and performance
- reasons, the majority of requests should be satisfied without truncation
- or TCP retry.
-
-
- 2.7. Requestors who deliberately send large queries to force truncation
- are only increasing their own costs, and cannot effectively attack the
- resources of an authority server since the requestor would have to retry
- using TCP to complete the attack. An attack that always used TCP would
- have a lower cost.
-
-
- 2.8. The minimum useful number of address records is two, since with
- only one address, the probability that it would refer to an unreachable
- server is too high. Truncation which occurs after two address records
- have been added to the additional data section is therefore less
- operationally significant than truncation which occurs earlier.
-
-
- 2.9. The best case is no truncation. (This is because many requestors
- will retry using TCP by reflex, without considering whether the omitted
- data was actually necessary.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires December 2004 [Page 3]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- 3 - Analysis
-
-
- 3.1. An instrumented protocol trace of a best case delegation response
- follows. Note that 13 servers are named, and 13 addresses are given.
- This query was artificially designed to exactly reach the 512 octet
- limit.
-
-
- ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
- ;; QUERY SECTION:
- ;; [23456789.123456789.123456789.\
- 123456789.123456789.123456789.com A IN] ;; @80
-
-
- ;; AUTHORITY SECTION:
- com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
- com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
- com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
- com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
- com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
- com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
- com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
- com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
- com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
- com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
- com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
- com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
- com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
-
-
- ;; ADDITIONAL SECTION:
- A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
- B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
- C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
- D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
- E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
- F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
- G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
- H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
- I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
- J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
- K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
- L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
- M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
-
-
- ;; MSG SIZE sent: 80 rcvd: 512
-
-
-
-
-
-
- Expires December 2004 [Page 4]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- 3.2. For longer query names, the number of address records supplied will
- be lower. Furthermore, it is only by using a common parent name (which
- is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
- fit. The following output from a response simulator demonstrates these
- properties:
-
-
- % perl respsize.pl 13 13 0
- common name, average case: msg:303 nsaddr#13 (green)
- common name, worst case: msg:495 nsaddr# 1 (red)
- uncommon name, average case: msg:457 nsaddr# 3 (orange)
- uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
- % perl respsize.pl 13 13 2
- common name, average case: msg:303 nsaddr#11 (orange)
- common name, worst case: msg:495 nsaddr# 1 (red)
- uncommon name, average case: msg:457 nsaddr# 2 (orange)
- uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
-
-
- (Note: The response simulator program is shown in Section 5.)
-
-
- Here we use the term "green" if all address records could fit, or
- "orange" if two or more could fit, or "red" if fewer than two could fit.
- It's clear that without a common parent for nameserver names, much space
- would be lost.
-
-
- We're assuming an average query name size of 64 since that is the
- typical average maximum size seen in trace data at the time of this
- writing. If Internationalized Domain Name (IDN) or any other technology
- which results in larger query names be deployed significantly in advance
- of EDNS, then more new measurements and new estimates will have to be
- made.
-
-
- 4 - Conclusions
-
-
- 4.1. The current practice of giving all nameserver names a common parent
- (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
- responses and allows for more nameservers to be enumerated than would
- otherwise be possible. (Note that in this case it is wise to serve the
- common parent domain's zone from the same servers that are named within
- it, in order to limit external dependencies when all your eggs are in a
- single basket.)
-
-
- 4.2. Thirteen (13) seems to be the effective maximum number of
- nameserver names usable traditional (non-extended) DNS, assuming a
- common parent domain name, and assuming that additional-data truncation
- is undesirable in the average case.
-
-
-
-
- Expires December 2004 [Page 5]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
- prototypical delegation that currently contains thirteen (13) IPv4
- nameserver addresses (A RRs) for thirteen (13) nameserver names under a
- common parent, would not have a significant negative operational impact
- on the domain name system.
-
-
- 5 - Source Code
-
-
- #!/usr/bin/perl -w
-
-
- $asize = 2+2+2+4+2+4;
- $aaaasize = 2+2+2+4+2+16;
- ($nns, $na, $naaaa) = @ARGV;
- test("common", "average", common_name_average($nns),
- $na, $naaaa);
- test("common", "worst", common_name_worst($nns),
- $na, $naaaa);
- test("uncommon", "average", uncommon_name_average($nns),
- $na, $naaaa);
- test("uncommon", "worst", uncommon_name_worst($nns),
- $na, $naaaa);
- exit 0;
-
-
- sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_;
- my $nglue = numglue($msg, $na, $naaaa);
- printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n",
- $namekind, $casekind,
- $msg, ($msg > 512) ? "(*)" : " ",
- $nglue, ($nglue == $na + $naaaa) ? "green"
- : ($nglue >= 2) ? "orange"
- : "red";
- }
-
-
- sub pnum { my ($num, $tot) = @_;
- return sprintf "%3d%s",
- }
-
-
- sub numglue { my ($msg, $na, $naaaa) = @_;
- my $space = ($msg > 512) ? 0 : (512 - $msg);
- my $num = 0;
-
-
- while ($space && ($na || $naaaa )) {
- if ($na) {
- if ($space >= $asize) {
- $space -= $asize;
-
-
-
-
- Expires December 2004 [Page 6]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- $num++;
- }
- $na--;
- }
- if ($naaaa) {
- if ($space >= $aaaasize) {
- $space -= $aaaasize;
- $num++;
- }
- $naaaa--;
- }
- }
- return $num;
- }
-
-
- sub msgsize { my ($qname, $nns, $nsns) = @_;
- return 12 + # header
- $qname+2+2 + # query
- 0 + # answer
- $nns * (4+2+2+4+2+$nsns); # authority
- }
-
-
- sub average_case { my ($nns, $nsns) = @_;
- return msgsize(64, $nns, $nsns);
- }
-
-
- sub worst_case { my ($nns, $nsns) = @_;
- return msgsize(256, $nns, $nsns);
- }
-
-
- sub common_name_average { my ($nns) = @_;
- return 15 + average_case($nns, 2);
- }
-
-
- sub common_name_worst { my ($nns) = @_;
- return 15 + worst_case($nns, 2);
- }
-
-
- sub uncommon_name_average { my ($nns) = @_;
- return average_case($nns, 15);
- }
-
-
- sub uncommon_name_worst { my ($nns) = @_;
- return worst_case($nns, 15);
- }
-
-
-
-
- Expires December 2004 [Page 7]
- INTERNET-DRAFT June 2003 RESPSIZE
-
-
-
- Security Considerations
-
-
- The recommendations contained in this document have no known security
- implications.
-
-
- IANA Considerations
-
-
- This document does not call for changes or additions to any IANA
- registry.
-
-
- IPR Statement
-
-
- Copyright (C) The Internet Society (2003-2004). 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.
-
-
- 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.
-
-
- Authors' Addresses
-
-
- Paul Vixie
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 423 1301
- vixie@isc.org
-
-
- Akira Kato
- University of Tokyo, Information Technology Center
- 2-11-16 Yayoi Bunkyo
- Tokyo 113-8658, JAPAN
- +81 3 5841 2750
- kato@wide.ad.jp
-
-
-
-
-
-
-
-
-
-
- Expires December 2004 [Page 8]
\ No newline at end of file
+++ /dev/null
-
-
-Network Working Group S. Woolf
-Internet-Draft Internet Systems Consortium, Inc.
-Expires: January 16, 2005 D. Conrad
- Nominum, Inc.
- July 18, 2004
-
-
- Identifying an Authoritative Name `Server
- draft-ietf-dnsop-serverid-02
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
- RFC 3668.
-
- 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 January 16, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- With the increased use of DNS anycast, load balancing, and other
- mechanisms allowing more than one DNS name server to share a single
- IP address, it is sometimes difficult to tell which of a pool of name
- servers has answered a particular query. A standardized mechanism to
- determine the identity of a name server responding to a particular
- query would be useful, particularly as a diagnostic aid. Existing ad
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 1]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
- hoc mechanisms for addressing this concern are not adequate. This
- document attempts to describe the common ad hoc solution to this
- problem, including its advantages and disadvantasges, and to
- characterize an improved mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 2]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-1. Introduction
-
- With the increased use of DNS anycast, load balancing, and other
- mechanisms allowing more than one DNS name server to share a single
- IP address, it is sometimes difficult to tell which of a pool of name
- servers has answered a particular query. A standardized mechanism to
- determine the identity of a name server responding to a particular
- query would be useful, particularly as a diagnostic aid.
-
- Unfortunately, existing ad-hoc mechanisms for providing such
- identification have some shortcomings, not the least of which is the
- lack of prior analysis of exactly how such a mechanism should be
- designed and deployed. This document describes the existing
- convention used in one widely deployed implementation of the DNS
- protocol and discusses requirements for an improved solution to the
- problem.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 3]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-2. Rationale
-
- Identifying which name server is responding to queries is often
- useful, particularly in attempting to diagnose name server
- difficulties. However, relying on the IP address of the name server
- has become more problematic due the deployment of various load
- balancing solutions, including the use of shared unicast addresses as
- documented in [RFC3258].
-
- An unfortunate side effect of these load balancing solutions is that
- traditional methods of determining which server is responding can be
- unreliable. Specifically, non-DNS methods such as ICMP ping, TCP
- connections, or non-DNS UDP packets (e.g., as generated by tools such
- as "traceroute"), etc., can end up going to a different server than
- that which receives the DNS queries.
-
- The widespread use of the existing convention suggests a need for a
- documented, interoperable means of querying the identity of a
- nameserver that may be part of an anycast or load-balancing cluster.
- At the same time, however, it also has some drawbacks that argue
- against standardizing it as it's been practiced so far.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 4]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-3. Existing Conventions
-
- Recent versions of the commonly deployed Berkeley Internet Name
- Domain implementation of the DNS protocol suite from the Internet
- Software Consortium [BIND] support a way of identifying a particular
- server via the use of a standard, if somewhat unusual, DNS query.
- Specifically, a query to a late model BIND server for a TXT resource
- record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
- return a string that can be configured by the name server
- administrator to provide a unique identifier for the responding
- server (defaulting to the value of a gethostname() call). This
- mechanism, which is an extension of the BIND convention of using
- CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
- version information, has been copied by several name server vendors.
-
- For reference, the other well-known name used by recent versions of
- BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
- query for a TXT RR for this name will return an administratively re-
- definable string which defaults to the version of the server
- responding.
-
-3.1 Advantages
-
- There are several valuable attributes to this mechanism, which
- account for its usefulness.
- 1. This mechanism is within the DNS protocol itself. An
- identification mechanism that relies on the DNS protocol is more
- likely to be successful (although not guaranteed) in going to the
- same machine as a "normal" DNS query.
- 2. It is simple to configure. An administrator can easily turn on
- this feature and control the results of the relevant query.
- 3. It allows the administrator complete control of what information
- is given out in the response, minimizing passive leakage of
- implementation or configuration details. Such details are often
- considered sensitive by infrastructure operators.
-
-3.2 Disadvantages
-
- At the same time, there are some forbidding drawbacks to the
- VERSION.BIND mechanism that argue against standardizing it as it
- currently operates.
- 1. It requires an additional query to correlate between the answer
- to a DNS query under normal conditions and the supposed identity
- of the server receiving the query. There are a number of
- situations in which this simply isn't reliable.
- 2. It reserves an entire class in the DNS (CHAOS) for what amounts
- to one zone. While CHAOS class is defined in [RFC1034] and
- [RFC1035], it's not clear that supporting it solely for this
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 5]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
- purpose is a good use of the namespace or of implementation
- effort.
- 3. It is implementation specific. BIND is one DNS implementation.
- At the time of this writing, it is probably the most prevalent,
- for authoritative servers anyway. This does not justify
- standardizing on its ad hoc solution to a problem shared across
- many operators and implementors.
-
- The first of the listed disadvantages is technically the most
- serious. It argues for an attempt to design a good answer to the
- problem that "I need to know what nameserver is answering my
- queries", not simply a convenient one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 6]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-4. Characteristics of an Implementation Neutral Convention
-
- The discussion above of advantages and disadvantages to the
- HOSTNAME.BIND mechanism suggest some requirements for a better
- solution to the server identification problem. These are summarized
- here as guidelines for any effort to provide appropriate protocol
- extensions:
- 1. The mechanism adopted MUST be in-band for the DNS protocol. That
- is, it needs to allow the query for the server's identifying
- information to be part of a normal, operational query. It SHOULD
- also permit a separate, dedicated query for the server's
- identifying information.
- 2. The new mechanism should not require dedicated namespaces or
- other reserved values outside of the existing protocol mechanisms
- for these, i.e. the OPT pseudo-RR.
- 3. Support for the identification functionality SHOULD be easy to
- implement and easy to enable. It MUST be easy to disable and
- SHOULD lend itself to access controls on who can query for it.
- 4. It should be possible to return a unique identifier for a server
- without requiring the exposure of information that may be
- non-public and considered sensitive by the operator, such as a
- hostname or unicast IP address maintained for administrative
- purposes.
- 5. The identification mechanism SHOULD NOT be
- implementation-specific.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 7]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-5. IANA Considerations
-
- This document proposes no specific IANA action. Protocol extensions,
- if any, to meet the requirements described are out of scope for this
- document. Should such extensions be specified and adopted by normal
- IETF process, the specification will include appropriate guidance to
- IANA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 8]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-6. Security Considerations
-
- Providing identifying information as to which server is responding
- can be seen as information leakage and thus a security risk. This
- motivates the suggestion above that a new mechanism for server
- identification allow the administrator to disable the functionality
- altogether or partially restrict availability of the data. It also
- suggests that the serverid data should not be readily correlated with
- a hostname or unicast IP address that may be considered private to
- the nameserver operator's management infrastructure.
-
- Propagation of protocol or service meta-data can sometimes expose the
- application to denial of service or other attack. As DNS is a
- critically important infrastructure service for the production
- Internet, extra care needs to be taken against this risk for
- designers, implementors, and operators of a new mechanism for server
- identification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 9]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-7. Acknowledgements
-
- The technique for host identification documented here was initially
- implemented by Paul Vixie of the Internet Software Consortium in the
- Berkeley Internet Name Daemon package. Comments and questions on
- earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
- Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
- ICANN Root Server System Advisory Committee. The newest draft takes
- a significantly different direction from previous versions, owing to
- discussion among contributors to the DNSOP working group and others,
- particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler,
- and Rob Austein.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 10]
-\f
-Internet-Draft Identifying an Authoritative Name `Server July 2004
-
-
-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 (2004). 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.
-
-
-
-
-Woolf & Conrad Expires January 16, 2005 [Page 11]
-\f
-
projects / thirdparty / bind9.git / commitdiff
