< draft-ietf-dnsop-negative-trust-anchors-07.txt   draft-ietf-dnsop-negative-trust-anchors-08.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 10, 2015 Expires: November 11, 2015
W. Kumari W. Kumari
Google Google
J. Livingood J. Livingood
Comcast Comcast
R. Weber R. Weber
Nominum Nominum
May 9, 2015 May 10, 2015
Definition and Use of DNSSEC Negative Trust Anchors Definition and Use of DNSSEC Negative Trust Anchors
draft-ietf-dnsop-negative-trust-anchors-07 draft-ietf-dnsop-negative-trust-anchors-08
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 10, 2015. This Internet-Draft will expire on November 11, 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 2, line 45 skipping to change at page 2, line 45
8.1. Security Considerations . . . . . . . . . . . . . . . . . 11 8.1. Security Considerations . . . . . . . . . . . . . . . . . 11
8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 11 8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 11
8.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 8.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 13 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 13
A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 13 A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 13
A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 13 A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 13
A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 13 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction and motivation 1. Introduction and motivation
This document defines a Negative Trust Anchor, which can be used This document defines a Negative Trust Anchor, which can be used
during the transition to ubiquitous DNSSEC deployment. Negative during the transition to ubiquitous DNSSEC deployment. Negative
Trust Anchors (NTAs) are configured locally on a validating DNS Trust Anchors (NTAs) are configured locally on a validating DNS
recursive resolver to shield end users from DNSSEC-related recursive resolver to shield end users from DNSSEC-related
authoritative name server operational errors. Negative Trust Anchors authoritative name server operational errors. Negative Trust Anchors
are intended to be temporary, and should not be distributed by IANA are intended to be temporary, and should not be distributed by IANA
or any other organization outside of the administrative boundary of or any other organization outside of the administrative boundary of
skipping to change at page 5, line 50 skipping to change at page 5, line 50
domain's authoritative servers and modified those records or had the domain's authoritative servers and modified those records or had the
domain pointed to their own rogue authoritative servers. They should domain pointed to their own rogue authoritative servers. They should
also confirm that the domain is not intentionally broken, such as for also confirm that the domain is not intentionally broken, such as for
testing purposes as noted in Section 6. Finally, they should make a testing purposes as noted in Section 6. Finally, they should make a
reasonable attempt to contact the domain owner of the misconfigured reasonable attempt to contact the domain owner of the misconfigured
zone, preferably prior to implementing the Negative Trust Anchor. zone, preferably prior to implementing the Negative Trust Anchor.
Involving trained technical personnel is costly, but operational Involving trained technical personnel is costly, but operational
experience suggests that this is a very rare event, usually on the experience suggests that this is a very rare event, usually on the
order of once per quarter (or even less). order of once per quarter (or even less).
It is important to confirm that the comains is still under the It is important for the resolver operator to confirm that the domain
ownership / control of the legitimate owner of the domain - this is is still under the ownership / control of the legitimate owner of the
to ensure that disabling validation for a specific domain does not domain in order to ensure that disabling validation for a specific
direct users to an address under an attackers control. Contacting domain does not direct users to an address under an attacker's
the domain owner allows the resolver operator to determine if the control. Contacting the domain owner and telling them the DNSSEC
issue is a DNSSEC misconfiguration or an attack. records that the resolver operator is seeing allows the resolver
operator to determine if the issue is a DNSSEC misconfiguration or an
attack.
In the case of a validation failure due to misconfiguration of a TLD In the case of a validation failure due to misconfiguration of a TLD
or popular domain name (such as a top 100 website), content or or popular domain name (such as a top 100 website), content or
services in the affected TLD or domain could be inaccessible for a services in the affected TLD or domain could be inaccessible for a
large number of users. In such cases, it may be appropriate to use a large number of users. In such cases, it may be appropriate to use a
Negative Trust Anchor as soon as the misconfiguration is confirmed. Negative Trust Anchor as soon as the misconfiguration is confirmed.
An example of a list of "top N" websites is the "Alexa Top 500 Sites An example of a list of "top N" websites is the "Alexa Top 500 Sites
on the Web" [Alexa], another example would be to look through on the Web" [Alexa], , or a list of the of the most-accessed names in
historical query logs. the resolver's cache.
Once a domain has been confirmed to fail DNSSEC validation due to a Once a domain has been confirmed to fail DNSSEC validation due to a
DNSSEC-related misconfiguration, an ISP or other DNS recursive DNSSEC-related misconfiguration, an ISP or other DNS recursive
resolver operator may elect to use a Negative Trust Anchor for that resolver operator may elect to use a Negative Trust Anchor for that
domain or sub-domain. This instructs their DNS recursive resolver to domain or sub-domain. This instructs their DNS recursive resolver to
temporarily NOT perform DNSSEC validation at or in the misconfigured temporarily NOT perform DNSSEC validation at or in the misconfigured
domain. This immediately restores access to the domain for end users domain. This immediately restores access to the domain for end users
while the domain's administrator corrects the misconfiguration(s). while the domain's administrator corrects the misconfiguration(s).
It does not and should not involve turning off validation more It does not and should not involve turning off validation more
broadly. broadly.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
stages of DNSSEC adoption, domain owners are ultimately responsible stages of DNSSEC adoption, domain owners are ultimately responsible
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.
It is RECOMMENDED that implmentations warn operators (or treat as an An NTA placed at a node where there is a configured positive trust
error) if they attempt to add an NTA for a domain that has a anchor takes precendence over that trust anchor, effectively
configured positive trust anchor. disabling it. Implementations MAY issue a warning when this occurs.
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 11, line 7 skipping to change at page 11, line 7
the key. The checks above should be done, with the addition of the key. The checks above should be done, with the addition of
checking if another key in the DNSKEY RRSet is now used to sign checking if another key in the DNSKEY RRSet is now used to sign
the records. the records.
* Data in DS or DNSKEY doesn't match the other. This is more * Data in DS or DNSKEY doesn't match the other. This is more
common in initial setup when there was a copy and paste error. common in initial setup when there was a copy and paste error.
Again checking history on data is the best you can do there. Again checking history on data is the best you can do there.
All of the above is just a starting point for consideration when All of the above is just a starting point for consideration when
deciding whether or not to deploy a trust anchor. It is not possible deciding whether or not to deploy a trust anchor. It is not possible
to provide a simple checklist to run through to determine if a domain to provide a simple checklist to run through to determine whether a
is broken because of an attack or an operator error. domain is broken because of an attack or an operator error.
8. Other Considerations 8. Other Considerations
8.1. Security Considerations 8.1. Security Considerations
End to end DNSSEC validation will be disabled during the time that a End to end DNSSEC validation will be disabled during the time that a
Negative Trust Anchor is used. In addition, the Negative Trust Negative Trust Anchor is used. In addition, the Negative Trust
Anchor may be in place after the point in time when the DNS Anchor may be in place after the point in time when the DNS
misconfiguration that caused validation to break has been fixed. misconfiguration that caused validation to break has been fixed.
Thus, there may be a gap between when a domain has been re-secured Thus, there may be a gap between when a domain has been re-secured
skipping to change at page 11, line 52 skipping to change at page 11, line 52
played an important role in the development and evolution of this played an important role in the development and evolution of this
document. This in some cases included performing a detailed review document. This in some cases included performing a detailed review
of this document and then providing feedback and constructive of this document and then providing feedback and constructive
criticism for future revisions, or engaging in a healthy debate over criticism for future revisions, or engaging in a healthy debate over
the subject of the document. All of this was helpful and therefore the subject of the document. All of this was helpful and therefore
the following individuals merit acknowledgement: Joe Abley,John the following individuals merit acknowledgement: Joe Abley,John
Barnitz, Tom Creighton, Marco Davids, Brian Dickson, Patrik Falstrom, Barnitz, Tom Creighton, Marco Davids, Brian Dickson, Patrik Falstrom,
Tony Finch, Chris Ganster, Olafur Gudmundsson, Peter Hagopian, Wes Tony Finch, Chris Ganster, Olafur Gudmundsson, Peter Hagopian, Wes
Hardaker, Paul Hoffman, Shane Kerr, Murray Kucherawy, Rick Lamb, Marc Hardaker, Paul Hoffman, Shane Kerr, Murray Kucherawy, Rick Lamb, Marc
Lampo, Scott Rose, Ted Lemon, Antoin Verschuren, Paul Vixie, Patrik Lampo, Scott Rose, Ted Lemon, Antoin Verschuren, Paul Vixie, Patrik
Wallstrom, Nick Weaver Wallstrom, W.C.A. Wijngaards, Nick Weaver
Edward Lewis, Evan Hunt, Andew Sullivan and Tatuya Jinmei provided Edward Lewis, Evan Hunt, Andew Sullivan and Tatuya Jinmei provided
especially large amounts of text and / or detailed review. especially large amounts of text and / or detailed review.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, March 2005.
skipping to change at page 13, line 21 skipping to change at page 13, line 21
to test and understand the implications of these operations. Note to test and understand the implications of these operations. Note
also that some of available implementations may not implement all also that some of available implementations may not implement all
recommended functionality in this document. In that case it is recommended functionality in this document. In that case it is
advisable to request the developer or vendor of the implementation to advisable to request the developer or vendor of the implementation to
support the missing feature, rather than start using the incomplete support the missing feature, rather than start using the incomplete
implementation. implementation.
A.1. NLNet Labs Unbound A.1. NLNet Labs Unbound
Unbound lets us simply disable validation checking for a specific Unbound lets us simply disable validation checking for a specific
zone. zone by adding configuration statements to unbound.conf:
For additional information see [Unound-Configuration]
server: server:
domain-insecure: "foo.example.com" domain-insecure: "foo.example.com"
Using the 'unbound-control' command one can add and remove Negative
Trust Anchors without restarting the nameserver.
Using the "unbound-control" command:
list_insecure list domain-insecure zones
insecure_add zone add domain-insecure zone
insecure_remove zone remove domain-insecure zone
Items added with the "unbound-control" command are added to the
running server and are lost when the server is restarted. Items from
unbound.conf stay after restart.
For additional information see [Unound-Configuration]
A.2. ISC BIND A.2. ISC BIND
Use the "rndc" command: Use the "rndc" command:
nta -dump nta -dump
List all negative trust anchors. List all negative trust anchors.
nta [-lifetime duration] [-force] domain [view] nta [-lifetime duration] [-force] domain [view]
Set a negative trust anchor, disabling DNSSEC validation Set a negative trust anchor, disabling DNSSEC validation
for the given domain. for the given domain.
Using -lifetime specifies the duration of the NTA, up Using -lifetime specifies the duration of the NTA, up
skipping to change at page 14, line 4 skipping to change at page 14, line 25
Remove a negative trust anchor, re-enabling validation Remove a negative trust anchor, re-enabling validation
for the given domain. for the given domain.
A.3. Nominum Vantio A.3. Nominum Vantio
** **
*negative-trust-anchors* *negative-trust-anchors*
_Format_: name _Format_: name
_Command Channel_: view.update name=world negative-trust- _Command Channel_: view.update name=world negative-trust-
anchors=(foo.example.com) anchors=(foo.example.com)
_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]
-06 to 07 -07 to -08
o Added some cleanup from Paul Hoffman and Evan Hunt.
o Some better text on how to make Unbound do this, provided by
W.C.A. Wijngaards.
-06 to -07
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. 16 change blocks. 
25 lines changed or deleted 46 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/