< draft-ietf-dnsop-negative-trust-anchors-08.txt   draft-ietf-dnsop-negative-trust-anchors-09.txt >
Domain Name System Operations P. Ebersman Domain Name System Operations P. Ebersman
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational C. Griffiths Intended status: Informational C. Griffiths
Expires: November 11, 2015 Expires: November 13, 2015
W. Kumari W. Kumari
Google Google
J. Livingood J. Livingood
Comcast Comcast
R. Weber R. Weber
Nominum Nominum
May 10, 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-08 draft-ietf-dnsop-negative-trust-anchors-09
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 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 11, 2015. This Internet-Draft will expire on November 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 19 skipping to change at page 7, line 19
for managing and ensuring their DNS records are configured correctly. for managing and ensuring their DNS records are configured correctly.
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 takes precendence over that trust anchor, effectively anchor MUST take precendence over that trust anchor, effectively
disabling it. Implementations MAY issue a warning when this occurs. disabling it. Implementations SHOULD issue a warning or
informational message when this occurs, so that operators are not
surprised when 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]
-08 to -09
o Clarified that an NTA MUST take precedece over a positive, local
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
W.C.A. Wijngaards. W.C.A. Wijngaards.
-06 to -07 -06 to -07
o Addressed a large number of comments from Paul Hoffman, Scott Rose
Addressed a large number of comments from Paul Hoffman, Scott Rose
and some more from Jinmei. and some more from Jinmei.
-05 to -06 -05 to -06
o A bunch of comments from Tony Finch. o A bunch of comments from Tony Finch.
-04 to -05 -04 to -05
o A large bunch of cleanups from Jinmei. Thanks! o A large bunch of cleanups from Jinmei. Thanks!
o Also clarified that if there is an NTA at foo.bar.baz.example, and o Also clarified that if there is an NTA at foo.bar.baz.example, and
a positive *trust anchor* at bar.baz.example, the most specific a positive *trust anchor* at bar.baz.example, the most specific
wins. I'm not very happy with this text, any additional text wins. I'm not very happy with this text, any additional text
gratefully accepted... gratefully accepted...
 End of changes. 8 change blocks. 
8 lines changed or deleted 15 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/