draft-ietf-dnsext-dnssec-bis-updates-06.txt   draft-ietf-dnsext-dnssec-bis-updates-07.txt 
Network Working Group S. Weiler Network Working Group S. Weiler
Internet-Draft SPARTA, Inc. Internet-Draft SPARTA, Inc.
Updates: 4034, 4035 R. Austein Updates: 4034, 4035 D. Blacka
(if approved) ISC (if approved) VeriSign, Inc.
Expires: May 22, 2008 November 19, 2007 Expires: January 15, 2009 July 14, 2008
Clarifications and Implementation Notes for DNSSECbis Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-06 draft-ietf-dnsext-dnssec-bis-updates-07
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 May 22, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
Table of Contents Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . 7
4.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 7 4.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 11
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
repository of items that need to be addressed when advancing the repository of items that need to be addressed when advancing the
DNSSECbis documents from Proposed Standard to Draft Standard. DNSSECbis documents from Proposed Standard to Draft Standard.
skipping to change at page 6, line 51 skipping to change at page 6, line 51
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 3.5. Setting the DO Bit on Replies
[RFC4035] does not provide any instructions to servers as to how to [RFC4035] does not provide any instructions to servers as to how to
set the DO bit. Some authoritative server implementations have set the DO bit. Some authoritative server implementations have
chosen to copy the DO bit settings from the incoming query to the 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 outgoing response. Others have chosen to never set the DO bit in
responses. Either behavior is permited. To be clear, in replies to responses. Either behavior is permitted. To be clear, in replies to
queries with the DO-bit set servers may or may not set the DO bit. queries with the DO-bit set servers may or may not set the DO bit.
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.
skipping to change at page 7, line 38 skipping to change at page 7, line 38
the size of the DNSKEY RRset. However, be aware that there is no way the size of the DNSKEY RRset. However, be aware that there is no way
to tell resolvers what a particularly DNSKEY is supposed to be used to tell resolvers what a particularly DNSKEY is supposed to be used
for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
authenticate any RRset in the zone. For example, if a weaker or less authenticate any RRset in the zone. For example, if a weaker or less
trusted DNSKEY is being used to authenticate NSEC RRsets or all trusted DNSKEY is being used to authenticate NSEC RRsets or all
dynamically updated records, that same DNSKEY can also be used to dynamically updated records, that same DNSKEY can also be used to
sign any other RRsets from the zone. sign any other RRsets from the zone.
Furthermore, note that the SEP bit setting has no effect on how a Furthermore, note that the SEP bit setting has no effect on how a
DNSKEY may be used -- the validation process is specifically DNSKEY may be used -- the validation process is specifically
prohibited from using that bit by [RFC4034] section 2.1.2. It prohibited from using that bit by [RFC4034] section 2.1.2. It is
possible to use a DNSKEY without the SEP bit set as the sole secure possible to use a DNSKEY without the SEP bit set as the sole secure
entry point to the zone, yet use a DNSKEY with the SEP bit set to entry point to the zone, yet use a DNSKEY with the SEP bit set to
sign all RRsets in the zone (other than the DNSKEY RRset). It's also sign all RRsets in the zone (other than the DNSKEY RRset). It's also
possible to use a single DNSKEY, with or without the SEP bit set, to possible to use a single DNSKEY, with or without the SEP bit set, to
sign the entire zone, including the DNSKEY RRset itself. sign the entire zone, including the DNSKEY RRset itself.
4.3. Errors in Examples 4.3. Errors in Examples
The text in [RFC4035] Section C.1 refers to the examples in B.1 as The text in [RFC4035] Section C.1 refers to the examples in B.1 as
"x.w.example.com" while B.1 uses "x.w.example". This is painfully "x.w.example.com" while B.1 uses "x.w.example". This is painfully
skipping to change at page 8, line 35 skipping to change at page 8, line 35
preserving the security properties DNSSEC offers. Furthermore, preserving the security properties DNSSEC offers. Furthermore,
failure to address some of the interoperability concerns in Section 3 failure to address some of the interoperability concerns in Section 3
could limit the ability to later change or expand DNSSEC, including could limit the ability to later change or expand DNSSEC, including
by adding new algorithms. by adding new algorithms.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. RFC 1034, STD 13, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
skipping to change at page 9, line 24 skipping to change at page 9, line 24
Signer (DS)", RFC 3755, May 2004. Signer (DS)", RFC 3755, May 2004.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, September 2006. RFC 4641, September 2006.
[RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
July 2007. July 2007.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The editors would like the thank Rob Austein for his previous work as
an editor of this document.
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.2, were discovered by David queries, as described in Section 2.2, were discovered by David
Blacka. Blacka.
The error in algorithm 1 key tag calculation, as described in The error in algorithm 1 key tag calculation, as described in
skipping to change at page 10, line 15 skipping to change at page 10, line 15
Authors' Addresses Authors' Addresses
Samuel Weiler Samuel Weiler
SPARTA, Inc. SPARTA, Inc.
7110 Samuel Morse Drive 7110 Samuel Morse Drive
Columbia, Maryland 21046 Columbia, Maryland 21046
US US
Email: weiler@tislabs.com Email: weiler@tislabs.com
Rob Austein David Blacka
ISC VeriSign, Inc.
950 Charter Street 21345 Ridgetop Circle
Redwood City, CA 94063 Dulles, VA 20166
USA US
Email: sra@isc.org Email: davidb@verisign.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 11, line 44 skipping to change at line 457
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 13 change blocks. 
21 lines changed or deleted 20 lines changed or added

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