340 lines
11 KiB
Plaintext
340 lines
11 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|