mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 22:15:20 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2012-01-20 06:39:52 +00:00
parent 2e9e2e6aea
commit add449ed75
1 changed files with 150 additions and 150 deletions
Download Patch File Download Diff File Expand all files Collapse all files

300
doc/draft/draft-ietf-dnsext-dnssec-bis-updates-15.txt → doc/draft/draft-ietf-dnsext-dnssec-bis-updates-16.txt
View File

@@ -5,12 +5,12 @@ Network Working Group S. Weiler
Internet-Draft SPARTA, Inc. Internet-Draft SPARTA, Inc.
Updates: 4033, 4034, 4035, 5155 D. Blacka Updates: 4033, 4034, 4035, 5155 D. Blacka
(if approved) VeriSign, Inc. (if approved) VeriSign, Inc.
Intended status: Standards Track January 13, 2012 Intended status: Standards Track January 14, 2012
Expires: July 16, 2012 Expires: July 17, 2012
Clarifications and Implementation Notes for DNSSECbis Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-15 draft-ietf-dnsext-dnssec-bis-updates-16
Abstract Abstract
@@ -37,7 +37,7 @@ Status of this Memo
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."
This Internet-Draft will expire on July 16, 2012. This Internet-Draft will expire on July 17, 2012.
Copyright Notice Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
Weiler & Blacka Expires July 16, 2012 [Page 1] Weiler & Blacka Expires July 17, 2012 [Page 1]
Internet-Draft DNSSECbis Implementation Notes January 2012 Internet-Draft DNSSECbis Implementation Notes January 2012
@@ -108,7 +108,7 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
Weiler & Blacka Expires July 16, 2012 [Page 2] Weiler & Blacka Expires July 17, 2012 [Page 2]
Internet-Draft DNSSECbis Implementation Notes January 2012 Internet-Draft DNSSECbis Implementation Notes January 2012
@@ -131,9 +131,9 @@ Table of Contents
5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 6 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 6
5.1. Errors in Canonical Form Type Code List . . . . . . . . . 7 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 7
5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 7 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 7
5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 7 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 8
5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 8 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 8
5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 8 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 9
5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 9 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 9
5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 9 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 9
5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 9 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 9
@@ -142,10 +142,10 @@ Table of Contents
5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 10 5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 10
5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 11 5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 11
5.10.3. Preference Based on Source . . . . . . . . . . . . . 11 5.10.3. Preference Based on Source . . . . . . . . . . . . . 11
5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 11 5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 12
5.12. Expect Extra Signatures From Strange Keys . . . . . . . . 12 5.12. Expect Extra Signatures From Strange Keys . . . . . . . . 12
6. Minor Corrections and Clarifications . . . . . . . . . . . . . 12 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 13
6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 12 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 13
6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 13 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 13
6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 13 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 13
6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 14 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 14
@@ -155,8 +155,8 @@ Table of Contents
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16
Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 16 Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
@@ -164,7 +164,7 @@ Table of Contents
Weiler & Blacka Expires July 16, 2012 [Page 3] Weiler & Blacka Expires July 17, 2012 [Page 3]
Internet-Draft DNSSECbis Implementation Notes January 2012 Internet-Draft DNSSECbis Implementation Notes January 2012
@@ -220,7 +220,7 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
Weiler & Blacka Expires July 16, 2012 [Page 4] Weiler & Blacka Expires July 17, 2012 [Page 4]
Internet-Draft DNSSECbis Implementation Notes January 2012 Internet-Draft DNSSECbis Implementation Notes January 2012
@@ -276,7 +276,7 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
Weiler & Blacka Expires July 16, 2012 [Page 5] Weiler & Blacka Expires July 17, 2012 [Page 5]
Internet-Draft DNSSECbis Implementation Notes January 2012 Internet-Draft DNSSECbis Implementation Notes January 2012
@@ -332,25 +332,27 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
Weiler & Blacka Expires July 16, 2012 [Page 6] Weiler & Blacka Expires July 17, 2012 [Page 6]
Internet-Draft DNSSECbis Implementation Notes January 2012 Internet-Draft DNSSECbis Implementation Notes January 2012
5.1. Errors in Canonical Form Type Code List 5.1. Errors in Canonical Form Type Code List
When canonicalizing DNS names, DNS names in the RDATA section of NSEC When canonicalizing DNS names (for both ordering and signing), DNS
and RRSIG resource records are not downcased. names in the RDATA section of NSEC resource records are not
downcased. DNS names in the RDATA section of RRSIG resource records
are downcased.
[RFC4034] Section 6.2 item 3 has a list of resource record types for The guidance in the above paragraph differs from what has been
which DNS names in the RDATA are downcased for purposes of DNSSEC published before but is consistent with current common practice.
canonical form (for both ordering and signing). That list [RFC4034] Section 6.2 item 3 says that names in both of these RR
erroneously contains NSEC and RRSIG. According to [RFC3755], DNS types should be downcased. The earlier [RFC3755] says that they
names in the RDATA of NSEC and RRSIG should not be downcased. should not. Current practice follows neither document fully.
The same section also erroneously lists HINFO, and twice at that. Section 6.2 of RFC4034 also erroneously lists HINFO as a record that
Since HINFO records contain no domain names, they are not subject to needs downcasing, and twice at that. Since HINFO records contain no
downcasing. domain names, they are not subject to downcasing.
5.2. Unknown DS Message Digest Algorithms 5.2. Unknown DS Message Digest Algorithms
@@ -381,18 +383,20 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
disregards any DS records using unknown or unsupported message digest disregards any DS records using unknown or unsupported message digest
algorithms. algorithms.
5.3. Private Algorithms
As discussed above, section 5.2 of [RFC4035] requires that validators
make decisions about the security status of zones based on the public
Weiler & Blacka Expires July 16, 2012 [Page 7]
Weiler & Blacka Expires July 17, 2012 [Page 7]
Internet-Draft DNSSECbis Implementation Notes January 2012 Internet-Draft DNSSECbis Implementation Notes January 2012
5.3. Private Algorithms
As discussed above, section 5.2 of [RFC4035] requires that validators
make decisions about the security status of zones based on the public
key algorithms shown in the DS records for those zones. In the case key algorithms shown in the DS records for those zones. In the case
of private algorithms, as described in [RFC4034] Appendix A.1.1, the of private algorithms, as described in [RFC4034] Appendix A.1.1, the
eight-bit algorithm field in the DS RR is not conclusive about what eight-bit algorithm field in the DS RR is not conclusive about what
@@ -434,6 +438,17 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
method described in section 4.2.1.2 of [RFC4641] might not work method described in section 4.2.1.2 of [RFC4641] might not work
reliably. reliably.
Weiler & Blacka Expires July 17, 2012 [Page 8]
Internet-Draft DNSSECbis Implementation Notes January 2012
5.5. Key Tag Calculation 5.5. Key Tag Calculation
[RFC4034] Appendix B.1 incorrectly defines the Key Tag field [RFC4034] Appendix B.1 incorrectly defines the Key Tag field
@@ -441,14 +456,6 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
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
Weiler & Blacka Expires July 16, 2012 [Page 8]
Internet-Draft DNSSECbis Implementation Notes January 2012
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.
5.6. Setting the DO Bit on Replies 5.6. Setting the DO Bit on Replies
@@ -490,6 +497,14 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
validate itself -- on the grounds that a later query might come with validate itself -- on the grounds that a later query might come with
the CD bit set. the CD bit set.
Weiler & Blacka Expires July 17, 2012 [Page 9]
Internet-Draft DNSSECbis Implementation Notes January 2012
RFC4035 is ambiguous about what to do when a cached response was RFC4035 is ambiguous about what to do when a cached response was
obtained with the CD bit not set, a case that only arises when the obtained with the CD bit not set, a case that only arises when the
resolver chooses not to set the CD bit on all upstream queries, as resolver chooses not to set the CD bit on all upstream queries, as
@@ -497,14 +512,6 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
does the cache need to track the state of the CD bit used to make a does the cache need to track the state of the CD bit used to make a
given query. The problem arises when the cached response is a server given query. The problem arises when the cached response is a server
failure (RCODE 2), which may indicate that the requested data failed failure (RCODE 2), which may indicate that the requested data failed
Weiler & Blacka Expires July 16, 2012 [Page 9]
Internet-Draft DNSSECbis Implementation Notes January 2012
DNSSEC validation at an upstream validating resolver. (RFC2308 DNSSEC validation at an upstream validating resolver. (RFC2308
permits caching of server failures for up to five minutes.) In these permits caching of server failures for up to five minutes.) In these
cases, a new query with the CD bit set is required. cases, a new query with the CD bit set is required.
@@ -546,21 +553,20 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
This policy has the disadvantage of possibly giving the user some This policy has the disadvantage of possibly giving the user some
unexpected and unnecessary validation failures when sub-zone trust unexpected and unnecessary validation failures when sub-zone trust
anchors are neglected. As a concrete example, consider a validator anchors are neglected. As a concrete example, consider a validator
Weiler & Blacka Expires July 17, 2012 [Page 10]
Internet-Draft DNSSECbis Implementation Notes January 2012
that configured a trust anchor for "zone.example." in 2009 and one that configured a trust anchor for "zone.example." in 2009 and one
for "example." in 2011. In 2012, "zone.example." rolls its KSK and for "example." in 2011. In 2012, "zone.example." rolls its KSK and
updates its DS records, but the validator operator doesn't update its updates its DS records, but the validator operator doesn't update its
trust anchor. With the "closest encloser" policy, the validator gets trust anchor. With the "closest encloser" policy, the validator gets
validation failures. validation failures.
Weiler & Blacka Expires July 16, 2012 [Page 10]
Internet-Draft DNSSECbis Implementation Notes January 2012
5.10.2. Accept Any Success 5.10.2. Accept Any Success
Another policy is to try all applicable trust anchors until one gives Another policy is to try all applicable trust anchors until one gives
@@ -604,19 +610,19 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
anchors from a different DLV registry, then the rest of the manually anchors from a different DLV registry, then the rest of the manually
configured trust anchors. configured trust anchors.
Weiler & Blacka Expires July 17, 2012 [Page 11]
Internet-Draft DNSSECbis Implementation Notes January 2012
5.11. Mandatory Algorithm Rules 5.11. Mandatory Algorithm Rules
The last paragraph of RFC4035 Section 2.2 includes rules for which The last paragraph of RFC4035 Section 2.2 includes rules for which
algorithms must be used to sign a zone. Since these rules have been algorithms must be used to sign a zone. Since these rules have been
confusing, we restate them in different language here: confusing, we restate them in different language here:
Weiler & Blacka Expires July 16, 2012 [Page 11]
Internet-Draft DNSSECbis Implementation Notes January 2012
The DS RRset and DNSKEY RRset are used to signal which algorithms The DS RRset and DNSKEY RRset are used to signal which algorithms
are used to sign a zone. The pressence of an algorithm in a are used to sign a zone. The pressence of an algorithm in a
zone's DS or DNSKEY RRset set signals that that algorithm is used zone's DS or DNSKEY RRset set signals that that algorithm is used
@@ -657,6 +663,16 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
zone. zone.
Weiler & Blacka Expires July 17, 2012 [Page 12]
Internet-Draft DNSSECbis Implementation Notes January 2012
6. Minor Corrections and Clarifications 6. Minor Corrections and Clarifications
6.1. Finding Zone Cuts 6.1. Finding Zone Cuts
@@ -665,14 +681,6 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
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.
Weiler & Blacka Expires July 16, 2012 [Page 12]
Internet-Draft DNSSECbis Implementation Notes January 2012
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,
and in some situations the resolver may also need to apply special and in some situations the resolver may also need to apply special
@@ -713,22 +721,20 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
wildcard expansion. This is true for "x.w.example" but not for wildcard expansion. This is true for "x.w.example" but not for
"x.w.example.com", which of course has a label count of 4 "x.w.example.com", which of course has a label count of 4
(antithetically, a label count of 3 would imply the answer was the (antithetically, a label count of 3 would imply the answer was the
Weiler & Blacka Expires July 17, 2012 [Page 13]
Internet-Draft DNSSECbis Implementation Notes January 2012
result of a wildcard expansion). result of a wildcard expansion).
The first paragraph of [RFC4035] Section C.6 also has a minor error: The first paragraph of [RFC4035] Section C.6 also has a minor error:
the reference to "a.z.w.w.example" should instead be "a.z.w.example", the reference to "a.z.w.w.example" should instead be "a.z.w.example",
as in the previous line. as in the previous line.
Weiler & Blacka Expires July 16, 2012 [Page 13]
Internet-Draft DNSSECbis Implementation Notes January 2012
6.4. Errors in RFC 5155 6.4. Errors in RFC 5155
A NSEC3 record that matches an Empty Non-Terminal effectively has no A NSEC3 record that matches an Empty Non-Terminal effectively has no
@@ -771,20 +777,19 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
The recommendation in Section 5.9 to always set the CD bit has The recommendation in Section 5.9 to always set the CD bit has
security implications. By setting the CD bit, a resolver will not security implications. By setting the CD bit, a resolver will not
benefit from more stringent validation rules or a more complete set benefit from more stringent validation rules or a more complete set
Weiler & Blacka Expires July 17, 2012 [Page 14]
Internet-Draft DNSSECbis Implementation Notes January 2012
of trust anchors at an upstream validator. of trust anchors at an upstream validator.
9. References 9. References
Weiler & Blacka Expires July 16, 2012 [Page 14]
Internet-Draft DNSSECbis Implementation Notes January 2012
9.1. Normative References 9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
@@ -828,19 +833,19 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
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,
Weiler & Blacka Expires July 17, 2012 [Page 15]
Internet-Draft DNSSECbis Implementation Notes January 2012
July 2007. July 2007.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007. Trust Anchors", RFC 5011, September 2007.
Weiler & Blacka Expires July 16, 2012 [Page 15]
Internet-Draft DNSSECbis Implementation Notes January 2012
[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
November 2007. November 2007.
@@ -882,6 +887,16 @@ Appendix A. Acknowledgments
document. document.
Weiler & Blacka Expires July 17, 2012 [Page 16]
Internet-Draft DNSSECbis Implementation Notes January 2012
Appendix B. Discussion of Setting the CD Bit Appendix B. Discussion of Setting the CD Bit
RFC 4035 may be read as relying on the implicit assumption that there RFC 4035 may be read as relying on the implicit assumption that there
@@ -889,14 +904,6 @@ Appendix B. Discussion of Setting the CD Bit
resolver and the authoritative server for a given zone. It is resolver and the authoritative server for a given zone. It is
entirely possible, however, for more than one validator to stand entirely possible, however, for more than one validator to stand
between a stub resolver and an authoritative server. If these between a stub resolver and an authoritative server. If these
Weiler & Blacka Expires July 16, 2012 [Page 16]
Internet-Draft DNSSECbis Implementation Notes January 2012
different validators have disjoint trust anchors configured, then it different validators have disjoint trust anchors configured, then it
will be possible that each would be able to validate some portion of will be possible that each would be able to validate some portion of
the DNS tree but neither will be able to validate all of it. the DNS tree but neither will be able to validate all of it.
@@ -938,21 +945,19 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
upstream. The distinction is really between "cached RCODE=2" and upstream. The distinction is really between "cached RCODE=2" and
"cached everything else". "cached everything else".
Weiler & Blacka Expires July 17, 2012 [Page 17]
Internet-Draft DNSSECbis Implementation Notes January 2012
The tables are probably easiest to think of in terms of describing The tables are probably easiest to think of in terms of describing
what happens when a stub resolver sends a query to an intermediate what happens when a stub resolver sends a query to an intermediate
resolver, but they are perfectly general and can be applied to any resolver, but they are perfectly general and can be applied to any
validating resolver. validating resolver.
Weiler & Blacka Expires July 16, 2012 [Page 17]
Internet-Draft DNSSECbis Implementation Notes January 2012
Model 1: "always set" Model 1: "always set"
This model is so named because the validating resolver sets the CD This model is so named because the validating resolver sets the CD
@@ -985,6 +990,25 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
1 is NOT RECOMMENDED. 1 is NOT RECOMMENDED.
Weiler & Blacka Expires July 17, 2012 [Page 18]
Internet-Draft DNSSECbis Implementation Notes January 2012
CD F/C line conditions action CD F/C line conditions action
==================================================================== ====================================================================
1 F N1 Set CD=1 on upstream query 1 F N1 Set CD=1 on upstream query
@@ -1001,14 +1025,6 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
generated with CD=0 generated with CD=0
Weiler & Blacka Expires July 16, 2012 [Page 18]
Internet-Draft DNSSECbis Implementation Notes January 2012
Model 3: "sometimes set" Model 3: "sometimes set"
This model is so named because it sets the CD bit on upstream queries This model is so named because it sets the CD bit on upstream queries
@@ -1041,6 +1057,14 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
was generated was generated
with CD=1 & with CD=1 &
no covering no covering
Weiler & Blacka Expires July 17, 2012 [Page 19]
Internet-Draft DNSSECbis Implementation Notes January 2012
TA TA
@@ -1056,15 +1080,6 @@ Authors' Addresses
Email: weiler@tislabs.com Email: weiler@tislabs.com
Weiler & Blacka Expires July 16, 2012 [Page 19]
Internet-Draft DNSSECbis Implementation Notes January 2012
David Blacka David Blacka
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
@@ -1101,20 +1116,5 @@ Internet-Draft DNSSECbis Implementation Notes January 2012
Weiler & Blacka Expires July 17, 2012 [Page 20]
Weiler & Blacka Expires July 16, 2012 [Page 20]