draft-ietf-dnsext-dnssec-okbit-02.txt   draft-ietf-dnsext-dnssec-okbit-03.txt 
INTERNET-DRAFT David Conrad INTERNET-DRAFT David Conrad
draft-ietf-dnsext-dnssec-okbit-02.txt Nominum Inc. draft-ietf-dnsext-dnssec-okbit-03.txt Nominum, Inc.
May, 2001 October, 2001
Indicating Resolver Support of DNSSEC Indicating Resolver Support of DNSSEC
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
In order to deploy DNSSEC operationally, DNSSEC aware servers should In order to deploy DNSSEC operationally, DNSSEC aware servers should
only perform automatic inclusion of DNSSEC RRs when there is an only perform automatic inclusion of DNSSEC RRs when there is an
explicit indication that the resolver can understand those RRs. This explicit indication that the resolver can understand those RRs. This
document proposes the use of a bit in the EDNS0 header to provide document proposes the use of a bit in the EDNS0 header to provide
that explicit indication and the necessary protocol changes to that explicit indication and describes the necessary protocol changes
implement that notification. to implement that notification.
1. Introduction 1. Introduction
DNSSEC [RFC2535] has been specified to provide data integrity and DNSSEC [RFC2535] has been specified to provide data integrity and
authentication to security aware resolvers and applications through authentication to security aware resolvers and applications through
the use of cryptographic digital signatures. However, as DNSSEC is the use of cryptographic digital signatures. However, as DNSSEC is
deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
servers. In such situations, the DNSSEC-aware server (responding to servers. In such situations, the DNSSEC-aware server (responding to
a request for data in a signed zone) will respond with SIG, KEY, a request for data in a signed zone) will respond with SIG, KEY,
and/or NXT records. For reasons described in the subsequent section, and/or NXT records. For reasons described in the subsequent section,
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Client-side support of DNSSEC is assumed to be binary -- either the 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 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 willing to accept any. As such, a single bit is sufficient to
indicate client-side DNSSEC support. As effective use of DNSSEC indicate client-side DNSSEC support. As effective use of DNSSEC
implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
enhanced DNS header) are scarce, and there may be situations in which enhanced DNS header) are scarce, and there may be situations in which
non-compliant caching or forwarding servers inappropriately copy data non-compliant caching or forwarding servers inappropriately copy data
from classic headers as queries are passed on to authoritative from classic headers as queries are passed on to authoritative
servers, the use of a bit from the EDNS0 header is proposed. servers, the use of a bit from the EDNS0 header is proposed.
An alternative approach would be to use the existance of an EDNS0 An alternative approach would be to use the existence of an EDNS0
header as an implicit indication of client-side support of DNSSEC. header as an implicit indication of client-side support of DNSSEC.
This approach was not chosen as there may be applications in which This approach was not chosen as there may be applications in which
EDNS0 is supported but in which the use of DNSSEC is inappropriate. EDNS0 is supported but in which the use of DNSSEC is inappropriate.
3. Protocol Changes 3. Protocol Changes
The mechanism chosen for the explicit notification of the ability of The mechanism chosen for the explicit notification of the ability of
the client to accept (if not understand) DNSSEC security RRs is using 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 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 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 context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
the the third and fourth bytes of the "extended RCODE and flags" the third and fourth bytes of the "extended RCODE and flags" portion
portion of the EDNS0 OPT meta-RR, structured as follows: of the EDNS0 OPT meta-RR, structured as follows:
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION | 0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO| Z | 2: |DO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Setting the DO bit to one in a query indicates to the server that the 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 resolver is able to accept DNSSEC security RRs. The DO bit cleared
(set to zero) indicates the resolver is unprepared to handle DNSSEC (set to zero) indicates the resolver is unprepared to handle DNSSEC
security RRs and those RRs MUST NOT be returned in the response security RRs and those RRs MUST NOT be returned in the response
(unless DNSSEC security RRs are explicitly queried for). (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, More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
or NXT RRs to authenticate a response as specified in [RFC2535] or NXT RRs to authenticate a response as specified in [RFC2535]
unless the DO bit was set on the request. Security records that match 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 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 for an AXFR or IXFR query, are included whether or not the DO bit was
set. set.
A recursive DNSSEC-aware server MUST set the DO bit on recursive A recursive DNSSEC-aware server MUST set the DO bit on recursive
requests, regardless of the status of the DO bit on the initiating requests, regardless of the status of the DO bit on the initiating
resolver request. If the initiating resolver request does not have resolver request. If the initiating resolver request does not have
the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
security RRs before returning the data to the client, however cached security RRs before returning the data to the client, however cached
data MUST NOT be modified. data MUST NOT be modified.
In the event a server returns a NOTIMP, FORMERR or SERVFAIL response 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 to a query that has the DO bit set, the resolver SHOULD NOT expect
DNSSEC security RRs and SHOULD retry the query without the EDNS0 in DNSSEC security RRs and SHOULD retry the query without EDNS0 in
accordance with section 5.3 of [RFC2671]. accordance with section 5.3 of [RFC2671].
Security Considerations Security Considerations
The absence of DNSSEC data in response to a query with the DO bit set 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 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 that zone as the response may be forged or a non-forged response of
an altered (DO bit cleared) query. an altered (DO bit cleared) query.
IANA considerations: IANA considerations:
EDNS0[RFC2761] defines 16 bits as extened flags in the OPT record, EDNS0[RFC2671] defines 16 bits as extended flags in the OPT record,
these bits are encoded into the TTL field of the OPT record (RFC2761 these bits are encoded into the TTL field of the OPT record (RFC2671
section 4.6). section 4.6).
This document reserves one of these bits as the OK bit. It is 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 requested that the left most bit be allocated. Thus the USE of the
OPT record TTL field would look like OPT record TTL field would look like
+0 (MSB) +1 (LSB) +0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION | 0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
skipping to change at page 5, line 14 skipping to change at page 5, line 16
August 1999 August 1999
Author's Address Author's Address
David Conrad David Conrad
Nominum Inc. Nominum Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 779 6003 Phone: +1 650 381 6003
Email: david.conrad@nominum.com Email: david.conrad@nominum.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/