draft-ietf-dnsext-dnssec-okbit-00.txt   draft-ietf-dnsext-dnssec-okbit-01.txt 
INTERNET-DRAFT David Conrad INTERNET-DRAFT David Conrad
draft-ietf-dnsext-dnssec-okbit-00.txt Nominum Inc. draft-ietf-dnsext-dnssec-okbit-01.txt Nominum Inc.
August, 2000 November, 2000
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 33 skipping to change at page 1, line 33
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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 respond with DNSSEC RRs when there is an explicit indication only perform automatic inclusion of DNSSEC RRs when there is an
that the resolver can understand those RRs. This document proposes explicit indication that the resolver can understand those RRs. This
the use of a bit in the EDNS0 header to provide that explicit document proposes the use of a bit in the EDNS0 header to provide
indication and the necessary protocol changes to implement that that explicit indication and the necessary protocol changes to
notification. 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 36 skipping to change at page 3, line 36
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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).
More explicitly, in order to explicitly indicate DNSSEC security RRs More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
are acceptible to the resolver, DNSSEC-aware nameservers (both BASIC or NXT RRs to authenticate a response as specified in [RFC2535]
and FULL according to [RFC2535] definitions) MUST NOT add DNSSEC unless the DO bit was set on the request. Security records that match
security RRs to any section of a response unless at least one of the an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data
following is true: for an AXFR or IXFR query, are included whether or not the DO bit was
set.
1) The DO bit of the query EDNS0 header was set on the request,
indicating that the client would like DNSSEC security RRs.
2) The query type is SIG, KEY, or NXT and the RRs added match the
query name and query type.
In case 1), response generation is as indicated in [RFC2535].
In case 2), only those RRs which match the query name and query type
are added.
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 NOTIMPL, 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 the 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.
 End of changes. 

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