+++ /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
-
-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
-
-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
-
-
-
-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. Josefsson
-Request for Comments: 4648 SJD
-Obsoletes: 3548 October 2006
-Category: Standards Track
-
-
- The Base16, Base32, and Base64 Data Encodings
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes the commonly used base 64, base 32, and base
- 16 encoding schemes. It also discusses the use of line-feeds in
- encoded data, use of padding in encoded data, use of non-alphabet
- characters in encoded data, use of different encoding alphabets, and
- canonical encodings.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 1]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
-Table of Contents
-
- 1. Introduction ....................................................3
- 2. Conventions Used in This Document ...............................3
- 3. Implementation Discrepancies ....................................3
- 3.1. Line Feeds in Encoded Data .................................3
- 3.2. Padding of Encoded Data ....................................4
- 3.3. Interpretation of Non-Alphabet Characters in Encoded Data ..4
- 3.4. Choosing the Alphabet ......................................4
- 3.5. Canonical Encoding .........................................5
- 4. Base 64 Encoding ................................................5
- 5. Base 64 Encoding with URL and Filename Safe Alphabet ............7
- 6. Base 32 Encoding ................................................8
- 7. Base 32 Encoding with Extended Hex Alphabet ....................10
- 8. Base 16 Encoding ...............................................10
- 9. Illustrations and Examples .....................................11
- 10. Test Vectors ..................................................12
- 11. ISO C99 Implementation of Base64 ..............................14
- 12. Security Considerations .......................................14
- 13. Changes Since RFC 3548 ........................................15
- 14. Acknowledgements ..............................................15
- 15. Copying Conditions ............................................15
- 16. References ....................................................16
- 16.1. Normative References .....................................16
- 16.2. Informative References ...................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 2]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
-1. Introduction
-
- Base encoding of data is used in many situations to store or transfer
- data in environments that, perhaps for legacy reasons, are restricted
- to US-ASCII [1] data. Base encoding can also be used in new
- applications that do not have legacy restrictions, simply because it
- makes it possible to manipulate objects with text editors.
-
- In the past, different applications have had different requirements
- and thus sometimes implemented base encodings in slightly different
- ways. Today, protocol specifications sometimes use base encodings in
- general, and "base64" in particular, without a precise description or
- reference. Multipurpose Internet Mail Extensions (MIME) [4] is often
- used as a reference for base64 without considering the consequences
- for line-wrapping or non-alphabet characters. The purpose of this
- specification is to establish common alphabet and encoding
- considerations. This will hopefully reduce ambiguity in other
- documents, leading to better interoperability.
-
-2. Conventions Used in This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [2].
-
-3. Implementation Discrepancies
-
- Here we discuss the discrepancies between base encoding
- implementations in the past and, where appropriate, mandate a
- specific recommended behavior for the future.
-
-3.1. Line Feeds in Encoded Data
-
- MIME [4] is often used as a reference for base 64 encoding. However,
- MIME does not define "base 64" per se, but rather a "base 64 Content-
- Transfer-Encoding" for use within MIME. As such, MIME enforces a
- limit on line length of base 64-encoded data to 76 characters. MIME
- inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating
- that it is "virtually identical"; however, PEM uses a line length of
- 64 characters. The MIME and PEM limits are both due to limits within
- SMTP.
-
- Implementations MUST NOT add line feeds to base-encoded data unless
- the specification referring to this document explicitly directs base
- encoders to add line feeds after a specific number of characters.
-
-
-
-
-
-
-Josefsson Standards Track [Page 3]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
-3.2. Padding of Encoded Data
-
- In some circumstances, the use of padding ("=") in base-encoded data
- is not required or used. In the general case, when assumptions about
- the size of transported data cannot be made, padding is required to
- yield correct decoded data.
-
- Implementations MUST include appropriate pad characters at the end of
- encoded data unless the specification referring to this document
- explicitly states otherwise.
-
- The base64 and base32 alphabets use padding, as described below in
- sections 4 and 6, but the base16 alphabet does not need it; see
- section 8.
-
-3.3. Interpretation of Non-Alphabet Characters in Encoded Data
-
- Base encodings use a specific, reduced alphabet to encode binary
- data. Non-alphabet characters could exist within base-encoded data,
- caused by data corruption or by design. Non-alphabet characters may
- be exploited as a "covert channel", where non-protocol data can be
- sent for nefarious purposes. Non-alphabet characters might also be
- sent in order to exploit implementation errors leading to, e.g.,
- buffer overflow attacks.
-
- Implementations MUST reject the encoded data if it contains
- characters outside the base alphabet when interpreting base-encoded
- data, unless the specification referring to this document explicitly
- states otherwise. Such specifications may instead state, as MIME
- does, that characters outside the base encoding alphabet should
- simply be ignored when interpreting data ("be liberal in what you
- accept"). Note that this means that any adjacent carriage return/
- line feed (CRLF) characters constitute "non-alphabet characters" and
- are ignored. Furthermore, such specifications MAY ignore the pad
- character, "=", treating it as non-alphabet data, if it is present
- before the end of the encoded data. If more than the allowed number
- of pad characters is found at the end of the string (e.g., a base 64
- string terminated with "==="), the excess pad characters MAY also be
- ignored.
-
-3.4. Choosing the Alphabet
-
- Different applications have different requirements on the characters
- in the alphabet. Here are a few requirements that determine which
- alphabet should be used:
-
-
-
-
-
-
-Josefsson Standards Track [Page 4]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
- o Handled by humans. The characters "0" and "O" are easily
- confused, as are "1", "l", and "I". In the base32 alphabet below,
- where 0 (zero) and 1 (one) are not present, a decoder may
- interpret 0 as O, and 1 as I or L depending on case. (However, by
- default it should not; see previous section.)
-
- o Encoded into structures that mandate other requirements. For base
- 16 and base 32, this determines the use of upper- or lowercase
- alphabets. For base 64, the non-alphanumeric characters (in
- particular, "/") may be problematic in file names and URLs.
-
- o Used as identifiers. Certain characters, notably "+" and "/" in
- the base 64 alphabet, are treated as word-breaks by legacy text
- search/index tools.
-
- There is no universally accepted alphabet that fulfills all the
- requirements. For an example of a highly specialized variant, see
- IMAP [8]. In this document, we document and name some currently used
- alphabets.
-
-3.5. Canonical Encoding
-
- The padding step in base 64 and base 32 encoding can, if improperly
- implemented, lead to non-significant alterations of the encoded data.
- For example, if the input is only one octet for a base 64 encoding,
- then all six bits of the first symbol are used, but only the first
- two bits of the next symbol are used. These pad bits MUST be set to
- zero by conforming encoders, which is described in the descriptions
- on padding below. If this property do not hold, there is no
- canonical representation of base-encoded data, and multiple base-
- encoded strings can be decoded to the same binary data. If this
- property (and others discussed in this document) holds, a canonical
- encoding is guaranteed.
-
- In some environments, the alteration is critical and therefore
- decoders MAY chose to reject an encoding if the pad bits have not
- been set to zero. The specification referring to this may mandate a
- specific behaviour.
-
-4. Base 64 Encoding
-
- The following description of base 64 is derived from [3], [4], [5],
- and [6]. This encoding may be referred to as "base64".
-
- The Base 64 encoding is designed to represent arbitrary sequences of
- octets in a form that allows the use of both upper- and lowercase
- letters but that need not be human readable.
-
-
-
-
-Josefsson Standards Track [Page 5]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
- A 65-character subset of US-ASCII is used, enabling 6 bits to be
- represented per printable character. (The extra 65th character, "=",
- is used to signify a special processing function.)
-
- The encoding process represents 24-bit groups of input bits as output
- strings of 4 encoded characters. Proceeding from left to right, a
- 24-bit input group is formed by concatenating 3 8-bit input groups.
- These 24 bits are then treated as 4 concatenated 6-bit groups, each
- of which is translated into a single character in the base 64
- alphabet.
-
- Each 6-bit group is used as an index into an array of 64 printable
- characters. The character referenced by the index is placed in the
- output string.
-
- Table 1: The Base 64 Alphabet
-
- Value Encoding Value Encoding Value Encoding Value Encoding
- 0 A 17 R 34 i 51 z
- 1 B 18 S 35 j 52 0
- 2 C 19 T 36 k 53 1
- 3 D 20 U 37 l 54 2
- 4 E 21 V 38 m 55 3
- 5 F 22 W 39 n 56 4
- 6 G 23 X 40 o 57 5
- 7 H 24 Y 41 p 58 6
- 8 I 25 Z 42 q 59 7
- 9 J 26 a 43 r 60 8
- 10 K 27 b 44 s 61 9
- 11 L 28 c 45 t 62 +
- 12 M 29 d 46 u 63 /
- 13 N 30 e 47 v
- 14 O 31 f 48 w (pad) =
- 15 P 32 g 49 x
- 16 Q 33 h 50 y
-
- Special processing is performed if fewer than 24 bits are available
- at the end of the data being encoded. A full encoding quantum is
- always completed at the end of a quantity. When fewer than 24 input
- bits are available in an input group, bits with value zero are added
- (on the right) to form an integral number of 6-bit groups. Padding
- at the end of the data is performed using the '=' character. Since
- all base 64 input is an integral number of octets, only the following
- cases can arise:
-
- (1) The final quantum of encoding input is an integral multiple of 24
- bits; here, the final unit of encoded output will be an integral
- multiple of 4 characters with no "=" padding.
-
-
-
-Josefsson Standards Track [Page 6]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
- (2) The final quantum of encoding input is exactly 8 bits; here, the
- final unit of encoded output will be two characters followed by
- two "=" padding characters.
-
- (3) The final quantum of encoding input is exactly 16 bits; here, the
- final unit of encoded output will be three characters followed by
- one "=" padding character.
-
-5. Base 64 Encoding with URL and Filename Safe Alphabet
-
- The Base 64 encoding with an URL and filename safe alphabet has been
- used in [12].
-
- An alternative alphabet has been suggested that would use "~" as the
- 63rd character. Since the "~" character has special meaning in some
- file system environments, the encoding described in this section is
- recommended instead. The remaining unreserved URI character is ".",
- but some file system environments do not permit multiple "." in a
- filename, thus making the "." character unattractive as well.
-
- The pad character "=" is typically percent-encoded when used in an
- URI [9], but if the data length is known implicitly, this can be
- avoided by skipping the padding; see section 3.2.
-
- This encoding may be referred to as "base64url". This encoding
- should not be regarded as the same as the "base64" encoding and
- should not be referred to as only "base64". Unless clarified
- otherwise, "base64" refers to the base 64 in the previous section.
-
- This encoding is technically identical to the previous one, except
- for the 62:nd and 63:rd alphabet character, as indicated in Table 2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 7]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
- Table 2: The "URL and Filename safe" Base 64 Alphabet
-
- Value Encoding Value Encoding Value Encoding Value Encoding
- 0 A 17 R 34 i 51 z
- 1 B 18 S 35 j 52 0
- 2 C 19 T 36 k 53 1
- 3 D 20 U 37 l 54 2
- 4 E 21 V 38 m 55 3
- 5 F 22 W 39 n 56 4
- 6 G 23 X 40 o 57 5
- 7 H 24 Y 41 p 58 6
- 8 I 25 Z 42 q 59 7
- 9 J 26 a 43 r 60 8
- 10 K 27 b 44 s 61 9
- 11 L 28 c 45 t 62 - (minus)
- 12 M 29 d 46 u 63 _
- 13 N 30 e 47 v (underline)
- 14 O 31 f 48 w
- 15 P 32 g 49 x
- 16 Q 33 h 50 y (pad) =
-
-6. Base 32 Encoding
-
- The following description of base 32 is derived from [11] (with
- corrections). This encoding may be referred to as "base32".
-
- The Base 32 encoding is designed to represent arbitrary sequences of
- octets in a form that needs to be case insensitive but that need not
- be human readable.
-
- A 33-character subset of US-ASCII is used, enabling 5 bits to be
- represented per printable character. (The extra 33rd character, "=",
- is used to signify a special processing function.)
-
- The encoding process represents 40-bit groups of input bits as output
- strings of 8 encoded characters. Proceeding from left to right, a
- 40-bit input group is formed by concatenating 5 8bit input groups.
- These 40 bits are then treated as 8 concatenated 5-bit groups, each
- of which is translated into a single character in the base 32
- alphabet. When a bit stream is encoded via the base 32 encoding, the
- bit stream must be presumed to be ordered with the most-significant-
- bit first. That is, the first bit in the stream will be the high-
- order bit in the first 8bit byte, the eighth bit will be the low-
- order bit in the first 8bit byte, and so on.
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 8]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
- Each 5-bit group is used as an index into an array of 32 printable
- characters. The character referenced by the index is placed in the
- output string. These characters, identified in Table 3, below, are
- selected from US-ASCII digits and uppercase letters.
-
- Table 3: The Base 32 Alphabet
-
- Value Encoding Value Encoding Value Encoding Value Encoding
- 0 A 9 J 18 S 27 3
- 1 B 10 K 19 T 28 4
- 2 C 11 L 20 U 29 5
- 3 D 12 M 21 V 30 6
- 4 E 13 N 22 W 31 7
- 5 F 14 O 23 X
- 6 G 15 P 24 Y (pad) =
- 7 H 16 Q 25 Z
- 8 I 17 R 26 2
-
- Special processing is performed if fewer than 40 bits are available
- at the end of the data being encoded. A full encoding quantum is
- always completed at the end of a body. When fewer than 40 input bits
- are available in an input group, bits with value zero are added (on
- the right) to form an integral number of 5-bit groups. Padding at
- the end of the data is performed using the "=" character. Since all
- base 32 input is an integral number of octets, only the following
- cases can arise:
-
- (1) The final quantum of encoding input is an integral multiple of 40
- bits; here, the final unit of encoded output will be an integral
- multiple of 8 characters with no "=" padding.
-
- (2) The final quantum of encoding input is exactly 8 bits; here, the
- final unit of encoded output will be two characters followed by
- six "=" padding characters.
-
- (3) The final quantum of encoding input is exactly 16 bits; here, the
- final unit of encoded output will be four characters followed by
- four "=" padding characters.
-
- (4) The final quantum of encoding input is exactly 24 bits; here, the
- final unit of encoded output will be five characters followed by
- three "=" padding characters.
-
- (5) The final quantum of encoding input is exactly 32 bits; here, the
- final unit of encoded output will be seven characters followed by
- one "=" padding character.
-
-
-
-
-
-Josefsson Standards Track [Page 9]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
-7. Base 32 Encoding with Extended Hex Alphabet
-
- The following description of base 32 is derived from [7]. This
- encoding may be referred to as "base32hex". This encoding should not
- be regarded as the same as the "base32" encoding and should not be
- referred to as only "base32". This encoding is used by, e.g.,
- NextSECure3 (NSEC3) [10].
-
- One property with this alphabet, which the base64 and base32
- alphabets lack, is that encoded data maintains its sort order when
- the encoded data is compared bit-wise.
-
- This encoding is identical to the previous one, except for the
- alphabet. The new alphabet is found in Table 4.
-
- Table 4: The "Extended Hex" Base 32 Alphabet
-
- Value Encoding Value Encoding Value Encoding Value Encoding
- 0 0 9 9 18 I 27 R
- 1 1 10 A 19 J 28 S
- 2 2 11 B 20 K 29 T
- 3 3 12 C 21 L 30 U
- 4 4 13 D 22 M 31 V
- 5 5 14 E 23 N
- 6 6 15 F 24 O (pad) =
- 7 7 16 G 25 P
- 8 8 17 H 26 Q
-
-8. Base 16 Encoding
-
- The following description is original but analogous to previous
- descriptions. Essentially, Base 16 encoding is the standard case-
- insensitive hex encoding and may be referred to as "base16" or "hex".
-
- A 16-character subset of US-ASCII is used, enabling 4 bits to be
- represented per printable character.
-
- The encoding process represents 8-bit groups (octets) of input bits
- as output strings of 2 encoded characters. Proceeding from left to
- right, an 8-bit input is taken from the input data. These 8 bits are
- then treated as 2 concatenated 4-bit groups, each of which is
- translated into a single character in the base 16 alphabet.
-
- Each 4-bit group is used as an index into an array of 16 printable
- characters. The character referenced by the index is placed in the
- output string.
-
-
-
-
-
-Josefsson Standards Track [Page 10]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
- Table 5: The Base 16 Alphabet
-
- Value Encoding Value Encoding Value Encoding Value Encoding
- 0 0 4 4 8 8 12 C
- 1 1 5 5 9 9 13 D
- 2 2 6 6 10 A 14 E
- 3 3 7 7 11 B 15 F
-
- Unlike base 32 and base 64, no special padding is necessary since a
- full code word is always available.
-
-9. Illustrations and Examples
-
- To translate between binary and a base encoding, the input is stored
- in a structure, and the output is extracted. The case for base 64 is
- displayed in the following figure, borrowed from [5].
-
- +--first octet--+-second octet--+--third octet--+
- |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
- +-----------+---+-------+-------+---+-----------+
- |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
- +--1.index--+--2.index--+--3.index--+--4.index--+
-
- The case for base 32 is shown in the following figure, borrowed from
- [7]. Each successive character in a base-32 value represents 5
- successive bits of the underlying octet sequence. Thus, each group
- of 8 characters represents a sequence of 5 octets (40 bits).
-
- 1 2 3
- 01234567 89012345 67890123 45678901 23456789
- +--------+--------+--------+--------+--------+
- |< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
- +--------+--------+--------+--------+--------+
- <===> 8th character
- <====> 7th character
- <===> 6th character
- <====> 5th character
- <====> 4th character
- <===> 3rd character
- <====> 2nd character
- <===> 1st character
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 11]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
- The following example of Base64 data is from [5], with corrections.
-
- Input data: 0x14fb9c03d97e
- Hex: 1 4 f b 9 c | 0 3 d 9 7 e
- 8-bit: 00010100 11111011 10011100 | 00000011 11011001 01111110
- 6-bit: 000101 001111 101110 011100 | 000000 111101 100101 111110
- Decimal: 5 15 46 28 0 61 37 62
- Output: F P u c A 9 l +
-
- Input data: 0x14fb9c03d9
- Hex: 1 4 f b 9 c | 0 3 d 9
- 8-bit: 00010100 11111011 10011100 | 00000011 11011001
- pad with 00
- 6-bit: 000101 001111 101110 011100 | 000000 111101 100100
- Decimal: 5 15 46 28 0 61 36
- pad with =
- Output: F P u c A 9 k =
-
- Input data: 0x14fb9c03
- Hex: 1 4 f b 9 c | 0 3
- 8-bit: 00010100 11111011 10011100 | 00000011
- pad with 0000
- 6-bit: 000101 001111 101110 011100 | 000000 110000
- Decimal: 5 15 46 28 0 48
- pad with = =
- Output: F P u c A w = =
-
-10. Test Vectors
-
- BASE64("") = ""
-
- BASE64("f") = "Zg=="
-
- BASE64("fo") = "Zm8="
-
- BASE64("foo") = "Zm9v"
-
- BASE64("foob") = "Zm9vYg=="
-
- BASE64("fooba") = "Zm9vYmE="
-
- BASE64("foobar") = "Zm9vYmFy"
-
- BASE32("") = ""
-
- BASE32("f") = "MY======"
-
- BASE32("fo") = "MZXQ===="
-
-
-
-Josefsson Standards Track [Page 12]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
- BASE32("foo") = "MZXW6==="
-
- BASE32("foob") = "MZXW6YQ="
-
- BASE32("fooba") = "MZXW6YTB"
-
- BASE32("foobar") = "MZXW6YTBOI======"
-
- BASE32-HEX("") = ""
-
- BASE32-HEX("f") = "CO======"
-
- BASE32-HEX("fo") = "CPNG===="
-
- BASE32-HEX("foo") = "CPNMU==="
-
- BASE32-HEX("foob") = "CPNMUOG="
-
- BASE32-HEX("fooba") = "CPNMUOJ1"
-
- BASE32-HEX("foobar") = "CPNMUOJ1E8======"
-
- BASE16("") = ""
-
- BASE16("f") = "66"
-
- BASE16("fo") = "666F"
-
- BASE16("foo") = "666F6F"
-
- BASE16("foob") = "666F6F62"
-
- BASE16("fooba") = "666F6F6261"
-
- BASE16("foobar") = "666F6F626172"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 13]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
-11. ISO C99 Implementation of Base64
-
- An ISO C99 implementation of Base64 encoding and decoding that is
- believed to follow all recommendations in this RFC is available from:
-
- http://josefsson.org/base-encoding/
-
- This code is not normative.
-
- The code could not be included in this RFC for procedural reasons
- (RFC 3978 section 5.4).
-
-12. Security Considerations
-
- When base encoding and decoding is implemented, care should be taken
- not to introduce vulnerabilities to buffer overflow attacks, or other
- attacks on the implementation. A decoder should not break on invalid
- input including, e.g., embedded NUL characters (ASCII 0).
-
- If non-alphabet characters are ignored, instead of causing rejection
- of the entire encoding (as recommended), a covert channel that can be
- used to "leak" information is made possible. The ignored characters
- could also be used for other nefarious purposes, such as to avoid a
- string equality comparison or to trigger implementation bugs. The
- implications of ignoring non-alphabet characters should be understood
- in applications that do not follow the recommended practice.
- Similarly, when the base 16 and base 32 alphabets are handled case
- insensitively, alteration of case can be used to leak information or
- make string equality comparisons fail.
-
- When padding is used, there are some non-significant bits that
- warrant security concerns, as they may be abused to leak information
- or used to bypass string equality comparisons or to trigger
- implementation problems.
-
- Base encoding visually hides otherwise easily recognized information,
- such as passwords, but does not provide any computational
- confidentiality. This has been known to cause security incidents
- when, e.g., a user reports details of a network protocol exchange
- (perhaps to illustrate some other problem) and accidentally reveals
- the password because she is unaware that the base encoding does not
- protect the password.
-
- Base encoding adds no entropy to the plaintext, but it does increase
- the amount of plaintext available and provide a signature for
- cryptanalysis in the form of a characteristic probability
- distribution.
-
-
-
-
-Josefsson Standards Track [Page 14]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
-13. Changes Since RFC 3548
-
- Added the "base32 extended hex alphabet", needed to preserve sort
- order of encoded data.
-
- Referenced IMAP for the special Base64 encoding used there.
-
- Fixed the example copied from RFC 2440.
-
- Added security consideration about providing a signature for
- cryptoanalysis.
-
- Added test vectors.
-
- Fixed typos.
-
-14. Acknowledgements
-
- Several people offered comments and/or suggestions, including John E.
- Hadstate, Tony Hansen, Gordon Mohr, John Myers, Chris Newman, and
- Andrew Sieber. Text used in this document are based on earlier RFCs
- describing specific uses of various base encodings. The author
- acknowledges the RSA Laboratories for supporting the work that led to
- this document.
-
- This revised version is based in parts on comments and/or suggestions
- made by Roy Arends, Eric Blake, Brian E Carpenter, Elwyn Davies, Bill
- Fenner, Sam Hartman, Ted Hardie, Per Hygum, Jelte Jansen, Clement
- Kent, Tero Kivinen, Paul Kwiatkowski, and Ben Laurie.
-
-15. Copying Conditions
-
- Copyright (c) 2000-2006 Simon Josefsson
-
- Regarding the abstract and sections 1, 3, 8, 10, 12, 13, and 14 of
- this document, that were written by Simon Josefsson ("the author",
- for the remainder of this section), the author makes no guarantees
- and is not responsible for any damage resulting from its use. The
- author grants irrevocable permission to anyone to use, modify, and
- distribute it in any way that does not diminish the rights of anyone
- else to use, modify, and distribute it, provided that redistributed
- derivative works do not contain misleading author or version
- information and do not falsely purport to be IETF RFC documents.
- Derivative works need not be licensed under similar terms.
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 15]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
-16. References
-
-16.1. Normative References
-
- [1] Cerf, V., "ASCII format for network interchange", RFC 20,
- October 1969.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-16.2. Informative References
-
- [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
- Part I: Message Encryption and Authentication Procedures", RFC
- 1421, February 1993.
-
- [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message Bodies",
- RFC 2045, November 1996.
-
- [5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
- "OpenPGP Message Format", RFC 2440, November 1998.
-
- [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [7] Klyne, G. and L. Masinter, "Identifying Composite Media
- Features", RFC 2938, September 2000.
-
- [8] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
- 4rev1", RFC 3501, March 2003.
-
- [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
- January 2005.
-
- [10] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNSSEC Hash
- Authenticated Denial of Existence", Work in Progress, June
- 2006.
-
- [11] Myers, J., "SASL GSSAPI mechanisms", Work in Progress, May
- 2000.
-
- [12] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
- http://zgp.org/pipermail/p2p-hackers/2001-September/
- 000315.html, September 2001.
-
-
-
-
-Josefsson Standards Track [Page 16]
-\f
-RFC 4648 Base-N Encodings October 2006
-
-
-Author's Address
-
- Simon Josefsson
- SJD
- EMail: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 17]
-\f
-RFC 4648 Base-N Encodings October 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Josefsson Standards Track [Page 18]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group M. Stapp
-Request for Comments: 4701 Cisco Systems, Inc.
-Category: Standards Track T. Lemon
- Nominum, Inc.
- A. Gustafsson
- Araneus Information Systems Oy
- October 2006
-
-
- A DNS Resource Record (RR) for Encoding
- Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- It is possible for Dynamic Host Configuration Protocol (DHCP) clients
- to attempt to update the same DNS Fully Qualified Domain Name (FQDN)
- or to update a DNS FQDN that has been added to the DNS for another
- purpose as they obtain DHCP leases. Whether the DHCP server or the
- clients themselves perform the DNS updates, conflicts can arise. To
- resolve such conflicts, RFC 4703 proposes storing client identifiers
- in the DNS to unambiguously associate domain names with the DHCP
- clients to which they refer. This memo defines a distinct Resource
- Record (RR) type for this purpose for use by DHCP clients and
- servers: the "DHCID" RR.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Standards Track [Page 1]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
-Table of Contents
-
- 1. Introduction ....................................................3
- 2. Terminology .....................................................3
- 3. The DHCID RR ....................................................3
- 3.1. DHCID RDATA Format .........................................3
- 3.2. DHCID Presentation Format ..................................4
- 3.3. The DHCID RR Identifier Type Codes .........................4
- 3.4. The DHCID RR Digest Type Code ..............................4
- 3.5. Computation of the RDATA ...................................5
- 3.5.1. Using the Client's DUID .............................5
- 3.5.2. Using the Client Identifier Option ..................6
- 3.5.3. Using the Client's htype and chaddr .................6
- 3.6. Examples ...................................................6
- 3.6.1. Example 1 ...........................................6
- 3.6.2. Example 2 ...........................................7
- 3.6.3. Example 3 ...........................................7
- 4. Use of the DHCID RR .............................................8
- 5. Updater Behavior ................................................8
- 6. Security Considerations .........................................8
- 7. IANA Considerations .............................................9
- 8. Acknowledgements ................................................9
- 9. References ......................................................9
- 9.1. Normative References .......................................9
- 9.2. Informative References ....................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Standards Track [Page 2]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
-1. Introduction
-
- A set of procedures to allow DHCP [7] [11] clients and servers to
- automatically update the DNS ([3], [4]) is proposed in [1].
-
- Conflicts can arise if multiple DHCP clients wish to use the same DNS
- name or a DHCP client attempts to use a name added for another
- purpose. To resolve such conflicts, [1] proposes storing client
- identifiers in the DNS to unambiguously associate domain names with
- the DHCP clients using them. In the interest of clarity, it is
- preferable for this DHCP information to use a distinct RR type. This
- memo defines a distinct RR for this purpose for use by DHCP clients
- or servers: the "DHCID" RR.
-
- In order to obscure potentially sensitive client identifying
- information, the data stored is the result of a one-way SHA-256 hash
- computation. The hash includes information from the DHCP client's
- message as well as the domain name itself, so that the data stored in
- the DHCID RR will be dependent on both the client identification used
- in the DHCP protocol interaction and the domain name. This means
- that the DHCID RDATA will vary if a single client is associated over
- time with more than one name. This makes it difficult to 'track' a
- client as it is associated with various domain names.
-
-2. Terminology
-
- 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 [2].
-
-3. The DHCID RR
-
- The DHCID RR is defined with mnemonic DHCID and type code 49. The
- DHCID RR is only defined in the IN class. DHCID RRs cause no
- additional section processing.
-
-3.1. DHCID RDATA Format
-
- The RDATA section of a DHCID RR in transmission contains RDLENGTH
- octets of binary data. The format of this data and its
- interpretation by DHCP servers and clients are described below.
-
- DNS software should consider the RDATA section to be opaque. DHCP
- clients or servers use the DHCID RR to associate a DHCP client's
- identity with a DNS name, so that multiple DHCP clients and servers
- may deterministically perform dynamic DNS updates to the same zone.
- From the updater's perspective, the DHCID resource record RDATA
- consists of a 2-octet identifier type, in network byte order,
-
-
-
-Stapp, et al. Standards Track [Page 3]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
- followed by a 1-octet digest type, followed by one or more octets
- representing the actual identifier:
-
- < 2 octets > Identifier type code
- < 1 octet > Digest type code
- < n octets > Digest (length depends on digest type)
-
-3.2. DHCID Presentation Format
-
- In DNS master files, the RDATA is represented as a single block in
- base-64 encoding identical to that used for representing binary data
- in [8], Section 3. The data may be divided up into any number of
- white-space-separated substrings, down to single base-64 digits,
- which are concatenated to form the complete RDATA. These substrings
- can span lines using the standard parentheses.
-
-3.3. The DHCID RR Identifier Type Codes
-
- The DHCID RR Identifier Type Code specifies what data from the DHCP
- client's request was used as input into the hash function. The
- identifier type codes are defined in a registry maintained by IANA,
- as specified in Section 7. The initial list of assigned values for
- the identifier type code and that type's identifier is:
-
-
- +------------------+------------------------------------------------+
- | Identifier Type | Identifier |
- | Code | |
- +------------------+------------------------------------------------+
- | 0x0000 | The 1-octet 'htype' followed by 'hlen' octets |
- | | of 'chaddr' from a DHCPv4 client's DHCPREQUEST |
- | | [7]. |
- | 0x0001 | The data octets (i.e., the Type and |
- | | Client-Identifier fields) from a DHCPv4 |
- | | client's Client Identifier option [10]. |
- | 0x0002 | The client's DUID (i.e., the data octets of a |
- | | DHCPv6 client's Client Identifier option [11] |
- | | or the DUID field from a DHCPv4 client's |
- | | Client Identifier option [6]). |
- | 0x0003 - 0xfffe | Undefined; available to be assigned by IANA. |
- | 0xffff | Undefined; RESERVED. |
- +------------------+------------------------------------------------+
-
-3.4. The DHCID RR Digest Type Code
-
- The DHCID RR Digest Type Code is an identifier for the digest
- algorithm used. The digest is calculated over an identifier and the
- canonical FQDN as described in the next section.
-
-
-
-Stapp, et al. Standards Track [Page 4]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
- The digest type codes are defined in a registry maintained by IANA,
- as specified in Section 7. The initial list of assigned values for
- the digest type codes is: value 0 is reserved, and value 1 is
- SHA-256. Reserving other types requires IETF standards action.
- Defining new values will also require IETF standards action to
- document how DNS updaters are to deal with multiple digest types.
-
-3.5. Computation of the RDATA
-
- The DHCID RDATA is formed by concatenating the 2-octet identifier
- type code with variable-length data.
-
- The RDATA for all type codes other than 0xffff, which is reserved for
- future expansion, is formed by concatenating the 2-octet identifier
- type code, the 1-octet digest type code, and the digest value (32
- octets for SHA-256).
-
- < identifier-type > < digest-type > < digest >
-
- The input to the digest hash function is defined to be:
-
- digest = SHA-256(< identifier > < FQDN >)
-
- The FQDN is represented in the buffer in the canonical wire format as
- described in [9], Section 6.2. The identifier type code and the
- identifier are related as specified in Section 3.3: the identifier
- type code describes the source of the identifier.
-
- A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
- option is present in the DHCPv4 messages and it is encoded as
- specified in [6]. Otherwise, the updater uses 0x0001 if a Client
- Identifier option is present, and 0x0000 if not.
-
- A DHCPv6 updater always uses the 0x0002 type code.
-
-3.5.1. Using the Client's DUID
-
- When the updater is using the Client's DUID (either from a DHCPv6
- Client Identifier option or from a portion of the DHCPv4 Client
- Identifier option encoded as specified in [6]), the first two octets
- of the DHCID RR MUST be 0x0002, in network byte order. The third
- octet is the digest type code (1 for SHA-256). The rest of the DHCID
- RR MUST contain the results of computing the SHA-256 hash across the
- octets of the DUID followed by the FQDN.
-
-
-
-
-
-
-
-Stapp, et al. Standards Track [Page 5]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
-3.5.2. Using the Client Identifier Option
-
- When the updater is using the DHCPv4 Client Identifier option sent by
- the client in its DHCPREQUEST message, the first two octets of the
- DHCID RR MUST be 0x0001, in network byte order. The third octet is
- the digest type code (1 for SHA-256). The rest of the DHCID RR MUST
- contain the results of computing the SHA-256 hash across the data
- octets (i.e., the Type and Client-Identifier fields) of the option,
- followed by the FQDN.
-
-3.5.3. Using the Client's htype and chaddr
-
- When the updater is using the client's link-layer address as the
- identifier, the first two octets of the DHCID RDATA MUST be zero.
- The third octet is the digest type code (1 for SHA-256). To generate
- the rest of the resource record, the updater computes a one-way hash
- using the SHA-256 algorithm across a buffer containing the client's
- network hardware type, link-layer address, and the FQDN data.
- Specifically, the first octet of the buffer contains the network
- hardware type as it appeared in the DHCP 'htype' field of the
- client's DHCPREQUEST message. All of the significant octets of the
- 'chaddr' field in the client's DHCPREQUEST message follow, in the
- same order in which the octets appear in the DHCPREQUEST message.
- The number of significant octets in the 'chaddr' field is specified
- in the 'hlen' field of the DHCPREQUEST message. The FQDN data, as
- specified above, follows.
-
-3.6. Examples
-
-3.6.1. Example 1
-
- A DHCP server allocates the IPv6 address 2001:DB8::1234:5678 to a
- client that included the DHCPv6 client-identifier option data 00:01:
- 00:06:41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The
- server updates the name "chi6.example.com" on the client's behalf and
- uses the DHCP client identifier option data as input in forming a
- DHCID RR. The DHCID RDATA is formed by setting the two type octets
- to the value 0x0002, the 1-octet digest type to 1 for SHA-256, and
- performing a SHA-256 hash computation across a buffer containing the
- 14 octets from the client-id option and the FQDN (represented as
- specified in Section 3.5).
-
- chi6.example.com. AAAA 2001:DB8::1234:5678
- chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
- OjxfNuVAA2kjEA= )
-
- If the DHCID RR type is not supported, the RDATA would be encoded
- [13] as:
-
-
-
-Stapp, et al. Standards Track [Page 6]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
- \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
- b95000da48c40 )
-
-3.6.2. Example 2
-
- A DHCP server allocates the IPv4 address 192.0.2.2 to a client that
- included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
- in its DHCP request. The server updates the name "chi.example.com"
- on the client's behalf and uses the DHCP client identifier option
- data as input in forming a DHCID RR. The DHCID RDATA is formed by
- setting the two type octets to the value 0x0001, the 1-octet digest
- type to 1 for SHA-256, and performing a SHA-256 hash computation
- across a buffer containing the seven octets from the client-id option
- and the FQDN (represented as specified in Section 3.5).
-
- chi.example.com. A 192.0.2.2
- chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
- L3b/NaiUDlW2No= )
-
- If the DHCID RR type is not supported, the RDATA would be encoded
- [13] as:
-
- \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
- 6a2503956d8da )
-
-3.6.3. Example 3
-
- A DHCP server allocating the IPv4 address 192.0.2.3 to a client with
- the Ethernet MAC address 01:02:03:04:05:06 using domain name
- "client.example.com" uses the client's link-layer address to identify
- the client. The DHCID RDATA is composed by setting the two type
- octets to zero, the 1-octet digest type to 1 for SHA-256, and
- performing an SHA-256 hash computation across a buffer containing the
- 1-octet 'htype' value for Ethernet, 0x01, followed by the six octets
- of the Ethernet MAC address, and the domain name (represented as
- specified in Section 3.5).
-
- client.example.com. A 192.0.2.3
- client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
- ytcKD//7es/deY= )
-
- If the DHCID RR type is not supported, the RDATA would be encoded
- [13] as:
-
- \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
- fffedeb3f75e6 )
-
-
-
-
-
-Stapp, et al. Standards Track [Page 7]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
-4. Use of the DHCID RR
-
- This RR MUST NOT be used for any purpose other than that detailed in
- [1]. Although this RR contains data that is opaque to DNS servers,
- the data must be consistent across all entities that update and
- interpret this record. Therefore, new data formats may only be
- defined through actions of the DHC Working Group, as a result of
- revising [1].
-
-5. Updater Behavior
-
- The data in the DHCID RR allows updaters to determine whether more
- than one DHCP client desires to use a particular FQDN. This allows
- site administrators to establish policy about DNS updates. The DHCID
- RR does not establish any policy itself.
-
- Updaters use data from a DHCP client's request and the domain name
- that the client desires to use to compute a client identity hash, and
- then compare that hash to the data in any DHCID RRs on the name that
- they wish to associate with the client's IP address. If an updater
- discovers DHCID RRs whose RDATA does not match the client identity
- that they have computed, the updater SHOULD conclude that a different
- client is currently associated with the name in question. The
- updater SHOULD then proceed according to the site's administrative
- policy. That policy might dictate that a different name be selected,
- or it might permit the updater to continue.
-
-6. Security Considerations
-
- The DHCID record as such does not introduce any new security problems
- into the DNS. In order to obscure the client's identity information,
- a one-way hash is used. Further, in order to make it difficult to
- 'track' a client by examining the names associated with a particular
- hash value, the FQDN is included in the hash computation. Thus, the
- RDATA is dependent on both the DHCP client identification data and on
- each FQDN associated with the client.
-
- However, it should be noted that an attacker that has some knowledge,
- such as of MAC addresses commonly used in DHCP client identification
- data, may be able to discover the client's DHCP identify by using a
- brute-force attack. Even without any additional knowledge, the
- number of unknown bits used in computing the hash is typically only
- 48 to 80.
-
- Administrators should be wary of permitting unsecured DNS updates to
- zones, whether or not they are exposed to the global Internet. Both
- DHCP clients and servers SHOULD use some form of update
- authentication (e.g., [12]) when performing DNS updates.
-
-
-
-Stapp, et al. Standards Track [Page 8]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
-7. IANA Considerations
-
- IANA has allocated a DNS RR type number for the DHCID record type.
-
- This specification defines a new number-space for the 2-octet
- identifier type codes associated with the DHCID RR. IANA has
- established a registry of the values for this number-space. Three
- initial values are assigned in Section 3.3, and the value 0xFFFF is
- reserved for future use. New DHCID RR identifier type codes are
- assigned through Standards Action, as defined in [5].
-
- This specification defines a new number-space for the 1-octet digest
- type codes associated with the DHCID RR. IANA has established a
- registry of the values for this number-space. Two initial values are
- assigned in Section 3.4. New DHCID RR digest type codes are assigned
- through Standards Action, as defined in [5].
-
-8. Acknowledgements
-
- Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
- Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
- Volz for their review and suggestions.
-
-9. References
-
-9.1. Normative References
-
- [1] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain
- Name (FQDN) Conflicts among Dynamic Host Configuration Protocol
- (DHCP) Clients", RFC 4703, October 2006.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [4] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
- [6] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
- for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
- RFC 4361, February 2006.
-
-
-
-
-
-Stapp, et al. Standards Track [Page 9]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
-9.2. Informative References
-
- [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
- [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
- RFC 3548, July 2003.
-
- [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [10] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 2132, March 1997.
-
- [11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
- Carney, "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [12] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Standards Track [Page 10]
-\f
-RFC 4701 The DHCID RR October 2006
-
-
-Authors' Addresses
-
- Mark Stapp
- Cisco Systems, Inc.
- 1414 Massachusetts Ave.
- Boxborough, MA 01719
- USA
-
- Phone: 978.936.1535
- EMail: mjs@cisco.com
-
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- EMail: mellon@nominum.com
-
-
- Andreas Gustafsson
- Araneus Information Systems Oy
- Ulappakatu 1
- 02320 Espoo
- Finland
-
- EMail: gson@araneus.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Standards Track [Page 11]
-\f
-RFC 4701 The DHCID RR October 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Stapp, et al. Standards Track [Page 12]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group B. Laurie
-Request for Comments: 5155 G. Sisson
-Category: Standards Track R. Arends
- Nominet
- D. Blacka
- VeriSign, Inc.
- March 2008
-
-
- DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- The Domain Name System Security (DNSSEC) Extensions introduced the
- NSEC resource record (RR) for authenticated denial of existence.
- This document introduces an alternative resource record, NSEC3, which
- similarly provides authenticated denial of existence. However, it
- also provides measures against zone enumeration and permits gradual
- expansion of delegation-centric zones.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
- 2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6
- 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 7
- 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8
- 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9
- 3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9
- 3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9
- 3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 9
- 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
- 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 11
-
-
-
-Laurie, et al. Standards Track [Page 1]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- 4. The NSEC3PARAM Resource Record . . . . . . . . . . . . . . . . 12
- 4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
- 4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
- 4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 12
- 4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13
- 4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13
- 4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
- 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 14
- 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 14
- 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 7. Authoritative Server Considerations . . . . . . . . . . . . . 16
- 7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16
- 7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
- 7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18
- 7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 19
- 7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19
- 7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
- 7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 19
- 7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 20
- 7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20
- 7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20
- 7.2.9. Server Response to a Run-Time Collision . . . . . . . 21
- 7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 21
- 7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21
- 7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
- 8. Validator Considerations . . . . . . . . . . . . . . . . . . . 23
- 8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 23
- 8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 23
- 8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
- 8.4. Validating Name Error Responses . . . . . . . . . . . . . 24
- 8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24
- 8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24
- 8.7. Validating Wildcard No Data Responses . . . . . . . . . . 25
- 8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 25
- 8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25
- 9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 26
- 9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 26
- 9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 26
- 10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
- 10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26
- 10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 27
- 10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27
- 10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28
- 10.5. Transitioning a Signed Zone from NSEC3 to NSEC . . . . . . 28
- 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
- 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
- 12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
-
-
-
-Laurie, et al. Standards Track [Page 2]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- 12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
- 12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 31
- 12.1.3. Transitioning to a New Hash Algorithm . . . . . . . . 31
- 12.1.4. Using High Iteration Values . . . . . . . . . . . . . 31
- 12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
- 12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 33
- 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
- 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
- 13.2. Informative References . . . . . . . . . . . . . . . . . . 34
- Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 35
- Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 40
- B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 40
- B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 42
- B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 43
- B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 44
- B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
- B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
- B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 48
- Appendix C. Special Considerations . . . . . . . . . . . . . . . 48
- C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 49
- C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
- C.2.1. Avoiding Hash Collisions During Generation . . . . . . 50
- C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 50
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 3]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-1. Introduction
-
-1.1. Rationale
-
- The DNS Security Extensions included the NSEC RR to provide
- authenticated denial of existence. Though the NSEC RR meets the
- requirements for authenticated denial of existence, it introduces a
- side-effect in that the contents of a zone can be enumerated. This
- property introduces undesired policy issues.
-
- The enumeration is enabled by the set of NSEC records that exists
- inside a signed zone. An NSEC record lists two names that are
- ordered canonically, in order to show that nothing exists between the
- two names. The complete set of NSEC records lists all the names in a
- zone. It is trivial to enumerate the content of a zone by querying
- for names that do not exist.
-
- An enumerated zone can be used, for example, as a source of probable
- e-mail addresses for spam, or as a key for multiple WHOIS queries to
- reveal registrant data that many registries may have legal
- obligations to protect. Many registries therefore prohibit the
- copying of their zone data; however, the use of NSEC RRs renders
- these policies unenforceable.
-
- A second problem is that the cost to cryptographically secure
- delegations to unsigned zones is high, relative to the perceived
- security benefit, in two cases: large, delegation-centric zones, and
- zones where insecure delegations will be updated rapidly. In these
- cases, the costs of maintaining the NSEC RR chain may be extremely
- high and use of the "Opt-Out" convention may be more appropriate (for
- these unsecured zones).
-
- This document presents the NSEC3 Resource Record which can be used as
- an alternative to NSEC to mitigate these issues.
-
- Earlier work to address these issues include [DNSEXT-NO], [RFC4956],
- and [DNSEXT-NSEC2v2].
-
-1.2. Requirements
-
- 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].
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 4]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-1.3. Terminology
-
- The reader is assumed to be familiar with the basic DNS and DNSSEC
- concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034],
- [RFC4035], and subsequent RFCs that update them: [RFC2136],
- [RFC2181], and [RFC2308].
-
- The following terminology is used throughout this document:
-
- Zone enumeration: the practice of discovering the full content of a
- zone via successive queries. Zone enumeration was non-trivial
- prior to the introduction of DNSSEC.
-
- Original owner name: the owner name corresponding to a hashed owner
- name.
-
- Hashed owner name: the owner name created after applying the hash
- function to an owner name.
-
- Hash order: the order in which hashed owner names are arranged
- according to their numerical value, treating the leftmost (lowest
- numbered) octet as the most significant octet. Note that this
- order is the same as the canonical DNS name order specified in
- [RFC4034], when the hashed owner names are in base32, encoded with
- an Extended Hex Alphabet [RFC4648].
-
- Empty non-terminal: a domain name that owns no resource records, but
- has one or more subdomains that do.
-
- Delegation: an NS RRSet with a name different from the current zone
- apex (non-zone-apex), signifying a delegation to a child zone.
-
- Secure delegation: a name containing a delegation (NS RRSet) and a
- signed DS RRSet, signifying a delegation to a signed child zone.
-
- Insecure delegation: a name containing a delegation (NS RRSet), but
- lacking a DS RRSet, signifying a delegation to an unsigned child
- zone.
-
- Opt-Out NSEC3 resource record: an NSEC3 resource record that has the
- Opt-Out flag set to 1.
-
- Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR.
-
- Closest encloser: the longest existing ancestor of a name. See also
- Section 3.3.1 of [RFC4592].
-
-
-
-
-
-Laurie, et al. Standards Track [Page 5]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- Closest provable encloser: the longest ancestor of a name that can
- be proven to exist. Note that this is only different from the
- closest encloser in an Opt-Out zone.
-
- Next closer name: the name one label longer than the closest
- provable encloser of a name.
-
- Base32: the "Base 32 Encoding with Extended Hex Alphabet" as
- specified in [RFC4648]. Note that trailing padding characters
- ("=") are not used in the NSEC3 specification.
-
- To cover: An NSEC3 RR is said to "cover" a name if the hash of the
- name or "next closer" name falls between the owner name and the
- next hashed owner name of the NSEC3. In other words, if it proves
- the nonexistence of the name, either directly or by proving the
- nonexistence of an ancestor of the name.
-
- To match: An NSEC3 RR is said to "match" a name if the owner name of
- the NSEC3 RR is the same as the hashed owner name of that name.
-
-2. Backwards Compatibility
-
- This specification describes a protocol change that is not generally
- backwards compatible with [RFC4033], [RFC4034], and [RFC4035]. In
- particular, security-aware resolvers that are unaware of this
- specification (NSEC3-unaware resolvers) may fail to validate the
- responses introduced by this document.
-
- In order to aid deployment, this specification uses a signaling
- technique to prevent NSEC3-unaware resolvers from attempting to
- validate responses from NSEC3-signed zones.
-
- This specification allocates two new DNSKEY algorithm identifiers for
- this purpose. Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm
- 3, DSA. Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5,
- RSASHA1. These are not new algorithms, they are additional
- identifiers for the existing algorithms.
-
- Zones signed according to this specification MUST only use these
- algorithm identifiers for their DNSKEY RRs. Because these new
- identifiers will be unknown algorithms to existing, NSEC3-unaware
- resolvers, those resolvers will then treat responses from the NSEC3
- signed zone as insecure, as detailed in Section 5.2 of [RFC4035].
-
- These algorithm identifiers are used with the NSEC3 hash algorithm
- SHA1. Using other NSEC3 hash algorithms requires allocation of a new
- alias (see Section 12.1.3).
-
-
-
-
-Laurie, et al. Standards Track [Page 6]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- Security aware resolvers that are aware of this specification MUST
- recognize the new algorithm identifiers and treat them as equivalent
- to the algorithms that they alias.
-
- A methodology for transitioning from a DNSSEC signed zone to a zone
- signed using NSEC3 is discussed in Section 10.4.
-
-3. The NSEC3 Resource Record
-
- The NSEC3 Resource Record (RR) provides authenticated denial of
- existence for DNS Resource Record Sets.
-
- The NSEC3 RR lists RR types present at the original owner name of the
- NSEC3 RR. It includes the next hashed owner name in the hash order
- of the zone. The complete set of NSEC3 RRs in a zone indicates which
- RRSets exist for the original owner name of the RR and form a chain
- of hashed owner names in the zone. This information is used to
- provide authenticated denial of existence for DNS data. To provide
- protection against zone enumeration, the owner names used in the
- NSEC3 RR are cryptographic hashes of the original owner name
- prepended as a single label to the name of the zone. The NSEC3 RR
- indicates which hash function is used to construct the hash, which
- salt is used, and how many iterations of the hash function are
- performed over the original owner name. The hashing technique is
- described fully in Section 5.
-
- Hashed owner names of unsigned delegations may be excluded from the
- chain. An NSEC3 RR whose span covers the hash of an owner name or
- "next closer" name of an unsigned delegation is referred to as an
- Opt-Out NSEC3 RR and is indicated by the presence of a flag.
-
- The owner name for the NSEC3 RR is the base32 encoding of the hashed
- owner name prepended as a single label to the name of the zone.
-
- The type value for the NSEC3 RR is 50.
-
- The NSEC3 RR RDATA format is class independent and is described
- below.
-
- The class MUST be the same as the class of the original owner name.
-
- The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
- field. This is in the spirit of negative caching [RFC2308].
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 7]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-3.1. RDATA Fields
-
-3.1.1. Hash Algorithm
-
- The Hash Algorithm field identifies the cryptographic hash algorithm
- used to construct the hash-value.
-
- The values for this field are defined in the NSEC3 hash algorithm
- registry defined in Section 11.
-
-3.1.2. Flags
-
- The Flags field contains 8 one-bit flags that can be used to indicate
- different processing. All undefined flags must be zero. The only
- flag defined by this specification is the Opt-Out flag.
-
-3.1.2.1. Opt-Out Flag
-
- If the Opt-Out flag is set, the NSEC3 record covers zero or more
- unsigned delegations.
-
- If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
- delegations.
-
- The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
- delegations. It is the least significant bit in the Flags field.
- See Section 6 for details about the use of this flag.
-
-3.1.3. Iterations
-
- The Iterations field defines the number of additional times the hash
- function has been performed. More iterations result in greater
- resiliency of the hash value against dictionary attacks, but at a
- higher computational cost for both the server and resolver. See
- Section 5 for details of the use of this field, and Section 10.3 for
- limitations on the value.
-
-3.1.4. Salt Length
-
- The Salt Length field defines the length of the Salt field in octets,
- ranging in value from 0 to 255.
-
-3.1.5. Salt
-
- The Salt field is appended to the original owner name before hashing
- in order to defend against pre-calculated dictionary attacks. See
- Section 5 for details on how the salt is used.
-
-
-
-
-Laurie, et al. Standards Track [Page 8]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-3.1.6. Hash Length
-
- The Hash Length field defines the length of the Next Hashed Owner
- Name field, ranging in value from 1 to 255 octets.
-
-3.1.7. Next Hashed Owner Name
-
- The Next Hashed Owner Name field contains the next hashed owner name
- in hash order. This value is in binary format. Given the ordered
- set of all hashed owner names, the Next Hashed Owner Name field
- contains the hash of an owner name that immediately follows the owner
- name of the given NSEC3 RR. The value of the Next Hashed Owner Name
- field in the last NSEC3 RR in the zone is the same as the hashed
- owner name of the first NSEC3 RR in the zone in hash order. Note
- that, unlike the owner name of the NSEC3 RR, the value of this field
- does not contain the appended zone name.
-
-3.1.8. Type Bit Maps
-
- The Type Bit Maps field identifies the RRSet types that exist at the
- original owner name of the NSEC3 RR.
-
-3.2. NSEC3 RDATA Wire Format
-
- The RDATA of the NSEC3 RR is as shown below:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Hash Alg. | Flags | Iterations |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Salt Length | Salt /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Hash Length | Next Hashed Owner Name /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Type Bit Maps /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Hash Algorithm is a single octet.
-
- Flags field is a single octet, the Opt-Out flag is the least
- significant bit, as shown below:
-
- 0 1 2 3 4 5 6 7
- +-+-+-+-+-+-+-+-+
- | |O|
- +-+-+-+-+-+-+-+-+
-
-
-
-
-Laurie, et al. Standards Track [Page 9]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- Iterations is represented as a 16-bit unsigned integer, with the most
- significant bit first.
-
- Salt Length is represented as an unsigned octet. Salt Length
- represents the length of the Salt field in octets. If the value is
- zero, the following Salt field is omitted.
-
- Salt, if present, is encoded as a sequence of binary octets. The
- length of this field is determined by the preceding Salt Length
- field.
-
- Hash Length is represented as an unsigned octet. Hash Length
- represents the length of the Next Hashed Owner Name field in octets.
-
- The next hashed owner name is not base32 encoded, unlike the owner
- name of the NSEC3 RR. It is the unmodified binary hash value. It
- does not include the name of the containing zone. The length of this
- field is determined by the preceding Hash Length field.
-
-3.2.1. Type Bit Maps Encoding
-
- The encoding of the Type Bit Maps field is the same as that used by
- the NSEC RR, described in [RFC4034]. It is explained and clarified
- here for clarity.
-
- The RR type space is split into 256 window blocks, each representing
- the low-order 8 bits of the 16-bit RR type space. Each block that
- has at least one active RR type is encoded using a single octet
- window number (from 0 to 255), a single octet bitmap length (from 1
- to 32) indicating the number of octets used for the bitmap of the
- window block, and up to 32 octets (256 bits) of bitmap.
-
- Blocks are present in the NSEC3 RR RDATA in increasing numerical
- order.
-
- Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
- where "|" denotes concatenation.
-
- Each bitmap encodes the low-order 8 bits of RR types within the
- window block, in network bit order. The first bit is bit 0. For
- window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
- to RR type 2 (NS), and so forth. For window block 1, bit 1
- corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
- 1, it indicates that an RRSet of that type is present for the
- original owner name of the NSEC3 RR. If a bit is set to 0, it
- indicates that no RRSet of that type is present for the original
- owner name of the NSEC3 RR.
-
-
-
-Laurie, et al. Standards Track [Page 10]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- Since bit 0 in window block 0 refers to the non-existing RR type 0,
- it MUST be set to 0. After verification, the validator MUST ignore
- the value of bit 0 in window block 0.
-
- Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of
- [RFC2929] or within the range reserved for assignment only to QTYPEs
- and Meta-TYPEs MUST be set to 0, since they do not appear in zone
- data. If encountered, they must be ignored upon reading.
-
- Blocks with no types present MUST NOT be included. Trailing zero
- octets in the bitmap MUST be omitted. The length of the bitmap of
- each block is determined by the type code with the largest numerical
- value, within that block, among the set of RR types present at the
- original owner name of the NSEC3 RR. Trailing octets not specified
- MUST be interpreted as zero octets.
-
-3.3. Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- o The Hash Algorithm field is represented as an unsigned decimal
- integer. The value has a maximum of 255.
-
- o The Flags field is represented as an unsigned decimal integer.
- The value has a maximum of 255.
-
- o The Iterations field is represented as an unsigned decimal
- integer. The value is between 0 and 65535, inclusive.
-
- o The Salt Length field is not represented.
-
- o The Salt field is represented as a sequence of case-insensitive
- hexadecimal digits. Whitespace is not allowed within the
- sequence. The Salt field is represented as "-" (without the
- quotes) when the Salt Length field has a value of 0.
-
- o The Hash Length field is not represented.
-
- o The Next Hashed Owner Name field is represented as an unpadded
- sequence of case-insensitive base32 digits, without whitespace.
-
- o The Type Bit Maps field is represented as a sequence of RR type
- mnemonics. When the mnemonic is not known, the TYPE
- representation as described in Section 5 of [RFC3597] MUST be
- used.
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 11]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-4. The NSEC3PARAM Resource Record
-
- The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
- flags, iterations, and salt) needed by authoritative servers to
- calculate hashed owner names. The presence of an NSEC3PARAM RR at a
- zone apex indicates that the specified parameters may be used by
- authoritative servers to choose an appropriate set of NSEC3 RRs for
- negative responses. The NSEC3PARAM RR is not used by validators or
- resolvers.
-
- If an NSEC3PARAM RR is present at the apex of a zone with a Flags
- field value of zero, then there MUST be an NSEC3 RR using the same
- hash algorithm, iterations, and salt parameters present at every
- hashed owner name in the zone. That is, the zone MUST contain a
- complete set of NSEC3 RRs with the same hash algorithm, iterations,
- and salt parameters.
-
- The owner name for the NSEC3PARAM RR is the name of the zone apex.
-
- The type value for the NSEC3PARAM RR is 51.
-
- The NSEC3PARAM RR RDATA format is class independent and is described
- below.
-
- The class MUST be the same as the NSEC3 RRs to which this RR refers.
-
-4.1. RDATA Fields
-
- The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
-
-4.1.1. Hash Algorithm
-
- The Hash Algorithm field identifies the cryptographic hash algorithm
- used to construct the hash-value.
-
- The acceptable values are the same as the corresponding field in the
- NSEC3 RR.
-
-4.1.2. Flag Fields
-
- The Opt-Out flag is not used and is set to zero.
-
- All other flags are reserved for future use, and must be zero.
-
- NSEC3PARAM RRs with a Flags field value other than zero MUST be
- ignored.
-
-
-
-
-
-Laurie, et al. Standards Track [Page 12]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-4.1.3. Iterations
-
- The Iterations field defines the number of additional times the hash
- is performed.
-
- Its acceptable values are the same as the corresponding field in the
- NSEC3 RR.
-
-4.1.4. Salt Length
-
- The Salt Length field defines the length of the salt in octets,
- ranging in value from 0 to 255.
-
-4.1.5. Salt
-
- The Salt field is appended to the original owner name before hashing.
-
-4.2. NSEC3PARAM RDATA Wire Format
-
- The RDATA of the NSEC3PARAM RR is as shown below:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Hash Alg. | Flags | Iterations |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Salt Length | Salt /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Hash Algorithm is a single octet.
-
- Flags field is a single octet.
-
- Iterations is represented as a 16-bit unsigned integer, with the most
- significant bit first.
-
- Salt Length is represented as an unsigned octet. Salt Length
- represents the length of the following Salt field in octets. If the
- value is zero, the Salt field is omitted.
-
- Salt, if present, is encoded as a sequence of binary octets. The
- length of this field is determined by the preceding Salt Length
- field.
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 13]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-4.3. Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- o The Hash Algorithm field is represented as an unsigned decimal
- integer. The value has a maximum of 255.
-
- o The Flags field is represented as an unsigned decimal integer.
- The value has a maximum value of 255.
-
- o The Iterations field is represented as an unsigned decimal
- integer. The value is between 0 and 65535, inclusive.
-
- o The Salt Length field is not represented.
-
- o The Salt field is represented as a sequence of case-insensitive
- hexadecimal digits. Whitespace is not allowed within the
- sequence. This field is represented as "-" (without the quotes)
- when the Salt Length field is zero.
-
-5. Calculation of the Hash
-
- The hash calculation uses three of the NSEC3 RDATA fields: Hash
- Algorithm, Salt, and Iterations.
-
- Define H(x) to be the hash of x using the Hash Algorithm selected by
- the NSEC3 RR, k to be the number of Iterations, and || to indicate
- concatenation. Then define:
-
- IH(salt, x, 0) = H(x || salt), and
-
- IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
-
- Then the calculated hash of an owner name is
-
- IH(salt, owner name, iterations),
-
- where the owner name is in the canonical form, defined as:
-
- The wire format of the owner name where:
-
- 1. The owner name is fully expanded (no DNS name compression) and
- fully qualified;
-
- 2. All uppercase US-ASCII letters are replaced by the corresponding
- lowercase US-ASCII letters;
-
-
-
-
-
-Laurie, et al. Standards Track [Page 14]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- 3. If the owner name is a wildcard name, the owner name is in its
- original unexpanded form, including the "*" label (no wildcard
- substitution);
-
- This form is as defined in Section 6.2 of [RFC4034].
-
- The method to calculate the Hash is based on [RFC2898].
-
-6. Opt-Out
-
- In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS
- RRSets at delegation points are not signed and may be accompanied by
- a DS RRSet. With the Opt-Out bit clear, the security status of the
- child zone is determined by the presence or absence of this DS RRSet,
- cryptographically proven by the signed NSEC3 RR at the hashed owner
- name of the delegation. Setting the Opt-Out flag modifies this by
- allowing insecure delegations to exist within the signed zone without
- a corresponding NSEC3 RR at the hashed owner name of the delegation.
-
- An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the
- owner name or "next closer" name of the delegation is between the
- owner name of the NSEC3 RR and the next hashed owner name.
-
- An Opt-Out NSEC3 RR does not assert the existence or non-existence of
- the insecure delegations that it may cover. This allows for the
- addition or removal of these delegations without recalculating or re-
- signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do
- assert the (non)existence of other, authoritative RRSets.
-
- An Opt-Out NSEC3 RR MAY have the same original owner name as an
- insecure delegation. In this case, the delegation is proven insecure
- by the lack of a DS bit in the type map and the signed NSEC3 RR does
- assert the existence of the delegation.
-
- Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and
- non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT
- be any hashed owner names of insecure delegations (nor any other RRs)
- between it and the name indicated by the next hashed owner name in
- the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner
- names or hashed "next closer" names of insecure delegations.
-
- The effects of the Opt-Out flag on signing, serving, and validating
- responses are covered in following sections.
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 15]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-7. Authoritative Server Considerations
-
-7.1. Zone Signing
-
- Zones using NSEC3 must satisfy the following properties:
-
- o Each owner name within the zone that owns authoritative RRSets
- MUST have a corresponding NSEC3 RR. Owner names that correspond
- to unsigned delegations MAY have a corresponding NSEC3 RR.
- However, if there is not a corresponding NSEC3 RR, there MUST be
- an Opt-Out NSEC3 RR that covers the "next closer" name to the
- delegation. Other non-authoritative RRs are not represented by
- NSEC3 RRs.
-
- o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
- the empty non-terminal is only derived from an insecure delegation
- covered by an Opt-Out NSEC3 RR.
-
- o The TTL value for any NSEC3 RR SHOULD be the same as the minimum
- TTL value field in the zone SOA RR.
-
- o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST
- indicate the presence of all types present at the original owner
- name, except for the types solely contributed by an NSEC3 RR
- itself. Note that this means that the NSEC3 type itself will
- never be present in the Type Bit Maps.
-
- The following steps describe a method of proper construction of NSEC3
- RRs. This is not the only such possible method.
-
- 1. Select the hash algorithm and the values for salt and iterations.
-
- 2. For each unique original owner name in the zone add an NSEC3 RR.
-
- * If Opt-Out is being used, owner names of unsigned delegations
- MAY be excluded.
-
- * The owner name of the NSEC3 RR is the hash of the original
- owner name, prepended as a single label to the zone name.
-
- * The Next Hashed Owner Name field is left blank for the moment.
-
- * If Opt-Out is being used, set the Opt-Out bit to one.
-
- * For collision detection purposes, optionally keep track of the
- original owner name with the NSEC3 RR.
-
-
-
-
-
-Laurie, et al. Standards Track [Page 16]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- * Additionally, for collision detection purposes, optionally
- create an additional NSEC3 RR corresponding to the original
- owner name with the asterisk label prepended (i.e., as if a
- wildcard existed as a child of this owner name) and keep track
- of this original owner name. Mark this NSEC3 RR as temporary.
-
- 3. For each RRSet at the original owner name, set the corresponding
- bit in the Type Bit Maps field.
-
- 4. If the difference in number of labels between the apex and the
- original owner name is greater than 1, additional NSEC3 RRs need
- to be added for every empty non-terminal between the apex and the
- original owner name. This process may generate NSEC3 RRs with
- duplicate hashed owner names. Optionally, for collision
- detection, track the original owner names of these NSEC3 RRs and
- create temporary NSEC3 RRs for wildcard collisions in a similar
- fashion to step 1.
-
- 5. Sort the set of NSEC3 RRs into hash order.
-
- 6. Combine NSEC3 RRs with identical hashed owner names by replacing
- them with a single NSEC3 RR with the Type Bit Maps field
- consisting of the union of the types represented by the set of
- NSEC3 RRs. If the original owner name was tracked, then
- collisions may be detected when combining, as all of the matching
- NSEC3 RRs should have the same original owner name. Discard any
- possible temporary NSEC3 RRs.
-
- 7. In each NSEC3 RR, insert the next hashed owner name by using the
- value of the next NSEC3 RR in hash order. The next hashed owner
- name of the last NSEC3 RR in the zone contains the value of the
- hashed owner name of the first NSEC3 RR in the hash order.
-
- 8. Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
- Iterations, and Salt fields to the zone apex.
-
- If a hash collision is detected, then a new salt has to be chosen,
- and the signing process restarted.
-
-7.2. Zone Serving
-
- This specification modifies DNSSEC-enabled DNS responses generated by
- authoritative servers. In particular, it replaces the use of NSEC
- RRs in such responses with NSEC3 RRs.
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 17]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- In the following response cases, the NSEC RRs dictated by DNSSEC
- [RFC4035] are replaced with NSEC3 RRs that prove the same facts.
- Responses that would not contain NSEC RRs are unchanged by this
- specification.
-
- When returning responses containing multiple NSEC3 RRs, all of the
- NSEC3 RRs MUST use the same hash algorithm, iteration, and salt
- values. The Flags field value MUST be either zero or one.
-
-7.2.1. Closest Encloser Proof
-
- For many NSEC3 responses a proof of the closest encloser is required.
- This is a proof that some ancestor of the QNAME is the closest
- encloser of QNAME.
-
- This proof consists of (up to) two different NSEC3 RRs:
-
- o An NSEC3 RR that matches the closest (provable) encloser.
-
- o An NSEC3 RR that covers the "next closer" name to the closest
- encloser.
-
- The first NSEC3 RR essentially proposes a possible closest encloser,
- and proves that the particular encloser does, in fact, exist. The
- second NSEC3 RR proves that the possible closest encloser is the
- closest, and proves that the QNAME (and any ancestors between QNAME
- and the closest encloser) does not exist.
-
- These NSEC3 RRs are collectively referred to as the "closest encloser
- proof" in the subsequent descriptions.
-
- For example, the closest encloser proof for the nonexistent
- "alpha.beta.gamma.example." owner name might prove that
- "gamma.example." is the closest encloser. This response would
- contain the NSEC3 RR that matches "gamma.example.", and would also
- contain the NSEC3 RR that covers "beta.gamma.example." (which is the
- "next closer" name).
-
- It is possible, when using Opt-Out (Section 6), to not be able to
- prove the actual closest encloser because it is, or is part of an
- insecure delegation covered by an Opt-Out span. In this case,
- instead of proving the actual closest encloser, the closest provable
- encloser is used. That is, the closest enclosing authoritative name
- is used instead. In this case, the set of NSEC3 RRs used for this
- proof is referred to as the "closest provable encloser proof".
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 18]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-7.2.2. Name Error Responses
-
- To prove the nonexistence of QNAME, a closest encloser proof and an
- NSEC3 RR covering the (nonexistent) wildcard RR at the closest
- encloser MUST be included in the response. This collection of (up
- to) three NSEC3 RRs proves both that QNAME does not exist and that a
- wildcard that could have matched QNAME also does not exist.
-
- For example, if "gamma.example." is the closest provable encloser to
- QNAME, then an NSEC3 RR covering "*.gamma.example." is included in
- the authority section of the response.
-
-7.2.3. No Data Responses, QTYPE is not DS
-
- The server MUST include the NSEC3 RR that matches QNAME. This NSEC3
- RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
- set in its Type Bit Maps field.
-
-7.2.4. No Data Responses, QTYPE is DS
-
- If there is an NSEC3 RR that matches QNAME, the server MUST return it
- in the response. The bits corresponding with DS and CNAME MUST NOT
- be set in the Type Bit Maps field of this NSEC3 RR.
-
- If no NSEC3 RR matches QNAME, the server MUST return a closest
- provable encloser proof for QNAME. The NSEC3 RR that covers the
- "next closer" name MUST have the Opt-Out bit set (note that this is
- true by definition -- if the Opt-Out bit is not set, something has
- gone wrong).
-
- If a server is authoritative for both sides of a zone cut at QNAME,
- the server MUST return the proof from the parent side of the zone
- cut.
-
-7.2.5. Wildcard No Data Responses
-
- If there is a wildcard match for QNAME, but QTYPE is not present at
- that name, the response MUST include a closest encloser proof for
- QNAME and MUST include the NSEC3 RR that matches the wildcard. This
- combination proves both that QNAME itself does not exist and that a
- wildcard that matches QNAME does exist. Note that the closest
- encloser to QNAME MUST be the immediate ancestor of the wildcard RR
- (if this is not the case, then something has gone wrong).
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 19]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-7.2.6. Wildcard Answer Responses
-
- If there is a wildcard match for QNAME and QTYPE, then, in addition
- to the expanded wildcard RRSet returned in the answer section of the
- response, proof that the wildcard match was valid must be returned.
-
- This proof is accomplished by proving that both QNAME does not exist
- and that the closest encloser of the QNAME and the immediate ancestor
- of the wildcard are the same (i.e., the correct wildcard matched).
-
- To this end, the NSEC3 RR that covers the "next closer" name of the
- immediate ancestor of the wildcard MUST be returned. It is not
- necessary to return an NSEC3 RR that matches the closest encloser, as
- the existence of this closest encloser is proven by the presence of
- the expanded wildcard in the response.
-
-7.2.7. Referrals to Unsigned Subzones
-
- If there is an NSEC3 RR that matches the delegation name, then that
- NSEC3 RR MUST be included in the response. The DS bit in the type
- bit maps of the NSEC3 RR MUST NOT be set.
-
- If the zone is Opt-Out, then there may not be an NSEC3 RR
- corresponding to the delegation. In this case, the closest provable
- encloser proof MUST be included in the response. The included NSEC3
- RR that covers the "next closer" name for the delegation MUST have
- the Opt-Out flag set to one. (Note that this will be the case unless
- something has gone wrong).
-
-7.2.8. Responding to Queries for NSEC3 Owner Names
-
- The owner names of NSEC3 RRs are not represented in the NSEC3 RR
- chain like other owner names. As a result, each NSEC3 owner name is
- covered by another NSEC3 RR, effectively negating the existence of
- the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR
- can be proven by its RRSIG RRSet.
-
- If the following conditions are all true:
-
- o the QNAME equals the owner name of an existing NSEC3 RR, and
-
- o no RR types exist at the QNAME, nor at any descendant of QNAME,
-
- then the response MUST be constructed as a Name Error response
- (Section 7.2.2). Or, in other words, the authoritative name server
- will act as if the owner name of the NSEC3 RR did not exist.
-
-
-
-
-
-Laurie, et al. Standards Track [Page 20]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
- query.
-
-7.2.9. Server Response to a Run-Time Collision
-
- If the hash of a non-existing QNAME collides with the owner name of
- an existing NSEC3 RR, then the server will be unable to return a
- response that proves that QNAME does not exist. In this case, the
- server MUST return a response with an RCODE of 2 (server failure).
-
- Note that with the hash algorithm specified in this document, SHA-1,
- such collisions are highly unlikely.
-
-7.3. Secondary Servers
-
- Secondary servers (and perhaps other entities) need to reliably
- determine which NSEC3 parameters (i.e., hash, salt, and iterations)
- are present at every hashed owner name, in order to be able to choose
- an appropriate set of NSEC3 RRs for negative responses. This is
- indicated by an NSEC3PARAM RR present at the zone apex.
-
- If there are multiple NSEC3PARAM RRs present, there are multiple
- valid NSEC3 chains present. The server must choose one of them, but
- may use any criteria to do so.
-
-7.4. Zones Using Unknown Hash Algorithms
-
- Zones that are signed according to this specification, but are using
- an unrecognized NSEC3 hash algorithm value, cannot be effectively
- served. Such zones SHOULD be rejected when loading. Servers SHOULD
- respond with RCODE=2 (server failure) responses when handling queries
- that would fall under such zones.
-
-7.5. Dynamic Update
-
- A zone signed using NSEC3 may accept dynamic updates [RFC2136].
- However, NSEC3 introduces some special considerations for dynamic
- updates.
-
- Adding and removing names in a zone MUST account for the creation or
- removal of empty non-terminals.
-
- o When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
- corresponding to empty non-terminals created by that name MUST be
- removed. Note that more than one name may be asserting the
- existence of a particular empty non-terminal.
-
-
-
-
-
-Laurie, et al. Standards Track [Page 21]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
- MUST also be added for any empty non-terminals that are created.
- That is, if there is not an existing NSEC3 RR matching an empty
- non-terminal, it must be created and added.
-
- The presence of Opt-Out in a zone means that some additions or
- delegations of names will not require changes to the NSEC3 RRs in a
- zone.
-
- o When removing a delegation RRSet, if that delegation does not have
- a matching NSEC3 RR, then it was opted out. In this case, nothing
- further needs to be done.
-
- o When adding a delegation RRSet, if the "next closer" name of the
- delegation is covered by an existing Opt-Out NSEC3 RR, then the
- delegation MAY be added without modifying the NSEC3 RRs in the
- zone.
-
- The presence of Opt-Out in a zone means that when adding or removing
- NSEC3 RRs, the value of the Opt-Out flag that should be set in new or
- modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of
- basic rules to resolve the ambiguity.
-
- The central concept to these rules is that the state of the Opt-Out
- flag of the covering NSEC3 RR is preserved.
-
- o When removing an NSEC3 RR, the value of the Opt-Out flag for the
- previous NSEC3 RR (the one whose next hashed owner name is
- modified) should not be changed.
-
- o When adding an NSEC3 RR, the value of the Opt-Out flag is set to
- the value of the Opt-Out flag of the NSEC3 RR that previously
- covered the owner name of the NSEC3 RR. That is, the now previous
- NSEC3 RR.
-
- If the zone in question is consistent with its use of the Opt-Out
- flag (that is, all NSEC3 RRs in the zone have the same value for the
- flag) then these rules will retain that consistency. If the zone is
- not consistent in the use of the flag (i.e., a partially Opt-Out
- zone), then these rules will not retain the same pattern of use of
- the Opt-Out flag.
-
- For zones that partially use the Opt-Out flag, if there is a logical
- pattern for that use, the pattern could be maintained by using a
- local policy on the server.
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 22]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-8. Validator Considerations
-
-8.1. Responses with Unknown Hash Types
-
- A validator MUST ignore NSEC3 RRs with unknown hash types. The
- practical result of this is that responses containing only such NSEC3
- RRs will generally be considered bogus.
-
-8.2. Verifying NSEC3 RRs
-
- A validator MUST ignore NSEC3 RRs with a Flag fields value other than
- zero or one.
-
- A validator MAY treat a response as bogus if the response contains
- NSEC3 RRs that contain different values for hash algorithm,
- iterations, or salt from each other for that zone.
-
-8.3. Closest Encloser Proof
-
- In order to verify a closest encloser proof, the validator MUST find
- the longest name, X, such that
-
- o X is an ancestor of QNAME that is matched by an NSEC3 RR present
- in the response. This is a candidate for the closest encloser,
- and
-
- o The name one label longer than X (but still an ancestor of -- or
- equal to -- QNAME) is covered by an NSEC3 RR present in the
- response.
-
- One possible algorithm for verifying this proof is as follows:
-
- 1. Set SNAME=QNAME. Clear the flag.
-
- 2. Check whether SNAME exists:
-
- * If there is no NSEC3 RR in the response that matches SNAME
- (i.e., an NSEC3 RR whose owner name is the same as the hash of
- SNAME, prepended as a single label to the zone name), clear
- the flag.
-
- * If there is an NSEC3 RR in the response that covers SNAME, set
- the flag.
-
- * If there is a matching NSEC3 RR in the response and the flag
- was set, then the proof is complete, and SNAME is the closest
- encloser.
-
-
-
-
-Laurie, et al. Standards Track [Page 23]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- * If there is a matching NSEC3 RR in the response, but the flag
- is not set, then the response is bogus.
-
- 3. Truncate SNAME by one label from the left, go to step 2.
-
- Once the closest encloser has been discovered, the validator MUST
- check that the NSEC3 RR that has the closest encloser as the original
- owner name is from the proper zone. The DNAME type bit must not be
- set and the NS type bit may only be set if the SOA type bit is set.
- If this is not the case, it would be an indication that an attacker
- is using them to falsely deny the existence of RRs for which the
- server is not authoritative.
-
- In the following descriptions, the phrase "a closest (provable)
- encloser proof for X" means that the algorithm above (or an
- equivalent algorithm) proves that X does not exist by proving that an
- ancestor of X is its closest encloser.
-
-8.4. Validating Name Error Responses
-
- A validator MUST verify that there is a closest encloser proof for
- QNAME present in the response and that there is an NSEC3 RR that
- covers the wildcard at the closest encloser (i.e., the name formed by
- prepending the asterisk label to the closest encloser).
-
-8.5. Validating No Data Responses, QTYPE is not DS
-
- The validator MUST verify that an NSEC3 RR that matches QNAME is
- present and that both the QTYPE and the CNAME type are not set in its
- Type Bit Maps field.
-
- Note that this test also covers the case where the NSEC3 RR exists
- because it corresponds to an empty non-terminal, in which case the
- NSEC3 RR will have an empty Type Bit Maps field.
-
-8.6. Validating No Data Responses, QTYPE is DS
-
- If there is an NSEC3 RR that matches QNAME present in the response,
- then that NSEC3 RR MUST NOT have the bits corresponding to DS and
- CNAME set in its Type Bit Maps field.
-
- If there is no such NSEC3 RR, then the validator MUST verify that a
- closest provable encloser proof for QNAME is present in the response,
- and that the NSEC3 RR that covers the "next closer" name has the Opt-
- Out bit set.
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 24]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-8.7. Validating Wildcard No Data Responses
-
- The validator MUST verify a closest encloser proof for QNAME and MUST
- find an NSEC3 RR present in the response that matches the wildcard
- name generated by prepending the asterisk label to the closest
- encloser. Furthermore, the bits corresponding to both QTYPE and
- CNAME MUST NOT be set in the wildcard matching NSEC3 RR.
-
-8.8. Validating Wildcard Answer Responses
-
- The verified wildcard answer RRSet in the response provides the
- validator with a (candidate) closest encloser for QNAME. This
- closest encloser is the immediate ancestor to the generating
- wildcard.
-
- Validators MUST verify that there is an NSEC3 RR that covers the
- "next closer" name to QNAME present in the response. This proves
- that QNAME itself did not exist and that the correct wildcard was
- used to generate the response.
-
-8.9. Validating Referrals to Unsigned Subzones
-
- The delegation name in a referral is the owner name of the NS RRSet
- present in the authority section of the referral response.
-
- If there is an NSEC3 RR present in the response that matches the
- delegation name, then the validator MUST ensure that the NS bit is
- set and that the DS bit is not set in the Type Bit Maps field of the
- NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from
- the correct (i.e., parent) zone. This is done by ensuring that the
- SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
-
- Note that the presence of an NS bit implies the absence of a DNAME
- bit, so there is no need to check for the DNAME bit in the Type Bit
- Maps field of the NSEC3 RR.
-
- If there is no NSEC3 RR present that matches the delegation name,
- then the validator MUST verify a closest provable encloser proof for
- the delegation name. The validator MUST verify that the Opt-Out bit
- is set in the NSEC3 RR that covers the "next closer" name to the
- delegation name.
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 25]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-9. Resolver Considerations
-
-9.1. NSEC3 Resource Record Caching
-
- Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs
- when returning responses that contain them. In DNSSEC [RFC4035], in
- many cases it is possible to find the correct NSEC RR to return in a
- response by name (e.g., when returning a referral, the NSEC RR will
- always have the same owner name as the delegation). With this
- specification, that will not be true, nor will a cache be able to
- calculate the name(s) of the appropriate NSEC3 RR(s).
- Implementations may need to use new methods for caching and
- retrieving NSEC3 RRs.
-
-9.2. Use of the AD Bit
-
- The AD bit, as defined by [RFC4035], MUST NOT be set when returning a
- response containing a closest (provable) encloser proof in which the
- NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
-
- This rule is based on what this closest encloser proof actually
- proves: names that would be covered by the Opt-Out NSEC3 RR may or
- may not exist as insecure delegations. As such, not all the data in
- responses containing such closest encloser proofs will have been
- cryptographically verified, so the AD bit cannot be set.
-
-10. Special Considerations
-
-10.1. Domain Name Length Restrictions
-
- Zones signed using this specification have additional domain name
- length restrictions imposed upon them. In particular, zones with
- names that, when converted into hashed owner names exceed the 255
- octet length limit imposed by [RFC1035], cannot use this
- specification.
-
- The actual maximum length of a domain name in a particular zone
- depends on both the length of the zone name (versus the whole domain
- name) and the particular hash function used.
-
- As an example, SHA-1 produces a hash of 160 bits. The base-32
- encoding of 160 bits results in 32 characters. The 32 characters are
- prepended to the name of the zone as a single label, which includes a
- length field of a single octet. The maximum length of the zone name,
- when using SHA-1, is 222 octets (255 - 33).
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 26]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-10.2. DNAME at the Zone Apex
-
- The DNAME specification in Section 3 of [RFC2672] has a 'no-
- descendants' limitation. If a DNAME RR is present at node N, there
- MUST be no data at any descendant of N.
-
- If N is the apex of the zone, there will be NSEC3 and RRSIG types
- present at descendants of N. This specification updates the DNAME
- specification to allow NSEC3 and RRSIG types at descendants of the
- apex regardless of the existence of DNAME at the apex.
-
-10.3. Iterations
-
- Setting the number of iterations used allows the zone owner to choose
- the cost of computing a hash, and therefore the cost of generating a
- dictionary. Note that this is distinct from the effect of salt,
- which prevents the use of a single precomputed dictionary for all
- time.
-
- Obviously the number of iterations also affects the zone owner's cost
- of signing and serving the zone as well as the validator's cost of
- verifying responses from the zone. We therefore impose an upper
- limit on the number of iterations. We base this on the number of
- iterations that approximates the cost of verifying an RRSet.
-
- The limits, therefore, are based on the size of the smallest zone
- signing key, rounded up to the nearest table value (or rounded down
- if the key is larger than the largest table value).
-
- A zone owner MUST NOT use a value higher than shown in the table
- below for iterations for the given key size. A resolver MAY treat a
- response with a higher value as insecure, after the validator has
- verified that the signature over the NSEC3 RR is correct.
-
- +----------+------------+
- | Key Size | Iterations |
- +----------+------------+
- | 1024 | 150 |
- | 2048 | 500 |
- | 4096 | 2,500 |
- +----------+------------+
-
- This table is based on an approximation of the ratio between the cost
- of an SHA-1 calculation and the cost of an RSA verification for keys
- of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits
- (2500 to 1).
-
-
-
-
-
-Laurie, et al. Standards Track [Page 27]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- The ratio between SHA-1 calculation and DSA verification is higher
- (1500 to 1 for keys of size 1024). A higher iteration count degrades
- performance, while DSA verification is already more expensive than
- RSA for the same key size. Therefore the values in the table MUST be
- used independent of the key algorithm.
-
-10.4. Transitioning a Signed Zone from NSEC to NSEC3
-
- When transitioning an already signed and trusted zone to this
- specification, care must be taken to prevent client validation
- failures during the process.
-
- The basic procedure is as follows:
-
- 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases
- described in Section 2. The actual method for safely and
- securely changing the DNSKEY RRSet of the zone is outside the
- scope of this specification. However, the end result MUST be
- that all DS RRs in the parent use the specified algorithm
- aliases.
-
- After this transition is complete, all NSEC3-unaware clients will
- treat the zone as insecure. At this point, the authoritative
- server still returns negative and wildcard responses that contain
- NSEC RRs.
-
- 2. Add signed NSEC3 RRs to the zone, either incrementally or all at
- once. If adding incrementally, then the last RRSet added MUST be
- the NSEC3PARAM RRSet.
-
- 3. Upon the addition of the NSEC3PARAM RRSet, the server switches to
- serving negative and wildcard responses with NSEC3 RRs according
- to this specification.
-
- 4. Remove the NSEC RRs either incrementally or all at once.
-
-10.5. Transitioning a Signed Zone from NSEC3 to NSEC
-
- To safely transition back to a DNSSEC [RFC4035] signed zone, simply
- reverse the procedure above:
-
- 1. Add NSEC RRs incrementally or all at once.
-
- 2. Remove the NSEC3PARAM RRSet. This will signal the server to use
- the NSEC RRs for negative and wildcard responses.
-
- 3. Remove the NSEC3 RRs either incrementally or all at once.
-
-
-
-
-Laurie, et al. Standards Track [Page 28]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- 4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
- After this transition is complete, all NSEC3-unaware clients will
- treat the zone as secure.
-
-11. IANA Considerations
-
- Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
- parameter, this document does not define a particular mechanism for
- safely transitioning from one NSEC3 hash algorithm to another. When
- specifying a new hash algorithm for use with NSEC3, a transition
- mechanism MUST also be defined.
-
- This document updates the IANA registry "DOMAIN NAME SYSTEM
- PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-
- registry "TYPES", by defining two new types. Section 3 defines the
- NSEC3 RR type 50. Section 4 defines the NSEC3PARAM RR type 51.
-
- This document updates the IANA registry "DNS SECURITY ALGORITHM
- NUMBERS -- per [RFC4035]"
- (http://www.iana.org/assignments/dns-sec-alg-numbers). Section 2
- defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for
- respectively existing registrations DSA and RSASHA1 in combination
- with NSEC3 hash algorithm SHA1.
-
- Since these algorithm numbers are aliases for existing DNSKEY
- algorithm numbers, the flags that exist for the original algorithm
- are valid for the alias algorithm.
-
- This document creates a new IANA registry for NSEC3 flags. This
- registry is named "DNSSEC NSEC3 Flags". The initial contents of this
- registry are:
-
- 0 1 2 3 4 5 6 7
- +---+---+---+---+---+---+---+---+
- | | | | | | | |Opt|
- | | | | | | | |Out|
- +---+---+---+---+---+---+---+---+
-
- bit 7 is the Opt-Out flag.
-
- bits 0 - 6 are available for assignment.
-
- Assignment of additional NSEC3 Flags in this registry requires IETF
- Standards Action [RFC2434].
-
- This document creates a new IANA registry for NSEC3PARAM flags. This
- registry is named "DNSSEC NSEC3PARAM Flags". The initial contents of
- this registry are:
-
-
-
-Laurie, et al. Standards Track [Page 29]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- 0 1 2 3 4 5 6 7
- +---+---+---+---+---+---+---+---+
- | | | | | | | | 0 |
- +---+---+---+---+---+---+---+---+
-
- bit 7 is reserved and must be 0.
-
- bits 0 - 6 are available for assignment.
-
- Assignment of additional NSEC3PARAM Flags in this registry requires
- IETF Standards Action [RFC2434].
-
- Finally, this document creates a new IANA registry for NSEC3 hash
- algorithms. This registry is named "DNSSEC NSEC3 Hash Algorithms".
- The initial contents of this registry are:
-
- 0 is Reserved.
-
- 1 is SHA-1.
-
- 2-255 Available for assignment.
-
- Assignment of additional NSEC3 hash algorithms in this registry
- requires IETF Standards Action [RFC2434].
-
-12. Security Considerations
-
-12.1. Hashing Considerations
-
-12.1.1. Dictionary Attacks
-
- The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the
- attacker retrieves all the NSEC3 RRs, then calculates the hashes of
- all likely domain names, comparing against the hashes found in the
- NSEC3 RRs, and thus enumerating the zone). These are substantially
- more expensive than enumerating the original NSEC RRs would have
- been, and in any case, such an attack could also be used directly
- against the name server itself by performing queries for all likely
- names, though this would obviously be more detectable. The expense
- of this off-line attack can be chosen by setting the number of
- iterations in the NSEC3 RR.
-
- Zones are also susceptible to a pre-calculated dictionary attack --
- that is, a list of hashes for all likely names is computed once, then
- NSEC3 RR is scanned periodically and compared against the precomputed
- hashes. This attack is prevented by changing the salt on a regular
- basis.
-
-
-
-
-Laurie, et al. Standards Track [Page 30]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- The salt SHOULD be at least 64 bits long and unpredictable, so that
- an attacker cannot anticipate the value of the salt and compute the
- next set of dictionaries before the zone is published.
-
-12.1.2. Collisions
-
- Hash collisions between QNAME and the owner name of an NSEC3 RR may
- occur. When they do, it will be impossible to prove the non-
- existence of the colliding QNAME. However, with SHA-1, this is
- highly unlikely (on the order of 1 in 2^160). Note that DNSSEC
- already relies on the presumption that a cryptographic hash function
- is second pre-image resistant, since these hash functions are used
- for generating and validating signatures and DS RRs.
-
-12.1.3. Transitioning to a New Hash Algorithm
-
- Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
- parameter, this document does not define a particular mechanism for
- safely transitioning from one NSEC3 hash algorithm to another. When
- specifying a new hash algorithm for use with NSEC3, a transition
- mechanism MUST also be defined. It is possible that the only
- practical and palatable transition mechanisms may require an
- intermediate transition to an insecure state, or to a state that uses
- NSEC records instead of NSEC3.
-
-12.1.4. Using High Iteration Values
-
- Since validators should treat responses containing NSEC3 RRs with
- high iteration values as insecure, presence of just one signed NSEC3
- RR with a high iteration value in a zone provides attackers with a
- possible downgrade attack.
-
- The attack is simply to remove any existing NSEC3 RRs from a
- response, and replace or add a single (or multiple) NSEC3 RR that
- uses a high iterations value to the response. Validators will then
- be forced to treat the response as insecure. This attack would be
- effective only when all of following conditions are met:
-
- o There is at least one signed NSEC3 RR that uses a high iterations
- value present in the zone.
-
- o The attacker has access to one or more of these NSEC3 RRs. This
- is trivially true when the NSEC3 RRs with high iteration values
- are being returned in typical responses, but may also be true if
- the attacker can access the zone via AXFR or IXFR queries, or any
- other methodology.
-
-
-
-
-
-Laurie, et al. Standards Track [Page 31]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- Using a high number of iterations also introduces an additional
- denial-of-service opportunity against servers, since servers must
- calculate several hashes per negative or wildcard response.
-
-12.2. Opt-Out Considerations
-
- The Opt-Out Flag (O) allows for unsigned names, in the form of
- delegations to unsigned zones, to exist within an otherwise signed
- zone. All unsigned names are, by definition, insecure, and their
- validity or existence cannot be cryptographically proven.
-
- In general:
-
- o Resource records with unsigned names (whether existing or not)
- suffer from the same vulnerabilities as RRs in an unsigned zone.
- These vulnerabilities are described in more detail in [RFC3833]
- (note in particular Section 2.3, "Name Chaining" and Section 2.6,
- "Authenticated Denial of Domain Names").
-
- o Resource records with signed names have the same security whether
- or not Opt-Out is used.
-
- Note that with or without Opt-Out, an insecure delegation may be
- undetectably altered by an attacker. Because of this, the primary
- difference in security when using Opt-Out is the loss of the ability
- to prove the existence or nonexistence of an insecure delegation
- within the span of an Opt-Out NSEC3 RR.
-
- In particular, this means that a malicious entity may be able to
- insert or delete RRs with unsigned names. These RRs are normally NS
- RRs, but this also includes signed wildcard expansions (while the
- wildcard RR itself is signed, its expanded name is an unsigned name).
-
- Note that being able to add a delegation is functionally equivalent
- to being able to add any RR type: an attacker merely has to forge a
- delegation to name server under his/her control and place whatever
- RRs needed at the subzone apex.
-
- While in particular cases, this issue may not present a significant
- security problem, in general it should not be lightly dismissed.
- Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly.
- In particular, zone signing tools SHOULD NOT default to using Opt-
- Out, and MAY choose to not support Opt-Out at all.
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 32]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-12.3. Other Considerations
-
- Walking the NSEC3 RRs will reveal the total number of RRs in the zone
- (plus empty non-terminals), and also what types there are. This
- could be mitigated by adding dummy entries, but certainly an upper
- limit can always be found.
-
-13. References
-
-13.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and
- facilities", STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS
- UPDATE)", RFC 2136, April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
- Writing an IANA Considerations Section in RFCs",
- BCP 26, RFC 2434, October 1998.
-
- [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
- "Domain Name System (DNS) IANA Considerations",
- BCP 42, RFC 2929, September 2000.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
- Record (RR) Types", RFC 3597, September 2003.
-
- [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.
-
-
-
-Laurie, et al. Standards Track [Page 33]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D.,
- and S. Rose, "Protocol Modifications for the DNS
- Security Extensions", RFC 4035, March 2005.
-
- [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
- Encodings", RFC 4648, October 2006.
-
-13.2. Informative References
-
- [DNSEXT-NO] Josefsson, S., "Authenticating Denial of Existence
- in DNS with Minimum Disclosure", Work in Progress,
- July 2000.
-
- [DNSEXT-NSEC2v2] Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format",
- Work in Progress, December 2004.
-
- [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
- RFC 2672, August 1999.
-
- [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
- Specification Version 2.0", RFC 2898,
- September 2000.
-
- [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
- Domain Name System (DNS)", RFC 3833, August 2004.
-
- [RFC4592] Lewis, E., "The Role of Wildcards in the Domain
- Name System", RFC 4592, July 2006.
-
- [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS
- Security (DNSSEC) Opt-In", RFC 4956, July 2007.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 34]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-Appendix A. Example Zone
-
- This is a zone showing its NSEC3 RRs. They can also be used as test
- vectors for the hash algorithm.
-
- The overall TTL and class are specified in the SOA RR, and are
- subsequently omitted for clarity.
-
- The zone is preceded by a list that contains the hashes of the
- original ownernames.
-
- ; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
- ; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl
- ; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi
- ; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
- ; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r
- ; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
- ; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
- ; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
- ; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc
- ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
- ; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv
- ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
- ; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
- example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
- RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
- 40430 example.
- Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
- q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
- VI2LmKusbZsT0Q== )
- NS ns1.example.
- NS ns2.example.
- RRSIG NS 7 1 3600 20150420235959 20051021000000 (
- 40430 example.
- PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
- qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
- CnMXjtz6SyObxA== )
- MX 1 xx.example.
- RRSIG MX 7 1 3600 20150420235959 20051021000000 (
- 40430 example.
- GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw
- 9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ
- n9Mto/Kx+wBo+w== )
- DNSKEY 256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
- sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
- TY4hHn9npWFRw5BYubE= )
-
-
-
-
-Laurie, et al. Standards Track [Page 35]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- DNSKEY 257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
- j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
- AbsUdblMFin8CVF3n4s= )
- RRSIG DNSKEY 7 1 3600 20150420235959 (
- 20051021000000 12708 example.
- AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31
- uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm
- MGQZf3bH+QsCtg== )
- NSEC3PARAM 1 0 12 aabbccdd
- RRSIG NSEC3PARAM 7 1 3600 20150420235959 (
- 20051021000000 40430 example.
- C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re
- rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ
- TLQsjlkynhG6Cg== )
- 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
- SOA NSEC3PARAM RRSIG )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
- IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
- BOCXJZMnpuwhpA== )
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
- RRSIG A 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed
- K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW
- k8p6xHMPZumXlw== )
- NSEC3 1 1 12 aabbccdd (
- 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
- 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
- NI6mRk/r1dOSUw== )
- 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
- 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG
- VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob
- TuktZ+sdsZPY1w== )
- 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
- b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 36]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
- Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
- XtAIR3chwgW+SA== )
- a.example. NS ns1.a.example.
- NS ns2.a.example.
- DS 58470 5 1 (
- 3079F1593EBAD6DC121E202A8B766A6A4837206C )
- RRSIG DS 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh
- M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo
- o722vZ4UZ2dIdA== )
- ns1.a.example. A 192.0.2.5
- ns2.a.example. A 192.0.2.6
- ai.example. A 192.0.2.9
- RRSIG A 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
- tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
- rznEn8sQ64UdqA== )
- HINFO "KLH-10" "ITS"
- RRSIG HINFO 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx
- enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1
- v0wLHpEZG7Xj2w== )
- AAAA 2001:db8:0:0:0:0:f00:baa9
- RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
- uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
- cHueLuXkMjBArQ== )
- b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
- gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
- 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
- pOv0TSTyiTxIZg== )
- c.example. NS ns1.c.example.
- NS ns2.c.example.
- ns1.c.example. A 192.0.2.7
- ns2.c.example. A 192.0.2.8
- gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
- ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
- RRSIG )
-
-
-
-Laurie, et al. Standards Track [Page 37]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by
- LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK
- Dy+rdGIeRSVNyw== )
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
- k8udemvp1j2f7eg6jebps17vp3n8i58h )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
- 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
- MpzVSKfTwx4uYA== )
- k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
- kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
- S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
- Otx7w9WfcIg62A== )
- kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
- q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr
- 6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F
- QJazmASFKGxGXg== )
- ns1.example. A 192.0.2.1
- RRSIG A 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j
- kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN
- 4FRvZR9SCFHF5Q== )
- ns2.example. A 192.0.2.2
- RRSIG A 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4
- zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj
- 4IHfeX6n8vfoGA== )
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
- r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
- ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
- NlkxWcLsIlMmUg== )
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 38]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
- t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
- ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
- HF1FWKW7RIJdtQ== )
- t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
- 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
- RRSIG )
- RRSIG NSEC3 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca
- fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI
- X1xPl1ATNa+8Dw== )
- *.w.example. MX 1 ai.example.
- RRSIG MX 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
- 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
- ivEBP6+4KS3ldA== )
- x.w.example. MX 1 xx.example.
- RRSIG MX 7 3 3600 20150420235959 20051021000000 (
- 40430 example.
- IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv
- QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY
- 7WCtwwekLKRAwQ== )
- x.y.w.example. MX 1 xx.example.
- RRSIG MX 7 4 3600 20150420235959 20051021000000 (
- 40430 example.
- MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn
- nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze
- 8/8Ccl2Zn2hbug== )
- xx.example. A 192.0.2.10
- RRSIG A 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX
- YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX
- pQvhq+Ac6+ZiFg== )
- HINFO "KLH-10" "TOPS-20"
- RRSIG HINFO 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih
- FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW
- 6Jfqj/8NzWjvKg== )
- AAAA 2001:db8:0:0:0:0:f00:baaa
-
-
-
-
-
-Laurie, et al. Standards Track [Page 39]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe
- uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE
- NzYfMItpILl/Xw== )
-
-Appendix B. Example Responses
-
- The examples in this section show response messages using the signed
- zone example in Appendix A.
-
-B.1. Name Error
-
- An authoritative name error. The NSEC3 RRs prove that the name does
- not exist and that there is no wildcard RR that should have been
- expanded.
-
-;; Header: QR AA DO RCODE=3
-;;
-;; Question
-a.c.x.w.example. IN A
-
-;; Answer
-;; (empty)
-
-;; Authority
-
-example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
-example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
- 40430 example.
- Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
- q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
- VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
-;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
- SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
- IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
- BOCXJZMnpuwhpA== )
-
-
-
-
-
-Laurie, et al. Standards Track [Page 40]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-;; NSEC3 RR that matches the closest encloser (x.w.example)
-;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
-
-b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
- gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
-b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
- 5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
- pOv0TSTyiTxIZg== )
-
-;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
-;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
-
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
- b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
- Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
- XtAIR3chwgW+SA== )
-
-;; Additional
-;; (empty)
-
- The query returned three NSEC3 RRs that prove that the requested data
- does not exist and that no wildcard expansion applies. The negative
- response is authenticated by verifying the NSEC3 RRs. The
- corresponding RRSIGs indicate that the NSEC3 RRs are signed by an
- "example" DNSKEY of algorithm 7 and with key tag 40430. The resolver
- needs the corresponding DNSKEY RR in order to authenticate this
- answer.
-
- One of the owner names of the NSEC3 RRs matches the closest encloser.
- One of the NSEC3 RRs prove that there exists no longer name. One of
- the NSEC3 RRs prove that there exists no wildcard RRSets that should
- have been expanded. The closest encloser can be found by applying
- the algorithm in Section 8.3.
-
- In the above example, the name 'x.w.example' hashes to
- 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might
- be the closest encloser. To prove that 'c.x.w.example' and
- '*.x.w.example' do not exist, these names are hashed to,
- respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and
- '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs
- prove that these hashed owner names do not exist.
-
-
-
-
-
-Laurie, et al. Standards Track [Page 41]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-B.2. No Data Error
-
- A "no data" response. The NSEC3 RR proves that the name exists and
- that the requested RR type does not.
-
-;; Header: QR AA DO RCODE=0
-;;
-;; Question
-ns1.example. IN MX
-
-;; Answer
-;; (empty)
-
-;; Authority
-example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
-example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
- 40430 example.
- Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
- q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
- VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.
-
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
- 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
- 4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
- NI6mRk/r1dOSUw== )
-;; Additional
-;; (empty)
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"),
- but the requested RR type does not exist (type MX is absent in the
- type code list of the NSEC3 RR), and was not a CNAME (type CNAME is
- also absent in the type code list of the NSEC3 RR).
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 42]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-B.2.1. No Data Error, Empty Non-Terminal
-
- A "no data" response because of an empty non-terminal. The NSEC3 RR
- proves that the name exists and that the requested RR type does not.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- y.w.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
- example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
- 40430 example.
- Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
- q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
- VI2LmKusbZsT0Q== )
-
- ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
-
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
- k8udemvp1j2f7eg6jebps17vp3n8i58h )
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
- 2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
- MpzVSKfTwx4uYA== )
-
- ;; Additional
- ;; (empty)
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"),
- but the requested RR type does not exist (Type A is absent in the
- Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty
- non-terminal proof using NSECs, this is identical to a No Data Error.
- This example is solely mentioned to be complete.
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 43]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-B.3. Referral to an Opt-Out Unsigned Zone
-
- The NSEC3 RRs prove that nothing for this delegation was signed.
- There is no proof that the unsigned delegation exists.
-
- ;; Header: QR DO RCODE=0
- ;;
- ;; Question
- mc.c.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- c.example. NS ns1.c.example.
- NS ns2.c.example.
-
- ;; NSEC3 RR that covers the "next closer" name (c.example)
- ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
-
- 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
- b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
- 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
- Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
- XtAIR3chwgW+SA== )
-
- ;; NSEC3 RR that matches the closest encloser (example)
- ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
-
- 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
- SOA NSEC3PARAM RRSIG )
- 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
- IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
- BOCXJZMnpuwhpA== )
-
- ;; Additional
- ns1.c.example. A 192.0.2.7
- ns2.c.example. A 192.0.2.8
-
- The query returned a referral to the unsigned "c.example." zone. The
- response contains the closest provable encloser of "c.example" to be
- "example", since the hash of "c.example"
-
-
-
-
-Laurie, et al. Standards Track [Page 44]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
- and its Opt-Out bit is set.
-
-B.4. Wildcard Expansion
-
- A query that was answered with a response containing a wildcard
- expansion. The label count in the RRSIG RRSet in the answer section
- indicates that a wildcard RRSet was expanded to produce this
- response, and the NSEC3 RR proves that no "next closer" name exists
- in the zone.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN MX
-
- ;; Answer
- a.z.w.example. MX 1 ai.example.
- a.z.w.example. RRSIG MX 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
- 9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
- ivEBP6+4KS3ldA== )
-
- ;; Authority
- example. NS ns1.example.
- example. NS ns2.example.
- example. RRSIG NS 7 1 3600 20150420235959 20051021000000 (
- 40430 example.
- PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
- qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
- CnMXjtz6SyObxA== )
-
- ;; NSEC3 RR that covers the "next closer" name (z.w.example)
- ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
- r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
- ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
- NlkxWcLsIlMmUg== )
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 45]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- ;; Additional
- ai.example. A 192.0.2.9
- ai.example. RRSIG A 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
- tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
- rznEn8sQ64UdqA== )
- ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9
- ai.example. RRSIG AAAA 7 2 3600 20150420235959 20051021000000 (
- 40430 example.
- LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
- uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
- cHueLuXkMjBArQ== )
-
- The query returned an answer that was produced as a result of a
- wildcard expansion. The answer section contains a wildcard RRSet
- expanded as it would be in a traditional DNS response. The RRSIG
- Labels field value of 2 indicates that the answer is the result of a
- wildcard expansion, as the "a.z.w.example" name contains 4 labels.
- This also shows that "w.example" exists, so there is no need for an
- NSEC3 RR that matches the closest encloser.
-
- The NSEC3 RR proves that no closer match could have been used to
- answer this query.
-
-B.5. Wildcard No Data Error
-
- A "no data" response for a name covered by a wildcard. The NSEC3 RRs
- prove that the matching wildcard name does not have any RRs of the
- requested type and that no closer match exists in the zone.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN AAAA
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
- example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
- 40430 example.
- Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
- q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
- VI2LmKusbZsT0Q== )
-
-
-
-
-Laurie, et al. Standards Track [Page 46]
-\f
-RFC 5155 NSEC3 March 2008
-
-
- ;; NSEC3 RR that matches the closest encloser (w.example)
- ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
-
- k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
- kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
- k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
- S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
- Otx7w9WfcIg62A== )
-
- ;; NSEC3 RR that covers the "next closer" name (z.w.example)
- ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
- r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
- q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
- ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
- NlkxWcLsIlMmUg== )
-
- ;; NSEC3 RR that matches a wildcard at the closest encloser.
- ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
-
- r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
- t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
- r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 (
- 20150420235959 20051021000000 40430 example.
- aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
- ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
- HF1FWKW7RIJdtQ== )
-
- ;; Additional
- ;; (empty)
-
- The query returned the NSEC3 RRs that prove that the requested data
- does not exist and no wildcard RR applies.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 47]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-B.6. DS Child Zone No Data Error
-
- A "no data" response for a QTYPE=DS query that was mistakenly sent to
- a name server for the child zone.
-
-;; Header: QR AA DO RCODE=0
-;;
-;; Question
-example. IN DS
-
-;; Answer
-;; (empty)
-
-;; Authority
-example. SOA ns1.example. bugs.x.w.example. 1 3600 300 (
- 3600000 3600 )
-example. RRSIG SOA 7 1 3600 20150420235959 20051021000000 (
- 40430 example.
- Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
- q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
- VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
- 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
- SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600
- 20150420235959 20051021000000 40430 example.
- OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
- IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
- BOCXJZMnpuwhpA== )
-
-;; Additional
-;; (empty)
-
- The query returned an NSEC3 RR showing that the requested was
- answered by the server authoritative for the zone "example". The
- NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3
- RR is from the apex of the child, not from the zone cut of the
- parent. Queries for the "example" DS RRSet should be sent to the
- parent servers (which are in this case the root servers).
-
-Appendix C. Special Considerations
-
- The following paragraphs clarify specific behavior and explain
- special considerations for implementations.
-
-
-
-
-Laurie, et al. Standards Track [Page 48]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-C.1. Salting
-
- Augmenting original owner names with salt before hashing increases
- the cost of a dictionary of pre-generated hash-values. For every bit
- of salt, the cost of a precomputed dictionary doubles (because there
- must be an entry for each word combined with each possible salt
- value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
- salt, multiplying the cost by 2^2040. This means that an attacker
- must, in practice, recompute the dictionary each time the salt is
- changed.
-
- Including a salt, regardless of size, does not affect the cost of
- constructing NSEC3 RRs. It does increase the size of the NSEC3 RR.
-
- There MUST be at least one complete set of NSEC3 RRs for the zone
- using the same salt value.
-
- The salt SHOULD be changed periodically to prevent pre-computation
- using a single salt. It is RECOMMENDED that the salt be changed for
- every re-signing.
-
- Note that this could cause a resolver to see RRs with different salt
- values for the same zone. This is harmless, since each RR stands
- alone (that is, it denies the set of owner names whose hashes, using
- the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
- RR) -- it is only the server that needs a complete set of NSEC3 RRs
- with the same salt in order to be able to answer every possible
- query.
-
- There is no prohibition with having NSEC3 RRs with different salts
- within the same zone. However, in order for authoritative servers to
- be able to consistently find covering NSEC3 RRs, the authoritative
- server MUST choose a single set of parameters (algorithm, salt, and
- iterations) to use when selecting NSEC3 RRs.
-
-C.2. Hash Collision
-
- Hash collisions occur when different messages have the same hash
- value. The expected number of domain names needed to give a 1 in 2
- chance of a single collision is about 2^(n/2) for a hash of length n
- bits (i.e., 2^80 for SHA-1). Though this probability is extremely
- low, the following paragraphs deal with avoiding collisions and
- assessing possible damage in the event of an attack using hash
- collisions.
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 49]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-C.2.1. Avoiding Hash Collisions During Generation
-
- During generation of NSEC3 RRs, hash values are supposedly unique.
- In the (academic) case of a collision occurring, an alternative salt
- MUST be chosen and all hash values MUST be regenerated.
-
-C.2.2. Second Preimage Requirement Analysis
-
- A cryptographic hash function has a second-preimage resistance
- property. The second-preimage resistance property means that it is
- computationally infeasible to find another message with the same hash
- value as a given message, i.e., given preimage X, to find a second
- preimage X' != X such that hash(X) = hash(X'). The work factor for
- finding a second preimage is of the order of 2^160 for SHA-1. To
- mount an attack using an existing NSEC3 RR, an adversary needs to
- find a second preimage.
-
- Assuming an adversary is capable of mounting such an extreme attack,
- the actual damage is that a response message can be generated that
- claims that a certain QNAME (i.e., the second pre-image) does exist,
- while in reality QNAME does not exist (a false positive), which will
- either cause a security-aware resolver to re-query for the non-
- existent name, or to fail the initial query. Note that the adversary
- can't mount this attack on an existing name, but only on a name that
- the adversary can't choose and that does not yet exist.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 50]
-\f
-RFC 5155 NSEC3 March 2008
-
-
-Authors' Addresses
-
- Ben Laurie
- Nominet
- 17 Perryn Road
- London W3 7LR
- England
-
- Phone: +44 20 8735 0686
- EMail: ben@links.org
-
-
- Geoffrey Sisson
- Nominet
- Minerva House
- Edmund Halley Road
- Oxford Science Park
- Oxford OX4 4DQ
- UNITED KINGDOM
-
- Phone: +44 1865 332211
- EMail: geoff-s@panix.com
-
-
- Roy Arends
- Nominet
- Minerva House
- Edmund Halley Road
- Oxford Science Park
- Oxford OX4 4DQ
- UNITED KINGDOM
-
- Phone: +44 1865 332211
- EMail: roy@nominet.org.uk
-
-
- David Blacka
- VeriSign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- EMail: davidb@verisign.com
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 51]
-\f
-RFC 5155 NSEC3 March 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.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Standards Track [Page 52]
-\f
projects / thirdparty / bind9.git / commitdiff
