[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Domain Name System Operations                               J. Livingood
Internet-Draft                                                   Comcast
Intended status: Informational                           August 13, 2019
Expires: February 14, 2020


        Responsibility for Authoritative DNS and DNSSEC Mistakes
             draft-livingood-dnsop-auth-dnssec-mistakes-05

Abstract

   DNS Security Extensions (DNSSEC) validation by recursive DNS
   resolvers has been deployed at scale.  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.  This
   sometimes results in DNSSEC-validation failures, for which operators
   of validating resolvers are often blamed.  This is similar to other,
   non-DNSSEC-related authoritative DNS errors, for which individual
   recursive DNS operators are sometimes incorrectly blamed.  This
   document makes clear that responsibility for any and all
   authoritative DNS failures rests squarely with authoritative domain
   name operators, who are the only party that can properly maintain
   their domain names and rectify associated authoritative DNS errors.

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 https://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 February 14, 2020.

Copyright Notice

   Copyright (c) 2019 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



Livingood               Expires February 14, 2020               [Page 1]


Internet-Draft     Responsibility for DNSSEC Mistakes        August 2019


   (https://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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Domain Validation Failures  . . . . . . . . . . . . . . . . .   3
   3.  Responsibility for Failures . . . . . . . . . . . . . . . . .   4
   4.  Comparison to Other DNS Misconfigurations . . . . . . . . . .   5
   5.  Other Considerations  . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Security Considerations . . . . . . . . . . . . . . . . .   5
     5.2.  Privacy Considerations  . . . . . . . . . . . . . . . . .   5
     5.3.  IANA Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Document Change Log  . . . . . . . . . . . . . . . .   7
   Appendix B.  Open Issues  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  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].

   DNS Security Extensions (DNSSEC) validation by recursive DNS
   resolvers has been deployed at scale.  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.  This
   sometimes results in DNSSEC-validation failures, for which operators
   of validating resolvers are often blamed.  This is similar to other,
   non-DNSSEC-related authoritative DNS errors, for which individual
   recursive DNS operators are sometimes incorrectly blamed.  This
   documents makes clear that responsibility for any and all
   authoritative DNS failures rests squarely with authoritative domain
   name operators, who are the only party that can properly maintain
   their domain names and rectify associated authoritative DNS errors.

   Operators of DNS recursive resolvers, including Internet Service
   Providers (ISPs) and cloud-based DNS resolvers, occasionally observe



Livingood               Expires February 14, 2020               [Page 2]


Internet-Draft     Responsibility for DNSSEC Mistakes        August 2019


   domains incorrectly managing DNSSEC-related resource records.  This
   mismanagement triggers DNSSEC validation failures, and then causes
   large numbers of end users to be unable to reach a domain.
   Similarly, errors in non-DNSSEC-related authoritative DNS resource
   records result in failures, from NXDOMAIN responses to valid
   responses containing outdated or unreachable hosts.

   Many end users, as well as reporters, policymakers, regulators, and
   others often interpret this as a failure of particular recursive DNS
   resolvers.  Rather than seeing this as a failure on the part of the
   domain they wanted to reach, they may themselves and/or recommend to
   others that they switch to a non-validating resolver (which reduces
   their security), switch to a different DNS resolver (which can reduce
   non-DNS application layer performance), or contact their ISP or DNS
   resolver operator to complain.

   This document makes clear, however, that responsibility for these
   types of authoritative DNS failures rests squarely with authoritative
   domain name operators, as noted in Section 3.

2.  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 or other error or
   omission on the part of an domain administrator.  As domains
   transition to DNSSEC the most likely reason for a validation failure
   during and shortly after the transition is likely due to
   misconfiguration.  Thus, domain administrators should be sure to read
   [RFC6781] in full.  They should also pay special attention to
   Section 4.2, pertaining to key rollovers, which appears to be the
   cause of many validation failures.

   In one example [DNSSEC-Validation-Failure-Analysis], a specific
   domain name failed to validate.  An investigation revealed that the
   domain's administrators performed a Key Signing Key (KSK) rollover by
   (1) generating a new key and (2) signing the domain with the new key.
   However, they did not use a double-signing procedure for the KSK and
   a pre-publish procedure for the ZSK.  Double-signing refers to
   signing a zone with two KSKs and then updating the parent zone with
   the new DS record so that both keys are valid at the same time.  This
   meant that the domain name was signed with the new KSK, but it was
   not double-signed with the old KSK.  So, the new key was used for
   signing the zone but the old key was not.  As a result, the domain
   could not be trusted and returned an error when trying to reach the
   domain.  Thus, the domain was in a situation where the DNSSEC chain
   of trust was broken because the Delegation Signer (DS) record pointed
   to the old KSK, which was no longer used for signing the zone.  (A DS



Livingood               Expires February 14, 2020               [Page 3]


Internet-Draft     Responsibility for DNSSEC Mistakes        August 2019


   record provides a link in the chain of trust for DNSSEC from the
   parent zone to the child zone - in this case between TLD and domain
   name.)

   In a non-DNSSEC-related example, a domain administrator may add a new
   host with an A and AAAA resource record pointing the name to the IP
   addresses of new servers with a Time To Live (TTL) of two days.  But
   they may turn down the old servers with a similar two day TTL before
   that TTL has expired.  As a result, some number of users are likely
   to continue to attempt to connect to the old IP addresses that are no
   longer reachable.  While a best practice is to reduce the TTL to a
   matter of seconds or minutes before such a shift, many domains
   continue to forget the impact that the TTL can have, or make
   countless other errors in their domain name, server, and network
   administration that negatively impacts domain name-based
   reachability.

3.  Responsibility for Failures

   An authoritative domain owner is solely and completely responsible
   for managing their domain name(s) and associated DNS resource
   records.  This includes complete responsibility for the correctness
   of those resource records, the proper functioning and reachability of
   their authoritative DNS servers, and the correctness of DNS records
   linking their domain to a top-level domain (TLD) or other higher
   level domain.  The domain owner is also responsible for selection of
   the authoritative domain administrator, operator, or service
   provider.  Thus, even in cases where some error may be introduced by
   a third party, whether that is due to an authoritative server
   software vendor, software tools vendor, domain name registrar,
   Content Delivery Network (CDN), or other organization, these are all
   parties that the domain owner has selected and is responsible for
   managing successfully.

   There are some cases where the domain administrator is different than
   the domain owner.  In those cases, a domain owner has delegated
   operational responsibility to the domain administrator (and that
   domain administrator may further delegate some sub-domains and/or
   records to another party, such as a CDN).  So no matter whether a
   domain owner is also the domain administrator or not, the domain
   owner and domain administrator are nevertheless operationally
   responsible for the proper configuration and operation of the domain
   name .

   In the case of a domain name failing DNSSEC validation, even when
   this is due to a misconfiguration of the domain, that is the sole
   responsibility of the domain owner.




Livingood               Expires February 14, 2020               [Page 4]


Internet-Draft     Responsibility for DNSSEC Mistakes        August 2019


   Any assistance or mitigation responses undertaken by other parties to
   mitigate the misconfiguration of a domain name by a domain owner and/
   or administrator, especially operators of DNS recursive resolvers,
   are optional and at the pleasure of those parties.  This can the use
   of a Negative Trust Anchor [RFC7646] and/or clearing the cache in
   particular DNS resolvers.

4.  Comparison to Other DNS Misconfigurations

   As noted in Section 3 domain administrators are ultimately
   responsible for managing and ensuring their DNS records are
   configured correctly.  ISPs or other DNS recursive resolver operators
   cannot and should not correct misconfigured A, CNAME, MX, or other
   resource records of domains for which they are not authoritative.
   Expecting non-authoritative entities to protect domain owners and
   administrators from any misconfiguration of resource records is
   therefore unrealistic and unreasonable, does not scale well, and is
   strongly contrary to the delegated design of the DNS and could lead
   to extensive operational instability and/or variation.

5.  Other Considerations

5.1.  Security Considerations

   Authoritative domain name owners and/or administrators, in the case
   of DNSSEC-related mistakes that cause validation failures to occur,
   should focus on correcting the immediate authoritative DNS issue and
   then improving their processes and tools in the future.

   During the period of time that their domain cannot be resolved due to
   a DNSSEC-related mistake, they SHOULD NOT encourage end users to
   switch to non-validating resolvers [I-D.draft-livingood-dnsop-dont-
   switch-resolvers] .

5.2.  Privacy Considerations

   In the case of a DNSSEC validation failure, if an end user changes to
   a non-validating resolver they can subject themselves to increased
   security risks and threats against which DNSSEC may have provided
   protection.  This can include threats to their privacy, such as by
   unwittingly visiting a phishing site and sharing sensitive data or
   other private information with a malicious party or some party other
   than that which was originally intended.

   As a result, in order to protect their privacy, users SHOULD NOT
   switch to a non-validating resolver when a DNSSEC validation failure
   occurs [I-D.draft-livingood-dnsop-dont-switch-resolvers].




Livingood               Expires February 14, 2020               [Page 5]


Internet-Draft     Responsibility for DNSSEC Mistakes        August 2019


5.3.  IANA Considerations

   There are no IANA considerations in this document.

6.  Acknowledgements

   - William Brown

7.  References

7.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.

   [RFC4398]  Josefsson, S., "Storing Certificates in the Domain Name
              System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006,
              <https://www.rfc-editor.org/info/rfc4398>.

   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
              (DS) Resource Records (RRs)", RFC 4509,
              DOI 10.17487/RFC4509, May 2006,
              <https://www.rfc-editor.org/info/rfc4509>.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
              <https://www.rfc-editor.org/info/rfc5155>.



Livingood               Expires February 14, 2020               [Page 6]


Internet-Draft     Responsibility for DNSSEC Mistakes        August 2019


   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,
              <https://www.rfc-editor.org/info/rfc6781>.

   [RFC7646]  Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
              and R. Weber, "Definition and Use of DNSSEC Negative Trust
              Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
              <https://www.rfc-editor.org/info/rfc7646>.

7.2.  Informative References

   [DNSSEC-Validation-Failure-Analysis]
              Barnitz, J., Creighton, T., Ganster, C., Griffiths, C.,
              and J. Livingood, "Analysis of DNSSEC Validation Failure -
              NASA.GOV", Comcast , January 2012,
              <http://www.dnssec.comcast.net/
              DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf>.

   [I-D.livingood-dnsop-dont-switch-resolvers]
              Livingood, J., "In Case of DNSSEC Validation Failures, Do
              Not Change Resolvers", draft-livingood-dnsop-dont-switch-
              resolvers-03 (work in progress), November 2015.

Appendix A.  Document Change Log

   [RFC Editor: This section is to be removed before publication]

   Individual-00: First version published as an individual draft.

   Individual-01: Fixed nits identified by William Brown

   Individual-02: Updated prior to IETF-91

   WG-00: Renamed at request of DNSOP co-chairs

   WG-01: Updated doc to keep it from expiring

   WG-02: Removed RFC 2119 reference in XML

   WG-03 to 04: Refreshed draft and broadened to all auth issues, not
   just DNSSEC.

   WG-05: Refreshed to buy time for me to write a combined document







Livingood               Expires February 14, 2020               [Page 7]


Internet-Draft     Responsibility for DNSSEC Mistakes        August 2019


Appendix B.  Open Issues

   [RFC Editor: This section is to be removed before publication]

   Fix I-D xref

Author's Address

   Jason Livingood
   Comcast

   Email: jason_livingood@comcast.com







































Livingood               Expires February 14, 2020               [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/