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

From: [email-masked]
Date: Tue, 23 Oct 2001 07:02:16 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Indicating Resolver Support of DNSSEC
	Author(s)	: D. Conrad
	Filename	: draft-ietf-dnsext-dnssec-okbit-03.txt
	Pages		: 5
	Date		: 22-Oct-01
	
In order to deploy DNSSEC 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 the necessary protocol changes to
implement that notification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-dnssec-okbit-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dnssec-okbit-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 23 Oct 2001 10:27:57 -0400 (EDT)

> 	Filename	: draft-ietf-dnsext-dnssec-okbit-03.txt

This document has been sitting in the RFC editors queue for some time
while we finished creating a registry for the DNS header bits. 

There are two changes from the prior version
1. Minor edits for clarity. 

2. The document now specifies that OK bit MUST be copied from the 
EDNS query header to the ENDS answer header.
The prior version was silent on this issue.
This change was prompted by an implementor clarification request to the
author. 

Does any member of the working group object to the changes? 
(see diff of all text changes below)

The WGLC will finish on October 31 at 23:00 UTC. 

	Olafur 

--- ok-02.txt	Tue Oct 23 10:21:05 2001
+++ ok-03.txt	Tue Oct 23 10:21:11 2001
@@ -35,8 +35,8 @@
    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 the necessary protocol changes to
-   implement that notification.
+   that explicit indication and describes the necessary protocol changes
+   to implement that notification.
 
 1. Introduction
 
@@ -113,7 +113,7 @@
    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 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.
    This approach was not chosen as there may be applications in which
    EDNS0 is supported but in which the use of DNSSEC is inappropriate.
@@ -125,8 +125,8 @@
    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 the third and fourth bytes of the "extended RCODE and flags"
-   portion of the EDNS0 OPT meta-RR, structured as follows:
+   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)
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
@@ -139,7 +139,8 @@
    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).
+   (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]
@@ -156,14 +157,14 @@
    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 the EDNS0 in
+   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].
 
 Security Considerations
@@ -175,8 +176,8 @@
 
 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
+   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
@@ -227,7 +228,7 @@
    Redwood City, CA 94063
    USA
 
-   Phone: +1 650 779 6003
+   Phone: +1 650 381 6003
 
    Email: [email-masked]

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Randy Bush <[email-masked]>
Date: Wed, 24 Oct 2001 10:33:34 -0700

> This change was prompted by an implementor clarification request to the

i think this was a good change

randy, with chair hat off