draft-ietf-dnsext-dnssec-trans-00.txt   draft-ietf-dnsext-dnssec-trans-01.txt 
DNS Extensions Working Group R. Arends DNS Extensions Working Group R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: December 7, 2004 P. Koch Expires: April 25, 2005 P. Koch
Universitaet Bielefeld Universitaet Bielefeld
J. Schlyter J. Schlyter
NIC-SE NIC-SE
June 8, 2004 October 25, 2004
Evaluating DNSSEC Transition Mechanisms Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-00.txt draft-ietf-dnsext-dnssec-trans-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 7, 2004. This Internet-Draft will expire on April 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document collects and summarizes different proposals for This document collects and summarizes different proposals for
alternative and additional strategies for authenticated denial in DNS alternative and additional strategies for authenticated denial in DNS
responses, evaluates these proposals and gives a recommendation for a responses, evaluates these proposals and gives a recommendation for a
way forward. way forward.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . 3 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
2.1 Mechanisms Updating DNSSEC-bis . . . . . . . . . . . . . . . 4 2.1 Mechanisms Updating DNSSEC-bis . . . . . . . . . . . . . . 4
2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . . . . 4 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . . . . 4 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 4
2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . . . . 5 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 5
2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6
2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . . . . 7 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . . . . 8 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8
2.2 Mechanisms not Updating DNSSEC-bis . . . . . . . . . . . . . 9 2.2 Mechanisms not Updating DNSSEC-bis . . . . . . . . . . . . 9
2.2.1 Partial Type-code and Signal Rollover . . . . . . . . . . . 9 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 9
2.2.2 A Complete Type-code and Signal Rollover . . . . . . . . . . 9 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 9
2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . . . . 10 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 10
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 11 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 13
1. Introduction 1. Introduction
The working group consents on not including NSEC-alt in the The working group consents on not including NSEC-alt in the
DNSSEC-bis documents. The working group considers to take up DNSSEC-bis documents. The working group considers to take up
"prevention of zone enumeration" as a work item. "prevention of zone enumeration" as a work item.
There may be multiple mechanisms to allow for co-existence with There may be multiple mechanisms to allow for co-existence with
DNSSEC-bis. The chairs allow the working group a little over a week DNSSEC-bis. The chairs allow the working group a little over a week
(up to June 12) to come to consensus on a possible modification to (up to June 12) to come to consensus on a possible modification to
skipping to change at page 3, line 42 skipping to change at page 3, line 42
not cover every detail necessary for implementation. In any case, not cover every detail necessary for implementation. In any case,
documentation and further study is needed before implementaion and/or documentation and further study is needed before implementaion and/or
deployment, including those which seem to be solely operational in deployment, including those which seem to be solely operational in
nature. nature.
2. Transition Mechanisms 2. Transition Mechanisms
In the light of recent discussions and past proposals, we have found In the light of recent discussions and past proposals, we have found
several ways to allow for transition to future expansion of several ways to allow for transition to future expansion of
authenticated denial. We tried to illuminate the paths and pitfalls authenticated denial. We tried to illuminate the paths and pitfalls
in these ways forward. Some proposals lead to a versioning of DNSSEC, in these ways forward. Some proposals lead to a versioning of
where DNSSEC-bis may co-exist with DNSSEC-ter, other proposals are DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
'clean' but may cause delay, while again others may be plain hacks. proposals are 'clean' but may cause delay, while again others may be
plain hacks.
Some paths do not introduce versioning, and might require the current Some paths do not introduce versioning, and might require the current
DNSSEC-bis documents to be fully updated to allow for extensions to DNSSEC-bis documents to be fully updated to allow for extensions to
authenticated denial mechanisms. Other paths introduce versioning and authenticated denial mechanisms. Other paths introduce versioning
do not (or minimally) require DNSSEC-bis documents to be updated, and do not (or minimally) require DNSSEC-bis documents to be updated,
allowing DNSSEC-bis to be deployed, while future versions can be allowing DNSSEC-bis to be deployed, while future versions can be
drafted independent from or partially depending on DNSSEC-bis. drafted independent from or partially depending on DNSSEC-bis.
2.1 Mechanisms Updating DNSSEC-bis 2.1 Mechanisms Updating DNSSEC-bis
2.1.1 Dynamic NSEC Synthesis 2.1.1 Dynamic NSEC Synthesis
This proposal assumes that NSEC RRs and the authenticating RRSIG will This proposal assumes that NSEC RRs and the authenticating RRSIG will
be generated dynamically to just cover the (non existent) query name. be generated dynamically to just cover the (non existent) query name.
The owner name is (the) one preceding the name queried for, the Next The owner name is (the) one preceding the name queried for, the Next
Owner Name Field has the value of the Query Name Field + 1 (first Owner Name Field has the value of the Query Name Field + 1 (first
successor in canonical ordering). A separate key (the normal ZSK or a successor in canonical ordering). A separate key (the normal ZSK or
separate ZSK per authoritative server) would be used for RRSIGs on a separate ZSK per authoritative server) would be used for RRSIGs on
NSEC RRs. This is a defense against enumeration, though it has the NSEC RRs. This is a defense against enumeration, though it has the
presumption of online signing. presumption of online signing.
2.1.1.1 Coexistence and Migration 2.1.1.1 Coexistence and Migration
There is no change in interpretation other then that the next owner There is no change in interpretation other then that the next owner
name might or might not exist. name might or might not exist.
2.1.1.2 Limitations 2.1.1.2 Limitations
skipping to change at page 5, line 9 skipping to change at page 5, line 9
This proposal introduces versioning for the NSEC RR type (a.k.a. This proposal introduces versioning for the NSEC RR type (a.k.a.
subtyping) by adding a (one octet) version field to the NSEC RDATA. subtyping) by adding a (one octet) version field to the NSEC RDATA.
Version number 0 is assigned to the current (DNSSEC-bis) meaning, Version number 0 is assigned to the current (DNSSEC-bis) meaning,
making this an 'Must Be Zero' (MBZ) for the to be published docset. making this an 'Must Be Zero' (MBZ) for the to be published docset.
2.1.2.1 Coexistence and Migration 2.1.2.1 Coexistence and Migration
Since the versioning is done inside the NSEC RR, different versions Since the versioning is done inside the NSEC RR, different versions
may coexist. However, depending on future methods, that may or may may coexist. However, depending on future methods, that may or may
not be useful inside a single zone. Resolvers cannot ask for specific not be useful inside a single zone. Resolvers cannot ask for
NSEC versions but may be able to indicate version support by means of specific NSEC versions but may be able to indicate version support by
a to be defined EDNS option bit. means of a to be defined EDNS option bit.
2.1.2.2 Limitations 2.1.2.2 Limitations
There are no technical limitations, though it will cause delay to There are no technical limitations, though it will cause delay to
allow testing of the (currently unknown) new NSEC interpretation. allow testing of the (currently unknown) new NSEC interpretation.
Since the versioning and signaling is done inside the NSEC RR, future Since the versioning and signaling is done inside the NSEC RR, future
methods will likely be restricted to a single RR type authenticated methods will likely be restricted to a single RR type authenticated
denial (as opposed to e.g. NSEC-alt, which currently proposes three denial (as opposed to e.g. NSEC-alt, which currently proposes three
RR types). RR types).
skipping to change at page 6, line 22 skipping to change at page 6, line 22
2.1.3.2 Limitations 2.1.3.2 Limitations
This mechanism uses an NSEC field that was not designed for that This mechanism uses an NSEC field that was not designed for that
purpose. Similar methods were discussed during the Opt-In discussion purpose. Similar methods were discussed during the Opt-In discussion
and the Silly-State discussion. and the Silly-State discussion.
2.1.3.3 Amendments to DNSSEC-bis 2.1.3.3 Amendments to DNSSEC-bis
The specific type-bit-map-bits must be allocated and they need to be The specific type-bit-map-bits must be allocated and they need to be
specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
interpretation. Also, behaviour of the resolver and validator must be interpretation. Also, behaviour of the resolver and validator must
documented in case unknown values are encountered for the MBZ field. be documented in case unknown values are encountered for the MBZ
Currently the protocol document specifies that the validator MUST field. Currently the protocol document specifies that the validator
ignore the setting of the NSEC and the RRSIG bits, while other bits MUST ignore the setting of the NSEC and the RRSIG bits, while other
are only used for the specific purpose of the type-bit-map field bits are only used for the specific purpose of the type-bit-map field
2.1.3.4 Cons 2.1.3.4 Cons
The type-bit-map was not designed for this purpose. It is a The type-bit-map was not designed for this purpose. It is a
straightforward hack. Text in protocol section 5.4 was put in straightforward hack. Text in protocol section 5.4 was put in
specially to defend against this usage. specially to defend against this usage.
2.1.3.5 Pros 2.1.3.5 Pros
No change needed to the on-the-wire protocol as specified in the No change needed to the on-the-wire protocol as specified in the
skipping to change at page 7, line 7 skipping to change at page 7, line 7
2.1.4.1 Coexistence and Migration 2.1.4.1 Coexistence and Migration
Depending on the design of this new RR type multiple denial Depending on the design of this new RR type multiple denial
mechanisms may coexist in a zone. Old validators will not understand mechanisms may coexist in a zone. Old validators will not understand
and thus ignore the new type, so interpretation of the new NSEC and thus ignore the new type, so interpretation of the new NSEC
scheme may fail, negative responses may appear 'bogus'. scheme may fail, negative responses may appear 'bogus'.
2.1.4.2 Limitations 2.1.4.2 Limitations
A record of this kind is likely to carry additional feature/ A record of this kind is likely to carry additional
versioning indications unrelated to the current question of feature/versioning indications unrelated to the current question of
authenticated denial. authenticated denial.
2.1.4.3 Amendments to DNSSEC-bis 2.1.4.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that The current DNSSEC-bis documents need to be updated to indicate that
the absence of this type indicates dnssec-bis, and that the (mere) the absence of this type indicates dnssec-bis, and that the (mere)
presence of this type indicated unknown versions. presence of this type indicated unknown versions.
2.1.4.4 Cons 2.1.4.4 Cons
The only other 'zone' or 'apex' record is the SOA record. Though this The only other 'zone' or 'apex' record is the SOA record. Though
proposal is not new, it is yet unknown how it might fulfill this proposal is not new, it is yet unknown how it might fulfill
authenticated denial extensions. This new RR type would only provide authenticated denial extensions. This new RR type would only provide
for a generalized signaling mechanism, not the new authenticated for a generalized signaling mechanism, not the new authenticated
denial scheme. Since it is likely to be general in nature, due to denial scheme. Since it is likely to be general in nature, due to
this generality consensus is not to be reached soon. this generality consensus is not to be reached soon.
2.1.4.5 Pros 2.1.4.5 Pros
This approach would allow for a lot of other per zone information to This approach would allow for a lot of other per zone information to
be transported or signaled to both (slave) servers and resolvers. be transported or signaled to both (slave) servers and resolvers.
2.1.5 NSEC White Lies 2.1.5 NSEC White Lies
This proposal disables one part of NSEC (the pointer part) by means This proposal disables one part of NSEC (the pointer part) by means
of a special target (root, apex, owner, ...), leaving intact only the of a special target (root, apex, owner, ...), leaving intact only the
ability to authenticate denial of existence of RR sets, not denial of ability to authenticate denial of existence of RR sets, not denial of
existence of domain names (NXDOMAIN). It may be necessary to have one existence of domain names (NXDOMAIN). It may be necessary to have
working NSEC to prove the absence of a wildcard. one working NSEC to prove the absence of a wildcard.
2.1.5.1 Coexistence and Migration 2.1.5.1 Coexistence and Migration
The NSEC target can be specified per RR, so standard NSEC and 'white The NSEC target can be specified per RR, so standard NSEC and 'white
lie' NSEC can coexist in a zone. There is no need for migration lie' NSEC can coexist in a zone. There is no need for migration
because no versioning is introduced or intended. because no versioning is introduced or intended.
2.1.5.2 Limitations 2.1.5.2 Limitations
This proposal breaks the protocol and is applicable to certain types This proposal breaks the protocol and is applicable to certain types
skipping to change at page 9, line 50 skipping to change at page 9, line 50
2.2.1.5 Pros 2.2.1.5 Pros
Graceful adoption of future versions of NSEC, while there are no Graceful adoption of future versions of NSEC, while there are no
amendments to DNSSEC-bis. amendments to DNSSEC-bis.
2.2.2 A Complete Type-code and Signal Rollover 2.2.2 A Complete Type-code and Signal Rollover
A new DNSSEC space is defined which can exist independent of current A new DNSSEC space is defined which can exist independent of current
DNSSEC-bis space. DNSSEC-bis space.
This proposal assumes that all current DNSSEC type-codes (RRSIG/ This proposal assumes that all current DNSSEC type-codes
DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
versions of DNSSEC. Any future version of DNSSEC has its own types to future versions of DNSSEC. Any future version of DNSSEC has its own
allow for keys, signatures, authenticated denial, etcetera. types to allow for keys, signatures, authenticated denial, etcetera.
2.2.2.1 Coexistence and Migration 2.2.2.1 Coexistence and Migration
Both spaces can co-exist. They can be made completely orthogonal. Both spaces can co-exist. They can be made completely orthogonal.
2.2.2.2 Limitations 2.2.2.2 Limitations
None. None.
2.2.2.3 Amendments to DNSSEC-bis 2.2.2.3 Amendments to DNSSEC-bis
skipping to change at page 10, line 28 skipping to change at page 10, line 28
2.2.2.4 Cons 2.2.2.4 Cons
With this path we abandon the current DNSSEC-bis. Though it is easy With this path we abandon the current DNSSEC-bis. Though it is easy
to role specific well-known and well-tested parts into the re-write, to role specific well-known and well-tested parts into the re-write,
once deployment has started this path is very expensive for once deployment has started this path is very expensive for
implementers, registries, registrars and registrants as well as implementers, registries, registrars and registrants as well as
resolvers/users. A TCR is not to be expected to occur frequently, so resolvers/users. A TCR is not to be expected to occur frequently, so
while a next generation authenticated denial may be enabled by a TCR, while a next generation authenticated denial may be enabled by a TCR,
it is likely that that TCR will only be agreed upon if it serves a it is likely that that TCR will only be agreed upon if it serves a
whole basket of changes or additions. A quick introduction of NSEC-ng whole basket of changes or additions. A quick introduction of
should not be expected from this path. NSEC-ng should not be expected from this path.
2.2.2.5 Pros 2.2.2.5 Pros
No amendments/changes to current DNSSEC-bis docset needed. It is No amendments/changes to current DNSSEC-bis docset needed. It is
always there as last resort. always there as last resort.
2.2.3 Unknown Algorithm in RRSIG 2.2.3 Unknown Algorithm in RRSIG
This proposal assumes that future extensions make use of the existing This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of NSEC RDATA syntax, while it may need to change the interpretation of
skipping to change at page 13, line 8 skipping to change at page 13, line 8
Box 5774 Box 5774
Stockholm SE-114 87 Stockholm SE-114 87
Sweden Sweden
EMail: jakob@nic.se EMail: jakob@nic.se
URI: http://www.nic.se/ URI: http://www.nic.se/
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 26 change blocks. 
91 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/