draft-ietf-dnsext-edns0dot5-00.txt   draft-ietf-dnsext-edns0dot5-01.txt 
Network Working Group R. Austein Network Working Group R. Austein
draft-ietf-dnsext-edns0dot5-00.txt InterNetShare.com, Inc. draft-ietf-dnsext-edns0dot5-01.txt InterNetShare.com, Inc.
H. Alvestrand H. Alvestrand
EDB MaXware AS EDB MaXware AS
February 2000 July 2000
A Proposed Enhancement to the EDNS0 Version Mechanism A Proposed Enhancement to the EDNS0 Version Mechanism
Status of this document Status of this document
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 RFC 2026. all provisions of Section 10 of RFC 2026.
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 2, line 30 skipping to change at page 2, line 30
- We want to provide a safe way to experiment with new protocol - We want to provide a safe way to experiment with new protocol
features, both inside and outside the deployed DNS; features, both inside and outside the deployed DNS;
- We want to provide a safe way to deprecate protocol features. - We want to provide a safe way to deprecate protocol features.
Our revised extension model has two parts, both of which are carried 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 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 of the TTL field of the OPT RR, and a variable-length list of
FEATURES, stored in the variable part of the OPT RR. FEATURES, stored in the variable part of the OPT RR.
All FEATUREs are extensions of the DNS. We reserve FEATURE numbers 1 All FEATUREs are extensions of the DNS. We reserve the range of
to 100 for describing features of the original RFC 1034/1035 DNS FEATURE numbers from 1 to 100 for describing features of the original
specification that we might eventually chose to deprecate. RFC 1034/1035 DNS specification that we might eventually choose to
deprecate.
Any query/response pair can be described as using a set of DNS Any query/response pair can be described as using a set of DNS
FEATUREs. Such features might for instance be: FEATUREs. Such features might for instance be:
- Domain binary labels according to [BINARY-LABELS]; - Domain binary labels according to [BINARY-LABELS];
- Extended RCODEs (the general principle, not specific values); - Extended RCODEs (the general principle, not specific values);
- Multi-packet UDP response; - Multi-packet UDP response;
- Increased maximum UDP payload size; - Increased maximum UDP payload size;
- Character set identification in DNS labels; - Character set identification in DNS labels;
- SIG record parsing and checking; - SIG record parsing and checking;
FEATURE numbers are handed out by IANA on a first-come-first-served FEATURE numbers are handed out by IANA on a first-come-first-served
basis. Any revised specification of a format or function should have basis within their appropriate ranges. Any revised specification of
its own FEATURE number; in the IETF process, any significantly a format or function should have its own FEATURE number; in the IETF
changed Internet-Draft should have a new FEATURE number assigned for process, any significantly changed Internet-Draft should have a new
experimentation. FEATURE number assigned for experimentation.
An assigned VERSION number names a set of FEATUREs. VERSION numbers An assigned VERSION number names a set of FEATUREs. VERSION numbers
are assigned by the IETF through a standards action. are assigned by the IETF through a standards action.
Normally, any VERSION number encompasses every FEATURE of all lower Normally, any VERSION number encompasses every FEATURE of all lower
VERSION numbers, but the possibility of removing FEATUREs exists for VERSION numbers, but the possibility of removing FEATUREs exists for
two reasons: two reasons:
- To remove the need for supporting FEATUREs that turned out to be a - To remove the need for supporting FEATUREs that turned out to be a
Really Bad Idea; Really Bad Idea;
skipping to change at page 3, line 36 skipping to change at page 3, line 37
The OPTION-DATA for FEATURES is an ordered list of "feature numbers"; The OPTION-DATA for FEATURES is an ordered list of "feature numbers";
a feature number is represented as a big-endian 16-bit unsigned a feature number is represented as a big-endian 16-bit unsigned
integer, and the list is sorted into numerically increasing order. integer, and the list is sorted into numerically increasing order.
Each feature number names a particular protocol feature that is Each feature number names a particular protocol feature that is
supported by the implementation that generated this OPT pseudo-RR. supported by the implementation that generated this OPT pseudo-RR.
Usage Usage
When composing a query message, the client includes an OPT record In most respects, the FEATURE mechanism is used symmetrically by
indicating the set of FEATUREs that: clients and servers; exceptions to this rule are stated after the
general explanation.
- Allows the client to express this query; When composing a DNS message, a client or server includes an OPT
record indicating a set of FEATUREs that:
- Allows the server to express all responses that the client is - MUST include all FEATUREs that the client or server believes are
prepared to accept for this query. relevant to this message;
- MAY include all FEATURES that the client or server is prepared to
receive.
This set is expressed as a VERSION and any additional FEATURES This set is expressed as a VERSION and any additional FEATURES
required. required.
The server will include an OPT pseudo-RR that indicates: In general, we expect that a client or server will include an OPT
pseudo-RR that indicates:
- The highest VERSION numbers supported by the responder (for - The highest VERSION number that the entity generating the message
information only -- the client takes no action based on this); supports; and
- The set of FEATUREs not encompassed by the VERSION that are
necessary to express the response.
No FEATURE may be included or used that is not within the set of - A small (possibly empty) set of additional FEATUREs not encompassed
FEATUREs that the query originator indicated. by the VERSION that the entity deems necessary or desirable.
The above symmetry notwithstanding, we impose one important
constraint on the server: while a server is allowed to indicate
whatever FEATUREs it believes are relevant or useful, a server MUST
NOT make use of any FEATURE in a response that is not within the set
of FEATUREs indicated by the client that generated the corresponding
request. That is, a response may say "I support FEATURE FOO"
regardless of what the client supports, but the rest of the response
must not use FEATURE FOO unless the client also supports it.
As a special case, if a client explicitly queries for the OPT RR of 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 the root zone, the server returns an OPT record including all
FEATUREs that the server supports. This functionality is provided FEATUREs that the server supports. This functionality is provided
strictly for diagnostic purposes. strictly for diagnostic purposes.
Life Cycle Life Cycle
We expect the life cycle of new features to proceed as follows: We expect the life cycle of new features to proceed as follows:
- VERSION X is defined and deployed. - VERSION X is defined and deployed.
- A new FEATURE is defined and experimentally implemented. All - A new FEATURE is defined and experimentally implemented. All
clients and servers part of the experiment use FEATURE to indicate clients and servers taking part in the experiment use FEATURE to
support. indicate support.
- Community consensus is reached that this FEATURE is genuinely - Community consensus is reached that this FEATURE is genuinely
useful. useful.
- VERSION X+1 is defined, encompassing all FEATUREs from VERSION X, - VERSION X+1 is defined, encompassing all FEATUREs from VERSION X,
plus the new FEATURE (and perhaps others). plus the new FEATURE (and perhaps others).
- The next generation of DNS software supports VERSION X+1, and never - The next generation of DNS software supports VERSION X+1, and never
use FEATURE. use FEATURE.
skipping to change at page 4, line 47 skipping to change at page 5, line 11
protocol features, such an ability should be used only rarely, if at protocol features, such an ability should be used only rarely, if at
all, since by any realistic estimate it takes years (decades?) to all, since by any realistic estimate it takes years (decades?) to
upgrade all the DNS implementations already in the field. upgrade all the DNS implementations already in the field.
A flexible extension mechanism of this type increases the risk that A flexible extension mechanism of this type increases the risk that
some implementors might chose to deploy features designed to hinder some implementors might chose to deploy features designed to hinder
interoperability (so-called "labeled noninteroperability"). interoperability (so-called "labeled noninteroperability").
Security Considerations Security Considerations
We do not believe that this protocol enhancement adds any new We do not believe that this protocol enhancement adds any major new
security risks, but we do believe that it would be helpful in getting security risks, but we do believe that it would be helpful in getting
complicated DNS extensions such as [DNSSEC] deployed more quickly. complicated DNS extensions such as [DNSSEC] deployed more quickly.
As with any enhancement to or complication of the DNS protocol, this
enhancement offers attackers yet another way to increase the load on
a name server. Root, TLD and other "major" name servers should view
excessively complicated FEATURE sets with suspicion, and should not
allow themselves to be tricked into performing more work than is
really necessary.
IANA Considerations IANA Considerations
IANA will need to allocate an EDNS0 option code for FEATURES. IANA will need to allocate an EDNS0 option code for FEATURES.
IANA will need to create a new registry of feature numbers. IANA will need to create a new registry of feature numbers.
Acknowledgments
The authors would like to thank the following people for their help
in improving this document: Randy Bush, Patrik Faltstrom, Olafur
Gudmundsson, Bob Halley, and XXX.
References References
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
facilities", RFC 1034, November 1987. facilities", RFC 1034, November 1987.
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
 End of changes. 

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