Responsibility for Authoritative DNSSEC Mistakes
draft-livingood-dnsop-auth-dnssec-mistakes-01

Domain Name System Operations                               J. Livingood
Internet-Draft                                                   Comcast
Intended status: Informational                            March 23, 2015
Expires: September 22, 2015

            Responsibility for Authoritative DNSSEC Mistakes
             draft-livingood-dnsop-auth-dnssec-mistakes-01

Abstract

   DNS Security Extensions (DNSSEC) is now entering 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.  Authoritative DNS operators
   should focus on improving these processes and establishing a high
   level of quality in their work.

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 September 22, 2015.

Copyright Notice

   Copyright (c) 2015 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 the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

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

Domain Name System Operations                               J. Livingood
Internet-Draft                                                   Comcast
Intended status: Informational                            March 23, 2015
Expires: September 22, 2015

            Responsibility for Authoritative DNSSEC Mistakes
             draft-livingood-dnsop-auth-dnssec-mistakes-01

Abstract

   DNS Security Extensions (DNSSEC) is now entering 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.  Authoritative DNS operators
   should focus on improving these processes and establishing a high
   level of quality in their work.

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 September 22, 2015.

Copyright Notice

   Copyright (c) 2015 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 the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

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

   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, operators of DNS recursive resolvers, such
   as Internet Service Providers (ISPs), occasionally observe 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.  Many end
   users tend interpret this as a failure of their DNS servers, and may
   switch to a non-validating resolver (reducing their security) or
   contact their ISP to complain, rather than seeing this as a failure
   on the part of the domain they wanted to reach.

   This document makes clear, however, that responsibility for these
   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 on the part of an
   domain administrator.  As domains transition to DNSSEC the most
   likely reason for a validation failure will be 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 recent validation failures.

   In one recent 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 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.)

3.  Responsibility for Failures

   A domain administrator is solely and completely responsible for
   managing their domain name(s) and DNS resource records.  This
   includes complete responsibility for the correctness of those
   resource records, the proper functioning 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, or other organization, these are all
   parties that the domain administrator 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.  So no matter
   whether a domain owner is also the domain administrator or not, the
   domain administrator is nevertheless operationally responsible for
   the proper configuration operation of the domain.

   So in the case of a domain name failing to successfully validate,
   when this is due to a misconfiguration of the domain, that is the
   sole responsibility of the domain administrator.

   Any assistance or mitigation responses undertaken by other parties to
   mitigate the misconfiguration of a domain name by a domain
   administrator, especially operators of DNS recursive resolvers, are
   optional and at the pleasure of those parties.

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 administrators
   from any misconfiguration of resource records is therefore
   unrealistic and unreasonable, and in the long-term is harmful 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 operators and domain name owners, in the
   case of DNSSEC-related mistakes that cause validation failures to
   occur, should focus on correcting the 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,
   as 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
   addition, 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.

5.2.  Privacy Considerations

   There are no privacy considerations in this document.

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, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [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.

   [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.

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

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

Appendix B.  Open Issues

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

   No open issues at this time

Author's Address

   Jason Livingood
   Comcast
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA 19103
   US
   
   Email: jason_livingood@cable.comcast.com
   URI:   http://www.comcast.com