draft-ietf-dnsext-dnssec-bis-updates-03.txt   draft-ietf-dnsext-dnssec-bis-updates-04.txt 
Network Working Group S. Weiler Network Working Group S. Weiler
Internet-Draft SPARTA, Inc Internet-Draft SPARTA, Inc
Updates: 4034, 4035 (if approved) R. Austein Updates: 4034, 4035 (if approved) R. Austein
Expires: December 28, 2006 ISC Intended status: Informational ISC
June 26, 2006 Expires: April 25, 2007 October 22, 2006
Clarifications and Implementation Notes for DNSSECbis Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-03 draft-ietf-dnsext-dnssec-bis-updates-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 1, line 35 skipping to change at page 1, line 35
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 The list of current Internet-Drafts can be accessed at
http://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 28, 2006. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document is a collection of minor technical clarifications to This document is a collection of minor technical clarifications to
the DNSSECbis document set. It is meant to serve as a resource to the DNSSECbis document set. It is meant to serve as a resource to
implementors as well as an interim repository of DNSSECbis errata. implementors as well as an interim repository of DNSSECbis errata.
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4 2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4
2.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 2.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4
2.2. Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5 2.2. Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5
2.3. Validating Responses to an ANY Query . . . . . . . . . . . 5 2.3. Validating Responses to an ANY Query . . . . . . . . . . . 5
3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
3.1. Unknown DS Message Digest Algorithms . . . . . . . . . . . 5 3.1. Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
3.2. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 3.2. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
3.3. Caution About Local Policy and Multiple RRSIGs . . . . . . 6 3.3. Caution About Local Policy and Multiple RRSIGs . . . . . . 6
3.4. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 3.4. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
3.5. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7
3.6. Responding to QTYPE=* with the DO Bit Clear . . . . . . . 7
4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7 4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7
4.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7 4.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7
4.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7 4.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 8
4.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 8 4.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 8
4.4. Errors in Canonical Form Type Code List . . . . . . . . . 8 4.4. Errors in Canonical Form Type Code List . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction and Terminology 1. Introduction and Terminology
This document lists some minor clarifications and corrections to This document lists some minor clarifications and corrections to
DNSSECbis, as described in [RFC4033], [RFC4034], and [RFC4035]. DNSSECbis, as described in [RFC4033], [RFC4034], and [RFC4035].
It is intended to serve as a resource for implementors and as a It is intended to serve as a resource for implementors and as a
skipping to change at page 7, line 14 skipping to change at page 7, line 14
cases, a resolver would be well advised to accept any valid RRSIG as cases, a resolver would be well advised to accept any valid RRSIG as
sufficient. If the first RRSIG tested fails validation, a resolver sufficient. If the first RRSIG tested fails validation, a resolver
would be well advised to try others, giving a successful validation would be well advised to try others, giving a successful validation
result if any can be validated and giving a failure only if all result if any can be validated and giving a failure only if all
RRSIGs fail validation. RRSIGs fail validation.
If a resolver adopts a more restrictive policy, there's a danger that If a resolver adopts a more restrictive policy, there's a danger that
properly-signed data might unnecessarily fail validation, perhaps properly-signed data might unnecessarily fail validation, perhaps
because of cache timing issues. Furthermore, certain zone management because of cache timing issues. Furthermore, certain zone management
techniques, like the Double Signature Zone-signing Key Rollover techniques, like the Double Signature Zone-signing Key Rollover
method described in section 4.2.1.2 of [I-D.ietf-dnsop-dnssec- method described in section 4.2.1.2 of [RFC4641] might not work
operational-practices] might not work reliably. reliably.
3.4. Key Tag Calculation 3.4. Key Tag Calculation
[RFC4034] Appendix B.1 incorrectly defines the Key Tag field [RFC4034] Appendix B.1 incorrectly defines the Key Tag field
calculation for algorithm 1. It correctly says that the Key Tag is calculation for algorithm 1. It correctly says that the Key Tag is
the most significant 16 of the least significant 24 bits of the the most significant 16 of the least significant 24 bits of the
public key modulus. However, [RFC4034] then goes on to incorrectly public key modulus. However, [RFC4034] then goes on to incorrectly
say that this is 4th to last and 3rd to last octets of the public key say that this is 4th to last and 3rd to last octets of the public key
modulus. It is, in fact, the 3rd to last and 2nd to last octets. modulus. It is, in fact, the 3rd to last and 2nd to last octets.
3.5. Setting the DO Bit on Replies
[RFC4035] does not provide any instructions to servers as to how to
set the DO bit. Some authoritative server implementations have
chosen to copy the DO bit settings from the incoming query to the
outgoing response. Others have chosen to never set the DO bit in
responses. Either behavior is permited. To be clear, in replies to
queries with the DO-bit set servers may or may not set the DO bit.
3.6. Responding to QTYPE=* with the DO Bit Clear
To protect resolvers that cannot cope with DNSSEC types, a server
should not include DNSSEC RR types when responding to a query with
QTYPE=* and the DO bit not set.
4. Minor Corrections and Clarifications 4. Minor Corrections and Clarifications
4.1. Finding Zone Cuts 4.1. Finding Zone Cuts
Appendix C.8 of [RFC4035] discusses sending DS queries to the servers Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
for a parent zone. To do that, a resolver may first need to apply for a parent zone. To do that, a resolver may first need to apply
special rules to discover what those servers are. special rules to discover what those servers are.
As explained in Section 3.1.4.1 of [RFC4035], security-aware name As explained in Section 3.1.4.1 of [RFC4035], security-aware name
servers need to apply special processing rules to handle the DS RR, servers need to apply special processing rules to handle the DS RR,
skipping to change at page 9, line 49 skipping to change at page 10, line 17
7.2. Informative References 7.2. Informative References
[I-D.ietf-dnsext-dnssec-experiments] [I-D.ietf-dnsext-dnssec-experiments]
Blacka, D., "DNSSEC Experiments", Blacka, D., "DNSSEC Experiments",
draft-ietf-dnsext-dnssec-experiments-03 (work in draft-ietf-dnsext-dnssec-experiments-03 (work in
progress), April 2006. progress), April 2006.
[I-D.ietf-dnsext-nsec3] [I-D.ietf-dnsext-nsec3]
Laurie, B., "DNSSEC Hashed Authenticated Denial of Laurie, B., "DNSSEC Hashed Authenticated Denial of
Existence", draft-ietf-dnsext-nsec3-05 (work in progress), Existence", draft-ietf-dnsext-nsec3-07 (work in progress),
May 2006. August 2006.
[I-D.ietf-dnsop-dnssec-operational-practices]
Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practices-08 (work in
progress), March 2006.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
and DNSSEC On-line Signing", RFC 4470, April 2006. and DNSSEC On-line Signing", RFC 4470, April 2006.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, September 2006.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The editors are extremely grateful to those who, in addition to The editors are extremely grateful to those who, in addition to
finding errors and omissions in the DNSSECbis document set, have finding errors and omissions in the DNSSECbis document set, have
provided text suitable for inclusion in this document. provided text suitable for inclusion in this document.
The lack of specificity about handling private algorithms, as The lack of specificity about handling private algorithms, as
described in Section 3.2, and the lack of specificity in handling ANY described in Section 3.2, and the lack of specificity in handling ANY
queries, as described in Section 2.3, were discovered by David queries, as described in Section 2.3, were discovered by David
Blacka. Blacka.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Email: weiler@tislabs.com Email: weiler@tislabs.com
Rob Austein Rob Austein
ISC ISC
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Email: sra@isc.org Email: sra@isc.org
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING 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.
Intellectual Property
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 Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 12, line 29 skipping to change at page 12, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. 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 that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 14 change blocks. 
33 lines changed or deleted 48 lines changed or added

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