Internet DRAFT - draft-livingood-dont-switch-resolvers
draft-livingood-dont-switch-resolvers
Domain Name System Operations J. Livingood
Internet-Draft Comcast
Intended status: Best Current Practice September 24, 2014
Expires: March 28, 2015
In Case of DNSSEC Validation Failures, Do Not Change Resolvers
draft-livingood-dont-switch-resolvers-02
Abstract
DNS Security Extensions (DNSSEC) is beginning widespread deployment.
However, domain signing tools and processes are not yet as mature and
reliable as is the case for non-DNSSEC-related domain administration
tools and processes. As a result, some DNSSEC validation failures
may occur. When these failures do occur, end users SHOULD NOT change
to a non-validating DNS resolver.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 28, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Livingood Expires March 28, 2015 [Page 1]
Internet-Draft Do Not Change Resolvers September 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Domain Validation Failures . . . . . . . . . . . . . . . . . 2
4. Misunderstanding DNSSEC Validation Failures . . . . . . . . . 3
5. Comparison to Other DNS Misconfigurations . . . . . . . . . . 3
6. Switching to a Non-Validating Resolver is NOT Recommended . . 3
7. Other Considerations . . . . . . . . . . . . . . . . . . . . 4
7.1. Security Considerations . . . . . . . . . . . . . . . . . 4
7.2. Privacy Considerations . . . . . . . . . . . . . . . . . 4
7.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 4
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
9. Normative References . . . . . . . . . . . . . . . . . . . . 4
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 5
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
The Domain Name System (DNS), DNS Security Extensions (DNSSEC), and
related operational practices are defined extensively [RFC1034]
[RFC1035] [RFC4033] [RFC4034] [RFC4035] [RFC4398] [RFC4509] [RFC6781]
[RFC5155].
DNSSEC has now entered widespread deployment. However, domain
signing tools and processes are not yet as mature and reliable as is
the case for non-DNSSEC-related domain administration tools and
processes. As a result, some DNSSEC validation failures may occur.
When these failures do occur, end users SHOULD NOT change to a non-
validating DNS resolver.
3. Domain Validation Failures
A domain name can fail validation for two general reasons, a
legitimate security failure such as due to an attack or compromise of
some sort, or as a result of misconfiguration (mistake) on the part
of an domain administrator. There is no way for end users to discern
which of these issues has caused a DNSSEC-signed domain to fail
Livingood Expires March 28, 2015 [Page 2]
Internet-Draft Do Not Change Resolvers September 2014
validation, and end users should therefore assume that it may be due
to a legitimate security problem.
4. Misunderstanding DNSSEC Validation Failures
End users may incorrectly interpret the failure to reach a domain due
to DNSSEC-related misconfiguration as their ISP or DNS resolver
operator purposely blocking access to the domain, or as a
performance-related failure on the part of their ISP. In reality,
these failures may be due to a security issue of which the end user
is not aware.
5. Comparison to Other DNS Misconfigurations
Authoritative DNS-related mistakes and errors typically affect the
entire Internet, and all DNS recursive resolver operators equally.
So for example, in an A record is incorrect, an end user would get
the incorrect record in a DNS response no matter what resolver they
used.
In contrast to this, DNSSEC-related mistakes, errors, or validation
security failures would only affect end users of validating
resolvers.
6. Switching to a Non-Validating Resolver is NOT Recommended
As noted in Section 4 some end users may not understand why a domain
fails to validate on one network but not another (or with one DNS
resolver but not another) Section 5. As a result, they may consider
switching to an alternative, non-validating resolver themselves. But
if a domain fails DNSSEC validation and is inaccessible, this could
very well be due to a security-related issue.
As a best practice: In order to be as safe and secure as possible,
end users SHOULD NOT change to DNS servers that do not perform DNSSEC
validation as a workaround.
Even if a website in a domain seems to look "normal" and valid,
according to the DNSSEC protocol, that domain is not secure. Domains
that fail DNSSEC for legitimate reasons may be in control of hackers
or there could be other significant security issues with the domain.
Thus, switching to a non-validating resolver to restore access to a
domain that fails DNSSEC validation is NOT recommended and is
potentially harmful to end user security.
Livingood Expires March 28, 2015 [Page 3]
Internet-Draft Do Not Change Resolvers September 2014
7. Other Considerations
7.1. Security Considerations
The use of a non-validating DNS recursive resolver has comparatively
less security capabilities than a validating resolver, since one
implements DNS Security Extensions and one does not.
In the case of a DNSSEC validation failure, if an end user changes to
a non-validating resolver they may subject themselves to increased
security risks and threats against which DNS Security Extensions may
have provided protection.
7.2. Privacy Considerations
There are no privacy considerations in this document.
7.3. IANA Considerations
There are no IANA considerations in this document.
8. Acknowledgements
- William Brown
9. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Livingood Expires March 28, 2015 [Page 4]
Internet-Draft Do Not Change Resolvers September 2014
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", RFC 4398, March 2006.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Format", RFC 5914, June 2010.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, December
2012.
Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication]
-00: First version published as an individual draft.
-01: Fixed nits identified by William Brown
-02: Updated prior to IETF-91
Appendix B. Open Issues
[RFC Editor: This section is to be removed before publication]
Author's Address
Jason Livingood
Comcast Cable Communications
One Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
US
Email: jason_livingood@cable.comcast.com
URI: http://www.comcast.com
Livingood Expires March 28, 2015 [Page 5]
