.\" $Id: draft-ietf-dnsext-edns0dot5.ms,v 1.4 2000/02/22 22:48:07 sra Exp $ .\" .\" %% draft_name ::= draft-ietf-dnsext-edns0dot5 .\" %% draft_number ::= 00 .\" %% author_foot ::= Austein & Alvestrand .\" %% author ::= R. Austein .\" %% author ::= InterNetShare.com, Inc. .\" %% author ::= H. Alvestrand .\" %% author ::= EDB MaXware AS .\" .\" %%BEGIN%% .pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LH draft-ietf-dnsext-edns0dot5-00.txt .ds CH .ds RH February 2000 .ds LF Austein & Alvestrand .ds CF Expires 28 August 2000 .ds RF [Page %] .hy 0 .ad l .sp 2 Network Working Group R. Austein draft-ietf-dnsext-edns0dot5-00.txt InterNetShare.com, Inc. H. Alvestrand EDB MaXware AS February 2000 .\" %%END%% .sp 2 .ce A Proposed Enhancement to the EDNS0 Version Mechanism .sp 2 .fi .ne 4 Status of this document .sp .in 3 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 The list of Internet-Draft Shadow Directories can be accessed at Distribution of this document is unlimited. Please send comments to the Namedroppers mailing list . .ti 0 .ne 4 Motivation and Scope EDNS0 [EDNS0] specifies a general framework for extending the packet format used by the Domain Name System protocols. The framework includes a simple version numbering scheme to allow the parties in a DNS protocol exchange to determine which extension features the other party understands. While having the advantage of simplicity, the version numbering scheme as specified has drawbacks: - It provides no way to deprecate a protocol feature; - It provides no way to deploy experimental protocol features. .ne 4 This note proposes to replace the monolithic version numbering mechanism with a mechanism for listing an explicit set of protocol features that a particular implementation supports. We retain version numbering as a way of abbreviating the feature sets that we expect to see in common use. .ti 0 .ne 4 Model Our revised extension model for EDNS0 is designed with three goals in mind: .in 5 .ti 3 - We want the protocol to be as simple as possible for the common case of a client or server that implements "mainstream standard DNS"; .ti 3 - We want to provide a safe way to experiment with new protocol features, both inside and outside the deployed DNS; .ti 3 - We want to provide a safe way to deprecate protocol features. .in 3 Our revised extension model has two parts, both of which are carried in the OPT pseudo-RR: the VERSION, which stored in the second octet of the TTL field of the OPT RR, and a variable-length list of FEATURES, stored in the variable part of the OPT RR. All FEATUREs are extensions of the DNS. We reserve FEATURE numbers 1 to 100 for describing features of the original RFC 1034/1035 DNS specification that we might eventually chose to deprecate. Any query/response pair can be described as using a set of DNS FEATUREs. Such features might for instance be: .in 5 .ti 3 - Domain binary labels according to [BINARY-LABELS]; .ti 3 - Extended RCODEs (the general principle, not specific values); .ti 3 - Multi-packet UDP response; .ti 3 - Increased maximum UDP payload size; .ti 3 - Character set identification in DNS labels; .ti 3 - SIG record parsing and checking; .in 3 FEATURE numbers are handed out by IANA on a first-come-first-served basis. Any revised specification of a format or function should have its own FEATURE number; in the IETF process, any significantly changed Internet-Draft should have a new FEATURE number assigned for experimentation. An assigned VERSION number names a set of FEATUREs. VERSION numbers are assigned by the IETF through a standards action. Normally, any VERSION number encompasses every FEATURE of all lower VERSION numbers, but the possibility of removing FEATUREs exists for two reasons: .in 5 .ti 3 - To remove the need for supporting FEATUREs that turned out to be a Really Bad Idea; .ti 3 - To allow replacing a badly specified FEATURE with a better specified FEATURE performing the same function that has a new FEATURE number. .in 3 .ti 0 .ne 4 Mechanism We propose to transport explicit feature sets as lists of integers carried in the variable RDATA portion of the EDNS0 OPT pseudo-RR. The OPTION-CODE for FEATURES is [TBD]. The OPTION-DATA for FEATURES is an ordered list of "feature numbers"; a feature number is represented as a big-endian 16-bit unsigned integer, and the list is sorted into numerically increasing order. Each feature number names a particular protocol feature that is supported by the implementation that generated this OPT pseudo-RR. .ti 0 .ne 4 Usage When composing a query message, the client includes an OPT record indicating the set of FEATUREs that: .in 5 .ti 3 - Allows the client to express this query; .ti 3 - Allows the server to express all responses that the client is prepared to accept for this query. .in 3 This set is expressed as a VERSION and any additional FEATURES required. The server will include an OPT pseudo-RR that indicates: .in 5 .ti 3 - The highest VERSION numbers supported by the responder (for information only -- the client takes no action based on this); .ti 3 - The set of FEATUREs not encompassed by the VERSION that are necessary to express the response. .in 3 No FEATURE may be included or used that is not within the set of FEATUREs that the query originator indicated. As a special case, if a client explicitly queries for the OPT RR of the root zone, the server returns an OPT record including all FEATUREs that the server supports. This functionality is provided strictly for diagnostic purposes. .ti 0 .ne 4 Life Cycle We expect the life cycle of new features to proceed as follows: .in 5 .ti 3 - VERSION X is defined and deployed. .ti 3 - A new FEATURE is defined and experimentally implemented. All clients and servers part of the experiment use FEATURE to indicate support. .ti 3 - Community consensus is reached that this FEATURE is genuinely useful. .ti 3 - VERSION X+1 is defined, encompassing all FEATUREs from VERSION X, plus the new FEATURE (and perhaps others). .ti 3 - The next generation of DNS software supports VERSION X+1, and never use FEATURE. .in 3 .ti 0 .ne 4 Risks While we have tried to provide the ability to deprecate old bad protocol features, such an ability should be used only rarely, if at all, since by any realistic estimate it takes years (decades?) to upgrade all the DNS implementations already in the field. A flexible extension mechanism of this type increases the risk that some implementors might chose to deploy features designed to hinder interoperability (so-called "labeled noninteroperability"). .ti 0 .ne 4 Security Considerations We do not believe that this protocol enhancement adds any new security risks, but we do believe that it would be helpful in getting complicated DNS extensions such as [DNSSEC] deployed more quickly. .ti 0 .ne 4 IANA Considerations IANA will need to allocate an EDNS0 option code for FEATURES. IANA will need to create a new registry of feature numbers. .in 8 .ti 0 .ne 4 References .ne 2 .ti 3 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. .ne 2 .ti 3 [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, November 1987. .ne 2 .ti 3 [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987. .ne 2 .ti 3 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. .ne 2 .ti 3 [BINARY-LABELS] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673 August 1999. .in 6 .ti 0 .ne 4 Author's addresses: .nf Rob Austein InterNetShare.com, Inc. 505 West Olive Ave., Suite 321 Sunnyvale, CA 94086 USA .\" Technically, this is my phone number, but it's not very useful .\" .\" +1 408 735 9800 sra@hactrn.net Harald Tveit Alvestrand EDB MaXware AS Pirsenteret N-7486 Trondheim NORWAY +47 73 54 57 97 Harald@Alvestrand.no .fi .\" .\" Local Variables: .\" mode:nroff .\" indent-tabs-mode: nil .\" End: