< draft-ietf-dnsop-negative-trust-anchors-05.txt   draft-ietf-dnsop-negative-trust-anchors-06.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 6, 2015 Expires: November 9, 2015
W. Kumari W. Kumari
Google Google
J. Livingood J. Livingood
Comcast Comcast
R. Weber R. Weber
Nominum Nominum
May 5, 2015 May 8, 2015
Definition and Use of DNSSEC Negative Trust Anchors Definition and Use of DNSSEC Negative Trust Anchors
draft-ietf-dnsop-negative-trust-anchors-05 draft-ietf-dnsop-negative-trust-anchors-06
Abstract Abstract
DNS Security Extensions (DNSSEC) is now entering widespread DNS Security Extensions (DNSSEC) is now entering widespread
deployment. However, domain signing tools and processes are not yet deployment. However, domain signing tools and processes are not yet
as mature and reliable as those for non-DNSSEC-related domain as mature and reliable as those for non-DNSSEC-related domain
administration tools and processes. Negative Trust Anchors administration tools and processes. Negative Trust Anchors
(described in this document) can be used to mitigate DNSSEC (described in this document) can be used to mitigate DNSSEC
validation failures. validation failures.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2015. This Internet-Draft will expire on November 9, 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 3, line 45 skipping to change at page 3, line 45
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." integrity of the cache."
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 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 validator treats any upstream
the zone is unsigned and does not set the AD bit. Note that this is responses as if the zone is unsigned and does not set the AD bit in
a behavior, and not a separate resource record. This Negative Trust responses it sends to clients. Note that this is a behavior, and not
Anchor can potentially be implemented at any level within the chain a separate resource record. This Negative Trust Anchor can
of trust and would stop validation from that point in the chain down. potentially be implemented at any level within the chain of trust and
Validation starts again if there is a positive trust anchor further would stop validation from that point in the chain down. Validation
down in the chain. For example, if there is a NTA at example.com, starts again if there is a positive trust anchor further down in the
and a positive trust anchor at foo.bar.example.com, then validation chain. For example, if there is a NTA at example.com, and a positive
resumes for foo.bar.example.com and anything below it. 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. common reason for a validation failure has been misconfiguration.
Thus, domain administrators should be sure to read [RFC6781] in full. Thus, domain administrators should be sure to read [RFC6781] in full.
They should also pay special attention to Section 4.2, pertaining to They should also pay special attention to Section 4.2, pertaining to
key rollovers, which appear to be the cause of many recent validation key rollovers, which appear to be the cause of many recent validation
failures. failures.
It is also possible that some DNSSEC validation failures could arise It is also possible that some DNSSEC validation failures could arise
due to differences in how different software developers interpret due to differences in how different software developers interpret
DNSSEC standards and/or how those developers choose to implement DNSSEC standards and/or how those developers choose to implement
support for DNSSEC. For example, it is conceivable that a domain may support for DNSSEC. For example, it is conceivable that a domain may
be DNSSEC signed properly, and one vendor's DNS recursive resolvers be DNSSEC signed properly, and one vendor's DNS recursive resolvers
skipping to change at page 7, line 12 skipping to change at page 7, line 12
Figure 1: Negative Trust Anchor Diagram Figure 1: Negative Trust Anchor Diagram
3. Managing Negative Trust Anchors 3. Managing Negative Trust Anchors
While Negative Trust Anchors have proven useful during the early While Negative Trust Anchors have proven useful during the early
stages of DNSSEC adoption, domain owners are ultimately responsible stages of DNSSEC adoption, domain owners are ultimately responsible
for managing and ensuring their DNS records are configured correctly. for managing and ensuring their DNS records are configured correctly.
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 configuring a Trust Anchor using either a public
either using Delegation Signer (DS), Key Signing Key (KSK), or Zone key as in a DNSKEY RR or a hash of a public key as in a DS RR. A
Signing Key (ZSK). A Negative Trust Anchor should use domain name Negative Trust Anchor should use domain name formatting that
formatting that signifies where in a delegation a validation process signifies where in a delegation a validation process should be
should be stopped. stopped.
Different DNS recursive resolvers may have different configuration Different DNS validators may have different configuration names for a
names for a Negative Trust Anchor. For example, Unbound calls their Negative Trust Anchor. For examples see Appendix A.
configuration "domain-insecure."[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
 End of changes. 8 change blocks. 
22 lines changed or deleted 22 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/