doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc3225.txt b/doc/rfc/rfc3225.txt
new file mode 100644
index 0000000..13e6768
--- /dev/null
+++ b/doc/rfc/rfc3225.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                          D. Conrad
+Request for Comments: 3225                                 Nominum, Inc.
+Category: Standards Track                                  December 2001
+
+
+                 Indicating Resolver Support of DNSSEC
+
+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 (2001).  All Rights Reserved.
+
+Abstract
+
+   In order to deploy DNSSEC (Domain Name System Security Extensions)
+   operationally, DNSSEC aware servers should only perform automatic
+   inclusion of DNSSEC RRs when there is an explicit indication that the
+   resolver can understand those RRs.  This document proposes the use of
+   a bit in the EDNS0 header to provide that explicit indication and
+   describes the necessary protocol changes to implement that
+   notification.
+
+1. Introduction
+
+   DNSSEC [RFC2535] has been specified to provide data integrity and
+   authentication to security aware resolvers and applications through
+   the use of cryptographic digital signatures.  However, as DNSSEC is
+   deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
+   servers.  In such situations, the DNSSEC-aware server (responding to
+   a request for data in a signed zone) will respond with SIG, KEY,
+   and/or NXT records.  For reasons described in the subsequent section,
+   such responses can have significant negative operational impacts for
+   the DNS infrastructure.
+
+   This document discusses a method to avoid these negative impacts,
+   namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
+   NXT RRs when there is an explicit indication from the resolver that
+   it can understand those RRs.
+
+   For the purposes of this document, "DNSSEC security RRs" are
+   considered RRs of type SIG, KEY, or NXT.
+
+
+
+Conrad                      Standards Track                     [Page 1]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+   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. Rationale
+
+   Initially, as DNSSEC is deployed, the vast majority of queries will
+   be from resolvers that are not DNSSEC aware and thus do not
+   understand or support the DNSSEC security RRs.  When a query from
+   such a resolver is received for a DNSSEC signed zone, the DNSSEC
+   specification indicates the nameserver must respond with the
+   appropriate DNSSEC security RRs.  As DNS UDP datagrams are limited to
+   512 bytes [RFC1035], responses including DNSSEC security RRs have a
+   high probability of resulting in a truncated response being returned
+   and the resolver retrying the query using TCP.
+
+   TCP DNS queries result in significant overhead due to connection
+   setup and teardown.  Operationally, the impact of these TCP queries
+   will likely be quite detrimental in terms of increased network
+   traffic (typically five packets for a single query/response instead
+   of two), increased latency resulting from the additional round trip
+   times, increased incidences of queries failing due to timeouts, and
+   significantly increased load on nameservers.
+
+   In addition, in preliminary and experimental deployment of DNSSEC,
+   there have been reports of non-DNSSEC aware resolvers being unable to
+   handle responses which contain DNSSEC security RRs, resulting in the
+   resolver failing (in the worst case) or entire responses being
+   ignored (in the better case).
+
+   Given these operational implications, explicitly notifying the
+   nameserver that the client is prepared to receive (if not understand)
+   DNSSEC security RRs would be prudent.
+
+   Client-side support of DNSSEC is assumed to be binary -- either the
+   client is willing to receive all DNSSEC security RRs or it is not
+   willing to accept any.  As such, a single bit is sufficient to
+   indicate client-side DNSSEC support.  As effective use of DNSSEC
+   implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
+   enhanced DNS header) are scarce, and there may be situations in which
+   non-compliant caching or forwarding servers inappropriately copy data
+   from classic headers as queries are passed on to authoritative
+   servers, the use of a bit from the EDNS0 header is proposed.
+
+   An alternative approach would be to use the existence of an EDNS0
+   header as an implicit indication of client-side support of DNSSEC.
+   This approach was not chosen as there may be applications in which
+   EDNS0 is supported but in which the use of DNSSEC is inappropriate.
+
+
+
+Conrad                      Standards Track                     [Page 2]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+3. Protocol Changes
+
+   The mechanism chosen for the explicit notification of the ability of
+   the client to accept (if not understand) DNSSEC security RRs is using
+   the most significant bit of the Z field on the EDNS0 OPT header in
+   the query.  This bit is referred to as the "DNSSEC OK" (DO) bit.  In
+   the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
+   the third and fourth bytes of the "extended RCODE and flags" portion
+   of the EDNS0 OPT meta-RR, structured as follows:
+
+                +0 (MSB)                +1 (LSB)
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      0: |   EXTENDED-RCODE      |       VERSION         |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      2: |DO|                    Z                       |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   Setting the DO bit to one in a query indicates to the server that the
+   resolver is able to accept DNSSEC security RRs.  The DO bit cleared
+   (set to zero) indicates the resolver is unprepared to handle DNSSEC
+   security RRs and those RRs MUST NOT be returned in the response
+   (unless DNSSEC security RRs are explicitly queried for).  The DO bit
+   of the query MUST be copied in the response.
+
+   More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
+   or NXT RRs to authenticate a response as specified in [RFC2535]
+   unless the DO bit was set on the request.  Security records that
+   match an explicit SIG, KEY, NXT, or ANY query, or are part of the
+   zone data for an AXFR or IXFR query, are included whether or not the
+   DO bit was set.
+
+   A recursive DNSSEC-aware server MUST set the DO bit on recursive
+   requests, regardless of the status of the DO bit on the initiating
+   resolver request.  If the initiating resolver request does not have
+   the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
+   security RRs before returning the data to the client, however cached
+   data MUST NOT be modified.
+
+   In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
+   to a query that has the DO bit set, the resolver SHOULD NOT expect
+   DNSSEC security RRs and SHOULD retry the query without EDNS0 in
+   accordance with section 5.3 of [RFC2671].
+
+
+
+
+
+
+
+
+
+Conrad                      Standards Track                     [Page 3]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+Security Considerations
+
+   The absence of DNSSEC data in response to a query with the DO bit set
+   MUST NOT be taken to mean no security information is available for
+   that zone as the response may be forged or a non-forged response of
+   an altered (DO bit cleared) query.
+
+IANA Considerations
+
+   EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
+   these bits are encoded into the TTL field of the OPT record (RFC2671
+   section 4.6).
+
+   This document reserves one of these bits as the OK bit.  It is
+   requested that the left most bit be allocated.  Thus the USE of the
+   OPT record TTL field would look like
+
+                +0 (MSB)                +1 (LSB)
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      0: |   EXTENDED-RCODE      |       VERSION         |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      2: |DO|                    Z                       |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+Acknowledgements
+
+   This document is based on a rough draft by Bob Halley with input from
+   Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
+   Rob Austein, Steve Bellovin, and Erik Nordmark.
+
+References
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specifications", 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.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+             2671, August 1999.
+
+
+
+
+
+Conrad                      Standards Track                     [Page 4]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+Author's Address
+
+   David Conrad
+   Nominum Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+   USA
+
+   Phone: +1 650 381 6003
+   EMail: david.conrad@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conrad                      Standards Track                     [Page 5]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conrad                      Standards Track                     [Page 6]
+