< draft-ietf-dnsop-negative-trust-anchors-01.txt   draft-ietf-dnsop-negative-trust-anchors-02.txt >
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Expires: September 5, 2015 Dyn Expires: September 5, 2015 Dyn
W. Kumari W. Kumari
Google Google
J. Livingood J. Livingood
Comcast Comcast
R. Weber R. Weber
Nominum Nominum
March 04, 2015 March 04, 2015
Definition and Use of DNSSEC Negative Trust Anchors Definition and Use of DNSSEC Negative Trust Anchors
draft-ietf-dnsop-negative-trust-anchors-01 draft-ietf-dnsop-negative-trust-anchors-02
Abstract Abstract
DNS Security Extensions (DNSSEC) is now entering widespread DNS Security Extensions (DNSSEC) is now entering widespread
deployment. However, domain signing tools and processes are not yet deployment. However, domain signing tools and processes are not yet
as mature and reliable as those for non-DNSSEC-related domain as mature and reliable as those for non-DNSSEC-related domain
administration tools and processes. Negative Trust Anchors administration tools and processes. Negative Trust Anchors
(described in this document) can be used to mitigate DNSSEC (described in this document) can be used to mitigate DNSSEC
validation failures. validation failures.
[RFC Editor: Please remove this before puiblication. This document [RFC Editor: Please remove this before publication. This document is
is being stored in github at https://github.com/wkumari/draft- being stored in github at https://github.com/wkumari/draft-livingood-
livingood-dnsop-negative-trust-anchors . Authors accept pull dnsop-negative-trust-anchors . Authors accept pull requests, and keep
requests, and keep the latest (edit buffer) versions there, so the latest (edit buffer) versions there, so commenters can follow
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 3, line 39 skipping to change at page 3, line 39
a failure on the part of the domain they wanted to reach. Without a failure on the part of the domain they wanted to reach. Without
the techniques in this document, this pressure may cause the resolver the techniques in this document, this pressure may cause the resolver
operator to disable (or simply not deploy) DNSSEC validation. Use of operator to disable (or simply not deploy) DNSSEC validation. Use of
a Negative Trust Anchor to temporarily disable DNSSEC validation for a Negative Trust Anchor to temporarily disable DNSSEC validation for
a specific misconfigured domain name immediately restores access for a specific misconfigured domain name immediately restores access for
end users. This allows the domain's administrators to fix their end users. This allows the domain's administrators to fix their
misconfiguration, while also allowing the organization using the misconfiguration, while also allowing the organization using the
Negative Trust Anchor to keep DNSSEC validation enabled and still Negative Trust Anchor to keep DNSSEC validation enabled and still
reach the misconfigured domain. reach the misconfigured domain.
It is worth noting the folowing text from RFC4033 [RFC4033] - "In the It is worth noting the following text from RFC4033 [RFC4033] - "In
final analysis, however, authenticating both DNS keys and data is a the final analysis, however, authenticating both DNS keys and data is
matter of local policy, which may extend or even override the a matter of local policy, which may extend or even override the
protocol extensions defined in this document set." A responsibility protocol extensions defined in this document set." A responsibility
(one of many) of a caching server operator is to "protect the (one of many) of a caching server operator is to "protect the
integrity of the cache." DNSSEC is just a tool to help accomplish integrity of the cache." DNSSEC is just a tool to help accomplish
that. It carries ancillary data that a local cache administrator may that. It carries ancillary data that a local cache administrator may
use to filter out undesired responses. DNSSEC is not an enforcement use to filter out undesired responses. DNSSEC is not an enforcement
mechanism, it's a resource. When I see folks voice opinions that mechanism, it's a resource. When I see folks voice opinions that
DNSSEC's recommended operation has to strictly followed, my gut DNSSEC's recommended operation has to strictly followed, my gut
reaction is that these folks have forgotten the purpose of all of our reaction is that these folks have forgotten the purpose of all of our
efforts. We don't secure protocols to make things work better. We efforts. We don't secure protocols to make things work better. We
don't operate the DNS because we like to run a well run machine. We don't operate the DNS because we like to run a well run machine. We
skipping to change at page 4, line 21 skipping to change at page 4, line 21
2. Definition of a Negative Trust Anchor 2. Definition of a Negative Trust Anchor
Trust Anchors are defined in [RFC5914]. A trust anchor should be Trust Anchors are defined in [RFC5914]. A trust anchor should be
used by a validating caching resolver as a starting point for used by a validating caching resolver as a starting point for
building the authentication chain for a signed DNS response. The building the authentication chain for a signed DNS response. The
inverse of this is a Negative Trust Anchor, which creates a stopping inverse of this is a Negative Trust Anchor, which creates a stopping
point for a caching resolver to end validation of the authentication point for a caching resolver to end validation of the authentication
chain. Instead, the resolver sends the response as if the zone is chain. Instead, the resolver sends the response as if the zone is
unsigned and does not set the AD bit. Note that this is a behavior, unsigned and does not set the AD bit. Note that this is a behavior,
and not a seperate resource record. This Negative Trust Anchor can and not a separate resource record. This Negative Trust Anchor can
potentially be implemented at any level within the chain of trust and potentially be implemented at any level within the chain of trust and
would stop validation from that point in the chain down. would stop validation from that point in the chain down.
3. Domain Validation Failures 3. 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.
skipping to change at page 8, line 22 skipping to change at page 8, line 22
9. Removal of a Negative Trust Anchor 9. Removal of a Negative Trust Anchor
As explored in Section 12.1, using an NTA once the zone correctly As explored in Section 12.1, using an NTA once the zone correctly
validates can have security considerations. It is therefore validates can have security considerations. It is therefore
recommended that NTA implementors should periodically attempt to recommended that NTA implementors should periodically attempt to
validate the domain in question, for the period of time that the validate the domain in question, for the period of time that the
Negative Trust Anchor is in place, until such validation is again Negative Trust Anchor is in place, until such validation is again
successful. 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 authoritive 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 possiable method to as soon as is reasonably possible. One possible method to
automatically determine when the NTA can be removed is to send a automatically determine when the NTA can be removed is to send a
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. Implmentations 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 implmentations 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 implmentation should remove all cached When removing the NTA, the implementation should remove all cached
entries below the NTA node. entries below the NTA node.
10. Comparison to Other DNS Misconfigurations 10. Comparison to Other DNS Misconfigurations
As noted in Section 6, domain administrators are ultimately As noted in Section 6, domain administrators are ultimately
responsible for managing and ensuring their DNS records are responsible for managing and ensuring their DNS records are
configured correctly. ISPs or other DNS recursive resolver operators configured correctly. ISPs or other DNS recursive resolver operators
cannot and should not correct misconfigured A, CNAME, MX, or other cannot and should not correct misconfigured A, CNAME, MX, or other
resource records of domains for which they are not authoritative. resource records of domains for which they are not authoritative.
Expecting non-authoritative entities to protect domain administrators Expecting non-authoritative entities to protect domain administrators
skipping to change at page 11, line 22 skipping to change at page 11, line 22
- Antoin Verschuren - Antoin Verschuren
- Paul Vixie - Paul Vixie
- Patrik Wallstrom - Patrik Wallstrom
- Nick Weaver - Nick Weaver
- Ralf Weber - Ralf Weber
Edward Lewis and Evan Hunt provided expecially large amounts of text. Edward Lewis and Evan Hunt provided especially large amounts of text.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
skipping to change at page 12, line 49 skipping to change at page 12, line 49
2011, <http://conferences.npl.co.uk/satin/presentations/ 2011, <http://conferences.npl.co.uk/satin/presentations/
satin2011slides-Weaver.pdf>. satin2011slides-Weaver.pdf>.
[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 achive Negative Trust The section contains example configurations to achieve Negative Trust
Anchor funcationality for the zone foo.example.com. Anchor functionality for the zone foo.example.com.
Please note: These are simply examples - nameserver operators are Please note: These are simply examples - nameserver operators are
expected to test and understand the implications of these operations. expected to test and understand the implications of these operations.
A.1. NLNet Labs Unbound A.1. NLNet Labs Unbound
Unbound lets us simply disable validation eching for a specific zone. Unbound lets us simply disable validation checking for a specific
See: <http://unbound.net/documentation/howto_turnoff_dnssec.html> [ zone. See: <http://unbound.net/documentation/
TODO(WK): Make this a "real" reference ] howto_turnoff_dnssec.html> [ TODO(WK): Make this a "real" reference ]
server: server:
domain-insecure: "foo.example.com" domain-insecure: "foo.example.com"
A.2. ISC BIND A.2. ISC BIND
Use the "rndc" command: Use the "rndc" command:
nta -dump nta -dump
List all negative trust anchors. List all negative trust anchors.
skipping to change at page 14, line 15 skipping to change at page 14, line 15
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
Ind-07 - WG-00: Ind-07 - WG-00:
o Simply updated name to reflect WG doc. o Simply updated name to reflect WG doc.
WG-00 to WG-01: WG-00 to WG-01:
o Stole chuncks of text from Ed Lewis' mailing list "tirade" :-) o Stole chunks of text from Ed Lewis' mailing list "tirade" :-)
o New rndc usage text from Evan. o New rndc usage text from Evan.
o Deleted the (already resolved) open issues from Appendix C, moved o Deleted the (already resolved) open issues from Appendix C, moved
the unresolved issues into github, resolved them! the unresolved issues into github, resolved them!
o Clarification that authmated removal is best removal method, and o Clarification that automated removal is best removal method, and
how to implment (Evan Hunt) how to implement (Evan Hunt)
o Clarifiy that an NTA is not a RR (Rick Lamb) o Clarify that an NTA is not a RR (Rick Lamb)
o Grammar fixes. o Grammar fixes.
-01 to -02
o Gah! I forgot to run spell check. And I type like a chimpanzee
with bad hand-eye coordination...
Individual-00: First version published as an individual draft. Individual-00: First version published as an individual draft.
Individual-01: Fixed minor typos and grammatical nits. Closed all Individual-01: Fixed minor typos and grammatical nits. Closed all
open editorial items. open editorial items.
Individual-02: Simple date change to keep doc from expiring. Individual-02: Simple date change to keep doc from expiring.
Substantive updates planned. Substantive updates planned.
Individual-03: Changes to address feedback from Paul Vixie, by adding Individual-03: Changes to address feedback from Paul Vixie, by adding
a new section "Limited Time and Scope of Use". Changes to address a new section "Limited Time and Scope of Use". Changes to address
 End of changes. 16 change blocks. 
25 lines changed or deleted 30 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/