< draft-ietf-dnsop-negative-trust-anchors-00.txt   draft-ietf-dnsop-negative-trust-anchors-01.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: June 18, 2015 Dyn Expires: September 5, 2015 Dyn
W. Kumari W. Kumari
Google Google
J. Livingood J. Livingood
Comcast Comcast
R. Weber R. Weber
Nominum Nominum
December 15, 2014 March 04, 2015
Definition and Use of DNSSEC Negative Trust Anchors Definition and Use of DNSSEC Negative Trust Anchors
draft-ietf-dnsop-negative-trust-anchors-00 draft-ietf-dnsop-negative-trust-anchors-01
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.
[RFC Editor: Please remove this before puiblication. This document
is being stored in github at https://github.com/wkumari/draft-
livingood-dnsop-negative-trust-anchors . Authors accept pull
requests, and keep the latest (edit buffer) versions there, so
commenters can follow along at home.]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 18, 2015. This Internet-Draft will expire on September 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of a Negative Trust Anchor . . . . . . . . . . . . 3 2. Definition of a Negative Trust Anchor . . . . . . . . . . . . 4
3. delete . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Domain Validation Failures . . . . . . . . . . . . . . . . . 4
4. Domain Validation Failures . . . . . . . . . . . . . . . . . 4 4. End User Reaction . . . . . . . . . . . . . . . . . . . . . . 4
5. End User Reaction . . . . . . . . . . . . . . . . . . . . . . 4 5. Switching to a Non-Validating Resolver is Not Recommended . . 5
6. Switching to a Non-Validating Resolver is Not Recommended . . 5 6. Responsibility for Failures . . . . . . . . . . . . . . . . . 5
7. Responsibility for Failures . . . . . . . . . . . . . . . . . 5 7. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 6
8. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 6 8. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 7
9. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 7 9. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 8
10. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7 10. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8
11. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8 11. Intentionally Broken Domains . . . . . . . . . . . . . . . . 9
12. Intentionally Broken Domains . . . . . . . . . . . . . . . . 8 12. Other Considerations . . . . . . . . . . . . . . . . . . . . 9
13. Other Considerations . . . . . . . . . . . . . . . . . . . . 8 12.1. Security Considerations . . . . . . . . . . . . . . . . 9
13.1. Security Considerations . . . . . . . . . . . . . . . . 8 12.2. Privacy Considerations . . . . . . . . . . . . . . . . . 10
13.2. Privacy Considerations . . . . . . . . . . . . . . . . . 9 12.3. IANA Considerations . . . . . . . . . . . . . . . . . . 10
13.3. IANA Considerations . . . . . . . . . . . . . . . . . . 9 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 14.1. Normative References . . . . . . . . . . . . . . . . . . 11
15.1. Normative References . . . . . . . . . . . . . . . . . . 10 14.2. Informative References . . . . . . . . . . . . . . . . . 12
15.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 12 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 12
A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 12 A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 13
A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 12 A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 13
A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 12 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 13 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and
related operational practices are defined extensively [RFC1034] related operational practices are defined extensively [RFC1034]
[RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781] [RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781]
[RFC5155]. [RFC5155].
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 3, line 36 skipping to change at page 3, line 39
a failure on the part of the domain they wanted to reach. Without a failure on the part of the domain they wanted to reach. Without
the techniques in this document, this pressure may cause the resolver the techniques in this document, this pressure may cause the resolver
operator to disable (or simply not deploy) DNSSEC validation. Use of operator to disable (or simply not deploy) DNSSEC validation. Use of
a Negative Trust Anchor to temporarily disable DNSSEC validation for a Negative Trust Anchor to temporarily disable DNSSEC validation for
a specific misconfigured domain name immediately restores access for a specific misconfigured domain name immediately restores access for
end users. This allows the domain's administrators to fix their end users. This allows the domain's administrators to fix their
misconfiguration, while also allowing the organization using the misconfiguration, while also allowing the organization using the
Negative Trust Anchor to keep DNSSEC validation enabled and still Negative Trust Anchor to keep DNSSEC validation enabled and still
reach the misconfigured domain. reach the misconfigured domain.
It is worth noting the folowing text from RFC4033 [RFC4033] - "In the
final analysis, however, authenticating both DNS keys and data is a
matter of local policy, which may extend or even override the
protocol extensions defined in this document set." A responsibility
(one of many) of a caching server operator is to "protect the
integrity of the cache." DNSSEC is just a tool to help accomplish
that. It carries ancillary data that a local cache administrator may
use to filter out undesired responses. DNSSEC is not an enforcement
mechanism, it's a resource. When I see folks voice opinions that
DNSSEC's recommended operation has to strictly followed, my gut
reaction is that these folks have forgotten the purpose of all of our
efforts. We don't secure protocols to make things work better. We
don't operate the DNS because we like to run a well run machine. We
don't run the Internet for the fun of it. (Some might enjoy running
it, that's job satisfaction to some extent.) At the end of the day
all that matters is that what is being done benefits society. We run
the Internet to enrich society. We prefer a well run DNS because it
saps less resources than a poorly run DNS. We prefer secure
protocols so that people don't become victims (in some sense of the
word). Make it work. Do what it takes to make it work. "Local
policy" rules.
2. Definition of a Negative Trust Anchor 2. Definition of a Negative Trust Anchor
Trust Anchors are defined in [RFC5914]. A trust anchor should be Trust Anchors are defined in [RFC5914]. A trust anchor should be
used by a validating caching resolver as a starting point for used by a validating caching resolver as a starting point for
building the authentication chain for a signed DNS response. The building the authentication chain for a signed DNS response. The
inverse of this is a Negative Trust Anchor, which creates a stopping inverse of this is a Negative Trust Anchor, which creates a stopping
point for a caching resolver to end validation of the authentication point for a caching resolver to end validation of the authentication
chain. Instead, the resolver sends the response as if the zone is chain. Instead, the resolver sends the response as if the zone is
unsigned and does not set the AD bit. This Negative Trust Anchor can unsigned and does not set the AD bit. Note that this is a behavior,
potentially be placed at any level within the chain of trust and and not a seperate resource record. This Negative Trust Anchor can
potentially be implemented at any level within the chain of trust and
would stop validation from that point in the chain down. would stop validation from that point in the chain down.
3. delete 3. Domain Validation Failures
4. Domain Validation Failures
A domain name can fail validation for two general reasons: a A domain name can fail validation for two general reasons: a
legitimate security failure such as due to an attack or compromise of legitimate security failure such as due to an attack or compromise of
some sort, or as a result of misconfiguration on the part of an some sort, or as a result of misconfiguration on the part of an
domain administrator. As domains transition to DNSSEC the most domain administrator. As domains transition to DNSSEC, the most
likely reason for a validation failure will be misconfiguration. likely reason for a validation failure will be misconfiguration.
Thus, domain administrators should be sure to read [RFC6781] in full. Thus, domain administrators should be sure to read [RFC6781] in full.
They should also pay special attention to Section 4.2, pertaining to They should also pay special attention to Section 4.2, pertaining to
key rollovers, which appear to be the cause of many recent validation key rollovers, which appear to be the cause of many recent validation
failures. failures.
It is also possible that some DNSSEC validation failures could arise It is also possible that some DNSSEC validation failures could arise
due to differences in how different software developers interpret due to differences in how different software developers interpret
DNSSEC standards and/or how those developers choose to implement DNSSEC standards and/or how those developers choose to implement
support for DNSSEC. For example, it is conceivable that a domain may support for DNSSEC. For example, it is conceivable that a domain may
be DNSSEC signed properly, and one vendor's DNS recursive resolvers be DNSSEC signed properly, and one vendor's DNS recursive resolvers
will validate the domain but other vendors' software may fail to will validate the domain but other vendors' software may fail to
validate the domain. validate the domain.
5. End User Reaction 4. End User Reaction
End users generally do not know what DNSSEC is, nor should they be End users generally do not know what DNSSEC is, nor should they be
expected to at the current time (especially absent widespread expected to at the current time (especially absent widespread
integration of DNSSEC indicators in end user software such as web integration of DNSSEC indicators in end user software such as web
browsers). As a result, end users may misinterpret the failure to browsers). As a result, end users may misinterpret the failure to
reach a domain due to DNSSEC-related misconfiguration . They may reach a domain due to DNSSEC-related misconfiguration . They may
(incorrectly) assume that their ISP is purposely blocking access to (incorrectly) assume that their ISP is purposely blocking access to
the domain or that it is a performance failure on the part of their the domain or that it is a performance failure on the part of their
ISP (especially of the ISP's DNS servers). They may contact their ISP (especially of the ISP's DNS servers). They may contact their
ISP to complain, which will incur cost for their ISP. In addition, ISP to complain, which will incur cost for their ISP. In addition,
skipping to change at page 5, line 5 skipping to change at page 5, line 26
recursive resolver operator is actually doing exactly what they are recursive resolver operator is actually doing exactly what they are
supposed to do in failing to resolve a domain name, as this is the supposed to do in failing to resolve a domain name, as this is the
expected result when a domain can no longer be validated, protecting expected result when a domain can no longer be validated, protecting
end users from a potential security threat. Use of a Negative Trust end users from a potential security threat. Use of a Negative Trust
Anchor would allow the ISP to specifically remedy the failure to Anchor would allow the ISP to specifically remedy the failure to
reach that domain, without compromising security for other sites. reach that domain, without compromising security for other sites.
This would result in a satisfied end user, with minimal impact to the This would result in a satisfied end user, with minimal impact to the
ISP, while maintaining the security of DNSSEC for correctly ISP, while maintaining the security of DNSSEC for correctly
maintained domains. maintained domains.
6. Switching to a Non-Validating Resolver is Not Recommended 5. Switching to a Non-Validating Resolver is Not Recommended
As noted in Section 5 some people may consider switching to an As noted in Section 4, some people may consider switching to an
alternative, non-validating resolver themselves, or may recommend alternative, non-validating resolver themselves, or may recommend
that others do so. But if a domain fails DNSSEC validation and is that others do so. But if a domain fails DNSSEC validation and is
inaccessible, this could very well be due to a security-related inaccessible, this could very well be due to a security-related
issue. In order to be as safe and secure as possible, end users issue. In order to be as safe and secure as possible, end users
should not change to DNS servers that do not perform DNSSEC should not change to DNS servers that do not perform DNSSEC
validation as a workaround, and people should not recommend that validation as a workaround, and people should not recommend that
others do so either. Domains that fail DNSSEC for legitimate reasons others do so either. Domains that fail DNSSEC for legitimate reasons
(versus misconfiguration) may be in control of hackers or there could (versus misconfiguration) may be in control of hackers or there could
be other significant security issues with the domain. be other significant security issues with the domain.
Thus, switching to a non-validating resolver to restore access to a Thus, switching to a non-validating resolver to restore access to a
domain that fails DNSSEC validation is not a recommended practice, is domain that fails DNSSEC validation is not a recommended practice, is
bad advice to others, is potentially harmful to end user security, bad advice to others, is potentially harmful to end user security,
and is potentially harmful to DNSSEC adoption. and is potentially harmful to DNSSEC adoption.
7. Responsibility for Failures 6. Responsibility for Failures
A domain administrator is solely and completely responsible for A domain administrator is solely and completely responsible for
managing their domain name(s) and DNS resource records. This managing their domain name(s) and DNS resource records. This
includes complete responsibility for the correctness of those includes complete responsibility for the correctness of those
resource records, the proper functioning of their DNS authoritative resource records, the proper functioning of their DNS authoritative
servers, and the correctness of DNS records linking their domain to a servers, and the correctness of DNS records linking their domain to a
top-level domain (TLD) or other higher level domain. Even in cases top-level domain (TLD) or other higher level domain. Even in cases
where some error may be introduced by a third party, whether that is where some error may be introduced by a third party, whether that is
due to an authoritative server software vendor, software tools due to an authoritative server software vendor, software tools
vendor, domain name registrar, or other organization, these are all vendor, domain name registrar, or other organization, these are all
skipping to change at page 6, line 5 skipping to change at page 6, line 26
So in the case of a domain name failing to successfully validate, So in the case of a domain name failing to successfully validate,
when this is due to a misconfiguration of the domain, that is the when this is due to a misconfiguration of the domain, that is the
sole responsibility of the domain administrator. sole responsibility of the domain administrator.
Any assistance or mitigation responses undertaken by other parties to Any assistance or mitigation responses undertaken by other parties to
mitigate the misconfiguration of a domain name by a domain mitigate the misconfiguration of a domain name by a domain
administrator, especially operators of DNS recursive resolvers, are administrator, especially operators of DNS recursive resolvers, are
optional and at the pleasure of those parties. optional and at the pleasure of those parties.
8. Use of a Negative Trust Anchor 7. Use of a Negative Trust Anchor
Technical personnel trained in the operation of DNS servers MUST Technical personnel trained in the operation of DNS servers MUST
confirm that a failure is due to misconfiguration, as a similar confirm that a failure is due to misconfiguration, as a similar
breakage could have occurred if an attacker gained access to a breakage could have occurred if an attacker gained access to a
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 12. Finally, they should make a testing purposes as noted in Section 11. 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.
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), this could make or popular domain name (such as a top 100 website), this could make
content or services in the affected TLD or domain inaccessible for a content or services in the affected TLD or domain 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.
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
skipping to change at page 6, line 30 skipping to change at page 7, line 4
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.
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.
A Negative Trust Anchor MUST only be used for a limited duration. A Negative Trust Anchor MUST only be used for a limited duration.
Implementors SHOULD allow the operator using the Negative Trust Implementors SHOULD allow the operator using the Negative Trust
Andhor to set an end time and date associated with any Negative Trust Anchor to set an end time and date associated with any Negative Trust
Anchor. Optimally this time and date is set in a DNS recursive Anchor. Optimally this time and date is set in a DNS recursive
resolver's configuration, though in the short-term this may also be resolver's configuration, though in the short-term this may also be
achieved via other systems or supporting processes. Use of a achieved via other systems or supporting processes. Use of a
Negative Trust Anchor MUST NOT be automatic. Negative Trust Anchor MUST NOT be automatic.
Finally, a Negative Trust Anchor SHOULD be used only in a specific Finally, a Negative Trust Anchor SHOULD be used only in a specific
domain or sub-domain and MUST NOT affect validation of other names up domain or sub-domain and MUST NOT affect validation of other names up
the authentication chain. For example, a Negative Trust Anchor for the authentication chain. For example, a Negative Trust Anchor for
zone1.example.com would affect only names at or below zone1.example.com would affect only names at or below
zone1.example.com, and validation would still be performed on zone1.example.com, and validation would still be performed on
skipping to change at page 7, line 4 skipping to change at page 7, line 25
Finally, a Negative Trust Anchor SHOULD be used only in a specific Finally, a Negative Trust Anchor SHOULD be used only in a specific
domain or sub-domain and MUST NOT affect validation of other names up domain or sub-domain and MUST NOT affect validation of other names up
the authentication chain. For example, a Negative Trust Anchor for the authentication chain. For example, a Negative Trust Anchor for
zone1.example.com would affect only names at or below zone1.example.com would affect only names at or below
zone1.example.com, and validation would still be performed on zone1.example.com, and validation would still be performed on
example.com, .com, and the root ("."). In another example, a example.com, .com, and the root ("."). In another example, a
Negative Trust Anchor for example.com would affect only names within Negative Trust Anchor for example.com would affect only names within
example.com, and validation would still be performed on .com, and the example.com, and validation would still be performed on .com, and the
root (".") root (".")
Root (.) <====== Root (.) <======
| || | ||
| ||<======>+----+----+ DNSSEC | ||<======>+----+----+ DNSSEC
| || |Recursive| Validation | || |Recursive| Validation
TLD (com) <=====|| |Resolver |<============> TLD (com) <=====|| |Resolver |<============>
| +<------>+---------+ | +<------>+---------+
| | DNS NTA | | DNS NTA
| | (example.com) | | (example.com)
SUB TLD (example.com) <------| <--------------> SUB TLD (example.com) <------| <-------------->
| | | |
| | | |
| | | |
(zone1.example.com <-----| (zone1.example.com <-----|
Figure 1: Negative Trust Anchor Diagram Figure 1: Negative Trust Anchor Diagram
9. Managing Negative Trust Anchors 8. Managing Negative Trust Anchors
While Negative Trust Anchors have proven useful during the early While Negative Trust Anchors have proven useful during the early
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
Section 7. Section 6.
Most current implementations of DNS validating resolvers currently Most current implementations of DNS validating resolvers currently
follow [RFC4033] on defining the implementation of Trust Anchor as follow [RFC4033] on defining the implementation of Trust Anchor as
either using Delegation Signer (DS), Key Signing Key (KSK), or Zone either using Delegation Signer (DS), Key Signing Key (KSK), or Zone
Signing Key (ZSK). A Negative Trust Anchor should use domain name Signing Key (ZSK). A Negative Trust Anchor should use domain name
formatting that signifies where in a delegation a validation process formatting that signifies where in a delegation a validation process
should be stopped. should be stopped.
Different DNS recursive resolvers may have different configuration Different DNS recursive resolvers may have different configuration
names for a Negative Trust Anchor. For example, Unbound calls their names for a Negative Trust Anchor. For example, Unbound calls their
configuration "domain-insecure." configuration "domain-insecure."
[need to update reference to full Appendix A, not just unbound]
[Unbound-Configuration] [Unbound-Configuration]
10. Removal of a Negative Trust Anchor 9. Removal of a Negative Trust Anchor
As explored in Section 13.1, using an NTA once the zone correctly As explored in Section 12.1, using an NTA once the zone correctly
validates can have security considerations. It is therefore validates can have security considerations. It is therefore
recommended that NTA implementors should periodically attempt to recommended that NTA implementors should periodically attempt to
validate the domain in question, for the period of time that the validate the domain in question, for the period of time that the
Negative Trust Anchor is in place, until such validation is again Negative Trust Anchor is in place, until such validation is again
successful. Before removing the Negative Trust Anchor, all successful. NTAs MUST expire automatically when their configured
authoritive resolvers listed in the zone should be checked. Due to lifetime ends. The lifetime MUST NOT exceed a week. Before removing
AnyCast or load balancers, this may not be possible. the Negative Trust Anchor, all authoritive resolvers listed in the
zone should be checked (due to anycast and load balancers it may not
be possible to check all instances).
Once all testing succeeds, a Negative Trust Anchor should be removed Once all testing succeeds, a Negative Trust Anchor should be removed
as soon as is reasonably possible. Optimally this is automatic, as soon as is reasonably possible. One possiable method to
though it may also be achieved via other systems or supporting automatically determine when the NTA can be removed is to send a
processes. periodic query for type SOA at the NTA node; if it gets a response
that it can validate (whether the response was an actual SOA answer
or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is
presumed no longer to be necessary and is removed. Implmentations
SHOULD, by default, perform this operation. Note that under some
circumstances this is undesirable behavior (for example, if
www.example.com has a bad signature, but example.com/SOA is fine) and
so implmentations may wish to allow the operator to override this
spot-check / behavior.
11. Comparison to Other DNS Misconfigurations When removing the NTA, the implmentation should remove all cached
entries below the NTA node.
As noted in Section 7 domain administrators are ultimately 10. Comparison to Other DNS Misconfigurations
As noted in Section 6, domain administrators are ultimately
responsible for managing and ensuring their DNS records are responsible for managing and ensuring their DNS records are
configured correctly. ISPs or other DNS recursive resolver operators configured correctly. ISPs or other DNS recursive resolver operators
cannot and should not correct misconfigured A, CNAME, MX, or other cannot and should not correct misconfigured A, CNAME, MX, or other
resource records of domains for which they are not authoritative. resource records of domains for which they are not authoritative.
Expecting non-authoritative entities to protect domain administrators Expecting non-authoritative entities to protect domain administrators
from any misconfiguration of resource records is therefore from any misconfiguration of resource records is therefore
unrealistic and unreasonable, and in the long-term is harmful to the unrealistic and unreasonable, and in the long-term is harmful to the
delegated design of the DNS and could lead to extensive operational delegated design of the DNS and could lead to extensive operational
instability and/or variation. instability and/or variation.
12. Intentionally Broken Domains 11. Intentionally Broken Domains
Some domains, such as dnssec-failed.org, have been intentionally Some domains, such as dnssec-failed.org, have been intentionally
broken for testing purposes broken for testing purposes
[Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For [Measuring-DNSSEC-Validation-of-Website-Visitors] [Netalyzr]. For
example, dnssec-failed.org is a DNSSEC-signed domain that is broken. example, dnssec-failed.org is a DNSSEC-signed domain that is broken.
If an end user is querying a validating DNS recursive resolver, then If an end user is querying a validating DNS recursive resolver, then
this or other similarly intentionally broken domains should fail to this or other similarly intentionally broken domains should fail to
resolve and should result in a SERVFAIL error. If such a domain resolve and should result in a SERVFAIL error. If such a domain
resolved successfully, then it is a sign that the DNS recursive resolved successfully, then it is a sign that the DNS recursive
resolver is not fully validating. resolver is not fully validating.
Organizations that utilize Negative Trust Anchors should not add a Organizations that utilize Negative Trust Anchors should not add a
Negative Trust Anchor for any intentionally broken domain. Negative Trust Anchor for any intentionally broken domain.
Organizations operating an intentionally broken domain may wish to Organizations operating an intentionally broken domain may wish to
consider adding a TXT record for the domain to the effect of "This consider adding a TXT record for the domain to the effect of "This
domain is purposely DNSSEC broken for testing purposes". domain is purposely DNSSEC broken for testing purposes".
13. Other Considerations 12. Other Considerations
13.1. Security Considerations 12.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 have been re- Thus, there may be a gap between when a domain has have been re-
secured and when a Negative Trust Anchor is removed. In addition, a secured and when a Negative Trust Anchor is removed. In addition, a
Negative Trust Anchor may be put in place by DNS recursive resolver Negative Trust Anchor may be put in place by DNS recursive resolver
operators without the knowledge of the authoritative domain operators without the knowledge of the authoritative domain
administrator for a given domain name. However, attempts SHOULD be administrator for a given domain name. However, attempts SHOULD be
skipping to change at page 9, line 20 skipping to change at page 10, line 5
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]. This is particularly important since there is [Disclosure-Example]. This is particularly important since there is
currently no special DNS query response code that could indicate to currently no special DNS query response code that could indicate to
end users or applications that a Negative Trust Anchor is in place. end users or applications that a Negative Trust Anchor is in place.
Such disclosures should optimally include both the data and time that Such disclosures should optimally include both the data and time that
the Negative Trust Anchor was put in place and when it was removed. the Negative Trust Anchor was put in place and when it was removed.
13.2. Privacy Considerations 12.2. Privacy Considerations
There are no privacy considerations in this document. There are no privacy considerations in this document.
13.3. IANA Considerations 12.3. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
14. Acknowledgements 13. Acknowledgements
Several people made contributions of text to this document and/or Several people made contributions of text to this document and/or
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: the following individuals merit acknowledgement:
- Joe Abley - Joe Abley
skipping to change at page 10, line 19 skipping to change at page 11, line 4
- Wes Hardaker - Wes Hardaker
- Paul Hoffman - Paul Hoffman
- Shane Kerr - Shane Kerr
- Murray Kucherawy - Murray Kucherawy
- Warren Kumari - Warren Kumari
- Rick Lamb - Rick Lamb
- Marc Lampo - Marc Lampo
- Ted Lemon - Ted Lemon
- Ed Lewis - Ed Lewis
- Antoin Verschuren - Antoin Verschuren
- Paul Vixie - Paul Vixie
- Patrik Wallstrom - Patrik Wallstrom
- Nick Weaver - Nick Weaver
- Ralf Weber - Ralf Weber
15. References Edward Lewis and Evan Hunt provided expecially large amounts of text.
15.1. Normative References 14. References
14.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. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[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 11, line 30 skipping to change at page 12, line 16
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, March 2008.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Format", RFC 5914, June 2010. Format", RFC 5914, June 2010.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, December Operational Practices, Version 2", RFC 6781, December
2012. 2012.
15.2. Informative References 14.2. Informative References
[DNSSEC-Validation-Failure-Analysis] [DNSSEC-Validation-Failure-Analysis]
Barnitz, J., Creighton, T., Ganster, C., Griffiths, C., Barnitz, J., Creighton, T., Ganster, C., Griffiths, C.,
and J. Livingood, "Analysis of DNSSEC Validation Failure - and J. Livingood, "Analysis of DNSSEC Validation Failure -
NASA.GOV", Comcast , January 2012, NASA.GOV", Comcast , January 2012,
<http://www.dnssec.comcast.net/ <http://www.dnssec.comcast.net/
DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf>. DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf>.
[Disclosure-Example] [Disclosure-Example]
Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", Comcast, "faa.gov Failing DNSSEC Validation (Fixed)",
skipping to change at page 12, line 38 skipping to change at page 13, line 21
See: <http://unbound.net/documentation/howto_turnoff_dnssec.html> [ See: <http://unbound.net/documentation/howto_turnoff_dnssec.html> [
TODO(WK): Make this a "real" reference ] TODO(WK): Make this a "real" reference ]
server: server:
domain-insecure: "foo.example.com" domain-insecure: "foo.example.com"
A.2. ISC BIND A.2. ISC BIND
Use the "rndc" command: Use the "rndc" command:
_rndc nta [-lifetime duration] [-force] foo.example.com [view]_ nta -dump
List all negative trust anchors.
Set a negative trust anchor, disabling DNSSEC validation for the nta [-lifetime duration] [-force] domain [view]
given domain. Using -lifetime specifies the duration of the NTA, up Set a negative trust anchor, disabling DNSSEC validation
to one day. Using -force prevents the NTA from expiring before its for the given domain.
full lifetime, even if the domain can validate sooner. Using -lifetime specifies the duration of the NTA, up
to one week. The default is one hour.
Using -force prevents the NTA from expiring before its
full lifetime, even if the domain can validate sooner.
nta -remove domain [view]
Remove a negative trust anchor, re-enabling validation
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]
Ind-07 - WG-00:
o Simply updated name to reflect WG doc.
WG-00 to WG-01:
o Stole chuncks of text from Ed Lewis' mailing list "tirade" :-)
o New rndc usage text from Evan.
o Deleted the (already resolved) open issues from Appendix C, moved
the unresolved issues into github, resolved them!
o Clarification that authmated removal is best removal method, and
how to implment (Evan Hunt)
o Clarifiy that an NTA is not a RR (Rick Lamb)
o Grammar fixes.
Individual-00: First version published as an individual draft. Individual-00: First version published as an individual draft.
Individual-01: Fixed minor typos and grammatical nits. Closed all Individual-01: Fixed minor typos and grammatical nits. Closed all
open editorial items. open editorial items.
Individual-02: Simple date change to keep doc from expiring. Individual-02: Simple date change to keep doc from expiring.
Substantive updates planned. Substantive updates planned.
Individual-03: Changes to address feedback from Paul Vixie, by adding Individual-03: Changes to address feedback from Paul Vixie, by adding
a new section "Limited Time and Scope of Use". Changes to address a new section "Limited Time and Scope of Use". Changes to address
skipping to change at page 14, line 6 skipping to change at page 15, line 15
per March Davids. per March Davids.
Individual-06: Added more OPEN issues to continue tracking WG Individual-06: Added more OPEN issues to continue tracking WG
discussion. No changes in the main document - just expanded issue discussion. No changes in the main document - just expanded issue
tracking. tracking.
Individual-07: Refresh document - needs revision and rework before Individual-07: Refresh document - needs revision and rework before
IETF-91. Planning to add more contributors. IETF-91. Planning to add more contributors.
o Using github issue tracker - go see https://github.com/wkumari/ o Using github issue tracker - go see https://github.com/wkumari/
draft-livingood-dnsop-negative-trust-anchors/issues for more draft-livingood-dnsop-negative-trust-anchors for more details.
details.
o A bunch of readability improvments. o A bunch of readability improvments.
o Issue: Notify the domain owner of the validation failure - o Issue: Notify the domain owner of the validation failure -
resolved. resolved.
o Issue: Make the NTA as specific as possible - resolved. o Issue: Make the NTA as specific as possible - resolved.
WG-00
o Renamed because adopted by WG.
Appendix C. Open Issues
[RFC Editor: This section is to be removed before publication]
Determine whether RFC 2119 language should be used or not when
describing things like the duration of a NTA.
The DNSOP WG should discuss whether a 1 day limit is reasonable,
whether a different time (more or less than 1 day, such as 1 hour or
1 week) should be specified, or whether no time should be specified
(just a recommendation that it SHOULD generally be limited to X).
Olafur Gudmundsson has suggested that we may want to consider whether
a non validatable RRSIG should be returned or not when a NTA is in
place. This was raised in the context of NLnet Labs' DNSSEC-Trigger,
which apparently acts like forwarding stub-validator. He said, "The
reason for this is if NTA strips signatures the stub-validator thinks
it is under attack and may a) go into recursive mode to try to
resolve the domain, getting to the right answer the long way. b) Give
the wrong error "Missing signatures" instead of the real error. If
all the validator does is not to set the AD bit for RRsets at and
below the NTA, stub-resolvers (and cascading resolvers) should be
happy."
Determine whether an informative reference to X.509 in the
Introduction is necessary.
Is it desirable to say that NTAs should not be distributed across
organizational boundaries?
Per Warren Kumari, add examples to appendix. "it would be very
helpful to actually show how this is used, with e.g and example in an
Appendix, for -insert favorite resolver here-. The document contains
a lot of really useful content about why you might use one, how to
minimize damage, etc but (IMO) does't do a great job of explaining
how to actually do so". Rick Lamb and Joe Abley also agreed on the
need for this.
Per Rick Lamb, "it might be useful to have section 2 "Definition .."
make that clear for slow people like me - that the NTA is not an RR
and is more of a configuration. Maybe simply replacing "placed" with
"implemented" in section 2? "This NTA can potentially be -placed/
implemented- at any level within the chain of trust"
Per Olafur Gudmundsson, address fact that ALL authoritative name
servers must be working. "section 10 you talk about possible early
removal the NTA when validation succeeds but there may be instances
where validation succeeds when using a sub-set of the authoritative
servers thus NTA should only be removed if all servers are providing
"good" signatures."
Per Olafur Gudmundsson, "Furthermore what to do if some names work
but others do not, for example I remember a case where the records at
the apex worked but all names below the apex were signed by a key not
in the DNSKEY RRset, thus it is possible that either human or
automated checks may assume there is no problem when there actually
is one. What this is bringing to my mind is maybe you want a new
section with guidelines on how to test for failures and in what cases
failure justifies NTA and what tests MUST pass before preemttive
removal of an NTA."
Per Olafur Gudmundsson, "Also should there be guidance that removal
of NTA should include cleaning the caches of all RRsets below the
name?"
Reference and text per Ed Lewis: One thing that seems to need
repeating from time to time is this passage in RFC 4033. ... In the
final analysis, however, authenticating both DNS keys and data is a
matter of local policy, which may extend or even override the
protocol extensions defined in this document set. See Section 5 for
further discussion. A responsibility (one of many) of a caching
server operator is to "protect the integrity of the cache." DNSSEC
is just a tool to help accomplish that. It carries ancillary data
that a local cache administrator may use to filter out undesired
responses. DNSSEC is not an enforcement mechanism, it's a resource.
When I see folks voice opinions that DNSSEC's recommended operation
has to strictly followed, my gut reaction is that these folks have
forgotten the purpose of all of our efforts. We don't secure
protocols to make things work better. We don't operate the DNS
because we like to run a well run machine. We don't run the Internet
for the fun of it. (Some might enjoy running it, that's job
satisfaction to some extent.) At the end of the day all that matters
is that what is being done benefits society. We run the Internet to
enrich society. We prefer a well run DNS because it saps less
resources than a poorly run DNS. We prefer secure protocols so that
people don't become victims (in some sense of the word). Make it
work. Do what it takes to make it work. "Local policy" rules.
Per David Conrad: I'd suggest that in the BCP/RFC/whatever, in
addition to recommending that NTAs be time capped and not written to
permanent storage, it should also recommend NTAs be written as
specifically as possible. (Should be obvious, but doesn't hurt to
reiterate I suppose).
Per Ralf Weber: Informing the domain owner on the validation failure.
There should be a section in the document that the operator deploying
an NTA has to inform the domain owner of the problem. (JL note:
would prefer to say operator SHOULD take reasonable steps to notify
the domain owner, etc.)
Authors' Addresses Authors' Addresses
Paul Ebersman Paul Ebersman
Comcast Comcast
One Comcast Center One Comcast Center
1701 John F. Kennedy Boulevard 1701 John F. Kennedy Boulevard
Philadelphia, PA 19103 Philadelphia, PA 19103
US US
Email: ebersman-ietf@dragon.net Email: ebersman-ietf@dragon.net
 End of changes. 46 change blocks. 
178 lines changed or deleted 141 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/