< draft-ietf-dnsop-negative-trust-anchors-04.txt   draft-ietf-dnsop-negative-trust-anchors-05.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: October 24, 2015 Dyn Expires: November 6, 2015
W. Kumari W. Kumari
Google Google
J. Livingood J. Livingood
Comcast Comcast
R. Weber R. Weber
Nominum Nominum
April 22, 2015 May 5, 2015
Definition and Use of DNSSEC Negative Trust Anchors Definition and Use of DNSSEC Negative Trust Anchors
draft-ietf-dnsop-negative-trust-anchors-04 draft-ietf-dnsop-negative-trust-anchors-05
Abstract Abstract
DNS Security Extensions (DNSSEC) is now entering widespread DNS Security Extensions (DNSSEC) is now entering widespread
deployment. However, domain signing tools and processes are not yet deployment. However, domain signing tools and processes are not yet
as mature and reliable as those for non-DNSSEC-related domain as mature and reliable as those for non-DNSSEC-related domain
administration tools and processes. Negative Trust Anchors administration tools and processes. Negative Trust Anchors
(described in this document) can be used to mitigate DNSSEC (described in this document) can be used to mitigate DNSSEC
validation failures. validation failures.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 24, 2015. This Internet-Draft will expire on November 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and motivation . . . . . . . . . . . . . . . . . 2 1. Introduction and motivation . . . . . . . . . . . . . . . . . 2
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. Domain Validation Failures . . . . . . . . . . . . . . . 4
1.3. End User Reaction . . . . . . . . . . . . . . . . . . . . 4 1.3. End User Reaction . . . . . . . . . . . . . . . . . . . . 4
1.4. Switching to a Non-Validating Resolver is Not Recommended 5 1.4. Switching to a Non-Validating Resolver is Not Recommended 5
2. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 5 2. Use of a Negative Trust Anchor . . . . . . . . . . . . . . . 5
3. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 6 3. Managing Negative Trust Anchors . . . . . . . . . . . . . . . 7
4. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7 4. Removal of a Negative Trust Anchor . . . . . . . . . . . . . 7
5. Comparison to Other DNS Misconfigurations . . . . . . . . . . 7 5. Comparison to Other DNS Misconfigurations . . . . . . . . . . 8
6. Intentionally Broken Domains . . . . . . . . . . . . . . . . 8 6. Intentionally Broken Domains . . . . . . . . . . . . . . . . 8
7. Other Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 8
7.1. Security Considerations . . . . . . . . . . . . . . . . . 8 7.1. Security Considerations . . . . . . . . . . . . . . . . . 8
7.2. Privacy Considerations . . . . . . . . . . . . . . . . . 9 7.2. Privacy Considerations . . . . . . . . . . . . . . . . . 9
7.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 9 7.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 11 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 10
A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 11 A.1. NLNet Labs Unbound . . . . . . . . . . . . . . . . . . . 10
A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 11 A.2. ISC BIND . . . . . . . . . . . . . . . . . . . . . . . . 11
A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 12 A.3. Nominum Vantio . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Discovering broken domains . . . . . . . . . . . . . 12 Appendix B. Discovering broken domains . . . . . . . . . . . . . 11
Appendix C. Document Change Log . . . . . . . . . . . . . . . . 14 Appendix C. Document Change Log . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction and motivation 1. Introduction and motivation
This document defines a Negative Trust Anchor, which can be used This document defines a Negative Trust Anchor, which can be used
during the transition to ubiquitous DNSSEC deployment. Negative during the transition to ubiquitous DNSSEC deployment. Negative
Trust Anchors (NTAs) are configured locally on a validating DNS Trust Anchors (NTAs) are configured locally on a validating DNS
recursive resolver to shield end users from DNSSEC-related recursive resolver to shield end users from DNSSEC-related
authoritative name server operational errors. Negative Trust Anchors authoritative name server operational errors. Negative Trust Anchors
are intended to be temporary, and should not be distributed by IANA are intended to be temporary, and should not be distributed by IANA
or any other organization outside of the administrative boundary of or any other organization outside of the administrative boundary of
skipping to change at page 4, line 4 skipping to change at page 3, line 50
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. By way building the authentication chain for a signed DNS response. By way
of analogy, negative trust anchors stop validation of the of analogy, negative trust anchors stop validation of the
authentication chain. Instead, the resolver sends the response as if authentication chain. Instead, the resolver sends the response as if
the zone is unsigned and does not set the AD bit. Note that this is the zone is unsigned and does not set the AD bit. Note that this is
a behavior, and not a separate resource record. This Negative Trust a behavior, and not a separate resource record. This Negative Trust
Anchor can potentially be implemented at any level within the chain Anchor can potentially be implemented at any level within the chain
of trust and would stop validation from that point in the chain down. of trust and would stop validation from that point in the chain down.
Validation starts again if there is a positive trust anchor further
down in the chain. For example, if there is a NTA at example.com,
and a positive trust anchor at foo.bar.example.com, then validation
resumes for foo.bar.example.com and anything below it.
1.2. Domain Validation Failures 1.2. 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
skipping to change at page 4, line 48 skipping to change at page 4, line 50
will incur cost for their ISP. In addition, they may use online will incur cost for their ISP. In addition, they may use online
tools and sites to complain of this problem, such as via a blog, web tools and sites to complain of this problem, such as via a blog, web
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, as 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, protecting expected result when a domain can no longer be validated and it
end users from a potential security threat. Use of a Negative Trust protects end users from a potential security threat. Use of a
Anchor would allow the ISP to specifically remedy the failure to Negative Trust Anchor would allow the ISP to specifically remedy the
reach that domain, without compromising security for other sites. failure to reach that domain, without compromising security for other
sites. This would result in a satisfied end user, with minimal
This would result in a satisfied end user, with minimal impact to the impact to the ISP, while maintaining the security of DNSSEC for
ISP, while maintaining the security of DNSSEC for correctly correctly maintained domains.
maintained domains.
1.4. Switching to a Non-Validating Resolver is Not Recommended 1.4. Switching to a Non-Validating Resolver is Not Recommended
As noted in Section 1.3, some people may consider switching to an As noted in Section 1.3, 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
skipping to change at page 5, line 37 skipping to change at page 5, line 39
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 6. Finally, they should make a testing purposes as noted in Section 6. Finally, they should make a
reasonable attempt to contact the domain owner of the misconfigured reasonable attempt to contact the domain owner of the misconfigured
zone, preferably prior to implementing the Negative Trust Anchor. zone, preferably prior to implementing the Negative Trust Anchor.
Involving trained technical personnel is costly, but operational
experience suggests that this is a very rare event such as around
once per quarter (or even less).
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), content or
content or services in the affected TLD or domain inaccessible for a services in the affected TLD or domain could be inaccessible for a
large number of users. In such cases, it may be appropriate to use a large number of users. In such cases, it may be appropriate to use a
Negative Trust Anchor as soon as the misconfiguration is confirmed. Negative Trust Anchor as soon as the misconfiguration is confirmed.
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
Anchor 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
example.com, .com, and the root ("."). This Negative Trust Anchor example.com, .com, and the root ("."). This Negative Trust Anchor
also SHOULD NOT affect names in another branch of the tree (such as also SHOULD NOT affect names in another branch of the tree (such as
example.net). In another example, a Negative Trust Anchor for example.net). In another example, a Negative Trust Anchor for
example.com would affect only names within example.com, and example.com would affect only names within example.com, and
validation would still be performed on .com, and the root ("."). 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.
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) <------| <-------------->
skipping to change at page 7, line 7 skipping to change at page 7, line 20
Most current implementations of DNS validating resolvers currently Most current implementations of DNS validating resolvers currently
follow [RFC4033] on 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."[Unbound-Configuration]
[Unbound-Configuration]
4. Removal of a Negative Trust Anchor 4. Removal of a Negative Trust Anchor
As explored in Section 7.1, using an NTA once the zone correctly As explored in Section 7.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. NTAs MUST expire automatically when their configured successful. NTAs MUST expire automatically when their configured
lifetime ends. The lifetime MUST NOT exceed a week. Before removing lifetime ends. The lifetime MUST NOT exceed a week. Before removing
the Negative Trust Anchor, all authoritative resolvers listed in the the Negative Trust Anchor, 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, a Negative Trust Anchor should be removed
as soon as is reasonably possible. One possible method to as soon as is reasonably possible. One possible method to
skipping to change at page 7, line 37 skipping to change at page 7, line 48
periodic query for type SOA at the NTA node; if it gets a response 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 that it can validate (whether the response was an actual SOA answer
or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is
presumed no longer to be necessary and is removed. Implementations presumed no longer to be necessary and is removed. Implementations
SHOULD, by default, perform this operation. Note that under some SHOULD, by default, perform this operation. Note that under some
circumstances this is undesirable behavior (for example, if circumstances this is undesirable behavior (for example, if
www.example.com has a bad signature, but example.com/SOA is fine) and www.example.com has a bad signature, but example.com/SOA is fine) and
so implementations may wish to allow the operator to override this so implementations may 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 below the NTA node. entries 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
which they are not authoritative. Expecting non-authoritative which they are not authoritative. Expecting non-authoritative
entities to protect domain administrators from any misconfiguration entities to protect domain administrators from any misconfiguration
skipping to change at page 8, line 32 skipping to change at page 8, line 44
domain is purposely DNSSEC broken for testing purposes". domain is purposely DNSSEC broken for testing purposes".
7. Other Considerations 7. Other Considerations
7.1. Security Considerations 7.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 been re-secured
secured and when a Negative Trust Anchor is removed. In addition, a and when a Negative Trust Anchor is removed. In addition, a Negative
Negative Trust Anchor may be put in place by DNS recursive resolver Trust Anchor may be put in place by DNS recursive resolver operators
operators without the knowledge of the authoritative domain without the knowledge of the authoritative domain administrator for a
administrator for a given domain name. However, attempts SHOULD be given domain name. However, attempts SHOULD be made to contact and
made to contact and inform the domain administrator prior to putting inform the domain administrator prior to putting the NTA in place.
the NTA in place.
End users of a DNS recursive resolver or other people may wonder why End users of a DNS recursive resolver or other people may wonder why
a domain that fails DNSSEC validation resolves with a supposedly a domain that fails DNSSEC validation resolves with a supposedly
validating resolver. As a result, implementors should consider validating resolver. As a result, implementors should consider
transparently disclosing those Negative Trust Anchors which are transparently disclosing those Negative Trust Anchors which are
currently in place or were in place in the past, such as on a website currently in place or were in place in the past, such as on a website
[Disclosure-Example]. 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
skipping to change at page 9, line 21 skipping to change at page 9, line 29
There are no IANA considerations in this document. There are no IANA considerations in this document.
8. Acknowledgements 8. 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,John
Barnitz, Tom Creighton, Marco Davids, Brian Dickson, Patrik Falstrom,
- Joe Abley Tony Finch, Chris Ganster, Olafur Gudmundsson, Peter Hagopian, Wes
Hardaker, Paul Hoffman, Shane Kerr, Murray Kucherawy, Rick Lamb, Marc
- John Barnitz Lampo, Ted Lemon, Antoin Verschuren, Paul Vixie, Patrik Wallstrom,
Nick Weaver
- Tom Creighton
- Marco Davids
- Brian Dickson
- Patrik Falstrom
- Tony Finch
- Chris Ganster
- Olafur Gudmundsson
- Peter Hagopian
- Wes Hardaker
- Paul Hoffman
- Shane Kerr
- Murray Kucherawy
- Warren Kumari
- Rick Lamb
- Marc Lampo
- Ted Lemon
- Ed Lewis
- Jinmei Tatuya
- Antoin Verschuren
- Paul Vixie
- Patrik Wallstrom
- Nick Weaver
Edward Lewis, Evan Hunt and Andew Sullivan provided especially large Edward Lewis, Evan Hunt, Andew Sullivan and Tatuya Jinmei provided
amounts of text and / or detailed review. especially large amounts of text and / or detailed review.
9. References 9. References
9.1. Normative References 9.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.
9.2. Informative References 9.2. Informative References
[Disclosure-Example] [Disclosure-Example]
Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", Comcast, "faa.gov Failing DNSSEC Validation (Fixed)",
Comcast , February 2013, <http://dns.comcast.net/index Comcast , February 2013,
.php/entry/faa-gov-failing-dnssec-validation-fixed>. <http://dns.comcast.net/index.php/entry/
faa-gov-failing-dnssec-validation-fixed>.
[Measuring-DNSSEC-Validation-of-Website-Visitors] [Measuring-DNSSEC-Validation-of-Website-Visitors]
Mens, J., "Is my Web site being used via a DNSSEC- Mens, J., "Is my Web site being used via a DNSSEC-
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
skipping to change at page 11, line 22 skipping to change at page 10, line 39
[Unbound-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.
Please note: These are simply examples - nameserver operators are Note: These are simply examples - nameserver operators are expected
expected to test and understand the implications of these operations. to test and understand the implications of these operations. Note
also that some of available implementations may not implement all
recommended functionality in this document. In that case it is
advisable to request the developer or vendor of the implementation to
support the missing feature, rather than start using the incomplete
implementation.
A.1. NLNet Labs Unbound A.1. NLNet Labs Unbound
Unbound lets us simply disable validation checking for a specific Unbound lets us simply disable validation checking for a specific
zone. See: <http://unbound.net/documentation/ zone. See: <http://unbound.net/documentation/
howto_turnoff_dnssec.html> howto_turnoff_dnssec.html>
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:
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]
skipping to change at page 12, line 25 skipping to change at page 11, line 44
_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. Discovering broken domains Appendix B. 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 negative trust anchor.
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 servers 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 which might not to have it test the domain before the incident occurs.
always be the case.
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 to look deeper in the issue. want to inform the vendor where it fails so that the vendor can look
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.
There are several tools do this, an incomplete list includes: There are several tools do this, an incomplete list includes:
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 iis.se DNS check (http://dnscheck.iis.se)
most of these tools are open source so you can them install locally
if you want.
Using the tools over the Internet has the advantage though that as most of these tools are open source and can be installed locally.
these are not located in the same part of the network you already However, using the tools over the Internet has the advantage of
will have more than local view by using different tools. providing visibility from a different point.
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 server.s Use consistently around the world and from all authoritative servers.
DNS Tools (dig) or DNS looking glasses to verify this. An error that Use DNS Tools (dig) or DNS looking glasses to verify this. An error
is consistently the same is more likely to be operator caused than an that is consistently the same is more likely to be operator caused
attack, although that is not an guarantee. Also if the output from than an attack. Also if the output from the authoritative server is
the authoritative server is consistently different from the resolvers consistently different from the resolvers output this hints to an
output this hints to an attack rather then an error, unless there is attack rather then an error, unless there is EDNS0 client subnet
EDNS0 client subnet (draft-vandergaast-edns-client-subnet) applied to (draft-ietf-dnsop-edns-client-subnet) applied to the domain.
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 changes DNSSEC data the actual record someone occur on events that change DNSSEC data, the actual record someone
wants to go often stays the same. Again if the data is the same this wants to go to often stays the same. If the data is the same, this
is an indication that the error is operator caused not an guarantee. is an indication (not a guarantee) that the error is operator caused.
Keep in mind that with DNS being used to globally balance traffic the Keep in mind that with DNS being used to globally balance traffic the
data associated to a name might be different in different parts of data associated to a name might be different in different parts of
the Internet. the Internet.
Here are some examples of common DNSSEC failures that have been seen Here are some examples of common DNSSEC failures that have been seen
as operator signing errors on the Internet: as operator signing errors on the Internet:
o RRSIG timing issue. Each signature has an inception and expiry o RRSIG timing issue. Each signature has an inception time and
time in which between it is valid. Letting this time expire expiry time, between which it is valid. Letting this time expire
without creating a new signature is one of the most common DNSSEC without creating a new signature is one of the most common DNSSEC
errors. To a lesser extent it also happened that signatures where errors. To a lesser extent, this also occurs if signatures were
made active before the inception time. For all of these errors made active before the inception time. For all of these errors
your primary check is to check on the data. Signature expiration your primary check is to check on the data. Signature expiration
is also about the only error we see on actual data (like is also about the only error we see on actual data (like
www.example.com). All other errors are more or less related to www.example.com). All other errors are more or less related to
dealing with the chain of trust established by DS records in the dealing with the chain of trust established by DS records in the
parent zone and DNSKEYs in the child zones. These mostly occur parent zone and DNSKEYs in the child zones. These mostly occur
during key rollovers, but are not limited to that. during key rollovers, but are not limited to that.
o DNSKEYs in child zone don't match parents zone DS record. There o DNSKEYs in child zone don't match the DS record in the parent
is a big variation of this that can happen at any point in the key zone. There is a big variation of this that can happen at any
lifecycle. DNSViz is the best tools to show problems in the point in the key lifecycle. DNSViz is the best tools to show
chain. If you debug yourself use dig +multiline so that you can problems in the chain. If you debug yourself use dig +multiline
see the key id of a DNSKEY. Common Variations of this can be: so that you can see the key id of a DNSKEY. Common Variations of
this can be:
o DS pointing to a non existent key in the child zone. Questions o DS pointing to a non existent key in the child zone. Questions
for considerations here are: Has the existed before and was used? for consideration here include: Has there ever been a key (and, if
Was there a change in the DNSKEY RRSet recently (indicating a key so, was it used)? Has there been a recent change in the DNSKEY
rollover) and of course has the actual data in the zone changes. RRSet (indicating a key rollover)? Has the actual data in the
Is the zone DNSSEC signed at all and has it been in the past? zone changed? Is the zone DNSSEC signed at all and has it been in
the past?
o DS pointing to an existent key, but no signatures are made with o DS pointing to an existent key, but no signatures are made with
the key. Again the checks above should be done with addition of the key. The checks above should be done, with the addition of
checking if another key in the DNSKEY RRSet is now used to sign checking if another key in the DNSKEY RRSet is now used to sign
the records. the records.
o Data in DS or DNSKEY doesn't match the other. This is more common o 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. Again in initial setup when there was a copy and paste error. Again
checking history on data is the best you can do there. It's not checking history on data is the best you can do there.
possible to give a checklist just to run through to decide if a
domain is broken because of an attack or an operator error.
All of the above is just a starting point for consideration when All of the above is just a starting point for consideration when
having to decide to deploy or not deploy a trust anchor. deciding whether or not to deploy a trust anchor. It is not possible
to provide a simple checklist to run through to determine if a domain
is broken because of an attack or an operator error.
Appendix C. Document Change Log Appendix C. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-04 to -05
o A large bunch of cleanups from Jinmei. Thanks!
o Also clarified that if there is an NTA at foo.bar.baz.example, and
a positive *trust anchor* at bar.baz.example, the most specific
wins. I'm not very happy with this text, any additional text
gratefully accepted...
-03 to -04: -03 to -04:
o Addressed some comment from an email from Jinmei that I had o Addressed some comment from an email from Jinmei that I had
missed. Turns out others had made many of the same comments, and missed. Turns out others had made many of the same comments, and
so most had already been addressed. so most had already been addressed.
-02 to -03: -02 to -03:
o Included text from Ralph into Appendix B o Included text from Ralph into Appendix B
skipping to change at page 16, line 28 skipping to change at page 16, line 4
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
Chris Griffiths Chris Griffiths
Dyn
150 Dow Street
Tower Two
Manchester, NH 03101
US
Email: cgriffiths@gmail.com Email: cgriffiths@gmail.com
URI: http://www.dyn.com
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: warren@kumari.net Email: warren@kumari.net
URI: http://www.google.com URI: http://www.google.com
Jason Livingood Jason Livingood
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: jason_livingood@cable.comcast.com Email: jason_livingood@cable.comcast.com
URI: http://www.comcast.com URI: http://www.comcast.com
 End of changes. 44 change blocks. 
141 lines changed or deleted 112 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/