284 lines
9.4 KiB
Plaintext
284 lines
9.4 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
INTERNET-DRAFT M. Sawyer
|
||
A. Gustafsson
|
||
M. Graff
|
||
Nominum
|
||
<draft-msawyer-dnsext-edns-attributes-00.txt> 15 November 2000
|
||
|
||
Handling of unknown EDNS0 attributes
|
||
|
||
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
|
||
|
||
This draft expires on May 15, 2001.
|
||
|
||
Abstract
|
||
|
||
This document provides a clarification of the EDNS0 protocol,
|
||
specifying the behavior of servers when they receive unknown EDNS
|
||
options.
|
||
|
||
1.1 - Introduction
|
||
|
||
Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms
|
||
[RFC2671] is helpful.
|
||
|
||
EDNS0 [RFC2671] specifies a general framework for extending the
|
||
packet format used by the Domain Name System protocol. The framework
|
||
provides for a series of additional options, identified by a 16 bit
|
||
attribute ID and arbitrary sized payload. Any number of these
|
||
additional options can be specified in the DNS packet. As specified,
|
||
the current scheme has drawbacks:
|
||
|
||
|
||
|
||
Expires May 2001 [Page 1]
|
||
|
||
INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
|
||
|
||
|
||
- It provides no way for implementers to deploy test systems with
|
||
experimental features prior to approval of the feature and assignment
|
||
of an attribute ID.
|
||
|
||
- It provides no specification on what an application should do when
|
||
receiving unrecognized options.
|
||
|
||
This draft proposes to clarify the original EDNS0 draft [RFC2671],
|
||
addressing these drawbacks.
|
||
|
||
1.2 - Requirements
|
||
|
||
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 - Protocol changes:
|
||
|
||
This document updates [RFC2671]. Conformance to this specification
|
||
is claimed by specifying EDNS version 1.
|
||
|
||
2.1 - Advisory and Required Options:
|
||
|
||
|
||
Some potential uses of EDNS options are advisory in nature, For
|
||
example, a hypothetical option indicating that "I understand frobozz
|
||
compression in responses" can be safely ignored by the recipient,
|
||
which will then simply not use frobozz compression. Others uses of
|
||
options, such as a hypothetical "send only cryptographically verified
|
||
data in responses" option, cannot be safely ignored, and should cause
|
||
the request to fail if not understood by the receiver.
|
||
|
||
This suggests that we need two types of options, "advisory" options
|
||
(that can be ignored) and "required" options (that can not). Because
|
||
a server needs to classify options as advisory or required even if
|
||
they were not yet defined when the server was implemented, the type
|
||
of an option must be evident without knowing its internal structure.
|
||
This is achieved by splitting the option type codes into two ranges:
|
||
options with type code 0x0000-0x7FFF are considered "advisory", and
|
||
options with type code 0x8000-0xFFFF are considered "required".
|
||
|
||
2.2 - Handling of Unknown and Unsupported EDNS Option Types
|
||
|
||
When a server receives an unknown or unsupported advisory option in a
|
||
request or response message, it MUST ignore the unknown option and
|
||
process the message as if the option was not present. In the reply,
|
||
it SHOULD include an advisory UNSUPPORTED option (TBD).
|
||
|
||
|
||
|
||
|
||
Expires May 2001 [Page 2]
|
||
|
||
INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
|
||
|
||
|
||
When a server receives an unknown or unsupported required option in a
|
||
request message, it MUST NOT act on the request, and it MUST return
|
||
an error response with the extended result code BADOPT (TBD). In the
|
||
reply, it SHOULD include an advisory UNSUPPORTED option.
|
||
|
||
When a server receives an unknown or unsupported required option in a
|
||
response message, it MUST ignore the response. The server SHOULD
|
||
continue to parse options after the unknown option, including a list
|
||
of all unsupported options in the UNSUPPORTED option in the reply.
|
||
|
||
Servers MAY include SUPPORTED options in replies to messages, listing
|
||
option codes which they understand. This message SHOULD contain all
|
||
option codes the server understands. This facility MAY NOT be used
|
||
in place of the UNSUPPORTED option to identify unsupported options in
|
||
replies.
|
||
|
||
Clients MAY include SUPPORTED or UNSUPPORTED options in queries.
|
||
UNSUPPORTED options SHOULD only list those option codes which the
|
||
client has received in previous replies from the server, not an
|
||
inclusive list of all unsupported option codes.
|
||
|
||
2.3 - Use of Reserved Options for Development
|
||
|
||
Option codes in the range of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF
|
||
are considered "reserved" and shall not be assigned to new protocols.
|
||
Software vendors SHOULD use these options for testing of protocols
|
||
under development, provided the following conditions are met:
|
||
|
||
- Vendors MUST NOT ship any versions of the software which use option
|
||
codes in this range. They MUST delay shipping software with the new
|
||
options until IANA has assigned permanent option codes.
|
||
|
||
- Vendors MUST NOT place development servers on the live internet
|
||
which send options in this range to remote servers or which
|
||
understand options in this range as having any meaning.
|
||
|
||
3.1 - SUPPORTED and UNSUPPORTED options
|
||
|
||
The SUPPORTED and UNSUPPORTED options contain a list of option codes
|
||
which the server or client does or doesn't support. The list
|
||
contains, in network byte order, the supported or unsupported 16 bit
|
||
option codes:
|
||
|
||
1 1 1 1 1 1
|
||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
| SUPPORTED or UNSUPPORTED (TBD) |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
|
||
|
||
|
||
Expires May 2001 [Page 3]
|
||
|
||
INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
|
||
|
||
|
||
| LENGTH (number of options * 2) |
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
/ OPTION CODE(s) /
|
||
/ /
|
||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||
|
||
Sending a SUPPORTED option with a zero-length payload indicates that
|
||
the server or client supports no EDNS options, so none should be
|
||
used. UNSUPPORTED options with zero-length payloads SHOULD NOT be
|
||
sent, as such a message is meaningless.
|
||
|
||
4 - IANA considerations
|
||
|
||
When allocating EDNS Option Codes, the IANA shall henceforth require
|
||
the RFC defining the new option to specify whether the option is an
|
||
"advisory" or a "required" option. The option code for an advisory
|
||
option shall be allocated from the range 0x0000-0x7FEF, and the code
|
||
for a required option shall be allocated from the range
|
||
0x8000-0xFFEF.
|
||
|
||
Option codes in the ranges of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF
|
||
are considered "reserved."
|
||
|
||
The IANA is hereby requested to assign EDNS Version Number 1 to this
|
||
specification, to assign a new extended RCODE value for BADOPT, and
|
||
to assign advisory option codes for UNSUPPORTED and SUPPORTED.
|
||
|
||
|
||
5 - Security considerations
|
||
|
||
This document provides a mechanism for users to override the default
|
||
behavior of the server when accessing data from its internal zone
|
||
databases. Software developers and administrators should use some
|
||
care when enabling these options, as they may provide outside users
|
||
the ability to retrieve information otherwise not available.
|
||
|
||
6 - Acknowledgments
|
||
|
||
The authors would like to thank Olafur Gudmundsson for his input on
|
||
this draft.
|
||
|
||
7 - References
|
||
|
||
[RFC2119] S. Brander, ``Key words for use in RFCs to Indicate
|
||
Requirement Levels,'' RFC 2119, ISI, November 1997.
|
||
|
||
[RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC
|
||
2671, ISI, August, 1999
|
||
|
||
|
||
|
||
Expires May 2001 [Page 4]
|
||
|
||
INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
|
||
|
||
|
||
Author's Address
|
||
|
||
Michael Sawyer
|
||
Nominum, Inc.
|
||
950 Charter St.
|
||
Redwood City, CA 94063
|
||
Phone: +1-650-779-6021
|
||
michael.sawyer@nominum.com
|
||
|
||
Andreas Gustafsson
|
||
Nominum, Inc.
|
||
950 Charter St.
|
||
Redwood City, CA 94063
|
||
Phone: +1-650-779-6004
|
||
andreas.gustafsson@nominum.com
|
||
|
||
Michael Graff
|
||
Nominum, Inc.
|
||
950 Charter St.
|
||
Redwood City, CA 94063
|
||
Phone: +1-650-779-6034
|
||
michael.graff@nominum.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Expires May 2001 [Page 5]
|
||
|