< draft-ietf-dnsop-negative-trust-anchors-10.txt   draft-ietf-dnsop-negative-trust-anchors-11.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 13, 2015 Expires: January 15, 2016
W. Kumari W. Kumari
Google Google
J. Livingood J. Livingood
Comcast Comcast
R. Weber R. Weber
Nominum Nominum
May 12, 2015 July 14, 2015
Definition and Use of DNSSEC Negative Trust Anchors Definition and Use of DNSSEC Negative Trust Anchors
draft-ietf-dnsop-negative-trust-anchors-10 draft-ietf-dnsop-negative-trust-anchors-11
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. This document defines Negative
(described in this document) can be used to mitigate DNSSEC Trust Anchors which can be used to mitigate DNSSEC validation
validation failures. failures by disabling DNSSEC validation at specified domains.
[RFC Editor: Please remove this before publication. This document is [RFC Editor: Please remove this before publication. This document is
being stored in github at https://github.com/wkumari/draft-livingood- being stored in github at https://github.com/wkumari/draft-livingood-
dnsop-negative-trust-anchors . Authors accept pull requests, and keep dnsop-negative-trust-anchors . Authors accept pull requests, and keep
the latest (edit buffer) versions there, so commenters can follow the latest (edit buffer) versions there, so commenters can follow
along at home.] 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
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 13, 2015. This Internet-Draft will expire on January 15, 2016.
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
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 and motivation . . . . . . . . . . . . . . . . . 3 1. Introduction and motivation . . . . . . . . . . . . . . . . . 3
1.1. Definition of a Negative Trust Anchor . . . . . . . . . . 3 1.1. Definition of a Negative Trust Anchor . . . . . . . . . . 3
1.2. Domain Validation Failures . . . . . . . . . . . . . . . 4 1.2. Motivations for Negative Trust Anchors . . . . . . . . . 4
1.3. End User Reaction . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Mitigating Domain Validation Failures . . . . . . . . 4
1.4. Switching to a Non-Validating Resolver is Not Recommended 5 1.2.2. Improving End User Experience . . . . . . . . . . . . 4
1.2.3. Avoiding Switching to a Non-Validating Resolver . . . 5
2. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 5 2. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 5
2.1. Applicability of Negative Trust Anchors . . . . . . . . . 6
3. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 7 3. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 7
3.1. Alerting Users to NTA Use . . . . . . . . . . . . . . . . 7 3.1. Alerting Users to Negative Trust Anchor Use . . . . . . . 7
4. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7 4. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7
5. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8 5. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8
6. Intentionally Broken Domains . . . . . . . . . . . . . . . . 8 6. Intentionally Broken Domains . . . . . . . . . . . . . . . . 8
7. Discovering broken domains . . . . . . . . . . . . . . . . . 9 7. Discovering broken domains . . . . . . . . . . . . . . . . . 9
8. Other Considerations . . . . . . . . . . . . . . . . . . . . 11 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Security Considerations . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.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 . . . . . . . . . . . . . . . . . . . . . 14 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction and motivation 1. Introduction and motivation
This document defines a Negative Trust Anchor, which can be used
during the transition to ubiquitous DNSSEC deployment. Negative
Trust Anchors (NTAs) are configured locally on a validating DNS
recursive resolver to shield end users from DNSSEC-related
authoritative name server operational errors. Negative Trust Anchors
are intended to be temporary, and should not be distributed by IANA
or any other organization outside of the administrative boundary of
the organization locally implementing a Negative Trust Anchor.
Finally, Negative Trust Anchors pertain only to DNSSEC and not to
Public Key Infrastructures (PKI) such as X.509.
DNSSEC has now entered widespread deployment. However, the DNSSEC DNSSEC has now entered widespread deployment. However, the DNSSEC
signing tools and processes are less mature and reliable than those signing tools and processes are less mature and reliable than those
for non-DNSSEC-related administration. As a result, operators of DNS for non-DNSSEC-related administration. As a result, operators of DNS
recursive resolvers, such as Internet Service Providers (ISPs), recursive resolvers, such as Internet Service Providers (ISPs),
occasionally observe domains incorrectly managing DNSSEC-related occasionally observe domains incorrectly managing DNSSEC-related
resource records. This mismanagement triggers DNSSEC validation resource records. This mismanagement triggers DNSSEC validation
failures, and then causes large numbers of end users to be unable to failures, and then causes large numbers of end users to be unable to
reach a domain. Many end users tend to interpret this as a failure reach a domain. Many end users tend to interpret this as a failure
of their ISP or resolver operator, and may switch to a non-validating of their ISP or resolver operator, and may switch to a non-validating
resolver or contact their ISP to complain, rather than seeing this as resolver or contact their ISP to complain, rather than seeing this as
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.
a Negative Trust Anchor to temporarily disable DNSSEC validation for
a specific misconfigured domain name immediately restores access for
end users. This allows the domain's administrators to fix their
misconfiguration, while also allowing the organization using the
Negative Trust Anchor to keep DNSSEC validation enabled and still
reach the misconfigured domain.
It is worth noting the following text from [RFC4033] - "In the final This document defines the Negative Trust Anchor (NTA), which can be
analysis, however, authenticating both DNS keys and data is a matter used during the transition to ubiquitous DNSSEC deployment. NTAs are
of local policy, which may extend or even override the protocol configured locally on a validating DNS recursive resolver to shield
extensions defined in this document set." A responsibility (one of end users from DNSSEC-related authoritative name server operational
many) of a caching server operator is to "protect the integrity of errors. NTAs are intended to be temporary, and only implemented by
the cache." the organization requiring an NTA (and not distributed by any
organizations outside of the administrative boundary). Finally, NTAs
pertain only to DNSSEC and not to Public Key Infrastructures (PKI)
such as X.509.
Use of an NTA to temporarily disable DNSSEC validation for a specific
misconfigured domain name immediately restores access for end users.
This allows the domain's administrators to fix their
misconfiguration, while also allowing the organization using the NTA
to keep DNSSEC validation enabled and still reach the misconfigured
domain.
[ ED NOTE: Don't forget to insert 2119 boilerplate - not doing now,
to avoid messing up section numbers... ]
1.1. Definition of a Negative Trust Anchor 1.1. 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 is used by a
used by a validating caching resolver as a starting point for validating caching resolver as a starting point for building the
building the authentication chain for a signed DNS response. By way authentication chain for a signed DNS response. By way of analogy,
of analogy, negative trust anchors stop validation of the NTAs stop validation of the authentication chain. Instead, the
authentication chain. Instead, the validator treats any upstream validator treats any upstream responses as if the zone is unsigned
responses as if the zone is unsigned and does not set the AD bit in and does not set the AD bit in responses it sends to clients. Note
responses it sends to clients. Note that this is a behavior, and not that this is a behavior, and not a separate resource record. This
a separate resource record. This Negative Trust Anchor can NTA can potentially be implemented at any level within the chain of
potentially be implemented at any level within the chain of trust and trust and would stop validation from that point in the chain down.
would stop validation from that point in the chain down. Validation Validation starts again if there is a positive trust anchor further
starts again if there is a positive trust anchor further down in the down in the chain. For example, if there is an NTA at example.com,
chain. For example, if there is a NTA at example.com, and a positive and a positive trust anchor at foo.bar.example.com, then validation
trust anchor at foo.bar.example.com, then validation resumes for resumes for foo.bar.example.com and anything below it.
foo.bar.example.com and anything below it.
1.2. Domain Validation Failures 1.2. Motivations for Negative Trust Anchors
1.2.1. Mitigating 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 a zone
domain administrator. As domains transition to DNSSEC, the most administrator. As domains transition to DNSSEC, the most common
common reason for a validation failure has been misconfiguration. reason for a validation failure has been misconfiguration. Thus,
Thus, domain administrators should be sure to read [RFC6781] in full. domain administrators should be sure to read [RFC6781] in full. They
They should also pay special attention to Section 4.2, pertaining to should also pay special attention to Section 4.2, pertaining to key
key rollovers, which appear to be the cause of many recent validation 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.
1.3. End User Reaction 1.2.2. Improving End User Experience
End users generally do not know of, understand, or care about the End users generally do not know of, understand, or care about the
resolution process that causes connections to happen. This is by resolution process that causes connections to happen. This is by
design: the point of the DNS is to insulate users from having to design: the point of the DNS is to insulate users from having to
remember IP addresses through a friendlier way of naming systems. It remember IP addresses through a friendlier way of naming systems. It
follows from this that end users do not, and should not, be expected follows from this that end users do not, and should not, be expected
to know about DNSSEC, validation, or anything of the sort. As a to know about DNSSEC, validation, or anything of the sort. As a
result, end users may misinterpret the failure to reach a domain due result, end users may misinterpret the failure to reach a domain due
to DNSSEC-related misconfiguration . They may (incorrectly) assume to DNSSEC-related misconfiguration . They may (incorrectly) assume
that their ISP is purposely blocking access to the domain or that it that their ISP is purposely blocking access to the domain or that it
skipping to change at page 5, line 11 skipping to change at page 5, line 7
forum, or social media site, which may lead to dissatisfaction on the forum, or social media site, which may lead to dissatisfaction on the
part of other end users or general criticism of an ISP or operator of part of other end users or general criticism of an ISP or operator of
a DNS recursive resolver. a DNS recursive resolver.
As end users publicize these failures, others may recommend they As end users publicize these failures, others may recommend they
switch from security-aware DNS resolvers to resolvers not performing switch from security-aware DNS resolvers to resolvers not performing
DNSSEC validation. This is a shame since the ISP or other DNS DNSSEC validation. This is a shame since the ISP or other DNS
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; this is the supposed to do in failing to resolve a domain name; this is the
expected result when a domain can no longer be validated and it expected result when a domain can no longer be validated and it
protects end users from a potential security threat. Use of a protects end users from a potential security threat. Use of an NTA
Negative Trust Anchor would allow the ISP to specifically remedy the would allow the ISP to specifically remedy the failure to reach that
failure to reach that domain, without compromising security for other domain, without compromising security for other sites. This would
sites. This would result in a satisfied end user, with minimal result in a satisfied end user, with minimal impact to the ISP, while
impact to the ISP, while maintaining the security of DNSSEC for maintaining the security of DNSSEC for correctly maintained domains.
correctly maintained domains.
1.4. Switching to a Non-Validating Resolver is Not Recommended It is worth noting the following text from [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."
As noted in Section 1.3, some people may consider switching to an 1.2.3. Avoiding Switching to a Non-Validating Resolver
As noted in Section 1.2.2, 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.
2. Use of a Negative Trust Anchor 2. 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 DNSSEC validation failure is due to misconfiguration,
breakage could have occurred if an attacker gained access to a as a similar breakage could have occurred if an attacker gained
domain's authoritative servers and modified those records or had the access to a domain's authoritative servers and modified those records
domain pointed to their own rogue authoritative servers. They should or had the domain pointed to their own rogue authoritative servers.
also confirm that the domain is not intentionally broken, such as for They should also confirm that the domain is not intentionally broken,
testing purposes as noted in Section 6. Finally, they should make a such as for testing purposes as noted in Section 6. Finally, they
reasonable attempt to contact the domain owner of the misconfigured should make a reasonable attempt to contact the domain owner of the
zone, preferably prior to implementing the Negative Trust Anchor. misconfigured zone, preferably prior to implementing the NTA.
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 for the resolver operator to confirm that the domain It is important for the resolver operator to confirm that the domain
is still under the ownership / control of the legitimate owner of the is still under the ownership / control of the legitimate owner of the
domain in order to ensure that disabling validation for a specific domain in order to ensure that disabling validation for a specific
domain does not direct users to an address under an attacker's domain does not direct users to an address under an attacker's
control. Contacting the domain owner and telling them the DNSSEC control. Contacting the domain owner and telling them the DNSSEC
records that the resolver operator is seeing allows the resolver records that the resolver operator is seeing allows the resolver
operator to determine if the issue is a DNSSEC misconfiguration or an operator to determine if the issue is a DNSSEC misconfiguration or an
attack. 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
Negative Trust Anchor as soon as the misconfiguration is confirmed. an NTA as soon as the misconfiguration is confirmed. An example of a
An example of a list of "top N" websites is the "Alexa Top 500 Sites list of "top N" websites is the "Alexa Top 500 Sites on the Web"
on the Web" [Alexa], , or a list of the of the most-accessed names in [Alexa], , or a list of the of the most-accessed names in the
the resolver's cache. 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 an NTA for that domain or sub-
domain or sub-domain. This instructs their DNS recursive resolver to domain. This instructs their DNS recursive resolver to temporarily
temporarily NOT perform DNSSEC validation at or in the misconfigured NOT perform DNSSEC validation at or in the misconfigured domain.
domain. This immediately restores access to the domain for end users This immediately restores access to the domain for end users while
while the domain's administrator corrects the misconfiguration(s). the domain's administrator corrects the misconfiguration(s). It does
It does not and should not involve turning off validation more not and should not involve turning off validation more broadly.
broadly.
A Negative Trust Anchor MUST only be used for a limited duration. 2.1. Applicability of Negative Trust Anchors
Implementors SHOULD allow the operator using the 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
resolver's configuration, though in the short-term this may also be
achieved via other systems or supporting processes. Use of a
Negative Trust Anchor MUST NOT be automatic.
Finally, a Negative Trust Anchor SHOULD be used only in a specific A NTA MUST only be used for a limited duration. Implementors SHOULD
domain or sub-domain and MUST NOT affect validation of other names up allow the operator using the NTA to set an end time and date
the authentication chain. For example, a Negative Trust Anchor for associated with any NTA. Optimally, this time and date is set in a
zone1.example.com would affect only names at or below DNS recursive resolver's configuration, though in the short-term this
zone1.example.com, and validation would still be performed on may also be achieved via other systems or supporting processes. Use
example.com, .com, and the root ("."). This Negative Trust Anchor of an NTA MUST NOT be automatic.
also SHOULD NOT affect names in another branch of the tree (such as
example.net). In another example, a Negative Trust Anchor for Finally, an NTA SHOULD be used only in a specific domain or sub-
example.com would affect only names within example.com, and domain and MUST NOT affect validation of other names up the
validation would still be performed on .com, and the root ("."). In authentication chain. For example, an NTA for zone1.example.com
this scenario, if there is a (probably manually configured) trust would affect only names at or below zone1.example.com, and validation
anchor for zone1.example.com, validation would be performed for would still be performed on example.com, .com, and the root (".").
This NTA also SHOULD NOT affect names in another branch of the tree
(such as example.net). In another example, an NTA for example.com
would affect only names within example.com, and validation would
still be performed on .com, and the root ("."). In this scenario, if
there is a (probably manually configured) trust anchor for
zone1.example.com, validation would be performed for
zone1.example.com and subdomains of zone1.example.com. zone1.example.com and subdomains of zone1.example.com.
3. Managing Negative Trust Anchors 3. Managing Negative Trust Anchors
While Negative Trust Anchors have proven useful during the early While NTAs have proven useful during the early stages of DNSSEC
stages of DNSSEC adoption, domain owners are ultimately responsible adoption, domain owners are ultimately responsible for managing and
for managing and ensuring their DNS records are configured correctly. 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
Negative Trust Anchor. For examples see Appendix A. an NTA. 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 precedence over that trust anchor, effectively
disabling it. Implementations MAY issue a warning or informational disabling it. Implementations MAY issue a warning or informational
message when this occurs, so that operators are not surprised when message when this occurs, so that operators are not surprised when
this happens. this happens.
3.1. Alerting Users to NTA Use 3.1. Alerting Users to Negative Trust Anchor 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 NTAs which are currently in place or
currently in place or were in place in the past, such as on a website were in place in the past, such as on a website [Disclosure-Example].
[Disclosure-Example].
This is particularly important since there is currently no special This is particularly important since there is currently no special
DNS query response code that could indicate to end users or DNS query response code that could indicate to end users or
applications that a Negative Trust Anchor is in place. Such applications that an NTA is in place. Such disclosures should
disclosures should optimally include both the data and time that the optimally include both the data and time that the NTA was put in
Negative Trust Anchor was put in place and when it was removed. place and when it was removed.
4. Removal of a Negative Trust Anchor 4. Removal of a Negative Trust Anchor
As explored in Section 8.1, using an NTA once the zone correctly As explored in Section 10, 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 NTA
Negative Trust Anchor is in place, until such validation is again is in place, until such validation is again successful. NTAs MUST
successful. NTAs MUST expire automatically when their configured expire automatically when their configured lifetime ends. The
lifetime ends. The lifetime MUST NOT exceed a week. Before removing lifetime SHOULD NOT exceed a week. There is limited experience with
the Negative Trust Anchor, all authoritative resolvers listed in the what this value should be, but at least one large vendor has
documented customer feedback suggesting that a week is reasonable
based on expectations of how long failures take to fix or to be
forgotten. Operational experience may further refine these
expectations.
Before removing the NTA, all authoritative resolvers listed in the
zone should be checked (due to anycast and load balancers it may not zone should be checked (due to anycast and load balancers it may not
be possible to check all instances). be possible to check all instances).
Once all testing succeeds, a Negative Trust Anchor should be removed Once all testing succeeds, an NTA should be removed as soon as is
as soon as is reasonably possible. One possible method to reasonably possible. One possible method to automatically determine
automatically determine when the NTA can be removed is to send a when the NTA can be removed is to send a periodic query for type SOA
periodic query for type SOA at the NTA node; if it gets a response at the NTA node; if it gets a response that it can validate (whether
that it can validate (whether the response was an actual SOA answer the response was an actual SOA answer or a NOERROR/NODATA with
or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is appropriate NSEC/NSEC3 records), the NTA is presumed no longer to be
presumed no longer to be necessary and is removed. Implementations necessary and is removed. Implementations SHOULD, by default,
SHOULD, by default, perform this operation. Note that under some perform this operation. Note that under some circumstances this is
circumstances this is undesirable behavior (for example, if undesirable behavior (for example, if www.example.com has a bad
www.example.com has a bad signature, but example.com/SOA is fine) and signature, but example.com/SOA is fine) and so implementations may
so implementations may wish to allow the operator to override this wish to allow the operator to override this spot-check / behavior.
spot-check / behavior.
When removing the NTA, the implementation SHOULD remove all cached When removing the NTA, the implementation SHOULD remove all cached
entries at and below the NTA node. entries at and below the NTA node.
5. Comparison to Other DNS Misconfigurations 5. Comparison to Other DNS Misconfigurations
Domain administrators are ultimately responsible for managing and Domain administrators are ultimately responsible for managing and
ensuring their DNS records are configured correctly. ISPs or other ensuring their DNS records are configured correctly. ISPs or other
DNS recursive resolver operators cannot and should not correct DNS recursive resolver operators cannot and should not correct
misconfigured A, CNAME, MX, or other resource records of domains for misconfigured A, CNAME, MX, or other resource records of domains for
skipping to change at page 8, line 49 skipping to change at page 9, line 5
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 "Server Failure" error (RCODE 2, also resolve and should result in a "Server Failure" error (RCODE 2, also
known as 'SERVFAIL'). If such a domain resolved successfully, then known as 'SERVFAIL'). If such a domain resolved successfully, then
it is a sign that the DNS recursive resolver is not fully validating. it is a sign that the DNS recursive resolver is not fully validating.
Organizations that utilize Negative Trust Anchors should not add a Organizations that utilize NTAs should not add an NTA for any
Negative Trust Anchor for any intentionally broken domain. Such intentionally broken domain. Such additions are prevented by the
additions are prevented by the requirement that the operator attempt requirement that the operator attempt to contact the administrators
to contact the administrators for the zone that has broken DNSSEC. for the zone that has broken DNSSEC.
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".
7. Discovering broken domains 7. Discovering broken domains
Discovering that a domain is DNSSEC broken as result of an operator Discovering that a domain is DNSSEC broken as result of an operator
error instead of an attack is not trivial, and the examples here error instead of an attack is not trivial, and the examples here
should be vetted by an experienced professional before taking the should be vetted by an experienced professional before taking the
decision on implementing an negative trust anchor. decision on implementing an NTA.
One of the key thing to look for when looking at a DNSSEC broken One of the key thing to look for when looking at a DNSSEC broken
domain is consistency and history. It therefore is good if you have domain is consistency and history. It therefore is good if you have
the ability to look at the server's DNS traffic over a long period of the ability to look at the server's DNS traffic over a long period of
time or have a database that stores DNS names associated answers time or have a database that stores DNS names associated answers
(this is often referred to as a "passive DNS database"). Another (this is often referred to as a "passive DNS database"). Another
invaluable tool is dnsviz (http://www.dnsivz.net) which also stores invaluable tool is dnsviz (http://www.dnsivz.net) which also stores
DNSSEC related data historically. The drawback here is that you need DNSSEC related data historically. The drawback here is that you need
to have it test the domain before the incident occurs. to have it test the domain before the incident occurs.
The first and easiest thing to check is if the failure of the domain The first and easiest thing to check is if the failure of the domain
is consistent across different software implementations. If not, you is consistent across different software implementations. If not, you
want to inform the vendor where it fails so that the vendor can look want to inform the vendor where it fails so that the vendor can look
more deeply into the issue. more deeply into the issue.
The next thing is to figure out what the actual failure mode is. The next thing is to figure out what the actual failure mode is. At
There are several tools to do this, an incomplete list includes: the time of this writing are several tools to do this, including:
o DNSViz (http://dnsviz.net) o DNSViz (http://dnsviz.net)
o Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com) o Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com)
o iis.se DNS check (http://dnscheck.iis.se) o zonemaster (http://www.zonemaster.fr, https://github.com/dotse/
zonemaster)
most of these tools are open source and can be installed locally. most of these tools are open source and can be installed locally.
However, using the tools over the Internet has the advantage of However, using the tools over the Internet has the advantage of
providing visibility from a different point. providing visibility from a different point. This is an incomplete
list, and it is expected that additional tools will be developed over
time to aid in troubleshooting DNSSEC issues.
Once you figure out what the error is, you need to check if it shows Once you figure out what the error is, you need to check if it shows
consistently around the world and from all authoritative servers. consistently around the world and from all authoritative servers.
Use DNS Tools (dig) or DNS looking glasses to verify this. An error Use DNS Tools (dig) or DNS looking glasses to verify this. An error
that is consistently the same is more likely to be operator caused that is consistently the same is more likely to be operator caused
than an attack. Also if the output from the authoritative server is than an attack. Also if the output from the authoritative server is
consistently different from the resolvers output this hints to an consistently different from the resolvers output this hints to an
attack rather then an error, unless there is EDNS0 client subnet attack rather then an error, unless there is EDNS0 client subnet
(draft-ietf-dnsop-edns-client-subnet) applied to the domain. (draft-ietf-dnsop-edns-client-subnet) applied to the domain.
A last check is to look at the actual DNS data. Is the result of the A last check is to look at the actual DNS data. Is the result of the
query still the same or has it changed? While a lot of DNSSEC errors query still the same or has it changed? While a lot of DNSSEC errors
occur on events that change DNSSEC data, the actual record someone occur on events that change DNSSEC data, the actual record someone
skipping to change at page 11, line 10 skipping to change at page 11, line 16
* 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 whether a to provide a simple checklist to run through to determine whether a
domain 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. Privacy Considerations
8.1. Security Considerations There are no privacy considerations in this document.
End to end DNSSEC validation will be disabled during the time that a 9. IANA Considerations
Negative Trust Anchor is used. In addition, the Negative Trust
Anchor may be in place after the point in time when the DNS There are no IANA considerations in this document.
misconfiguration that caused validation to break has been fixed.
Thus, there may be a gap between when a domain has been re-secured 10. Security Considerations
and when a Negative Trust Anchor is removed. In addition, a Negative
Trust Anchor may be put in place by DNS recursive resolver operators End to end DNSSEC validation will be disabled during the time that an
without the knowledge of the authoritative domain administrator for a NTA is used. In addition, the NTA may be in place after the point in
given domain name. However, attempts SHOULD be made to contact and time when the DNS misconfiguration that caused validation to break
inform the domain administrator prior to putting the NTA in place. has been fixed. Thus, there may be a gap between when a domain has
been re-secured and when an NTA is removed. In addition, an NTA may
be put in place by DNS recursive resolver operators without the
knowledge of the authoritative domain administrator for a given
domain name. However, attempts SHOULD be made to contact and inform
the domain administrator prior to putting the NTA in place.
One side effect of implementing an NTA is that it may break client One side effect of implementing an NTA is that it may break client
applications that assume that a domain is signed and expect an AD bit applications that assume that a domain is signed and expect an AD bit
in the response. It is expected that many application that require in the response. It is expected that many application that require
DNSSEC for a domain will perform their own validation, and so this DNSSEC for a domain will perform their own validation, and so this
should not be a major issue. should not be a major issue.
8.2. Privacy Considerations 11. Acknowledgements
There are no privacy considerations in this document.
8.3. IANA Considerations
There are no IANA considerations in this document.
9. 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: 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,
Hardaker, Paul Hoffman, Shane Kerr, Murray Kucherawy, Rick Lamb, Marc Christer Holmberg, Wes Hardaker, Paul Hoffman, Shane Kerr, Murray
Lampo, Scott Rose, Ted Lemon, Antoin Verschuren, Paul Vixie, Patrik Kucherawy, Rick Lamb, Marc Lampo, Scott Rose, Ted Lemon, A. Schulze,
Wallstrom, W.C.A. Wijngaards, Nick Weaver Antoin Verschuren, Paul Vixie, Patrik Wallstrom, Nick Weaver, W.C.A.
Edward Lewis, Evan Hunt, Andew Sullivan and Tatuya Jinmei provided Wijngaards, Suzanne Woolf.
Edward Lewis, Evan Hunt, Andrew 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 12. References
10.1. Normative References 12.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.
[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.
10.2. Informative References 12.2. Informative References
[Alexa] Alexa, an Amazon.com Company, "Alexa "The top 500 sites on [Alexa] Alexa, an Amazon.com Company, "Alexa "The top 500 sites on
the web. "", , May 2015, <http://www.alexa.com/topsites>. the web. "", , May 2015, <http://www.alexa.com/topsites>.
[Disclosure-Example] [Disclosure-Example]
Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", Comcast, "faa.gov Failing DNSSEC Validation (Fixed)",
Comcast , February 2013, Comcast , February 2013,
<http://dns.comcast.net/index.php/entry/ <http://dns.comcast.net/index.php/entry/
faa-gov-failing-dnssec-validation-fixed>. faa-gov-failing-dnssec-validation-fixed>.
skipping to change at page 12, line 45 skipping to change at page 13, line 5
validator?", July 2012, <http://jpmens.net/2012/07/30/ validator?", July 2012, <http://jpmens.net/2012/07/30/
is-my-web-site-being-used-via-dnssec-validator/>. is-my-web-site-being-used-via-dnssec-validator/>.
[Netalyzr] [Netalyzr]
Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson,
"Implications of Netalyzr's DNS Measurements", Securing "Implications of Netalyzr's DNS Measurements", Securing
and Trusting Internet Names, SATIN 2011 SATIN 2011, April and Trusting Internet Names, SATIN 2011 SATIN 2011, April
2011, <http://conferences.npl.co.uk/satin/presentations/ 2011, <http://conferences.npl.co.uk/satin/presentations/
satin2011slides-Weaver.pdf>. satin2011slides-Weaver.pdf>.
[Unound-Configuration] [Unbound-Configuration]
Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June
2010, <http://unbound.net/documentation/ 2010, <http://unbound.net/documentation/
howto_turnoff_dnssec.html>. howto_turnoff_dnssec.html>.
Appendix A. Configuration Examples Appendix A. Configuration Examples
The section contains example configurations to achieve Negative Trust The section contains example configurations to achieve Negative Trust
Anchor functionality for the zone foo.example.com. Anchor functionality for the zone foo.example.com.
Note: These are simply examples - nameserver operators are expected Note: These are simply examples - nameserver operators are expected
skipping to change at page 13, line 38 skipping to change at page 13, line 43
Using the "unbound-control" command: Using the "unbound-control" command:
list_insecure list domain-insecure zones list_insecure list domain-insecure zones
insecure_add zone add domain-insecure zone insecure_add zone add domain-insecure zone
insecure_remove zone remove domain-insecure zone insecure_remove zone remove domain-insecure zone
Items added with the "unbound-control" command are added to the Items added with the "unbound-control" command are added to the
running server and are lost when the server is restarted. Items from running server and are lost when the server is restarted. Items from
unbound.conf stay after restart. unbound.conf stay after restart.
For additional information see [Unound-Configuration] For additional information see [Unbound-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.
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]
-10.5 to 11
Integrated Alissa Cooper's No Objection comments. Text from Suz
and Evan.
-10.4 to 10.5
Integrated some comments from Ben Campbell's No Objection IESG
review.
-10.3 to 10.4
s/personnel trained in the operation of DNS servers MUST confirm/
personnel trained in the operation of DNS servers must confirm/ -
Alissa Cooper,
-10.2 to 10.3
o Integrated comments from Gen-ART review - Christer Holmberg.
o Offlist comment from Tony Finch. Made the "Negative Trust Anchors
are intended to be temporary," sentence much better.
-10.1 to 10.2
o Incoroprated comments from IETF LC, including:
o A. Schulze - s/Unound/Unbound/
o Joe Abley: Tone in into jarring. S1.2 s/domain administrator/zone
administrator/, dnscheck -> zonemaster
-10 to 10.1
o Fixed some typos (e.g Anrew -> Andrew)
-09 to -10 -09 to -10
o 'Implementations MAY issue a warning or informational message when o 'Implementations MAY issue a warning or informational message when
this occurs' - changed SHOULD to MAY, per Evan. 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 precedence 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
W.C.A. Wijngaards. W.C.A. Wijngaards.
-06 to -07 -06 to -07
skipping to change at page 16, line 37 skipping to change at page 17, line 25
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
issues raised by Antoin Verschuren and Patrik Wallstrom, by adding a issues raised by Antoin Verschuren and Patrik Wallstrom, by adding a
new section "Intentionally Broken Domains" and added two related new section "Intentionally Broken Domains" and added two related
references. Added text to address the need for manual investigation, references. Added text to address the need for manual investigation,
as suggested by Patrik Falstrom. Added a suggestion on notification as suggested by Patrik Falstrom. Added a suggestion on notification
as suggested by Marc Lampo. Made several additions and changes as suggested by Marc Lampo. Made several additions and changes
suggested by Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane suggested by Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane
Kerr, Joe Abley, Murray Kucherawy, Olafur Gudmundsson. Kerr, Joe Abley, Murray Kucherawy, Olafur Gudmundsson.
Individual-04: Moved the section defining a NTA forward, and added Individual-04: Moved the section defining an NTA forward, and added
new text to the Abstract and Introduction per feedback from Paul new text to the Abstract and Introduction per feedback from Paul
Hoffman. Hoffman.
Individual-05: Incorporated feedback from the DNSOP WG list received Individual-05: Incorporated feedback from the DNSOP WG list received
on 2/17/13 and 2/18/13. This is likely the final version before the on 2/17/13 and 2/18/13. This is likely the final version before the
IETF 86 draft cutoff date. Updated references to RFC6781 to RFC6781, IETF 86 draft cutoff date. Updated references to RFC6781 to RFC6781,
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
 End of changes. 54 change blocks. 
189 lines changed or deleted 234 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/