diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt
new file mode 100644
index 0000000000..ba1b4147f4
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt
@@ -0,0 +1,616 @@
+
+
+
+DNSEXT Working Group M. Graff
+Internet-Draft P. Vixie
+Obsoletes: 2671 (if approved) Internet Systems Consortium
+Intended status: Standards Track July 28, 2009
+Expires: January 29, 2010
+
+
+ Extension Mechanisms for DNS (EDNS0)
+ draft-ietf-dnsext-rfc2671bis-edns0-02
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and 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 January 29, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+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
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 1]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+ allow requestors to advertise their capabilities to responders. This
+ document describes backward compatible mechanisms for allowing the
+ protocol to grow.
+
+ This document updates the EDNS0 specification based on 10 years of
+ operational experience.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
+ 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3
+ 4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 3
+ 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3
+ 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4
+ 6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 6.1. OPT Record Behavior . . . . . . . . . . . . . . . . . . . 4
+ 6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5
+ 6.3. Requestor's Payload Size . . . . . . . . . . . . . . . . . 6
+ 6.4. Responder's Payload Size . . . . . . . . . . . . . . . . . 6
+ 6.5. Payload Size Selection . . . . . . . . . . . . . . . . . . 7
+ 6.6. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 7
+ 6.7. Extended RCODE . . . . . . . . . . . . . . . . . . . . . . 7
+ 6.8. OPT Options Type Allocation Procedure . . . . . . . . . . 8
+ 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 8
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+ 11.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 2]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+1. Introduction
+
+ DNS [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.
+
+ 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. [RFC2671]
+ originally proposed extensions to the basic DNS protocol to overcome
+ these deficiencies. This memo refines that specification and
+ obsoletes [RFC2671].
+
+
+2. Requirements Language
+
+ 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].
+
+
+3. EDNS Support Requirement
+
+ EDNS support is manditory in a modern world. DNSSEC requires EDNS
+ support, and many other featres are made possible only by EDNS
+ support to request or advertise them.
+
+
+4. Affected Protocol Elements
+
+4.1. Message Header
+
+ The DNS Message Header's (see , section 4.1.1 [RFC1035]) 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 below contains subfields that carry a bit field
+ extension of the RCODE field and additional flag bits, respectively.
+
+
+
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 3]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+4.2. Label Types
+
+ The first two bits of a wire format domain label are used to denote
+ the type of the label. ,section 4.1.4 [RFC1035] allocates two of the
+ four possible types and reserves the other two. More label types
+ were proposed in [RFC2671] section 3.
+
+4.3. UDP Message Size
+
+ 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 below
+ contains a maximum payload size field.
+
+
+5. 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.
+
+ This document does not describe any specific Extended Label Type.
+
+ In practice, Extended Label Types are difficult to use due to support
+ in clients and intermediate gateways. Therefore, the registry of
+ Extended Label Types is requested to be closed. They cause
+ interoperability problems and at present no defined label types are
+ in use.
+
+
+6. OPT pseudo-RR
+
+6.1. OPT Record Behavior
+
+ One OPT pseudo-RR (RR type 41) MAY be added to the additional data
+ section of a request. If present in requests, compliant responders
+ which implement EDNS MUST include an OPT record in non-truncated
+ responses, and SHOULD attempt to include them in all responses. An
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 4]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+ 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.
+
+6.2. OPT Record Format
+
+ 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 basic extension elements which we
+ expect to be so popular that it would be a waste of wire space to
+ encode them as {attribute, value} pairs.
+
+ 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 |
+ | CLASS | u_int16_t | requestor's UDP payload size |
+ | TTL | u_int32_t | extended RCODE and flags |
+ | RDLEN | u_int16_t | describes RDATA |
+ | RDATA | octet stream | {attribute,value} pairs |
+ +------------+--------------+------------------------------+
+
+ OPT RR Format
+
+ 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 /
+ / /
+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+
+
+
+
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 5]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+ OPTION-CODE
+ Assigned by Expert Review.
+
+ OPTION-LENGTH
+ Size (in octets) of OPTION-DATA.
+
+ OPTION-DATA
+ Varies per OPTION-CODE.
+
+ 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.
+
+ Any OPTION-CODE values not understood by a responder or requestor
+ MUST be ignored. 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.
+
+6.3. Requestor's Payload Size
+
+ The requestor'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 requestor's network stack. Note
+ that path MTU, with or without fragmentation, may be smaller than
+ this. Values lower than 512 MUST be treated as equal to 512.
+
+ Note that a 512-octet UDP payload requires a 576-octet IP reassembly
+ buffer. Choosing 1280 for IPv4 over Ethernet 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.
+
+ The requestor's maximum payload size can change over time, and MUST
+ therefore not be cached for use beyond the transaction in which it is
+ advertised.
+
+6.4. Responder's Payload Size
+
+ 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.)
+
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 6]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+6.5. Payload Size Selection
+
+ 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.
+
+ A requestor MAY choose to implement a fallback to smaller advertised
+ sizes to work around firewall or other network limitations. A
+ requestor SHOULD choose to use a fallback mechanism which begins with
+ a large size, such as 4096. If that fails, a fallback around the
+ 1220 byte range SHOULD be tried, as it has a reasonable chance to fit
+ within a single Ethernet frame. Failing that, a requestor MAY choose
+ a 512 byte packet, which with large answers may cause a TCP retry.
+
+6.6. Middleware Boxes
+
+ Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes.
+
+ Middleware boxes which simply forward requests to a recursive
+ resolver MUST NOT modify the OPT record contents in either direction.
+
+6.7. Extended RCODE
+
+ 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 |
+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+ EXTENDED-RCODE
+ Forms upper 8 bits of extended 12-bit RCODE. Note that
+ EXTENDED-RCODE value "0" indicates that an unextended RCODE is
+ in use (values "0" through "15").
+
+ VERSION
+ Indicates the implementation level of whoever sets it. Full
+ conformance with this specification is indicated by version
+ ``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 MAY
+ ideally be a run time configuration option.
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 7]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+ 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 SHOULD 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 and
+ including RCODE=BADVERS.
+
+ DO
+ DNSSEC OK bit as defined by [RFC3225].
+
+ Z
+ Set to zero by senders and ignored by receivers, unless
+ modified in a subsequent specification.
+
+6.8. OPT Options Type Allocation Procedure
+
+ Allocations assigned by expert review. TBD
+
+
+7. Transport Considerations
+
+ The presence of an OPT pseudo-RR in a request should be taken as 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.
+
+ Lack of presence of an OPT record in a request MUST be taken as an
+ indication that the requestor does not implement any part of this
+ specification and that the responder MUST NOT use any protocol
+ extension described here in its response.
+
+ Responders who do not implement these protocol extensions MUST
+ respond with FORMERR messages without any OPT record.
+
+ If there is a problem with processing the OPT record itself, such as
+ an option value that is badly formatted or includes out of range
+ values, a FORMERR MAY be retured. If this occurs the response MUST
+ include an OPT record. This MAY be used to distinguish between
+ servers whcih do not implement EDNS and format errors within EDNS.
+
+ 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)
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 8]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+ DNS response, possibly setting TC if the response will not fit in the
+ unextended response message's 512-octet size.
+
+
+8. 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.
+
+ Announcing very large UDP buffer sizes may result in dropping by
+ firewalls. This could cause retransmissions with no hope of success.
+ Some devices reject fragmented UDP packets.
+
+ Announcing too small UDP buffer sizes may result in fallback to TCP.
+ This is especially important with DNSSEC, where answers are much
+ larger.
+
+
+9. IANA Considerations
+
+ The IANA has assigned RR type code 41 for OPT.
+
+ [RFC2671] specified a number of IANA sub-registries within "DOMAIN
+ NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option
+ Codes", "EDNS Version Numbers", and "Domain System Response Code."
+ IANA is advised to re-parent these subregistries to this document.
+
+ RFC 2671 created an extended label type registry. We request that
+ this registry be closed.
+
+ This document assigns extended label type 0bxx111111 as "Reserved for
+ future extended label types." We request that IANA record this
+ assignment.
+
+ This document assigns option code 65535 to "Reserved for future
+ expansion."
+
+ This document expands the RCODE space from 4 bits to 12 bits. This
+ will allow IANA to assign more than the 16 distinct RCODE values
+ allowed in RFC 1035 [RFC1035].
+
+ This document assigns EDNS Extended RCODE "16" to "BADVERS".
+
+ IESG approval should be required to create new entries in the EDNS
+ Extended Label Type or EDNS Version Number registries, while any
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 9]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+ published RFC (including Informational, Experimental, or BCP) should
+ be grounds for allocation of an EDNS Option Code.
+
+
+10. Acknowledgements
+
+ Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
+ Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
+ Narten were each instrumental in creating and refining this
+ specification.
+
+
+11. References
+
+11.1. Normative References
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+ RFC 2671, August 1999.
+
+ [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
+ RFC 3225, December 2001.
+
+11.2. Informative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+Authors' Addresses
+
+ Michael Graff
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, California 94063
+ US
+
+ Phone: +1 650.423.1304
+ Email: mgraff@isc.org
+
+
+
+
+
+
+
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 10]
+
+Internet-Draft EDNS0 Extensions July 2009
+
+
+ Paul Vixie
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, California 94063
+ US
+
+ Phone: +1 650.423.1301
+ Email: vixie@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graff & Vixie Expires January 29, 2010 [Page 11]
+
diff --git a/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt
new file mode 100644
index 0000000000..7e81e4c4bf
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt
@@ -0,0 +1,729 @@
+
+
+
+Network Working Group M. Andrews
+Internet-Draft ISC
+Intended status: BCP November 19, 2009
+Expires: May 23, 2010
+
+
+ Locally-served DNS Zones
+ draft-ietf-dnsop-default-local-zones-09
+
+Abstract
+
+ Experience with the Domain Name System (DNS) has shown that there are
+ a number of DNS zones all iterative resolvers and recursive
+ nameservers should automatically serve, unless configured otherwise.
+ 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.
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and 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 May 23, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+
+
+
+Andrews Expires May 23, 2010 [Page 1]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews Expires May 23, 2010 [Page 2]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+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. RFC1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.2. RFC3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6
+ 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6
+ 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6
+ 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7
+ 4.6. IPv6 Example Prefix . . . . . . . . . . . . . . . . . . . 7
+ 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ Appendix A. Change History [To Be Removed on Publication] . . . . 10
+ A.1. draft-ietf-dnsop-default-local-zones-09.txt . . . . . . . 10
+ A.2. draft-ietf-dnsop-default-local-zones-08.txt . . . . . . . 10
+ A.3. draft-ietf-dnsop-default-local-zones-07.txt . . . . . . . 10
+ A.4. draft-ietf-dnsop-default-local-zones-06.txt . . . . . . . 10
+ A.5. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 11
+ A.6. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 11
+ A.7. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 11
+ A.8. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 11
+ A.9. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11
+ A.10. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11
+ A.11. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11
+ A.12. draft-andrews-full-service-resolvers-02.txt . . . . . . . 12
+ Appendix B. Proposed Status [To Be Removed on Publication] . . . 12
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews Expires May 23, 2010 [Page 3]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+1. Introduction
+
+ Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035])
+ has shown that there are a number of DNS zones that all iterative
+ resolvers and recursive nameservers SHOULD automatically serve,
+ unless intentionally configured otherwise. These zones include, but
+ are not limited to, the IN-ADDR.ARPA zones for the address space
+ allocated by [RFC1918] and the IP6.ARPA zones for locally assigned
+ unique local IPv6 addresses defined in [RFC4193].
+
+ 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.
+
+ [RFC4193] recommends that queries for D.F.IP6.ARPA be handled
+ locally. This document extends the recommendation to cover the IN-
+ ADDR.ARPA zones for [RFC1918] 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 [RFC1918] addresses but do not follow the last
+ paragraph in Section 3 of [RFC1918].
+
+1.1. Reserved Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+
+Andrews Expires May 23, 2010 [Page 4]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+2. Effects on sites using RFC 1918 addresses.
+
+ For most sites using [RFC1918] 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 [RFC1918] 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
+ all at once 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." [RFC2606]. 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 May 23, 2010 [Page 5]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+ The SOA RR is needed to support negative caching [RFC2308] 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 [RFC2136] 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. RFC1918 Zones
+
+ The following zones correspond to the IPv4 address space reserved in
+ [RFC1918].
+
+ +----------------------+
+ | 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 May 23, 2010 [Page 6]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+4.2. RFC3330 Zones
+
+ The following zones correspond to those address ranges from [RFC3330]
+ 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 ([RFC3596], Section 2.5 IP6.ARPA Domain) for the
+ IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291],
+ 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 [RFC4193] already required special treatment of:
+
+
+
+
+
+Andrews Expires May 23, 2010 [Page 7]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+ +--------------+
+ | Zone |
+ +--------------+
+ | D.F.IP6.ARPA |
+ +--------------+
+
+4.5. IPv6 Link Local Addresses
+
+ IPv6 Link-Local Addresses as of [RFC4291], 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 |
+ +----------------+
+
+4.6. IPv6 Example Prefix
+
+ IPv6 example prefix [RFC3849].
+
+ +--------------------------+
+ | Zone |
+ +--------------------------+
+ | 8.B.D.0.1.0.0.2.IP6.ARPA |
+ +--------------------------+
+
+ Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as a example here.
+
+
+5. Zones that are Out-Of-Scope
+
+ IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and
+ 2.5.7), and IPv6 Non-Locally Assigned Local addresses ([RFC4193]) 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 the zones 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) [RFC4193],
+ there has been no decision made about whether the Regional Internet
+ Registries (RIRs) will provide delegations in this space or not. If
+
+
+
+Andrews Expires May 23, 2010 [Page 8]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+ 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
+ [RFC4159].
+
+ 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).
+
+
+6. IANA Considerations
+
+ This document requests that IANA establish a registry of zones which
+ require this default behaviour. The initial contents of this
+ registry are defined in Section 4. Implementors are encouraged to
+ periodically check this registry and adjust their implementations to
+ reflect changes therein.
+
+ This registry can be amended through "IETF Review" as per [RFC5226].
+
+ 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 [RFC1918]
+ 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 [RFC4035] by publishing and using DNSSEC trust
+ anchors. This will protect the clients from accidental import of
+
+
+
+Andrews Expires May 23, 2010 [Page 9]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+ 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
+
+ [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.
+
+ [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+ and E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, February 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2136] Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, April 1997.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2398, March 1998.
+
+ [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+ Names", BCP 32, RFC 2606, June 1999.
+
+ [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IPv6", RFC 3596, October 2003.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4159] Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
+ August 2005.
+
+ [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", RFC 4193, October 2005.
+
+
+
+Andrews Expires May 23, 2010 [Page 10]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ October 2008.
+
+9.2. Informative References
+
+ [AS112] "AS112 Project", .
+
+ [I-D.draft-ietf-dnsop-as112-ops]
+ Abley, J. and W. Maton, "AS112 Nameserver Operations",
+ draft-ietf-dnsop-as112-ops-01 (work in progress),
+ November 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-01 (work in
+ progress), November 2007.
+
+ [RFC3330] "Special-Use IPv4 Addresses", RFC 3330, September 2002.
+
+ [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
+ Reserved for Documentation", RFC 3849, July 2004.
+
+
+Appendix A. Change History [To Be Removed on Publication]
+
+A.1. draft-ietf-dnsop-default-local-zones-09.txt
+
+ refresh awaiting writeup
+
+A.2. draft-ietf-dnsop-default-local-zones-08.txt
+
+ editorial, reference updates
+
+A.3. draft-ietf-dnsop-default-local-zones-07.txt
+
+ none, expiry prevention
+
+A.4. draft-ietf-dnsop-default-local-zones-06.txt
+
+ add IPv6 example prefix
+
+
+
+
+
+
+Andrews Expires May 23, 2010 [Page 11]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+A.5. draft-ietf-dnsop-default-local-zones-05.txt
+
+ none, expiry prevention
+
+A.6. draft-ietf-dnsop-default-local-zones-04.txt
+
+ Centrally Assigned Local addresses -> Non-Locally Assigned Local
+ address
+
+A.7. draft-ietf-dnsop-default-local-zones-03.txt
+
+ expanded section 4 descriptions
+
+ Added references [RFC2136], [RFC3596],
+ [I-D.draft-ietf-dnsop-as112-ops] and
+ [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
+
+ Revised language.
+
+A.8. draft-ietf-dnsop-default-local-zones-02.txt
+
+ RNAME now "nobody.invalid."
+
+ Revised language.
+
+A.9. draft-ietf-dnsop-default-local-zones-01.txt
+
+ Revised impact description.
+
+ Updated to reflect change in IP6.INT status.
+
+A.10. 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.11. draft-andrews-full-service-resolvers-03.txt
+
+ Added "Proposed Status".
+
+
+
+
+
+
+
+Andrews Expires May 23, 2010 [Page 12]
+
+Internet-Draft Locally-served DNS Zones November 2009
+
+
+A.12. 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 May 23, 2010 [Page 13]
+
+
diff --git a/doc/rfc/rfc3755.txt b/doc/rfc/rfc3755.txt
new file mode 100644
index 0000000000..a9a7cf2692
--- /dev/null
+++ b/doc/rfc/rfc3755.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group S. Weiler
+Request for Comments: 3755 SPARTA, Inc.
+Updates: 3658, 2535 May 2004
+Category: Standards Track
+
+
+ Legacy Resolver Compatibility for Delegation Signer (DS)
+
+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 (2004). All Rights Reserved.
+
+Abstract
+
+ As the DNS Security (DNSSEC) specifications have evolved, the syntax
+ and semantics of the DNSSEC resource records (RRs) have changed.
+ Many deployed nameservers understand variants of these semantics.
+ Dangerous interactions can occur when a resolver that understands an
+ earlier version of these semantics queries an authoritative server
+ that understands the new delegation signer semantics, including at
+ least one failure scenario that will cause an unsecured zone to be
+ unresolvable. This document changes the type codes and mnemonics of
+ the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
+
+1. Introduction
+
+ The DNSSEC protocol has been through many iterations whose syntax and
+ semantics are not completely compatible. This has occurred as part
+ of the ordinary process of proposing a protocol, implementing it,
+ testing it in the increasingly complex and diverse environment of the
+ Internet, and refining the definitions of the initial Proposed
+ Standard. In the case of DNSSEC, the process has been complicated by
+ DNS's criticality and wide deployment and the need to add security
+ while minimizing daily operational complexity.
+
+ A weak area for previous DNS specifications has been lack of detail
+ in specifying resolver behavior, leaving implementors largely on
+ their own to determine many details of resolver function. This,
+ combined with the number of iterations the DNSSEC specifications have
+ been through, has resulted in fielded code with a wide variety of
+
+
+
+Weiler Standards Track [Page 1]
+
+RFC 3755 Legacy Resolver Compatibility for DS May 2004
+
+
+ behaviors. This variety makes it difficult to predict how a protocol
+ change will be handled by all deployed resolvers. The risk that a
+ change will cause unacceptable or even catastrophic failures makes it
+ difficult to design and deploy a protocol change. One strategy for
+ managing that risk is to structure protocol changes so that existing
+ resolvers can completely ignore input that might confuse them or
+ trigger undesirable failure modes.
+
+ This document addresses a specific problem caused by Delegation
+ Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR
+ that are incompatible with the semantics in [RFC2535]. Answers
+ provided by DS-aware servers can trigger an unacceptable failure mode
+ in some resolvers that implement RFC 2535, which provides a great
+ disincentive to sign zones with DS. The changes defined in this
+ document allow for the incremental deployment of DS.
+
+1.1. Terminology
+
+ In this document, the term "unsecure delegation" means any delegation
+ for which no DS record appears at the parent. An "unsecure referral"
+ is an answer from the parent containing an NS RRset and a proof that
+ no DS record exists for that name.
+
+ 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].
+
+1.2. The Problem
+
+ Delegation Signer (DS) introduces new semantics for the NXT RR that
+ are incompatible with the semantics in RFC 2535. In RFC 2535, NXT
+ records were only required to be returned as part of a non-existence
+ proof. With DS, an unsecure referral returns, in addition to the NS,
+ a proof of non-existence of a DS RR in the form of an NXT and
+ SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a
+ response with RCODE=0, AA=0, and both an NS and an NXT in the
+ authority section. Some widely deployed 2535-aware resolvers
+ interpret any answer with an NXT as a proof of non-existence of the
+ requested record. This results in unsecure delegations being
+ invisible to 2535-aware resolvers and violates the basic
+ architectural principle that DNSSEC must do no harm -- the signing of
+ zones must not prevent the resolution of unsecured delegations.
+
+2. Possible Solutions
+
+ This section presents several solutions that were considered.
+ Section 3 describes the one selected.
+
+
+
+
+Weiler Standards Track [Page 2]
+
+RFC 3755 Legacy Resolver Compatibility for DS May 2004
+
+
+2.1. Change SIG, KEY, and NXT type codes
+
+ To avoid the problem described above, legacy (RFC2535-aware)
+ resolvers need to be kept from seeing unsecure referrals that include
+ NXT records in the authority section. The simplest way to do that is
+ to change the type codes for SIG, KEY, and NXT.
+
+ The obvious drawback to this is that new resolvers will not be able
+ to validate zones signed with the old RRs. This problem already
+ exists, however, because of the changes made by DS, and resolvers
+ that understand the old RRs (and have compatibility issues with DS)
+ are far more prevalent than 2535-signed zones.
+
+2.2. Change a subset of type codes
+
+ The observed problem with unsecure referrals could be addressed by
+ changing only the NXT type code or another subset of the type codes
+ that includes NXT. This has the virtue of apparent simplicity, but
+ it risks introducing new problems or not going far enough. It's
+ quite possible that more incompatibilities exist between DS and
+ earlier semantics. Legacy resolvers may also be confused by seeing
+ records they recognize (SIG and KEY) while being unable to find NXTs.
+ Although it may seem unnecessary to fix that which is not obviously
+ broken, it's far cleaner to change all of the type codes at once.
+ This will leave legacy resolvers and tools completely blinded to
+ DNSSEC -- they will see only unknown RRs.
+
+2.3. Replace the DO bit
+
+ Another way to keep legacy resolvers from ever seeing DNSSEC records
+ with DS semantics is to have authoritative servers only send that
+ data to DS-aware resolvers. It's been proposed that assigning a new
+ EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and
+ having authoritative servers send DNSSEC data only in response to
+ queries with the DA bit set, would accomplish this. This bit would
+ presumably supplant the DO bit described in [RFC3225].
+
+ This solution is sufficient only if all 2535-aware resolvers zero out
+ EDNS0 flags that they don't understand. If one passed through the DA
+ bit unchanged, it would still see the new semantics, and it would
+ probably fail to see unsecure delegations. Since it's impractical to
+ know how every DNS implementation handles unknown EDNS0 flags, this
+ is not a universal solution. It could, though, be considered in
+ addition to changing the RR type codes.
+
+
+
+
+
+
+
+Weiler Standards Track [Page 3]
+
+RFC 3755 Legacy Resolver Compatibility for DS May 2004
+
+
+2.4. Increment the EDNS version
+
+ Another possible solution is to increment the EDNS version number as
+ defined in [RFC2671], on the assumption that all existing
+ implementations will reject higher versions than they support, and
+ retain the DO bit as the signal for DNSSEC awareness. This approach
+ has not been tested.
+
+2.5. Do nothing
+
+ There is a large deployed base of DNS resolvers that understand
+ DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and,
+ due to under specification in those documents, interpret any answer
+ with an NXT as a non-existence proof. So long as that is the case,
+ zone owners will have a strong incentive to not sign any zones that
+ contain unsecure delegations, lest those delegations be invisible to
+ such a large installed base. This will dramatically slow DNSSEC
+ adoption.
+
+ Unfortunately, without signed zones there's no clear incentive for
+ operators of resolvers to upgrade their software to support the new
+ version of DNSSEC, as defined in RFC 3658. Historical data suggests
+ that resolvers are rarely upgraded, and that old nameserver code
+ never dies.
+
+ Rather than wait years for resolvers to be upgraded through natural
+ processes before signing zones with unsecure delegations, addressing
+ this problem with a protocol change will immediately remove the
+ disincentive for signing zones and allow widespread deployment of
+ DNSSEC.
+
+3. Protocol changes
+
+ This document changes the type codes of SIG, KEY, and NXT. This
+ approach is the cleanest and safest of those discussed above, largely
+ because the behavior of resolvers that receive unknown type codes is
+ well understood. This approach has also received the most testing.
+
+ To avoid operational confusion, it's also necessary to change the
+ mnemonics for these RRs. DNSKEY will be the replacement for KEY,
+ with the mnemonic indicating that these keys are not for application
+ use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace
+ SIG, and NSEC (Next SECure) will replace NXT. These new types
+ completely replace the old types, except that SIG(0) [RFC2931] and
+ TKEY [RFC2930] will continue to use SIG and KEY.
+
+
+
+
+
+
+Weiler Standards Track [Page 4]
+
+RFC 3755 Legacy Resolver Compatibility for DS May 2004
+
+
+ The new types will have exactly the same syntax and semantics as
+ specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for
+ the following:
+
+ 1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC
+ RRs MUST NOT be compressed,
+
+ 2) Embedded domain names in RRSIG and NSEC RRs are not downcased for
+ purposes of DNSSEC canonical form and ordering nor for equality
+ comparison, and
+
+ 3) An RRSIG with a type-covered field of zero has undefined
+ semantics. The meaning of such a resource record may only be
+ defined by IETF Standards Action.
+
+ If a resolver receives the old types, it SHOULD treat them as unknown
+ RRs and SHOULD NOT assign any special meaning to them or give them
+ any special treatment. It MUST NOT use them for DNSSEC validations
+ or other DNS operational decision making. For example, a resolver
+ MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs.
+ If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive
+ special treatment. As an example, if a SIG is included in a signed
+ zone, there MUST be an RRSIG for it. Authoritative servers may wish
+ to give error messages when loading zones containing SIG or NXT
+ records (KEY records may be included for SIG(0) or TKEY).
+
+ As a clarification to previous documents, some positive responses,
+ particularly wildcard proofs and unsecure referrals, will contain
+ NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as negative
+ answers merely because they contain an NSEC.
+
+4. IANA Considerations
+
+4.1. DNS Resource Record Types
+
+ This document updates the IANA registry for DNS Resource Record Types
+ by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs,
+ respectively.
+
+ Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
+ TKEY [RFC2930] use only.
+
+ Type 30 (NXT) should be marked as Obsolete.
+
+
+
+
+
+
+
+
+Weiler Standards Track [Page 5]
+
+RFC 3755 Legacy Resolver Compatibility for DS May 2004
+
+
+4.2. DNS Security Algorithm Numbers
+
+ To allow zone signing (DNSSEC) and transaction security mechanisms
+ (SIG(0) and TKEY) to use different sets of algorithms, the existing
+ "DNS Security Algorithm Numbers" registry is modified to include the
+ applicability of each algorithm. Specifically, two new columns are
+ added to the registry, showing whether each algorithm may be used for
+ zone signing, transaction security mechanisms, or both. Only
+ algorithms usable for zone signing may be used in DNSKEY, RRSIG, and
+ DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in
+ SIG and KEY RRs.
+
+ All currently defined algorithms except for Indirect (algorithm 252)
+ remain usable for transaction security mechanisms. Only RSA/SHA-1
+ [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and
+ 254) may be used for zone signing. Note that the registry does not
+ contain the requirement level of each algorithm, only whether or not
+ an algorithm may be used for the given purposes. For example,
+ RSA/MD5, while allowed for transaction security mechanisms, is NOT
+ RECOMMENDED, per [RFC3110].
+
+ Additionally, the presentation format algorithm mnemonics from
+ [RFC2535] Section 7 are added to the registry. This document assigns
+ RSA/SHA-1 the mnemonic RSASHA1.
+
+ As before, assignment of new algorithms in this registry requires
+ IETF Standards Action. Additionally, modification of algorithm
+ mnemonics or applicability requires IETF Standards Action. Documents
+ defining a new algorithm must address the applicability of the
+ algorithm and should assign a presentation mnemonic to the algorithm.
+
+4.3. DNSKEY Flags
+
+ Like the KEY resource record, DNSKEY contains a 16-bit flags field.
+ This document creates a new registry for the DNSKEY flags field.
+
+ Initially, this registry only contains an assignment for bit 7 (the
+ ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
+ Standards Action.
+
+4.4. DNSKEY Protocol Octet
+
+ Like the KEY resource record, DNSKEY contains an eight bit protocol
+ field. The only defined value for this field is 3 (DNSSEC). No
+ other values are allowed, hence no IANA registry is needed for this
+ field.
+
+
+
+
+
+Weiler Standards Track [Page 6]
+
+RFC 3755 Legacy Resolver Compatibility for DS May 2004
+
+
+5. Security Considerations
+
+ The changes introduced here do not materially affect security. The
+ implications of trying to use both new and legacy types together are
+ not well understood, and attempts to do so would probably lead to
+ unintended and dangerous results.
+
+ Changing type codes will leave code paths in legacy resolvers that
+ are never exercised. Unexercised code paths are a frequent source of
+ security holes, largely because those code paths do not get frequent
+ scrutiny.
+
+ Doing nothing, as described in section 2.5, will slow DNSSEC
+ deployment. While this does not decrease security, it also fails to
+ increase it.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
+ (DNS)", RFC 2536, March 1999.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
+ RFC 2930, September 2000.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+ (SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+ Name System (DNS)", RFC 3110, May 2001.
+
+ [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
+ (RR)", RFC 3658, December 2003.
+
+
+
+
+
+
+
+
+
+
+
+Weiler Standards Track [Page 7]
+
+RFC 3755 Legacy Resolver Compatibility for DS May 2004
+
+
+6.2. Informative References
+
+ [RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
+ Security Extensions", RFC 2065, January 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+ 3225, December 2001.
+
+ [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
+ Resource Record (RR)", RFC 3445, December 2002.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+7. Acknowledgments
+
+ The changes introduced here and the analysis of alternatives had many
+ contributors. With apologies to anyone overlooked, those include:
+ Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis,
+ Bill Manning, Paul Vixie, and Suzanne Woolf.
+
+ Thanks to Jakob Schlyter and Mark Andrews for identifying the
+ incompatibility described in section 1.2.
+
+ In addition to the above, the author would like to thank Scott Rose,
+ Olafur Gudmundsson, and Sandra Murphy for their substantive comments.
+
+8. Author's Address
+
+ Samuel Weiler
+ SPARTA, Inc.
+ 7075 Samuel Morse Drive
+ Columbia, MD 21046
+ USA
+
+ EMail: weiler@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler Standards Track [Page 8]
+
+RFC 3755 Legacy Resolver Compatibility for DS May 2004
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Weiler Standards Track [Page 9]
+
diff --git a/doc/rfc/rfc4294.txt b/doc/rfc/rfc4294.txt
new file mode 100644
index 0000000000..8fea5c311b
--- /dev/null
+++ b/doc/rfc/rfc4294.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group J. Loughney, Ed.
+Request for Comments: 4294 Nokia
+Category: Informational April 2006
+
+
+ IPv6 Node Requirements
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document defines requirements for IPv6 nodes. It is expected
+ that IPv6 will be deployed in a wide range of devices and situations.
+ Specifying the requirements for IPv6 nodes allows IPv6 to function
+ well and interoperate in a large number of situations and
+ deployments.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Requirement Language .......................................3
+ 1.2. Scope of This Document .....................................3
+ 1.3. Description of IPv6 Nodes ..................................3
+ 2. Abbreviations Used in This Document .............................3
+ 3. Sub-IP Layer ....................................................4
+ 3.1. Transmission of IPv6 Packets over Ethernet Networks
+ - RFC 2464 .................................................4
+ 3.2. IP version 6 over PPP - RFC 2472 ...........................4
+ 3.3. IPv6 over ATM Networks - RFC 2492 ..........................4
+ 4. IP Layer ........................................................5
+ 4.1. Internet Protocol Version 6 - RFC 2460 .....................5
+ 4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5
+ 4.3. Path MTU Discovery and Packet Size .........................6
+ 4.4. ICMP for the Internet Protocol Version 6 (IPv6) -
+ RFC 2463 ...................................................7
+ 4.5. Addressing .................................................7
+ 4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8
+ 5. DNS and DHCP ....................................................8
+ 5.1. DNS ........................................................8
+
+
+
+
+Loughney Informational [Page 1]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+ 5.2. Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6) - RFC 3315 ........................................9
+ 6. IPv4 Support and Transition ....................................10
+ 6.1. Transition Mechanisms .....................................10
+ 7. Mobile IP ......................................................10
+ 8. Security .......................................................10
+ 8.1. Basic Architecture ........................................10
+ 8.2. Security Protocols ........................................11
+ 8.3. Transforms and Algorithms .................................11
+ 8.4. Key Management Methods ....................................12
+ 9. Router-Specific Functionality ..................................12
+ 9.1. General ...................................................12
+ 10. Network Management ............................................12
+ 10.1. Management Information Base Modules (MIBs) ...............12
+ 11. Security Considerations .......................................13
+ 12. References ....................................................13
+ 12.1. Normative References .....................................13
+ 12.2. Informative References ...................................16
+ 13. Authors and Acknowledgements ..................................18
+
+1. Introduction
+
+ The goal of this document is to define the common functionality
+ required from both IPv6 hosts and routers. Many IPv6 nodes will
+ implement optional or additional features, but this document
+ summarizes requirements from other published Standards Track
+ documents in one place.
+
+ This document tries to avoid discussion of protocol details, and
+ references RFCs for this purpose. This document is informational in
+ nature and does not update Standards Track RFCs.
+
+ Although the document points to different specifications, it should
+ be noted that in most cases, the granularity of requirements are
+ smaller than a single specification, as many specifications define
+ multiple, independent pieces, some of which may not be mandatory.
+
+ As it is not always possible for an implementer to know the exact
+ usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
+ that they should adhere to Jon Postel's Robustness Principle:
+
+ Be conservative in what you do, be liberal in what you accept from
+ others [RFC-793].
+
+
+
+
+
+
+
+
+Loughney Informational [Page 2]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+1.1. Requirement Language
+
+ 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 [RFC-2119].
+
+1.2. Scope of This Document
+
+ IPv6 covers many specifications. It is intended that IPv6 will be
+ deployed in many different situations and environments. Therefore,
+ it is important to develop the requirements for IPv6 nodes to ensure
+ interoperability.
+
+ This document assumes that all IPv6 nodes meet the minimum
+ requirements specified here.
+
+1.3. Description of IPv6 Nodes
+
+ From the Internet Protocol, Version 6 (IPv6) Specification
+ [RFC-2460], we have the following definitions:
+
+ Description of an IPv6 Node
+
+ - a device that implements IPv6.
+
+ Description of an IPv6 router
+
+ - a node that forwards IPv6 packets not explicitly addressed
+ to itself.
+
+ Description of an IPv6 Host
+
+ - any node that is not a router.
+
+2. Abbreviations Used in This Document
+
+ ATM Asynchronous Transfer Mode
+
+ AH Authentication Header
+
+ DAD Duplicate Address Detection
+
+ ESP Encapsulating Security Payload
+
+ ICMP Internet Control Message Protocol
+
+ IKE Internet Key Exchange
+
+
+
+
+Loughney Informational [Page 3]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+ MIB Management Information Base
+
+ MLD Multicast Listener Discovery
+
+ MTU Maximum Transfer Unit
+
+ NA Neighbor Advertisement
+
+ NBMA Non-Broadcast Multiple Access
+
+ ND Neighbor Discovery
+
+ NS Neighbor Solicitation
+
+ NUD Neighbor Unreachability Detection
+
+ PPP Point-to-Point Protocol
+
+ PVC Permanent Virtual Circuit
+
+ SVC Switched Virtual Circuit
+
+3. Sub-IP Layer
+
+ An IPv6 node must include support for one or more IPv6 link-layer
+ specifications. Which link-layer specifications are included will
+ depend upon what link-layers are supported by the hardware available
+ on the system. It is possible for a conformant IPv6 node to support
+ IPv6 on some of its interfaces and not on others.
+
+ As IPv6 is run over new layer 2 technologies, it is expected that new
+ specifications will be issued. This section highlights some major
+ layer 2 technologies and is not intended to be complete.
+
+3.1. Transmission of IPv6 Packets over Ethernet Networks - RFC 2464
+
+ Nodes supporting IPv6 over Ethernet interfaces MUST implement
+ Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
+
+3.2. IP version 6 over PPP - RFC 2472
+
+ Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP
+ [RFC-2472].
+
+3.3. IPv6 over ATM Networks - RFC 2492
+
+ Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
+ Networks [RFC-2492]. Additionally, RFC 2492 states:
+
+
+
+Loughney Informational [Page 4]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+ A minimally conforming IPv6/ATM driver SHALL support the PVC mode
+ of operation. An IPv6/ATM driver that supports the full SVC mode
+ SHALL also support PVC mode of operation.
+
+4. IP Layer
+
+4.1. Internet Protocol Version 6 - RFC 2460
+
+ The Internet Protocol Version 6 is specified in [RFC-2460]. This
+ specification MUST be supported.
+
+ Unrecognized options in Hop-by-Hop Options or Destination Options
+ extensions MUST be processed as described in RFC 2460.
+
+ The node MUST follow the packet transmission rules in RFC 2460.
+
+ Nodes MUST always be able to send, receive, and process fragment
+ headers. All conformant IPv6 implementations MUST be capable of
+ sending and receiving IPv6 packets; the forwarding functionality MAY
+ be supported.
+
+ RFC 2460 specifies extension headers and the processing for these
+ headers.
+
+ A full implementation of IPv6 includes implementation of the
+ following extension headers: Hop-by-Hop Options, Routing (Type 0),
+ Fragment, Destination Options, Authentication and Encapsulating
+ Security Payload [RFC-2460].
+
+ An IPv6 node MUST be able to process these headers. It should be
+ noted that there is some discussion about the use of Routing Headers
+ and possible security threats [IPv6-RH] that they cause.
+
+4.2. Neighbor Discovery for IPv6 - RFC 2461
+
+ Neighbor Discovery SHOULD be supported. [RFC-2461] states:
+
+ "Unless specified otherwise (in a document that covers operating
+ IP over a particular link type) this document applies to all link
+ types. However, because ND uses link-layer multicast for some of
+ its services, it is possible that on some link types (e.g., NBMA
+ links) alternative protocols or mechanisms to implement those
+ services will be specified (in the appropriate document covering
+ the operation of IP over a particular link type). The services
+ described in this document that are not directly dependent on
+ multicast, such as Redirects, Next-hop determination, Neighbor
+ Unreachability Detection, etc., are expected to be provided as
+
+
+
+
+Loughney Informational [Page 5]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+ specified in this document. The details of how one uses ND on
+ NBMA links is an area for further study."
+
+ Some detailed analysis of Neighbor Discovery follows:
+
+ Router Discovery is how hosts locate routers that reside on an
+ attached link. Router Discovery MUST be supported for
+ implementations.
+
+ Prefix Discovery is how hosts discover the set of address prefixes
+ that define which destinations are on-link for an attached link.
+ Prefix discovery MUST be supported for implementations. Neighbor
+ Unreachability Detection (NUD) MUST be supported for all paths
+ between hosts and neighboring nodes. It is not required for paths
+ between routers. However, when a node receives a unicast Neighbor
+ Solicitation (NS) message (that may be a NUD's NS), the node MUST
+ respond to it (i.e., send a unicast Neighbor Advertisement).
+
+ Duplicate Address Detection MUST be supported on all links supporting
+ link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take
+ place on all unicast addresses).
+
+ A host implementation MUST support sending Router Solicitations.
+
+ Receiving and processing Router Advertisements MUST be supported for
+ host implementations. The ability to understand specific Router
+ Advertisement options is dependent on supporting the specification
+ where the RA is specified.
+
+ Sending and Receiving Neighbor Solicitation (NS) and Neighbor
+ Advertisement (NA) MUST be supported. NS and NA messages are
+ required for Duplicate Address Detection (DAD).
+
+ Redirect functionality SHOULD be supported. If the node is a router,
+ Redirect functionality MUST be supported.
+
+4.3. Path MTU Discovery and Packet Size
+
+4.3.1. Path MTU Discovery - RFC 1981
+
+ Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
+ implementations MAY choose to not support it and avoid large packets.
+ The rules in RFC 2460 MUST be followed for packet fragmentation and
+ reassembly.
+
+4.3.2. IPv6 Jumbograms - RFC 2675
+
+ IPv6 Jumbograms [RFC-2675] MAY be supported.
+
+
+
+Loughney Informational [Page 6]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+4.4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463
+
+ ICMPv6 [RFC-2463] MUST be supported.
+
+4.5. Addressing
+
+4.5.1. IP Version 6 Addressing Architecture - RFC 3513
+
+ The IPv6 Addressing Architecture [RFC-3513] MUST be supported as
+ updated by [RFC-3879].
+
+4.5.2. IPv6 Stateless Address Autoconfiguration - RFC 2462
+
+ IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
+ This specification MUST be supported for nodes that are hosts.
+ Static address can be supported as well.
+
+ Nodes that are routers MUST be able to generate link local addresses
+ as described in RFC 2462 [RFC-2462].
+
+ From 2462:
+
+ The autoconfiguration process specified in this document applies
+ only to hosts and not routers. Since host autoconfiguration uses
+ information advertised by routers, routers will need to be
+ configured by some other means. However, it is expected that
+ routers will generate link-local addresses using the mechanism
+ described in this document. In addition, routers are expected to
+ successfully pass the Duplicate Address Detection procedure
+ described in this document on all addresses prior to assigning
+ them to an interface.
+
+ Duplicate Address Detection (DAD) MUST be supported.
+
+4.5.3. Privacy Extensions for Address Configuration in IPv6 - RFC 3041
+
+ Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
+ SHOULD be supported. It is recommended that this behavior be
+ configurable on a connection basis within each application when
+ available. It is noted that a number of applications do not work
+ with addresses generated with this method, while other applications
+ work quite well with them.
+
+4.5.4. Default Address Selection for IPv6 - RFC 3484
+
+ The rules specified in the Default Address Selection for IPv6
+ [RFC-3484] document MUST be implemented. It is expected that IPv6
+ nodes will need to deal with multiple addresses.
+
+
+
+Loughney Informational [Page 7]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+4.5.5. Stateful Address Autoconfiguration
+
+ Stateful Address Autoconfiguration MAY be supported. DHCPv6
+ [RFC-3315] is the standard stateful address configuration protocol;
+ see Section 5.3 for DHCPv6 support.
+
+ Nodes which do not support Stateful Address Autoconfiguration may be
+ unable to obtain any IPv6 addresses, aside from link-local addresses,
+ when it receives a router advertisement with the 'M' flag (Managed
+ address configuration) set and that contains no prefixes advertised
+ for Stateless Address Autoconfiguration (see Section 4.5.2).
+ Additionally, such nodes will be unable to obtain other configuration
+ information, such as the addresses of DNS servers when it is
+ connected to a link over which the node receives a router
+ advertisement in which the 'O' flag ("Other stateful configuration")
+ is set.
+
+4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710
+
+ Nodes that need to join multicast groups SHOULD implement MLDv2
+ [RFC-3810]. However, if the node has applications that only need
+ support for Any-Source Multicast [RFC-3569], the node MAY implement
+ MLDv1 [RFC-2710] instead. If the node has applications that need
+ support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node
+ MUST support MLDv2 [RFC-3810].
+
+ When MLD is used, the rules in the "Source Address Selection for the
+ Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
+ followed.
+
+5. DNS and DHCP
+
+5.1. DNS
+
+ DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363],
+ and [RFC-3596]. Not all nodes will need to resolve names; those that
+ will never need to resolve DNS names do not need to implement
+ resolver functionality. However, the ability to resolve names is a
+ basic infrastructure capability that applications rely on and
+ generally needs to be supported. All nodes that need to resolve
+ names SHOULD implement stub-resolver [RFC-1034] functionality, as in
+ RFC 1034, Section 5.3.1, with support for:
+
+ - AAAA type Resource Records [RFC-3596];
+
+ - reverse addressing in ip6.arpa using PTR records [RFC-3152];
+
+
+
+
+
+Loughney Informational [Page 8]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+ - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
+ octets.
+
+ Those nodes are RECOMMENDED to support DNS security extensions
+ [RFC-4033], [RFC-4034], and [RFC-4035].
+
+ Those nodes are NOT RECOMMENDED to support the experimental A6 and
+ DNAME Resource Records [RFC-3363].
+
+5.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315
+
+5.2.1. Managed Address Configuration
+
+ The method by which IPv6 nodes that use DHCP for address assignment
+ can obtain IPv6 addresses and other configuration information upon
+ receipt of a Router Advertisement with the 'M' flag set is described
+ in Section 5.5.3 of RFC 2462.
+
+ In addition, in the absence of a router, those IPv6 nodes that use
+ DHCP for address assignment MUST initiate DHCP to obtain IPv6
+ addresses and other configuration information, as described in
+ Section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP for
+ address assignment can ignore the 'M' flag in Router Advertisements.
+
+5.2.2. Other Configuration Information
+
+ The method by which IPv6 nodes that use DHCP to obtain other
+ configuration information can obtain other configuration information
+ upon receipt of a Router Advertisement with the 'O' flag set is
+ described in Section 5.5.3 of RFC 2462.
+
+ Those IPv6 nodes that use DHCP to obtain other configuration
+ information initiate DHCP for other configuration information upon
+ receipt of a Router Advertisement with the 'O' flag set, as described
+ in Section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP
+ for other configuration information can ignore the 'O' flag in Router
+ Advertisements.
+
+ An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to
+ obtain other configuration information.
+
+5.3.3. Use of Router Advertisements in Managed Environments
+
+ Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+ are expected to determine their default router information and on-
+ link prefix information from received Router Advertisements.
+
+
+
+
+
+Loughney Informational [Page 9]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+6. IPv4 Support and Transition
+
+ IPv6 nodes MAY support IPv4.
+
+6.1. Transition Mechanisms
+
+6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893
+
+ If an IPv6 node implements dual stack and tunneling, then [RFC-4213]
+ MUST be supported.
+
+7. Mobile IP
+
+ The Mobile IPv6 [RFC-3775] specification defines requirements for the
+ following types of nodes:
+
+ - mobile nodes
+
+ - correspondent nodes with support for route optimization
+
+ - home agents
+
+ - all IPv6 routers
+
+ Hosts MAY support mobile node functionality described in Section 8.5
+ of [RFC-3775], including support of generic packet tunneling [RFC-
+ 2473] and secure home agent communications [RFC-3776].
+
+ Hosts SHOULD support route optimization requirements for
+ correspondent nodes described in Section 8.2 of [RFC-3775].
+
+ Routers SHOULD support the generic mobility-related requirements for
+ all IPv6 routers described in Section 8.3 of [RFC-3775]. Routers MAY
+ support the home agent functionality described in Section 8.4 of
+ [RFC-3775], including support of [RFC-2473] and [RFC-3776].
+
+8. Security
+
+ This section describes the specification of IPsec for the IPv6 node.
+
+8.1. Basic Architecture
+
+ Security Architecture for the Internet Protocol [RFC-4301] MUST be
+ supported.
+
+
+
+
+
+
+
+Loughney Informational [Page 10]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+8.2. Security Protocols
+
+ ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported.
+
+8.3. Transforms and Algorithms
+
+ Current IPsec RFCs specify the support of transforms and algorithms
+ for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and
+ HMAC-MD5-96. However, "Cryptographic Algorithm Implementation
+ Requirements For ESP And AH" [RFC-4305] contains the current set of
+ mandatory to implement algorithms for ESP and AH. It also specifies
+ algorithms that should be implemented because they are likely to be
+ promoted to mandatory at some future time. IPv6 nodes SHOULD conform
+ to the requirements in [RFC-4305], as well as the requirements
+ specified below.
+
+ Since ESP encryption and authentication are both optional, support
+ for the NULL encryption algorithm [RFC-2410] and the NULL
+ authentication algorithm [RFC-4303] MUST be provided to maintain
+ consistency with the way these services are negotiated. However,
+ while authentication and encryption can each be NULL, they MUST NOT
+ both be NULL. The NULL encryption algorithm is also useful for
+ debugging.
+
+ The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported
+ within ESP. Security issues related to the use of DES are discussed
+ in [DESDIFF], [DESINT], and [DESCRACK]. DES-CBC is still listed as
+ required by the existing IPsec RFCs, but updates to these RFCs will
+ be published in the near future. DES provides 56 bits of protection,
+ which is no longer considered sufficient.
+
+ The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP
+ MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC-2403]
+ within AH and ESP MAY also be supported.
+
+ The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the
+ same security issues as DES-CBC, and the 3DES-CBC algorithm within
+ ESP MUST be supported to ensure interoperability.
+
+ The AES-128-CBC algorithm [RFC-3602] MUST also be supported within
+ ESP. AES-128 is expected to be a widely available, secure, and
+ efficient algorithm. While AES-128-CBC is not required by the
+ current IPsec RFCs, it is expected to become required in the future.
+
+
+
+
+
+
+
+
+Loughney Informational [Page 11]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+8.4. Key Management Methods
+
+ An implementation MUST support the manual configuration of the
+ security key and SPI. The SPI configuration is needed in order to
+ delineate between multiple keys.
+
+ Key management SHOULD be supported. Examples of key management
+ systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include
+ key management functions.
+
+ Where key refresh, anti-replay features of AH and ESP, or on-demand
+ creation of Security Associations (SAs) is required, automated keying
+ MUST be supported.
+
+ Key management methods for multicast traffic are also being worked on
+ by the MSEC WG.
+
+9. Router-Specific Functionality
+
+ This section defines general host considerations for IPv6 nodes that
+ act as routers. Currently, this section does not discuss routing-
+ specific requirements.
+
+9.1. General
+
+9.1.1. IPv6 Router Alert Option - RFC 2711
+
+ The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
+ Hop Header that is used in conjunction with some protocols (e.g.,
+ RSVP [RFC-2205] or MLD [RFC-2710]). The Router Alert option will
+ need to be implemented whenever protocols that mandate its usage are
+ implemented. See Section 4.6.
+
+9.1.2. Neighbor Discovery for IPv6 - RFC 2461
+
+ Sending Router Advertisements and processing Router Solicitation MUST
+ be supported.
+
+10. Network Management
+
+ Network Management MAY be supported by IPv6 nodes. However, for IPv6
+ nodes that are embedded devices, network management may be the only
+ possible way of controlling these nodes.
+
+10.1. Management Information Base Modules (MIBs)
+
+ The following two MIBs SHOULD be supported by nodes that support an
+ SNMP agent.
+
+
+
+Loughney Informational [Page 12]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+10.1.1. IP Forwarding Table MIB
+
+ IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that
+ support an SNMP agent.
+
+10.1.2. Management Information Base for the Internet Protocol (IP)
+
+ IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP
+ agent.
+
+11. Security Considerations
+
+ This document does not affect the security of the Internet, but
+ implementations of IPv6 are expected to support a minimum set of
+ security features to ensure security on the Internet. "IP Security
+ Document Roadmap" [RFC-2411] is important for everyone to read.
+
+ The security considerations in RFC 2460 state the following:
+
+ The security features of IPv6 are described in the Security
+ Architecture for the Internet Protocol [RFC-2401].
+
+ RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for
+ the security features of IPv6.
+
+12. References
+
+12.1. Normative References
+
+ [RFC-1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
+ Discovery for IP version 6", RFC 1981, August 1996.
+
+ [RFC-2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+ Keyed-Hashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC-2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96
+ within ESP and AH", RFC 2403, November 1998.
+
+ [RFC-2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
+ within ESP and AH", RFC 2404, November 1998.
+
+
+
+
+Loughney Informational [Page 13]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+ [RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
+ Algorithm With Explicit IV", RFC 2405, November 1998.
+
+ [RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
+ and Its Use With IPsec", RFC 2410, November 1998.
+
+ [RFC-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
+ Document Roadmap", RFC 2411, November 1998.
+
+ [RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
+ Algorithms", RFC 2451, November 1998.
+
+ [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version
+ 6 (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+ Discovery for IP Version 6 (IPv6)", RFC 2461, December
+ 1998.
+
+ [RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [RFC-2463] Conta, A. and S. Deering, "Internet Control Message
+ Protocol (ICMPv6) for the Internet Protocol Version 6
+ (IPv6) Specification", RFC 2463, December 1998.
+
+ [RFC-2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
+ 2472, December 1998.
+
+ [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
+ IPv6 Specification", RFC 2473, December 1998.
+
+ [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC-2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
+ Listener Discovery (MLD) for IPv6", RFC 2710, October
+ 1999.
+
+ [RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
+ Option", RFC 2711, October 1999.
+
+ [RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for
+ Stateless Address Autoconfiguration in IPv6", RFC
+ 3041, January 2001.
+
+ [RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+ August 2001.
+
+
+
+Loughney Informational [Page 14]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+ [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
+ C., and M. Carney, "Dynamic Host Configuration
+ Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+ [RFC-3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and
+ T. Hain, "Representing Internet Protocol version 6
+ (IPv6) Addresses in the Domain Name System (DNS)", RFC
+ 3363, August 2002.
+
+ [RFC-3484] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
+ "Coexistence between Version 1, Version 2, and Version
+ 3 of the Internet-standard Network Management
+ Framework", BCP 74, RFC 3584, August 2003.
+
+ [RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version
+ 6 (IPv6) Addressing Architecture", RFC 3513, April
+ 2003.
+
+ [RFC-3590] Haberman, B., "Source Address Selection for the
+ Multicast Listener Discovery (MLD) Protocol", RFC
+ 3590, September 2003.
+
+ [RFC-3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IP Version 6", RFC 3596,
+ October 2003.
+
+ [RFC-3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
+ Cipher Algorithm and Its Use with IPsec", RFC 3602,
+ September 2003.
+
+ [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
+ Support in IPv6", RFC 3775, June 2004.
+
+ [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using
+ IPsec to Protect Mobile IPv6 Signaling Between Mobile
+ Nodes and Home Agents", RFC 3776, June 2004.
+
+ [RFC-3810] Vida, R. and L. Costa, "Multicast Listener Discovery
+ Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+ [RFC-3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
+ Addresses", RFC 3879, September 2004.
+
+ [RFC-4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292,
+ April 2006.
+
+ [RFC-4293] Routhier, S., Ed., "Management Information Base for
+ the Internet Protocol (IP)", RFC 4293, April 2006.
+
+
+
+Loughney Informational [Page 15]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+ [RFC-4301] Kent, S. and R. Atkinson, "Security Architecture for
+ the Internet Protocol", RFC 4301, December 2005.
+
+ [RFC-4302] Kent, S., "IP Authentication Header", RFC 4302,
+ December 2005.
+
+ [RFC-4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
+ RFC 4303, December 2005.
+
+ [RFC-4305] Eastlake 3rd, D., "Cryptographic Algorithm
+ Implementation Requirements for Encapsulating Security
+ Payload (ESP) and Authentication Header (AH)", RFC
+ 4305, December 2005.
+
+12.2. Informative References
+
+ [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of
+ DES-like cryptosystems", Journal of Cryptology Vol 4,
+ Jan 1991.
+
+ [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA
+ 2000.
+
+ [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without
+ Strong Integrity", Proceedings of the 32nd IETF,
+ Danvers, MA, April 1995.
+
+ [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home
+ Address Options", Work in Progress.
+
+ [RFC-793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [RFC-1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
+ Jamin, "Resource ReSerVation Protocol (RSVP) --
+ Version 1 Functional Specification", RFC 2205,
+ September 1997.
+
+ [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over
+ Ethernet Networks", RFC 2464, December 1998.
+
+ [RFC-2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over
+ ATM Networks", RFC 2492, January 1999.
+
+
+
+
+
+Loughney Informational [Page 16]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+ [RFC-2675] Borman, D., Deering, S., and R. Hinden, "IPv6
+ Jumbograms", RFC 2675, August 1999.
+
+ [RFC-4213] Nordmark, E. and R. Gilligan, "Basic Transition
+ Mechanisms for IPv6 Hosts and Routers", RFC 4213,
+ October 2005.
+
+ [RFC-3569] Bhattacharyya, S., "An Overview of Source-Specific
+ Multicast (SSM)", RFC 3569, July 2003.
+
+ [RFC-3736] Droms, R., "Stateless Dynamic Host Configuration
+ Protocol (DHCP) Service for IPv6", RFC 3736, April
+ 2004.
+
+ [RFC-4001] Daniele, M., Haberman, B., Routhier, S., and J.
+ Schoenwaelder, "Textual Conventions for Internet
+ Network Addresses", RFC 4001, February 2005.
+
+ [RFC-4033] Arends, R., Austein, R., Larson, M., Massey, D., and
+ S. Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC-4034] Arends, R., Austein, R., Larson, M., Massey, D., and
+ S. Rose, "Resource Records for the DNS Security
+ Extensions", RFC 4034, 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-4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+ Protocol", RFC 4306, December 2005.
+
+ [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for
+ IP", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney Informational [Page 17]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+13. Authors and Acknowledgements
+
+ This document was written by the IPv6 Node Requirements design team:
+
+ Jari Arkko
+ [jari.arkko@ericsson.com]
+
+ Marc Blanchet
+ [marc.blanchet@viagenie.qc.ca]
+
+ Samita Chakrabarti
+ [samita.chakrabarti@eng.sun.com]
+
+ Alain Durand
+ [alain.durand@sun.com]
+
+ Gerard Gastaud
+ [gerard.gastaud@alcatel.fr]
+
+ Jun-ichiro itojun Hagino
+ [itojun@iijlab.net]
+
+ Atsushi Inoue
+ [inoue@isl.rdc.toshiba.co.jp]
+
+ Masahiro Ishiyama
+ [masahiro@isl.rdc.toshiba.co.jp]
+
+ John Loughney
+ [john.loughney@nokia.com]
+
+ Rajiv Raghunarayan
+ [raraghun@cisco.com]
+
+ Shoichi Sakane
+ [shouichi.sakane@jp.yokogawa.com]
+
+ Dave Thaler
+ [dthaler@windows.microsoft.com]
+
+ Juha Wiljakka
+ [juha.wiljakka@Nokia.com]
+
+ The authors would like to thank Ran Atkinson, Jim Bound, Brian
+ Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas
+ Narten, Juha Ollila, and Pekka Savola for their comments.
+
+
+
+
+
+Loughney Informational [Page 18]
+
+RFC 4294 IPv6 Node Requirements April 2006
+
+
+Editor's Contact Information
+
+ Comments or questions regarding this document should be sent to the
+ IPv6 Working Group mailing list (ipv6@ietf.org) or to:
+
+ John Loughney
+ Nokia Research Center
+ Itamerenkatu 11-13
+ 00180 Helsinki
+ Finland
+
+ Phone: +358 50 483 6242
+ EMail: John.Loughney@Nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney Informational [Page 19]
+
+RFC 4294 IPv6 Node Requirements 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Loughney Informational [Page 20]
+
diff --git a/doc/rfc/rfc4339.txt b/doc/rfc/rfc4339.txt
new file mode 100644
index 0000000000..a6f29d9f43
--- /dev/null
+++ b/doc/rfc/rfc4339.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group J. Jeong, Ed.
+Request for Comments: 4339 ETRI/University of Minnesota
+Category: Informational February 2006
+
+
+ IPv6 Host Configuration of DNS Server Information Approaches
+
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+IESG Note
+
+ This document describes three different approaches for the
+ configuration of DNS name resolution server information in IPv6
+ hosts.
+
+ There is not an IETF consensus on which approach is preferred. The
+ analysis in this document was developed by the proponents for each
+ approach and does not represent an IETF consensus.
+
+ The 'RA option' and 'Well-known anycast' approaches described in this
+ document are not standardized. Consequently the analysis for these
+ approaches might not be completely applicable to any specific
+ proposal that might be proposed in the future.
+
+Abstract
+
+ This document describes three approaches for IPv6 recursive DNS
+ server address configuration. It details the operational attributes
+ of three solutions: RA option, DHCPv6 option, and well-known anycast
+ addresses for recursive DNS servers. Additionally, it suggests the
+ deployment scenarios in four kinds of networks (ISP, enterprise,
+ 3GPP, and unmanaged networks) considering multi-solution resolution.
+
+
+
+
+
+
+
+
+
+
+Jeong Informational [Page 1]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. IPv6 DNS Configuration Approaches ...............................3
+ 3.1. RA Option ..................................................3
+ 3.1.1. Advantages ..........................................4
+ 3.1.2. Disadvantages .......................................5
+ 3.1.3. Observations ........................................5
+ 3.2. DHCPv6 Option ..............................................6
+ 3.2.1. Advantages ..........................................7
+ 3.2.2. Disadvantages .......................................8
+ 3.2.3. Observations ........................................9
+ 3.3. Well-known Anycast Addresses ...............................9
+ 3.3.1. Advantages .........................................10
+ 3.3.2. Disadvantages ......................................10
+ 3.3.3. Observations .......................................10
+ 4. Interworking among IPv6 DNS Configuration Approaches ...........11
+ 5. Deployment Scenarios ...........................................12
+ 5.1. ISP Network ...............................................12
+ 5.1.1. RA Option Approach .................................13
+ 5.1.2. DHCPv6 Option Approach .............................13
+ 5.1.3. Well-known Anycast Addresses Approach ..............14
+ 5.2. Enterprise Network ........................................14
+ 5.3. 3GPP Network ..............................................15
+ 5.3.1. Currently Available Mechanisms and
+ Recommendations ....................................15
+ 5.3.2. RA Extension .......................................16
+ 5.3.3. Stateless DHCPv6 ...................................16
+ 5.3.4. Well-known Addresses ...............................17
+ 5.3.5. Recommendations ....................................18
+ 5.4. Unmanaged Network .........................................18
+ 5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18
+ 5.4.2. Case B: A Dual-stack Gateway Connected to a
+ Dual-stack ISP .....................................19
+ 5.4.3. Case C: A Dual-stack Gateway Connected to
+ an IPv4-only ISP ...................................19
+ 5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19
+ 6. Security Considerations ........................................19
+ 6.1. RA Option .................................................20
+ 6.2. DHCPv6 Option .............................................21
+ 6.3. Well-known Anycast Addresses ..............................21
+ 7. Contributors ...................................................21
+ 8. Acknowledgements ...............................................23
+ 9. References .....................................................23
+ 9.1. Normative References ......................................23
+ 9.2. Informative References ....................................23
+
+
+
+
+Jeong Informational [Page 2]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+1. Introduction
+
+ Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
+ Autoconfiguration provide ways to configure either fixed or mobile
+ nodes with one or more IPv6 addresses, default routes, and some other
+ parameters [1][2]. To support the access to additional services in
+ the Internet that are identified by a DNS name, such as a web server,
+ the configuration of at least one recursive DNS server is also needed
+ for DNS name resolution.
+
+ This document describes three approaches of recursive DNS server
+ address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6
+ option [3]-[5], and (c) well-known anycast addresses for recursive
+ DNS servers [7]. Also, it suggests the applicable scenarios for four
+ kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP
+ network, and (d) unmanaged network.
+
+ This document is just an analysis of each possible approach, and it
+ does not recommend a particular approach or combination of
+ approaches. Some approaches may even not be adopted at all as a
+ result of further discussion.
+
+ Therefore, the objective of this document is to help the audience
+ select the approaches suitable for IPv6 host configuration of
+ recursive DNS servers.
+
+2. Terminology
+
+ This document uses the terminology described in [1]-[7]. In
+ addition, a new term is defined below:
+
+ o Recursive DNS Server (RDNSS): Server which provides a recursive
+ DNS resolution service.
+
+3. IPv6 DNS Configuration Approaches
+
+ In this section, the operational attributes of the three solutions
+ are described in detail.
+
+3.1. RA Option
+
+ The RA approach defines a new ND option, called the RDNSS option,
+ that contains a recursive DNS server address [6]. Existing ND
+ transport mechanisms (i.e., advertisements and solicitations) are
+ used. This works in the same way that nodes learn about routers and
+ prefixes. An IPv6 host can configure the IPv6 addresses of one or
+ more RDNSSes via RA message periodically sent by a router or
+ solicited by a Router Solicitation (RS).
+
+
+
+Jeong Informational [Page 3]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ This approach needs RDNSS information to be configured in the routers
+ doing the advertisements. The configuration of RDNSS addresses can
+ be performed manually by an operator or in other ways, such as
+ automatic configuration through a DHCPv6 client running on the
+ router. An RA message with one RDNSS option can include as many
+ RDNSS addresses as needed [6].
+
+ Through the ND protocol and RDNSS option, along with a prefix
+ information option, an IPv6 host can perform network configuration of
+ its IPv6 address and RDNSS simultaneously [1][2]. The RA option for
+ RDNSS can be used on any network that supports the use of ND.
+
+ The RA approach is useful in some mobile environments where the
+ addresses of the RDNSSes are changing because the RA option includes
+ a lifetime field that allows client to use RDNSSes nearer to the
+ client. This can be configured to a value that will require the
+ client to time out the entry and switch over to another RDNSS address
+ [6]. However, from the viewpoint of implementation, the lifetime
+ field would seem to make matters a bit more complex. Instead of just
+ writing to a DNS configuration file, such as resolv.conf for the list
+ of RDNSS addresses, we have to have a daemon around (or a program
+ that is called at the defined intervals) that keeps monitoring the
+ lifetime of RDNSSes all the time.
+
+ The preference value of RDNSS, included in the RDNSS option, allows
+ IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this
+ can be used for the load balancing of RDNSSes.
+
+3.1.1. Advantages
+
+ The RA option for RDNSS has a number of advantages. These include:
+
+ 1. The RA option is an extension of existing ND/Autoconfig
+ mechanisms [1][2] and does not require a change in the base ND
+ protocol.
+
+ 2. This approach, like ND, works well on a variety of link types,
+ including point-to-point links, point-to-multipoint, and
+ multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1]
+ states, however, that there may be some link types on which ND is
+ not feasible; on such links, some other mechanisms will be needed
+ for DNS configuration.
+
+ 3. All the information a host needs to run the basic Internet
+ applications (such as the email, web, ftp, etc.) can be obtained
+ with the addition of this option to ND and address
+ autoconfiguration. The use of a single mechanism is more
+ reliable and easier to provide than when the RDNSS information is
+
+
+
+Jeong Informational [Page 4]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ learned via another protocol mechanism. Debugging problems when
+ multiple protocol mechanisms are being used is harder and much
+ more complex.
+
+ 4. This mechanism works over a broad range of scenarios and
+ leverages IPv6 ND. This works well on links that are high
+ performance (e.g., Ethernet LANs) and low performance (e.g.,
+ cellular networks). In the latter case, by combining the RDNSS
+ information with the other information in the RA, the host can
+ learn all the information needed to use most Internet
+ applications, such as the web, in a single packet. This not only
+ saves bandwidth, but also minimizes the delay needed to learn the
+ RDNSS information.
+
+ 5. The RA approach could be used as a model for similar types of
+ configuration information. New RA options for other server
+ addresses, such as NTP server address, that are common to all
+ clients on a subnet would be easy to define.
+
+3.1.2. Disadvantages
+
+ 1. ND is mostly implemented in the kernel of the operating system.
+ Therefore, if ND supports the configuration of some additional
+ services, such as DNS servers, ND should be extended in the
+ kernel and complemented by a user-land process. DHCPv6, however,
+ has more flexibility for the extension of service discovery
+ because it is an application layer protocol.
+
+ 2. The current ND framework should be modified to facilitate the
+ synchronization between another ND cache for RDNSSes in the
+ kernel space and the DNS configuration file in the user space.
+ Because it is unacceptable to write and rewrite to the DNS
+ configuration file (e.g., resolv.conf) from the kernel, another
+ approach is needed. One simple approach to solve this is to have
+ a daemon listening to what the kernel conveys, and to have the
+ daemon do these steps, but such a daemon is not needed with the
+ current ND framework.
+
+ 3. It is necessary to configure RDNSS addresses at least at one
+ router on every link where this information needs to be
+ configured via the RA option.
+
+3.1.3. Observations
+
+ The proposed RDNSS RA option, along with the IPv6 ND and
+ Autoconfiguration, allows a host to obtain all of the information it
+ needs to access basic Internet services like the web, email, ftp,
+ etc. This is preferable in the environments where hosts use RAs to
+
+
+
+Jeong Informational [Page 5]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ autoconfigure their addresses and all the hosts on the subnet share
+ the same router and server addresses. If the configuration
+ information can be obtained from a single mechanism, it is preferable
+ because it does not add additional delay, and because it uses a
+ minimum of bandwidth. Environments like this include homes, public
+ cellular networks, and enterprise environments where no per host
+ configuration is needed.
+
+ DHCPv6 is preferable where it is being used for address configuration
+ and if there is a need for host specific configuration [3]-[5].
+ Environments like this are most likely to be the enterprise
+ environments where the local administration chooses to have per host
+ configuration control.
+
+3.2. DHCPv6 Option
+
+ DHCPv6 [3] includes the "DNS Recursive Name Server" option, through
+ which a host can obtain a list of IP addresses of recursive DNS
+ servers [5]. The DNS Recursive Name Server option carries a list of
+ IPv6 addresses of RDNSSes to which the host may send DNS queries.
+ The DNS servers are listed in the order of preference for use by the
+ DNS resolver on the host.
+
+ The DNS Recursive Name Server option can be carried in any DHCPv6
+ Reply message, in response to either a Request or an Information
+ request message. Thus, the DNS Recursive Name Server option can be
+ used either when DHCPv6 is used for address assignment, or when
+ DHCPv6 is used only for other configuration information as stateless
+ DHCPv6 [4].
+
+ Stateless DHCPv6 can be deployed either by using DHCPv6 servers
+ running on general-purpose computers, or on router hardware. Several
+ router vendors currently implement stateless DHCPv6 servers.
+ Deploying stateless DHCPv6 in routers has the advantage that no
+ special hardware is required, and it should work well for networks
+ where DHCPv6 is needed for very straightforward configuration of
+ network devices.
+
+ However, routers can also act as DHCPv6 relay agents. In this case,
+ the DHCPv6 server need not be on the router; it can be on a general
+ purpose computer. This has the potential to give the operator of the
+ DHCPv6 server more flexibility in how the DHCPv6 server responds to
+ individual clients that can easily be given different configuration
+ information based on their identity, or for any other reason.
+ Nothing precludes adding this flexibility to a router, but generally,
+ in current practice, DHCP servers running on general-purpose hosts
+ tend to have more configuration options than those that are embedded
+ in routers.
+
+
+
+Jeong Informational [Page 6]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
+ clients that use a stateful configuration assignment. To do this,
+ the DHCPv6 server sends a Reconfigure message to the client. The
+ client validates the Reconfigure message, and then contacts the
+ DHCPv6 server to obtain updated configuration information. By using
+ this mechanism, it is currently possible to propagate new
+ configuration information to DHCPv6 clients as this information
+ changes.
+
+ The DHC Working Group has standardized an additional mechanism
+ through which configuration information, including the list of
+ RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns
+ a lifetime to configuration information obtained through DHCPv6. At
+ the expiration of the lifetime, the host contacts the DHCPv6 server
+ to obtain updated configuration information, including the list of
+ RDNSSes. This lifetime gives the network administrator another
+ mechanism to configure hosts with new RDNSSes by controlling the time
+ at which the host refreshes the list.
+
+ The DHC Working Group has also discussed the possibility of defining
+ an extension to DHCPv6 that would allow the use of multicast to
+ provide configuration information to multiple hosts with a single
+ DHCPv6 message. Because of the lack of deployment experience, the WG
+ has deferred consideration of multicast DHCPv6 configuration at this
+ time. Experience with DHCPv4 has not identified a requirement for
+ multicast message delivery, even in large service provider networks
+ with tens of thousands of hosts that may initiate a DHCPv4 message
+ exchange simultaneously.
+
+3.2.1. Advantages
+
+ The DHCPv6 option for RDNSS has a number of advantages. These
+ include:
+
+ 1. DHCPv6 currently provides a general mechanism for conveying
+ network configuration information to clients. Configuring DHCPv6
+ servers in this way allows the network administrator to configure
+ RDNSSes, the addresses of other network services, and location-
+ specific information, such as time zones.
+
+ 2. As a consequence, when the network administrator goes to
+ configure DHCPv6, all the configuration information can be
+ managed through a single service, typically with a single user
+ interface and a single configuration database.
+
+
+
+
+
+
+
+Jeong Informational [Page 7]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ 3. DHCPv6 allows for the configuration of a host with information
+ specific to that host, so that hosts on the same link can be
+ configured with different RDNSSes and with other configuration
+ information.
+
+ 4. A mechanism exists for extending DHCPv6 to support the
+ transmission of additional configuration that has not yet been
+ anticipated.
+
+ 5. Hosts that require other configuration information, such as the
+ addresses of SIP servers and NTP servers, are likely to need
+ DHCPv6 for other configuration information.
+
+ 6. The specification for configuration of RDNSSes through DHCPv6 is
+ available as an RFC. No new protocol extensions (such as new
+ options) are necessary.
+
+ 7. Interoperability among independent implementations has been
+ demonstrated.
+
+3.2.2. Disadvantages
+
+ The DHCPv6 option for RDNSS has a few disadvantages. These include:
+
+ 1. Update currently requires a message from server (however, see
+ [8]).
+
+ 2. Because DNS information is not contained in RA messages, the host
+ must receive two messages from the router and must transmit at
+ least one message to the router. On networks where bandwidth is
+ at a premium, this is a disadvantage, although on most networks
+ it is not a practical concern.
+
+ 3. There is an increased latency for initial configuration. In
+ addition to waiting for an RA message, the client must now
+ exchange packets with a DHCPv6 server. Even if it is locally
+ installed on a router, this will slightly extend the time
+ required to configure the client. For clients that are moving
+ rapidly from one network to another, this will be a disadvantage.
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Informational [Page 8]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+3.2.3. Observations
+
+ In the general case, on general-purpose networks, stateless DHCPv6
+ provides significant advantages and no significant disadvantages.
+ Even in the case where bandwidth is at a premium and low latency is
+ desired, if hosts require other configuration information in addition
+ to a list of RDNSSes or if hosts must be configured selectively,
+ those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
+ name server option will be advantageous.
+
+ However, we are aware of some applications where it would be
+ preferable to put the RDNSS information into an RA packet; for
+ example, in a mobile phone network, where bandwidth is at a premium
+ and extremely low latency is desired. The DNS configuration based on
+ RA should be standardized so as to allow these special applications
+ to be handled using DNS information in the RA packet.
+
+3.3. Well-known Anycast Addresses
+
+ Anycast uses the same routing system as unicast [9]. However,
+ administrative entities are local ones. The local entities may
+ accept unicast routes (including default routes) to anycast servers
+ from adjacent entities. The administrative entities should not
+ advertise their peer routes to their internal anycast servers, if
+ they want to prohibit external access from some peers to the servers.
+ If some advertisement is inevitable (such as the case with default
+ routes), the packets to the servers should be blocked at the boundary
+ of the entities. Thus, for this anycast, not only unicast routing
+ but also unicast ND protocols can be used as is.
+
+ First of all, the well-known anycast addresses approach is much
+ different from that discussed by the IPv6 Working Group in the past
+ [7]. Note that "anycast" in this memo is simpler than that of RFC
+ 1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to
+ have multiple servers on a single link sharing an anycast address.
+ That is, on a link, an anycast address is assumed to be unique. DNS
+ clients today already have redundancy by having multiple well-known
+ anycast addresses configured as RDNSS addresses. There is no point
+ in having multiple RDNSSes sharing an anycast address on a single
+ link.
+
+ The approach with well-known anycast addresses is to set multiple
+ well-known anycast addresses in clients' resolver configuration files
+ from the beginning as, say, factory default. Thus, there is no
+ transport mechanism and no packet format [7].
+
+ An anycast address is an address shared by multiple servers (in this
+ case, the servers are RDNSSes). A request from a client to the
+
+
+
+Jeong Informational [Page 9]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ anycast address is routed to a server selected by the routing system.
+ However, it is a bad idea to mandate "site" boundary on anycast
+ addresses, because most users do not have their own servers and want
+ to access their ISPs across their site boundaries. Larger sites may
+ also depend on their ISPs or may have their own RDNSSes within "site"
+ boundaries.
+
+3.3.1. Advantages
+
+ The basic advantage of the well-known addresses approach is that it
+ uses no transport mechanism. Thus, the following apply:
+
+ 1. There is no delay to get the response and no further delay by
+ packet losses.
+
+ 2. The approach can be combined with any other configuration
+ mechanisms, such as the RA-based approach and DHCP-based
+ approach, as well as the factory default configuration.
+
+ 3. The approach works over any environment where DNS works.
+
+ Another advantage is that this approach only needs configuration of
+ the DNS servers as a router (or configuration of a proxy router).
+ Considering that DNS servers do need configuration, the amount of
+ overall configuration effort is proportional to the number of DNS
+ servers and it scales linearly. Note that, in the simplest case,
+ where a subscriber to an ISP does not have a DNS server, the
+ subscriber naturally accesses DNS servers of the ISP, even though the
+ subscriber and the ISP do nothing and there is no protocol to
+ exchange DNS server information between the subscriber and the ISP.
+
+3.3.2. Disadvantages
+
+ The well-known anycast addresses approach requires that DNS servers
+ (or routers near to them as a proxy) act as routers to advertise
+ their anycast addresses to the routing system, which requires some
+ configuration (see the last paragraph of the previous section on the
+ scalability of the effort). In addition, routers at the boundary of
+ the "site" might need the configuration of route filters to prevent
+ providing DNS services for parties outside the "site" and the
+ possibility of denial of service attacks on the internal DNS
+ infrastructure.
+
+3.3.3. Observations
+
+ If other approaches are used in addition, the well-known anycast
+ addresses should also be set in RA or DHCP configuration files to
+ reduce the configuration effort of users.
+
+
+
+Jeong Informational [Page 10]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ The redundancy by multiple RDNSSes is better provided by multiple
+ servers with different anycast addresses than by multiple servers
+ sharing the same anycast address, because the former approach allows
+ stale servers to generate routes to their anycast addresses. Thus,
+ in a routing domain (or domains sharing DNS servers), there will be
+ only one server with an anycast address unless the domain is so large
+ that load distribution is necessary.
+
+ Small ISPs will operate one RDNSS at each anycast address that is
+ shared by all the subscribers. Large ISPs may operate multiple
+ RDNSSes at each anycast address to distribute and reduce load, where
+ the boundary between RDNSSes may be fixed (redundancy is still
+ provided by multiple addresses) or change dynamically. DNS packets
+ with the well-known anycast addresses are not expected (though not
+ prohibited) to cross ISP boundaries, as ISPs are expected to be able
+ to take care of themselves.
+
+ Because "anycast" in this memo is simpler than that of RFC 1546 [9]
+ and RFC 3513 [10], where it is assumed to be administratively
+ prohibited to have multiple servers on a single link sharing an
+ anycast address, anycast in this memo should be implemented as
+ UNICAST of RFC 2461 [1] and RFC 3513 [10]. As a result, ND-related
+ instability disappears. Thus, in the well-known anycast addresses
+ approach, anycast can and should use the anycast address as a source
+ unicast (according to RFC 3513 [10]) address of packets of UDP and
+ TCP responses. With TCP, if a route flips and packets to an anycast
+ address are routed to a new server, it is expected that the flip is
+ detected by ICMP or sequence number inconsistency, and that the TCP
+ connection is reset and retried.
+
+4. Interworking among IPv6 DNS Configuration Approaches
+
+ Three approaches can work together for IPv6 host configuration of
+ RDNSS. This section shows a consideration on how these approaches
+ can interwork.
+
+ For ordering between RA and DHCP approaches, the O (Other stateful
+ configuration) flag in the RA message can be used [6][28]. If no
+ RDNSS option is included, an IPv6 host may perform DNS configuration
+ through DHCPv6 [3]-[5] regardless of whether the O flag is set or
+ not.
+
+ The well-known anycast addresses approach fully interworks with the
+ other approaches. That is, the other approaches can remove the
+ configuration effort on servers by using the well-known addresses as
+ the default configuration. Moreover, the clients preconfigured with
+ the well-known anycast addresses can be further configured to use
+ other approaches to override the well-known addresses, if the
+
+
+
+Jeong Informational [Page 11]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ configuration information from other approaches is available.
+ Otherwise, all the clients need to have the well-known anycast
+ addresses preconfigured. In order to use the anycast approach along
+ with two other approaches, there are three choices as follows:
+
+ 1. The first choice is that well-known addresses are used as last
+ resort, when an IPv6 host cannot get RDNSS information through RA
+ and DHCP. The well-known anycast addresses have to be
+ preconfigured in all of IPv6 hosts' resolver configuration files.
+
+ 2. The second is that an IPv6 host can configure well-known
+ addresses as the most preferable in its configuration file even
+ though either an RA option or DHCP option is available.
+
+ 3. The last is that the well-known anycast addresses can be set in
+ RA or DHCP configuration to reduce the configuration effort of
+ users. According to either the RA or DHCP mechanism, the well-
+ known addresses can be obtained by an IPv6 host. Because this
+ approach is the most convenient for users, the last option is
+ recommended.
+
+ Note: This section does not necessarily mean that this document
+ suggests adopting all of these three approaches and making them
+ interwork in the way described here. In fact, as a result of further
+ discussion some approaches may not even be adopted at all.
+
+5. Deployment Scenarios
+
+ Regarding the DNS configuration on the IPv6 host, several mechanisms
+ are being considered by the DNSOP Working Group, such as RA option,
+ DHCPv6 option, and well-known preconfigured anycast addresses as of
+ today, and this document is a final result from the long thread. In
+ this section, we suggest four applicable scenarios of three
+ approaches for IPv6 DNS configuration.
+
+ Note: In the applicable scenarios, authors do not implicitly push any
+ specific approaches into the restricted environments. No enforcement
+ is in each scenario, and all mentioned scenarios are probable. The
+ main objective of this work is to provide a useful guideline for IPv6
+ DNS configuration.
+
+5.1. ISP Network
+
+ A characteristic of an ISP network is that multiple Customer Premises
+ Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
+ routers and that each PE connects multiple CPE devices to the
+ backbone network infrastructure [11]. The CPEs may be hosts or
+ routers.
+
+
+
+Jeong Informational [Page 12]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ If the CPE is a router, there is a customer network that is connected
+ to the ISP backbone through the CPE. Typically, each customer
+ network gets a different IPv6 prefix from an IPv6 PE router, but the
+ same RDNSS configuration will be distributed.
+
+ This section discusses how the different approaches to distributing
+ DNS information are compared in an ISP network.
+
+5.1.1. RA Option Approach
+
+ When the CPE is a host, the RA option for RDNSS can be used to allow
+ the CPE to get RDNSS information and /64 prefix information for
+ stateless address autoconfiguration at the same time when the host is
+ attached to a new subnet [6]. Because an IPv6 host must receive at
+ least one RA message for stateless address autoconfiguration and
+ router configuration, the host could receive RDNSS configuration
+ information in the RA without the overhead of an additional message
+ exchange.
+
+ When the CPE is a router, the CPE may accept the RDNSS information
+ from the RA on the interface connected to the ISP and copy that
+ information into the RAs advertised in the customer network.
+
+ This approach is more valuable in the mobile host scenario, in which
+ the host must receive at least an RA message for detecting a new
+ network, than in other scenarios generally, although the
+ administrator should configure RDNSS information on the routers.
+ Secure ND [12] can provide extended security when RA messages are
+ used.
+
+5.1.2. DHCPv6 Option Approach
+
+ DHCPv6 can be used for RDNSS configuration through the use of the DNS
+ option, and can provide other configuration information in the same
+ message with RDNSS configuration [3]-[5]. The DHCPv6 DNS option is
+ already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or
+ stateless DHCP [4] is not nearly as complex as a full DHCPv6
+ implementation. DHCP is a client-server model protocol, so ISPs can
+ handle user identification on its network intentionally; also,
+ authenticated DHCP [13] can be used for secure message exchange.
+
+ The expected model for deployment of IPv6 service by ISPs is to
+ assign a prefix to each customer, which will be used by the customer
+ gateway to assign a /64 prefix to each network in the customer's
+ network. Prefix delegation with DHCP (DHCPv6 PD) has already been
+ adopted by ISPs for automating the assignment of the customer prefix
+ to the customer gateway [15]. DNS configuration can be carried in
+ the same DHCPv6 message exchange used for DHCPv6 to provide that
+
+
+
+Jeong Informational [Page 13]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ information efficiently, along with any other configuration
+ information needed by the customer gateway or customer network. This
+ service model can be useful to Home or SOHO subscribers. The Home or
+ SOHO gateway, which is a customer gateway for ISP, can then pass that
+ RDNSS configuration information to the hosts in the customer network
+ through DHCP.
+
+5.1.3. Well-known Anycast Addresses Approach
+
+ The well-known anycast addresses approach is also a feasible and
+ simple mechanism for ISP [7]. The use of well-known anycast
+ addresses avoids some of the security risks in rogue messages sent
+ through an external protocol such as RA or DHCPv6. The configuration
+ of hosts for the use of well-known anycast addresses requires no
+ protocol or manual configuration, but the configuration of routing
+ for the anycast addresses requires intervention on the part of the
+ network administrator. Also, the number of special addresses would
+ be equal to the number of RDNSSes that could be made available to
+ subscribers.
+
+5.2. Enterprise Network
+
+ An enterprise network is defined as a network that has multiple
+ internal links, one or more router connections to one or more
+ providers, and is actively managed by a network operations entity
+ [14]. An enterprise network can get network prefixes from an ISP by
+ either manual configuration or prefix delegation [15]. In most
+ cases, because an enterprise network manages its own DNS domains, it
+ operates its own DNS servers for the domains. These DNS servers
+ within enterprise networks process recursive DNS name resolution
+ requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the
+ enterprise network can be performed as it is in Section 4, in which
+ three approaches can be used together as follows:
+
+ 1. An IPv6 host can decide which approach is or may be used in its
+ subnet with the O flag in RA message [6][28]. As the first
+ choice in Section 4, well-known anycast addresses can be used as
+ a last resort when RDNSS information cannot be obtained through
+ either an RA option or a DHCP option. This case needs IPv6 hosts
+ to preconfigure the well-known anycast addresses in their DNS
+ configuration files.
+
+ 2. When the enterprise prefers the well-known anycast approach to
+ others, IPv6 hosts should preconfigure the well-known anycast
+ addresses as it is in the first choice.
+
+ 3. The last choice, a more convenient and transparent way, does not
+ need IPv6 hosts to preconfigure the well-known anycast addresses
+
+
+
+Jeong Informational [Page 14]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ because the addresses are delivered to IPv6 hosts via either the
+ RA option or DHCPv6 option as if they were unicast addresses.
+ This way is most recommended for the sake of the user's
+ convenience.
+
+5.3. 3GPP Network
+
+ The IPv6 DNS configuration is a missing part of IPv6
+ autoconfiguration and an important part of the basic IPv6
+ functionality in the 3GPP User Equipment (UE). The higher-level
+ description of the 3GPP architecture can be found in [16], and
+ transition to IPv6 in 3GPP networks is analyzed in [17] and [18].
+
+ In the 3GPP architecture, there is a dedicated link between the UE
+ and the GGSN called the Packet Data Protocol (PDP) Context. This
+ link is created through the PDP Context activation procedure [19].
+ There is a separate PDP context type for IPv4 and IPv6 traffic. If a
+ 3GPP UE user is communicating by using IPv6 (i.e., by having an
+ active IPv6 PDP context), it cannot be assumed that the user
+ simultaneously has an active IPv4 PDP context, and DNS queries could
+ be done using IPv4. A 3GPP UE can thus be an IPv6 node, and somehow
+ it needs to discover the address of the RDNSS. Before IP-based
+ services (e.g., web browsing or e-mail) can be used, the IPv6 (and
+ IPv4) RDNSS addresses need to be discovered in the 3GPP UE.
+
+ Section 5.3.1 briefly summarizes currently available mechanisms in
+ 3GPP networks and recommendations. 5.3.2 analyzes the Router
+ Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6
+ mechanism, and 5.3.4 analyzes the well-known addresses approach.
+ Section 5.3.5 summarizes the recommendations.
+
+5.3.1. Currently Available Mechanisms and Recommendations
+
+ 3GPP has defined a mechanism in which RDNSS addresses can be received
+ in the PDP context activation (a control plane mechanism). That is
+ called the Protocol Configuration Options Information Element (PCO-
+ IE) mechanism [20]. The RDNSS addresses can also be received over
+ the air (using text messages) or typed in manually in the UE. Note
+ that the two last mechanisms are not very well scalable. The UE user
+ most probably does not want to type IPv6 RDNSS addresses manually in
+ the user's UE. The use of well-known addresses is briefly discussed
+ in section 5.3.4.
+
+ It is seen that the mechanisms above most probably are not sufficient
+ for the 3GPP environment. IPv6 is intended to operate in a zero-
+ configuration manner, no matter what the underlying network
+ infrastructure is. Typically, the RDNSS address is needed to make an
+ IPv6 node operational, and the DNS configuration should be as simple
+
+
+
+Jeong Informational [Page 15]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ as the address autoconfiguration mechanism. Note that there will be
+ additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP-
+ specific DNS configuration mechanisms (such as PCO-IE [20]) do not
+ work for those IP interfaces. In other words, a good IPv6 DNS
+ configuration mechanism should also work in a multi-access network
+ environment.
+
+ From a 3GPP point of view, the best IPv6 DNS configuration solution
+ is feasible for a very large number of IPv6-capable UEs (even
+ hundreds of millions in one operator's network), is automatic, and
+ thus requires no user action. It is suggested that a lightweight,
+ stateless mechanism be standardized for use in all network
+ environments. The solution could then be used for 3GPP, 3GPP2, and
+ other access network technologies. Thus, not only is a light,
+ stateless IPv6 DNS configuration mechanism needed in 3GPP networks,
+ but also 3GPP networks and UEs would certainly benefit from the new
+ mechanism.
+
+5.3.2. RA Extension
+
+ Router Advertisement extension [6] is a lightweight IPv6 DNS
+ configuration mechanism that requires minor changes in the 3GPP UE
+ IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
+ the 3GPP architecture) IPv6 stack. This solution can be specified in
+ the IETF (no action is needed in the 3GPP) and taken in use in 3GPP
+ UEs and GGSNs.
+
+ In this solution, an IPv6-capable UE configures DNS information via
+ an RA message sent by its default router (GGSN); i.e., the RDNSS
+ option for a recursive DNS server is included in the RA message.
+ This solution is easily scalable for a very large number of UEs. The
+ operator can configure the RDNSS addresses in the GGSN as a part of
+ normal GGSN configuration. The IPv6 RDNSS address is received in the
+ Router Advertisement, and an extra Round Trip Time (RTT) for asking
+ RDNSS addresses can be avoided.
+
+ When one considers the cons, this mechanism still requires
+ standardization effort in the IETF, and the end nodes and routers
+ need to support this mechanism. The equipment software update
+ should, however, be pretty straightforward, and new IPv6 equipment
+ could support RA extension already from the beginning.
+
+5.3.3. Stateless DHCPv6
+
+ A DHCPv6-based solution needs the implementation of Stateless DHCP
+ [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the
+ operator's network. A possible configuration is such that the GGSN
+ works as a DHCP relay.
+
+
+
+Jeong Informational [Page 16]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ The pros of a stateless DHCPv6-based solution are:
+
+ 1. Stateless DHCPv6 is a standardized mechanism.
+
+ 2. DHCPv6 can be used for receiving configuration information other
+ than RDNSS addresses; e.g., SIP server addresses.
+
+ 3. DHCPv6 works in different network environments.
+
+ 4. When DHCPv6 service is deployed through a single, centralized
+ server, the RDNSS configuration information can be updated by the
+ network administrator at a single source.
+
+ Some issues with DHCPv6 in 3GPP networks are listed below:
+
+ 1. DHCPv6 requires an additional server in the network unless the
+ (Stateless) DHCPv6 functionality is integrated into an existing
+ router. This means that there might be one additional server to
+ be maintained.
+
+ 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
+ (3GPP Stateless Address Autoconfiguration is typically used) and
+ is not automatically implemented in 3GPP IPv6 UEs.
+
+ 3. Scalability and reliability of DHCPv6 in very large 3GPP networks
+ (with tens or hundreds of millions of UEs) may be an issue; at
+ least the redundancy needs to be taken care of. However, if the
+ DHCPv6 service is integrated into the network elements, such as a
+ router operating system, scalability and reliability is
+ comparable with other DNS configuration approaches.
+
+ 4. It is sub-optimal to utilize the radio resources in 3GPP networks
+ for DHCPv6 messages if there is a simpler alternative is
+ available.
+
+ * The use of stateless DHCPv6 adds one round-trip delay to the
+ case in which the UE can start transmitting data right after
+ the Router Advertisement.
+
+ 5. If the DNS information (suddenly) changes, Stateless DHCPv6
+ cannot automatically update the UE; see [21].
+
+5.3.4. Well-known Addresses
+
+ Using well-known addresses is also a feasible and light mechanism for
+ 3GPP UEs. Those well-known addresses can be preconfigured in the UE
+ software and the operator can make the corresponding configuration on
+ the network side. Thus, this is a very easy mechanism for the UE,
+
+
+
+Jeong Informational [Page 17]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ but it requires some configuration work in the network. When using
+ well-known addresses, UE forwards queries to any of the preconfigured
+ addresses. In the current proposal [7], IPv6 anycast addresses are
+ suggested.
+
+ Note: An IPv6 DNS configuration proposal, based on the use of well-
+ known site-local addresses, was developed by the IPv6 Working Group;
+ it was seen as a feasible mechanism for 3GPP UEs, although no IETF
+ consensus was reached on this proposal. In the end, the deprecation
+ of IPv6 site-local addresses made it impossible to standardize a
+ mechanism that uses site-local addresses as well-known addresses.
+ However, as of this writing, this mechanism is implemented in some
+ operating systems and 3GPP UEs as a last resort of IPv6 DNS
+ configuration.
+
+5.3.5. Recommendations
+
+ It is suggested that a lightweight, stateless DNS configuration
+ mechanism be specified as soon as possible. From a 3GPP UE and
+ network point of view, the Router Advertisement-based mechanism looks
+ most promising. The sooner a light, stateless mechanism is
+ specified, the sooner we can stop using well-known site-local
+ addresses for IPv6 DNS configuration.
+
+5.4. Unmanaged Network
+
+ There are four deployment scenarios of interest in unmanaged networks
+ [22]:
+
+ 1. A gateway that does not provide IPv6 at all,
+
+ 2. A dual-stack gateway connected to a dual-stack ISP,
+
+ 3. A dual-stack gateway connected to an IPv4-only ISP, and
+
+ 4. A gateway connected to an IPv6-only ISP.
+
+5.4.1. Case A: Gateway Does Not Provide IPv6 at All
+
+ In this case, the gateway does not provide IPv6; the ISP may or may
+ not provide IPv6. Automatic or Configured tunnels are the
+ recommended transition mechanisms for this scenario.
+
+ The case where dual-stack hosts behind an NAT need access to an IPv6
+ RDNSS cannot be entirely ruled out. The DNS configuration mechanism
+ has to work over the tunnel, and the underlying tunneling mechanism
+ could implement NAT traversal. The tunnel server assumes the role of
+ a relay (for both DHCP and well-known anycast addresses approaches).
+
+
+
+Jeong Informational [Page 18]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ The RA-based mechanism is relatively straightforward in its
+ operation, assuming the tunnel server is also the IPv6 router
+ emitting RAs. The well-known anycast addresses approach also seems
+ simple in operation across the tunnel, but the deployment model using
+ well-known anycast addresses in a tunneled environment is unclear or
+ not well understood.
+
+5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP
+
+ This is similar to a typical IPv4 home user scenario, where DNS
+ configuration parameters are obtained using DHCP. The exception is
+ that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where
+ the DHCP server is stateful (it maintains the state for clients).
+
+5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP
+
+ This is similar to Case B. If a gateway provides IPv6 connectivity
+ by managing tunnels, then it is also supposed to provide access to an
+ RDNSS. Like this, the tunnel for IPv6 connectivity originates from
+ the dual-stack gateway instead of from the host.
+
+5.4.4. Case D: A Gateway Connected to an IPv6-only ISP
+
+ This is similar to Case B.
+
+6. Security Considerations
+
+ As security requirements depend solely on applications and differ
+ from application to application, there can be no generic requirement
+ defined at the IP or application layer for DNS.
+
+ However, note that cryptographic security requires configured secret
+ information and that full autoconfiguration and cryptographic
+ security are mutually exclusive. People insisting on secure, full
+ autoconfiguration will get false security, false autoconfiguration,
+ or both.
+
+ In some deployment scenarios [17], where cryptographic security is
+ required for applications, the secret information for the
+ cryptographic security is preconfigured, through which application-
+ specific configuration data, including those for DNS, can be securely
+ configured. Note that if applications requiring cryptographic
+ security depend on DNS, the applications also require cryptographic
+ security to DNS. Therefore, the full autoconfiguration of DNS is not
+ acceptable.
+
+ However, with full autoconfiguration, weaker but still reasonable
+ security is being widely accepted and will continue to be acceptable.
+
+
+
+Jeong Informational [Page 19]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ That is, with full autoconfiguration, which means there is no
+ cryptographic security for the autoconfiguration, it is already
+ assumed that the local environment is secure enough that the
+ information from the local autoconfiguration server has acceptable
+ security even without cryptographic security. Thus, the
+ communication between the local DNS client and local DNS server has
+ acceptable security.
+
+ In autoconfiguring recursive servers, DNSSEC may be overkill, because
+ DNSSEC [23]-[25] needs the configuration and reconfiguration of
+ clients at root key roll-over [26][27]. Even if additional keys for
+ secure key roll-over are added at the initial configuration, they are
+ as vulnerable as the original keys to some forms of attack, such as
+ social hacking. Another problem of using DNSSEC and
+ autoconfiguration together is that DNSSEC requires secure time, which
+ means secure communication with autoconfigured time servers, which
+ requires configured secret information. Therefore, in order that the
+ autoconfiguration may be secure, configured secret information is
+ required.
+
+ If DNSSEC [23]-[25] is used and the signatures are verified on the
+ client host, the misconfiguration of a DNS server may simply be
+ denial of service. Also, if local routing environment is not
+ reliable, clients may be directed to a false resolver with the same
+ IP address as the true one.
+
+6.1. RA Option
+
+ The security of RA option for RDNSS is the same as the ND protocol
+ security [1][6]. The RA option does not add any new vulnerability.
+
+ Note that the vulnerability of ND is not worse and is a subset of the
+ attacks that any node attached to a LAN can do independently of ND.
+ A malicious node on a LAN can promiscuously receive packets for any
+ router's MAC address and send packets with the router's MAC address
+ as the source MAC address in the L2 header. As a result, the L2
+ switches send packets addressed to the router to the malicious node.
+ Also, this attack can send redirects that tell the hosts to send
+ their traffic somewhere else. The malicious node can send
+ unsolicited RA or NA replies, answer RS or NS requests, etc. All of
+ this can be done independently of implementing ND. Therefore, the RA
+ option for RDNSS does not add to the vulnerability.
+
+ Security issues regarding the ND protocol were discussed by the IETF
+ SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for
+ the ND security has been published [12].
+
+
+
+
+
+Jeong Informational [Page 20]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+6.2. DHCPv6 Option
+
+ The DNS Recursive Name Server option may be used by an intruder DHCP
+ server to cause DHCP clients to send DNS queries to an intruder DNS
+ recursive name server [5]. The results of these misdirected DNS
+ queries may be used to spoof DNS names.
+
+ To avoid attacks through the DNS Recursive Name Server option, the
+ DHCP client SHOULD require DHCP authentication (see "Authentication
+ of DHCP messages" in RFC 3315 [3][13]) before installing a list of
+ DNS recursive name servers obtained through authenticated DHCP.
+
+6.3. Well-known Anycast Addresses
+
+ The well-known anycast addresses approach is not a protocol, thus
+ there is no need to secure the protocol itself.
+
+ However, denial of service attacks on the DNS resolver system might
+ be easier to achieve as the anycast addresses used are by definition
+ well known.
+
+7. Contributors
+
+ Ralph Droms
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxboro, MA 01719
+ US
+
+ Phone: +1 978 936 1674
+ EMail: rdroms@cisco.com
+
+
+ Robert M. Hinden
+ Nokia
+ 313 Fairchild Drive
+ Mountain View, CA 94043
+ US
+
+ Phone: +1 650 625 2004
+ EMail: bob.hinden@nokia.com
+
+
+
+
+
+
+
+
+
+
+Jeong Informational [Page 21]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ Ted Lemon
+ Nominum, Inc.
+ 950 Charter Street
+ Redwood City, CA 94043
+ US
+
+ EMail: Ted.Lemon@nominum.com
+
+ Masataka Ohta
+ Tokyo Institute of Technology
+ 2-12-1, O-okayama, Meguro-ku
+ Tokyo 152-8552
+ Japan
+
+ Phone: +81 3 5734 3299
+ Fax: +81 3 5734 3299
+ EMail: mohta@necom830.hpcl.titech.ac.jp
+
+
+ Soohong Daniel Park
+ Mobile Platform Laboratory, SAMSUNG Electronics
+ 416 Maetan-3dong, Yeongtong-Gu
+ Suwon, Gyeonggi-Do 443-742
+ Korea
+
+ Phone: +82 31 200 4508
+ EMail: soohong.park@samsung.com
+
+
+ Suresh Satapati
+ Cisco Systems, Inc.
+ San Jose, CA 95134
+ US
+
+ EMail: satapati@cisco.com
+
+
+ Juha Wiljakka
+ Nokia
+ Visiokatu 3
+ FIN-33720, TAMPERE
+ Finland
+
+ Phone: +358 7180 48372
+ EMail: juha.wiljakka@nokia.com
+
+
+
+
+
+
+Jeong Informational [Page 22]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+8. Acknowledgements
+
+ This document has greatly benefited from inputs by David Meyer, Rob
+ Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
+ Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
+ Also, Tony Bonanno proofread this document. The authors appreciate
+ their contribution.
+
+9. References
+
+9.1. Normative References
+
+ [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+ for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+ [2] Thomson, S. and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+ Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+ RFC 3315, July 2003.
+
+ [4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
+ Service for IPv6", RFC 3736, April 2004.
+
+ [5] Droms, R., "DNS Configuration options for Dynamic Host
+ Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
+ 2003.
+
+9.2. Informative References
+
+ [6] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6
+ Router Advertisement Option for DNS Configuration", Work in
+ Progress, September 2005.
+
+ [7] Ohta, M., "Preconfigured DNS Server Addresses", Work in
+ Progress, February 2004.
+
+ [8] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
+ Option for Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6)", RFC 4242, November 2005.
+
+ [9] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
+ Service", RFC 1546, November 1993.
+
+ [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+ Addressing Architecture", RFC 3513, April 2003.
+
+
+
+
+Jeong Informational [Page 23]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ [11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola,
+ "Scenarios and Analysis for Introducing IPv6 into ISP Networks",
+ RFC 4029, March 2005.
+
+ [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
+ Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+ [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
+ RFC 3118, June 2001.
+
+ [14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June
+ 2005.
+
+ [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
+ Configuration Protocol (DHCP) version 6", RFC 3633, December
+ 2003.
+
+ [16] Wasserman, M., "Recommendations for IPv6 in Third Generation
+ Partnership Project (3GPP) Standards", RFC 3314, September 2002.
+
+ [17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC
+ 3574, August 2003.
+
+ [18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation
+ Partnership Project (3GPP) Networks", RFC 4215, October 2005.
+
+ [19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
+ Service description; Stage 2 (Release 5)", December 2002.
+
+ [20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
+ specification; Core network protocols; Stage 3 (Release 5)",
+ June 2003.
+
+ [21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
+ Requirements for Stateless Dynamic Host Configuration Protocol
+ for IPv6 (DHCPv6)", RFC 4076, May 2005.
+
+ [22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
+ "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April
+ 2004.
+
+ [23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033, March
+ 2005.
+
+ [24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+
+
+Jeong Informational [Page 24]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 2006
+
+
+ [25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions", RFC
+ 4035, March 2005.
+
+ [26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work
+ in Progress, October 2005.
+
+ [27] Guette, G. and O. Courtay, "Requirements for Automated Key
+ Rollover in DNSSEC", Work in Progress, January 2005.
+
+ [28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
+ and O Flags of IPv6 Router Advertisement", Work in Progress,
+ March 2005.
+
+Author's Address
+
+ Jaehoon Paul Jeong (editor)
+ ETRI/Department of Computer Science and Engineering
+ University of Minnesota
+ 117 Pleasant Street SE
+ Minneapolis, MN 55455
+ US
+
+ Phone: +1 651 587 7774
+ Fax: +1 612 625 2002
+ EMail: jjeong@cs.umn.edu
+ URI: http://www.cs.umn.edu/~jjeong/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Informational [Page 25]
+
+RFC 4339 IPv6 Host Configuration of DNS Server February 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).
+
+
+
+
+
+
+
+Jeong Informational [Page 26]
+
diff --git a/doc/rfc/rfc4471.txt b/doc/rfc/rfc4471.txt
new file mode 100644
index 0000000000..eb338e6b5e
--- /dev/null
+++ b/doc/rfc/rfc4471.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group G. Sisson
+Request for Comments: 4471 B. Laurie
+Category: Experimental Nominet
+ September 2006
+
+
+ Derivation of DNS Name Predecessor and Successor
+
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes two methods for deriving the canonically-
+ ordered predecessor and successor of a DNS name. These methods may
+ be used for dynamic NSEC resource record synthesis, enabling
+ security-aware name servers to provide authenticated denial of
+ existence without disclosing other owner names in a DNSSEC secured
+ zone.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Notational Conventions ..........................................3
+ 3. Derivations .....................................................3
+ 3.1. Absolute Method ............................................3
+ 3.1.1. Derivation of DNS Name Predecessor ..................3
+ 3.1.2. Derivation of DNS Name Successor ....................4
+ 3.2. Modified Method ............................................4
+ 3.2.1. Derivation of DNS Name Predecessor ..................5
+ 3.2.2. Derivation of DNS Name Successor ....................6
+ 4. Notes ...........................................................6
+ 4.1. Test for Existence .........................................6
+ 4.2. Case Considerations ........................................7
+ 4.3. Choice of Range ............................................7
+ 4.4. Wild Card Considerations ...................................8
+ 4.5. Possible Modifications .....................................8
+ 4.5.1. Restriction of Effective Maximum DNS Name Length ....8
+ 4.5.2. Use of Modified Method with Zones Containing
+
+
+
+Sisson & Laurie Experimental [Page 1]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ SRV RRs .............................................8
+ 5. Examples ........................................................9
+ 5.1. Examples of Immediate Predecessors Using Absolute Method ..10
+ 5.2. Examples of Immediate Successors Using Absolute Method ....14
+ 5.3. Examples of Predecessors Using Modified Method ............19
+ 5.4. Examples of Successors Using Modified Method ..............20
+ 6. Security Considerations ........................................21
+ 7. Acknowledgements ...............................................21
+ 8. References .....................................................21
+ 8.1. Normative References ......................................21
+ 8.2. Informative References ....................................22
+
+1. Introduction
+
+ One of the proposals for avoiding the exposure of zone information
+ during the deployment DNSSEC is dynamic NSEC resource record (RR)
+ synthesis. This technique is described in [DNSSEC-TRANS] and
+ [RFC4470], and involves the generation of NSEC RRs that just span the
+ query name for non-existent owner names. In order to do this, the
+ DNS names that would occur just prior to and just following a given
+ query name must be calculated in real time, as maintaining a list of
+ all possible owner names that might occur in a zone would be
+ impracticable.
+
+ Section 6.1 of [RFC4034] defines canonical DNS name order. This
+ document does not amend or modify this definition. However, the
+ derivation of immediate predecessor and successor, although trivial,
+ is non-obvious. Accordingly, several methods are described here as
+ an aid to implementors and a reference to other interested parties.
+
+ This document describes two methods:
+
+ 1. An "absolute method", which returns the immediate predecessor or
+ successor of a domain name such that no valid DNS name could
+ exist between that DNS name and the predecessor or successor.
+
+ 2. A "modified method", which returns a predecessor and successor
+ that are more economical in size and computation. This method is
+ restricted to use with zones consisting exclusively of owner
+ names that contain no more than one label more than the owner
+ name of the apex, where the longest possible owner name (i.e.,
+ one with a maximum length left-most label) would not exceed the
+ maximum DNS name length. This is, however, the type of zone for
+ which the technique of online signing is most likely to be used.
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 2]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+2. Notational Conventions
+
+ The following notational conventions are used in this document for
+ economy of expression:
+
+ N: An unspecified DNS name.
+
+ P(N): Immediate predecessor to N (absolute method).
+
+ S(N): Immediate successor to N (absolute method).
+
+ P'(N): Predecessor to N (modified method).
+
+ S'(N): Successor to N (modified method).
+
+3. Derivations
+
+ These derivations assume that all uppercase US-ASCII letters in N
+ have already been replaced by their corresponding lowercase
+ equivalents. Unless otherwise specified, processing stops after the
+ first step in which a condition is met.
+
+ The derivations make reference to maximum label length and maximum
+ DNS name length; these are defined in Section 3.1 of [RFC1034] to be
+ 63 and 255 octets, respectively.
+
+3.1. Absolute Method
+
+3.1.1. Derivation of DNS Name Predecessor
+
+ To derive P(N):
+
+ 1. If N is the same as the owner name of the zone apex, prepend N
+ repeatedly with labels of the maximum length possible consisting
+ of octets of the maximum sort value (e.g., 0xff) until N is the
+ maximum length possible; otherwise proceed to the next step.
+
+ 2. If the least significant (left-most) label of N consists of a
+ single octet of the minimum sort value (e.g., 0x00), remove that
+ label; otherwise proceed to the next step.
+
+ 3. If the least significant (right-most) octet in the least
+ significant (left-most) label of N is the minimum sort value,
+ remove the least significant octet and proceed to step 5.
+
+ 4. Decrement the value of the least significant (right-most) octet
+ of the least significant (left-most) label, skipping any values
+ that correspond to uppercase US-ASCII letters, and then append
+
+
+
+Sisson & Laurie Experimental [Page 3]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ the least significant (left-most) label with as many octets as
+ possible of the maximum sort value. Proceed to the next step.
+
+ 5. Prepend N repeatedly with labels of as long a length as possible
+ consisting of octets of the maximum sort value until N is the
+ maximum length possible.
+
+3.1.2. Derivation of DNS Name Successor
+
+ To derive S(N):
+
+ 1. If N is two or more octets shorter than the maximum DNS name
+ length, prepend N with a label containing a single octet of the
+ minimum sort value (e.g., 0x00); otherwise proceed to the next
+ step.
+
+ 2. If N is one octet shorter than the maximum DNS name length and
+ the least significant (left-most) label is one or more octets
+ shorter than the maximum label length, append an octet of the
+ minimum sort value to the least significant label; otherwise
+ proceed to the next step.
+
+ 3. Increment the value of the least significant (right-most) octet
+ in the least significant (left-most) label that is less than the
+ maximum sort value (e.g., 0xff), skipping any values that
+ correspond to uppercase US-ASCII letters, and then remove any
+ octets to the right of that one. If all octets in the label are
+ the maximum sort value, then proceed to the next step.
+
+ 4. Remove the least significant (left-most) label. Unless N is now
+ the same as the owner name of the zone apex (this will occur only
+ if N was the maximum possible name in canonical DNS name order,
+ and thus has wrapped to the owner name of zone apex), repeat
+ starting at step 2.
+
+3.2. Modified Method
+
+ This method is for use with zones consisting only of single-label
+ owner names where an owner name consisting of label of maximum length
+ would not result in a DNS name that exceeded the maximum DNS name
+ length. This method is computationally simpler and returns values
+ that are more economical in size than the absolute method. It
+ differs from the absolute method detailed above in the following
+ ways:
+
+ 1. Step 1 of the derivation P(N) has been omitted as the existence
+ of the owner name of the zone apex never requires denial.
+
+
+
+
+Sisson & Laurie Experimental [Page 4]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ 2. A new step 1 has been introduced that removes unnecessary labels.
+
+ 3. Step 4 of the derivation P(N) has been omitted as it is only
+ necessary for zones containing owner names consisting of more
+ than one label. This omission generally results in a significant
+ reduction of the length of derived predecessors.
+
+ 4. Step 1 of the derivation S(N) had been omitted as it is only
+ necessary for zones containing owner names consisting of more
+ than one label. This omission results in a tiny reduction of the
+ length of derived successors, and maintains consistency with the
+ modification of step 4 of the derivation P(N) described above.
+
+ 5. Steps 2 and 4 of the derivation S(N) have been modified to
+ eliminate checks for maximum DNS name length, as it is an
+ assumption of this method that no DNS name in the zone can exceed
+ the maximum DNS name length.
+
+3.2.1. Derivation of DNS Name Predecessor
+
+ To derive P'(N):
+
+ 1. If N is two or more labels longer than the owner name of the
+ apex, repeatedly remove the least significant (left-most) label
+ until N is only one label longer than the owner name of the apex;
+ otherwise proceed to the next step.
+
+ 2. If the least significant (left-most) label of N consists of a
+ single octet of the minimum sort value (e.g., 0x00), remove that
+ label; otherwise proceed to the next step. (If this condition is
+ met, P'(N) is the owner name of the apex.)
+
+ 3. If the least significant (right-most) octet in the least
+ significant (left-most) label of N is the minimum sort value,
+ remove the least significant octet.
+
+ 4. Decrement the value of the least significant (right-most) octet,
+ skipping any values that correspond to uppercase US-ASCII
+ letters, and then append the label with as many octets as
+ possible of the maximum sort value.
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 5]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+3.2.2. Derivation of DNS Name Successor
+
+ To derive S'(N):
+
+ 1. If N is two or more labels longer than the owner name of the
+ apex, repeatedly remove the least significant (left-most) label
+ until N is only one label longer than the owner name of the apex.
+ Proceed to the next step.
+
+ 2. If the least significant (left-most) label of N is one or more
+ octets shorter than the maximum label length, append an octet of
+ the minimum sort value to the least significant label; otherwise
+ proceed to the next step.
+
+ 3. Increment the value of the least significant (right-most) octet
+ in the least significant (left-most) label that is less than the
+ maximum sort value (e.g., 0xff), skipping any values that
+ correspond to uppercase US-ASCII letters, and then remove any
+ octets to the right of that one. If all octets in the label are
+ the maximum sort value, then proceed to the next step.
+
+ 4. Remove the least significant (left-most) label. (This will occur
+ only if the least significant label is the maximum label length
+ and consists entirely of octets of the maximum sort value, and
+ thus has wrapped to the owner name of the zone apex.)
+
+4. Notes
+
+4.1. Test for Existence
+
+ Before using the result of P(N) or P'(N) as the owner name of an NSEC
+ RR in a DNS response, a name server should test to see whether the
+ name exists. If it does, either a standard non-synthesised NSEC RR
+ should be used, or the synthesised NSEC RR should reflect the RRset
+ types that exist at the NSEC RR's owner name in the Type Bit Map
+ field as specified by Section 4.1.2 of [RFC4034]. Implementors will
+ likely find it simpler to use a non-synthesised NSEC RR. For further
+ details, see Section 2 of [RFC4470].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 6]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+4.2. Case Considerations
+
+ Section 3.5 of [RFC1034] specifies that "while upper and lower case
+ letters are allowed in names, no significance is attached to the
+ case". Additionally, Section 6.1 of [RFC4034] states that when
+ determining canonical DNS name order, "uppercase US-ASCII letters are
+ treated as if they were lowercase US-ASCII letters". Consequently,
+ values corresponding to US-ASCII uppercase letters must be skipped
+ when decrementing and incrementing octets in the derivations
+ described in Section 3.
+
+ The following pseudo-code is illustrative:
+
+ Decrement the value of an octet:
+
+ if (octet == '[') // '[' is just after uppercase 'Z'
+ octet = '@'; // '@' is just prior to uppercase 'A'
+ else
+ octet--;
+
+ Increment the value of an octet:
+
+ if (octet == '@') // '@' is just prior to uppercase 'A'
+ octet = '['; // '[' is just after uppercase 'Z'
+ else
+ octet++;
+
+4.3. Choice of Range
+
+ [RFC2181] makes the clarification that "any binary string whatever
+ can be used as the label of any resource record". Consequently, the
+ minimum sort value may be set as 0x00 and the maximum sort value as
+ 0xff, and the range of possible values will be any DNS name that
+ contains octets of any value other than those corresponding to
+ uppercase US-ASCII letters.
+
+ However, if all owner names in a zone are in the letter-digit-hyphen,
+ or LDH, format specified in [RFC1034], it may be desirable to
+ restrict the range of possible values to DNS names containing only
+ LDH values. This has the effect of
+
+ 1. making the output of tools such as `dig' and `nslookup' less
+ subject to confusion,
+
+ 2. minimising the impact that NSEC RRs containing DNS names with
+ non-LDH values (or non-printable values) might have on faulty DNS
+ resolver implementations, and
+
+
+
+
+Sisson & Laurie Experimental [Page 7]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ 3. preventing the possibility of results that are wildcard DNS names
+ (see Section 4.4).
+
+ This may be accomplished by using a minimum sort value of 0x1f (US-
+ ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
+ character lowercase `z'), and then skipping non-LDH, non-lowercase
+ values when incrementing or decrementing octets.
+
+4.4. Wild Card Considerations
+
+ Neither derivation avoids the possibility that the result may be a
+ DNS name containing a wildcard label, i.e., a label containing a
+ single octet with the value 0x2a (US-ASCII character `*'). With
+ additional tests, wildcard DNS names may be explicitly avoided;
+ alternatively, if the range of octet values can be restricted to
+ those corresponding to letter-digit-hyphen, or LDH, characters (see
+ Section 4.3), such DNS names will not occur.
+
+ Note that it is improbable that a result that is a wildcard DNS name
+ will occur unintentionally; even if one does occur either as the
+ owner name of, or in the RDATA of an NSEC RR, it is treated as a
+ literal DNS name with no special meaning.
+
+4.5. Possible Modifications
+
+4.5.1. Restriction of Effective Maximum DNS Name Length
+
+ [RFC1034] specifies that "the total number of octets that represent a
+ name (i.e., the sum of all label octets and label lengths) is limited
+ to 255", including the null (zero-length) label that represents the
+ root. For the purpose of deriving predecessors and successors during
+ NSEC RR synthesis, the maximum DNS name length may be effectively
+ restricted to the length of the longest DNS name in the zone. This
+ will minimise the size of responses containing synthesised NSEC RRs
+ but, especially in the case of the modified method, may result in
+ some additional computational complexity.
+
+ Note that this modification will have the effect of revealing
+ information about the longest name in the zone. Moreover, when the
+ contents of the zone changes, e.g., during dynamic updates and zone
+ transfers, care must be taken to ensure that the effective maximum
+ DNS name length agrees with the new contents.
+
+4.5.2. Use of Modified Method with Zones Containing SRV RRs
+
+ Normally, the modified method cannot be used in zones that contain
+ Service Record (SRV) RRs [RFC2782], as SRV RRs have owner names that
+ contain multiple labels. However, the use of SRV RRs can be
+
+
+
+Sisson & Laurie Experimental [Page 8]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ accommodated by various techniques. There are at least four possible
+ ways to do this:
+
+ 1. Use conventional NSEC RRs for the region of the zone that
+ contains first-level labels beginning with the underscore (`_')
+ character. For the purposes of generating these NSEC RRs, the
+ existence of (possibly fictional) ownernames `9{63}' and `a'
+ could be assumed, providing a lower and upper bound for this
+ region. Then all queries where the QNAME does not exist but
+ contains a first-level label beginning with an underscore could
+ be handled using the normal DNSSEC protocol.
+
+ This approach would make it possible to enumerate all DNS names
+ in the zone containing a first-level label beginning with
+ underscore, including all SRV RRs, but this may be of less a
+ concern to the zone administrator than incurring the overhead of
+ the absolute method or of the following variants of the modified
+ method.
+
+ 2. The absolute method could be used for synthesising NSEC RRs for
+ all queries where the QNAME contains a leading underscore.
+ However, this re-introduces the susceptibility of the absolute
+ method to denial of service activity, as an attacker could send
+ queries for an effectively inexhaustible supply of domain names
+ beginning with a leading underscore.
+
+ 3. A variant of the modified method could be used for synthesising
+ NSEC RRs for all queries where the QNAME contains a leading
+ underscore. This variant would assume that all predecessors and
+ successors to queries where the QNAME contains a leading
+ underscore may consist of two labels rather than only one. This
+ introduces a little additional complexity without incurring the
+ full increase in response size and computational complexity as
+ the absolute method.
+
+ 4. Finally, a variant of the modified method that assumes that all
+ owner names in the zone consist of one or two labels could be
+ used. However, this negates much of the reduction in response
+ size of the modified method and may be nearly as computationally
+ complex as the absolute method.
+
+5. Examples
+
+ In the following examples,
+
+ the owner name of the zone apex is "example.com.",
+
+
+
+
+
+Sisson & Laurie Experimental [Page 9]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ the range of octet values is 0x00 - 0xff excluding values
+ corresponding to uppercase US-ASCII letters, and
+
+ non-printable octet values are expressed as three-digit decimal
+ numbers preceded by a backslash (as specified in Section 5.1 of
+ [RFC1035]).
+
+5.1. Examples of Immediate Predecessors Using Absolute Method
+
+ Example of a typical case:
+
+ P(foo.example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.fon\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
+
+ where {n} represents the number of repetitions of an octet.
+
+ Example where least significant (left-most) label of DNS name
+ consists of a single octet of the minimum sort value:
+
+ P(\000.foo.example.com.) = foo.example.com.
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 10]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ Example where least significant (right-most) octet of least
+ significant (left-most) label has the minimum sort value:
+
+ P(foo\000.example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.foo.example.com.
+
+ or, in alternate notation:
+
+ \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 11]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ Example where DNS name contains an octet that must be decremented by
+ skipping values corresponding to US-ASCII uppercase letters:
+
+ P(fo\[.example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.fo\@\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
+
+ where {n} represents the number of repetitions of an octet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 12]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ Example where DNS name is the owner name of the zone apex, and
+ consequently wraps to the DNS name with the maximum possible sort
+ order in the zone:
+
+ P(example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 13]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+5.2. Examples of Immediate Successors Using Absolute Method
+
+ Example of typical case:
+
+ S(foo.example.com.) = \000.foo.example.com.
+
+ Example where DNS name is one octet short of the maximum DNS name
+ length:
+
+ N = fooooooooooooooooooooooooooooooooooooooooooooooo
+ .ooooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooo.ooooooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooo.ooooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+ or, in alternate notation:
+
+ fo{47}.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ fooooooooooooooooooooooooooooooooooooooooooooooo
+ \000.ooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooooo.ooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooooo.ooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oooo.example.com.
+
+ or, in alternate notation:
+
+ fo{47}\000.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 14]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ Example where DNS name is the maximum DNS name length:
+
+ N = fooooooooooooooooooooooooooooooooooooooooooooooo
+ o.oooooooooooooooooooooooooooooooooooooooooooooo
+ ooooooooooooooooo.oooooooooooooooooooooooooooooo
+ ooooooooooooooooooooooooooooooooo.oooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ o.example.com.
+
+ or, in alternate notation:
+
+ fo{48}.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ fooooooooooooooooooooooooooooooooooooooooooooooo
+ p.oooooooooooooooooooooooooooooooooooooooooooooo
+ ooooooooooooooooo.oooooooooooooooooooooooooooooo
+ ooooooooooooooooooooooooooooooooo.oooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ o.example.com.
+
+ or, in alternate notation:
+
+ fo{47}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 15]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ Example where DNS name is the maximum DNS name length and the least
+ significant (left-most) label has the maximum sort value:
+
+ N = \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.ooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooooo.ooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooooo.ooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oooo.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooop.oooooooooooooooooooooooooooooooo
+ ooooooooooooooooooooooooooooooo.oooooooooooooooo
+ ooooooooooooooooooooooooooooooooooooooooooooooo.
+ example.com.
+
+ or, in alternate notation:
+
+ o{62}p.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 16]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ Example where DNS name is the maximum DNS name length and the eight
+ least significant (right-most) octets of the least significant
+ (left-most) label have the maximum sort value:
+
+ N = foooooooooooooooooooooooooooooooooooooooo\255
+ \255\255\255\255\255\255\255.ooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooo.ooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooo.ooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooo.example.com.
+
+ or, in alternate notation:
+
+ fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ fooooooooooooooooooooooooooooooooooooooop.oooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ ooooooooo.oooooooooooooooooooooooooooooooooooooo
+ ooooooooooooooooooooooooo.oooooooooooooooooooooo
+ ooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+ or, in alternate notation:
+
+ fo{39}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 17]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ Example where DNS name is the maximum DNS name length and contains an
+ octet that must be incremented by skipping values corresponding to
+ US-ASCII uppercase letters:
+
+ N = fooooooooooooooooooooooooooooooooooooooooooooooo
+ \@.ooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooo.ooooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooo.ooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oo.example.com.
+
+ or, in alternate notation:
+
+ fo{47}\@.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ fooooooooooooooooooooooooooooooooooooooooooooooo
+ \[.ooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooo.ooooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooo.ooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oo.example.com.
+
+ or, in alternate notation:
+
+ fo{47}\[.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 18]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ Example where DNS name has the maximum possible sort order in the
+ zone, and consequently wraps to the owner name of the zone apex:
+
+ N = \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+ S(N) = example.com.
+
+5.3. Examples of Predecessors Using Modified Method
+
+ Example of a typical case:
+
+ P'(foo.example.com.) =
+
+ fon\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.example.com.
+
+ or, in alternate notation:
+
+ fon\255{60}.example.com.
+
+
+
+
+Sisson & Laurie Experimental [Page 19]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ Example where DNS name contains more labels than DNS names in the
+ zone:
+
+ P'(bar.foo.example.com.) = foo.example.com.
+
+ Example where least significant (right-most) octet of least
+ significant (left-most) label has the minimum sort value:
+
+ P'(foo\000.example.com.) = foo.example.com.
+
+ Example where least significant (left-most) label has the minimum
+ sort value:
+
+ P'(\000.example.com.) = example.com.
+
+ Example where DNS name is the owner name of the zone apex, and
+ consequently wraps to the DNS name with the maximum possible sort
+ order in the zone:
+
+ P'(example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255.example.com.
+
+ or, in alternate notation:
+
+ \255{63}.example.com.
+
+5.4. Examples of Successors Using Modified Method
+
+ Example of a typical case:
+
+ S'(foo.example.com.) = foo\000.example.com.
+
+ Example where DNS name contains more labels than DNS names in the
+ zone:
+
+ S'(bar.foo.example.com.) = foo\000.example.com.
+
+
+ Example where least significant (left-most) label has the maximum
+ sort value, and consequently wraps to the owner name of the zone
+ apex:
+
+
+
+
+Sisson & Laurie Experimental [Page 20]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+ N = \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255.example.com.
+
+ or, in alternate notation:
+
+ \255{63}.example.com.
+
+ S'(N) = example.com.
+
+6. Security Considerations
+
+ The derivation of some predecessors/successors requires the testing
+ of more conditions than others. Consequently, the effectiveness of a
+ denial-of-service attack may be enhanced by sending queries that
+ require more conditions to be tested. The modified method involves
+ the testing of fewer conditions than the absolute method and
+ consequently is somewhat less susceptible to this exposure.
+
+7. Acknowledgements
+
+ The authors would like to thank Sam Weiler, Olaf Kolkman, Olafur
+ Gudmundsson, and Niall O'Reilly for their review and input.
+
+8. References
+
+8.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.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
+ for specifying the location of services (DNS SRV)",
+ RFC 2782, February 2000.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and
+ S. Rose, "Resource Records for the DNS Security
+ Extensions", RFC 4034, March 2005.
+
+
+
+
+Sisson & Laurie Experimental [Page 21]
+
+RFC 4471 DNS Name Predecessor and Successor September 2006
+
+
+8.2. Informative References
+
+ [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC
+ Records and DNSSEC On-line Signing", RFC 4470, April
+ 2006.
+
+ [DNSSEC-TRANS] Arends, R., Koch, P., and J. Schlyter, "Evaluating
+ DNSSEC Transition Mechanisms", Work in Progress,
+ February 2005.
+
+Authors' Addresses
+
+ Geoffrey Sisson
+ Nominet
+ Sandford Gate
+ Sandy Lane West
+ Oxford
+ OX4 6LB
+ GB
+
+ Phone: +44 1865 332211
+ EMail: geoff@nominet.org.uk
+
+
+ Ben Laurie
+ Nominet
+ 17 Perryn Road
+ London
+ W3 7LR
+ GB
+
+ Phone: +44 20 8735 0686
+ EMail: ben@algroup.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 22]
+
+RFC 4471 DNS Name Predecessor and Successor September 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).
+
+
+
+
+
+
+
+Sisson & Laurie Experimental [Page 23]
+
diff --git a/doc/rfc/rfc4472.txt b/doc/rfc/rfc4472.txt
new file mode 100644
index 0000000000..b396e9a11a
--- /dev/null
+++ b/doc/rfc/rfc4472.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group A. Durand
+Request for Comments: 4472 Comcast
+Category: Informational J. Ihren
+ Autonomica
+ P. Savola
+ CSC/FUNET
+ April 2006
+
+
+ Operational Considerations and Issues with IPv6 DNS
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This memo presents operational considerations and issues with IPv6
+ Domain Name System (DNS), including a summary of special IPv6
+ addresses, documentation of known DNS implementation misbehavior,
+ recommendations and considerations on how to perform DNS naming for
+ service provisioning and for DNS resolver IPv6 support,
+ considerations for DNS updates for both the forward and reverse
+ trees, and miscellaneous issues. This memo is aimed to include a
+ summary of information about IPv6 DNS considerations for those who
+ have experience with IPv4 DNS.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Representing IPv6 Addresses in DNS Records .................3
+ 1.2. Independence of DNS Transport and DNS Records ..............4
+ 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
+ 1.4. Query Type '*' and A/AAAA Records ..........................4
+ 2. DNS Considerations about Special IPv6 Addresses .................5
+ 2.1. Limited-Scope Addresses ....................................5
+ 2.2. Temporary Addresses ........................................5
+ 2.3. 6to4 Addresses .............................................5
+ 2.4. Other Transition Mechanisms ................................5
+ 3. Observed DNS Implementation Misbehavior .........................6
+ 3.1. Misbehavior of DNS Servers and Load-balancers ..............6
+ 3.2. Misbehavior of DNS Resolvers ...............................6
+
+
+
+Durand, et al. Informational [Page 1]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ 4. Recommendations for Service Provisioning Using DNS ..............7
+ 4.1. Use of Service Names instead of Node Names .................7
+ 4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
+ 4.3. Adding the Records Only When Fully IPv6-enabled ............8
+ 4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
+ 4.4.1. TTL with Courtesy Additional Data ...................9
+ 4.4.2. TTL with Critical Additional Data ..................10
+ 4.5. IPv6 Transport Guidelines for DNS Servers .................10
+ 5. Recommendations for DNS Resolver IPv6 Support ..................10
+ 5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
+ 5.2. Obtaining a List of DNS Recursive Resolvers ...............12
+ 5.3. IPv6 Transport Guidelines for Resolvers ...................12
+ 6. Considerations about Forward DNS Updating ......................13
+ 6.1. Manual or Custom DNS Updates ..............................13
+ 6.2. Dynamic DNS ...............................................13
+ 7. Considerations about Reverse DNS Updating ......................14
+ 7.1. Applicability of Reverse DNS ..............................14
+ 7.2. Manual or Custom DNS Updates ..............................15
+ 7.3. DDNS with Stateless Address Autoconfiguration .............16
+ 7.4. DDNS with DHCP ............................................17
+ 7.5. DDNS with Dynamic Prefix Delegation .......................17
+ 8. Miscellaneous DNS Considerations ...............................18
+ 8.1. NAT-PT with DNS-ALG .......................................18
+ 8.2. Renumbering Procedures and Applications' Use of DNS .......18
+ 9. Acknowledgements ...............................................19
+ 10. Security Considerations .......................................19
+ 11. References ....................................................20
+ 11.1. Normative References .....................................20
+ 11.2. Informative References ...................................22
+ Appendix A. Unique Local Addressing Considerations for DNS ........24
+ Appendix B. Behavior of Additional Data in IPv4/IPv6
+ Environments ..........................................24
+ B.1. Description of Additional Data Scenarios ..................24
+ B.2. Which Additional Data to Keep, If Any? ....................26
+ B.3. Discussion of the Potential Problems ......................27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 2]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+1. Introduction
+
+ This memo presents operational considerations and issues with IPv6
+ DNS; it is meant to be an extensive summary and a list of pointers
+ for more information about IPv6 DNS considerations for those with
+ experience with IPv4 DNS.
+
+ The purpose of this document is to give information about various
+ issues and considerations related to DNS operations with IPv6; it is
+ not meant to be a normative specification or standard for IPv6 DNS.
+
+ The first section gives a brief overview of how IPv6 addresses and
+ names are represented in the DNS, how transport protocols and
+ resource records (don't) relate, and what IPv4/IPv6 name space
+ fragmentation means and how to avoid it; all of these are described
+ at more length in other documents.
+
+ The second section summarizes the special IPv6 address types and how
+ they relate to DNS. The third section describes observed DNS
+ implementation misbehaviors that have a varying effect on the use of
+ IPv6 records with DNS. The fourth section lists recommendations and
+ considerations for provisioning services with DNS. The fifth section
+ in turn looks at recommendations and considerations about providing
+ IPv6 support in the resolvers. The sixth and seventh sections
+ describe considerations with forward and reverse DNS updates,
+ respectively. The eighth section introduces several miscellaneous
+ IPv6 issues relating to DNS for which no better place has been found
+ in this memo. Appendix A looks briefly at the requirements for
+ unique local addressing. Appendix B discusses additional data.
+
+1.1. Representing IPv6 Addresses in DNS Records
+
+ In the forward zones, IPv6 addresses are represented using AAAA
+ records. In the reverse zones, IPv6 address are represented using
+ PTR records in the nibble format under the ip6.arpa. tree. See
+ [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
+ for background information.
+
+ In particular, one should note that the use of A6 records in the
+ forward tree or Bitlabels in the reverse tree is not recommended
+ [RFC3363]. Using DNAME records is not recommended in the reverse
+ tree in conjunction with A6 records; the document did not mean to
+ take a stance on any other use of DNAME records [RFC3364].
+
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 3]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+1.2. Independence of DNS Transport and DNS Records
+
+ DNS has been designed to present a single, globally unique name space
+ [RFC2826]. This property should be maintained, as described here and
+ in Section 1.3.
+
+ The IP version used to transport the DNS queries and responses is
+ independent of the records being queried: AAAA records can be queried
+ over IPv4, and A records over IPv6. The DNS servers must not make
+ any assumptions about what data to return for Answer and Authority
+ sections based on the underlying transport used in a query.
+
+ However, there is some debate whether the addresses in Additional
+ section could be selected or filtered using hints obtained from which
+ transport was being used; this has some obvious problems because in
+ many cases the transport protocol does not correlate with the
+ requests, and because a "bad" answer is in a way worse than no answer
+ at all (consider the case where the client is led to believe that a
+ name received in the additional record does not have any AAAA records
+ at all).
+
+ As stated in [RFC3596]:
+
+ The IP protocol version used for querying resource records is
+ independent of the protocol version of the resource records; e.g.,
+ IPv4 transport can be used to query IPv6 records and vice versa.
+
+1.3. Avoiding IPv4/IPv6 Name Space Fragmentation
+
+ To avoid the DNS name space from fragmenting into parts where some
+ parts of DNS are only visible using IPv4 (or IPv6) transport, the
+ recommendation is to always keep at least one authoritative server
+ IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
+ See DNS IPv6 transport guidelines [RFC3901] for more information.
+
+1.4. Query Type '*' and A/AAAA Records
+
+ QTYPE=* is typically only used for debugging or management purposes;
+ it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
+ any available RRsets, not *all* the RRsets, because the caches do not
+ necessarily have all the RRsets and have no way of guaranteeing that
+ they have all the RRsets. Therefore, to get both A and AAAA records
+ reliably, two separate queries must be made.
+
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 4]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+2. DNS Considerations about Special IPv6 Addresses
+
+ There are a couple of IPv6 address types that are somewhat special;
+ these are considered here.
+
+2.1. Limited-Scope Addresses
+
+ The IPv6 addressing architecture [RFC4291] includes two kinds of
+ local-use addresses: link-local (fe80::/10) and site-local
+ (fec0::/10). The site-local addresses have been deprecated [RFC3879]
+ but are discussed with unique local addresses in Appendix A.
+
+ Link-local addresses should never be published in DNS (whether in
+ forward or reverse tree), because they have only local (to the
+ connected link) significance [WIP-DC2005].
+
+2.2. Temporary Addresses
+
+ Temporary addresses defined in RFC 3041 [RFC3041] (sometimes called
+ "privacy addresses") use a random number as the interface identifier.
+ Having DNS AAAA records that are updated to always contain the
+ current value of a node's temporary address would defeat the purpose
+ of the mechanism and is not recommended. However, it would still be
+ possible to return a non-identifiable name (e.g., the IPv6 address in
+ hexadecimal format), as described in [RFC3041].
+
+2.3. 6to4 Addresses
+
+ 6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a
+ public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
+
+ If the reverse DNS population would be desirable (see Section 7.1 for
+ applicability), there are a number of possible ways to do so.
+
+ [WIP-H2005] aims to design an autonomous reverse-delegation system
+ that anyone being capable of communicating using a specific 6to4
+ address would be able to set up a reverse delegation to the
+ corresponding 6to4 prefix. This could be deployed by, e.g., Regional
+ Internet Registries (RIRs). This is a practical solution, but may
+ have some scalability concerns.
+
+2.4. Other Transition Mechanisms
+
+ 6to4 is mentioned as a case of an IPv6 transition mechanism requiring
+ special considerations. In general, mechanisms that include a
+ special prefix may need a custom solution; otherwise, for example,
+ when IPv4 address is embedded as the suffix or not embedded at all,
+ special solutions are likely not needed.
+
+
+
+Durand, et al. Informational [Page 5]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ Note that it does not seem feasible to provide reverse DNS with
+ another automatic tunneling mechanism, Teredo [RFC4380]; this is
+ because the IPv6 address is based on the IPv4 address and UDP port of
+ the current Network Address Translation (NAT) mapping, which is
+ likely to be relatively short-lived.
+
+3. Observed DNS Implementation Misbehavior
+
+ Several classes of misbehavior in DNS servers, load-balancers, and
+ resolvers have been observed. Most of these are rather generic, not
+ only applicable to IPv6 -- but in some cases, the consequences of
+ this misbehavior are extremely severe in IPv6 environments and
+ deserve to be mentioned.
+
+3.1. Misbehavior of DNS Servers and Load-balancers
+
+ There are several classes of misbehavior in certain DNS servers and
+ load-balancers that have been noticed and documented [RFC4074]: some
+ implementations silently drop queries for unimplemented DNS records
+ types, or provide wrong answers to such queries (instead of a proper
+ negative reply). While typically these issues are not limited to
+ AAAA records, the problems are aggravated by the fact that AAAA
+ records are being queried instead of (mainly) A records.
+
+ The problems are serious because when looking up a DNS name, typical
+ getaddrinfo() implementations, with AF_UNSPEC hint given, first try
+ to query the AAAA records of the name, and after receiving a
+ response, query the A records. This is done in a serial fashion --
+ if the first query is never responded to (instead of properly
+ returning a negative answer), significant time-outs will occur.
+
+ In consequence, this is an enormous problem for IPv6 deployments, and
+ in some cases, IPv6 support in the software has even been disabled
+ due to these problems.
+
+ The solution is to fix or retire those misbehaving implementations,
+ but that is likely not going to be effective. There are some
+ possible ways to mitigate the problem, e.g., by performing the
+ lookups somewhat in parallel and reducing the time-out as long as at
+ least one answer has been received, but such methods remain to be
+ investigated; slightly more on this is included in Section 5.
+
+3.2. Misbehavior of DNS Resolvers
+
+ Several classes of misbehavior have also been noticed in DNS
+ resolvers [WIP-LB2005]. However, these do not seem to directly
+ impair IPv6 use, and are only referred to for completeness.
+
+
+
+
+Durand, et al. Informational [Page 6]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+4. Recommendations for Service Provisioning Using DNS
+
+ When names are added in the DNS to facilitate a service, there are
+ several general guidelines to consider to be able to do it as
+ smoothly as possible.
+
+4.1. Use of Service Names instead of Node Names
+
+ It makes sense to keep information about separate services logically
+ separate in the DNS by using a different DNS hostname for each
+ service. There are several reasons for doing this, for example:
+
+ o It allows more flexibility and ease for migration of (only a part
+ of) services from one node to another,
+
+ o It allows configuring different properties (e.g., Time to Live
+ (TTL)) for each service, and
+
+ o It allows deciding separately for each service whether or not to
+ publish the IPv6 addresses (in cases where some services are more
+ IPv6-ready than others).
+
+ Using SRV records [RFC2782] would avoid these problems.
+ Unfortunately, those are not sufficiently widely used to be
+ applicable in most cases. Hence an operation technique is to use
+ service names instead of node names (or "hostnames"). This
+ operational technique is not specific to IPv6, but required to
+ understand the considerations described in Section 4.2 and
+ Section 4.3.
+
+ For example, assume a node named "pobox.example.com" provides both
+ SMTP and IMAP service. Instead of configuring the MX records to
+ point at "pobox.example.com", and configuring the mail clients to
+ look up the mail via IMAP from "pobox.example.com", one could use,
+ e.g., "smtp.example.com" for SMTP (for both message submission and
+ mail relaying between SMTP servers) and "imap.example.com" for IMAP.
+ Note that in the specific case of SMTP relaying, the server itself
+ must typically also be configured to know all its names to ensure
+ that loops do not occur. DNS can provide a layer of indirection
+ between service names and where the service actually is, and using
+ which addresses. (Obviously, when wanting to reach a specific node,
+ one should use the hostname rather than a service name.)
+
+
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 7]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+4.2. Separate vs. the Same Service Names for IPv4 and IPv6
+
+ The service naming can be achieved in basically two ways: when a
+ service is named "service.example.com" for IPv4, the IPv6-enabled
+ service could either be added to "service.example.com" or added
+ separately under a different name, e.g., in a sub-domain like
+ "service.ipv6.example.com".
+
+ These two methods have different characteristics. Using a different
+ name allows for easier service piloting, minimizing the disturbance
+ to the "regular" users of IPv4 service; however, the service would
+ not be used transparently, without the user/application explicitly
+ finding it and asking for it -- which would be a disadvantage in most
+ cases. When the different name is under a sub-domain, if the
+ services are deployed within a restricted network (e.g., inside an
+ enterprise), it's possible to prefer them transparently, at least to
+ a degree, by modifying the DNS search path; however, this is a
+ suboptimal solution. Using the same service name is the "long-term"
+ solution, but may degrade performance for those clients whose IPv6
+ performance is lower than IPv4, or does not work as well (see
+ Section 4.3 for more).
+
+ In most cases, it makes sense to pilot or test a service using
+ separate service names, and move to the use of the same name when
+ confident enough that the service level will not degrade for the
+ users unaware of IPv6.
+
+4.3. Adding the Records Only When Fully IPv6-enabled
+
+ The recommendation is that AAAA records for a service should not be
+ added to the DNS until all of following are true:
+
+ 1. The address is assigned to the interface on the node.
+
+ 2. The address is configured on the interface.
+
+ 3. The interface is on a link that is connected to the IPv6
+ infrastructure.
+
+ In addition, if the AAAA record is added for the node, instead of
+ service as recommended, all the services of the node should be IPv6-
+ enabled prior to adding the resource record.
+
+ For example, if an IPv6 node is isolated from an IPv6 perspective
+ (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
+ that it should not have an address in the DNS.
+
+
+
+
+
+Durand, et al. Informational [Page 8]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ Consider the case of two dual-stack nodes, which both are IPv6-
+ enabled, but the server does not have (global) IPv6 connectivity. As
+ the client looks up the server's name, only A records are returned
+ (if the recommendations above are followed), and no IPv6
+ communication, which would have been unsuccessful, is even attempted.
+
+ The issues are not always so black-and-white. Usually, it's
+ important that the service offered using both protocols is of roughly
+ equal quality, using the appropriate metrics for the service (e.g.,
+ latency, throughput, low packet loss, general reliability, etc.).
+ This is typically very important especially for interactive or real-
+ time services. In many cases, the quality of IPv6 connectivity may
+ not yet be equal to that of IPv4, at least globally; this has to be
+ taken into consideration when enabling services.
+
+4.4. The Use of TTL for IPv4 and IPv6 RRs
+
+ The behavior of DNS caching when different TTL values are used for
+ different RRsets of the same name calls for explicit discussion. For
+ example, let's consider two unrelated zone fragments:
+
+ example.com. 300 IN MX foo.example.com.
+ foo.example.com. 300 IN A 192.0.2.1
+ foo.example.com. 100 IN AAAA 2001:db8::1
+
+ ...
+
+ child.example.com. 300 IN NS ns.child.example.com.
+ ns.child.example.com. 300 IN A 192.0.2.1
+ ns.child.example.com. 100 IN AAAA 2001:db8::1
+
+ In the former case, we have "courtesy" additional data; in the
+ latter, we have "critical" additional data. See more extensive
+ background discussion of additional data handling in Appendix B.
+
+4.4.1. TTL with Courtesy Additional Data
+
+ When a caching resolver asks for the MX record of example.com, it
+ gets back "foo.example.com". It may also get back either one or both
+ of the A and AAAA records in the additional section. The resolver
+ must explicitly query for both A and AAAA records [RFC2821].
+
+ After 100 seconds, the AAAA record is removed from the cache(s)
+ because its TTL expired. It could be argued to be useful for the
+ caching resolvers to discard the A record when the shorter TTL (in
+ this case, for the AAAA record) expires; this would avoid the
+ situation where there would be a window of 200 seconds when
+ incomplete information is returned from the cache. Further argument
+
+
+
+Durand, et al. Informational [Page 9]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ for discarding is that in the normal operation, the TTL values are so
+ high that very likely the incurred additional queries would not be
+ noticeable, compared to the obtained performance optimization. The
+ behavior in this scenario is unspecified.
+
+4.4.2. TTL with Critical Additional Data
+
+ The difference to courtesy additional data is that the A/AAAA records
+ served by the parent zone cannot be queried explicitly. Therefore,
+ after 100 seconds the AAAA record is removed from the cache(s), but
+ the A record remains. Queries for the remaining 200 seconds
+ (provided that there are no further queries from the parent that
+ could refresh the caches) only return the A record, leading to a
+ potential operational situation with unreachable servers.
+
+ Similar cache flushing strategies apply in this scenario; the
+ behavior is likewise unspecified.
+
+4.5. IPv6 Transport Guidelines for DNS Servers
+
+ As described in Section 1.3 and [RFC3901], there should continue to
+ be at least one authoritative IPv4 DNS server for every zone, even if
+ the zone has only IPv6 records. (Note that obviously, having more
+ servers with robust connectivity would be preferable, but this is the
+ minimum recommendation; also see [RFC2182].)
+
+5. Recommendations for DNS Resolver IPv6 Support
+
+ When IPv6 is enabled on a node, there are several things to consider
+ to ensure that the process is as smooth as possible.
+
+5.1. DNS Lookups May Query IPv6 Records Prematurely
+
+ The system library that implements the getaddrinfo() function for
+ looking up names is a critical piece when considering the robustness
+ of enabling IPv6; it may come in basically three flavors:
+
+ 1. The system library does not know whether IPv6 has been enabled in
+ the kernel of the operating system: it may start looking up AAAA
+ records with getaddrinfo() and AF_UNSPEC hint when the system is
+ upgraded to a system library version that supports IPv6.
+
+ 2. The system library might start to perform IPv6 queries with
+ getaddrinfo() only when IPv6 has been enabled in the kernel.
+ However, this does not guarantee that there exists any useful
+ IPv6 connectivity (e.g., the node could be isolated from the
+ other IPv6 networks, only having link-local addresses).
+
+
+
+
+Durand, et al. Informational [Page 10]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ 3. The system library might implement a toggle that would apply some
+ heuristics to the "IPv6-readiness" of the node before starting to
+ perform queries; for example, it could check whether only link-
+ local IPv6 address(es) exists, or if at least one global IPv6
+ address exists.
+
+ First, let us consider generic implications of unnecessary queries
+ for AAAA records: when looking up all the records in the DNS, AAAA
+ records are typically tried first, and then A records. These are
+ done in serial, and the A query is not performed until a response is
+ received to the AAAA query. Considering the misbehavior of DNS
+ servers and load-balancers, as described in Section 3.1, the lookup
+ delay for AAAA may incur additional unnecessary latency, and
+ introduce a component of unreliability.
+
+ One option here could be to do the queries partially in parallel; for
+ example, if the final response to the AAAA query is not received in
+ 0.5 seconds, start performing the A query while waiting for the
+ result. (Immediate parallelism might not be optimal, at least
+ without information-sharing between the lookup threads, as that would
+ probably lead to duplicate non-cached delegation chain lookups.)
+
+ An additional concern is the address selection, which may, in some
+ circumstances, prefer AAAA records over A records even when the node
+ does not have any IPv6 connectivity [WIP-RDP2004]. In some cases,
+ the implementation may attempt to connect or send a datagram on a
+ physical link [WIP-R2006], incurring very long protocol time-outs,
+ instead of quickly falling back to IPv4.
+
+ Now, we can consider the issues specific to each of the three
+ possibilities:
+
+ In the first case, the node performs a number of completely useless
+ DNS lookups as it will not be able to use the returned AAAA records
+ anyway. (The only exception is where the application desires to know
+ what's in the DNS, but not use the result for communication.) One
+ should be able to disable these unnecessary queries, for both latency
+ and reliability reasons. However, as IPv6 has not been enabled, the
+ connections to IPv6 addresses fail immediately, and if the
+ application is programmed properly, the application can fall
+ gracefully back to IPv4 [RFC4038].
+
+ The second case is similar to the first, except it happens to a
+ smaller set of nodes when IPv6 has been enabled but connectivity has
+ not been provided yet. Similar considerations apply, with the
+ exception that IPv6 records, when returned, will be actually tried
+ first, which may typically lead to long time-outs.
+
+
+
+
+Durand, et al. Informational [Page 11]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ The third case is a bit more complex: optimizing away the DNS lookups
+ with only link-locals is probably safe (but may be desirable with
+ different lookup services that getaddrinfo() may support), as the
+ link-locals are typically automatically generated when IPv6 is
+ enabled, and do not indicate any form of IPv6 connectivity. That is,
+ performing DNS lookups only when a non-link-local address has been
+ configured on any interface could be beneficial -- this would be an
+ indication that the address has been configured either from a router
+ advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+ [RFC3315], or manually. Each would indicate at least some form of
+ IPv6 connectivity, even though there would not be guarantees of it.
+
+ These issues should be analyzed at more depth, and the fixes found
+ consensus on, perhaps in a separate document.
+
+5.2. Obtaining a List of DNS Recursive Resolvers
+
+ In scenarios where DHCPv6 is available, a host can discover a list of
+ DNS recursive resolvers through the DHCPv6 "DNS Recursive Name
+ Server" option [RFC3646]. This option can be passed to a host
+ through a subset of DHCPv6 [RFC3736].
+
+ The IETF is considering the development of alternative mechanisms for
+ obtaining the list of DNS recursive name servers when DHCPv6 is
+ unavailable or inappropriate. No decision about taking on this
+ development work has been reached as of this writing [RFC4339].
+
+ In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
+ under consideration for development include the use of [WIP-O2004]
+ and the use of Router Advertisements to convey the information
+ [WIP-J2006].
+
+ Note that even though IPv6 DNS resolver discovery is a recommended
+ procedure, it is not required for dual-stack nodes in dual-stack
+ networks as IPv6 DNS records can be queried over IPv4 as well as
+ IPv6. Obviously, nodes that are meant to function without manual
+ configuration in IPv6-only networks must implement the DNS resolver
+ discovery function.
+
+5.3. IPv6 Transport Guidelines for Resolvers
+
+ As described in Section 1.3 and [RFC3901], the recursive resolvers
+ should be IPv4-only or dual-stack to be able to reach any IPv4-only
+ DNS server. Note that this requirement is also fulfilled by an IPv6-
+ only stub resolver pointing to a dual-stack recursive DNS resolver.
+
+
+
+
+
+
+Durand, et al. Informational [Page 12]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+6. Considerations about Forward DNS Updating
+
+ While the topic of how to enable updating the forward DNS, i.e., the
+ mapping from names to the correct new addresses, is not specific to
+ IPv6, it should be considered especially due to the advent of
+ Stateless Address Autoconfiguration [RFC2462].
+
+ Typically, forward DNS updates are more manageable than doing them in
+ the reverse DNS, because the updater can often be assumed to "own" a
+ certain DNS name -- and we can create a form of security relationship
+ with the DNS name and the node that is allowed to update it to point
+ to a new address.
+
+ A more complex form of DNS updates -- adding a whole new name into a
+ DNS zone, instead of updating an existing name -- is considered out
+ of scope for this memo as it could require zone-wide authentication.
+ Adding a new name in the forward zone is a problem that is still
+ being explored with IPv4, and IPv6 does not seem to add much new in
+ that area.
+
+6.1. Manual or Custom DNS Updates
+
+ The DNS mappings can also be maintained by hand, in a semi-automatic
+ fashion or by running non-standardized protocols. These are not
+ considered at more length in this memo.
+
+6.2. Dynamic DNS
+
+ Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
+ mechanism for dynamically updating the DNS. It works equally well
+ with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual
+ address configuration. It is important to consider how each of these
+ behave if IP address-based authentication, instead of stronger
+ mechanisms [RFC3007], was used in the updates.
+
+ 1. Manual addresses are static and can be configured.
+
+ 2. DHCPv6 addresses could be reasonably static or dynamic, depending
+ on the deployment, and could or could not be configured on the
+ DNS server for the long term.
+
+ 3. SLAAC addresses are typically stable for a long time, but could
+ require work to be configured and maintained.
+
+ As relying on IP addresses for Dynamic DNS is rather insecure at
+ best, stronger authentication should always be used; however, this
+ requires that the authorization keying will be explicitly configured
+ using unspecified operational methods.
+
+
+
+Durand, et al. Informational [Page 13]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ Note that with DHCP it is also possible that the DHCP server updates
+ the DNS, not the host. The host might only indicate in the DHCP
+ exchange which hostname it would prefer, and the DHCP server would
+ make the appropriate updates. Nonetheless, while this makes setting
+ up a secure channel between the updater and the DNS server easier, it
+ does not help much with "content" security, i.e., whether the
+ hostname was acceptable -- if the DNS server does not include
+ policies, they must be included in the DHCP server (e.g., a regular
+ host should not be able to state that its name is "www.example.com").
+ DHCP-initiated DDNS updates have been extensively described in
+ [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b].
+
+ The nodes must somehow be configured with the information about the
+ servers where they will attempt to update their addresses, sufficient
+ security material for authenticating themselves to the server, and
+ the hostname they will be updating. Unless otherwise configured, the
+ first could be obtained by looking up the authoritative name servers
+ for the hostname; the second must be configured explicitly unless one
+ chooses to trust the IP address-based authentication (not a good
+ idea); and lastly, the nodename is typically pre-configured somehow
+ on the node, e.g., at install time.
+
+ Care should be observed when updating the addresses not to use longer
+ TTLs for addresses than are preferred lifetimes for the addresses, so
+ that if the node is renumbered in a managed fashion, the amount of
+ stale DNS information is kept to the minimum. That is, if the
+ preferred lifetime of an address expires, the TTL of the record needs
+ to be modified unless it was already done before the expiration. For
+ better flexibility, the DNS TTL should be much shorter (e.g., a half
+ or a third) than the lifetime of an address; that way, the node can
+ start lowering the DNS TTL if it seems like the address has not been
+ renewed/refreshed in a while. Some discussion on how an
+ administrator could manage the DNS TTL is included in [RFC4192]; this
+ could be applied to (smart) hosts as well.
+
+7. Considerations about Reverse DNS Updating
+
+ Updating the reverse DNS zone may be difficult because of the split
+ authority over an address. However, first we have to consider the
+ applicability of reverse DNS in the first place.
+
+7.1. Applicability of Reverse DNS
+
+ Today, some applications use reverse DNS either to look up some hints
+ about the topological information associated with an address (e.g.,
+ resolving web server access logs) or (as a weak form of a security
+ check) to get a feel whether the user's network administrator has
+
+
+
+
+Durand, et al. Informational [Page 14]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ "authorized" the use of the address (on the premise that adding a
+ reverse record for an address would signal some form of
+ authorization).
+
+ One additional, maybe slightly more useful usage is ensuring that the
+ reverse and forward DNS contents match (by looking up the pointer to
+ the name by the IP address from the reverse tree, and ensuring that a
+ record under the name in the forward tree points to the IP address)
+ and correspond to a configured name or domain. As a security check,
+ it is typically accompanied by other mechanisms, such as a user/
+ password login; the main purpose of the reverse+forward DNS check is
+ to weed out the majority of unauthorized users, and if someone
+ managed to bypass the checks, he would still need to authenticate
+ "properly".
+
+ It may also be desirable to store IPsec keying material corresponding
+ to an IP address in the reverse DNS, as justified and described in
+ [RFC4025].
+
+ It is not clear whether it makes sense to require or recommend that
+ reverse DNS records be updated. In many cases, it would just make
+ more sense to use proper mechanisms for security (or topological
+ information lookup) in the first place. At minimum, the applications
+ that use it as a generic authorization (in the sense that a record
+ exists at all) should be modified as soon as possible to avoid such
+ lookups completely.
+
+ The applicability is discussed at more length in [WIP-S2005c].
+
+7.2. Manual or Custom DNS Updates
+
+ Reverse DNS can of course be updated using manual or custom methods.
+ These are not further described here, except for one special case.
+
+ One way to deploy reverse DNS would be to use wildcard records, for
+ example, by configuring one name for a subnet (/64) or a site (/48).
+ As a concrete example, a site (or the site's ISP) could configure the
+ reverses of the prefix 2001:db8:f00::/48 to point to one name using a
+ wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
+ site.example.com.". Naturally, such a name could not be verified
+ from the forward DNS, but would at least provide some form of
+ "topological information" or "weak authorization" if that is really
+ considered to be useful. Note that this is not actually updating the
+ DNS as such, as the whole point is to avoid DNS updates completely by
+ manually configuring a generic name.
+
+
+
+
+
+
+Durand, et al. Informational [Page 15]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+7.3. DDNS with Stateless Address Autoconfiguration
+
+ Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
+ some regard, while being more difficult in another, as described
+ below.
+
+ The address space administrator decides whether or not the hosts are
+ trusted to update their reverse DNS records. If they are trusted and
+ deployed at the same site (e.g., not across the Internet), a simple
+ address-based authorization is typically sufficient (i.e., check that
+ the DNS update is done from the same IP address as the record being
+ updated); stronger security can also be used [RFC3007]. If they
+ aren't allowed to update the reverses, no update can occur. However,
+ such address-based update authorization operationally requires that
+ ingress filtering [RFC3704] has been set up at the border of the site
+ where the updates occur, and as close to the updater as possible.
+
+ Address-based authorization is simpler with reverse DNS (as there is
+ a connection between the record and the address) than with forward
+ DNS. However, when a stronger form of security is used, forward DNS
+ updates are simpler to manage because the host can be assumed to have
+ an association with the domain. Note that the user may roam to
+ different networks and does not necessarily have any association with
+ the owner of that address space. So, assuming a stronger form of
+ authorization for reverse DNS updates than an address association is
+ generally infeasible.
+
+ Moreover, the reverse zones must be cleaned up by an unspecified
+ janitorial process: the node does not typically know a priori that it
+ will be disconnected, and it cannot send a DNS update using the
+ correct source address to remove a record.
+
+ A problem with defining the clean-up process is that it is difficult
+ to ensure that a specific IP address and the corresponding record are
+ no longer being used. Considering the huge address space, and the
+ unlikelihood of collision within 64 bits of the interface
+ identifiers, a process that would remove the record after no traffic
+ has been seen from a node in a long period of time (e.g., a month or
+ year) might be one possible approach.
+
+ To insert or update the record, the node must discover the DNS server
+ to send the update to somehow, similar to as discussed in
+ Section 6.2. One way to automate this is looking up the DNS server
+ authoritative (e.g., through SOA record) for the IP address being
+ updated, but the security material (unless the IP address-based
+ authorization is trusted) must also be established by some other
+ means.
+
+
+
+
+Durand, et al. Informational [Page 16]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ One should note that Cryptographically Generated Addresses (CGAs)
+ [RFC3972] may require a slightly different kind of treatment. CGAs
+ are addresses where the interface identifier is calculated from a
+ public key, a modifier (used as a nonce), the subnet prefix, and
+ other data. Depending on the usage profile, CGAs might or might not
+ be changed periodically due to, e.g., privacy reasons. As the CGA
+ address is not predictable, a reverse record can only reasonably be
+ inserted in the DNS by the node that generates the address.
+
+7.4. DDNS with DHCP
+
+ With DHCPv4, the reverse DNS name is typically already inserted to
+ the DNS that reflects the name (e.g., "dhcp-67.example.com"). One
+ can assume similar practice may become commonplace with DHCPv6 as
+ well; all such mappings would be pre-configured and would require no
+ updating.
+
+ If a more explicit control is required, similar considerations as
+ with SLAAC apply, except for the fact that typically one must update
+ a reverse DNS record instead of inserting one (if an address
+ assignment policy that reassigns disused addresses is adopted) and
+ updating a record seems like a slightly more difficult thing to
+ secure. However, it is yet uncertain how DHCPv6 is going to be used
+ for address assignment.
+
+ Note that when using DHCP, either the host or the DHCP server could
+ perform the DNS updates; see the implications in Section 6.2.
+
+ If disused addresses were to be reassigned, host-based DDNS reverse
+ updates would need policy considerations for DNS record modification,
+ as noted above. On the other hand, if disused address were not to be
+ assigned, host-based DNS reverse updates would have similar
+ considerations as SLAAC in Section 7.3. Server-based updates have
+ similar properties except that the janitorial process could be
+ integrated with DHCP address assignment.
+
+7.5. DDNS with Dynamic Prefix Delegation
+
+ In cases where a prefix, instead of an address, is being used and
+ updated, one should consider what is the location of the server where
+ DDNS updates are made. That is, where the DNS server is located:
+
+ 1. At the same organization as the prefix delegator.
+
+ 2. At the site where the prefixes are delegated to. In this case,
+ the authority of the DNS reverse zone corresponding to the
+ delegated prefix is also delegated to the site.
+
+
+
+
+Durand, et al. Informational [Page 17]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ 3. Elsewhere; this implies a relationship between the site and where
+ the DNS server is located, and such a relationship should be
+ rather straightforward to secure as well. Like in the previous
+ case, the authority of the DNS reverse zone is also delegated.
+
+ In the first case, managing the reverse DNS (delegation) is simpler
+ as the DNS server and the prefix delegator are in the same
+ administrative domain (as there is no need to delegate anything at
+ all); alternatively, the prefix delegator might forgo DDNS reverse
+ capability altogether, and use, e.g., wildcard records (as described
+ in Section 7.2). In the other cases, it can be slightly more
+ difficult, particularly as the site will have to configure the DNS
+ server to be authoritative for the delegated reverse zone, implying
+ automatic configuration of the DNS server -- as the prefix may be
+ dynamic.
+
+ Managing the DDNS reverse updates is typically simple in the second
+ case, as the updated server is located at the local site, and
+ arguably IP address-based authentication could be sufficient (or if
+ not, setting up security relationships would be simpler). As there
+ is an explicit (security) relationship between the parties in the
+ third case, setting up the security relationships to allow reverse
+ DDNS updates should be rather straightforward as well (but IP
+ address-based authentication might not be acceptable). In the first
+ case, however, setting up and managing such relationships might be a
+ lot more difficult.
+
+8. Miscellaneous DNS Considerations
+
+ This section describes miscellaneous considerations about DNS that
+ seem related to IPv6, for which no better place has been found in
+ this document.
+
+8.1. NAT-PT with DNS-ALG
+
+ The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look
+ like AAAA records to the IPv6-only nodes. Numerous problems have
+ been identified with [WIP-AD2005]. This is a strong reason not to
+ use NAT-PT in the first place.
+
+8.2. Renumbering Procedures and Applications' Use of DNS
+
+ One of the most difficult problems of systematic IP address
+ renumbering procedures [RFC4192] is that an application that looks up
+ a DNS name disregards information such as TTL, and uses the result
+ obtained from DNS as long as it happens to be stored in the memory of
+ the application. For applications that run for a long time, this
+
+
+
+
+Durand, et al. Informational [Page 18]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ could be days, weeks, or even months. Some applications may be
+ clever enough to organize the data structures and functions in such a
+ manner that lookups get refreshed now and then.
+
+ While the issue appears to have a clear solution, "fix the
+ applications", practically, this is not reasonable immediate advice.
+ The TTL information is not typically available in the APIs and
+ libraries (so, the advice becomes "fix the applications, APIs, and
+ libraries"), and a lot more analysis is needed on how to practically
+ go about to achieve the ultimate goal of avoiding using the names
+ longer than expected.
+
+9. Acknowledgements
+
+ Some recommendations (Section 4.3, Section 5.1) about IPv6 service
+ provisioning were moved here from [RFC4213] by Erik Nordmark and Bob
+ Gilligan. Havard Eidnes and Michael Patton provided useful feedback
+ and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark
+ Andrews helped in clarifying the issues regarding additional data and
+ the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei
+ Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided
+ useful feedback during the WG last call. Thomas Narten provided
+ extensive feedback during the IESG evaluation.
+
+10. Security Considerations
+
+ This document reviews the operational procedures for IPv6 DNS
+ operations and does not have security considerations in itself.
+
+ However, it is worth noting that in particular with Dynamic DNS
+ updates, security models based on the source address validation are
+ very weak and cannot be recommended -- they could only be considered
+ in the environments where ingress filtering [RFC3704] has been
+ deployed. On the other hand, it should be noted that setting up an
+ authorization mechanism (e.g., a shared secret, or public-private
+ keys) between a node and the DNS server has to be done manually, and
+ may require quite a bit of time and expertise.
+
+ To re-emphasize what was already stated, the reverse+forward DNS
+ check provides very weak security at best, and the only
+ (questionable) security-related use for them may be in conjunction
+ with other mechanisms when authenticating a user.
+
+
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 19]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+11. References
+
+11.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS
+ UPDATE)", RFC 2136, April 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton,
+ "Selection and Operation of Secondary DNS Servers",
+ BCP 16, RFC 2182, July 1997.
+
+ [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+ RFC 2671, August 1999.
+
+ [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+ April 2001.
+
+ [RFC3007] Wellington, B., "Secure Domain Name System (DNS)
+ Dynamic Update", RFC 3007, November 2000.
+
+ [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
+ Stateless Address Autoconfiguration in IPv6", RFC 3041,
+ January 2001.
+
+ [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+ via IPv4 Clouds", RFC 3056, February 2001.
+
+ [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+ August 2001.
+
+ [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+ and M. Carney, "Dynamic Host Configuration Protocol for
+ IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+ [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+ Hain, "Representing Internet Protocol version 6 (IPv6)
+ Addresses in the Domain Name System (DNS)", RFC 3363,
+ August 2002.
+
+
+
+Durand, et al. Informational [Page 20]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
+ Support for Internet Protocol version 6 (IPv6)",
+ RFC 3364, August 2002.
+
+ [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IP Version 6", RFC 3596,
+ October 2003.
+
+ [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
+ Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+ December 2003.
+
+ [RFC3736] Droms, R., "Stateless Dynamic Host Configuration
+ Protocol (DHCP) Service for IPv6", RFC 3736,
+ April 2004.
+
+ [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
+ Addresses", RFC 3879, September 2004.
+
+ [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport
+ Operational Guidelines", BCP 91, RFC 3901,
+ September 2004.
+
+ [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+ Castro, "Application Aspects of IPv6 Transition",
+ RFC 4038, March 2005.
+
+ [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior
+ Against DNS Queries for IPv6 Addresses", RFC 4074,
+ May 2005.
+
+ [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
+ Renumbering an IPv6 Network without a Flag Day",
+ RFC 4192, September 2005.
+
+ [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", RFC 4193, October 2005.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
+ Information Approaches", RFC 4339, February 2006.
+
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 21]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+11.2. Informative References
+
+ [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
+ Translation - Protocol Translation (NAT-PT)", RFC 2766,
+ February 2000.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
+ for specifying the location of services (DNS SRV)",
+ RFC 2782, February 2000.
+
+ [RFC2826] Internet Architecture Board, "IAB Technical Comment on
+ the Unique DNS Root", RFC 2826, May 2000.
+
+ [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
+ Multihomed Networks", BCP 84, RFC 3704, March 2004.
+
+ [RFC3972] Aura, T., "Cryptographically Generated Addresses
+ (CGA)", RFC 3972, March 2005.
+
+ [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
+ Material in DNS", RFC 4025, March 2005.
+
+ [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
+ Mechanisms for IPv6 Hosts and Routers", RFC 4213,
+ October 2005.
+
+ [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
+ Generation Partnership Project (3GPP) Networks",
+ RFC 4215, October 2005.
+
+ [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+ Network Address Translations (NATs)", RFC 4380,
+ February 2006.
+
+ [TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit
+ handling and additional data" on DNSEXT mailing list,
+ Message-
+ Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August
+ 1, 2005, .
+
+ [WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
+ Experimental", Work in Progress, October 2005.
+
+ [WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to
+ publish, that is the question", Work in Progress,
+ October 2005.
+
+
+
+
+Durand, et al. Informational [Page 22]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ [WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation
+ Specification", Work in Progress, November 2005.
+
+ [WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS
+ Configuration", Work in Progress, January 2006.
+
+ [WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution
+ Misbehavior", Work in Progress, February 2006.
+
+ [WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in
+ Progress, February 2004.
+
+ [WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
+ Considered Harmful", Work in Progress, January 2006.
+
+ [WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual
+ Stack IPv6 on by Default", Work in Progress, July 2004.
+
+ [WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in
+ Progress, March 2006.
+
+ [WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information
+ (DHCID RR)", Work in Progress, March 2006.
+
+ [WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR
+ Mapping", Work in Progress, August 2005.
+
+ [WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts
+ among DHCP Clients", Work in Progress, March 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 23]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+Appendix A. Unique Local Addressing Considerations for DNS
+
+ Unique local addresses [RFC4193] have replaced the now-deprecated
+ site-local addresses [RFC3879]. From the perspective of the DNS, the
+ locally generated unique local addresses (LUL) and site-local
+ addresses have similar properties.
+
+ The interactions with DNS come in two flavors: forward and reverse
+ DNS.
+
+ To actually use local addresses within a site, this implies the
+ deployment of a "split-faced" or a fragmented DNS name space, for the
+ zones internal to the site, and the outsiders' view to it. The
+ procedures to achieve this are not elaborated here. The implication
+ is that local addresses must not be published in the public DNS.
+
+ To facilitate reverse DNS (if desired) with local addresses, the stub
+ resolvers must look for DNS information from the local DNS servers,
+ not, e.g., starting from the root servers, so that the local
+ information may be provided locally. Note that the experience of
+ private addresses in IPv4 has shown that the root servers get loaded
+ for requests for private address lookups in any case. This
+ requirement is discussed in [RFC4193].
+
+Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments
+
+ DNS responses do not always fit in a single UDP packet. We'll
+ examine the cases that happen when this is due to too much data in
+ the Additional section.
+
+B.1. Description of Additional Data Scenarios
+
+ There are two kinds of additional data:
+
+ 1. "critical" additional data; this must be included in all
+ scenarios, with all the RRsets, and
+
+ 2. "courtesy" additional data; this could be sent in full, with only
+ a few RRsets, or with no RRsets, and can be fetched separately as
+ well, but at the cost of additional queries.
+
+ The responding server can algorithmically determine which type the
+ additional data is by checking whether it's at or below a zone cut.
+
+ Only those additional data records (even if sometimes carelessly
+ termed "glue") are considered "critical" or real "glue" if and only
+ if they meet the above-mentioned condition, as specified in Section
+ 4.2.1 of [RFC1034].
+
+
+
+Durand, et al. Informational [Page 24]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+ Remember that resource record sets (RRsets) are never "broken up", so
+ if a name has 4 A records and 5 AAAA records, you can either return
+ all 9, all 4 A records, all 5 AAAA records, or nothing. In
+ particular, notice that for the "critical" additional data getting
+ all the RRsets can be critical.
+
+ In particular, [RFC2181] specifies (in Section 9) that:
+
+ a. if all the "critical" RRsets do not fit, the sender should set
+ the TC bit, and the recipient should discard the whole response
+ and retry using mechanism allowing larger responses such as TCP.
+
+ b. "courtesy" additional data should not cause the setting of the TC
+ bit, but instead all the non-fitting additional data RRsets
+ should be removed.
+
+ An example of the "courtesy" additional data is A/AAAA records in
+ conjunction with MX records as shown in Section 4.4; an example of
+ the "critical" additional data is shown below (where getting both the
+ A and AAAA RRsets is critical with respect to the NS RR):
+
+ child.example.com. IN NS ns.child.example.com.
+ ns.child.example.com. IN A 192.0.2.1
+ ns.child.example.com. IN AAAA 2001:db8::1
+
+ When there is too much "courtesy" additional data, at least the non-
+ fitting RRsets should be removed [RFC2181]; however, as the
+ additional data is not critical, even all of it could be safely
+ removed.
+
+ When there is too much "critical" additional data, TC bit will have
+ to be set, and the recipient should ignore the response and retry
+ using TCP; if some data were to be left in the UDP response, the
+ issue is which data could be retained.
+
+ However, the practice may differ from the specification. Testing and
+ code analysis of three recent implementations [TC-TEST] confirm this.
+ None of the tested implementations have a strict separation of
+ critical and courtesy additional data, while some forms of additional
+ data may be treated preferably. All the implementations remove some
+ (critical or courtesy) additional data RRsets without setting the TC
+ bit if the response would not otherwise fit.
+
+ Failing to discard the response with the TC bit or omitting critical
+ information but not setting the TC bit lead to an unrecoverable
+ problem. Omitting only some of the RRsets if all would not fit (but
+ not setting the TC bit) leads to a performance problem. These are
+ discussed in the next two subsections.
+
+
+
+Durand, et al. Informational [Page 25]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+B.2. Which Additional Data to Keep, If Any?
+
+ NOTE: omitting some critical additional data instead of setting the
+ TC bit violates a 'should' in Section 9 of RFC2181. However, as many
+ implementations still do that [TC-TEST], operators need to understand
+ its implications, and we describe that behavior as well.
+
+ If the implementation decides to keep as much data (whether
+ "critical" or "courtesy") as possible in the UDP responses, it might
+ be tempting to use the transport of the DNS query as a hint in either
+ of these cases: return the AAAA records if the query was done over
+ IPv6, or return the A records if the query was done over IPv4.
+ However, this breaks the model of independence of DNS transport and
+ resource records, as noted in Section 1.2.
+
+ With courtesy additional data, as long as enough RRsets will be
+ removed so that TC will not be set, it is allowed to send as many
+ complete RRsets as the implementations prefers. However, the
+ implementations are also free to omit all such RRsets, even if
+ complete. Omitting all the RRsets (when removing only some would
+ suffice) may create a performance penalty, whereby the client may
+ need to issue one or more additional queries to obtain necessary
+ and/or consistent information.
+
+ With critical additional data, the alternatives are either returning
+ nothing (and absolutely requiring a retry with TCP) or returning
+ something (working also in the case if the recipient does not discard
+ the response and retry using TCP) in addition to setting the TC bit.
+ If the process for selecting "something" from the critical data would
+ otherwise be practically "flipping the coin" between A and AAAA
+ records, it could be argued that if one looked at the transport of
+ the query, it would have a larger possibility of being right than
+ just 50/50. In other words, if the returned critical additional data
+ would have to be selected somehow, using something more sophisticated
+ than a random process would seem justifiable.
+
+ That is, leaving in some intelligently selected critical additional
+ data is a trade-off between creating an optimization for those
+ resolvers that ignore the "should discard" recommendation and causing
+ a protocol problem by propagating inconsistent information about
+ "critical" records in the caches.
+
+ Similarly, leaving in the complete courtesy additional data RRsets
+ instead of removing all the RRsets is a performance trade-off as
+ described in the next section.
+
+
+
+
+
+
+Durand, et al. Informational [Page 26]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+B.3. Discussion of the Potential Problems
+
+ As noted above, the temptation for omitting only some of the
+ additional data could be problematic. This is discussed more below.
+
+ For courtesy additional data, this causes a potential performance
+ problem as this requires that the clients issue re-queries for the
+ potentially omitted RRsets. For critical additional data, this
+ causes a potential unrecoverable problem if the response is not
+ discarded and the query not re-tried with TCP, as the nameservers
+ might be reachable only through the omitted RRsets.
+
+ If an implementation would look at the transport used for the query,
+ it is worth remembering that often the host using the records is
+ different from the node requesting them from the authoritative DNS
+ server (or even a caching resolver). So, whichever version the
+ requestor (e.g., a recursive server in the middle) uses makes no
+ difference to the ultimate user of the records, whose transport
+ capabilities might differ from those of the requestor. This might
+ result in, e.g., inappropriately returning A records to an IPv6-only
+ node, going through a translation, or opening up another IP-level
+ session (e.g., a Packet Data Protocol (PDP) context [RFC4215]).
+ Therefore, at least in many scenarios, it would be very useful if the
+ information returned would be consistent and complete -- or if that
+ is not feasible, leave it to the client to query again.
+
+ The problem of too much additional data seems to be an operational
+ one: the zone administrator entering too many records that will be
+ returned truncated (or missing some RRsets, depending on
+ implementations) to the users. A protocol fix for this is using
+ Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity
+ for larger UDP packet sizes, pushing up the relevant threshold.
+ Further, DNS server implementations should omit courtesy additional
+ data completely rather than including only some RRsets [RFC2181]. An
+ operational fix for this is having the DNS server implementations
+ return a warning when the administrators create zones that would
+ result in too much additional data being returned. Further, DNS
+ server implementations should warn of or disallow such zone
+ configurations that are recursive or otherwise difficult to manage by
+ the protocol.
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 27]
+
+RFC 4472 Considerations with IPv6 DNS April 2006
+
+
+Authors' Addresses
+
+ Alain Durand
+ Comcast
+ 1500 Market St.
+ Philadelphia, PA 19102
+ USA
+
+ EMail: Alain_Durand@cable.comcast.com
+
+
+ Johan Ihren
+ Autonomica
+ Bellmansgatan 30
+ SE-118 47 Stockholm
+ Sweden
+
+ EMail: johani@autonomica.se
+
+
+ Pekka Savola
+ CSC/FUNET
+ Espoo
+ Finland
+
+ EMail: psavola@funet.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 28]
+
+RFC 4472 Considerations with IPv6 DNS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Durand, et al. Informational [Page 29]
+
diff --git a/doc/rfc/rfc4697.txt b/doc/rfc/rfc4697.txt
new file mode 100644
index 0000000000..773507ca69
--- /dev/null
+++ b/doc/rfc/rfc4697.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group M. Larson
+Request for Comments: 4697 P. Barber
+BCP: 123 VeriSign, Inc.
+Category: Best Current Practice October 2006
+
+
+ Observed DNS Resolution Misbehavior
+
+Status of This Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This memo describes DNS iterative resolver behavior that results in a
+ significant query volume sent to the root and top-level domain (TLD)
+ name servers. We offer implementation advice to iterative resolver
+ developers to alleviate these unnecessary queries. The
+ recommendations made in this document are a direct byproduct of
+ observation and analysis of abnormal query traffic patterns seen at
+ two of the thirteen root name servers and all thirteen com/net TLD
+ name servers.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. A Note about Terminology in this Memo ......................3
+ 1.2. Key Words ..................................................3
+ 2. Observed Iterative Resolver Misbehavior .........................3
+ 2.1. Aggressive Requerying for Delegation Information ...........3
+ 2.1.1. Recommendation ......................................5
+ 2.2. Repeated Queries to Lame Servers ...........................6
+ 2.2.1. Recommendation ......................................6
+ 2.3. Inability to Follow Multiple Levels of Indirection .........7
+ 2.3.1. Recommendation ......................................7
+ 2.4. Aggressive Retransmission when Fetching Glue ...............8
+ 2.4.1. Recommendation ......................................9
+ 2.5. Aggressive Retransmission behind Firewalls .................9
+ 2.5.1. Recommendation .....................................10
+ 2.6. Misconfigured NS Records ..................................10
+ 2.6.1. Recommendation .....................................11
+
+
+
+
+Larson & Barber Best Current Practice [Page 1]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ 2.7. Name Server Records with Zero TTL .........................11
+ 2.7.1. Recommendation .....................................12
+ 2.8. Unnecessary Dynamic Update Messages .......................12
+ 2.8.1. Recommendation .....................................13
+ 2.9. Queries for Domain Names Resembling IPv4 Addresses ........13
+ 2.9.1. Recommendation .....................................14
+ 2.10. Misdirected Recursive Queries ............................14
+ 2.10.1. Recommendation ....................................14
+ 2.11. Suboptimal Name Server Selection Algorithm ...............15
+ 2.11.1. Recommendation ....................................15
+ 3. Security Considerations ........................................16
+ 4. Acknowledgements ...............................................16
+ 5. Internationalization Considerations ............................16
+ 6. References .....................................................16
+ 6.1. Normative References ......................................16
+ 6.2. Informative References ....................................16
+
+1. Introduction
+
+ Observation of query traffic received by two root name servers and
+ the thirteen com/net Top-Level Domain (TLD) name servers has revealed
+ that a large proportion of the total traffic often consists of
+ "requeries". A requery is the same question ()
+ asked repeatedly at an unexpectedly high rate. We have observed
+ requeries from both a single IP address and multiple IP addresses
+ (i.e., the same query received simultaneously from multiple IP
+ addresses).
+
+ By analyzing requery events, we have found that the cause of the
+ duplicate traffic is almost always a deficient iterative resolver,
+ stub resolver, or application implementation combined with an
+ operational anomaly. The implementation deficiencies we have
+ identified to date include well-intentioned recovery attempts gone
+ awry, insufficient caching of failures, early abort when multiple
+ levels of indirection must be followed, and aggressive retry by stub
+ resolvers or applications. Anomalies that we have seen trigger
+ requery events include lame delegations, unusual glue records, and
+ anything that makes all authoritative name servers for a zone
+ unreachable (Denial of Service (DoS) attacks, crashes, maintenance,
+ routing failures, congestion, etc.).
+
+ In the following sections, we provide a detailed explanation of the
+ observed behavior and recommend changes that will reduce the requery
+ rate. None of the changes recommended affects the core DNS protocol
+ specification; instead, this document consists of guidelines to
+ implementors of iterative resolvers.
+
+
+
+
+
+Larson & Barber Best Current Practice [Page 2]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+1.1. A Note about Terminology in This Memo
+
+ To recast an old saying about standards, the nice thing about DNS
+ terms is that there are so many of them to choose from. Writing or
+ talking about DNS can be difficult and can cause confusion resulting
+ from a lack of agreed-upon terms for its various components. Further
+ complicating matters are implementations that combine multiple roles
+ into one piece of software, which makes naming the result
+ problematic. An example is the entity that accepts recursive
+ queries, issues iterative queries as necessary to resolve the initial
+ recursive query, caches responses it receives, and which is also able
+ to answer questions about certain zones authoritatively. This entity
+ is an iterative resolver combined with an authoritative name server
+ and is often called a "recursive name server" or a "caching name
+ server".
+
+ This memo is concerned principally with the behavior of iterative
+ resolvers, which are typically found as part of a recursive name
+ server. This memo uses the more precise term "iterative resolver",
+ because the focus is usually on that component. In instances where
+ the name server role of this entity requires mentioning, this memo
+ uses the term "recursive name server". As an example of the
+ difference, the name server component of a recursive name server
+ receives DNS queries and the iterative resolver component sends
+ queries.
+
+ The advent of IPv6 requires mentioning AAAA records as well as A
+ records when discussing glue. To avoid continuous repetition and
+ qualification, this memo uses the general term "address record" to
+ encompass both A and AAAA records when a particular situation is
+ relevant to both types.
+
+1.2. Key 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 [1].
+
+2. Observed Iterative Resolver Misbehavior
+
+2.1. Aggressive Requerying for Delegation Information
+
+ There can be times when every name server in a zone's NS RRSet is
+ unreachable (e.g., during a network outage), unavailable (e.g., the
+ name server process is not running on the server host), or
+ misconfigured (e.g., the name server is not authoritative for the
+ given zone, also known as "lame"). Consider an iterative resolver
+ that attempts to resolve a query for a domain name in such a zone and
+
+
+
+Larson & Barber Best Current Practice [Page 3]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ discovers that none of the zone's name servers can provide an answer.
+ We have observed a recursive name server implementation whose
+ iterative resolver then verifies the zone's NS RRSet in its cache by
+ querying for the zone's delegation information: it sends a query for
+ the zone's NS RRSet to one of the parent zone's name servers. (Note
+ that queries with QTYPE=NS are not required by the standard
+ resolution algorithm described in Section 4.3.2 of RFC 1034 [2].
+ These NS queries represent this implementation's addition to that
+ algorithm.)
+
+ For example, suppose that "example.com" has the following NS RRSet:
+
+ example.com. IN NS ns1.example.com.
+ example.com. IN NS ns2.example.com.
+
+ Upon receipt of a query for "www.example.com" and assuming that
+ neither "ns1.example.com" nor "ns2.example.com" can provide an
+ answer, this iterative resolver implementation immediately queries a
+ "com" zone name server for the "example.com" NS RRSet to verify that
+ it has the proper delegation information. This implementation
+ performs this query to a zone's parent zone for each recursive query
+ it receives that fails because of a completely unresponsive set of
+ name servers for the target zone. Consider the effect when a popular
+ zone experiences a catastrophic failure of all its name servers: now
+ every recursive query for domain names in that zone sent to this
+ recursive name server implementation results in a query to the failed
+ zone's parent name servers. On one occasion when several dozen
+ popular zones became unreachable, the query load on the com/net name
+ servers increased by 50%.
+
+ We believe this verification query is not reasonable. Consider the
+ circumstances: when an iterative resolver is resolving a query for a
+ domain name in a zone it has not previously searched, it uses the
+ list of name servers in the referral from the target zone's parent.
+ If on its first attempt to search the target zone, none of the name
+ servers in the referral is reachable, a verification query to the
+ parent would be pointless: this query to the parent would come so
+ quickly on the heels of the referral that it would be almost certain
+ to contain the same list of name servers. The chance of discovering
+ any new information is slim.
+
+ The other possibility is that the iterative resolver successfully
+ contacts one of the target zone's name servers and then caches the NS
+ RRSet from the authority section of a response, the proper behavior
+ according to Section 5.4.1 of RFC 2181 [3], because the NS RRSet from
+ the target zone is more trustworthy than delegation information from
+ the parent zone. If, while processing a subsequent recursive query,
+ the iterative resolver discovers that none of the name servers
+
+
+
+Larson & Barber Best Current Practice [Page 4]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ specified in the cached NS RRSet is available or authoritative,
+ querying the parent would be wrong. An NS RRSet from the parent zone
+ would now be less trustworthy than data already in the cache.
+
+ For this query of the parent zone to be useful, the target zone's
+ entire set of name servers would have to change AND the former set of
+ name servers would have to be deconfigured or decommissioned AND the
+ delegation information in the parent zone would have to be updated
+ with the new set of name servers, all within the Time to Live (TTL)
+ of the target zone's NS RRSet. We believe this scenario is uncommon:
+ administrative best practices dictate that changes to a zone's set of
+ name servers happen gradually when at all possible, with servers
+ removed from the NS RRSet left authoritative for the zone as long as
+ possible. The scenarios that we can envision that would benefit from
+ the parent requery behavior do not outweigh its damaging effects.
+
+ This section should not be understood to claim that all queries to a
+ zone's parent are bad. In some cases, such queries are not only
+ reasonable but required. Consider the situation when required
+ information, such as the address of a name server (i.e., the address
+ record corresponding to the RDATA of an NS record), has timed out of
+ an iterative resolver's cache before the corresponding NS record. If
+ the name of the name server is below the apex of the zone, then the
+ name server's address record is only available as glue in the parent
+ zone. For example, consider this NS record:
+
+ example.com. IN NS ns.example.com.
+
+ If a cache has this NS record but not the address record for
+ "ns.example.com", it is unable to contact the "example.com" zone
+ directly and must query the "com" zone to obtain the address record.
+ Note, however, that such a query would not have QTYPE=NS according to
+ the standard resolution algorithm.
+
+2.1.1. Recommendation
+
+ An iterative resolver MUST NOT send a query for the NS RRSet of a
+ non-responsive zone to any of the name servers for that zone's parent
+ zone. For the purposes of this injunction, a non-responsive zone is
+ defined as a zone for which every name server listed in the zone's NS
+ RRSet:
+
+ 1. is not authoritative for the zone (i.e., lame), or
+
+ 2. returns a server failure response (RCODE=2), or
+
+ 3. is dead or unreachable according to Section 7.2 of RFC 2308 [4].
+
+
+
+
+Larson & Barber Best Current Practice [Page 5]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+2.2. Repeated Queries to Lame Servers
+
+ Section 2.1 describes a catastrophic failure: when every name server
+ for a zone is unable to provide an answer for one reason or another.
+ A more common occurrence is when a subset of a zone's name servers is
+ unavailable or misconfigured. Different failure modes have different
+ expected durations. Some symptoms indicate problems that are
+ potentially transient, for example, various types of ICMP unreachable
+ messages because a name server process is not running or a host or
+ network is unreachable, or a complete lack of a response to a query.
+ Such responses could be the result of a host rebooting or temporary
+ outages; these events do not necessarily require any human
+ intervention and can be reasonably expected to be temporary.
+
+ Other symptoms clearly indicate a condition requiring human
+ intervention, such as lame server: if a name server is misconfigured
+ and not authoritative for a zone delegated to it, it is reasonable to
+ assume that this condition has potential to last longer than
+ unreachability or unresponsiveness. Consequently, repeated queries
+ to known lame servers are not useful. In this case of a condition
+ with potential to persist for a long time, a better practice would be
+ to maintain a list of known lame servers and avoid querying them
+ repeatedly in a short interval.
+
+ It should also be noted, however, that some authoritative name server
+ implementations appear to be lame only for queries of certain types
+ as described in RFC 4074 [5]. In this case, it makes sense to retry
+ the "lame" servers for other types of queries, particularly when all
+ known authoritative name servers appear to be "lame".
+
+2.2.1. Recommendation
+
+ Iterative resolvers SHOULD cache name servers that they discover are
+ not authoritative for zones delegated to them (i.e., lame servers).
+ If this caching is performed, lame servers MUST be cached against the
+ specific query tuple . Zone
+ name can be derived from the owner name of the NS record that was
+ referenced to query the name server that was discovered to be lame.
+
+ Implementations that perform lame server caching MUST refrain from
+ sending queries to known lame servers for a configurable time
+ interval after the server is discovered to be lame. A minimum
+ interval of thirty minutes is RECOMMENDED.
+
+
+
+
+
+
+
+
+Larson & Barber Best Current Practice [Page 6]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ An exception to this recommendation occurs if all name servers for a
+ zone are marked lame. In that case, the iterative resolver SHOULD
+ temporarily ignore the servers' lameness status and query one or more
+ servers. This behavior is a workaround for the type-specific
+ lameness issue described in the previous section.
+
+ Implementors should take care not to make lame server avoidance logic
+ overly broad: note that a name server could be lame for a parent zone
+ but not a child zone, e.g., lame for "example.com" but properly
+ authoritative for "sub.example.com". Therefore, a name server should
+ not be automatically considered lame for subzones. In the case
+ above, even if a name server is known to be lame for "example.com",
+ it should be queried for QNAMEs at or below "sub.example.com" if an
+ NS record indicates that it should be authoritative for that zone.
+
+2.3. Inability to Follow Multiple Levels of Indirection
+
+ Some iterative resolver implementations are unable to follow
+ sufficient levels of indirection. For example, consider the
+ following delegations:
+
+ foo.example. IN NS ns1.example.com.
+ foo.example. IN NS ns2.example.com.
+
+ example.com. IN NS ns1.test.example.net.
+ example.com. IN NS ns2.test.example.net.
+
+ test.example.net. IN NS ns1.test.example.net.
+ test.example.net. IN NS ns2.test.example.net.
+
+ An iterative resolver resolving the name "www.foo.example" must
+ follow two levels of indirection, first obtaining address records for
+ "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
+ address records for "ns1.example.com" or "ns2.example.com" in order
+ to query those name servers for the address records of
+ "www.foo.example". Although this situation may appear contrived, we
+ have seen multiple similar occurrences and expect more as new generic
+ top-level domains (gTLDs) become active. We anticipate many zones in
+ new gTLDs will use name servers in existing gTLDs, increasing the
+ number of delegations using out-of-zone name servers.
+
+2.3.1. Recommendation
+
+ Clearly constructing a delegation that relies on multiple levels of
+ indirection is not a good administrative practice. However, the
+ practice is widespread enough to require that iterative resolvers be
+ able to cope with it. Iterative resolvers SHOULD be able to handle
+ arbitrary levels of indirection resulting from out-of-zone name
+
+
+
+Larson & Barber Best Current Practice [Page 7]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ servers. Iterative resolvers SHOULD implement a level-of-effort
+ counter to avoid loops or otherwise performing too much work in
+ resolving pathological cases.
+
+ A best practice that avoids this entire issue of indirection is to
+ name one or more of a zone's name servers in the zone itself. For
+ example, if the zone is named "example.com", consider naming some of
+ the name servers "ns{1,2,...}.example.com" (or similar).
+
+2.4. Aggressive Retransmission when Fetching Glue
+
+ When an authoritative name server responds with a referral, it
+ includes NS records in the authority section of the response.
+ According to the algorithm in Section 4.3.2 of RFC 1034 [2], the name
+ server should also "put whatever addresses are available into the
+ additional section, using glue RRs if the addresses are not available
+ from authoritative data or the cache." Some name server
+ implementations take this address inclusion a step further with a
+ feature called "glue fetching". A name server that implements glue
+ fetching attempts to include address records for every NS record in
+ the authority section. If necessary, the name server issues multiple
+ queries of its own to obtain any missing address records.
+
+ Problems with glue fetching can arise in the context of
+ "authoritative-only" name servers, which only serve authoritative
+ data and ignore requests for recursion. Such an entity will not
+ normally generate any queries of its own. Instead it answers non-
+ recursive queries from iterative resolvers looking for information in
+ zones it serves. With glue fetching enabled, however, an
+ authoritative server invokes an iterative resolver to look up an
+ unknown address record to complete the additional section of a
+ response.
+
+ We have observed situations where the iterative resolver of a glue-
+ fetching name server can send queries that reach other name servers,
+ but is apparently prevented from receiving the responses. For
+ example, perhaps the name server is authoritative-only and therefore
+ its administrators expect it to receive only queries and not
+ responses. Perhaps unaware of glue fetching and presuming that the
+ name server's iterative resolver will generate no queries, its
+ administrators place the name server behind a network device that
+ prevents it from receiving responses. If this is the case, all
+ glue-fetching queries will go unanswered.
+
+ We have observed name server implementations whose iterative
+ resolvers retry excessively when glue-fetching queries are
+ unanswered. A single com/net name server has received hundreds of
+ queries per second from a single such source. Judging from the
+
+
+
+Larson & Barber Best Current Practice [Page 8]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ specific queries received and based on additional analysis, we
+ believe these queries result from overly aggressive glue fetching.
+
+2.4.1. Recommendation
+
+ Implementers whose name servers support glue fetching SHOULD take
+ care to avoid sending queries at excessive rates. Implementations
+ SHOULD support throttling logic to detect when queries are sent but
+ no responses are received.
+
+2.5. Aggressive Retransmission behind Firewalls
+
+ A common occurrence and one of the largest sources of repeated
+ queries at the com/net and root name servers appears to result from
+ resolvers behind misconfigured firewalls. In this situation, an
+ iterative resolver is apparently allowed to send queries through a
+ firewall to other name servers, but not receive the responses. The
+ result is more queries than necessary because of retransmission, all
+ of which are useless because the responses are never received. Just
+ as with the glue-fetching scenario described in Section 2.4, the
+ queries are sometimes sent at excessive rates. To make matters
+ worse, sometimes the responses, sent in reply to legitimate queries,
+ trigger an alarm on the originator's intrusion detection system. We
+ are frequently contacted by administrators responding to such alarms
+ who believe our name servers are attacking their systems.
+
+ Not only do some resolvers in this situation retransmit queries at an
+ excessive rate, but they continue to do so for days or even weeks.
+ This scenario could result from an organization with multiple
+ recursive name servers, only a subset of whose iterative resolvers'
+ traffic is improperly filtered in this manner. Stub resolvers in the
+ organization could be configured to query multiple recursive name
+ servers. Consider the case where a stub resolver queries a filtered
+ recursive name server first. The iterative resolver of this
+ recursive name server sends one or more queries whose replies are
+ filtered, so it cannot respond to the stub resolver, which times out.
+ Then the stub resolver retransmits to a recursive name server that is
+ able to provide an answer. Since resolution ultimately succeeds the
+ underlying problem might not be recognized or corrected. A popular
+ stub resolver implementation has a very aggressive retransmission
+ schedule, including simultaneous queries to multiple recursive name
+ servers, which could explain how such a situation could persist
+ without being detected.
+
+
+
+
+
+
+
+
+Larson & Barber Best Current Practice [Page 9]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+2.5.1. Recommendation
+
+ The most obvious recommendation is that administrators SHOULD take
+ care not to place iterative resolvers behind a firewall that allows
+ queries, but not the resulting replies, to pass through.
+
+ Iterative resolvers SHOULD take care to avoid sending queries at
+ excessive rates. Implementations SHOULD support throttling logic to
+ detect when queries are sent but no responses are received.
+
+2.6. Misconfigured NS Records
+
+ Sometimes a zone administrator forgets to add the trailing dot on the
+ domain names in the RDATA of a zone's NS records. Consider this
+ fragment of the zone file for "example.com":
+
+ $ORIGIN example.com.
+ example.com. 3600 IN NS ns1.example.com ; Note missing
+ example.com. 3600 IN NS ns2.example.com ; trailing dots
+
+ The zone's authoritative servers will parse the NS RDATA as
+ "ns1.example.com.example.com" and "ns2.example.com.example.com" and
+ return NS records with this incorrect RDATA in responses, including
+ typically the authority section of every response containing records
+ from the "example.com" zone.
+
+ Now consider a typical sequence of queries. An iterative resolver
+ attempting to resolve address records for "www.example.com" with no
+ cached information for this zone will query a "com" authoritative
+ server. The "com" server responds with a referral to the
+ "example.com" zone, consisting of NS records with valid RDATA and
+ associated glue records. (This example assumes that the
+ "example.com" zone delegation information is correct in the "com"
+ zone.) The iterative resolver caches the NS RRSet from the "com"
+ server and follows the referral by querying one of the "example.com"
+ authoritative servers. This server responds with the
+ "www.example.com" address record in the answer section and,
+ typically, the "example.com" NS records in the authority section and,
+ if space in the message remains, glue address records in the
+ additional section. According to Section 5.4.1 of RFC 2181 [3], NS
+ records in the authority section of an authoritative answer are more
+ trustworthy than NS records from the authority section of a non-
+ authoritative answer. Thus, the "example.com" NS RRSet just received
+ from the "example.com" authoritative server overrides the
+ "example.com" NS RRSet received moments ago from the "com"
+ authoritative server.
+
+
+
+
+
+Larson & Barber Best Current Practice [Page 10]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ But the "example.com" zone contains the erroneous NS RRSet as shown
+ in the example above. Subsequent queries for names in "example.com"
+ will cause the iterative resolver to attempt to use the incorrect NS
+ records and so it will try to resolve the nonexistent names
+ "ns1.example.com.example.com" and "ns2.example.com.example.com". In
+ this example, since all of the zone's name servers are named in the
+ zone itself (i.e., "ns1.example.com.example.com" and
+ "ns2.example.com.example.com" both end in "example.com") and all are
+ bogus, the iterative resolver cannot reach any "example.com" name
+ servers. Therefore, attempts to resolve these names result in
+ address record queries to the "com" authoritative servers. Queries
+ for such obviously bogus glue address records occur frequently at the
+ com/net name servers.
+
+2.6.1. Recommendation
+
+ An authoritative server can detect this situation. A trailing dot
+ missing from an NS record's RDATA always results by definition in a
+ name server name that exists somewhere under the apex of the zone
+ that the NS record appears in. Note that further levels of
+ delegation are possible, so a missing trailing dot could
+ inadvertently create a name server name that actually exists in a
+ subzone.
+
+ An authoritative name server SHOULD issue a warning when one of a
+ zone's NS records references a name server below the zone's apex when
+ a corresponding address record does not exist in the zone AND there
+ are no delegated subzones where the address record could exist.
+
+2.7. Name Server Records with Zero TTL
+
+ Sometimes a popular com/net subdomain's zone is configured with a TTL
+ of zero on the zone's NS records, which prohibits these records from
+ being cached and will result in a higher query volume to the zone's
+ authoritative servers. The zone's administrator should understand
+ the consequences of such a configuration and provision resources
+ accordingly. A zero TTL on the zone's NS RRSet, however, carries
+ additional consequences beyond the zone itself: if an iterative
+ resolver cannot cache a zone's NS records because of a zero TTL, it
+ will be forced to query that zone's parent's name servers each time
+ it resolves a name in the zone. The com/net authoritative servers do
+ see an increased query load when a popular com/net subdomain's zone
+ is configured with a TTL of zero on the zone's NS records.
+
+ A zero TTL on an RRSet expected to change frequently is extreme but
+ permissible. A zone's NS RRSet is a special case, however, because
+ changes to it must be coordinated with the zone's parent. In most
+ zone parent/child relationships that we are aware of, there is
+
+
+
+Larson & Barber Best Current Practice [Page 11]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ typically some delay involved in effecting changes. Furthermore,
+ changes to the set of a zone's authoritative name servers (and
+ therefore to the zone's NS RRSet) are typically relatively rare:
+ providing reliable authoritative service requires a reasonably stable
+ set of servers. Therefore, an extremely low or zero TTL on a zone's
+ NS RRSet rarely makes sense, except in anticipation of an upcoming
+ change. In this case, when the zone's administrator has planned a
+ change and does not want iterative resolvers throughout the Internet
+ to cache the NS RRSet for a long period of time, a low TTL is
+ reasonable.
+
+2.7.1. Recommendation
+
+ Because of the additional load placed on a zone's parent's
+ authoritative servers resulting from a zero TTL on a zone's NS RRSet,
+ under such circumstances authoritative name servers SHOULD issue a
+ warning when loading a zone.
+
+2.8. Unnecessary Dynamic Update Messages
+
+ The UPDATE message specified in RFC 2136 [6] allows an authorized
+ agent to update a zone's data on an authoritative name server using a
+ DNS message sent over the network. Consider the case of an agent
+ desiring to add a particular resource record. Because of zone cuts,
+ the agent does not necessarily know the proper zone to which the
+ record should be added. The dynamic update process requires that the
+ agent determine the appropriate zone so the UPDATE message can be
+ sent to one of the zone's authoritative servers (typically the
+ primary master as specified in the zone's Start of Authority (SOA)
+ record's MNAME field).
+
+ The appropriate zone to update is the closest enclosing zone, which
+ cannot be determined only by inspecting the domain name of the record
+ to be updated, since zone cuts can occur anywhere. One way to
+ determine the closest enclosing zone entails walking up the name
+ space tree by sending repeated UPDATE messages until successful. For
+ example, consider an agent attempting to add an address record with
+ the name "foo.bar.example.com". The agent could first attempt to
+ update the "foo.bar.example.com" zone. If the attempt failed, the
+ update could be directed to the "bar.example.com" zone, then the
+ "example.com" zone, then the "com" zone, and finally the root zone.
+
+ A popular dynamic agent follows this algorithm. The result is many
+ UPDATE messages received by the root name servers, the com/net
+ authoritative servers, and presumably other TLD authoritative
+ servers. A valid question is why the algorithm proceeds to send
+ updates all the way to TLD and root name servers. This behavior is
+ not entirely unreasonable: in enterprise DNS architectures with an
+
+
+
+Larson & Barber Best Current Practice [Page 12]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ "internal root" design, there could conceivably be private, non-
+ public TLD or root zones that would be the appropriate targets for a
+ dynamic update.
+
+ A significant deficiency with this algorithm is that knowledge of a
+ given UPDATE message's failure is not helpful in directing future
+ UPDATE messages to the appropriate servers. A better algorithm would
+ be to find the closest enclosing zone by walking up the name space
+ with queries for SOA or NS rather than "probing" with UPDATE
+ messages. Once the appropriate zone is found, an UPDATE message can
+ be sent. In addition, the results of these queries can be cached to
+ aid in determining the closest enclosing zones for future updates.
+ Once the closest enclosing zone is determined with this method, the
+ update will either succeed or fail and there is no need to send
+ further updates to higher-level zones. The important point is that
+ walking up the tree with queries yields cacheable information,
+ whereas walking up the tree by sending UPDATE messages does not.
+
+2.8.1. Recommendation
+
+ Dynamic update agents SHOULD send SOA or NS queries to progressively
+ higher-level names to find the closest enclosing zone for a given
+ name to update. Only after the appropriate zone is found should the
+ client send an UPDATE message to one of the zone's authoritative
+ servers. Update clients SHOULD NOT "probe" using UPDATE messages by
+ walking up the tree to progressively higher-level zones.
+
+2.9. Queries for Domain Names Resembling IPv4 Addresses
+
+ The root name servers receive a significant number of A record
+ queries where the QNAME looks like an IPv4 address. The source of
+ these queries is unknown. It could be attributed to situations where
+ a user believes that an application will accept either a domain name
+ or an IP address in a given configuration option. The user enters an
+ IP address, but the application assumes that any input is a domain
+ name and attempts to resolve it, resulting in an A record lookup.
+ There could also be applications that produce such queries in a
+ misguided attempt to reverse map IP addresses.
+
+ These queries result in Name Error (RCODE=3) responses. An iterative
+ resolver can negatively cache such responses, but each response
+ requires a separate cache entry; i.e., a negative cache entry for the
+ domain name "192.0.2.1" does not prevent a subsequent query for the
+ domain name "192.0.2.2".
+
+
+
+
+
+
+
+Larson & Barber Best Current Practice [Page 13]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+2.9.1. Recommendation
+
+ It would be desirable for the root name servers not to have to answer
+ these queries: they unnecessarily consume CPU resources and network
+ bandwidth. A possible solution is to delegate these numeric TLDs
+ from the root zone to a separate set of servers to absorb the
+ traffic. The "black hole servers" used by the AS 112 Project
+ (http://www.as112.net), which are currently delegated the
+ in-addr.arpa zones corresponding to RFC 1918 [7] private use address
+ space, would be a possible choice to receive these delegations. Of
+ course, the proper and usual root zone change procedures would have
+ to be followed to make such a change to the root zone.
+
+2.10. Misdirected Recursive Queries
+
+ The root name servers receive a significant number of recursive
+ queries (i.e., queries with the Recursion Desired (RD) bit set in the
+ header). Since none of the root servers offers recursion, the
+ servers' response in such a situation ignores the request for
+ recursion and the response probably does not contain the data the
+ querier anticipated. Some of these queries result from users
+ configuring stub resolvers to query a root server. (This situation
+ is not hypothetical: we have received complaints from users when this
+ configuration does not work as hoped.) Of course, users should not
+ direct stub resolvers to use name servers that do not offer
+ recursion, but we are not aware of any stub resolver implementation
+ that offers any feedback to the user when so configured, aside from
+ simply "not working".
+
+2.10.1. Recommendation
+
+ When the IP address of a name server that supposedly offers recursion
+ is configured in a stub resolver using an interactive user interface,
+ the resolver could send a test query to verify that the server indeed
+ supports recursion (i.e., verify that the response has the RA bit set
+ in the header). The user could be notified immediately if the server
+ is non-recursive.
+
+ The stub resolver could also report an error, either through a user
+ interface or in a log file, if the queried server does not support
+ recursion. Error reporting SHOULD be throttled to avoid a
+ notification or log message for every response from a non-recursive
+ server.
+
+
+
+
+
+
+
+
+Larson & Barber Best Current Practice [Page 14]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+2.11. Suboptimal Name Server Selection Algorithm
+
+ An entire document could be devoted to the topic of problems with
+ different implementations of the recursive resolution algorithm. The
+ entire process of recursion is woefully under-specified, requiring
+ each implementor to design an algorithm. Sometimes implementors make
+ poor design choices that could be avoided if a suggested algorithm
+ and best practices were documented, but that is a topic for another
+ document.
+
+ Some deficiencies cause significant operational impact and are
+ therefore worth mentioning here. One of these is name server
+ selection by an iterative resolver. When an iterative resolver wants
+ to contact one of a zone's authoritative name servers, how does it
+ choose from the NS records listed in the zone's NS RRSet? If the
+ selection mechanism is suboptimal, queries are not spread evenly
+ among a zone's authoritative servers. The details of the selection
+ mechanism are up to the implementor, but we offer some suggestions.
+
+2.11.1. Recommendation
+
+ This list is not conclusive, but reflects the changes that would
+ produce the most impact in terms of reducing disproportionate query
+ load among a zone's authoritative servers. That is, these changes
+ would help spread the query load evenly.
+
+ o Do not make assumptions based on NS RRSet order: all NS RRs SHOULD
+ be treated equally. (In the case of the "com" zone, for example,
+ most of the root servers return the NS record for
+ "a.gtld-servers.net" first in the authority section of referrals.
+ Apparently as a result, this server receives disproportionately
+ more traffic than the other twelve authoritative servers for
+ "com".)
+
+ o Use all NS records in an RRSet. (For example, we are aware of
+ implementations that hard-coded information for a subset of the
+ root servers.)
+
+ o Maintain state and favor the best-performing of a zone's
+ authoritative servers. A good definition of performance is
+ response time. Non-responsive servers can be penalized with an
+ extremely high response time.
+
+ o Do not lock onto the best-performing of a zone's name servers. An
+ iterative resolver SHOULD periodically check the performance of
+ all of a zone's name servers to adjust its determination of the
+ best-performing one.
+
+
+
+
+Larson & Barber Best Current Practice [Page 15]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+3. Security Considerations
+
+ The iterative resolver misbehavior discussed in this document exposes
+ the root and TLD name servers to increased risk of both intentional
+ and unintentional Denial of Service attacks.
+
+ We believe that implementation of the recommendations offered in this
+ document will reduce the amount of unnecessary traffic seen at root
+ and TLD name servers, thus reducing the opportunity for an attacker
+ to use such queries to his or her advantage.
+
+4. Acknowledgements
+
+ The authors would like to thank the following people for their
+ comments that improved this document: Andras Salamon, Dave Meyer,
+ Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
+ Olafur Gudmundsson, Pekka Savola, Peter Koch, and Rob Austein. We
+ apologize if we have omitted anyone; any oversight was unintentional.
+
+5. Internationalization Considerations
+
+ There are no new internationalization considerations introduced by
+ this memo.
+
+6. References
+
+6.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Mockapetris, P., "Domain names - concepts and facilities", STD
+ 13, RFC 1034, November 1987.
+
+6.2. Informative References
+
+ [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+ RFC 2181, July 1997.
+
+ [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
+ 2308, March 1998.
+
+ [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
+ Queries for IPv6 Addresses", RFC 4074, May 2005.
+
+ [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
+ 1997.
+
+
+
+Larson & Barber Best Current Practice [Page 16]
+
+RFC 4697 Observed DNS Resolution Misbehavior October 2006
+
+
+ [7] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E.
+ Lear, "Address Allocation for Private Internets", BCP 5, RFC
+ 1918, February 1996.
+
+Authors' Addresses
+
+ Matt Larson
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ EMail: mlarson@verisign.com
+
+
+ Piet Barber
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ EMail: pbarber@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber Best Current Practice [Page 17]
+
+RFC 4697 Observed DNS Resolution Misbehavior 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).
+
+
+
+
+
+
+
+Larson & Barber Best Current Practice [Page 18]
+
diff --git a/doc/rfc/rfc4955.txt b/doc/rfc/rfc4955.txt
new file mode 100644
index 0000000000..2d2eb84e0f
--- /dev/null
+++ b/doc/rfc/rfc4955.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group D. Blacka
+Request for Comments: 4955 VeriSign, Inc.
+Category: Standards Track July 2007
+
+
+ DNS Security (DNSSEC) Experiments
+
+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 IETF Trust (2007).
+
+Abstract
+
+ This document describes a methodology for deploying alternate, non-
+ backwards-compatible, DNS Security (DNSSEC) methodologies in an
+ experimental fashion without disrupting the deployment of standard
+ DNSSEC.
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
+ 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 4
+ 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 5
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Standards Track [Page 1]
+
+RFC 4955 DNS Security (DNSSEC) Experiments July 2007
+
+
+1. 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 coexistence
+ with standard DNSSEC and DNS by using unknown algorithm identifiers
+ to hide the experimental DNSSEC protocol modifications from standard
+ security-aware resolvers.
+
+2. Definitions and Terminology
+
+ Throughout this document, familiarity with the DNS system (RFC 1035
+ [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and
+ RFC 4035 [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].
+
+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 Standards Track [Page 2]
+
+RFC 4955 DNS Security (DNSSEC) Experiments July 2007
+
+
+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 RFC 4035 [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.
+
+ Although this behavior isn't strictly mandatory (as marked by MUST),
+ it is unlikely for a validator to implement a substantially different
+ behavior. Essentially, if the validator does not have a usable chain
+ of trust to a child zone, then it can only do one of two things:
+ treat responses from the zone as insecure (the recommended behavior),
+ or treat the responses as bogus. If the validator chooses the
+ latter, this will both violate the expectation of the zone owner and
+ defeat the purpose of the above rule. However, with local policy, it
+ is within the right of a validator to refuse to trust certain zones
+ based on any criteria, including the use of unknown signing
+ algorithms.
+
+ Because we are talking about experiments, it is RECOMMENDED that
+ private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1.
+ Note that secure handling of private algorithms requires special
+ handing by the validator logic. See "Clarifications and
+ Implementation Notes for DNSSECbis" [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.
+
+
+
+Blacka Standards Track [Page 3]
+
+RFC 4955 DNS Security (DNSSEC) Experiments July 2007
+
+
+ It is RECOMMENDED that for a particular DNSSEC experiment, a
+ particular domain name base is chosen for all new algorithms, then
+ the algorithm number (or name) is prepended to it. For example, for
+ experiment A, the base name of "dnssec-experiment-a.example.com" is
+ chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
+ defined to be "3.dnssec-experiment-a.example.com" and
+ "5.dnssec-experiment-a.example.com". However, any unique identifier
+ will suffice.
+
+ 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 possible to validate experimentally,
+ or it is not.
+
+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
+ Object Identifier (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).
+
+
+
+Blacka Standards Track [Page 4]
+
+RFC 4955 DNS Security (DNSSEC) Experiments July 2007
+
+
+ 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.
+
+6. Considerations
+
+ There are a number of considerations with using this methodology.
+
+ 1. If an unaware validator does not correctly follow the rules laid
+ out in RFC 4035 (e.g., the validator interprets a DNSSEC record
+ prior to validating it), or if the experiment is broader in scope
+ that just modifying the DNSSEC semantics, the experiment may not
+ be sufficiently masked by this technique. This may cause
+ unintended resolution failures.
+
+ 2. It will not be possible for security-aware resolvers unaware of
+ the experiment to build a chain of trust through an experimental
+ zone.
+
+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.
+
+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.
+
+ Implementers should take into account any security issues that may
+ result from environments being configured to trust both experimental
+ and non-experimental zones. If the experimental zone is more
+
+
+
+Blacka Standards Track [Page 5]
+
+RFC 4955 DNS Security (DNSSEC) Experiments July 2007
+
+
+ vulnerable to attacks, it could, for example, be used to promote
+ trust in zones not part of the experiment, possibly under the control
+ of an attacker.
+
+9. References
+
+9.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.
+
+9.2. Informative References
+
+ [5] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [6] Weiler, S. and R. Austein, "Clarifications and Implementation
+ Notes for DNSSECbis", Work in Progress, March 2007.
+
+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 Standards Track [Page 6]
+
+RFC 4955 DNS Security (DNSSEC) Experiments July 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The 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 currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Blacka Standards Track [Page 7]
+
diff --git a/doc/rfc/rfc4956.txt b/doc/rfc/rfc4956.txt
new file mode 100644
index 0000000000..536c680cba
--- /dev/null
+++ b/doc/rfc/rfc4956.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group R. Arends
+Request for Comments: 4956 Nominet
+Category: Experimental M. Kosters
+ D. Blacka
+ VeriSign, Inc.
+ July 2007
+
+
+ DNS Security (DNSSEC) Opt-In
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ In the DNS security (DNSSEC) extensions, delegations to unsigned
+ subzones are cryptographically secured. Maintaining this
+ cryptography is not always practical or necessary. This document
+ describes an experimental "Opt-In" model that allows administrators
+ to omit this cryptography and manage the cost of adopting DNSSEC with
+ large zones.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Experimental [Page 1]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
+ 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Server Considerations . . . . . . . . . . . . . . . . . . 6
+ 4.1.1. Delegations Only . . . . . . . . . . . . . . . . . . . 6
+ 4.1.2. Insecure Delegation Responses . . . . . . . . . . . . 6
+ 4.1.3. Dynamic Update . . . . . . . . . . . . . . . . . . . . 6
+ 4.2. Client Considerations . . . . . . . . . . . . . . . . . . 7
+ 4.2.1. Delegations Only . . . . . . . . . . . . . . . . . . . 7
+ 4.2.2. Validation Process Changes . . . . . . . . . . . . . . 7
+ 4.2.3. NSEC Record Caching . . . . . . . . . . . . . . . . . 8
+ 4.2.4. Use of the AD bit . . . . . . . . . . . . . . . . . . 8
+ 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 11
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+ Appendix A. Implementing Opt-In Using "Views" . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Experimental [Page 2]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+1. Overview
+
+ The cost to cryptographically secure delegations to unsigned zones is
+ high for large delegation-centric zones and zones where insecure
+ delegations will be updated rapidly. For these zones, the costs of
+ maintaining the NextSECure (NSEC) record chain may be extremely high
+ relative to the gain of cryptographically authenticating existence of
+ unsecured zones.
+
+ This document describes an experimental method of eliminating the
+ superfluous cryptography present in secure delegations to unsigned
+ zones. Using "Opt-In", a zone administrator can choose to remove
+ insecure delegations from the NSEC chain. This is accomplished by
+ extending the semantics of the NSEC record by using a redundant bit
+ in the type map.
+
+2. Definitions and Terminology
+
+ Throughout this document, familiarity with the DNS system (RFC 1035
+ [1]), DNS security extensions ([4], [5], and [6], referred to in this
+ document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
+ [10]) is assumed.
+
+ The following abbreviations and terms are used in this document:
+
+ RR: is used to refer to a DNS resource record.
+
+ RRset: refers to a Resource Record Set, as defined by [8]. In this
+ document, the RRset is also defined to include the covering RRSIG
+ records, if any exist.
+
+ signed name: refers to a DNS name that has, at minimum, a (signed)
+ NSEC record.
+
+ unsigned name: refers to a DNS name that does not (at least) have an
+ NSEC record.
+
+ covering NSEC record/RRset: is the NSEC record used to prove
+ (non)existence of a particular name or RRset. This means that for
+ a RRset or name 'N', the covering NSEC record has the name 'N', or
+ has an owner name less than 'N' and "next" name greater than 'N'.
+
+ delegation: refers to an NS RRset with a name different from the
+ current zone apex (non-zone-apex), signifying a delegation to a
+ subzone.
+
+
+
+
+
+
+Arends, et al. Experimental [Page 3]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+ secure delegation: refers to a signed name containing a delegation
+ (NS RRset), and a signed DS RRset, signifying a delegation to a
+ signed subzone.
+
+ insecure delegation: refers to a signed name containing a delegation
+ (NS RRset), but lacking a DS RRset, signifying a delegation to an
+ unsigned subzone.
+
+ Opt-In insecure delegation: refers to an unsigned name containing
+ only a delegation NS RRset. The covering NSEC record uses the
+ Opt-In methodology described in this document.
+
+ The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [2].
+
+3. Experimental Status
+
+ This document describes an EXPERIMENTAL extension to DNSSEC. It
+ interoperates with non-experimental DNSSEC using the technique
+ described in [7]. This experiment is identified with the following
+ private algorithms (using algorithm 253):
+
+ "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
+ and
+
+ "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
+ RSASHA1.
+
+ Servers wishing to sign and serve zones that utilize Opt-In MUST sign
+ the zone with only one or more of these private algorithms and MUST
+ NOT use any other algorithms.
+
+ Resolvers MUST NOT apply the Opt-In validation rules described in
+ this document unless a zone is signed using one or more of these
+ private algorithms.
+
+ This experimental protocol relaxes the restriction that validators
+ MUST ignore the setting of the NSEC bit in the type map as specified
+ in RFC 4035 [6] Section 5.4.
+
+ The remainder of this document assumes that the servers and resolvers
+ involved are aware of and are involved in this experiment.
+
+
+
+
+
+
+
+
+Arends, et al. Experimental [Page 4]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+4. Protocol Additions
+
+ In DNSSEC, delegation NS RRsets are not signed, but are instead
+ accompanied by an NSEC RRset of the same name and (possibly) a DS
+ record. The security status of the subzone is determined by the
+ presence or absence of the DS RRset, cryptographically proven by the
+ NSEC record. Opt-In expands this definition by allowing insecure
+ delegations to exist within an otherwise signed zone without the
+ corresponding NSEC record at the delegation's owner name. These
+ insecure delegations are proven insecure by using a covering NSEC
+ record.
+
+ Since this represents a change of the interpretation of NSEC records,
+ resolvers must be able to distinguish between RFC standard DNSSEC
+ NSEC records and Opt-In NSEC records. This is accomplished by
+ "tagging" the NSEC records that cover (or potentially cover) insecure
+ delegation nodes. This tag is indicated by the absence of the NSEC
+ bit in the type map. Since the NSEC bit in the type map merely
+ indicates the existence of the record itself, this bit is redundant
+ and safe for use as a tag.
+
+ An Opt-In tagged NSEC record does not assert the (non)existence of
+ the delegations that it covers (except for a delegation with the same
+ name). This allows for the addition or removal of these delegations
+ without recalculating or resigning records in the NSEC chain.
+ However, Opt-In tagged NSEC records do assert the (non)existence of
+ other RRsets.
+
+ An Opt-In NSEC record MAY have the same name as an insecure
+ delegation. In this case, the delegation is proven insecure by the
+ lack of a DS bit in the type map, and the signed NSEC record does
+ assert the existence of the delegation.
+
+ Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
+ records and standard DNSSEC NSEC records. If an NSEC record is not
+ Opt-In, there MUST NOT be any insecure delegations (or any other
+ records) between it and the RRsets indicated by the 'next domain
+ name' in the NSEC RDATA. If it is Opt-In, there MUST only be
+ insecure delegations between it and the next node indicated by the
+ 'next domain name' in the NSEC RDATA.
+
+ In summary,
+
+ o An Opt-In NSEC type is identified by a zero-valued (or not-
+ specified) NSEC bit in the type bit map of the NSEC record.
+
+
+
+
+
+
+Arends, et al. Experimental [Page 5]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+ o A standard DNSSEC NSEC type is identified by a one-valued NSEC bit
+ in the type bit map of the NSEC record.
+
+ and
+
+ o An Opt-In NSEC record does not assert the non-existence of a name
+ between its owner name and "next" name, although it does assert
+ that any name in this span MUST be an insecure delegation.
+
+ o An Opt-In NSEC record does assert the (non)existence of RRsets
+ with the same owner name.
+
+4.1. Server Considerations
+
+ Opt-In imposes some new requirements on authoritative DNS servers.
+
+4.1.1. Delegations Only
+
+ This specification dictates that only insecure delegations may exist
+ between the owner and "next" names of an Opt-In tagged NSEC record.
+ Signing tools MUST NOT generate signed zones that violate this
+ restriction. Servers MUST refuse to load and/or serve zones that
+ violate this restriction. Servers also MUST reject AXFR or IXFR
+ responses that violate this restriction.
+
+4.1.2. Insecure Delegation Responses
+
+ When returning an Opt-In insecure delegation, the server MUST return
+ the covering NSEC RRset in the Authority section.
+
+ In standard DNSSEC, NSEC records already must be returned along with
+ the insecure delegation. The primary difference that this proposal
+ introduces is that the Opt-In tagged NSEC record will have a
+ different owner name from the delegation RRset. This may require
+ implementations to search for the covering NSEC RRset.
+
+4.1.3. Dynamic Update
+
+ Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In
+ particular, it introduces the need for rules that describe when to
+ add or remove a delegation name from the NSEC chain. This document
+ does not attempt to define these rules. Until these rules are
+ defined, servers MUST NOT process DNS Dynamic Update requests against
+ zones that use Opt-In NSEC records. Servers SHOULD return responses
+ to update requests with RCODE=REFUSED.
+
+
+
+
+
+
+Arends, et al. Experimental [Page 6]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+4.2. Client Considerations
+
+ Opt-In imposes some new requirements on security-aware resolvers
+ (caching or otherwise).
+
+4.2.1. Delegations Only
+
+ As stated in Section 4.1 above, this specification restricts the
+ namespace covered by Opt-In tagged NSEC records to insecure
+ delegations only. Clients are not expected to take any special
+ measures to enforce this restriction; instead, it forms an underlying
+ assumption that clients may rely on.
+
+4.2.2. Validation Process Changes
+
+ This specification does not change the resolver's resolution
+ algorithm. However, it does change the DNSSEC validation process.
+
+4.2.2.1. Referrals
+
+ Resolvers MUST be able to use Opt-In tagged NSEC records to
+ cryptographically prove the validity and security status (as
+ insecure) of a referral. Resolvers determine the security status of
+ the referred-to zone as follows:
+
+ o In standard DNSSEC, the security status is proven by the existence
+ or absence of a DS RRset at the same name as the delegation. The
+ existence of the DS RRset indicates that the referred-to zone is
+ signed. The absence of the DS RRset is proven using a verified
+ NSEC record of the same name that does not have the DS bit set in
+ the type map. This NSEC record MAY also be tagged as Opt-In.
+
+ o Using Opt-In, the security status is proven by the existence of a
+ DS record (for signed) or the presence of a verified Opt-In tagged
+ NSEC record that covers the delegation name. That is, the NSEC
+ record does not have the NSEC bit set in the type map, and the
+ delegation name falls between the NSEC's owner and "next" name.
+
+ Using Opt-In does not substantially change the nature of following
+ referrals within DNSSEC. At every delegation point, the resolver
+ will have cryptographic proof that the referred-to subzone is signed
+ or unsigned.
+
+4.2.2.2. Queries for DS Resource Records
+
+ Since queries for DS records are directed to the parent side of a
+ zone cut (see [5], Section 5), negative responses to these queries
+ may be covered by an Opt-In flagged NSEC record.
+
+
+
+Arends, et al. Experimental [Page 7]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+ Resolvers MUST be able to use Opt-In tagged NSEC records to
+ cryptographically prove the validity and security status of negative
+ responses to queries for DS records. In particular, a NOERROR/NODATA
+ (i.e., RCODE=3, but the answer section is empty) response to a DS
+ query may be proven by an Opt-In flagged covering NSEC record, rather
+ than an NSEC record matching the query name.
+
+4.2.3. NSEC Record Caching
+
+ Caching resolvers MUST be able to retrieve the appropriate covering
+ Opt-In NSEC record when returning referrals that need them. This
+ requirement differs from standard DNSSEC in that the covering NSEC
+ will not have the same owner name as the delegation. Some
+ implementations may have to use new methods for finding these NSEC
+ records.
+
+4.2.4. Use of the AD bit
+
+ The AD bit, as defined by [3] and [6], MUST NOT be set when:
+
+ o sending a Name Error (RCODE=3) response where the covering NSEC is
+ tagged as Opt-In.
+
+ o sending an Opt-In insecure delegation response, unless the
+ covering (Opt-In) NSEC record's owner name equals the delegation
+ name.
+
+ o sending a NOERROR/NODATA response when query type is DS and the
+ covering NSEC is tagged as Opt-In, unless NSEC record's owner name
+ matches the query name.
+
+ This rule is based on what the Opt-In NSEC record actually proves:
+ for names that exist between the Opt-In NSEC record's owner and
+ "next" names, the Opt-In NSEC record cannot prove the non-existence
+ or existence of the name. As such, not all data in the response has
+ been cryptographically verified, so the AD bit cannot be set.
+
+5. Benefits
+
+ Using Opt-In allows administrators of large and/or changing
+ delegation-centric zones to minimize the overhead involved in
+ maintaining the security of the zone.
+
+ Opt-In accomplishes this by eliminating the need for NSEC records for
+ insecure delegations. This, in a zone with a large number of
+ delegations to unsigned subzones, can lead to substantial space
+ savings (both in memory and on disk). Additionally, Opt-In allows
+ for the addition or removal of insecure delegations without modifying
+
+
+
+Arends, et al. Experimental [Page 8]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+ the NSEC record chain. Zones that are frequently updating insecure
+ delegations (e.g., Top-Level Domains (TLDs)) can avoid the
+ substantial overhead of modifying and resigning the affected NSEC
+ records.
+
+6. Example
+
+ Consider the zone EXAMPLE shown below. This is a zone where all of
+ the NSEC records are tagged as Opt-In.
+
+ Example A: Fully Opt-In Zone.
+
+ EXAMPLE. SOA ...
+ EXAMPLE. RRSIG SOA ...
+ EXAMPLE. NS FIRST-SECURE.EXAMPLE.
+ EXAMPLE. RRSIG NS ...
+ EXAMPLE. DNSKEY ...
+ EXAMPLE. RRSIG DNSKEY ...
+ EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (
+ SOA NS RRSIG DNSKEY )
+ EXAMPLE. RRSIG NSEC ...
+
+ FIRST-SECURE.EXAMPLE. A ...
+ FIRST-SECURE.EXAMPLE. RRSIG A ...
+ FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG
+ FIRST-SECURE.EXAMPLE. RRSIG NSEC ...
+
+ NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
+ NS.NOT-SECURE.EXAMPLE. A ...
+
+ NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
+ NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG
+ NOT-SECURE-2.EXAMPLE RRSIG NSEC ...
+
+ SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE.
+ SECOND-SECURE.EXAMPLE. DS ...
+ SECOND-SECURE.EXAMPLE. RRSIG DS ...
+ SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY
+ SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
+
+ UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE.
+ NS.UNSIGNED.EXAMPLE. A ...
+
+
+ Example A.
+
+
+
+
+
+
+Arends, et al. Experimental [Page 9]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+ In this example, a query for a signed RRset (e.g., "FIRST-
+ SECURE.EXAMPLE A") or a secure delegation ("WWW.SECOND-SECURE.EXAMPLE
+ A") will result in a standard DNSSEC response.
+
+ A query for a nonexistent RRset will result in a response that
+ differs from standard DNSSEC by the following: the NSEC record will
+ be tagged as Opt-In, there may be no NSEC record proving the non-
+ existence of a matching wildcard record, and the AD bit will not be
+ set.
+
+ A query for an insecure delegation RRset (or a referral) will return
+ both the answer (in the Authority section) and the corresponding
+ Opt-In NSEC record to prove that it is not secure.
+
+ Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
+
+
+ RCODE=NOERROR, AD=0
+
+ Answer Section:
+
+ Authority Section:
+ UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE
+ SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS
+ SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
+
+ Additional Section:
+ NS.UNSIGNED.EXAMPLE. A ...
+
+ Example A.1
+
+ In the Example A.1 zone, the EXAMPLE. node MAY use either style of
+ NSEC record, because there are no insecure delegations that occur
+ between it and the next node, FIRST-SECURE.EXAMPLE. In other words,
+ Example A would still be a valid zone if the NSEC record for EXAMPLE.
+ was changed to the following RR:
+
+ EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS
+ RRSIG DNSKEY NSEC )
+
+ However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
+ SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure
+ delegations in the range they define. (NOT-SECURE.EXAMPLE. and
+ UNSIGNED.EXAMPLE., respectively).
+
+ NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
+ part of the NSEC chain and also covered by an Opt-In tagged NSEC
+ record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
+
+
+
+Arends, et al. Experimental [Page 10]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+ removed from the zone without modifying and resigning the prior NSEC
+ record. Delegations with names that fall between NOT-SECURE-
+ 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
+ resigning any NSEC records.
+
+7. Transition Issues
+
+ Opt-In is not backwards compatible with standard DNSSEC and is
+ considered experimental. Standard DNSSEC-compliant implementations
+ would not recognize Opt-In tagged NSEC records as different from
+ standard NSEC records. Because of this, standard DNSSEC
+ implementations, if they were to validate Opt-In style responses,
+ would reject all Opt-In insecure delegations within a zone as
+ invalid. However, by only signing with private algorithms, standard
+ DNSSEC implementations will treat Opt-In responses as unsigned.
+
+ It should be noted that all elements in the resolution path between
+ (and including) the validator and the authoritative name server must
+ be aware of the Opt-In experiment and implement the Opt-In semantics
+ for successful validation to be possible. In particular, this
+ includes any caching middleboxes between the validator and
+ authoritative name server.
+
+8. Security Considerations
+
+ Opt-In allows for unsigned names, in the form of delegations to
+ unsigned subzones, to exist within an otherwise signed zone. All
+ unsigned names are, by definition, insecure, and their validity or
+ existence cannot be cryptographically proven.
+
+ In general:
+
+ o Records with unsigned names (whether or not existing) suffer from
+ the same vulnerabilities as records in an unsigned zone. These
+ vulnerabilities are described in more detail in [12] (note in
+ particular Sections 2.3, "Name Games" and 2.6, "Authenticated
+ Denial").
+
+ o Records with signed names have the same security whether or not
+ Opt-In is used.
+
+ Note that with or without Opt-In, an insecure delegation may have its
+ contents undetectably altered by an attacker. Because of this, the
+ primary difference in security that Opt-In introduces is the loss of
+ the ability to prove the existence or nonexistence of an insecure
+ delegation within the span of an Opt-In NSEC record.
+
+
+
+
+
+Arends, et al. Experimental [Page 11]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+ In particular, this means that a malicious entity may be able to
+ insert or delete records with unsigned names. These records are
+ normally NS records, but this also includes signed wildcard
+ expansions (while the wildcard record itself is signed, its expanded
+ name is an unsigned name), which can be undetectably removed or used
+ to replace an existing unsigned delegation.
+
+ For example, if a resolver received the following response from the
+ example zone above:
+
+ Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
+
+ RCODE=NOERROR
+
+ Answer Section:
+
+ Authority Section:
+ DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
+ EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
+ RRSIG DNSKEY
+ EXAMPLE. RRSIG NSEC ...
+
+ Additional Section:
+
+
+ Attacker has forged a name
+
+ The resolver would have no choice but to believe that the referral to
+ NS.FORGED. is valid. If a wildcard existed that would have been
+ expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+ have undetectably removed it and replaced it with the forged
+ delegation.
+
+ Note that being able to add a delegation is functionally equivalent
+ to being able to add any record type: an attacker merely has to forge
+ a delegation to the nameserver under his/her control and place
+ whatever records are needed at the subzone apex.
+
+ While in particular cases, this issue may not present a significant
+ security problem, in general it should not be lightly dismissed.
+ Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+ In particular, zone signing tools SHOULD NOT default to Opt-In, and
+ MAY choose not to support Opt-In at all.
+
+
+
+
+
+
+
+
+Arends, et al. Experimental [Page 12]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+9. Acknowledgments
+
+ The contributions, suggestions, and remarks of the following persons
+ (in alphabetic order) to this document are acknowledged:
+
+ Mats Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill
+ Manning, Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter,
+ Brian Wellington.
+
+10. References
+
+10.1. Normative References
+
+ [1] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+ Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+ [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
+ [7] Blacka, D., "DNSSEC Experiments", RFC 4955, July 2007.
+
+10.2. Informative References
+
+ [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+ RFC 2181, July 1997.
+
+ [9] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+ [10] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+
+
+
+
+Arends, et al. Experimental [Page 13]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+ [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
+ December 2001.
+
+ [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+ System (DNS)", RFC 3833, August 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Experimental [Page 14]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+Appendix A. Implementing Opt-In Using "Views"
+
+ In many cases, it may be convenient to implement an Opt-In zone by
+ combining two separately maintained "views" of a zone at request
+ time. In this context, "view" refers to a particular version of a
+ zone, not to any specific DNS implementation feature.
+
+ In this scenario, one view is the secure view, the other is the
+ insecure (or legacy) view. The secure view consists of an entirely
+ signed zone using Opt-In tagged NSEC records. The insecure view
+ contains no DNSSEC information. It is helpful, although not
+ necessary, for the secure view to be a subset (minus DNSSEC records)
+ of the insecure view.
+
+ In addition, the only RRsets that may solely exist in the insecure
+ view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and
+ the zone apex NS RRset) MUST be signed and in the secure view.
+
+ These two views may be combined at request time to provide a virtual,
+ single Opt-In zone. The following algorithm is used when responding
+ to each query:
+
+ V_A is the secure view as described above.
+
+ V_B is the insecure view as described above.
+
+ R_A is a response generated from V_A, following standard DNSSEC.
+
+ R_B is a response generated from V_B, following DNS resolution as
+ per RFC 1035 [1].
+
+ R_C is the response generated by combining R_A with R_B, as
+ described below.
+
+ A query is DNSSEC-aware if it either has the DO bit [11] turned on
+ or is for a DNSSEC-specific record type.
+
+ 1. If V_A is a subset of V_B and the query is not DNSSEC-aware,
+ generate and return R_B, otherwise
+
+ 2. Generate R_A.
+
+ 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise
+
+
+
+
+
+
+
+
+Arends, et al. Experimental [Page 15]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+ 4. Generate R_B and combine it with R_A to form R_C:
+
+ For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
+ records from R_A into R_B, EXCEPT the AUTHORITY section SOA
+ record, if R_B's RCODE = NOERROR.
+
+ 5. Return R_C.
+
+Authors' Addresses
+
+ Roy Arends
+ Nominet
+ Sandford Gate
+ Sandy Lane West
+ Oxford OX4 6LB
+ UNITED KINGDOM
+
+ Phone: +44 1865 332211
+ EMail: roy@nominet.org.uk
+
+
+ Mark Kosters
+ VeriSign, Inc.
+ 21355 Ridgetop Circle
+ Dulles, VA 20166
+ US
+
+ Phone: +1 703 948 3200
+ EMail: mkosters@verisign.com
+ URI: http://www.verisignlabs.com
+
+
+ David Blacka
+ VeriSign, Inc.
+ 21355 Ridgetop Circle
+ Dulles, VA 20166
+ US
+
+ Phone: +1 703 948 3200
+ EMail: davidb@verisign.com
+ URI: http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Experimental [Page 16]
+
+RFC 4956 DNS Security (DNSSEC) Opt-In July 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The 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 currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Arends, et al. Experimental [Page 17]
+
diff --git a/doc/rfc/rfc5001.txt b/doc/rfc/rfc5001.txt
new file mode 100644
index 0000000000..fe15339369
--- /dev/null
+++ b/doc/rfc/rfc5001.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group R. Austein
+Request for Comments: 5001 ISC
+Category: Standards Track August 2007
+
+
+ DNS Name Server Identifier (NSID) Option
+
+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 IETF Trust (2007).
+
+Abstract
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query. While existing ad-hoc
+ mechanisms allow an operator to send follow-up queries when it is
+ necessary to debug such a configuration, the only completely reliable
+ way to obtain the identity of the name server that responded is to
+ have the name server include this information in the response itself.
+ This note defines a protocol extension to support this functionality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Standards Track [Page 1]
+
+RFC 5001 DNS NSID August 2007
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 3
+ 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 3
+ 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4
+ 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 4
+ 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 4
+ 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 7
+ 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 7
+ 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
+
+1. Introduction
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query.
+
+ Existing ad-hoc mechanisms allow an operator to send follow-up
+ queries when it is necessary to debug such a configuration, but there
+ are situations in which this is not a totally satisfactory solution,
+ since anycast routing may have changed, or the server pool in
+ question may be behind some kind of extremely dynamic load balancing
+ hardware. Thus, while these ad-hoc mechanisms are certainly better
+ than nothing (and have the advantage of already being deployed), a
+ better solution seems desirable.
+
+ Given that a DNS query is an idempotent operation with no retained
+ state, it would appear that the only completely reliable way to
+ obtain the identity of the name server that responded to a particular
+ query is to have that name server include identifying information in
+ the response itself. This note defines a protocol enhancement to
+ achieve this.
+
+
+
+
+
+
+
+
+Austein Standards Track [Page 2]
+
+RFC 5001 DNS NSID August 2007
+
+
+1.1. Reserved Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. Protocol
+
+ This note uses an EDNS [RFC2671] option to signal the resolver's
+ desire for information identifying the name server and to hold the
+ name server's response, if any.
+
+2.1. Resolver Behavior
+
+ A resolver signals its desire for information identifying a name
+ server by sending an empty NSID option (Section 2.3) in an EDNS OPT
+ pseudo-RR in the query message.
+
+ The resolver MUST NOT include any NSID payload data in the query
+ message.
+
+ The semantics of an NSID request are not transitive. That is: the
+ presence of an NSID option in a query is a request that the name
+ server which receives the query identify itself. If the name server
+ side of a recursive name server receives an NSID request, the client
+ is asking the recursive name server to identify itself; if the
+ resolver side of the recursive name server wishes to receive
+ identifying information, it is free to add NSID requests in its own
+ queries, but that is a separate matter.
+
+2.2. Name Server Behavior
+
+ A name server that understands the NSID option and chooses to honor a
+ particular NSID request responds by including identifying information
+ in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the
+ response message.
+
+ The name server MUST ignore any NSID payload data that might be
+ present in the query message.
+
+ The NSID option is not transitive. A name server MUST NOT send an
+ NSID option back to a resolver which did not request it. In
+ particular, while a recursive name server may choose to add an NSID
+ option when sending a query, this has no effect on the presence or
+ absence of the NSID option in the recursive name server's response to
+ the original client.
+
+
+
+
+
+Austein Standards Track [Page 3]
+
+RFC 5001 DNS NSID August 2007
+
+
+ As stated in Section 2.1, this mechanism is not restricted to
+ authoritative name servers; the semantics are intended to be equally
+ applicable to recursive name servers.
+
+2.3. The NSID Option
+
+ The OPTION-CODE for the NSID option is 3.
+
+ The OPTION-DATA for the NSID option is an opaque byte string, the
+ semantics of which are deliberately left outside the protocol. See
+ Section 3.1 for discussion.
+
+2.4. Presentation Format
+
+ User interfaces MUST read and write the contents of the NSID option
+ as a sequence of hexadecimal digits, two digits per payload octet.
+
+ The NSID payload is binary data. Any comparison between NSID
+ payloads MUST be a comparison of the raw binary data. Copy
+ operations MUST NOT assume that the raw NSID payload is null-
+ terminated. Any resemblance between raw NSID payload data and any
+ form of text is purely a convenience, and does not change the
+ underlying nature of the payload data.
+
+ See Section 3.3 for discussion.
+
+3. Discussion
+
+ This section discusses certain aspects of the protocol and explains
+ considerations that led to the chosen design.
+
+3.1. The NSID Payload
+
+ The syntax and semantics of the content of the NSID option are
+ deliberately left outside the scope of this specification.
+
+ Choosing the NSID content is a prerogative of the server
+ administrator. The server administrator might choose to encode the
+ NSID content in such a way that the server operator (or clients
+ authorized by the server operator) can decode the NSID content to
+ obtain more information than other clients can. Alternatively, the
+ server operator might choose unencoded NSID content that is equally
+ meaningful to any client.
+
+ This section describes some of the kinds of data that server
+ administrators might choose to provide as the content of the NSID
+ option, and explains the reasoning behind specifying a simple opaque
+ byte string in Section 2.3.
+
+
+
+Austein Standards Track [Page 4]
+
+RFC 5001 DNS NSID August 2007
+
+
+ There are several possibilities for the payload of the NSID option:
+
+ o It could be the "real" name of the specific name server within the
+ name server pool.
+
+ o It could be the "real" IP address (IPv4 or IPv6) of the name
+ server within the name server pool.
+
+ o It could be some sort of pseudo-random number generated in a
+ predictable fashion somehow using the server's IP address or name
+ as a seed value.
+
+ o It could be some sort of probabilistically unique identifier
+ initially derived from some sort of random number generator then
+ preserved across reboots of the name server.
+
+ o It could be some sort of dynamically generated identifier so that
+ only the name server operator could tell whether or not any two
+ queries had been answered by the same server.
+
+ o It could be a blob of signed data, with a corresponding key which
+ might (or might not) be available via DNS lookups.
+
+ o It could be a blob of encrypted data, the key for which could be
+ restricted to parties with a need to know (in the opinion of the
+ server operator).
+
+ o It could be an arbitrary string of octets chosen at the discretion
+ of the name server operator.
+
+ Each of these options has advantages and disadvantages:
+
+ o Using the "real" name is simple, but the name server may not have
+ a "real" name.
+
+ o Using the "real" address is also simple, and the name server
+ almost certainly does have at least one non-anycast IP address for
+ maintenance operations, but the operator of the name server may
+ not be willing to divulge its non-anycast address.
+
+ o Given that one common reason for using anycast DNS techniques is
+ an attempt to harden a critical name server against denial of
+ service attacks, some name server operators are likely to want an
+ identifier other than the "real" name or "real" address of the
+ name server instance.
+
+ o Using a hash or pseudo-random number can provide a fixed length
+ value that the resolver can use to tell two name servers apart
+
+
+
+Austein Standards Track [Page 5]
+
+RFC 5001 DNS NSID August 2007
+
+
+ without necessarily being able to tell where either one of them
+ "really" is, but makes debugging more difficult if one happens to
+ be in a friendly open environment. Furthermore, hashing might not
+ add much value, since a hash based on an IPv4 address still only
+ involves a 32-bit search space, and DNS names used for servers
+ that operators might have to debug at 4am tend not to be very
+ random.
+
+ o Probabilistically unique identifiers have properties similar to
+ hashed identifiers, but (given a sufficiently good random number
+ generator) are immune to the search space issues. However, the
+ strength of this approach is also its weakness: there is no
+ algorithmic transformation by which even the server operator can
+ associate name server instances with identifiers while debugging,
+ which might be annoying. This approach also requires the name
+ server instance to preserve the probabilistically unique
+ identifier across reboots, but this does not appear to be a
+ serious restriction, since authoritative nameservers almost always
+ have some form of non-volatile storage. In the rare case of a
+ name server that does not have any way to store such an
+ identifier, nothing terrible will happen if the name server
+ generates a new identifier every time it reboots.
+
+ o Using an arbitrary octet string gives name server operators yet
+ another setting to configure, or mis-configure, or forget to
+ configure. Having all the nodes in an anycast name server
+ constellation identify themselves as "My Name Server" would not be
+ particularly useful.
+
+ o A signed blob is not particularly useful as an NSID payload unless
+ the signed data is dynamic and includes some kind of replay
+ protection, such as a timestamp or some kind of data identifying
+ the requestor. Signed blobs that meet these criteria could
+ conceivably be useful in some situations but would require
+ detailed security analysis beyond the scope of this document.
+
+ o A static encrypted blob would not be particularly useful, as it
+ would be subject to replay attacks and would, in effect, just be a
+ random number to any party that does not possess the decryption
+ key. Dynamic encrypted blobs could conceivably be useful in some
+ situations but, as with signed blobs, dynamic encrypted blobs
+ would require detailed security analysis beyond the scope of this
+ document.
+
+ Given all of the issues listed above, there does not appear to be a
+ single solution that will meet all needs. Section 2.3 therefore
+ defines the NSID payload to be an opaque byte string and leaves the
+ choice of payload up to the implementor and name server operator.
+
+
+
+Austein Standards Track [Page 6]
+
+RFC 5001 DNS NSID August 2007
+
+
+ The following guidelines may be useful to implementors and server
+ operators:
+
+ o Operators for whom divulging the unicast address is an issue could
+ use the raw binary representation of a probabilistically unique
+ random number. This should probably be the default implementation
+ behavior.
+
+ o Operators for whom divulging the unicast address is not an issue
+ could just use the raw binary representation of a unicast address
+ for simplicity. This should only be done via an explicit
+ configuration choice by the operator.
+
+ o Operators who really need or want the ability to set the NSID
+ payload to an arbitrary value could do so, but this should only be
+ done via an explicit configuration choice by the operator.
+
+ This approach appears to provide enough information for useful
+ debugging without unintentionally leaking the maintenance addresses
+ of anycast name servers to nogoodniks, while also allowing name
+ server operators who do not find such leakage threatening to provide
+ more information at their own discretion.
+
+3.2. NSID Is Not Transitive
+
+ As specified in Section 2.1 and Section 2.2, the NSID option is not
+ transitive. This is strictly a hop-by-hop mechanism.
+
+ Most of the discussion of name server identification to date has
+ focused on identifying authoritative name servers, since the best
+ known cases of anycast name servers are a subset of the name servers
+ for the root zone. However, given that anycast DNS techniques are
+ also applicable to recursive name servers, the mechanism may also be
+ useful with recursive name servers. The hop-by-hop semantics support
+ this.
+
+ While there might be some utility in having a transitive variant of
+ this mechanism (so that, for example, a stub resolver could ask a
+ recursive server to tell it which authoritative name server provided
+ a particular answer to the recursive name server), the semantics of
+ such a variant would be more complicated, and are left for future
+ work.
+
+3.3. User Interface Issues
+
+ Given the range of possible payload contents described in
+ Section 3.1, it is not possible to define a single presentation
+ format for the NSID payload that is efficient, convenient,
+
+
+
+Austein Standards Track [Page 7]
+
+RFC 5001 DNS NSID August 2007
+
+
+ unambiguous, and aesthetically pleasing. In particular, while it is
+ tempting to use a presentation format that uses some form of textual
+ strings, attempting to support this would significantly complicate
+ what's intended to be a very simple debugging mechanism.
+
+ In some cases the content of the NSID payload may be binary data
+ meaningful only to the name server operator, and may not be
+ meaningful to the user or application, but the user or application
+ must be able to capture the entire content anyway in order for it to
+ be useful. Thus, the presentation format must support arbitrary
+ binary data.
+
+ In cases where the name server operator derives the NSID payload from
+ textual data, a textual form such as US-ASCII or UTF-8 strings might
+ at first glance seem easier for a user to deal with. There are,
+ however, a number of complex issues involving internationalized text
+ which, if fully addressed here, would require a set of rules
+ significantly longer than the rest of this specification. See
+ [RFC2277] for an overview of some of these issues.
+
+ It is much more important for the NSID payload data to be passed
+ unambiguously from server administrator to user and back again than
+ it is for the payload data to be pretty while in transit. In
+ particular, it's critical that it be straightforward for a user to
+ cut and paste an exact copy of the NSID payload output by a debugging
+ tool into other formats such as email messages or web forms without
+ distortion. Hexadecimal strings, while ugly, are also robust.
+
+3.4. Truncation
+
+ In some cases, adding the NSID option to a response message may
+ trigger message truncation. This specification does not change the
+ rules for DNS message truncation in any way, but implementors will
+ need to pay attention to this issue.
+
+ Including the NSID option in a response is always optional, so this
+ specification never requires name servers to truncate response
+ messages.
+
+ By definition, a resolver that requests NSID responses also supports
+ EDNS, so a resolver that requests NSID responses can also use the
+ "sender's UDP payload size" field of the OPT pseudo-RR to signal a
+ receive buffer size large enough to make truncation unlikely.
+
+4. IANA Considerations
+
+ IANA has allocated EDNS option code 3 for the NSID option
+ (Section 2.3).
+
+
+
+Austein Standards Track [Page 8]
+
+RFC 5001 DNS NSID August 2007
+
+
+5. Security Considerations
+
+ This document describes a channel signaling mechanism intended
+ primarily for debugging. Channel signaling mechanisms are outside
+ the scope of DNSSEC, per se. Applications that require integrity
+ protection for the data being signaled will need to use a channel
+ security mechanism such as TSIG [RFC2845].
+
+ Section 3.1 discusses a number of different kinds of information that
+ a name server operator might choose to provide as the value of the
+ NSID option. Some of these kinds of information are security
+ sensitive in some environments. This specification deliberately
+ leaves the syntax and semantics of the NSID option content up to the
+ implementation and the name server operator.
+
+ Two of the possible kinds of payload data discussed in Section 3.1
+ involve a digital signature and encryption, respectively. While this
+ specification discusses some of the pitfalls that might lurk for
+ careless users of these kinds of payload data, full analysis of the
+ issues that would be involved in these kinds of payload data would
+ require knowledge of the content to be signed or encrypted,
+ algorithms to be used, and so forth, which is beyond the scope of
+ this document. Implementors should seek competent advice before
+ attempting to use these kinds of NSID payloads.
+
+6. Acknowledgements
+
+ Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews,
+ Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad,
+ John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter
+ Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey
+ Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam
+ Weiler, and Suzanne Woolf, none of whom are responsible for what the
+ author did with their comments and suggestions. Apologies to anyone
+ inadvertently omitted from the above list.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+ RFC 2671, August 1999.
+
+
+
+
+
+
+Austein Standards Track [Page 9]
+
+RFC 5001 DNS NSID August 2007
+
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+7.2. Informative References
+
+ [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", RFC 2277, BCP 18, January 1998.
+
+Author's Address
+
+ Rob Austein
+ ISC
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ EMail: sra@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Standards Track [Page 10]
+
+RFC 5001 DNS NSID August 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The 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 currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Austein Standards Track [Page 11]
+
diff --git a/doc/rfc/rfc5452.txt b/doc/rfc/rfc5452.txt
new file mode 100644
index 0000000000..6f59bf57ac
--- /dev/null
+++ b/doc/rfc/rfc5452.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group A. Hubert
+Request for Comments: 5452 Netherlabs Computer Consulting BV.
+Updates: 2181 R. van Mook
+Category: Standards Track Equinix
+ January 2009
+
+
+ Measures for Making DNS More Resilient against Forged Answers
+
+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) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents (http://trustee.ietf.org/
+ license-info) in effect on the date of publication of this document.
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+Abstract
+
+ The current Internet climate poses serious threats to the Domain Name
+ System. In the interim period before the DNS protocol can be secured
+ more fully, measures can already be taken to harden the DNS to make
+ 'spoofing' a recursing nameserver many orders of magnitude harder.
+
+ Even a cryptographically secured DNS benefits from having the ability
+ to discard bogus responses quickly, as this potentially saves large
+ amounts of computation.
+
+ By describing certain behavior that has previously not been
+ standardized, this document sets out how to make the DNS more
+ resilient against accepting incorrect responses. This document
+ updates RFC 2181.
+
+
+
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 1]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Requirements and Definitions . . . . . . . . . . . . . . . . . 4
+ 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Description of DNS Spoofing . . . . . . . . . . . . . . . . . 5
+ 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 6
+ 4.1. Forcing a Query . . . . . . . . . . . . . . . . . . . . . 6
+ 4.2. Matching the Question Section . . . . . . . . . . . . . . 7
+ 4.3. Matching the ID Field . . . . . . . . . . . . . . . . . . 7
+ 4.4. Matching the Source Address of the Authentic Response . . 7
+ 4.5. Matching the Destination Address and Port of the
+ Authentic Response . . . . . . . . . . . . . . . . . . . . 8
+ 4.6. Have the Response Arrive before the Authentic Response . . 8
+ 5. Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . . 9
+ 6. Accepting Only In-Domain Records . . . . . . . . . . . . . . . 9
+ 7. Combined Difficulty . . . . . . . . . . . . . . . . . . . . . 10
+ 7.1. Symbols Used in Calculation . . . . . . . . . . . . . . . 10
+ 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 11
+ 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 8.1. Repetitive Spoofing Attempts for a Single Domain Name . . 13
+ 9. Forgery Countermeasures . . . . . . . . . . . . . . . . . . . 13
+ 9.1. Query Matching Rules . . . . . . . . . . . . . . . . . . . 13
+ 9.2. Extending the Q-ID Space by Using Ports and Addresses . . 14
+ 9.2.1. Justification and Discussion . . . . . . . . . . . . . 14
+ 9.3. Spoof Detection and Countermeasure . . . . . . . . . . . . 15
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 2]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+1. Introduction
+
+ This document describes several common problems in DNS
+ implementations, which, although previously recognized, remain
+ largely unsolved. Besides briefly recapping these problems, this
+ document contains rules that, if implemented, make complying
+ resolvers vastly more resistant to the attacks described. The goal
+ is to make the existing DNS as secure as possible within the current
+ protocol boundaries.
+
+ The words below are aimed at authors of resolvers: it is up to
+ operators to decide which nameserver implementation to use, or which
+ options to enable. Operational constraints may override the security
+ concerns described below. However, implementations are expected to
+ allow an operator to enable functionality described in this document.
+
+ Almost every transaction on the Internet involves the Domain Name
+ System, which is described in [RFC1034], [RFC1035], and beyond.
+
+ Additionally, it has recently become possible to acquire Secure
+ Socket Layer/Transport Layer Security (SSL/TLS) certificates with no
+ other confirmation of identity than the ability to respond to a
+ verification email sent via SMTP ([RFC5321]) -- which generally uses
+ DNS for its routing.
+
+ In other words, any party that (temporarily) controls the Domain Name
+ System is in a position to reroute most kinds of Internet
+ transactions, including the verification steps in acquiring an SSL/
+ TLS certificate for a domain. This in turn means that even
+ transactions protected by SSL/TLS could be diverted.
+
+ It is entirely conceivable that such rerouted traffic could be used
+ to the disadvantage of Internet users.
+
+ These and other developments have made the security and
+ trustworthiness of DNS of renewed importance. Although the DNS
+ community is working hard on finalizing and implementing a
+ cryptographically enhanced DNS protocol, steps should be taken to
+ make sure that the existing use of DNS is as secure as possible
+ within the bounds of the relevant standards.
+
+ It should be noted that the most commonly used resolvers currently do
+ not perform as well as possible in this respect, making this document
+ of urgent importance.
+
+ A thorough analysis of risks facing DNS can be found in [RFC3833].
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 3]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ This document expands on some of the risks mentioned in RFC 3833,
+ especially those outlined in the sections on "ID Guessing and Query
+ Prediction" and "Name Chaining". Furthermore, it emphasizes a number
+ of existing rules and guidelines embodied in the relevant DNS
+ protocol specifications. The following also specifies new
+ requirements to make sure the Domain Name System can be relied upon
+ until a more secure protocol has been standardized and deployed.
+
+ It should be noted that even when all measures suggested below are
+ implemented, protocol users are not protected against third parties
+ with the ability to observe, modify, or inject packets in the traffic
+ of a resolver.
+
+ For protocol extensions that offer protection against these
+ scenarios, see [RFC4033] and beyond.
+
+2. Requirements and Definitions
+
+2.1. Definitions
+
+ This document uses the following definitions:
+
+ Client: typically a 'stub-resolver' on an end-user's computer.
+
+ Resolver: a nameserver performing recursive service for clients,
+ also known as a caching server, or a full service resolver
+ ([RFC1123], Section 6.1.3.1).
+
+ Stub resolver: a very limited resolver on a client computer, that
+ leaves the recursing work to a full resolver.
+
+ Query: a question sent out by a resolver, typically in a UDP
+ packet
+
+ Response: the answer sent back by an authoritative nameserver,
+ typically in a UDP packet.
+
+ Third party: any entity other than the resolver or the intended
+ recipient of a question. The third party may have access to an
+ arbitrary authoritative nameserver, but has no access to packets
+ transmitted by the resolver or authoritative server.
+
+ Attacker: malicious third party.
+
+ Spoof: the activity of attempting to subvert the DNS process by
+ getting a chosen answer accepted.
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 4]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ Authentic response: the correct answer that comes from the right
+ authoritative server.
+
+ Target domain name: domain for which the attacker wishes to spoof
+ in an answer
+
+ Fake data: response chosen by the attacker.
+
+2.2. Key Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Description of DNS Spoofing
+
+ When certain steps are taken, it is feasible to "spoof" the current
+ deployed majority of resolvers with carefully crafted and timed DNS
+ packets. Once spoofed, a caching server will repeat the data it
+ wrongfully accepted, and make its clients contact the wrong, and
+ possibly malicious, servers.
+
+ To understand how this process works it is important to know what
+ makes a resolver accept a response.
+
+ The following sentence in Section 5.3.3 of [RFC1034] presaged the
+ present problem:
+
+ The resolver should be highly paranoid in its parsing of responses.
+ It should also check that the response matches the query it sent
+ using the ID field in the response.
+
+ DNS data is to be accepted by a resolver if and only if:
+
+ 1. The question section of the reply packet is equivalent to that of
+ a question packet currently waiting for a response.
+
+ 2. The ID field of the reply packet matches that of the question
+ packet.
+
+ 3. The response comes from the same network address to which the
+ question was sent.
+
+ 4. The response comes in on the same network address, including port
+ number, from which the question was sent.
+
+ In general, the first response matching these four conditions is
+ accepted.
+
+
+
+Hubert & van Mook Standards Track [Page 5]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ If a third party succeeds in meeting the four conditions before the
+ response from the authentic nameserver does so, it is in a position
+ to feed a resolver fabricated data. When it does so, we dub it an
+ "attacker", attempting to spoof in fake data.
+
+ All conditions mentioned above can theoretically be met by a third
+ party, with the difficulty being a function of the resolver
+ implementation and zone configuration.
+
+4. Detailed Description of Spoofing Scenarios
+
+ The previous paragraph discussed a number of requirements an attacker
+ must match in order to spoof in manipulated (or fake) data. This
+ section discusses the relative difficulties and how implementation-
+ defined choices impact the amount of work an attacker has to perform
+ to meet said difficulties.
+
+ Some more details can be found in Section 2.2 of [RFC3833].
+
+4.1. Forcing a Query
+
+ Formally, there is no need for a nameserver to perform service except
+ for its operator, its customers, or more generally its users.
+ Recently, open recursing nameservers have been used to amplify
+ denial-of-service attacks.
+
+ Providing full service enables the third party to send the target
+ resolver a query for the domain name it intends to spoof. On
+ receiving this query, and not finding the answer in its cache, the
+ resolver will transmit queries to relevant authoritative nameservers.
+ This opens up a window of opportunity for getting fake answer data
+ accepted.
+
+ Queries may however be forced indirectly, for example, by inducing a
+ mail server to perform DNS lookups.
+
+ Some operators restrict access by not recursing for unauthorized IP
+ addresses, but only respond with data from the cache. This makes
+ spoofing harder for a third party as it cannot then force the exact
+ moment a question will be asked. It is still possible however to
+ determine a time range when this will happen, because nameservers
+ helpfully publish the decreasing time to live (TTL) of entries in the
+ cache, which indicate from which absolute time onwards a new query
+ could be sent to refresh the expired entry.
+
+ The time to live of the target domain name's RRSets determines how
+ often a window of opportunity is available, which implies that a
+ short TTL makes spoofing far more viable.
+
+
+
+Hubert & van Mook Standards Track [Page 6]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ Note that the attacker might very well have authorized access to the
+ target resolver by virtue of being a customer or employee of its
+ operator. In addition, access may be enabled through the use of
+ reflectors as outlined in [RFC5358].
+
+4.2. Matching the Question Section
+
+ DNS packets, both queries and responses, contain a question section.
+ Incoming responses should be verified to have a question section that
+ is equivalent to that of the outgoing query.
+
+4.3. Matching the ID Field
+
+ The DNS ID field is 16 bits wide, meaning that if full use is made of
+ all these bits, and if their contents are truly random, it will
+ require on average 32768 attempts to guess. Anecdotal evidence
+ suggests there are implementations utilizing only 14 bits, meaning on
+ average 8192 attempts will suffice.
+
+ Additionally, if the target nameserver can be forced into having
+ multiple identical queries outstanding, the "Birthday Attack"
+ phenomenon means that any fake data sent by the attacker is matched
+ against multiple outstanding queries, significantly raising the
+ chance of success. Further details in Section 5.
+
+4.4. Matching the Source Address of the Authentic Response
+
+ It should be noted that meeting this condition entails being able to
+ transmit packets on behalf of the address of the authoritative
+ nameserver. While two Best Current Practice documents ([RFC2827] and
+ [RFC3013] specifically) direct Internet access providers to prevent
+ their customers from assuming IP addresses that are not assigned to
+ them, these recommendations are not universally (nor even widely)
+ implemented.
+
+ Many zones have two or three authoritative nameservers, which make
+ matching the source address of the authentic response very likely
+ with even a naive choice having a double digit success rate.
+
+ Most recursing nameservers store relative performance indications of
+ authoritative nameservers, which may make it easier to predict which
+ nameserver would originally be queried -- the one most likely to
+ respond the quickest.
+
+ Generally, this condition requires at most two or three attempts
+ before it is matched.
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 7]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+4.5. Matching the Destination Address and Port of the Authentic
+ Response
+
+ Note that the destination address of the authentic response is the
+ source address of the original query.
+
+ The actual address of a recursing nameserver is generally known; the
+ port used for asking questions is harder to determine. Most current
+ resolvers pick an arbitrary port at startup (possibly at random) and
+ use this for all outgoing queries. In quite a number of cases, the
+ source port of outgoing questions is fixed at the traditional DNS
+ assigned server port number of 53.
+
+ If the source port of the original query is random, but static, any
+ authoritative nameserver under observation by the attacker can be
+ used to determine this port. This means that matching this
+ conditions often requires no guess work.
+
+ If multiple ports are used for sending queries, this enlarges the
+ effective ID space by a factor equal to the number of ports used.
+
+ Less common resolving servers choose a random port per outgoing
+ query. If this strategy is followed, this port number can be
+ regarded as an additional ID field, again containing up to 16 bits.
+
+ If the maximum ports range is utilized, on average, around 32256
+ source ports would have to be tried before matching the source port
+ of the original query, as ports below 1024 may be unavailable for
+ use, leaving 64512 options.
+
+ It is in general safe for DNS to use ports in the range 1024-49152
+ even though some of these ports are allocated to other protocols.
+ DNS resolvers will not be able to use any ports that are already in
+ use. If a DNS resolver uses a port, it will release that port after
+ a short time and migrate to a different port. Only in the case of a
+ high-volume resolver is it possible that an application wanting a
+ particular UDP port suffers a long term block-out.
+
+ It should be noted that a firewall will not prevent the matching of
+ this address, as it will accept answers that (appear to) come from
+ the correct address, offering no additional security.
+
+4.6. Have the Response Arrive before the Authentic Response
+
+ Once any packet has matched the previous four conditions (plus
+ possible additional conditions), no further responses are generally
+ accepted.
+
+
+
+
+Hubert & van Mook Standards Track [Page 8]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ This means that the third party has a limited time in which to inject
+ its spoofed response. For calculations, we will assume a window in
+ order of at most 100 ms (depending on the network distance to the
+ authentic authoritative nameserver).
+
+ This time period can be far longer if the authentic authoritative
+ nameservers are (briefly) overloaded by queries, perhaps by the
+ attacker.
+
+5. Birthday Attacks
+
+ The so-called "birthday paradox" implies that a group of 23 people
+ suffices to have a more than even chance of having two or more
+ members of the group share a birthday.
+
+ An attacker can benefit from this exact phenomenon if it can force
+ the target resolver to have multiple equivalent (identical QNAME,
+ QTYPE, and QCLASS) outstanding queries at any one time to the same
+ authoritative server.
+
+ Any packet the attacker sends then has a much higher chance of being
+ accepted because it only has to match any of the outstanding queries
+ for that single domain. Compared to the birthday analogy above, of
+ the group composed of queries and responses, the chance of having any
+ of these share an ID rises quickly.
+
+ As long as small numbers of queries are sent out, the chance of
+ successfully spoofing a response rises linearly with the number of
+ outstanding queries for the exact domain and nameserver.
+
+ For larger numbers, this effect is less pronounced.
+
+ More details are available in US-CERT [vu-457875].
+
+6. Accepting Only In-Domain Records
+
+ Responses from authoritative nameservers often contain information
+ that is not part of the zone for which we deem it authoritative. As
+ an example, a query for the MX record of a domain might get as its
+ responses a mail exchanger in another domain, and additionally the IP
+ address of this mail exchanger.
+
+ If accepted uncritically, the resolver stands the chance of accepting
+ data from an untrusted source. Care must be taken to only accept
+ data if it is known that the originator is authoritative for the
+ QNAME or a parent of the QNAME.
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 9]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ One very simple way to achieve this is to only accept data if it is
+ part of the domain for which the query was intended.
+
+7. Combined Difficulty
+
+ Given a known or static destination port, matching ID field, the
+ source and destination address requires on average in the order of 2
+ * 2^15 = 65000 packets, assuming a zone has 2 authoritative
+ nameservers.
+
+ If the window of opportunity available is around 100 ms, as assumed
+ above, an attacker would need to be able to briefly transmit 650000
+ packets/s to have a 50% chance to get spoofed data accepted on the
+ first attempt.
+
+ A realistic minimal DNS response consists of around 80 bytes,
+ including IP headers, making the packet rate above correspond to a
+ respectable burst of 416 Mbit/s.
+
+ As of mid-2006, this kind of bandwidth was not common but not scarce
+ either, especially among those in a position to control many servers.
+
+ These numbers change when a window of a full second is assumed,
+ possibly because the arrival of the authentic response can be
+ prevented by overloading the bona fide authoritative hosts with decoy
+ queries. This reduces the needed bandwidth to 42 Mbit/s.
+
+ If, in addition, the attacker is granted more than a single chance
+ and allowed up to 60 minutes of work on a domain with a time to live
+ of 300 seconds, a meager 4 Mbit/s suffices for a 50% chance at
+ getting fake data accepted. Once equipped with a longer time,
+ matching condition 1 mentioned above is straightforward -- any
+ popular domain will have been queried a number of times within this
+ hour, and given the short TTL, this would lead to queries to
+ authoritative nameservers, opening windows of opportunity.
+
+7.1. Symbols Used in Calculation
+
+ Assume the following symbols are used:
+
+ I: Number distinct IDs available (maximum 65536)
+
+ P: Number of ports used (maximum around 64000 as ports under 1024 are
+ not always available, but often 1)
+
+ N: Number of authoritative nameservers for a domain (averages around
+ 2.5)
+
+
+
+
+Hubert & van Mook Standards Track [Page 10]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ F: Number of "fake" packets sent by the attacker
+
+ R: Number of packets sent per second by the attacker
+
+ W: Window of opportunity, in seconds. Bounded by the response time
+ of the authoritative servers (often 0.1s)
+
+ D: Average number of identical outstanding queries of a resolver
+ (typically 1, see Section 5)
+
+ A: Number of attempts, one for each window of opportunity
+
+7.2. Calculation
+
+ The probability of spoofing a resolver is equal to the amount of fake
+ packets that arrive within the window of opportunity, divided by the
+ size of the problem space.
+
+ When the resolver has 'D' multiple identical outstanding queries,
+ each fake packet has a proportionally higher chance of matching any
+ of these queries. This assumption only holds for small values of
+ 'D'.
+
+ In symbols, if the probability of being spoofed is denoted as P_s:
+
+ D * F
+ P_s = ---------
+ N * P * I
+
+ It is more useful to reason not in terms of aggregate packets but to
+ convert to packet rate, which can easily be converted to bandwidth if
+ needed.
+
+ If the window of opportunity length is 'W' and the attacker can send
+ 'R' packets per second, the number of fake packets 'F' that are
+ candidates to be accepted is:
+
+ D * R * W
+ F = R * W -> P_s = ---------
+ N * P * I
+
+ Finally, to calculate the combined chance 'P_cs' of spoofing over a
+ chosen time period 'T', it should be realized that the attacker has a
+ new window of opportunity each time the TTL 'TTL' of the target
+ domain expires. This means that the number of attempts 'A' is equal
+ to 'T / TTL'.
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 11]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ To calculate the combined chance of at least one success, the
+ following formula holds:
+
+ (T / TTL)
+ A ( D * R * W )
+ P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- )
+ ( N * P * I )
+
+ When common numbers (as listed above) for D, W, N, P, and I are
+ inserted, this formula reduces to:
+
+ (T / TTL)
+ ( R )
+ P_cs = 1 - ( 1 - ------- )
+ ( 1638400 )
+
+ From this formula, it can be seen that, if the nameserver
+ implementation is unchanged, only raising the TTL offers protection.
+ Raising N, the number of authoritative nameservers, is not feasible
+ beyond a small number.
+
+ For the degenerate case of a zero-second TTL, a window of opportunity
+ opens for each query sent, making the effective TTL equal to 'W'
+ above, the response time of the authoritative server.
+
+ This last case also holds for spoofing techniques that do not rely on
+ TTL expiry, but use repeated and changing queries.
+
+8. Discussion
+
+ The calculations above indicate the relative ease with which DNS data
+ can be spoofed. For example, using the formula derived earlier on an
+ RRSet with a 3600 second TTL, an attacker sending 7000 fake response
+ packets/s (a rate of 4.5 Mbit/s), stands a 10% chance of spoofing a
+ record in the first 24 hours, which rises to 50% after a week.
+
+ For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24
+ minutes, 50% after less than 3 hours, 90% after around 9 hours.
+
+ For some classes of attacks, the effective TTL is near zero, as noted
+ above.
+
+ Note that the attacks mentioned above can be detected by watchful
+ server operators - an unexpected incoming stream of 4.5 Mbit/s of
+ packets might be noticed.
+
+ An important assumption however in these calculations is a known or
+ static destination port of the authentic response.
+
+
+
+Hubert & van Mook Standards Track [Page 12]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ If that port number is unknown and needs to be guessed as well, the
+ problem space expands by a factor of 64000, leading the attacker to
+ need in excess of 285Gb/s to achieve similar success rates.
+
+ Such bandwidth is not generally available, nor is it expected to be
+ so in the foreseeable future.
+
+ Note that some firewalls may need reconfiguring if they are currently
+ set up to only allow outgoing queries from a single DNS source port.
+
+8.1. Repetitive Spoofing Attempts for a Single Domain Name
+
+ Techniques are available to use an effectively infinite number of
+ queries to achieve a desired spoofing goal. In the math above, this
+ reduces the effective TTL to 0.
+
+ If such techniques are employed, using the same 7000 packets/s rate
+ mentioned above, and using 1 source port, the spoofing chance rises
+ to 50% within 7 seconds.
+
+ If 64000 ports are used, as recommended in this document, using the
+ same query rate, the 50% level is reached after around 116 hours.
+
+9. Forgery Countermeasures
+
+9.1. Query Matching Rules
+
+ A resolver implementation MUST match responses to all of the
+ following attributes of the query:
+
+ o Source address against query destination address
+
+ o Destination address against query source address
+
+ o Destination port against query source port
+
+ o Query ID
+
+ o Query name
+
+ o Query class and type
+
+ before applying DNS trustworthiness rules (see Section 5.4.1 of
+ [RFC2181]).
+
+ A mismatch and the response MUST be considered invalid.
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 13]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+9.2. Extending the Q-ID Space by Using Ports and Addresses
+
+ Resolver implementations MUST:
+
+ o Use an unpredictable source port for outgoing queries from the
+ range of available ports (53, or 1024 and above) that is as large
+ as possible and practicable;
+
+ o Use multiple different source ports simultaneously in case of
+ multiple outstanding queries;
+
+ o Use an unpredictable query ID for outgoing queries, utilizing the
+ full range available (0-65535).
+
+ Resolvers that have multiple IP addresses SHOULD use them in an
+ unpredictable manner for outgoing queries.
+
+ Resolver implementations SHOULD provide means to avoid usage of
+ certain ports.
+
+ Resolvers SHOULD favor authoritative nameservers with which a trust
+ relation has been established; stub-resolvers SHOULD be able to use
+ Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when
+ communicating with their recursive resolver.
+
+ In case a cryptographic verification of response validity is
+ available (TSIG, SIG(0)), resolver implementations MAY waive above
+ rules, and rely on this guarantee instead.
+
+ Proper unpredictability can be achieved by employing a high quality
+ (pseudo-)random generator, as described in [RFC4086].
+
+9.2.1. Justification and Discussion
+
+ Since an attacker can force a full DNS resolver to send queries to
+ the attacker's own nameservers, any constant or sequential state held
+ by such a resolver can be measured, and it must not be trivially easy
+ to reverse engineer the resolver's internal state in a way that
+ allows low-cost, high-accuracy prediction of future state.
+
+ A full DNS resolver with only one or a small number of upstream-
+ facing endpoints is effectively using constants for IP source address
+ and UDP port number, and these are very predictable by potential
+ attackers, and must therefore be avoided.
+
+ A full DNS resolver that uses a simple increment to get its next DNS
+ query ID is likewise very predictable and so very spoofable.
+
+
+
+
+Hubert & van Mook Standards Track [Page 14]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ Finally, weak random number generators have been shown to expose
+ their internal state, such that an attacker who witnesses several
+ sequential "random" values can easily predict the next ones. A
+ crypto-strength random number generator is one whose output cannot be
+ predicted no matter how many successive values are witnessed.
+
+9.3. Spoof Detection and Countermeasure
+
+ If a resolver detects that an attempt is being made to spoof it,
+ perhaps by discovering that many packets fail the criteria as
+ outlined above, it MAY abandon the UDP query and re-issue it over
+ TCP. TCP, by the nature of its use of sequence numbers, is far more
+ resilient against forgery by third parties.
+
+10. Security Considerations
+
+ This document provides clarification of the DNS specification to
+ decrease the probability that DNS responses can be successfully
+ forged. Recommendations found above should be considered
+ complementary to possible cryptographical enhancements of the domain
+ name system, which protect against a larger class of attacks.
+
+ This document recommends the use of UDP source port number
+ randomization to extend the effective DNS transaction ID beyond the
+ available 16 bits.
+
+ A resolver that does not implement the recommendations outlined above
+ can easily be forced to accept spoofed responses, which in turn are
+ passed on to client computers -- misdirecting (user) traffic to
+ possibly malicious entities.
+
+ This document directly impacts the security of the Domain Name
+ System, implementers are urged to follow its recommendations.
+
+ Most security considerations can be found in Sections 4 and 5, while
+ proposed countermeasures are described in Section 9.
+
+ For brevity's sake, in lieu of repeating the security considerations
+ references, the reader is referred to these sections.
+
+ Nothing in this document specifies specific algorithms for operators
+ to use; it does specify algorithms implementations SHOULD or MUST
+ support.
+
+ It should be noted that the effects of source port randomization may
+ be dramatically reduced by NAT devices that either serialize or limit
+ in volume the UDP source ports used by the querying resolver.
+
+
+
+
+Hubert & van Mook Standards Track [Page 15]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ DNS recursive servers sitting behind at NAT or a statefull firewall
+ may consume all available NAT translation entries/ports when
+ operating under high query load. Port randomization will cause
+ translation entries to be consumed faster than with fixed query port.
+
+ To avoid this, NAT boxes and statefull firewalls can/should purge
+ outgoing DNS query translation entries 10-17 seconds after the last
+ outgoing query on that mapping was sent. [RFC4787]-compliant devices
+ need to treat UDP messages with port 53 differently than most other
+ UDP protocols.
+
+ To minimize the potential that port/state exhaustion attacks can be
+ staged from the outside, it is recommended that services that
+ generate a number of DNS queries for each connection should be rate
+ limited. This applies in particular to email servers.
+
+11. Acknowledgments
+
+ Source port randomization in DNS was first implemented and possibly
+ invented by Dan J. Bernstein.
+
+ Although any mistakes remain our own, the authors gratefully
+ acknowledge the help and contributions of:
+ Stephane Bortzmeyer
+ Alfred Hoenes
+ Peter Koch
+ Sean Leach
+ Norbert Sendetzky
+ Paul Vixie
+ Florian Weimer
+ Wouter Wijngaards
+ Dan Wing
+
+12. References
+
+12.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+
+
+Hubert & van Mook Standards Track [Page 16]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+ [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP
+ Source Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+ Wellington, "Secret Key Transaction Authentication for
+ DNS (TSIG)", RFC 2845, May 2000.
+
+ [RFC3013] Killalea, T., "Recommended Internet Service Provider
+ Security Services and Procedures", BCP 46, RFC 3013,
+ November 2000.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086,
+ June 2005.
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008.
+
+12.2. Informative References
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
+ Domain Name System (DNS)", RFC 3833, August 2004.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
+ Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+ October 2008.
+
+ [vu-457875] United States CERT, "Various DNS service implementations
+ generate multiple simultaneous queries for the same
+ resource record", VU 457875, November 2002.
+
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 17]
+
+RFC 5452 DNS Resilience against Forged Answers January 2009
+
+
+Authors' Addresses
+
+ Bert Hubert
+ Netherlabs Computer Consulting BV.
+ Braillelaan 10
+ Rijswijk (ZH) 2289 CM
+ The Netherlands
+
+ EMail: bert.hubert@netherlabs.nl
+
+
+ Remco van Mook
+ Equinix
+ Auke Vleerstraat 1
+ Enschede 7521 PE
+ The Netherlands
+
+ EMail: remco@eu.equinix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hubert & van Mook Standards Track [Page 18]
+
diff --git a/doc/rfc/rfc5625.txt b/doc/rfc/rfc5625.txt
new file mode 100644
index 0000000000..102d7e8770
--- /dev/null
+++ b/doc/rfc/rfc5625.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group R. Bellis
+Request for Comments: 5625 Nominet UK
+BCP: 152 August 2009
+Category: Best Current Practice
+
+
+ DNS Proxy Implementation Guidelines
+
+Abstract
+
+ This document provides guidelines for the implementation of DNS
+ proxies, as found in broadband gateways and other similar network
+ devices.
+
+Status of This Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis Best Current Practice [Page 1]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Terminology .....................................................3
+ 3. The Transparency Principle ......................................3
+ 4. Protocol Conformance ............................................4
+ 4.1. Unexpected Flags and Data ..................................4
+ 4.2. Label Compression ..........................................4
+ 4.3. Unknown Resource Record Types ..............................4
+ 4.4. Packet Size Limits .........................................4
+ 4.4.1. TCP Transport .......................................5
+ 4.4.2. Extension Mechanisms for DNS (EDNS0) ................6
+ 4.4.3. IP Fragmentation ....................................6
+ 4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7
+ 5. DHCP's Interaction with DNS .....................................7
+ 5.1. Domain Name Server (DHCP Option 6) .........................7
+ 5.2. Domain Name (DHCP Option 15) ...............................8
+ 5.3. DHCP Leases ................................................8
+ 6. Security Considerations .........................................9
+ 6.1. Forgery Resilience .........................................9
+ 6.2. Interface Binding .........................................10
+ 6.3. Packet Filtering ..........................................10
+ 7. Acknowledgements ...............................................10
+ 8. References .....................................................11
+ 8.1. Normative References ......................................11
+ 8.2. Informative References ....................................12
+
+1. Introduction
+
+ Research has found ([SAC035], [DOTSE]) that many commonly used
+ broadband gateways (and similar devices) contain DNS proxies that are
+ incompatible in various ways with current DNS standards.
+
+ These proxies are usually simple DNS forwarders, but typically do not
+ have any caching capabilities. The proxy serves as a convenient
+ default DNS resolver for clients on the LAN, but relies on an
+ upstream resolver (e.g., at an ISP) to perform recursive DNS lookups.
+
+ Note that to ensure full DNS protocol interoperability it is
+ preferred that client stub resolvers should communicate directly with
+ full-feature, upstream recursive resolvers wherever possible.
+
+ That notwithstanding, this document describes the incompatibilities
+ that have been discovered and offers guidelines to implementors on
+ how to provide better interoperability in those cases where the
+ client must use the broadband gateway's DNS proxy.
+
+
+
+
+
+Bellis Best Current Practice [Page 2]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+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 [RFC2119].
+
+3. The Transparency Principle
+
+ It is not considered practical for a simple DNS proxy to implement
+ all current and future DNS features.
+
+ There are several reasons why this is the case:
+
+ o Broadband gateways usually have limited hardware resources.
+
+ o Firmware upgrade cycles are long, and many users do not routinely
+ apply upgrades when they become available.
+
+ o No one knows what those future DNS features will be or how they
+ might be implemented.
+
+ o Doing so would substantially complicate the configuration user
+ interface (UI) of the device.
+
+ Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0
+ below) are intended to be used as "hop-by-hop" mechanisms. If the
+ DNS proxy is considered to be such a "hop" in the resolution chain,
+ then for it to function correctly, it would need to be fully
+ compliant with all such mechanisms.
+
+ [SAC035] shows that the more actively a proxy participates in the DNS
+ protocol, the more likely it is that it will somehow interfere with
+ the flow of messages between the DNS client and the upstream
+ recursive resolvers.
+
+ The role of the proxy should therefore be no more and no less than to
+ receive DNS requests from clients on the LAN side, forward those
+ verbatim to one of the known upstream recursive resolvers on the WAN
+ side, and ensure that the whole response is returned verbatim to the
+ original client.
+
+ It is RECOMMENDED that proxies should be as transparent as possible,
+ such that any "hop-by-hop" mechanisms or newly introduced protocol
+ extensions operate as if the proxy were not there.
+
+ Except when required to enforce an active security or network policy
+ (such as maintaining a pre-authentication "walled garden"), end-users
+ SHOULD be able to send their DNS queries to specified upstream
+
+
+
+Bellis Best Current Practice [Page 3]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+ resolvers, thereby bypassing the proxy altogether. In this case, the
+ gateway SHOULD NOT modify the DNS request or response packets in any
+ way.
+
+4. Protocol Conformance
+
+4.1. Unexpected Flags and Data
+
+ The Transparency Principle above, when combined with Postel's
+ Robustness Principle [RFC0793], suggests that DNS proxies should not
+ arbitrarily reject or otherwise drop requests or responses based on
+ perceived non-compliance with standards.
+
+ For example, some proxies have been observed to drop any packet
+ containing either the "Authentic Data" (AD) or "Checking Disabled"
+ (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035]
+ originally specified that these unused "Z" flag bits "MUST" be zero.
+ However, these flag bits were always intended to be reserved for
+ future use, so refusing to proxy any packet containing these flags
+ (now that uses for those flags have indeed been defined) is not
+ appropriate.
+
+ Therefore, proxies MUST ignore any unknown DNS flags and proxy those
+ packets as usual.
+
+4.2. Label Compression
+
+ Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
+
+ Proxies MUST forward packets regardless of the presence or absence of
+ compressed labels therein.
+
+4.3. Unknown Resource Record Types
+
+ [RFC3597] requires that resolvers MUST handle Resource Records (RRs)
+ of unknown type transparently.
+
+ All requests and responses MUST be proxied regardless of the values
+ of the QTYPE and QCLASS fields.
+
+ Similarly, all responses MUST be proxied regardless of the values of
+ the TYPE and CLASS fields of any Resource Record therein.
+
+4.4. Packet Size Limits
+
+ [RFC1035] specifies that the maximum size of the DNS payload in a UDP
+ packet is 512 octets. Where the required portions of a response
+ would not fit inside that limit, the DNS server MUST set the
+
+
+
+Bellis Best Current Practice [Page 4]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+ "TrunCation" (TC) bit in the DNS response header to indicate that
+ truncation has occurred. There are however two standard mechanisms
+ (described in Sections 4.4.1 and 4.4.2) for transporting responses
+ larger than 512 octets.
+
+ Many proxies have been observed to truncate all responses at 512
+ octets, and others at a packet size related to the WAN MTU, in either
+ case doing so without correctly setting the TC bit.
+
+ Other proxies have been observed to remove the TC bit in server
+ responses that correctly had the TC bit set by the server.
+
+ If a DNS response is truncated but the TC bit is not set, then client
+ failures may result. In particular, a naive DNS client library might
+ suffer crashes due to reading beyond the end of the data actually
+ received.
+
+ Since UDP packets larger than 512 octets are now expected in normal
+ operation, proxies SHOULD NOT truncate UDP packets that exceed that
+ size. See Section 4.4.3 for recommendations for packet sizes
+ exceeding the WAN MTU.
+
+ If a proxy must unilaterally truncate a response, then the proxy MUST
+ set the TC bit. Similarly, proxies MUST NOT remove the TC bit from
+ responses.
+
+4.4.1. TCP Transport
+
+ Should a UDP query fail because of truncation, the standard fail-over
+ mechanism is to retry the query using TCP, as described in Section
+ 6.1.3.2 of [RFC1123].
+
+ Whilst TCP transport is not strictly mandatory, it is supported by
+ the vast majority of stub resolvers and recursive servers. Lack of
+ support in the proxy prevents this fail-over mechanism from working.
+
+ DNS proxies MUST therefore be prepared to receive and forward queries
+ over TCP.
+
+ Note that it is unlikely that a client would send a request over TCP
+ unless it had already received a truncated UDP response. Some
+ "smart" proxies have been observed to first forward any request
+ received over TCP to an upstream resolver over UDP, only for the
+ response to be truncated, causing the proxy to retry over TCP. Such
+ behaviour increases network traffic and causes delay in DNS
+ resolution since the initial UDP request is doomed to fail.
+
+
+
+
+
+Bellis Best Current Practice [Page 5]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+ Therefore, whenever a proxy receives a request over TCP, the proxy
+ SHOULD forward the query over TCP and SHOULD NOT attempt the same
+ query over UDP first.
+
+4.4.2. Extension Mechanisms for DNS (EDNS0)
+
+ The "Extension Mechanism for DNS" [RFC2671] was introduced to allow
+ the transport of larger DNS packets over UDP and also to allow for
+ additional request and response flags.
+
+ A client may send an OPT Resource Record (OPT RR) in the Additional
+ Section of a request to indicate that it supports a specific receive
+ buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used
+ by DNSSEC to indicate that DNSSEC-related RRs should be returned to
+ the client.
+
+ However, some proxies have been observed to either reject (with a
+ FORMERR response code) or black-hole any packet containing an OPT RR.
+ As per Section 4.1, proxies MUST NOT refuse to proxy such packets.
+
+4.4.3. IP Fragmentation
+
+ Support for UDP packet sizes exceeding the WAN MTU depends on the
+ gateway's algorithm for handling fragmented IP packets. Several
+ methods are possible:
+
+ 1. Fragments are dropped.
+
+ 2. Fragments are forwarded individually as they're received.
+
+ 3. Complete packets are reassembled on the gateway and then re-
+ fragmented (if necessary) as they're forwarded to the client.
+
+ Method 1 above will cause compatibility problems with EDNS0 unless
+ the DNS client is configured to advertise an EDNS0 buffer size
+ limited to the WAN MTU less the size of the IP header. Note that RFC
+ 2671 does recommend that the path MTU should be taken into account
+ when using EDNS0.
+
+ Also, whilst the EDNS0 specification allows for a buffer size of up
+ to 65535 octets, most common DNS server implementations do not
+ support a buffer size above 4096 octets.
+
+ Therefore (irrespective of which of the above methods is in use),
+ proxies SHOULD be capable of forwarding UDP packets up to a payload
+ size of at least 4096 octets.
+
+
+
+
+
+Bellis Best Current Practice [Page 6]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+ NB: in theory, IP fragmentation may also occur if the LAN MTU is
+ smaller than the WAN MTU, although the author has not observed such a
+ configuration in use on any residential broadband service.
+
+4.5. Secret Key Transaction Authentication for DNS (TSIG)
+
+ [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
+ requests and responses at the packet level.
+
+ Any modifications made to the DNS portions of a TSIG-signed query or
+ response packet (with the exception of the Query ID) will cause a
+ TSIG authentication failure.
+
+ DNS proxies MUST implement Section 4.7 of [RFC2845] and either
+ forward packets unchanged (as recommended above) or fully implement
+ TSIG.
+
+ As per Section 4.3, DNS proxies MUST be capable of proxying packets
+ containing TKEY [RFC2930] Resource Records.
+
+ NB: any DNS proxy (such as those commonly found in WiFi hotspot
+ "walled gardens") that transparently intercepts all DNS queries and
+ that returns unsigned responses to signed queries, will also cause
+ TSIG authentication failures.
+
+5. DHCP's Interaction with DNS
+
+ Whilst this document is primarily about DNS proxies, most consumers
+ rely on DHCP [RFC2131] to obtain network configuration settings.
+ Such settings include the client machine's IP address, subnet mask,
+ and default gateway, but also include DNS-related settings.
+
+ It is therefore appropriate to examine how DHCP affects client DNS
+ configuration.
+
+5.1. Domain Name Server (DHCP Option 6)
+
+ Most gateways default to supplying their own IP address in the DHCP
+ "Domain Name Server" option [RFC2132]. The net result is that
+ without explicit re-configuration many DNS clients will, by default,
+ send queries to the gateway's DNS proxy. This is understandable
+ behaviour given that the correct upstream settings are not usually
+ known at boot time.
+
+
+
+
+
+
+
+
+Bellis Best Current Practice [Page 7]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+ Most gateways learn their own DNS settings via values supplied by an
+ ISP via DHCP or PPP over the WAN interface. However, whilst many
+ gateways do allow the device administrator to override those values,
+ some gateways only use those supplied values to affect the proxy's
+ own forwarding function, and do not offer these values via DHCP.
+
+ When using such a device, the only way to avoid using the DNS proxy
+ is to hard-code the required values in the client operating system.
+ This may be acceptable for a desktop system but it is inappropriate
+ for mobile devices that are regularly used on many different
+ networks.
+
+ As per Section 3, end-users SHOULD be able to send their DNS queries
+ directly to specified upstream resolvers, ideally without hard-coding
+ those settings in their stub resolver.
+
+ It is therefore RECOMMENDED that gateways SHOULD support device-
+ administrator configuration of values for the "Domain Name Server"
+ DHCP option.
+
+5.2. Domain Name (DHCP Option 15)
+
+ A significant amount of traffic to the DNS Root Name Servers is for
+ invalid top-level domain names, and some of that traffic can be
+ attributed to particular equipment vendors whose firmware defaults
+ this DHCP option to specific values.
+
+ Since no standard exists for a "local" scoped domain name suffix, it
+ is RECOMMENDED that the default value for this option SHOULD be
+ empty, and that this option MUST NOT be sent to clients when no value
+ is configured.
+
+5.3. DHCP Leases
+
+ It is noted that some DHCP servers in broadband gateways offer, by
+ default, their own IP address for the "Domain Name Server" option (as
+ described above) but then automatically start offering the upstream
+ servers' addresses once they've been learnt over the WAN interface.
+
+ In general, this behaviour is highly desirable, but the effect for
+ the end-user is that the settings used depend on whether the DHCP
+ lease was obtained before or after the WAN link was established.
+
+ If the DHCP lease is obtained whilst the WAN link is down, then the
+ DHCP client (and hence the DNS client) will not receive the correct
+ values until the DHCP lease is renewed.
+
+
+
+
+
+Bellis Best Current Practice [Page 8]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+ Whilst no specific recommendations are given here, vendors may wish
+ to give consideration to the length of DHCP leases and to whether
+ some mechanism for forcing a DHCP lease renewal might be appropriate.
+
+ Another possibility is that the learnt upstream values might be
+ persisted in non-volatile memory such that on reboot the same values
+ can be automatically offered via DHCP. However, this does run the
+ risk that incorrect values are initially offered if the device is
+ moved or connected to another ISP.
+
+ Alternatively, the DHCP server might only issue very short (i.e., 60
+ second) leases while the WAN link is down, only reverting to more
+ typical lease lengths once the WAN link is up and the upstream DNS
+ servers are known. Indeed, with such a configuration it may be
+ possible to avoid the need to implement a DNS proxy function in the
+ broadband gateway at all.
+
+6. Security Considerations
+
+ This document introduces no new protocols. However, there are some
+ security-related recommendations for vendors that are listed here.
+
+6.1. Forgery Resilience
+
+ Whilst DNS proxies are not usually full-feature resolvers, they
+ nevertheless share some characteristics with them.
+
+ Notwithstanding the recommendations above about transparency, many
+ DNS proxies are observed to pick a new Query ID for outbound requests
+ to ensure that responses are directed to the correct client.
+
+ NB: changing the Query ID is acceptable and compatible with proxying
+ TSIG-signed packets since the TSIG signature calculation is based on
+ the original message ID, which is carried in the TSIG RR.
+
+ It has been standard guidance for many years that each DNS query
+ should use a randomly generated Query ID. However, many proxies have
+ been observed picking sequential Query IDs for successive requests.
+
+ It is strongly RECOMMENDED that DNS proxies follow the relevant
+ recommendations in [RFC5452], particularly those in Section 9.2
+ relating to randomisation of Query IDs and source ports. This also
+ applies to source port selection within any NAT function.
+
+ If a DNS proxy is running on a broadband gateway with NAT that is
+ compliant with [RFC4787], then it SHOULD also follow the
+ recommendations in Section 10 of [RFC5452] concerning how long DNS
+ state is kept.
+
+
+
+Bellis Best Current Practice [Page 9]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+6.2. Interface Binding
+
+ Some gateways have been observed to have their DNS proxy listening on
+ both internal (LAN) and external (WAN) interfaces. In this
+ configuration, it is possible for the proxy to be used to mount
+ reflector attacks as described in [RFC5358].
+
+ The DNS proxy in a gateway SHOULD NOT, by default, be accessible from
+ the WAN interfaces of the device.
+
+6.3. Packet Filtering
+
+ The Transparency and Robustness Principles are not entirely
+ compatible with the deep packet-inspection features of security
+ appliances such as firewalls, which are intended to protect systems
+ on the inside of a network from rogue traffic.
+
+ However, a clear distinction may be made between traffic that is
+ intrinsically malformed and that which merely contains unexpected
+ data.
+
+ Examples of malformed packets that MAY be dropped include:
+
+ o invalid compression pointers (i.e., those that point outside of
+ the current packet or that might cause a parsing loop)
+
+ o incorrect counts for the Question, Answer, Authority, and
+ Additional Sections (although care should be taken where
+ truncation is a possibility)
+
+ Dropped packets will cause the client to repeatedly retransmit the
+ original request, with the client only detecting the error after
+ several retransmit intervals.
+
+ In these circumstances, proxies SHOULD synthesise a suitable DNS
+ error response to the client (i.e., SERVFAIL) instead of dropping the
+ packet completely. This will allow the client to detect the error
+ immediately.
+
+7. Acknowledgements
+
+ The author would particularly like to acknowledge the assistance of
+ Lisa Phifer of Core Competence. In addition, the author is grateful
+ for the feedback from the members of the DNSEXT Working Group.
+
+
+
+
+
+
+
+Bellis Best Current Practice [Page 10]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, September 1981.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
+ and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
+ RFC 2131, March 1997.
+
+ [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ Extensions", RFC 2132, March 1997.
+
+ [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.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
+ Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+ October 2008.
+
+
+
+
+
+Bellis Best Current Practice [Page 11]
+
+RFC 5625 DNS Proxy Implementation Guidelines August 2009
+
+
+ [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
+ Resilient against Forged Answers", RFC 5452, January 2009.
+
+8.2. Informative References
+
+ [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
+ Routers", February 2008,
+ .
+
+ [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
+ Broadband Routers and Firewalls", September 2008,
+ .
+
+Author's Address
+
+ Ray Bellis
+ Nominet UK
+ Edmund Halley Road
+ Oxford OX4 4DQ
+ United Kingdom
+
+ Phone: +44 1865 332211
+ EMail: ray.bellis@nominet.org.uk
+ URI: http://www.nominet.org.uk/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis Best Current Practice [Page 12]
+