diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3225.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3225.txt | 339 |
1 files changed, 0 insertions, 339 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3225.txt b/contrib/bind9/doc/rfc/rfc3225.txt deleted file mode 100644 index 13e6768..0000000 --- a/contrib/bind9/doc/rfc/rfc3225.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -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] - |
