Consistency for CDS/CDNSKEY and CSYNC is Mandatory
draft-thomassen-dnsop-cds-consistency-02

DNSOP Working Group                                         P. Thomassen
Internet-Draft                         Secure Systems Engineering, deSEC
Updates: 7344, 7477 (if approved)                        24 October 2022
Intended status: Standards Track                                        
Expires: 27 April 2023

           Consistency for CDS/CDNSKEY and CSYNC is Mandatory
                draft-thomassen-dnsop-cds-consistency-02

Abstract

   Maintenance of DNS delegations requires occasional changes of the DS
   and NS record sets on the parent side of the delegation.  [RFC7344]
   automates this for DS records by having the child publish CDS and/or
   CDNSKEY records which hold the prospective DS parameters.  Similarly,
   CSYNC records indicate a desired update of the delegation's NS
   records [RFC7477].  Parent-side entities (e.g.  Registries,
   Registrars) typically discover these records by periodically querying
   them from the child ("polling"), before using them to update the
   delegation's parameters.

   This document specifies that if polling is used, parent-side entities
   MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records
   are consistent across the child's authoritative nameservers, before
   taking any action based on these records.

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 27 April 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Thomassen                 Expires 27 April 2023                 [Page 1]
Internet-Draft               cds-consistency                October 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
   2.  Failure Scenarios . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Multi-Homing (Permanent Multi-Signer) . . . . . . . . . .   4
       2.1.1.  DS Breakage . . . . . . . . . . . . . . . . . . . . .   4
       2.1.2.  NS Breakage . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Provider Change (Temporary Multi-Signer)  . . . . . . . .   4
   3.  Performing a Poll-based CDS or CDNSKEY Update . . . . . . . .   5
   4.  Performing a Poll-based CSYNC Update  . . . . . . . . . . . .   6
     4.1.  Querying for CSYNC  . . . . . . . . . . . . . . . . . . .   6
     4.2.  Querying for Data Records (e.g.  NS)  . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change History (to be removed before publication)  .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [RFC7344] automates DNSSEC delegation trust maintenance by having the
   child publish CDS and/or CDNSKEY records which hold the prospective
   DS parameters.  Similarly, [RFC7477] specifies CSYNC records
   indicating a desired update of the delegation's NS records.  Parent-
   side entities (e.g.  Registries, Registrars) can use these records to
   update the delegation's DS and NS records.

   A common method for discovering these signals is to periodically
   query them from the child zone ("polling"), as described in
   Section 6.1 of [RFC7344] (CDS/CDNSKEY) and Section 3.1 of [RFC7477]
   (CSYNC).

Thomassen                 Expires 27 April 2023                 [Page 2]
Internet-Draft               cds-consistency                October 2022

   While [RFC7344] does specify acceptance rules (Section 4.1) for CDS/
   CDNSKEY records that have been retrieved, it does not mention how
   specifically the poll queries should be done.  For CSYNC, [RFC7477]
   leaves it up to the parent to decide from how many nameservers the
   records are retrieved (Section 4.2).  A naive implementation would
   thus be likely to retrieve records from just one authoritative
   server, possibly by directing queries towards a trusted validating
   resolver.

   This may be fine if all authoritative nameservers are controlled by
   the same entity (typically the DNS operator).  However, it poses a
   problem in conjunction with the multi-signer scenarios laid out in
   [RFC8901], both when deployed temporarily (during a provider change)
   or permanently (in a multi-homing setup).

   CDS/CDNSKEY/CSYNC records retrieved "naively" from one nameserver
   only may be entirely inconsistent with those of other authoritative
   servers.  When several providers are configured and no consistency
   check is done, a single provider could (accidentally or maliciously)
   roll the DS or NS record set at the parent and, for example, remove
   the other provider's trust anchors and/or nameservers from the
   delegation.  More detailed examples are given in Section 2.

   Whether in a permanent multi-homing setup or during provider change:
   A single provider should not be in the position to remove the other
   providers' records from the delegation.

   To address this issue, this document specifies that if polling is
   used, parent-side entities MUST ensure that the updates indicated by
   CDS/CDNSKEY and CSYNC record sets are consistent across all of the
   child's authoritative nameservers, before taking any action based on
   these records.

   Readers are expected to be familiar with DNSSEC, including [RFC4033],
   [RFC4034], [RFC4035], [RFC6781], [RFC7344], [RFC7477], and [RFC8901].

1.1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Thomassen                 Expires 27 April 2023                 [Page 3]
Internet-Draft               cds-consistency                October 2022

2.  Failure Scenarios

   The following scenarios are examples of how things can go wrong when
   consistency is not enforced by the parent during CDS/CDNSKEY/CSYNC
   processing.  Other scenarios that cause similar (or perhaps even
   more) harm may exist.

   The common feature of these scenarios is that if one DNS provider
   makes a mistake and the parent is not careful, DNS resolution and/or
   validation will break down, undermining the very guarantees of
   operator independence that DNSSEC multi-signer models are intended to
   provide.

2.1.  Multi-Homing (Permanent Multi-Signer)

2.1.1.  DS Breakage

   While performing a key rollover and adjusting the corresponding CDS/
   CDNSKEY records, a provider could accidentally publish CDS/CDNSKEY
   records that only include its own keys.

   When the parent happens to retrieve the records from a nameserver
   controlled by this provider, the other providers' DS records would be
   removed from the parent.  As a result, the zone is broken at least
   for some queries.

2.1.2.  NS Breakage

   A similar scenario affects the CSYNC record, which is used to update
   the delegation's NS record set at the parent.  The issue occurs, for
   example, when a provider accidentally includes only their own set of
   hostnames in the local NS record set, or publishes an otherwise
   flawed NS record set.

   If the parent then observes a CSYNC signal and fetches the flawed NS
   record set without ensuring consistency across nameservers, the
   delegation may be updated so that resolution is broken, or the multi-
   homing setup is silently reduced to a single-provider setup.

2.2.  Provider Change (Temporary Multi-Signer)

   Transferring a domain from one (signing) DNS provider to another,
   without going insecure, necessitates a brief period during which the
   domain is operated in multi-signer mode: First, the providers include
   each other's signing keys as DNSKEY and CDS/CDNSKEY records in their
   copy of the zone.  Once the parent detects the updated CDS/CDNSKEY
   record set at the old provider, the delegation's DS record set is
   updated.  Then, after waiting for cache expiration, the new

Thomassen                 Expires 27 April 2023                 [Page 4]
Internet-Draft               cds-consistency                October 2022

   provider's NS hostnames can be added to the zone's NS record set, so
   that queries start balancing across both providers.  (To conclude the
   hand-over, the old provider is removed by inverting these steps with
   swapped roles.)

   The multi-signer phase of this process breaks when the new provider
   fails to include the old provider's keys in the DNSKEY and CDS/
   CDNSKEY record sets.  One obvious consequence of that is that
   whenever the resolver happens to retrieve the DNKSEY record set from
   the new provider, the old provider's RRSIGs do no longer validate,
   causing to SERVFAIL responses.

   However, an even worse consequence can occur when the parent performs
   their next CDS/CDNSKEY scan: It may then happen that the incorrect
   CDS/CDNSKEY record set is fetched from the new provider and used to
   update the delegation's DS record set.  As a result, the old provider
   is prematureley removed from the domain's DNSSEC chain of trust.  The
   new DS record set authenticates the new provider's DNSKEYs only, and
   DNSSEC validation fails for all answers served by the old provider.

3.  Performing a Poll-based CDS or CDNSKEY Update

   The terminology in this section is as defined in [RFC7344].

   To retrieve a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust
   maintenance, the Parental Agent, knowing both the Child zone name and
   its NS hostnames, MUST ascertain that queries are made against all of
   the nameservers listed in the Child's delegation from the Parent, and
   ensure that each key referenced in any of the received answers is
   also referenced in all other received responses.

   In other words, CDS/CDNSKEY records at the Child zone apex MUST be
   fetched directly from each of the authoritative servers as determined
   by the delegation's NS record set, with DNSSEC validation enforced.
   When a key is referenced in a CDS or CDNSKEY record set returned by
   one nameserver, but is missing from a least one other nameserver's
   answer, the CDS/CDNSKEY state MUST be considered inconsistent.

   Consistency is only REQUIRED across received responses: Nameservers
   that appear to be unavailable SHOULD be disregarded as if they were
   not part of the NS record set.

   If an inconsistent CDS/CDNSKEY state is encountered, the Parental
   Agent MUST take no action.  Specifically, it MUST NOT delete or alter
   the existing DS RRset.

Thomassen                 Expires 27 April 2023                 [Page 5]
Internet-Draft               cds-consistency                October 2022

4.  Performing a Poll-based CSYNC Update

   A CSYNC-based update consists of (1) polling the CSYNC record to
   determine which data records shall be synchronized from child to
   parent; (2) querying for these data records (e.g.  NS) and placing
   them in the parent zone.  Both steps are described separately below.

   If an inconsistent CSYNC state is encountered in the process, the
   Parental Agent MUST take no action.  Specifically, it MUST NOT delete
   or alter any existing NS or other data RRset.

4.1.  Querying for CSYNC

   When retrieving CYSNC record sets, the Parental Agent MUST ascertain
   that queries are made against all of the nameservers listed in the
   Child's delegation from the Parent, and ensure that the CSYNC record
   sets are equal across all received responses.  Otherwise, the CSYNC
   state MUST be considered inconsistent.

   For CSYNC queries, consistency is only REQUIRED across received
   responses: Nameservers that appear to be unavailable SHOULD be
   disregarded as if they were not part of the NS record set.  (This is
   like for CDS/CDNSKEY queries above.)

4.2.  Querying for Data Records (e.g.  NS)

   When retrieving data records (e.g.  NS), the Parental Agent MUST
   ascertain that all queries are made against all of the nameservers
   listed in the Child's delegation from the Parent, and ensure that all
   answers received are equal.  Otherwise, the CSYNC state MUST be
   considered inconsistent.

   Answers MUST be all non-empty and equal, or all empty.  If both an
   empty and a non-empty answer is received for a data record query, the
   CSYNC state MUST be considered inconsistent.

   Nameservers that appear to be unavailable SHOULD be disregarded as if
   they were not part of the NS record set.

5.  Security Considerations

   The level of rigor mandated by this document is needed to prevent
   publication of a half-baked DS or NS RRsets (authorized only under an
   insufficient subset of authoritative nameservers).  This ensures, for
   example, that an operator in a multi-homed setup cannot unilaterally
   remove another operator's trust anchor or nameservers from the
   delegation.

Thomassen                 Expires 27 April 2023                 [Page 6]
Internet-Draft               cds-consistency                October 2022

   As a consequence, the delegation's records can only be modified when
   there is consensus across operators.

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

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

   [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
              DNSSEC Delegation Trust Maintenance", RFC 7344,
              DOI 10.17487/RFC7344, September 2014,
              <https://www.rfc-editor.org/info/rfc7344>.

   [RFC7477]  Hardaker, W., "Child-to-Parent Synchronization in DNS",
              RFC 7477, DOI 10.17487/RFC7477, March 2015,
              <https://www.rfc-editor.org/info/rfc7477>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8901]  Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
              Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
              DOI 10.17487/RFC8901, September 2020,
              <https://www.rfc-editor.org/info/rfc8901>.

Thomassen                 Expires 27 April 2023                 [Page 7]
Internet-Draft               cds-consistency                October 2022

Appendix A.  Change History (to be removed before publication)

   *  draft-thomassen-dnsop-cds-consistency-02

   |  Don't ignore DoE responses from individual nameservers (instead,
   |  require consistency across all responses received)

   *  draft-thomassen-dnsop-cds-consistency-01

   |  Allow for nameservers that don't respond or provide DoE (i.e.
   |  require consistency only among the non-empty answers received)
   |  
   |  Define similar requirements for CSYNC.
   |  
   |  Editorial changes.

   *  draft-thomassen-dnsop-cds-consistency-00

   |  Initial public draft.

Author's Address

   Peter Thomassen
   Secure Systems Engineering, deSEC
   Berlin
   Germany
   Email: peter.thomassen@securesystems.de

Thomassen                 Expires 27 April 2023                 [Page 8]