| < draft-ietf-dnsop-negative-trust-anchors-09.txt | draft-ietf-dnsop-negative-trust-anchors-10.txt > | |||
|---|---|---|---|---|
| skipping to change at page 1, line 16 ¶ | skipping to change at page 1, line 16 ¶ | |||
| Expires: November 13, 2015 | Expires: November 13, 2015 | |||
| W. Kumari | W. Kumari | |||
| J. Livingood | J. Livingood | |||
| Comcast | Comcast | |||
| R. Weber | R. Weber | |||
| Nominum | Nominum | |||
| May 12, 2015 | May 12, 2015 | |||
| Definition and Use of DNSSEC Negative Trust Anchors | Definition and Use of DNSSEC Negative Trust Anchors | |||
| draft-ietf-dnsop-negative-trust-anchors-09 | draft-ietf-dnsop-negative-trust-anchors-10 | |||
| Abstract | Abstract | |||
| DNS Security Extensions (DNSSEC) is now entering widespread | DNS Security Extensions (DNSSEC) is now entering widespread | |||
| deployment. However, domain signing tools and processes are not yet | deployment. However, domain signing tools and processes are not yet | |||
| as mature and reliable as those for non-DNSSEC-related domain | as mature and reliable as those for non-DNSSEC-related domain | |||
| administration tools and processes. Negative Trust Anchors | administration tools and processes. Negative Trust Anchors | |||
| (described in this document) can be used to mitigate DNSSEC | (described in this document) can be used to mitigate DNSSEC | |||
| validation failures. | validation failures. | |||
| skipping to change at page 7, line 20 ¶ | skipping to change at page 7, line 20 ¶ | |||
| Most current implementations of DNS validating resolvers currently | Most current implementations of DNS validating resolvers currently | |||
| follow [RFC4033] on configuring a Trust Anchor using either a public | follow [RFC4033] on configuring a Trust Anchor using either a public | |||
| key as in a DNSKEY RR or a hash of a public key as in a DS RR. | key as in a DNSKEY RR or a hash of a public key as in a DS RR. | |||
| Different DNS validators may have different configuration names for a | Different DNS validators may have different configuration names for a | |||
| Negative Trust Anchor. For examples see Appendix A. | Negative Trust Anchor. For examples see Appendix A. | |||
| An NTA placed at a node where there is a configured positive trust | An NTA placed at a node where there is a configured positive trust | |||
| anchor MUST take precendence over that trust anchor, effectively | anchor MUST take precendence over that trust anchor, effectively | |||
| disabling it. Implementations SHOULD issue a warning or | disabling it. Implementations MAY issue a warning or informational | |||
| informational message when this occurs, so that operators are not | message when this occurs, so that operators are not surprised when | |||
| surprised when this happens. | this happens. | |||
| 3.1. Alerting Users to NTA Use | 3.1. Alerting Users to NTA Use | |||
| End users of a DNS recursive resolver or other people may wonder why | End users of a DNS recursive resolver or other people may wonder why | |||
| a domain that fails DNSSEC validation resolves with a supposedly | a domain that fails DNSSEC validation resolves with a supposedly | |||
| validating resolver. As a result, implementors should consider | validating resolver. As a result, implementors should consider | |||
| transparently disclosing those Negative Trust Anchors which are | transparently disclosing those Negative Trust Anchors which are | |||
| currently in place or were in place in the past, such as on a website | currently in place or were in place in the past, such as on a website | |||
| [Disclosure-Example]. | [Disclosure-Example]. | |||
| skipping to change at page 14, line 39 ¶ | skipping to change at page 14, line 39 ¶ | |||
| _Command Channel_: resolver.update name=res1 negative-trust- | _Command Channel_: resolver.update name=res1 negative-trust- | |||
| anchors=(foo.example.com) | anchors=(foo.example.com) | |||
| *Description*: Disables DNSSEC validation for a domain, even if the | *Description*: Disables DNSSEC validation for a domain, even if the | |||
| domain is under an existing security root. | domain is under an existing security root. | |||
| Appendix B. Document Change Log | Appendix B. Document Change Log | |||
| [RFC Editor: This section is to be removed before publication] | [RFC Editor: This section is to be removed before publication] | |||
| -09 to -10 | ||||
| o 'Implementations MAY issue a warning or informational message when | ||||
| this occurs' - changed SHOULD to MAY, per Evan. | ||||
| -08 to -09 | -08 to -09 | |||
| o Clarified that an NTA MUST take precedece over a positive, local | o Clarified that an NTA MUST take precedece over a positive, local | |||
| TA. | TA. | |||
| -07 to -08 | -07 to -08 | |||
| o Added some cleanup from Paul Hoffman and Evan Hunt. | o Added some cleanup from Paul Hoffman and Evan Hunt. | |||
| o Some better text on how to make Unbound do this, provided by | o Some better text on how to make Unbound do this, provided by | |||
| End of changes. 3 change blocks. | ||||
| 4 lines changed or deleted | 9 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||