wdiff draft-ietf-dnsext-dnssec-okbit-02.txt draft-ietf-dnsext-dnssec-okbit-03.txt

INTERNET-DRAFT David Conrad
draft-ietf-dnsext-dnssec-okbit-02.txt Nominum Inc.
May, 2001A new Request for Comments is now available in online RFC libraries.

RFC 3225

Title: Indicating Resolver Support of DNSSEC

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract
Author(s): D. Conrad
Status: Standards Track
Date: December 2001
Mailbox: david.conrad@nominum.com
Pages: 6
Characters: 11548
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-dnsext-dnssec-okbit-03.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc3225.txt

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.

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 product 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 Extensions Working Group 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
IETF.

This is not
willing to accept any. As such, now a single bit is sufficient to
indicate client-side DNSSEC support. As effective use of DNSSEC
implies the need of EDNS0 [RFC2671], bits in Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the "classic" (non-EDNS
enhanced DNS header) are scarce, Internet community, 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 requests discussion and suggestions
for improvements. Please refer to use the existance of an EDNS0
header as an implicit indication of client-side support current edition 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.

3.
"Internet Official Protocol Changes

The mechanism chosen Standards" (STD 1) for the explicit notification
standardization state and status of the ability this protocol. Distribution
of
the client to accept (if not understand) DNSSEC security RRs this memo is using
the most significant bit of the Z field on the EDNS0 OPT header in
the query. unlimited.

This bit announcement is referred sent 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 the third IETF list 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 RFC-DIST list.
Requests 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).

More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
or NXT RRs added 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 deleted from the client, however cached
data MUST NOT IETF distribution list
should be modified.

In the event a server returns a NOTIMP, FORMERR or SERVFAIL response sent 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
accordance with section 5.3 of [RFC2671].

Security Considerations

The absence of DNSSEC data in response IETF-REQUEST@IETF.ORG. Requests to a query with the DO bit set
MUST NOT be taken
added 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[RFC2761] defines 16 bits as extened flags in the OPT record,
these bits are encoded into the TTL field of the OPT record (RFC2761
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

Acknowledgements

This document is based on a rough draft by Bob Halley with input deleted 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",
RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", 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

Author's Address

David Conrad
Nominum Inc.
950 Charter Street
Redwood City, CA 94063
USA

Phone: +1 650 779 6003

Email: david.conrad@nominum.com

Full Copyright Statement

This document and translations of it may the RFC-DIST distribution list should
be copied and furnished sent to
others, and derivative works that comment RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or otherwise explain it
or assist in its implmentation 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 EMAIL may not be modified in any way, such as obtained by removing
the copyright notice or references sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the Internet Society or other
Internet organizations, except as needed message body
help: ways_to_get_rfcs. For example:

To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the purpose
author of
developing Internet standards in which case the procedures for
copyrights defined RFC in the Internet Standards process must be
followed, question, or as required to translate it into languages other than
English.

The limited permissions granted above RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are perpetual and will not for
unlimited distribution.echo
Submissions for Requests for Comments should 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." sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.