+++ /dev/null
-
-
-
-DNSEXT D. Blacka
-Internet-Draft VeriSign, Inc.
-Intended status: Standards Track April 7, 2006
-Expires: October 9, 2006
-
-
- DNSSEC Experiments
- draft-ietf-dnsext-dnssec-experiments-03
-
-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 October 9, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 1]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Abstract
-
- This document describes a methodology for deploying alternate, non-
- backwards-compatible, DNSSEC methodologies in an experimental fashion
- without disrupting the deployment of standard DNSSEC.
-
-
-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. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
- 10.2. Informative References . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 2]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system (RFC 1035
- [5]) and the DNS security extensions ([2], [3], and [4] is assumed.
-
- 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].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 3]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-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 (bad) or otherwise broken to existing security-
- aware resolvers.
-
- This document describes a standard methodology for setting up 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
- security-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 4]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-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 servers that do implement the
- DNSSEC standard.
-
- Non-Backwards-Compatible: describes experiments that would cause a
- standard security-aware resolver to (incorrectly) determine that
- all or part of a zone is bogus, or to otherwise not interoperate
- 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 may be used
- if desired.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 5]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-4. Method
-
- The core of the methodology is the use of strictly unknown algorithm
- identifiers when signing the experimental zone, and more importantly,
- having only unknown algorithm identifiers in the 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
- algorithm identifiers. From [4], 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 likely that a validator would implement this behavior, or, more to
- the point, it would handle this situation in a safe way (see below
- (Section 6).)
-
- Because we are talking about experiments, it is RECOMMENDED that
- private algorithm numbers be used (see [3], appendix A.1.1. Note
- that secure handling of private algorithms requires special handing
- by the validator logic. See [6] for further details.) 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, it is suggested 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
-
-
-
-Blacka Expires October 9, 2006 [Page 6]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
- will suffice.
-
- Using this method, resolvers (or, more specifically, 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 security-aware servers and
- resolvers: servers and resolvers that are aware of the experiment
- (and thus recognize the experiment's algorithm identifiers and
- experimental semantics), and servers and resolvers that are unaware
- of the experiment.
-
- This method also precludes any zone from being both in an experiment
- and in a classic DNSSEC island of security. That is, a zone is
- either in an experiment and only experimentally validatable, or it is
- not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 7]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-5. Defining an Experiment
-
- The DNSSEC experiment MUST define the particular set of (previously
- unknown) algorithm identifiers 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.
-
- Normally 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.
-
- For example, an experiment might specify in its description the DNS
- name "dnssec-experiment-a.example.com" as the base name, and declare
- that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
- algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
- alias of DNSSEC algorithm 5 (RSASHA1).
-
- Resolvers MUST only recognize the experiment's semantics when present
- in a zone signed by one or more of these algorithm identifiers. This
- is necessary to isolate the semantics of one experiment from any
- others that the resolver might understand.
-
- In general, resolvers involved in the experiment are expected to
- understand both standard DNSSEC and the defined experimental DNSSEC
- protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 8]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-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 a non-validatable response and conclude
- that the response is bogus, either due to local policy or
- implementation details. This is not expected to be a common
- case, however.
-
- 2. It will not be possible for security-aware resolvers unaware of
- the experiment to build a chain of trust through an experimental
- zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 9]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-7. Use in Non-Experiments
-
- This general methodology MAY be used for non-backwards compatible
- DNSSEC protocol changes that start out as or become standards. In
- this case:
-
- o The protocol change SHOULD use public IANA allocated algorithm
- identifiers instead of private algorithm identifiers. This will
- help identify the protocol change as a standard, rather than an
- experiment.
-
- o Resolvers MAY recognize the protocol change in zones not signed
- (or not solely signed) using the new algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 10]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-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 October 9, 2006 [Page 11]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-9. IANA Considerations
-
- This document has no IANA actions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 12]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-10. References
-
-10.1. Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
-10.2. Informative References
-
- [5] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [6] Austein, R. and S. Weiler, "Clarifications and Implementation
- Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
- (work in progress), January 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 13]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-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 October 9, 2006 [Page 14]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- 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.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 15]
-\f
+++ /dev/null
-
-
-
-Network Working Group S. Weiler
-Internet-Draft SPARTA, Inc
-Updates: 4034, 4035 (if approved) J. Ihren
-Expires: July 24, 2006 Autonomica AB
- January 20, 2006
-
-
- Minimally Covering NSEC Records and DNSSEC On-line Signing
- draft-ietf-dnsext-dnssec-online-signing-02
-
-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 July 24, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes how to construct DNSSEC NSEC resource records
- that cover a smaller range of names than called for by RFC4034. By
- generating and signing these records on demand, authoritative name
- servers can effectively stop the disclosure of zone contents
- otherwise made possible by walking the chain of NSEC records in a
- signed zone.
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 1]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
-Changes from ietf-01 to ietf-02
-
- Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
- and NSEC bits set, to be consistent with DNSSECbis -- previous text
- said SHOULD.
-
- Made the applicability statement a little less oppressive.
-
-Changes from ietf-00 to ietf-01
-
- Added an applicability statement, making reference to ongoing work on
- NSEC3.
-
- Added the phrase "epsilon functions", which has been commonly used to
- describe the technique and already appeared in the header of each
- page, in place of "increment and decrement functions". Also added an
- explanatory sentence.
-
- Corrected references from 4034 section 6.2 to section 6.1.
-
- Fixed an out-of-date reference to [-bis] and other typos.
-
- Replaced IANA Considerations text.
-
- Escaped close parentheses in examples.
-
- Added some more acknowledgements.
-
-Changes from weiler-01 to ietf-00
-
- Inserted RFC numbers for 4033, 4034, and 4035.
-
- Specified contents of bitmap field in synthesized NSEC RR's, pointing
- out that this relaxes a constraint in 4035. Added 4035 to the
- Updates header.
-
-Changes from weiler-00 to weiler-01
-
- Clarified that this updates RFC4034 by relaxing requirements on the
- next name field.
-
- Added examples covering wildcard names.
-
- In the 'better functions' section, reiterated that perfect functions
- aren't needed.
-
- Added a reference to RFC 2119.
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 2]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
-Table of Contents
-
- 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
- 2. Applicability of This Technique . . . . . . . . . . . . . . . 4
- 3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5
- 4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
- 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
- Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
- Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 3]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
-1. Introduction and Terminology
-
- With DNSSEC [1], an NSEC record lists the next instantiated name in
- its zone, proving that no names exist in the "span" between the
- NSEC's owner name and the name in the "next name" field. In this
- document, an NSEC record is said to "cover" the names between its
- owner name and next name.
-
- Through repeated queries that return NSEC records, it is possible to
- retrieve all of the names in the zone, a process commonly called
- "walking" the zone. Some zone owners have policies forbidding zone
- transfers by arbitrary clients; this side-effect of the NSEC
- architecture subverts those policies.
-
- This document presents a way to prevent zone walking by constructing
- NSEC records that cover fewer names. These records can make zone
- walking take approximately as many queries as simply asking for all
- possible names in a zone, making zone walking impractical. Some of
- these records must be created and signed on demand, which requires
- on-line private keys. Anyone contemplating use of this technique is
- strongly encouraged to review the discussion of the risks of on-line
- signing in Section 6.
-
- 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 [4].
-
-
-2. Applicability of This Technique
-
- The technique presented here may be useful to a zone owner that wants
- to use DNSSEC, is concerned about exposure of its zone contents via
- zone walking, and is willing to bear the costs of on-line signing.
-
- As discussed in Section 6, on-line signing has several security
- risks, including an increased likelihood of private keys being
- disclosed and an increased risk of denial of service attack. Anyone
- contemplating use of this technique is strongly encouraged to review
- the discussion of the risks of on-line signing in Section 6.
-
- Furthermore, at the time this document was published, the DNSEXT
- working group was actively working on a mechanism to prevent zone
- walking that does not require on-line signing (tentatively called
- NSEC3). The new mechanism is likely to expose slightly more
- information about the zone than this technique (e.g. the number of
- instantiated names), but it may be preferable to this technique.
-
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 4]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
-3. Minimally Covering NSEC Records
-
- This mechanism involves changes to NSEC records for instantiated
- names, which can still be generated and signed in advance, as well as
- the on-demand generation and signing of new NSEC records whenever a
- name must be proven not to exist.
-
- In the 'next name' field of instantiated names' NSEC records, rather
- than list the next instantiated name in the zone, list any name that
- falls lexically after the NSEC's owner name and before the next
- instantiated name in the zone, according to the ordering function in
- RFC4034 [2] section 6.1. This relaxes the requirement in section
- 4.1.1 of RFC4034 that the 'next name' field contains the next owner
- name in the zone. This change is expected to be fully compatible
- with all existing DNSSEC validators. These NSEC records are returned
- whenever proving something specifically about the owner name (e.g.
- that no resource records of a given type appear at that name).
-
- Whenever an NSEC record is needed to prove the non-existence of a
- name, a new NSEC record is dynamically produced and signed. The new
- NSEC record has an owner name lexically before the QNAME but
- lexically following any existing name and a 'next name' lexically
- following the QNAME but before any existing name.
-
- The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
- bits set and SHOULD NOT have any other bits set. This relaxes the
- requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
- names that did not exist before the zone was signed.
-
- The functions to generate the lexically following and proceeding
- names need not be perfect nor consistent, but the generated NSEC
- records must not cover any existing names. Furthermore, this
- technique works best when the generated NSEC records cover as few
- names as possible. In this document, the functions that generate the
- nearby names are called 'epsilon' functions, a reference to the
- mathematical convention of using the greek letter epsilon to
- represent small deviations.
-
- An NSEC record denying the existence of a wildcard may be generated
- in the same way. Since the NSEC record covering a non-existent
- wildcard is likely to be used in response to many queries,
- authoritative name servers using the techniques described here may
- want to pregenerate or cache that record and its corresponding RRSIG.
-
- For example, a query for an A record at the non-instantiated name
- example.com might produce the following two NSEC records, the first
- denying the existence of the name example.com and the second denying
- the existence of a wildcard:
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 5]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
- exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
-
- \).com 3600 IN NSEC +.com ( RRSIG NSEC )
-
- Before answering a query with these records, an authoritative server
- must test for the existence of names between these endpoints. If the
- generated NSEC would cover existing names (e.g. exampldd.com or
- *bizarre.example.com), a better epsilon function may be used or the
- covered name closest to the QNAME could be used as the NSEC owner
- name or next name, as appropriate. If an existing name is used as
- the NSEC owner name, that name's real NSEC record MUST be returned.
- Using the same example, assuming an exampldd.com delegation exists,
- this record might be returned from the parent:
-
- exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
-
- Like every authoritative record in the zone, each generated NSEC
- record MUST have corresponding RRSIGs generated using each algorithm
- (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
- described in RFC4035 [3] section 2.2. To minimize the number of
- signatures that must be generated, a zone may wish to limit the
- number of algorithms in its DNSKEY RRset.
-
-
-4. Better Epsilon Functions
-
- Section 6.1 of RFC4034 defines a strict ordering of DNS names.
- Working backwards from that definition, it should be possible to
- define epsilon functions that generate the immediately following and
- preceding names, respectively. This document does not define such
- functions. Instead, this section presents functions that come
- reasonably close to the perfect ones. As described above, an
- authoritative server should still ensure than no generated NSEC
- covers any existing name.
-
- To increment a name, add a leading label with a single null (zero-
- value) octet.
-
- To decrement a name, decrement the last character of the leftmost
- label, then fill that label to a length of 63 octets with octets of
- value 255. To decrement a null (zero-value) octet, remove the octet
- -- if an empty label is left, remove the label. Defining this
- function numerically: fill the left-most label to its maximum length
- with zeros (numeric, not ASCII zeros) and subtract one.
-
- In response to a query for the non-existent name foo.example.com,
- these functions produce NSEC records of:
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 6]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
- fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
-
- \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
-
- The first of these NSEC RRs proves that no exact match for
- foo.example.com exists, and the second proves that there is no
- wildcard in example.com.
-
- Both of these functions are imperfect: they don't take into account
- constraints on number of labels in a name nor total length of a name.
- As noted in the previous section, though, this technique does not
- depend on the use of perfect epsilon functions: it is sufficient to
- test whether any instantiated names fall into the span covered by the
- generated NSEC and, if so, substitute those instantiated owner names
- for the NSEC owner name or next name, as appropriate.
-
-
-5. IANA Considerations
-
- This document specifies no IANA Actions.
-
-
-6. Security Considerations
-
- This approach requires on-demand generation of RRSIG records. This
- creates several new vulnerabilities.
-
- First, on-demand signing requires that a zone's authoritative servers
- have access to its private keys. Storing private keys on well-known
- internet-accessible servers may make them more vulnerable to
- unintended disclosure.
-
- Second, since generation of digital signatures tends to be
- computationally demanding, the requirement for on-demand signing
- makes authoritative servers vulnerable to a denial of service attack.
-
- Lastly, if the epsilon functions are predictable, on-demand signing
- may enable a chosen-plaintext attack on a zone's private keys. Zones
- using this approach should attempt to use cryptographic algorithms
- that are resistant to chosen-plaintext attacks. It's worth noting
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 7]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
- that while DNSSEC has a "mandatory to implement" algorithm, that is a
- requirement on resolvers and validators -- there is no requirement
- that a zone be signed with any given algorithm.
-
- The success of using minimally covering NSEC record to prevent zone
- walking depends greatly on the quality of the epsilon functions
- chosen. An increment function that chooses a name obviously derived
- from the next instantiated name may be easily reverse engineered,
- destroying the value of this technique. An increment function that
- always returns a name close to the next instantiated name is likewise
- a poor choice. Good choices of epsilon functions are the ones that
- produce the immediately following and preceding names, respectively,
- though zone administrators may wish to use less perfect functions
- that return more human-friendly names than the functions described in
- Section 4 above.
-
- Another obvious but misguided concern is the danger from synthesized
- NSEC records being replayed. It's possible for an attacker to replay
- an old but still validly signed NSEC record after a new name has been
- added in the span covered by that NSEC, incorrectly proving that
- there is no record at that name. This danger exists with DNSSEC as
- defined in [3]. The techniques described here actually decrease the
- danger, since the span covered by any NSEC record is smaller than
- before. Choosing better epsilon functions will further reduce this
- danger.
-
-7. Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-
-Appendix A. Acknowledgments
-
- Many individuals contributed to this design. They include, in
- addition to the authors of this document, Olaf Kolkman, Ed Lewis,
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 8]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
- Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
- Jakob Schlyter, Bill Manning, and Joao Damas.
-
- In addition, the editors would like to thank Ed Lewis, Scott Rose,
- and David Blacka for their careful review of the document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 9]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
-Authors' Addresses
-
- Samuel Weiler
- SPARTA, Inc
- 7075 Samuel Morse Drive
- Columbia, Maryland 21046
- US
-
- Email: weiler@tislabs.com
-
-
- Johan Ihren
- Autonomica AB
- Bellmansgatan 30
- Stockholm SE-118 47
- Sweden
-
- Email: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 10]
-\f
-Internet-Draft NSEC Epsilon January 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 11]
-\f
+++ /dev/null
-
-
-
-Network Working Group W. Hardaker
-Internet-Draft Sparta
-Expires: August 25, 2006 February 21, 2006
-
-
- Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
- draft-ietf-dnsext-ds-sha256-05.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 August 25, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document specifies how to use the SHA-256 digest type in DNS
- Delegation Signer (DS) Resource Records (RRs). DS records, when
- stored in a parent zone, point to key signing DNSKEY key(s) in a
- child zone.
-
-
-
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 1]
-\f
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Implementing the SHA-256 algorithm for DS record support . . . 3
- 2.1. DS record field values . . . . . . . . . . . . . . . . . . 3
- 2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3
- 2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
- 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
- 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
- 6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
- 6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
- Intellectual Property and Copyright Statements . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 2]
-\f
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-1. Introduction
-
- The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
- zones to distribute a cryptographic digest of a child's Key Signing
- Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the
- parent zone's private zone data signing keys for each algorithm in
- use by the parent. Each signature is published in an RRSIG resource
- record, owned by the same domain as the DS RRset and with a type
- covered of DS.
-
- 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].
-
-
-2. Implementing the SHA-256 algorithm for DS record support
-
- This document specifies that the digest type code [XXX: To be
- assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
- [SHA256CODE] for use within DS records. The results of the digest
- algorithm MUST NOT be truncated and the entire 32 byte digest result
- is to be published in the DS record.
-
-2.1. DS record field values
-
- Using the SHA-256 digest algorithm within a DS record will make use
- of the following DS-record fields:
-
- Digest type: [XXX: To be assigned by IANA; likely 2]
-
- Digest: A SHA-256 bit digest value calculated by using the following
- formula ("|" denotes concatenation). The resulting value is not
- truncated and the entire 32 byte result is to used in the
- resulting DS record and related calculations.
-
- digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
-
- where DNSKEY RDATA is defined by [RFC4034] as:
-
- DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
-
- The Key Tag field and Algorithm fields remain unchanged by this
- document and are specified in the [RFC4034] specification.
-
-2.2. DS Record with SHA-256 Wire Format
-
- The resulting on-the-wire format for the resulting DS record will be
- [XXX: IANA assignment should replace the 2 below]:
-
-
-
-Hardaker Expires August 25, 2006 [Page 3]
-\f
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
- 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 Tag | Algorithm | DigestType=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / /
- / Digest (length for SHA-256 is 32 bytes) /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-2.3. Example DS Record Using SHA-256
-
- The following is an example DNSKEY and matching DS record. This
- DNSKEY record comes from the example DNSKEY/DS records found in
- section 5.4 of [RFC4034].
-
- The DNSKEY record:
-
- dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
- fwJr1AYtsmx3TGkJaNXVbfi/
- 2pHm822aJ5iI9BMzNXxeYCmZ
- DRD99WYwYqUSdjMmmAphXdvx
- egXd/M5+X7OrzKBaMbCVdFLU
- Uh6DhweJBjEVv5f2wwjM9Xzc
- nOf+EPbtG9DMBmADjFDc2w/r
- ljwvFw==
- ) ; key id = 60485
-
- The resulting DS record covering the above DNSKEY record using a SHA-
- 256 digest: [RFC Editor: please replace XXX with the assigned digest
- type (likely 2):]
-
- dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
- CEB1E3E0614B93C4F9E99B83
- 83F6A1E4469DA50A )
-
-
-3. Implementation Requirements
-
- Implementations MUST support the use of the SHA-256 algorithm in DS
- RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
- digests if DS RRs with SHA-256 digests are present in the DS RRset.
-
-
-4. Deployment Considerations
-
- If a validator does not support the SHA-256 digest type and no other
- DS RR exists in a zone's DS RRset with a supported digest type, then
-
-
-
-Hardaker Expires August 25, 2006 [Page 4]
-\f
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
- the validator 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 in [RFC4035], section 5.2.
-
- Because zone administrators can not control the deployment speed of
- support for SHA-256 in validators that may be referencing any of
- their zones, zone operators should consider deploying both SHA-1 and
- SHA-256 based DS records. This should be done for every DNSKEY for
- which DS records are being generated. Whether to make use of both
- digest types and for how long is a policy decision that extends
- beyond the scope of this document.
-
-
-5. IANA Considerations
-
- Only one IANA action is required by this document:
-
- The Digest Type to be used for supporting SHA-256 within DS records
- needs to be assigned by IANA. This document requests that the Digest
- Type value of 2 be assigned to the SHA-256 digest algorithm.
-
- At the time of this writing, the current digest types assigned for
- use in DS records are as follows:
-
- VALUE Digest Type Status
- 0 Reserved -
- 1 SHA-1 MANDATORY
- 2 SHA-256 MANDATORY
- 3-255 Unassigned -
-
-
-6. Security Considerations
-
-6.1. Potential Digest Type Downgrade Attacks
-
- A downgrade attack from a stronger digest type to a weaker one is
- possible if all of the following are true:
-
- o A zone includes multiple DS records for a given child's DNSKEY,
- each of which use a different digest type.
-
- o A validator accepts a weaker digest even if a stronger one is
- present but invalid.
-
- For example, if the following conditions are all true:
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 5]
-\f
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
- o Both SHA-1 and SHA-256 based digests are published in DS records
- within a parent zone for a given child zone's DNSKEY.
-
- o The DS record with the SHA-1 digest matches the digest computed
- using the child zone's DNSKEY.
-
- o The DS record with the SHA-256 digest fails to match the digest
- computed using the child zone's DNSKEY.
-
- Then if the validator accepts the above situation as secure then this
- can be used as a downgrade attack since the stronger SHA-256 digest
- is ignored.
-
-6.2. SHA-1 vs SHA-256 Considerations for DS Records
-
- Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
- implementations allow for it. SHA-256 is widely believed to be more
- resilient to attack than SHA-1, and confidence in SHA-1's strength is
- being eroded by recently-announced attacks. Regardless of whether or
- not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
- time of this writing) that SHA-256 is the better choice for use in DS
- records.
-
- At the time of this publication, the SHA-256 digest algorithm is
- considered sufficiently strong for the immediate future. It is also
- considered sufficient for use in DNSSEC DS RRs for the immediate
- future. However, future published attacks may weaken the usability
- of this algorithm within the DS RRs. It is beyond the scope of this
- document to speculate extensively on the cryptographic strength of
- the SHA-256 digest algorithm.
-
- Likewise, it is also beyond the scope of this document to specify
- whether or for how long SHA-1 based DS records should be
- simultaneously published alongside SHA-256 based DS records.
-
-
-7. Acknowledgments
-
- This document is a minor extension to the existing DNSSEC documents
- and those authors are gratefully appreciated for the hard work that
- went into the base documents.
-
- The following people contributed to portions of this document in some
- fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
- Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
- Weiler.
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 6]
-\f
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-8. References
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [SHA256] National Institute of Standards and Technology, "Secure
- Hash Algorithm. NIST FIPS 180-2", August 2002.
-
-8.2. Informative References
-
- [SHA256CODE]
- Eastlake, D., "US Secure Hash Algorithms (SHA)",
- June 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 7]
-\f
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-Author's Address
-
- Wes Hardaker
- Sparta
- P.O. Box 382
- Davis, CA 95617
- US
-
- Email: hardaker@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 8]
-\f
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 9]
-\f
+++ /dev/null
-
-This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted
-from the Internet-Drafts directory. An Internet-Draft expires 185 days from
-the date that it is posted unless it is replaced by an updated version, or the
-Secretariat has been notified that the document is under official review by the
-IESG or has been passed to the RFC Editor for review and/or publication as an
-RFC. This Internet-Draft was not published as an RFC.
-
-Internet-Drafts are not archival documents, and copies of Internet-Drafts that have
-been deleted from the directory are not available. The Secretariat does not have
-any information regarding the future plans of the author(s) or working group, if
-applicable, with respect to this deleted Internet-Draft. For more information, or
-to request a copy of the document, please contact the author(s) directly.
-
-Draft Author(s):
-Remco van Mook <remco@virtu.nl>,
-Bert Hubert <bert.hubert@netherlabs.nl>
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Bernard Aboba
-INTERNET-DRAFT Dave Thaler
-Category: Standards Track Levon Esibov
-<draft-ietf-dnsext-mdns-46.txt> Microsoft Corporation
-16 April 2006
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-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 October 15, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2006.
-
-Abstract
-
- 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.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name Resolution Using LLMNR ........................... 4
- 2.1 LLMNR Packet Format ............................. 5
- 2.2 Sender Behavior ................................. 8
- 2.3 Responder Behavior .............................. 8
- 2.4 Unicast Queries and Responses ................... 11
- 2.5 Off-link Detection .............................. 11
- 2.6 Responder Responsibilities ...................... 12
- 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 ................................... 18
- 4.1 Uniqueness Verification ......................... 18
- 4.2 Conflict Detection and Defense .................. 19
- 4.3 Considerations for Multiple Interfaces .......... 20
- 4.4 API issues ...................................... 22
-5. Security Considerations ............................... 22
- 5.1 Denial of Service ............................... 22
- 5.2 Spoofing ...............,........................ 23
- 5.3 Authentication .................................. 24
- 5.4 Cache and Port Separation ....................... 24
-6. IANA considerations ................................... 25
-7. Constants ............................................. 25
-8. References ............................................ 26
- 8.1 Normative References ............................ 26
- 8.2 Informative References .......................... 26
-Acknowledgments .............................................. 28
-Authors' Addresses ........................................... 28
-Intellectual Property Statement .............................. 29
-Disclaimer of Validity ....................................... 29
-Copyright Statement .......................................... 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which is based on 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.
-
- 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. In such
- networks, if a network has a gateway, then typically 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. IPv4 administratively scoped
- multicast usage is specified in "Administratively Scoped IP
- Multicast" [RFC2365].
-
- 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",
- and "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1.2. Terminology
-
- This document assumes familiarity with DNS terminology defined in
- [RFC1035]. Other terminology used in this document includes:
-
-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 received on that 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. Names for which only a single responder is
- anticipated are referred to as UNIQUE. Name uniqueness is
- configured on the responder, and therefore uniqueness verification
- is the responder's responsibility.
-
-2. Name Resolution Using LLMNR
-
- LLMNR queries are sent to and received on port 5355. 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
- 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, if only 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].
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] An LLMNR sender sends an LLMNR query to the link-scope
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- multicast address(es), unless a unicast query is indicated,
- as specified in Section 2.4.
-
- [b] A responder responds to this query only if it is authoritative
- for the 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.
-
- [c] Upon reception of the response, the sender processes it.
-
- The sections that follow provide further details on sender and
- responder behavior.
-
-2.1. LLMNR Packet Format
-
- LLMNR is based on 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 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
- octets for the header, VLAN tag and CRC).
-
-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 | C|TC| T| Z| Z| Z| Z| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-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 Query/Response. A one bit field, which if set indicates that the
- message is an LLMNR response; if clear then the message is an LLMNR
- query.
-
-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.
-
-C Conflict. When set within a request, the 'C'onflict bit indicates
- that a sender has received multiple LLMNR responses to this query.
- In an LLMNR response, if the name is considered UNIQUE, then the
- 'C' bit is clear, otherwise it is set. LLMNR senders do not
- retransmit queries with the 'C' bit set. Responders MUST NOT
- respond to LLMNR queries with the 'C' bit set, but may start the
- uniqueness verification process, as described in Section 4.2.
-
-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 resend the LLMNR query over TCP using the
- unicast address of the responder as the destination address. If
- the sender receives a response to the TCP query, then it SHOULD
- discard the UDP response with the TC bit set. See [RFC2181] and
- Section 2.4 of this specification for further discussion of the TC
- bit.
-
-T Tentative. The 'T'entative bit is set in a response if the
- responder is authoritative for the name, but has not yet verified
- the uniqueness of the name. A responder MUST ignore the 'T' bit in
- a query, if set. A response with the 'T' bit set is silently
- discarded by the sender, except if it is a uniqueness query, in
- which case a conflict has been detected and a responder MUST
- resolve the conflict as described in Section 4.1.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-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 sender MUST set RCODE to zero;
- the responder ignores the RCODE and assumes it to be zero. 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.
-
- 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. This
- may be required, for example, when an LLMNR query includes a TSIG
- RR in the additional section, and the responder encounters a
- problem that requires returning a non-zero RCODE. TSIG error
- conditions defined in [RFC2845] include a TSIG RR in an
- unacceptable position (RCODE=1) or a TSIG RR which does not
- validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)).
-
- 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
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- 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. LLMNR
- responders MUST silently discard LLMNR queries with NSCOUNT not
- equal to zero.
-
-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, PTR, SRV, etc.) to the link-scope multicast address.
- As described in Section 2.4, a sender MAY also send a unicast query.
-
- The sender MUST anticipate receiving no replies to some LLMNR
- queries, in the event that no responders are available within the
- link-scope. If no response is received, a resolver treats it as a
- response that the name does not exist (RCODE=3 is returned). A
- sender can handle duplicate responses by discarding responses with a
- source IP address and ID field that duplicate a response already
- received.
-
- When multiple valid LLMNR responses are received with the 'C' bit
- set, they SHOULD be concatenated and treated in the same manner that
- multiple RRs received from the same DNS server would be. However,
- responses with the 'C' bit set SHOULD NOT be concatenated with
- responses with the 'C' bit clear; instead, only the responses with
- the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
- received along with error response(s), then the error responses are
- silently discarded.
-
- 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.
-
-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
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responder has another RR in addition to the SOA RR; 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.
-
- 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 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.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[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 MUST 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.
-
- 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.".
-
- Without the restriction on authority 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; for example a host
- "child.foo.example.com." could send a dynamic update for the NS and
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- glue A record to "foo.example.com.". However, 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.
-
- A unicast PTR RR query for an off-link address will not elicit a
- response, but instead an ICMP TTL or Hop Limit exceeded message will
- be received. An implementation receiving an ICMP message in response
- to a TCP connection setup attempt can return immediately, treating
- this as a response that no such name exists (RCODE=3 is returned).
- An implementation that cannot process ICMP messages MAY send
- multicast UDP queries for PTR RRs. Since TCP implementations will
- not retransmit prior to RTOmin, a considerable period will elapse
- before TCP retransmits multiple times, resulting in a long timeout
- for TCP PTR RR queries sent to an off-link destination.
-
-2.5. "Off link" Detection
-
- A sender MUST select a source address for LLMNR queries that is
- assigned on the interface on which the query is sent. The
- destination address of an LLMNR query MUST be a link-scope multicast
- address or a unicast address.
-
- A responder MUST select a source address for responses that is
- assigned on the interface on which the query was received. The
- destination address of an LLMNR response MUST be a 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.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- 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 early implementations of [RFC3927].
-
- 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.
-
-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.
- IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
- addresses are defined in [RFC2373]. 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
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- 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. An LLMNR sender SHOULD either
- estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
- high initial timeout. Suggested constants are described in Section
- 7.
-
- 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.
- An LLMNR query SHOULD NOT be sent more than three times.
-
- Where LLMNR queries are sent using TCP, retransmission is handled by
- the transport layer. Queries with the 'C' bit set MUST be sent using
- multicast UDP and MUST NOT be retransmitted.
-
- An LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
- has been received, or if it is necessary to collect all potential
- responses, such as if a uniqueness verification query is being made.
- Otherwise an LLMNR sender SHOULD consider a multicast query answered
- after the first response is received, if that response has the 'C'
- bit clear.
-
- However, if the first response has the 'C' bit set, then the sender
- SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect
- all possible responses. 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. A unicast
- query sender considers the query answered after the first response is
- received.
-
- Since it is possible for a response with the 'C' bit clear to be
- followed by a response with the 'C' bit set, an LLMNR sender SHOULD
- be prepared to process additional responses for the purposes of
- conflict detection, even after it has considered a query answered.
-
- 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
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responders responding with names which they have previously
- determined to be UNIQUE (see Section 4 for details).
-
-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 TTL of this record is set from the minimum of the
- MINIMUM field of the SOA record and the TTL of the SOA itself, and
- indicates how long a resolver may cache the negative answer. The
- owner name of the SOA record (MNAME) MUST be set to the query name.
- The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
- by senders. Negative responses without SOA records SHOULD NOT be
- cached.
-
- 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.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-3. Usage Model
-
- LLMNR is a peer-to-peer name resolution protocol that is not intended
- as a replacement for DNS; rather, it enables name resolution in
- scenarios in which conventional DNS name resolution is not possible.
- This includes situations in which hosts are not configured with the
- address of a DNS server; where the DNS server is unavailable or
- unreachable; where there is no DNS server authoritative for the name
- of a host, or where the authoritative DNS server does not have the
- desired RRs.
-
- By default, an LLMNR sender SHOULD send LLMNR queries only for
- single-label names. In order to reduce unnecessary DNS queries, stub
- resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS
- queries for single-label names. An LLMNR sender SHOULD NOT be
- enabled to send a query for any name, except where security
- mechanisms (described in Section 5.3) can be utilized.
-
- Regardless of whether security mechanisms can be utilized, LLMNR
- queries SHOULD NOT be sent unless 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, a
- host SHOULD attempt to reach DNS servers over all protocols
- on which DNS server address(es) are configured, prior to sending
- LLMNR queries. For dual stack hosts configured with DNS server
- address(es) for one protocol but not another, this implies that
- DNS queries SHOULD be sent over the protocol configured with
- a DNS server, prior to sending LLMNR queries.
-
- [2] All attempts to resolve the name via DNS on all interfaces
- have failed after exhausting the searchlist. This can occur
- because DNS servers did not respond, or because they
- responded to DNS queries with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section. Where a
- single resolver call generates DNS queries for A and AAAA RRs,
- an implementation MAY choose not to send LLMNR queries if any
- of the DNS queries is successful. An LLMNR query SHOULD only
- be sent for the originally requested name; a searchlist
- is not used to form additional LLMNR queries.
-
- Since LLMNR is a secondary name resolution mechanism, its usage is in
- part determined by the behavior of DNS implementations. In general,
- robust DNS resolver implementations are more likely to avoid
- unnecessary LLMNR queries.
-
- As noted in [DNSPerf], even when DNS servers are configured, a
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- 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 back-off. [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
- searchlist processing that will reduce unnecessary RCODE=3
- (authoritative name) errors, thereby also reducing unnecessary LLMNR
- queries.
-
- If error responses are received from both DNS and LLMNR, then the
- lowest RCODE value should be returned. For example, if either DNS or
- LLMNR receives a response with RCODE=0, then this should returned to
- the caller.
-
-3.1. LLMNR Configuration
-
- 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.
-
- 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
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- 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 link-local 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
- 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
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- 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
-
- By default, a responder SHOULD be configured to behave as though its
- name is UNIQUE on each interface on which LLMNR is enabled. However,
- it is also possible to configure multiple responders to be
- authoritative for the same name. For example, multiple responders
- MAY respond to a query for an A or AAAA type record for a cluster
- name (assigned to multiple hosts in the cluster).
-
- 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.
-
-4.1. Uniqueness Verification
-
- Prior to sending an LLMNR response with the 'T' bit clear, a
- responder configured with a UNIQUE name MUST verify that there is no
- other host within the scope of LLMNR query propagation that is
- authoritative for the same name on that interface.
-
- Once a responder has verified that its name is UNIQUE, if it receives
- an LLMNR query for that name, with the 'C' bit clear, it MUST
- respond, with the 'T' bit clear. Prior to verifying that its name is
- UNIQUE, a responder MUST set the 'T' bit in responses.
-
- 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
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- 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
- 'C' bit clear, over all protocols on which it responds to LLMNR
- queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
- uniqueness of a name by sending a query for the name with type='ANY'.
-
- If no response is received, the sender retransmits the query, as
- specified in Section 2.7. If a response is received, the sender MUST
- check if the source address matches the address of any of its
- interfaces; if so, then the response is not considered a conflict,
- since it originates from the sender. To avoid triggering conflict
- detection, a responder that detects that it is connected to the same
- link on multiple interfaces SHOULD set the 'C' bit in responses.
-
- If a response is received with the 'T' bit clear, the responder MUST
- NOT use the name in response to LLMNR queries received over any
- protocol (IPv4 or IPv6). If a response is received with the 'T' bit
- set, the responder MUST check if the source IP address in the
- response, interpreted as an unsigned integer, is less than the source
- IP address in the query. If so, the responder MUST NOT use the name
- in response to LLMNR queries received over any protocol (IPv4 or
- IPv6). For the purpose of uniqueness verification, the contents of
- the answer section in a response is irrelevant.
-
- 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. 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.
-
- In order to enable ongoing detection of name conflicts, when an LLMNR
- sender receives multiple LLMNR responses to a query, it MUST check if
- the 'C' bit is clear in any of the responses. If so, the sender
- SHOULD send another query for the same name, type and class, this
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- time with the 'C' bit set, with the potentially conflicting resource
- records included in the additional section.
-
- Queries with the 'C' bit set are considered advisory and responders
- MUST verify the existence of a conflict before acting on it. A
- responder receiving a query with the 'C' bit set MUST NOT respond.
-
- If the query is for a UNIQUE name, then the responder MUST send its
- own query for the same name, type and class, with the 'C' bit clear.
- If a response is received, the sender MUST check if the source
- address matches the address of any of its interfaces; if so, then the
- response is not considered a conflict, since it originates from the
- sender. To avoid triggering conflict detection, a responder that
- detects that it is connected to the same link on multiple interfaces
- SHOULD set the 'C' bit in responses.
-
- An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
- log them. Upon detecting a conflict, an LLMNR responder MUST
- immediately stop using the conflicting name in response to LLMNR
- queries received over any supported protocol, if the source IP
- address in the response, interpreted as an unsigned integer, is less
- than the source IP address in the uniqueness verification query.
-
- After stopping the use of a name, the responder MAY 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. A host that has stopped the use of a name may
- attempt uniqueness verification again after the expiration of the TTL
- of the conflicting response.
-
-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.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- ---------- ----------
- | | | |
- [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.
-
- 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 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.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-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 a peer-to-peer name resolution protocol designed for use on
- the local link. While LLMNR limits the vulnerability of responders
- to off-link senders, it is possible for an off-link responder to
- reach a sender.
-
- In scenarios such as public "hotspots" 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 network, while wireless attackers may mount
- attacks from a distance. Link-layer security such as [IEEE-802.11i]
- can be of assistance against these threats if it is available.
-
- This section details security measures available to mitigate threats
- from on and off-link attackers.
-
-5.1. Denial of Service
-
- Attackers may take advantage of LLMNR conflict detection by
- allocating the same name, denying service to other LLMNR responders
- and possibly allowing an attacker to receive packets destined for
- other hosts. By logging conflicts, LLMNR responders can provide
- forensic evidence of these attacks.
-
- An attacker may spoof LLMNR queries from a victim's address in order
- to mount a denial of service attack. Responders setting the IPv6 Hop
- Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- response may be able to reach the victim across the Internet.
-
- While LLMNR responders only respond to queries for which they are
- authoritative and LLMNR does not provide wildcard query support, an
- LLMNR response may be larger than the query, and an attacker can
- generate multiple responses to a query for a name used by multiple
- responders. A sender may protect itself against unsolicited
- responses by silently discarding them as rapidly as possible.
-
-5.2. Spoofing
-
- LLMNR is designed to prevent reception of queries sent by an off-link
- attacker. LLMNR requires that responders receiving UDP queries check
- that they are sent to a link-scope multicast address. However, 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. To prevent successful setup of TCP
- connections by an off-link sender, responders receiving a TCP SYN
- reply with a TCP SYN-ACK with TTL set to one (1).
-
- While it is difficult for an off-link attacker to send an LLMNR query
- to a responder, it is possible for an off-link 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. Since the
- forged response will only be accepted if it contains a matching ID
- field, choosing a pseudo-random ID field within queries provides some
- protection against off-link responders.
-
- Since LLMNR queries can be sent when DNS server(s) do not respond, an
- attacker can execute a denial of service attack on the DNS server(s)
- and then poison the LLMNR cache by responding to an LLMNR query with
- incorrect information. As noted in "Threat Analysis of the Domain
- Name System (DNS)" [RFC3833] these threats also exist with DNS, since
- DNS response spoofing tools are available that can allow an attacker
- to respond to a query more quickly than a distant DNS server.
- However, while switched networks or link layer security may make it
- difficult for an on-link attacker to snoop unicast DNS queries,
- multicast LLMNR queries are propagated to all hosts on the link,
- making it possible for an on-link attacker to spoof LLMNR responses
- without having to guess the value of the ID field in the query.
-
- 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.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- This vulnerability can be reduced by limiting use of LLMNR to
- resolution of single-label names as described in Section 3, or by
- implementation of authentication (see Section 5.3).
-
-5.3. Authentication
-
- LLMNR is a peer-to-peer name resolution protocol, and as a result,
- it is often deployed in situations where no trust model can be
- assumed. Where a pre-arranged security configuration is possible,
- the following security mechanisms may be used:
-
-[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
- [RFC2931] security mechanisms. "DNS Name Service based on Secure
- Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
- the use of TSIG to secure LLMNR, based on group keys. While group
- keys can be used to demonstrate membership in a group, they do not
- protect against forgery by an attacker that is a member of the
- group.
-
-[b] 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. As with TSIG, this does not
- protect against forgery by an attacker with access to the group
- pre-shared key.
-
-[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to
- support DNSSEC, LLMNR implementations MAY be configured with trust
- anchors, or they MAY make use of keys obtained from DNS queries.
- Since LLMNR does not support "delegated trust" (CD or AD bits),
- LLMNR implementations cannot make use of DNSSEC unless they are
- DNSSEC-aware and support validation. Unlike approaches [a] or [b],
- DNSSEC permits a responder to demonstrate ownership of a name, not
- just membership within a trusted group. As a result, it enables
- protection against forgery.
-
-5.4. 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.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- If LLMNR is given higher priority than DNS among the enabled name
- resolution mechanisms, 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 SHOULD NOT be used as a primary name resolution
- mechanism.
-
-6. IANA Considerations
-
- 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.
-
- This specification creates two new name spaces: the LLMNR namespace
- and the reserved bits in the LLMNR header. The reserved bits in the
- LLMNR header are allocated by IETF Consensus, in accordance with BCP
- 26 [RFC2434].
-
- In order to to avoid creating any new administrative procedures,
- administration of the LLMNR namespace will piggyback on the
- administration of the DNS namespace.
-
- The rights to use a fully qualified domain name (FQDN) within LLMNR
- are obtained coincident with acquiring the rights to use that name
- within DNS. Those wishing to use a FQDN within LLMNR should first
- acquire the rights to use the corresponding FQDN within DNS. Using a
- FQDN within LLMNR without ownership of the corresponding name in DNS
- creates the possibility of conflict and therefore is discouraged.
-
- LLMNR responders may self-allocate a name within the single-label
- name space, first defined in [RFC1001]. Since single-label names are
- not unique, no registration process is required.
-
-7. Constants
-
- The following timing constants are used in this protocol; they are
- not intended to be user configurable.
-
- JITTER_INTERVAL 100 ms
- LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
- 100 ms (IEEE 802 media, including IEEE 802.11)
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-8. References
-
-8.1. Normative References
-
-[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS
- Service on a TCP/UDP Transport: Concepts and Methods", RFC
- 1001, March 1987.
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-[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.
-
-[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.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
-8.2. Informative References
-
-[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.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 26]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[IEEE-802.11i]
- Institute of Electrical and Electronics Engineers, "Supplement
- to Standard for Telecommunications and Information Exchange
- Between Systems - LAN/MAN Specific Requirements - Part 11:
- Wireless LAN Medium Access Control (MAC) and Physical Layer
- (PHY) Specifications: Specification for Enhanced Security",
- IEEE 802.11i, July 2004.
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
- Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
- Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
- 2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[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
-
-[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.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 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.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 27]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirement", RFC 4033, March
- 2005.
-
-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
- 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
-
- 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
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 28]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 29]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 30]
-
-
-
+++ /dev/null
-
-
-
-Network Working Group R. Austein
-Internet-Draft ISC
-Expires: July 15, 2006 January 11, 2006
-
-
- DNS Name Server Identifier Option (NSID)
- draft-ietf-dnsext-nsid-01
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on July 15, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-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. While existing ad-hoc
- mechanism allow an operator to send follow-up queries when it is
- necessary to debug such a configuration, the only completely reliable
- way to obtain the identity of the name server which responded is to
- have the name server include this information in the response itself.
- This note defines a protocol extension to support this functionality.
-
-
-
-Austein Expires July 15, 2006 [Page 1]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4
- 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4
- 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4
- 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5
- 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6
- 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8
- 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8
- 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9
- 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
- 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires July 15, 2006 [Page 2]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-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.
-
- Existing ad-hoc mechanisms allow an operator to send follow-up
- queries when it is necessary to debug such a configuration, but there
- are situations in which this is not a totally satisfactory solution,
- since anycast routing may have changed, or the server pool in
- question may be behind some kind of extremely dynamic load balancing
- hardware. Thus, while these ad-hoc mechanisms are certainly better
- than nothing (and have the advantage of already being deployed), a
- better solution seems desirable.
-
- Given that a DNS query is an idempotent operation with no retained
- state, it would appear that the only completely reliable way to
- obtain the identity of the name server which responded to a
- particular query is to have that name server include identifying
- information in the response itself. This note defines a protocol
- enhancement to achieve this.
-
-1.1. 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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires July 15, 2006 [Page 3]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-2. Protocol
-
- This note uses an EDNS [RFC2671] option to signal the resolver's
- desire for information identifying the name server and to hold the
- name server's response, if any.
-
-2.1. Resolver Behavior
-
- A resolver signals its desire for information identifying a name
- server by sending an empty NSID option (Section 2.3) in an EDNS OPT
- pseudo-RR in the query message.
-
- The resolver MUST NOT include any NSID payload data in the query
- message.
-
- The semantics of an NSID request are not transitive. That is: the
- presence of an NSID option in a query is a request that the name
- server which receives the query identify itself. If the name server
- side of a recursive name server receives an NSID request, the client
- is asking the recursive name server to identify itself; if the
- resolver side of the recursive name server wishes to receive
- identifying information, it is free to add NSID requests in its own
- queries, but that is a separate matter.
-
-2.2. Name Server Behavior
-
- A name server which understands the NSID option and chooses to honor
- a particular NSID request responds by including identifying
- information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
- in the response message.
-
- The name server MUST ignore any NSID payload data that might be
- present in the query message.
-
- The NSID option is not transitive. A name server MUST NOT send an
- NSID option back to a resolver which did not request it. In
- particular, while a recursive name server may choose to add an NSID
- option when sending a query, this has no effect on the presence or
- absence of the NSID option in the recursive name server's response to
- the original client.
-
- As stated in Section 2.1, this mechanism is not restricted to
- authoritative name servers; the semantics are intended to be equally
- applicable to recursive name servers.
-
-2.3. The NSID Option
-
- The OPTION-CODE for the NSID option is [TBD].
-
-
-
-Austein Expires July 15, 2006 [Page 4]
-\f
-Internet-Draft DNS NSID January 2006
-
-
- The OPTION-DATA for the NSID option is an opaque byte string the
- semantics of which are deliberately left outside the protocol. See
- Section 3.1 for discussion.
-
-2.4. Presentation Format
-
- User interfaces MUST read and write the content of the NSID option as
- a sequence of hexadecimal digits, two digits per payload octet.
-
- The NSID payload is binary data. Any comparison between NSID
- payloads MUST be a comparison of the raw binary data. Copy
- operations MUST NOT assume that the raw NSID payload is null-
- terminated. Any resemblance between raw NSID payload data and any
- form of text is purely a convenience, and does not change the
- underlying nature of the payload data.
-
- See Section 3.3 for discussion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires July 15, 2006 [Page 5]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-3. Discussion
-
- This section discusses certain aspects of the protocol and explains
- considerations that led to the chosen design.
-
-3.1. The NSID Payload
-
- The syntax and semantics of the content of the NSID option is
- deliberately left outside the scope of this specification. This
- section describe some of the kinds of data that server administrators
- might choose to provide as the content of the NSID option, and
- explains the reasoning behind choosing a simple opaque byte string.
-
- There are several possibilities for the payload of the NSID option:
-
- o It could be the "real" name of the specific name server within the
- name server pool.
-
- o It could be the "real" IP address (IPv4 or IPv6) of the name
- server within the name server pool.
-
- o It could be some sort of pseudo-random number generated in a
- predictable fashion somehow using the server's IP address or name
- as a seed value.
-
- o It could be some sort of probabilisticly unique identifier
- initially derived from some sort of random number generator then
- preserved across reboots of the name server.
-
- o It could be some sort of dynamicly generated identifier so that
- only the name server operator could tell whether or not any two
- queries had been answered by the same server.
-
- o It could be a blob of signed data, with a corresponding key which
- might (or might not) be available via DNS lookups.
-
- o It could be a blob of encrypted data, the key for which could be
- restricted to parties with a need to know (in the opinion of the
- server operator).
-
- o It could be an arbitrary string of octets chosen at the discretion
- of the name server operator.
-
- Each of these options has advantages and disadvantages:
-
- o Using the "real" name is simple, but the name server may not have
- a "real" name.
-
-
-
-
-Austein Expires July 15, 2006 [Page 6]
-\f
-Internet-Draft DNS NSID January 2006
-
-
- o Using the "real" address is also simple, and the name server
- almost certainly does have at least one non-anycast IP address for
- maintenance operations, but the operator of the name server may
- not be willing to divulge its non-anycast address.
-
- o Given that one common reason for using anycast DNS techniques is
- an attempt to harden a critical name server against denial of
- service attacks, some name server operators are likely to want an
- identifier other than the "real" name or "real" address of the
- name server instance.
-
- o Using a hash or pseudo-random number can provide a fixed length
- value that the resolver can use to tell two name servers apart
- without necessarily being able to tell where either one of them
- "really" is, but makes debugging more difficult if one happens to
- be in a friendly open environment. Furthermore, hashing might not
- add much value, since a hash based on an IPv4 address still only
- involves a 32-bit search space, and DNS names used for servers
- that operators might have to debug at 4am tend not to be very
- random.
-
- o Probabilisticly unique identifiers have similar properties to
- hashed identifiers, but (given a sufficiently good random number
- generator) are immune to the search space issues. However, the
- strength of this approach is also its weakness: there is no
- algorithmic transformation by which even the server operator can
- associate name server instances with identifiers while debugging,
- which might be annoying. This approach also requires the name
- server instance to preserve the probabilisticly unique identifier
- across reboots, but this does not appear to be a serious
- restriction, since authoritative nameservers almost always have
- some form of nonvolatile storage in any case, and in the rare case
- of a name server that does not have any way to store such an
- identifier, nothing terrible will happen if the name server just
- generates a new identifier every time it reboots.
-
- o Using an arbitrary octet string gives name server operators yet
- another thing to configure, or mis-configure, or forget to
- configure. Having all the nodes in an anycast name server
- constellation identify themselves as "My Name Server" would not be
- particularly useful.
-
- Given all of the issues listed above, there does not appear to be a
- single solution that will meet all needs. Section 2.3 therefore
- defines the NSID payload to be an opaque byte string and leaves the
- choice up to the implementor and name server operator. The following
- guidelines may be useful to implementors and server operators:
-
-
-
-
-Austein Expires July 15, 2006 [Page 7]
-\f
-Internet-Draft DNS NSID January 2006
-
-
- o Operators for whom divulging the unicast address is an issue could
- use the raw binary representation of a probabilisticly unique
- random number. This should probably be the default implementation
- behavior.
-
- o Operators for whom divulging the unicast address is not an issue
- could just use the raw binary representation of a unicast address
- for simplicity. This should only be done via an explicit
- configuration choice by the operator.
-
- o Operators who really need or want the ability to set the NSID
- payload to an arbitrary value could do so, but this should only be
- done via an explicit configuration choice by the operator.
-
- This approach appears to provide enough information for useful
- debugging without unintentionally leaking the maintenance addresses
- of anycast name servers to nogoodniks, while also allowing name
- server operators who do not find such leakage threatening to provide
- more information at their own discretion.
-
-3.2. NSID Is Not Transitive
-
- As specified in Section 2.1 and Section 2.2, the NSID option is not
- transitive. This is strictly a hop-by-hop mechanism.
-
- Most of the discussion of name server identification to date has
- focused on identifying authoritative name servers, since the best
- known cases of anycast name servers are a subset of the name servers
- for the root zone. However, given that anycast DNS techniques are
- also applicable to recursive name servers, the mechanism may also be
- useful with recursive name servers. The hop-by-hop semantics support
- this.
-
- While there might be some utility in having a transitive variant of
- this mechanism (so that, for example, a stub resolver could ask a
- recursive server to tell it which authoritative name server provided
- a particular answer to the recursive name server), the semantics of
- such a variant would be more complicated, and are left for future
- work.
-
-3.3. User Interface Issues
-
- Given the range of possible payload contents described in
- Section 3.1, it is not possible to define a single presentation
- format for the NSID payload that is efficient, convenient,
- unambiguous, and aesthetically pleasing. In particular, while it is
- tempting to use a presentation format that uses some form of textual
- strings, attempting to support this would significantly complicate
-
-
-
-Austein Expires July 15, 2006 [Page 8]
-\f
-Internet-Draft DNS NSID January 2006
-
-
- what's intended to be a very simple debugging mechanism.
-
- In some cases the content of the NSID payload may be binary data
- meaningful only to the name server operator, and may not be
- meaningful to the user or application, but the user or application
- must be able to capture the entire content anyway in order for it to
- be useful. Thus, the presentation format must support arbitrary
- binary data.
-
- In cases where the name server operator derives the NSID payload from
- textual data, a textual form such as US-ASCII or UTF-8 strings might
- at first glance seem easier for a user to deal with. There are,
- however, a number of complex issues involving internationalized text
- which, if fully addressed here, would require a set of rules
- significantly longer than the rest of this specification. See
- [RFC2277] for an overview of some of these issues.
-
- It is much more important for the NSID payload data to be passed
- unambiguously from server administrator to user and back again than
- it is for the payload data data to be pretty while in transit. In
- particular, it's critical that it be straightforward for a user to
- cut and paste an exact copy of the NSID payload output by a debugging
- tool into other formats such as email messages or web forms without
- distortion. Hexadecimal strings, while ugly, are also robust.
-
-3.4. Truncation
-
- In some cases, adding the NSID option to a response message may
- trigger message truncation. This specification does not change the
- rules for DNS message truncation in any way, but implementors will
- need to pay attention to this issue.
-
- Including the NSID option in a response is always optional, so this
- specification never requires name servers to truncate response
- messages.
-
- By definition, a resolver that requests NSID responses also supports
- EDNS, so a resolver that requests NSID responses can also use the
- "sender's UDP payload size" field of the OPT pseudo-RR to signal a
- receive buffer size large enough to make truncation unlikely.
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires July 15, 2006 [Page 9]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-4. IANA Considerations
-
- This mechanism requires allocation of one ENDS option code for the
- NSID option (Section 2.3).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires July 15, 2006 [Page 10]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-5. Security Considerations
-
- This document describes a channel signaling mechanism, intended
- primarily for debugging. Channel signaling mechanisms are outside
- the scope of DNSSEC per se. Applications that require integrity
- protection for the data being signaled will need to use a channel
- security mechanism such as TSIG [RFC2845].
-
- Section 3.1 discusses a number of different kinds of information that
- a name server operator might choose to provide as the value of the
- NSID option. Some of these kinds of information are security
- sensitive in some environments. This specification deliberately
- leaves the syntax and semantics of the NSID option content up to the
- implementation and the name server operator.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires July 15, 2006 [Page 11]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-6. Acknowledgements
-
- Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
- Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
- Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
- Suzanne Woolf. Apologies to anyone inadvertently omitted from the
- above list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires July 15, 2006 [Page 12]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-7. References
-
-7.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, BCP 14, March 1997.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
- RFC 2671, August 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
-7.2. Informative References
-
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
- Languages", RFC 2277, BCP 18, January 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires July 15, 2006 [Page 13]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-Author's Address
-
- Rob Austein
- ISC
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- Email: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires July 15, 2006 [Page 14]
-\f
-Internet-Draft DNS NSID January 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Austein Expires July 15, 2006 [Page 15]
-\f
+++ /dev/null
-
-INTERNET-DRAFT DSA Information in the DNS
-OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
- DSA Keying and Signature Information in the DNS
- --- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- 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.
-
- 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 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
-
-
-
-Abstract
-
- The standard method of encoding US Government Digital Signature
- Algorithm keying and signature information for use in the Domain Name
- System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................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, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative References.....................................7
-
- Author's 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 4033, 4034, 4035] 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-2] 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, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-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.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Normative References
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, 27 January 2000.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative References
-
- [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 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.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [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
-
-
-Author's 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 2006.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
-
-
- Storage of Diffie-Hellman Keying Information in the DNS
- ------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
-
-
-
-Status of This Document
-
- 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.
-
- 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 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
-
-
-Abstract
-
- The standard method for encoding Diffie-Hellman keys in the Domain
- Name System is specified.
-
-
-
-
-
-
-
-
-
-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
-
- 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, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative Refences.......................................7
-
- Author's Address...........................................8
- 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 4033, 4034, 4035] 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].
-
- 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.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
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- key is the pair p and g, which is the same for both parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
- 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, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-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.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Normative References
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
- in RFCs", T. Narten, H. Alvestrand, October 1998.
-
- [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
- 1999.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-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 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
- and Sons.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2006.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.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
-
-
-
-
-
-
-DNSEXT Working Group Paul Vixie, ISC
-INTERNET-DRAFT
-<draft-ietf-dnsext-rfc2671bis-edns0-01.txt> March 17, 2008
-
-Intended Status: Standards Track
-Obsoletes: 2671 (if approved)
-
-
- Revised extension mechanisms for DNS (EDNS0)
-
-
-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.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-
- Abstract
-
- The Domain Name System's wire protocol includes a number of fixed
- fields whose range has been or soon will be exhausted and does not
- allow clients to advertise their capabilities to servers. This
- document describes backward compatible mechanisms for allowing the
- protocol to grow.
-
-
-
-Expires September 2008 [Page 1]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-1 - Introduction
-
-1.1. DNS (see [RFC1035]) specifies a Message Format and within such
-messages there are standard formats for encoding options, errors, and
-name compression. The maximum allowable size of a DNS Message is fixed.
-Many of DNS's protocol limits are too small for uses which are or which
-are desired to become common. There is no way for implementations to
-advertise their capabilities.
-
-1.2. Unextended agents will not know how to interpret the protocol
-extensions detailed here. In practice, these clients will be upgraded
-when they have need of a new feature, and only new features will make
-use of the extensions. Extended agents must be prepared for behaviour
-of unextended clients in the face of new protocol elements, and fall
-back gracefully to unextended DNS. RFC 2671 originally has proposed
-extensions to the basic DNS protocol to overcome these deficiencies.
-This memo refines that specification and obsoletes RFC 2671.
-
-1.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 [RFC2119].
-
-2 - Affected Protocol Elements
-
-2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
-word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
-1-bit flags. The original reserved Z bits have been allocated to
-various purposes, and most of the RCODE values are now in use. More
-flags and more possible RCODEs are needed. The OPT pseudo-RR specified
-in Section 4 contains subfields that carry a bit field extension of the
-RCODE field and additional flag bits, respectively; for details see
-Section 4.6 below.
-
-2.2. The first two bits of a wire format domain label are used to denote
-the type of the label. [RFC1035 4.1.4] allocates two of the four
-possible types and reserves the other two. Proposals for use of the
-remaining types far outnumber those available. More label types were
-needed, and an extension mechanism was proposed in RFC 2671 [RFC2671
-Section 3]. Section 3 of this document reserves DNS labels with a first
-octet in the range of 64-127 decimal (label type 01) for future
-standardization of Extended DNS Labels.
-
-
-
-
-
-
-
-Expires September 2008 [Page 2]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
-While the minimum maximum reassembly buffer size still allows a limit of
-512 octets of UDP payload, most of the hosts now connected to the
-Internet are able to reassemble larger datagrams. Some mechanism must
-be created to allow requestors to advertise larger buffer sizes to
-responders. To this end, the OPT pseudo-RR specified in Section 4
-contains a maximum payload size field; for details see Section 4.5
-below.
-
-3 - Extended Label Types
-
-The first octet in the on-the-wire representation of a DNS label
-specifies the label type; the basic DNS specification [RFC1035]
-dedicates the two most significant bits of that octet for this purpose.
-
-This document reserves DNS label type 0b01 for use as an indication for
-Extended Label Types. A specific extended label type is selected by the
-6 least significant bits of the first octet. Thus, Extended Label Types
-are indicated by the values 64-127 (0b01xxxxxx) in the first octet of
-the label.
-
-Allocations from this range are to be made for IETF documents fully
-describing the syntax and semantics as well as the applicability of the
-particular Extended Label Type.
-
-This document does not describe any specific Extended Label Type.
-
-4 - OPT pseudo-RR
-
-4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data
-section of a request, and to responses to such requests. An OPT is
-called a pseudo-RR because it pertains to a particular transport level
-message and not to any actual DNS data. OPT RRs MUST NOT be cached,
-forwarded, or stored in or loaded from master files. The quantity of
-OPT pseudo-RRs per message MUST be either zero or one, but not greater.
-
-4.2. An OPT RR has a fixed part and a variable set of options expressed
-as {attribute, value} pairs. The fixed part holds some DNS meta data
-and also a small collection of new protocol elements which we expect to
-be so popular that it would be a waste of wire space to encode them as
-{attribute, value} pairs.
-
-
-
-
-
-
-
-Expires September 2008 [Page 3]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-4.3. The fixed part of an OPT RR is structured as follows:
-
-Field Name Field Type Description
-------------------------------------------------------
-NAME domain name empty (root domain)
-TYPE u_int16_t OPT (41)
-CLASS u_int16_t sender's UDP payload size
-TTL u_int32_t extended RCODE and flags
-RDLEN u_int16_t describes RDATA
-RDATA octet stream {attribute,value} pairs
-
-
-4.4. The variable part of an OPT RR is encoded in its RDATA and is
-structured as zero or more of the following:
-
- : +0 (MSB) : +1 (LSB) :
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 0: | OPTION-CODE |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 2: | OPTION-LENGTH |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 4: | |
- / OPTION-DATA /
- / /
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-OPTION-CODE (Assigned by IANA.)
-
-OPTION-LENGTH Size (in octets) of OPTION-DATA.
-
-OPTION-DATA Varies per OPTION-CODE.
-
-4.4.1. Order of appearance of option tuples is never relevant. Any
-option whose meaning is affected by other options is so affected no
-matter which one comes first in the OPT RDATA.
-
-4.4.2. Any OPTION-CODE values not understood by a responder or requestor
-MUST be ignored. So, specifications of such options might wish to
-include some kind of signalled acknowledgement. For example, an option
-specification might say that if a responder sees option XYZ, it SHOULD
-include option XYZ in its response.
-
-
-
-
-
-
-Expires September 2008 [Page 4]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
-field) is the number of octets of the largest UDP payload that can be
-reassembled and delivered in the sender's network stack. Note that path
-MTU, with or without fragmentation, may be smaller than this. Values
-lower than 512 are undefined, and may be treated as format errors, or
-may be treated as equal to 512, at the implementor's discretion.
-
-4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
-reassembly buffer. Choosing 1280 on an Ethernet connected requestor
-would be reasonable. The consequence of choosing too large a value may
-be an ICMP message from an intermediate gateway, or even a silent drop
-of the response message.
-
-4.5.2. Both requestors and responders are advised to take account of the
-path's discovered MTU (if already known) when considering message sizes.
-
-4.5.3. The requestor's maximum payload size can change over time, and
-therefore MUST NOT be cached for use beyond the transaction in which it
-is advertised.
-
-4.5.4. The responder's maximum payload size can change over time, but
-can be reasonably expected to remain constant between two sequential
-transactions; for example, a meaningless QUERY to discover a responder's
-maximum UDP payload size, followed immediately by an UPDATE which takes
-advantage of this size. (This is considered preferrable to the outright
-use of TCP for oversized requests, if there is any reason to suspect
-that the responder implements EDNS, and if a request will not fit in the
-default 512 payload size limit.)
-
-4.5.5. Due to transaction overhead, it is unwise to advertise an
-architectural limit as a maximum UDP payload size. Just because your
-stack can reassemble 64KB datagrams, don't assume that you want to spend
-more than about 4KB of state memory per ongoing transaction.
-
-4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
-are structured as follows:
-
- : +0 (MSB) : +1 (LSB) :
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 0: | EXTENDED-RCODE | VERSION |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 2: | DO| Z |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-
-
-
-Expires September 2008 [Page 5]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that
- EXTENDED-RCODE value zero (0) indicates that an
- unextended RCODE is in use (values zero (0) through
- fifteen (15)).
-
-VERSION Indicates the implementation level of whoever sets it.
- Full conformance with this specification is indicated by
- version zero (0). Requestors are encouraged to set this
- to the lowest implemented level capable of expressing a
- transaction, to minimize the responder and network load
- of discovering the greatest common implementation level
- between requestor and responder. A requestor's version
- numbering strategy should ideally be a run time
- configuration option.
-
- If a responder does not implement the VERSION level of
- the request, then it answers with RCODE=BADVERS. All
- responses MUST be limited in format to the VERSION level
- of the request, but the VERSION of each response MUST be
- the highest implementation level of the responder. In
- this way a requestor will learn the implementation level
- of a responder as a side effect of every response,
- including error responses, including RCODE=BADVERS.
-
-DO DNSSEC OK bit [RFC3225].
-
-Z Set to zero by senders and ignored by receivers, unless
- modified in a subsequent specification [IANAFLAGS].
-
-5 - Transport Considerations
-
-5.1. The presence of an OPT pseudo-RR in a request is an indication that
-the requestor fully implements the given version of EDNS, and can
-correctly understand any response that conforms to that feature's
-specification.
-
-5.2. Lack of use of these features in a request is an indication that
-the requestor does not implement any part of this specification and that
-the responder SHOULD NOT use any protocol extension described here in
-its response.
-
-5.3. Responders who do not understand these protocol extensions are
-expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or
-to appear to "time out" due to inappropriate action by a "middle box"
-such as a NAT, or to ignore extensions and respond only to unextended
-
-
-
-Expires September 2008 [Page 6]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-protocol elements. Therefore use of extensions SHOULD be "probed" such
-that a responder who isn't known to support them be allowed a retry with
-no extensions if it responds with such an RCODE, or does not respond.
-If a responder's capability level is cached by a requestor, a new probe
-SHOULD be sent periodically to test for changes to responder capability.
-
-5.4. If EDNS is used in a request, and the response arrives with TC set
-and with no EDNS OPT RR, a requestor should assume that truncation
-prevented the OPT RR from being appended by the responder, and further,
-that EDNS is not used in the response. Correspondingly, an EDNS
-responder who cannot fit all necessary elements (including an OPT RR)
-into a response, should respond with a normal (unextended) DNS response,
-possibly setting TC if the response will not fit in the unextended
-response message's 512-octet size.
-
-6 - Security Considerations
-
-Requestor-side specification of the maximum buffer size may open a new
-DNS denial of service attack if responders can be made to send messages
-which are too large for intermediate gateways to forward, thus leading
-to potential ICMP storms between gateways and responders.
-
-7 - IANA Considerations
-
-IANA has allocated RR type code 41 for OPT.
-
-This document controls the following IANA sub-registries in registry
-"DOMAIN NAME SYSTEM PARAMETERS":
-
- "EDNS Extended Label Type"
- "EDNS Option Codes"
- "EDNS Version Numbers"
- "Domain System Response Code"
-
-IANA is advised to re-parent these subregistries to this document.
-
-This document assigns label type 0b01xxxxxx as "EDNS Extended Label
-Type." We request that IANA record this assignment.
-
-This document assigns option code 65535 to "Reserved for future
-expansion."
-
-This document assigns EDNS Extended RCODE "16" to "BADVERS".
-
-
-
-
-
-Expires September 2008 [Page 7]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-IESG approval is required to create new entries in the EDNS Extended
-Label Type or EDNS Version Number registries, while any published RFC
-(including Informational, Experimental, or BCP) is grounds for
-allocation of an EDNS Option Code.
-
-8 - Acknowledgements
-
-Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
-Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten,
-Alfred Hoenes and Markku Savela were each instrumental in creating and
-refining this specification.
-
-9 - References
-
-[RFC1035] P. Mockapetris, "Domain Names - Implementation and
- Specification," RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels," RFC 2119, Harvard University, March
- 1997.
-
-[RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671,
- Internet Software Consortium, August 1999.
-
-[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC
- 3225, Nominum Inc., December 2001.
-
-[IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site
- http://www.iana.org/assignments/dns-header-flags, as of
- June 2005 or later.
-
-10 - Author's Address
-
-Paul Vixie
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 423 1301
- EMail: vixie@isc.org
-
-
-
-
-
-
-
-
-Expires September 2008 [Page 8]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-Full Copyright Statement
-
-Copyright (C) IETF Trust (2007).
-
-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, THE IETF TRUST 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 provided by the IETF
-Administrative Support Activity (IASA).
-
-
-
-
-Expires September 2008 [Page 9]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-Network Working Group M. StJohns
-Internet-Draft Nominum, Inc.
-Intended status: Informational November 29, 2006
-Expires: June 2, 2007
-
-
- Automated Updates of DNSSEC Trust Anchors
- draft-ietf-dnsext-trustupdate-timers-05
-
-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 June 2, 2007.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes a means for automated, authenticated and
- authorized updating of DNSSEC "trust anchors". The method provides
- protection against N-1 key compromises of N keys 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(s).
-
- This mechanism will require changes to resolver management behavior
-
-
-
-StJohns Expires June 2, 2007 [Page 1]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- (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
- 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
- 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
- 2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5
- 2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
- 2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
- 2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
- 2.4.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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8
- 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9
- 6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9
- 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
- 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
- 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10
- 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
- 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
- 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11
- 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
- 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
- Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
- Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 2]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-1. Introduction
-
- As part of the reality of fielding DNSSEC (Domain Name System
- Security Extensions) [RFC4033] [RFC4034] [RFC4035], 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].
-
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 3]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-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 zone operator adds a new SEP key (i.e. a
- DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section
- 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
- validated by an existing trust anchor, then the resolver can add the
- new key to its valid set of trust anchors for that trust point.
-
- 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, we need to prevent an attacker from adding a new key and
- revoking 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 (see Section 7 below) 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 it signed 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.
-
- A self-signed RRSet is a DNSKEY RRSet which contains the specific
- DNSKEY and for which there is a corresponding validated RRSIG record.
- It's not a special DNSKEY RRSet, just a way of describing the
- validation requirements for that RRSet.
-
- 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.
-
- 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 June 2, 2007 [Page 4]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-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 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 for that
- key 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. 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
-
-
-
-StJohns Expires June 2, 2007 [Page 5]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- RRSet or half the RRSIG expiration interval and no more often than
- once per hour. 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. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
- origTTL, .1 * expireInterval)).
-
-2.4. Resolver Parameters
-
-2.4.1. Add Hold-Down Time
-
- The add hold-down time is 30 days or the expiration time of the
- original TTL of the first trust point DNSKEY RRSet which contained
- the new 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.4.2. Remove Hold-Down Time
-
- The remove hold-down time is 30 days. This parameter is solely a key
- management database bookeeping parameter. Failure to remove
- information about the state of defunct keys from the database will
- not adversely impact the security of this protocol, but may end up
- with a database cluttered with obsolete key information.
-
-2.4.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
- validating 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 June 2, 2007 [Page 6]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- 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.
-
- 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 | | | | | | |
- ----------------------------------------------------------
-
-
- State Table
-
-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 it's 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.
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 7]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-4.2. States
- 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 either hasn't yet
- been seen at the resolver or was seen but was absent from the last
- DNSKEY RRSet (e.g. KeyRem event).
- 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.
- 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. (Note: this state is
- more or less equivalent to the "Start" state, except that it's bad
- practice to re-introduce previously used keys - think of this as
- the holding state for all the old keys for which the resolver no
- longer needs to track state.)
-
-
-5. Trust Point Deletion
-
- A trust point which has all of its trust anchors revoked is
- considered deleted and is treated as if the trust point was never
- configured. If there are no superior configured trust points, data
- at and below the deleted trust point are considered insecure by the
- resolver. If there ARE superior configured trust points, data at and
- below the deleted trust point are evaluated with respect to the
- superior trust point(s).
-
- Alternately, a trust point which is subordinate to another configured
- trust point MAY be deleted by a resolver after 180 days where such
- subordinate trust point validly chains to a superior trust point.
- The decision to delete the subordinate trust anchor is a local
-
-
-
-StJohns Expires June 2, 2007 [Page 8]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- configuration decision. Once the subordinate trust point is deleted,
- validation of the subordinate zone is dependent on validating the
- chain of trust to the superior trust point.
-
-
-6. Scenarios - Informative
-
- 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.
-
-6.1. Adding a Trust Anchor
-
- Assume an existing trust anchor key 'A'.
- 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 (i.e. for various resolvers timers to go off and for
- them to retrieve the new DNSKEY RRSet and signatures).
- 6. The new trust anchor will be populated at the resolvers on the
- schedule described by the state table and update algorithm - see
- Section 2 above
-
-6.2. Deleting a Trust Anchor
-
- Assume existing trust anchors 'A' and 'B' and that you want to revoke
- and delete 'A'.
- 1. Set the revocation 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.
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 9]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-6.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.
-
-6.4. Active Key Compromised
-
- This is the same as the mechanism for Key Roll-Over (Section 6.3)
- above assuming 'A' is the active key.
-
-6.5. Stand-by Key Compromised
-
- Using the same assumptions and naming conventions as Key Roll-Over
- (Section 6.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
- included in the RRSet for the remove hold-down time.
-
-6.6. Trust Point Deletion
-
- To delete a trust point which is subordinate to another configured
- trust point (e.g. example.com to .com) requires some juggling of the
- data. The specific process is:
- 1. Generate a new DNSKEY and DS record and provide the DS record to
- the parent along with DS records for the old keys
- 2. Once the parent has published the DSs, add the new DNSKEY to the
- RRSet and revoke ALL of the old keys at the same time while
- signing the DNSKEY RRSet with all of the old and new keys.
- 3. After 30 days stop publishing the old, revoked keys and remove
- any corresponding DS records in the parent.
- Revoking the old trust point keys at the same time as adding new keys
- that chain to a superior trust prevents the resolver from adding the
- new keys as trust anchors. Adding DS records for the old keys avoids
- a race condition where either the subordinate zone becomes unsecure
-
-
-
-StJohns Expires June 2, 2007 [Page 10]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- (because the trust point was deleted) or becomes bogus (because it
- didn't chain to the superior zone).
-
-
-7. IANA Considerations
-
- The IANA will need to assign a bit in the DNSKEY flags field (see
- section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
- IANA actions required.
-
-
-8. Security Considerations
-
- In addition to the following sections, see also Theory of Operation
- above and especially Section 2.2 for related discussions.
-
-8.1. Key Ownership vs Acceptance Policy
-
- The reader should note that, while the zone owner is responsible for
- 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 to
- 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.
-
-8.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.
-
-8.3. Dynamic Updates
-
- Allowing a resolver to update its trust anchor set based on 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
-
-
-
-StJohns Expires June 2, 2007 [Page 11]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- lack of a standard management framework for DNS, this approach is no
- worse than the existing situation.
-
-
-9. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer (DS)", RFC 3755, May 2004.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-Editorial Comments
-
- [msj2] msj: To be assigned.
-
-
-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 June 2, 2007 [Page 12]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- 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.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 13]
-\f
-
+++ /dev/null
-Internet-Draft dnsext-wcard January 9, 2006
-
-DNSEXT Working Group E. Lewis
-INTERNET DRAFT NeuStar
-Expiration Date: July 9, 2006 January 9, 2006
-Updates RFC 1034, RFC 2672
-
- The Role of Wildcards
- in the Domain Name System
- draft-ietf-dnsext-wcard-clarify-10.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 July 9, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-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.
-
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 1]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
-Table of Contents
-
-1. Introduction . . . . . . . . . . . . . . . . 3
-1 1 Motivation 3
-1 2 The Original Definition 3
-1 3 Roadmap to This Document 4
-1 3 1 New Terms 4
-1.3.2 Changed Text 5
-1.3.3 Considerations with Special Types 5
-1.4 Standards Terminology 5
-2. Wildcard Syntax . . . . . . . . . . . . . . . 6
-2.1 Identifying a Wildcard 6
-2.1.1 Wild Card Domain Name and Asterisk Label 6
-2.1.2 Asterisks and Other Characters 6
-2.1.3 Non-terminal Wild Card Domain Names 6
-2.2 Existence Rules 7
-2.2.1 An Example 7
-2.2.2 Empty Non-terminals 9
-2.2.3 Yet Another Definition of Existence 10
-2.3 When is a Wild Card Domain Name Not Special 10
-3. Impact of a Wild Card Domain Name On a Response . . . . . 10
-3.1 Step 2 10
-3.2 Step 3 11
-3.3 Part 'c' 11
-3.3.1 Closest Encloser and the Source of Synthesis 12
-3.3.2 Closest Encloser and Source of Synthesis Examples 12
-3.3.3 Type Matching 13
-4. Considerations with Special Types . . . . . . . . . 13
-4.1 SOA RRSet at a Wild Card Domain Name 13
-4.2 NS RRSet at a Wild Card Domain Name 14
-4.2.1 Discarded Notions 14
-4.3 CNAME RRSet at a Wild Card Domain Name 15
-4.4 DNAME RRSet at a Wild Card Domain Name 15
-4.5 SRV RRSet at a Wild Card Domain Name 16
-4.6 DS RRSet at a Wild Card Domain Name 16
-4.7 NSEC RRSet at a Wild Card Domain Name 17
-4.8 RRSIG at a Wild Card Domain Name 17
-4.9 Empty Non-terminal Wild Card Domain Name 17
-5. Security Considerations . . . . . . . . . . . . . 17
-6. IANA Considerations . . . . . . . . . . . . . 17
-7. References . . . . . . . . . . . . . 17
-8. Editor . . . . . . . . . . . . . 18
-9. Others Contributing to the Document . . . . . . . . 18
-10. Trailing Boilerplate . . . . . . . . . . . . . 19
-
-
-
-
-
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 2]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
-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 is given to minimize any backwards
- compatibility issues with implementations that comply with RFC
- 1034's definition.
-
- This document is focused on the concept of wildcards as defined
- in RFC 1034. Nothing is implied regarding alternative means of
- synthesizing resource record sets, nor are alternatives discussed.
-
-1.1 Motivation
-
- Many DNS implementations diverge, in different ways, from the
- original definition of wildcards. 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 its changes, documenting only
- those based on implementation experience, and to remain as close
- to the original document as possible. To reinforce that this
- document is meant to clarify and adjust and not redefine wildcards,
- relevant sections of RFC 1034 are repeated verbatim to facilitate
- comparison of the old and new text.
-
-1.2 The Original Definition
-
- The definition of the wildcard concept is comprised by the
- documentation of 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).
-
- This is the definition of the term "wildcard" as it appears in
- RFC 1034, section 4.3.3.
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 3]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
-# 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 follows 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 relevant portion of the "Algorithm."
-
-# 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 Roadmap to 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.
-
-DNSEXT Working Group Expires July 9, 2006 [Page 4]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- The new terms are used to make discussions of wildcards clearer.
- Terminology doesn't directly have an impact on implementations.
-
-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
- RFC 1034 contained no specification on when and how to enforce the
- restriction.
-
-1.3.3 Considerations with Special Types
-
- This document describes semantics of wildcard RRSets for
- "interesting" types as well as empty non-terminal wildcards.
- Understanding these situations 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. References to section "4.3.2" are assumed to refer
- to RFC 1034's section 4.3.2, simply titled "Algorithm."
-
-
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 5]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
-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] just as non-wildcard resource records are.
- This feature has been under appreciated 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 so these labels 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......................
-
-DNSEXT Working Group Expires July 9, 2006 [Page 6]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- The restriction is now removed. The original documentation of it
- is incomplete and the restriction does not serve any purpose
- given years of operational experience.
-
- There are three possible reasons for putting the restriction in
- place, but none of the three has held up over time. One is
- that the restriction meant that there would never be subdomains
- of wild card domain names, but the restriciton as stated still
- permits "example.*.example." for instance. Another is that
- wild card domain names are not intended to be empty non-terminals,
- but this situation does not disrupt the algorithm in 4.3.2.
- Finally, "nested" wild card domain names are not ambiguous once
- the concept of the closest encloser had been documented.
-
- 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
-
- "Existence" is therefore an important concept in the understanding
- of wildcards. Unfortunately, the definition of what exists, in RFC
- 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is
- taken at the definition of existence.
-
-2.2.1 An Example
-
- To illustrate what is meant by existence consider this complete
- zone:
-
-
-
-
-
-
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 7]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- $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 responses would be synthesized from one of the
- wildcards in the zone:
-
- 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 responses would not be synthesized from any of the
- wildcards in the zone:
-
- QNAME=host1.example., QTYPE=MX, QCLASS=IN
- because host1.example. exists
-
- QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
- because sub.*.example. exists
-
-DNSEXT Working Group Expires July 9, 2006 [Page 8]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- 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)
-
- QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
- because *.example. exists
-
- The final example highlights one common misconception about
- wildcards. A wildcard "blocks itself" in the sense that a
- wildcard does not match its own subdomains. I.e. "*.example."
- does not match all names in the "example." zone, it fails to
- match the names below "*.example." To cover names under
- "*.example.", another wild card domain name is needed -
- "*.*.example." - which covers all but it's own subdomains.
-
-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, so this apparently
- is not the intent of the original definition, justifying the
- need for an updated definition in the next section.
-
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 9]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
-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 one RRSet. A node may exist with no
- RRSets only if it has descendents that do, this node is an empty
- non-terminal.
-
- 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. In the delegating zone, 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 is a Wild Card Domain Name 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 matches a single, corresponding 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
-
- RFC 1034's description of how wildcards impact response
- generation is in its 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 wildcard.
-
- The algorithm in 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 suggested means of implementing the
- requirements. As such, in step 3, parts a, b, and c, do not have
- to be implemented in that order, provided that the result of the
- implemented code is compliant with the protocol's specification.
-
-3.1 Step 2
-
- Step 2 of 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.
-
-DNSEXT Working Group Expires July 9, 2006 [Page 10]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- 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.
-
-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."
-
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 11]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
-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
-
-
-
-
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 12]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
-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' prior to the
- instructions to "go to step 6":
-
- 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.
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 13]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- 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 asterisk label only becomes
- significant when section 4.3.2, step 3 part 'c' is 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 RRSet 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) have become unclear.
-
- Salient points of the working group discussion on this topic is
- summarized in section 4.2.1.
-
- As a result of these discussion, 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.2.1 Discarded Notions
-
- Prior to DNSSEC, a wild card domain name owning a NS RRSet
- appeared to be workable, and there are some instances in which
- it is found in deployments using implementations that support
- this. Continuing to allow this in the specification is not
- tenable with DNSSEC. The reason is that the synthesis of the
- NS RRSet is being done in a zone that has delegated away the
- responsibility for the name. This "unauthorized" synthesis is
- not a problem for the base DNS protocol, but DNSSEC, in affirming
- the authorization model for DNS exposes the problem.
-
-DNSEXT Working Group Expires July 9, 2006 [Page 14]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- Outright banning of wildcards of type NS is also untenable as
- the DNS protocol does not define how to handle "illegal" data.
- Implementations may choose not to load a zone, but there is no
- protocol definition. The lack of the definition is complicated
- by having to cover dynamic update [RFC 2136], zone transfers,
- as well as loading at the master server. The case of a client
- (resolver, caching server) getting a wildcard of type NS in
- a reply would also have to be considered.
-
- Given the daunting challenge of a complete definition of how to
- ban such records, dealing with existing implementations that
- permit the records today is a further complication. There are
- uses of wild card domain name owning NS RRSets.
-
- One compromise proposed would have redefined wildcards of type
- NS to not be used in synthesis, this compromise fell apart
- because it would have required significant edits to the DNSSEC
- signing and validation work. (Again, DNSSEC catches
- unauthorized data.)
-
- With no clear consensus forming on the solution to this dilemma,
- and the realization that wildcards of type NS are a rarity in
- operations, the best course of action is to leave this open-ended
- until "it matters."
-
-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 [RFC2672] 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.example.net."
- and another cache obtains:
- "b.example. DNAME foo.bar.example.net."
- both generated from the record:
- "*.example. DNAME foo.bar.example.net."
- by an authoritative server.
-
-DNSEXT Working Group Expires July 9, 2006 [Page 15]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- 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 the owner 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 is 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. This statement is made in the context that an NS RRSet
- at a wild card domain name is undefined. At a non-delegation
-
-DNSEXT Working Group Expires July 9, 2006 [Page 16]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- point, a DS RRSet has no value (no corresponding DNSKEY RRSet
- will be used in DNSSEC validation). If there is a synthesized
- DS RRSet, it alone will not be very useful as it exists in the
- context of a delegation point.
-
-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. [RFC2308]
-
-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
-
-DNSEXT Working Group Expires July 9, 2006 [Page 17]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
- [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
-
- [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
- M. Andrews, March 1998
-
- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
- August 1999.
-
- [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
-
- 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.
-
-
-
-
-
-
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 17]
-\f
-Internet-Draft dnsext-wcard January 9, 2006
-
-10. Trailing Boilerplate
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- 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 July 9, 2006.
-
-
-
-DNSEXT Working Group Expires July 9, 2006 [Page 19]
+++ /dev/null
-
-
-
-DNS Operations M. Larson
-Internet-Draft P. Barber
-Expires: August 14, 2006 VeriSign
- February 10, 2006
-
-
- Observed DNS Resolution Misbehavior
- draft-ietf-dnsop-bad-dns-res-05
-
-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 August 14, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This memo describes DNS iterative resolver behavior that results in a
- significant query volume sent to the root and top-level domain (TLD)
- name servers. We offer implementation advice to iterative resolver
- developers to alleviate these unnecessary queries. The
- recommendations made in this document are a direct byproduct of
- observation and analysis of abnormal query traffic patterns seen at
- two of the thirteen root name servers and all thirteen com/net TLD
- name servers.
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 1]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- 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 . . . . . . . . . . . . . 7
- 2.2.1. Recommendation . . . . . . . . . . . . . . . . . . . . 7
- 2.3. Inability to follow multiple levels of indirection . . . . 8
- 2.3.1. Recommendation . . . . . . . . . . . . . . . . . . . . 9
- 2.4. Aggressive retransmission when fetching glue . . . . . . . 9
- 2.4.1. Recommendation . . . . . . . . . . . . . . . . . . . . 10
- 2.5. Aggressive retransmission behind firewalls . . . . . . . . 10
- 2.5.1. Recommendation . . . . . . . . . . . . . . . . . . . . 11
- 2.6. Misconfigured NS records . . . . . . . . . . . . . . . . . 11
- 2.6.1. Recommendation . . . . . . . . . . . . . . . . . . . . 12
- 2.7. Name server records with zero TTL . . . . . . . . . . . . 12
- 2.7.1. Recommendation . . . . . . . . . . . . . . . . . . . . 13
- 2.8. Unnecessary dynamic update messages . . . . . . . . . . . 13
- 2.8.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14
- 2.9. Queries for domain names resembling IPv4 addresses . . . . 14
- 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14
- 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15
- 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
- 2.11. Suboptimal name server selection algorithm . . . . . . . . 15
- 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
- 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
- 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
- 5. Security considerations . . . . . . . . . . . . . . . . . . . 19
- 6. Internationalization considerations . . . . . . . . . . . . . 20
- 7. Informative References . . . . . . . . . . . . . . . . . . . . 20
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
- Intellectual Property and Copyright Statements . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 2]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
-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 indirection 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. None of the changes recommended affects the core DNS protocol
- specification; instead, this document consists of guidelines to
- implementors of iterative resolvers.
-
-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
- to answer questions about certain zones authoritatively. This entity
- is an iterative resolver combined with an authoritative name server
- and is often called a "recursive name server" or a "caching 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",
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 3]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- because the focus is usually on that component. In instances where
- the name server role of this entity requires mentioning, this memo
- uses the term "recursive name server". As an example of the
- difference, 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 record" to
- encompass both A and AAAA records when a particular situation is
- relevant to both types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 4]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
-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. (Note
- that queries with QTYPE=NS are not required by the standard
- resolution algorithm described in section 4.3.2 of RFC 1034 [2].
- These NS queries represent this implementation's addition to that
- algorithm.)
-
- 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 would be pointless: this query to the parent would come so
- quickly on the heels of the referral that it would be almost certain
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 5]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- 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
- 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 [3], 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.
-
- This section should not be understood to claim that all queries to a
- zone's parent are bad. In some cases, such queries are not only
- reasonable but required. Consider the situation when required
- information, such as the address of a name server (i.e., the address
- record corresponding to the RDATA of an NS record), has timed out of
- an iterative resolver's cache before the corresponding NS record. If
- the name of the name server is below the apex of the zone, then the
- name server's address record is only available as glue in the parent
- zone. For example, consider this NS record:
-
- example.com. IN NS ns.example.com.
-
- If a cache has this NS record but not the address record for
- "ns.example.com", it is unable to contact the "example.com" zone
- directly and must query the "com" zone to obtain the address record.
- Note, however, that such a query would not have QTYPE=NS according to
- the standard resolution algorithm.
-
-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
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 6]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- 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 [4].
-
-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
- 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.
-
- It should also be noted, however, that some authoritative name server
- implementations appear to be lame only for queries of certain types
- as described in RFC 4074 [5]. In this case, it makes sense to retry
- the "lame" servers for other types of queries, particularly when all
- known authoritative name servers appear to be "lame".
-
-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).
- If this caching is performed, 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.
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 7]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- 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.
-
- An exception to this recommendation occurs if all name servers for a
- zone are marked lame. In that case, the iterative resolver SHOULD
- temporarily ignore the servers' lameness status and query one or more
- servers. This behavior is a workaround for the type-specific
- lameness issue described in the previous section.
-
- Implementors should take care not to make lame server avoidance logic
- overly broad: note that a name server could be lame for a parent zone
- but not a child zone, e.g., lame for "example.com" but properly
- authoritative for "sub.example.com". Therefore a name server should
- not be automatically considered lame for subzones. In the case
- above, even if a name server is known to be lame for "example.com",
- it should be queried for QNAMEs at or below "sub.example.com" if an
- NS record indicates it should be authoritative for that zone.
-
-2.3. Inability to follow multiple levels of indirection
-
- Some iterative resolver implementations are unable to follow
- sufficient levels of indirection. 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 existing gTLDs, increasing the
- number of delegations using out-of-zone name servers.
-
-
-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 8]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
-2.3.1. Recommendation
-
- Clearly constructing a delegation that relies on multiple levels of
- indirection is not a good administrative practice. However, the
- practice is widespread enough to require that iterative resolvers be
- able to cope with it. Iterative resolvers SHOULD be able to handle
- arbitrary levels of indirection resulting from out-of-zone name
- servers. Iterative resolvers SHOULD implement a level-of-effort
- counter to avoid loops or otherwise performing too much work in
- resolving pathological cases.
-
- A best practice that avoids this entire issue of indirection is to
- name one or more of a zone's name servers in the zone itself. For
- example, if the zone is named "example.com", consider naming some of
- the name servers "ns{1,2,...}.example.com" (or similar).
-
-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
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 9]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- 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
- 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
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 10]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- servers, which could explain how such a situation could persist
- without being detected.
-
-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 [3], 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"
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 11]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- authoritative server.
-
- But the "example.com" zone contains the erroneous NS RRset as shown
- 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 apex 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.
-
- An authoritative name server SHOULD issue a warning when one of a
- zone's NS records references a name server below the zone's apex when
- a corresponding address record does not exist in the zone AND there
- are no delegated subzones where the address record could exist.
-
-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
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 12]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- zone parent/child relationships we are aware of, there is typically
- some delay involved in effecting changes. Further, changes to the
- 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.
-
-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-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 13]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- public TLD or root zones that would be the appropriate targets for a
- dynamic update.
-
- 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 names 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 IPv4 addresses
-
- The root name servers receive a significant number of A record
- queries where the QNAME looks like an IPv4 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
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 14]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- bandwidth. A possible solution 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 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. Of course, the proper and usual root zone
- change procedures would have to be followed to make such a change to
- the root zone.
-
-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
- 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.
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 15]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
- 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 August 14, 2006 [Page 16]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
-3. Acknowledgments
-
- The authors would like to thank the following people for their
- comments that improved this document: Andras Salamon, Dave Meyer,
- Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
- Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein. We
- apologize if we have omitted anyone; any oversight was unintentional.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 17]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
-4. IANA considerations
-
- There are no new IANA considerations introduced by this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 18]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
-5. Security considerations
-
- The iterative resolver misbehavior discussed in this document exposes
- the root and TLD name servers to increased risk of both intentional
- and unintentional denial of service attacks.
-
- 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 August 14, 2006 [Page 19]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
-6. Internationalization considerations
-
- There are no new internationalization considerations introduced by
- this memo.
-
-7. Informative 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] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
- [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
- Queries for IPv6 Addresses", RFC 4074, May 2005.
-
- [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>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 20]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
-Authors' Addresses
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- Email: mlarson@verisign.com
-
-
- Piet Barber
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- Email: pbarber@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 21]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior February 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Larson & Barber Expires August 14, 2006 [Page 22]
-\f
+++ /dev/null
-
-
-
-Network Working Group M. Andrews
-Internet-Draft ISC
-Intended status: BCP June 5, 2008
-Expires: December 7, 2008
-
-
- Locally-served DNS Zones
- draft-ietf-dnsop-default-local-zones-05
-
-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 December 7, 2008.
-
-Abstract
-
- Experience has shown that there are a number of DNS zones all
- iterative resolvers and recursive nameservers should, unless
- configured otherwise, automatically serve. RFC 4193 specifies that
- this should occur for D.F.IP6.ARPA. This document extends the
- practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space
- and other well known zones with similar characteristics.
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 1]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4
- 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4
- 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5
- 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5
- 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6
- 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6
- 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6
- 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7
- 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
- Appendix A. Change History [To Be Removed on Publication] . . . . 10
- A.1. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 10
- A.2. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 10
- A.3. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10
- A.4. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10
- A.5. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11
- A.6. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11
- A.7. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11
- A.8. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11
- Appendix B. Proposed Status [To Be Removed on Publication] . . . 11
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
- Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 2]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-1. Introduction
-
- Experience has shown that there are a number of DNS [RFC 1034] [RFC
- 1035] zones that all iterative resolvers and recursive nameservers
- SHOULD, unless intentionally configured otherwise, automatically
- serve. These zones include, but are not limited to, the IN-ADDR.ARPA
- zones for the address space allocated by [RFC 1918] and the IP6.ARPA
- zones for locally assigned unique local IPv6 addresses, [RFC 4193].
-
- This recommendation is made because data has shown that significant
- leakage of queries for these name spaces is occurring, despite
- instructions to restrict them, and because it has therefore become
- necessary to deploy sacrificial name servers to protect the immediate
- parent name servers for these zones from excessive, unintentional,
- query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every
- expectation that the query load will continue to increase unless
- steps are taken as outlined here.
-
- Additionally, queries from clients behind badly configured firewalls
- that allow outgoing queries for these name spaces but drop the
- responses, put a significant load on the root servers (forward but no
- reverse zones configured). They also cause operational load for the
- root server operators as they have to reply to enquiries about why
- the root servers are "attacking" these clients. Changing the default
- configuration will address all these issues for the zones listed in
- Section 4.
-
- [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled
- locally. This document extends the recommendation to cover the IN-
- ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and
- IP6.ARPA zones for which queries should not appear on the public
- Internet.
-
- It is hoped that by doing this the number of sacrificial servers
- [AS112] will not have to be increased, and may in time be reduced.
-
- This recommendation should also help DNS responsiveness for sites
- which are using [RFC 1918] addresses but do not follow the last
- paragraph in Section 3 of [RFC 1918].
-
-1.1. 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].
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 3]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-2. Effects on sites using RFC 1918 addresses.
-
- For most sites using [RFC 1918] addresses, the changes here will have
- little or no detrimental effect. If the site does not already have
- the reverse tree populated the only effect will be that the name
- error responses will be generated locally rather than remotely.
-
- For sites that do have the reverse tree populated, most will either
- have a local copy of the zones or will be forwarding the queries to
- servers which have local copies of the zone. Therefore this
- recommendation will not be relevant.
-
- The most significant impact will be felt at sites that make use of
- delegations for [RFC 1918] addresses and have populated these zones.
- These sites will need to override the default configuration expressed
- in this document to allow resolution to continue. Typically, such
- sites will be fully disconnected from the Internet and have their own
- root servers for their own non-Internet DNS tree.
-
-
-3. Changes to Iterative Resolver Behaviour.
-
- Unless configured otherwise, an iterative resolver will now return
- authoritatively (aa=1) name errors (RCODE=3) for queries within the
- zones in Section 4, with the obvious exception of queries for the
- zone name itself where SOA, NS and "no data" responses will be
- returned as appropriate to the query type. One common way to do this
- is to serve empty (SOA and NS only) zones.
-
- An implementation of this recommendation MUST provide a mechanism to
- disable this new behaviour, and SHOULD allow this decision on a zone
- by zone basis.
-
- If using empty zones one SHOULD NOT use the same NS and SOA records
- as used on the public Internet servers as that will make it harder to
- detect the origin of the responses and thus any leakage to the public
- Internet servers. This document recommends that the NS record
- defaults to the name of the zone and the SOA MNAME defaults to the
- name of the only NS RR's target. The SOA RNAME should default to
- "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a
- mechanism to set these values. No address records need to be
- provided for the name server.
-
- Below is an example of a generic empty zone in master file format.
- It will produce a negative cache TTL of 3 hours.
-
- @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
- @ 10800 IN NS @
-
-
-
-Andrews Expires December 7, 2008 [Page 4]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- The SOA RR is needed to support negative caching [RFC 2308] of name
- error responses and to point clients to the primary master for DNS
- dynamic updates.
-
- SOA values of particular importance are the MNAME, the SOA RR's TTL
- and the negTTL value. Both TTL values SHOULD match. The rest of the
- SOA timer values MAY be chosen arbitrarily since they are not
- intended to control any zone transfer activity.
-
- The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries
- to discover the zone to be updated. Having no address records for
- the name server is expected to abort UPDATE processing in the client.
-
-
-4. Lists Of Zones Covered
-
- The following subsections are intended to seed the IANA registry as
- requested in the IANA Considerations Section. The zone name is the
- entity to be registered.
-
-4.1. RFC 1918 Zones
-
- The following zones correspond to the IPv4 address space reserved in
- [RFC 1918].
-
- +----------------------+
- | Zone |
- +----------------------+
- | 10.IN-ADDR.ARPA |
- | 16.172.IN-ADDR.ARPA |
- | 17.172.IN-ADDR.ARPA |
- | 18.172.IN-ADDR.ARPA |
- | 19.172.IN-ADDR.ARPA |
- | 20.172.IN-ADDR.ARPA |
- | 21.172.IN-ADDR.ARPA |
- | 22.172.IN-ADDR.ARPA |
- | 23.172.IN-ADDR.ARPA |
- | 24.172.IN-ADDR.ARPA |
- | 25.172.IN-ADDR.ARPA |
- | 26.172.IN-ADDR.ARPA |
- | 27.172.IN-ADDR.ARPA |
- | 28.172.IN-ADDR.ARPA |
- | 29.172.IN-ADDR.ARPA |
- | 30.172.IN-ADDR.ARPA |
- | 31.172.IN-ADDR.ARPA |
- | 168.192.IN-ADDR.ARPA |
- +----------------------+
-
-
-
-
-Andrews Expires December 7, 2008 [Page 5]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-4.2. RFC 3330 Zones
-
- The following zones correspond to those address ranges from [RFC
- 3330] that are not expected to appear as source or destination
- addresses on the public Internet and to not have a unique name to
- associate with.
-
- The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
- attempt to discourage any practice to provide a PTR RR for
- 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse
- mapping should exist, but the exact setup is out of the scope of this
- document. Similar logic applies to the reverse mapping for ::1
- (Section 4.3). The recommendations made here simply assume no other
- coverage for these domains exists.
-
- +------------------------------+------------------------+
- | Zone | Description |
- +------------------------------+------------------------+
- | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
- | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK |
- | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
- | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET |
- | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
- +------------------------------+------------------------+
-
-4.3. Local IPv6 Unicast Addresses
-
- The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for
- the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291],
- Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
-
- +-------------------------------------------+
- | Zone |
- +-------------------------------------------+
- | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
- | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
- | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
- | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
- +-------------------------------------------+
-
- Note: Line breaks and a escapes '\' have been inserted above for
- readability and to adhere to line width constraints. They are not
- parts of the zone names.
-
-4.4. IPv6 Locally Assigned Local Addresses
-
- Section 4.4 of [RFC 4193] already required special treatment of:
-
-
-
-
-Andrews Expires December 7, 2008 [Page 6]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- +--------------+
- | Zone |
- +--------------+
- | D.F.IP6.ARPA |
- +--------------+
-
-4.5. IPv6 Link Local Addresses
-
- IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered
- by four distinct reverse DNS zones:
-
- +----------------+
- | Zone |
- +----------------+
- | 8.E.F.IP6.ARPA |
- | 9.E.F.IP6.ARPA |
- | A.E.F.IP6.ARPA |
- | B.E.F.IP6.ARPA |
- +----------------+
-
-
-5. Zones that are Out-Of-Scope
-
- IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and
- IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered
- here. It is expected that IPv6 site-local addresses will be self
- correcting as IPv6 implementations remove support for site-local
- addresses. However, sacrificial servers for C.E.F.IP6.ARPA through
- F.E.F.IP6.ARPA may still need to be deployed in the short term if the
- traffic becomes excessive.
-
- For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193],
- there has been no decision made about whether the Regional Internet
- Registries (RIRs) will provide delegations in this space or not. If
- they don't, then C.F.IP6.ARPA will need to be added to the list in
- Section 4.4. If they do, then registries will need to take steps to
- ensure that name servers are provided for these addresses.
-
- This document also ignores IP6.INT. IP6.INT has been wound up with
- only legacy resolvers now generating reverse queries under IP6.INT
- [RFC 4159].
-
- This document has also deliberately ignored names immediately under
- the root domain. While there is a subset of queries to the root name
- servers which could be addressed using the techniques described here
- (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
- amount of traffic that requires a different strategy (e.g. lookups
- for unqualified hostnames, IPv6 addresses).
-
-
-
-Andrews Expires December 7, 2008 [Page 7]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-6. IANA Considerations
-
- This document requests that IANA establish a registry of zones which
- require this default behaviour. The initial contents of which are in
- Section 4. Implementors are encouraged to check this registry and
- adjust their implementations to reflect changes therein.
-
- This registry can be amended through "IETF Consensus" as per [RFC
- 2434].
-
- IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
- deployed in the reverse tree, delegations for these zones are made in
- the manner described in Section 7.
-
-
-7. Security Considerations
-
- During the initial deployment phase, particularly where [RFC 1918]
- addresses are in use, there may be some clients that unexpectedly
- receive a name error rather than a PTR record. This may cause some
- service disruption until their recursive name server(s) have been re-
- configured.
-
- As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
- namespaces, the zones listed above will need to be delegated as
- insecure delegations, or be within insecure zones. This will allow
- DNSSEC validation to succeed for queries in these spaces despite not
- being answered from the delegated servers.
-
- It is recommended that sites actively using these namespaces secure
- them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
- anchors. This will protect the clients from accidental import of
- unsigned responses from the Internet.
-
-
-8. Acknowledgements
-
- This work was supported by the US National Science Foundation
- (research grant SCI-0427144) and DNS-OARC.
-
-
-9. References
-
-9.1. Normative References
-
- [RFC 1034]
- Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- STD 13, RFC 1034, November 1987.
-
-
-
-Andrews Expires December 7, 2008 [Page 8]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- [RFC 1035]
- Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION", STD 13, RFC 1035, November 1987.
-
- [RFC 1918]
- Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
- and E. Lear, "Address Allocation for Private Internets",
- BCP 5, RFC 1918, February 1996.
-
- [RFC 2119]
- Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2136]
- Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC 2308]
- Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2398, March 1998.
-
- [RFC 2434]
- Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC 2606]
- Eastlake, D. and A. Panitz, "Reserved Top Level DNS
- Names", BCP 32, RFC 2606, June 1999.
-
- [RFC 3596]
- Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
- "DNS Extensions to Support IPv6", RFC 3596, October 2003.
-
- [RFC 4035]
- Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC 4159]
- Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
- August 2005.
-
- [RFC 4193]
- Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
- Addresses", RFC 4193, October 2005.
-
-
-
-
-Andrews Expires December 7, 2008 [Page 9]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- [RFC 4291]
- Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
-9.2. Informative References
-
- [AS112] "AS112 Project", <http://www.as112.net/>.
-
- [I-D.draft-ietf-dnsop-as112-ops]
- Abley, J. and W. Maton, "AS112 Nameserver Operations",
- draft-ietf-dnsop-as112-ops-00 (work in progress),
- February 2007.
-
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
- Abley, J. and W. Maton, "I'm Being Attacked by
- PRISONER.IANA.ORG!",
- draft-ietf-dnsop-as112-under-attack-help-help-00 (work in
- progress), February 2007.
-
- [RFC 3330]
- "Special-Use IPv4 Addresses", RFC 3330, September 2002.
-
-
-Appendix A. Change History [To Be Removed on Publication]
-
-A.1. draft-ietf-dnsop-default-local-zones-05.txt
-
- none, expiry prevention
-
-A.2. draft-ietf-dnsop-default-local-zones-04.txt
-
- Centrally Assigned Local addresses -> Non-Locally Assigned Local
- address
-
-A.3. draft-ietf-dnsop-default-local-zones-03.txt
-
- expanded section 4 descriptions
-
- Added references [RFC 2136], [RFC 3596],
- [I-D.draft-ietf-dnsop-as112-ops] and
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
-
- Revised language.
-
-A.4. draft-ietf-dnsop-default-local-zones-02.txt
-
- RNAME now "nobody.invalid."
-
-
-
-
-Andrews Expires December 7, 2008 [Page 10]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- Revised language.
-
-A.5. draft-ietf-dnsop-default-local-zones-01.txt
-
- Revised impact description.
-
- Updated to reflect change in IP6.INT status.
-
-A.6. draft-ietf-dnsop-default-local-zones-00.txt
-
- Adopted by DNSOP.
-
- "Author's Note" re-titled "Zones that are Out-Of-Scope"
-
- Add note that these zone are expected to seed the IANA registry.
-
- Title changed.
-
-A.7. draft-andrews-full-service-resolvers-03.txt
-
- Added "Proposed Status".
-
-A.8. draft-andrews-full-service-resolvers-02.txt
-
- Added 0.IN-ADDR.ARPA.
-
-
-Appendix B. Proposed Status [To Be Removed on Publication]
-
- This Internet-Draft is being submitted for eventual publication as an
- RFC with a proposed status of Best Current Practice.
-
-
-Author's Address
-
- Mark P. Andrews
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- US
-
- Email: Mark_Andrews@isc.org
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 11]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- 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, THE IETF TRUST 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.
-
-
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 12]
-\f
+++ /dev/null
-
-
-
-
-
-
- DNSOP Working Group Paul Vixie, ISC
- INTERNET-DRAFT Akira Kato, WIDE
- <draft-ietf-dnsop-respsize-06.txt> August 2006
-
- DNS Referral Response Size Issues
-
- 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.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2006). 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, and suggests ways to optimize the use of
- this limited space. Guidance is offered to DNS server implementors
- and to DNS zone operators.
-
-
-
-
- Expires January 2007 [Page 1]
-\f
- INTERNET-DRAFT August 2006 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 IP
- reassembly limit for IPv4, it became a hard DNS protocol limit and is
- not implicitly relaxed by changes in transport, for example to IPv6.
-
- 1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
- larger responses by mutual agreement of the requester and responder.
- The 512 octet message size limit will remain in practical effect until
- there is widespread deployment of EDNS0 in DNS resolvers on the
- Internet.
-
- 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.
- Negative responses are quite small, but for positive and delegation
- responses, every octet must be carefully and sparingly allocated. This
- document specifically addresses delegation response sizes.
-
- 2 - Delegation Details
-
- 2.1. RELEVANT PROTOCOL ELEMENTS
-
- 2.1.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, or a CNAME/DNAME chain
- Authority Section: NS RRset (nameserver names)
- Additional Section: A and AAAA RRsets (nameserver addresses)
-
- 2.1.2. If the total response size exceeds 512 octets, and if the data
- that does not fit was "required", then the TC bit will be set
- (indicating truncation). This will usually cause the requester to retry
- using TCP, depending on what information was desired and what
- information was omitted. For example, truncation in the authority
- section is of no interest to a stub resolver who only plans to consume
- the answer section. If a retry using TCP is needed, the total cost of
- the transaction is much higher. See [RFC1123 6.1.3.2] for details on
- the requirement that UDP be attempted before falling back to TCP.
-
- 2.1.3. RRsets are never sent partially unless TC bit set to indicate
- truncation. When TC bit is set, the final apparent RRset in the final
- non-empty section must be considered "possibly damaged" (see [RFC1035
- 6.2], [RFC2181 9]).
-
-
-
- Expires January 2007 [Page 2]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- 2.1.4. With or without truncation, the glue present in the additional
- data section should be considered "possibly incomplete", and requesters
- should be prepared to re-query for any damaged or missing RRsets. Note
- that truncation of the additional data section might not be signalled
- via the TC bit since additional data is often optional (see discussion
- in [RFC4472 B]).
-
- 2.1.5. 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 (see [RFC1035
- 4.1.4]). If all nameserver names in a message share a common parent
- (for example, all ending in ".ROOT-SERVERS.NET"), then more space will
- be available for incompressable data (such as nameserver addresses).
-
- 2.1.6. The query name can be as long as 255 octets of network data. In
- this worst case scenario, the question section will be 259 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.2. ADVICE TO ZONE OWNERS
-
- 2.2.1. 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. Note that if the zone
- contains any wildcards, it is possible for maximum length queries to
- require positive responses, but that it is reasonable to expect
- truncation and TCP retry in that case. For cost and performance
- reasons, the majority of requests should be satisfied without truncation
- or TCP retry.
-
- 2.2.2. Some queries to non-existing names can be large, but this is not
- a problem because negative responses need not contain any answer,
- authority or additional records. See [RFC2308 2.1] for more information
- about the format of negative responses.
-
- 2.2.3. The minimum useful number of name servers is two, for redundancy
- (see [RFC1034 4.1]). A zone's name servers should be reachable by all
- IP transport protocols (e.g., IPv4 and IPv6) in common use.
-
- 2.2.4. The best case is no truncation at all. This is because many
- requesters will retry using TCP immediately, or will automatically re-
- query for RRsets that are possibly truncated, without considering
- whether the omitted data was actually necessary.
-
-
-
-
-
- Expires January 2007 [Page 3]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- 2.3. ADVICE TO SERVER IMPLEMENTORS
-
- 2.3.1. In case of multi-homed name servers, it is advantageous to
- include an address record from each of several name servers before
- including several address records for any one name server. If address
- records for more than one transport (for example, A and AAAA) are
- available, then it is advantageous to include records of both types
- early on, before the message is full.
-
- 2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
- class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
- Each A RR will require 16 octets, and each AAAA RR will require 28
- octets.
-
- 2.3.3. While DNS distinguishes between necessary and optional resource
- records, this distinction is according to protocol elements necessary to
- signify facts, and takes no official notice of protocol content
- necessary to ensure correct operation. For example, a nameserver name
- that is in or below the zone cut being described by a delegation is
- "necessary content," since there is no way to reach that zone unless the
- parent zone's delegation includes "glue records" describing that name
- server's addresses.
-
- 2.3.4. It is also necessary to distinguish between "explicit truncation"
- where a message could not contain enough records to convey its intended
- meaning, and so the TC bit has been set, and "silent truncation", where
- the message was not large enough to contain some records which were "not
- required", and so the TC bit was not set.
-
- 2.3.5. A delegation response should prioritize glue records as follows.
-
- first
- All glue RRsets for one name server whose name is in or below the
- zone being delegated, or which has multiple address RRsets (currently
- A and AAAA), or preferably both;
-
- second
- Alternate between adding all glue RRsets for any name servers whose
- names are in or below the zone being delegated, and all glue RRsets
- for any name servers who have multiple address RRsets (currently A
- and AAAA);
-
- thence
- All other glue RRsets, in any order.
-
-
-
-
- Expires January 2007 [Page 4]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- Whenever there are multiple candidates for a position in this priority
- scheme, one should be chosen on a round-robin or fully random basis.
-
- The goal of this priority scheme is to offer "necessary" glue first,
- avoiding silent truncation for this glue if possible.
-
- 2.3.6. If any "necessary content" is silently truncated, then it is
- advisable that the TC bit be set in order to force a TCP retry, rather
- than have the zone be unreachable. Note that a parent server's proper
- response to a query for in-child glue or below-child glue is a referral
- rather than an answer, and that this referral MUST be able to contain
- the in-child or below-child glue, and that in outlying cases, only EDNS
- or TCP will be large enough to contain that data.
-
- 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
-
-
-
-
-
-
-
-
- Expires January 2007 [Page 5]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- ;; 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
-
- 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, due to the use of DNS compression pointers in the last 12
- occurances of the parent domain name. The following output from a
- response simulator demonstrates these properties.
-
- % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
- a.dns.br requires 10 bytes
- b.dns.br requires 4 bytes
- c.dns.br requires 4 bytes
- d.dns.br requires 4 bytes
- # of NS: 4
- For maximum size query (255 byte):
- only A is considered: # of A is 4 (green)
- A and AAAA are considered: # of A+AAAA is 3 (yellow)
- preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
- For average size query (64 byte):
- only A is considered: # of A is 4 (green)
- A and AAAA are considered: # of A+AAAA is 4 (green)
- preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-
-
-
-
-
-
-
-
-
- Expires January 2007 [Page 6]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
- ns-ext.isc.org requires 16 bytes
- ns.psg.com requires 12 bytes
- ns.ripe.net requires 13 bytes
- ns.eu.int requires 11 bytes
- # of NS: 4
- For maximum size query (255 byte):
- only A is considered: # of A is 4 (green)
- A and AAAA are considered: # of A+AAAA is 3 (yellow)
- preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
- For average size query (64 byte):
- only A is considered: # of A is 4 (green)
- A and AAAA are considered: # of A+AAAA is 4 (green)
- preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
- (Note: The response simulator program is shown in Section 5.)
-
- Here we use the term "green" if all address records could fit, or
- "yellow" if two or more could fit, or "orange" if only one could fit, or
- "red" if no address record could fit. It's clear that without a common
- parent for nameserver names, much space would be lost. For these
- examples we use an average/common name size of 15 octets, befitting our
- assumption of GTLD-SERVERS.NET as our common parent name.
-
- We're assuming a medium query name size of 64 since that is the typical
- 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 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, since the common parent domain name only appears
- once in a DNS message and is referred to via "compression pointers"
- thereafter.
-
- 4.2. If all nameserver names for a zone share a common parent, then it
- is operationally advisable to make all servers for the zone thus served
- also be authoritative for the zone of that common parent. For example,
- the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
- for the ROOT-SERVERS.NET. This is to ensure that the zone's servers
- always have the zone's nameservers' glue available when delegating, and
-
-
-
- Expires January 2007 [Page 7]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- will be able to respond with answers rather than referrals if a
- requester who wants that glue comes back asking for it. In this case
- the name server will likely be a "stealth server" -- authoritative but
- unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more
- information about stealth servers.
-
- 4.3. Thirteen (13) is the effective maximum number of nameserver names
- usable traditional (non-extended) DNS, assuming a common parent domain
- name, and given that implicit referral response truncation is
- undesirable in the average case.
-
- 4.4. Multi-homing of name servers within a protocol family is
- inadvisable since the necessary glue RRsets (A or AAAA) are atomically
- indivisible, and will be larger than a single resource record. Larger
- RRsets are more likely to lead to or encounter truncation.
-
- 4.5. Multi-homing of name servers across protocol families is less
- likely to lead to or encounter truncation, partly because multiprotocol
- clients are more likely to speak EDNS which can use a larger response
- size limit, and partly because the resource records (A and AAAA) are in
- different RRsets and are therefore divisible from each other.
-
- 4.6. Name server names which are at or below the zone they serve are
- more sensitive to referral response truncation, and glue records for
- them should be considered "less optional" than other glue records, in
- the assembly of referral responses.
-
- 4.7. If a zone is served by thirteen (13) name servers having a common
- parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
- single address record in some protocol family (e.g., an A RR), then all
- thirteen name servers or any subset thereof could multi-home in a second
- protocol family by adding a second address record (e.g., an AAAA RR)
- without reducing the reachability of the zone thus served.
-
- 5 - Source Code
-
- #!/usr/bin/perl
- #
- # SYNOPSIS
- # repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
- # if all queries are assumed to have a same zone suffix,
- # such as "jp" in JP TLD servers, specify it in -z option
- #
- use strict;
- use Getopt::Std;
-
-
-
- Expires January 2007 [Page 8]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- my ($sz_msg) = (512);
- my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
- my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
- my (%namedb, $name, $nssect, %opts, $optz);
- my $n_ns = 0;
-
- getopt('z', %opts);
- if (defined($opts{'z'})) {
- server_name_len($opts{'z'}); # just register it
- }
-
- foreach $name (@ARGV) {
- my $len;
- $n_ns++;
- $len = server_name_len($name);
- print "$name requires $len bytes\n";
- $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
- + $sz_rdlen + $len;
- }
- print "# of NS: $n_ns\n";
- arsect(255, $nssect, $n_ns, "maximum");
- arsect(64, $nssect, $n_ns, "average");
-
- sub server_name_len {
- my ($name) = @_;
- my (@labels, $len, $n, $suffix);
-
- $name =~ tr/A-Z/a-z/;
- @labels = split(/\./, $name);
- $len = length(join('.', @labels)) + 2;
- for ($n = 0; $#labels >= 0; $n++, shift @labels) {
- $suffix = join('.', @labels);
- return length($name) - length($suffix) + $sz_ptr
- if (defined($namedb{$suffix}));
- $namedb{$suffix} = 1;
- }
- return $len;
- }
-
- sub arsect {
- my ($sz_query, $nssect, $n_ns, $cond) = @_;
- my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
- $ansect = $sz_query + 1 + $sz_type + $sz_class;
- $space = $sz_msg - $sz_header - $ansect - $nssect;
- $n_a = atmost(int($space / $sz_rr_a), $n_ns);
-
-
-
- Expires January 2007 [Page 9]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- $n_a_aaaa = atmost(int($space
- / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
- $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
- / $sz_rr_aaaa), $n_ns);
- printf "For %s size query (%d byte):\n", $cond, $sz_query;
- printf " only A is considered: ";
- printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
- printf " A and AAAA are considered: ";
- printf "# of A+AAAA is %d (%s)\n",
- $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
- printf " preferred-glue A is assumed: ";
- printf "# of A is %d, # of AAAA is %d (%s)\n",
- $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
- }
-
- sub judge {
- my ($n, $n_ns) = @_;
- return "green" if ($n >= $n_ns);
- return "yellow" if ($n >= 2);
- return "orange" if ($n == 1);
- return "red";
- }
-
- sub atmost {
- my ($a, $b) = @_;
- return 0 if ($a < 0);
- return $b if ($a > $b);
- return $a;
- }
-
- 6 - Security Considerations
-
- The recommendations contained in this document have no known security
- implications.
-
- 7 - IANA Considerations
-
- This document does not call for changes or additions to any IANA
- registry.
-
- 8 - Acknowledgement
-
- The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
- for their valuable comments and suggestions.
-
-
-
-
- Expires January 2007 [Page 10]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- This work was supported by the US National Science Foundation (research
- grant SCI-0427144) and DNS-OARC.
-
- 9 - References
-
- [RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
- RFC1034, November 1987.
-
- [RFC1035] Mockapetris, P.V., "Domain names - Implementation and
- Specification", RFC1035, November 1987.
-
- [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
- Application and Support", RFC1123, October 1989.
-
- [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
- Changes (DNS NOTIFY)", RFC1996, August 1996.
-
- [RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
- RFC2181, July 1997.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC2308, March 1998.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
- August 1999.
-
- [RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
- and Issues with IPV6 DNS", April 2006.
-
- 10 - Authors' Addresses
-
- Paul Vixie
- Internet Systems Consortium, Inc.
- 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 January 2007 [Page 11]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors retain
- all their rights.
-
- 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 provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
- Expires January 2007 [Page 12]
-\f
-
+++ /dev/null
-
-
-
-
-Network Working Group S. Woolf
-Internet-Draft Internet Systems Consortium, Inc.
-Expires: September 6, 2006 D. Conrad
- Nominum, Inc.
- March 5, 2006
-
-
- Requirements for a Mechanism Identifying a Name Server Instance
- draft-ietf-dnsop-serverid-06
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 6, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-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 for
- administrators. Existing ad hoc mechanisms for addressing this need
-
-
-
-Woolf & Conrad Expires September 6, 2006 [Page 1]
-\f
-Internet-Draft Serverid March 2006
-
-
- 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
- some widely deployed implementations of the DNS protocol, including
- advantages and disadvantages, and discusses some attributes of an
- improved mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 6, 2006 [Page 2]
-\f
-Internet-Draft Serverid March 2006
-
-
-1. Introduction and Rationale
-
- Identifying which name server is responding to queries is often
- useful, particularly in attempting to diagnose name server
- difficulties. This is most obviously useful for authoritative
- nameservers in the attempt to diagnose the source or prevalence of
- inaccurate data, but can also conceivably be useful for caching
- resolvers in similar and other situations. Furthermore, the ability
- to identify which server is responding to a query has become more
- useful as DNS has become more critical to more Internet users, and as
- network and server deployment topologies have become more complex.
-
- The traditional means for determining which of several possible
- servers is answering a query has traditionally been based on the use
- of the server's IP address as a unique identifier. However, the
- modern Internet has seen the deployment of various load balancing,
- fault-tolerance, or attack-resistance schemes such as shared use of
- unicast IP addresses as documented in [RFC3258]. An unfortunate side
- effect of these schemes has been to make the use of IP addresses as
- identifiers somewhat problematic. Specifically, a dedicated DNS
- query may not go to the same server as answered a previous query,
- even though sent to the same IP address. Non-DNS methods such as
- ICMP ping, TCP connections, or non-DNS UDP packets (such as those
- generated by tools like "traceroute"), etc., may well be even less
- certain to reach the same server as the one which receives the DNS
- queries.
-
- There is a well-known and frequently-used technique for determining
- an identity for a nameserver more specific than the possibly-non-
- unique "server that answered the query I sent to IP address XXX".
- 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 September 6, 2006 [Page 3]
-\f
-Internet-Draft Serverid March 2006
-
-
-2. Existing Conventions
-
- For some time, the commonly deployed Berkeley Internet Name Domain
- implementation of the DNS protocol suite from the Internet Systems
- Consortium [BIND] has supported a way of identifying a particular
- server via the use of a standards-compliant, if somewhat unusual, DNS
- query. Specifically, a query to a recent 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. (The value defaults to the result 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.
-
- A refinement to the BIND-based mechanism, which dropped the
- implementation-specific string, replaces ".BIND" with ".SERVER".
- Thus the query string to learn the unique name of a server may be
- queried as "ID.SERVER".
-
- (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 CHAOS TXT RR for this name will return an
- administratively defined string which defaults to the version of the
- server responding. This is, however, not generally implemented by
- other vendors.)
-
-2.1. Advantages
-
- There are several valuable attributes to this mechanism, which
- account for its usefulness.
-
- 1. The "HOSTNAME.BIND" or "ID.SERVER" query response 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 system as a
- "normal" DNS query.
-
- 2. Since the identity information is requested and returned within
- the DNS protocol, it doesn't require allowing any other query
- mechanism to the server, such as holes in firewalls for
- otherwise-unallowed ICMP Echo requests. Thus it is likely to
- reach the same server over a path subject to the same routing,
- resource, and security policy as the query, without any special
- exceptions to site security policy.
-
-
-
-
-
-Woolf & Conrad Expires September 6, 2006 [Page 4]
-\f
-Internet-Draft Serverid March 2006
-
-
- 3. It is simple to configure. An administrator can easily turn on
- this feature and control the results of the relevant query.
-
- 4. 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.
-
- 5. Hypothetically, since it's an ordinary DNS record and the
- relevant DNSSEC RRs are class independent, the id.server response
- RR could be signed, which has the advantages described in
- [RFC4033].
-
-2.2. Disadvantages
-
- At the same time, there are some serious drawbacks to the CHAOS/TXT
- query 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
- purpose is a good use of the namespace or of implementation
- effort.
-
- 3. The initial and still common form, using .BIND, is implementation
- specific. BIND is one DNS implementation. At the time of this
- writing, it is probably the most prevalent for authoritative
- servers. This does not justify standardizing on its ad hoc
- solution to a problem shared across many operators and
- implementors. Meanwhile, the proposed refinement changes the
- string but preserves the ad hoc CHAOS/TXT mechanism.
-
- 4. There is no convention or shared understanding of what
- information an answer to such a query for a server identity could
- or should include, including a possible encoding or
- authentication mechanism.
-
- The first of the listed disadvantages may be 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 September 6, 2006 [Page 5]
-\f
-Internet-Draft Serverid March 2006
-
-
-2.3. 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. But it should preserve the ability of
- the CHAOS/TXT query-based mechanism to work through firewalls and
- in other situations where only DNS can be relied upon to reach
- the server of interest.
-
- 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. In particular, it should not
- propagate the existing drawback of requiring support for a CLASS
- and top level domain in the authoritative server (or the querying
- tool) to be useful.
-
- 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. It should be possible to authenticate the received data by some
- mechanism analogous to those provided by DNSSEC. In this
- context, the need could be met by including encryption options in
- the specification of a new mechanism.
-
- 6. The identification mechanism should not be implementation-
- specific.
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 6, 2006 [Page 6]
-\f
-Internet-Draft Serverid March 2006
-
-
-3. 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. A proposed extension, specified and adopted by normal IETF
- process, is described in [NSID], including relevant IANA action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 6, 2006 [Page 7]
-\f
-Internet-Draft Serverid March 2006
-
-
-4. Security Considerations
-
- Providing identifying information as to which server is responding to
- a particular query from a particular location in the Internet 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.
-
- Both authentication and confidentiality of serverid data are
- potentially of interest to administrators-- that is, operators may
- wish to make serverid data available and reliable to themselves and
- their chosen associates only. This would imply both an ability to
- authenticate it to themselves and keep it private from arbitrary
- other parties. This led to Characteristics 4 and 5 of an improved
- solution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 6, 2006 [Page 8]
-\f
-Internet-Draft Serverid March 2006
-
-
-5. 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 version
- 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.
-
-6. References
-
- [1] Mockapetris, P., "Domain Names - Concepts and Facilities",
- RFC 1034, STD 0013, November 1987.
-
- [2] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, STD 0013, November 1987.
-
- [3] Hardie, T., "Distributing Authoritative Name Servers via Shared
- Unicast Addresses", RFC 3258, April 2002.
-
- [4] ISC, "BIND 9 Configuration Reference".
-
- [5] Austein, S., "DNS Name Server Identifier Option (NSID)",
- Internet Drafts http://www.ietf.org/internet-drafts/
- draft-ietf-dnsext-nsid-01.txt, January 2006.
-
- [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 6, 2006 [Page 9]
-\f
-Internet-Draft Serverid March 2006
-
-
-Authors' Addresses
-
- Suzanne Woolf
- Internet Systems Consortium, Inc.
- 950 Charter Street
- Redwood City, CA 94063
- US
-
- Phone: +1 650 423-1333
- Email: woolf@isc.org
- URI: http://www.isc.org/
-
-
- David Conrad
- Nominum, Inc.
- 2385 Bay Road
- Redwood City, CA 94063
- US
-
- Phone: +1 1 650 381 6003
- Email: david.conrad@nominum.com
- URI: http://www.nominum.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 6, 2006 [Page 10]
-\f
-Internet-Draft Serverid March 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Woolf & Conrad Expires September 6, 2006 [Page 11]
-\f
-
projects / thirdparty / bind9.git / commitdiff
