SSE - Secure Systems Engineering GmbH

Hauptstraße 3 Berlin 10827 Germany pth@systemsecurity.com

OPS dnsop Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, "Automating DNSSEC Delegation Trust Maintenance" (RFC 7344) provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters that the parent can ingest. Similarly, "Child-to-Parent Synchronization in DNS" (RFC 7477) specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g., Registries and Registrars) can query these records from the child and, after validation, use them to update the parent-side Resource Record Sets (RRsets) of the delegation. This document specifies under which conditions the target states expressed via CDS/CDNSKEY and CSYNC records are considered "consistent". Parent-side entities accepting such records from the child have to ensure that update requests retrieved from different authoritative nameservers satisfy these consistency requirements before taking any action based on them. This document updates RFCs 7344 and 7477.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

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

• .  Introduction
  • .  Requirements Notation
  • .  Terminology
• .  Updates to RFCs 7344 and 7477
• .  Processing Requirements
  • .  CDS and CDNSKEY
  • .  CSYNC
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Failure Scenarios due to Inconsistencies
  • .  DS Breakage due to Replication Lag
  • .  Escalation of Lame Delegation Takeover
  • .  Multi-Provider (Permanent Multi-Signer)
    • .  DS Breakage
    • .  NS Breakage
  • .  Bogus Provider Change (Temporary Multi-Signer)
• Acknowledgments
• Author's Address

Introduction automates DNS Security Extensions (DNSSEC) delegation trust maintenance by having the child publish CDS and/or CDNSKEY records that describe the prospective DS parameters. Similarly, specifies CSYNC records indicating a desired update of the delegation's NS and associated glue records. Parent-side entities (e.g., Registries and Registrars) can use these records to update the corresponding records of the delegation. For ingesting CSYNC records, advocates that Parental Agents limit queries to a single authoritative nameserver (as done in normal resolution). (on CDS/CDNSKEY) has a corresponding section () that contains no provision for how specifically queries for these records should be done. Retrieving records from just one authoritative server (e.g., by directing queries towards a trusted validating resolver) works well under ideal operating scenarios. However, problems may arise if CDS/CDNSKEY/CSYNC record sets are inconsistent across authoritative nameserver either because they are out of sync (e.g., during a Key Signing Key (KSK) rollover) or because they are not controlled by the same entity (e.g., in a multi-signer setup ). In such cases, if CDS/CDNSKEY/CSYNC records are retrieved from one nameserver only ("naively", without a consistency check), each nameserver can unilaterally trigger an update of the delegation's DS or NS record set. For example, a single provider in a multi-signer setup may (accidentally or maliciously) cause another provider's trust anchors and/or nameservers to be removed from the delegation. This can occur both when the multi-signer configuration is temporary (e.g., during a provider change) and when it is permanent (e.g., for redundancy). In any case, a single provider should not be in the position to remove any other provider's records from the delegation. Similar breakage can occur when the delegation has lame nameservers, where an attacker may illegitimately initialize a DS record set and then manipulate the delegation's NS record set at will. More detailed examples are given in . For a CDS/CDNSKEY/CSYNC consumer, it is generally impossible to estimate the impact of a requested delegation update unless all of the child's authoritative nameservers are inspected. At the same time, applying an automated delegation update "MUST NOT break the current delegation" (per ), i.e., it must not hamper availability or validatability of the Child's resolution. As part of a more holistic treatment of the problem space, provides more-specific guidance on such safety checks. Therefore, this document specifies that parent-side entities need to ensure that the updates indicated by CDS/CDNSKEY and CSYNC record sets are plausibly consistent across the child's nameservers before taking any action based on these records. Readers are expected to be familiar with DNSSEC , in particular, , , , , and . For an overview of related operational practices, refer to and .

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 when, and only when, they appear in all capitals, as shown here.

Terminology

Multi-provider setup:

A constellation where several providers independently operate authoritative DNS service for a domain, usually for purposes of redundancy. This includes setups both with and without DNSSEC.

Multi-signer setup:

A multi-provider setup for a DNSSEC-enabled domain with multiple independent signing entities . Such a setup may be permanent (for redundancy) or temporary (for continuity of DNSSEC operation while changing the provider of a domain that normally uses a single one).

Otherwise, the terminology in this document is as defined in .

Updates to RFCs 7344 and 7477 lists acceptance rules for CDS/CDNSKEY records. This list is extended with the consistency requirements defined in this document. This document does not modify any other part of . Sections and of have logic for deciding from which nameserver to query CSYNC information. This logic is replaced with the CSYNC consistency requirements defined in this document.

Processing Requirements Consistency requirements that apply equally to CDS/CDNSKEY and CSYNC are listed first; type-specific consistency criteria are described in separate subsections. In order to determine plausible consistency of CDS/CDNSKEY or CSYNC RRsets across the child's nameservers, the Parental Agent MUST fetch all IP addresses for each nameserver hostname as listed in the Child's delegation from the Parent using a validating resolver, including any available glue records. Before acting on any CDS/CDNSKEY or CSYNC record for the child, the Parental Agent MUST have established plausible consistency by querying all of these IP addresses for the record set(s) in question, as per the guidelines spelled out in the following subsections. In all cases, consistency is REQUIRED across received responses only. (A NODATA response (see ) is a received response.) When a response cannot be obtained from a given nameserver, the Parental Agent SHOULD attempt to obtain it at a later time, before concluding that the nameserver is permanently unreachable and removing it from consideration. A configurable retry schedule is RECOMMENDED to increase the likelihood of collecting data from all nameservers. An exponential back-off schedule (e.g., 5, 10, 20, 40, ... minutes) provides a balance between faster task completion while accommodating transient unreachability. To sidestep localized routing issues, the Parental Agent MAY also attempt contacting the nameserver from another network vantage point. If an inconsistent state is encountered, the Parental Agent MUST abort the operation. Specifically, it MUST NOT delete or alter any existing RRset that would have been deleted or altered, and it MUST NOT create any RRsets that would have been created had the nameservers given consistent responses. To accommodate transient inconsistencies (e.g., replication delays), implementations MAY be configurable to undertake a retry of the full process, repeating all queries (suggested default: enabled with exponential back-off). Any pending queries can immediately be dequeued when encountering a response that confirms the status quo, either implicitly (NODATA) or explicitly (via a response that matches the current delegation state). This is because any subsequent responses could only confirm that nothing needs to happen or give an inconsistent result in which case nothing needs to happen. The parent may apply local policy in determining whether the requested update is consistent or not with the status quo, as illustrated in the type-specific sections below. In any case, queries may be continued across all nameservers for reporting purposes. Existing requirements for ensuring integrity remain in effect. In particular, DNSSEC signatures MUST be requested and validated for all queries unless otherwise noted.

CDS and CDNSKEY When retrieving 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 nameservers listed in the Child's delegation from the Parent. The Parental Agent MUST also ensure that each key referenced in any of the received answers is also referenced in all other received responses (subject to the CDS digest type considerations below) or that responses consistently indicate a request for removal of the entire DS RRset (). In other words, CDS/CDNSKEY records at the Child zone apex must be fetched directly from each reachable authoritative server as determined by the delegation's NS record set. When a key is referenced in an eligible CDS record set but not the CDNSKEY record set (or vice versa), or returned by one nameserver but is missing from at least one other nameserver's answer, the CDS/CDNSKEY state MUST be considered inconsistent. Similarly, the state MUST be considered inconsistent if there is a CDS or CDNSKEY response that indicates a removal request for the DS RRset whereas another response indicates no change (NODATA) or a DS update. CDS records MUST be considered for consistency only when their digest type field is designated as "MUST" in the "Implement for DNSSEC Delegation" column of the "Digest Algorithms" registry ). Consistency of records with other digest types need not be verified, especially when the digest type is unsupported; such records can be ignored. Independently of this, the parent may, as a matter of local policy, make its own choice regarding the hash digest types used when publishing a DS RRset (notwithstanding the requirements specified in ). (The set of keys referenced in the DS RRset is not up to local policy. Only if all keys from the CDNSKEY RRset and eligible CDS records are included is the DS RRset considered consistent.) During initial DS provisioning (DNSSEC bootstrapping), conventional DNSSEC validation for CDS/CDNSKEY responses is not (yet) available; in this case, authenticated bootstrapping should be used.

CSYNC A CSYNC-based workflow generally consists of:

1. querying the CSYNC (and possibly SOA) record to determine which data records shall be synchronized from child to parent, and
2. querying for these data records (e.g., NS) before placing them in the parent zone.

If the below conditions are not met during these steps, the CSYNC state MUST be considered inconsistent. When querying the CSYNC record, the Parental Agent MUST ascertain that queries are made against all nameservers listed in the Child's delegation from the Parent and ensure that the record's immediate flag and type bitmap are equal across received responses. The CSYNC record's SOA serial field and soaminimum flag might legitimately differ across nameservers (such as in multi-provider setups); thus, equality is not required across responses. Instead, for a given response, processing of these values MUST occur with respect to the SOA record as obtained from the same nameserver. If the resulting per-nameserver assessments of whether the update is permissible do not all agree, the CSYNC state MUST be considered inconsistent. Further, when retrieving the data record sets as indicated in the CSYNC record (such as NS or A/AAAA records), the Parental Agent MUST ascertain that all queries are made against all nameservers from which a CSYNC record was received and ensure that all of them return responses with equal rdata sets (including cases where all are empty). As an example of local policy, the parent may choose to accept glue records only for in-domain or sibling NS hostnames . Other CSYNC processing rules from remain in place without modification. For example, when the NS type flag is present, associated NS processing has to occur before potential glue updates to ensure that glue addresses match the right set of nameservers. Also, when the type bitmap contains the A/AAAA flags, corresponding address queries are only to be sent for NS hostnames that are in bailiwick, while out-of-bailiwick NS records are ignored. Refer to Sections and of for more details. CSYNC-based updates may cause validation or even insecure resolution to break (e.g., by changing the delegation to a set of nameservers that do not serve required DNSKEY records or do not know the zone at all). Parental Agents SHOULD check that CSYNC-based updates, if applied, do not break the delegation.

IANA Considerations This document has no IANA actions.

Security Considerations The level of rigor mandated by this document is needed to prevent publication of half-baked DS or delegation NS RRsets (authorized only under an insufficient subset of authoritative nameservers), ensuring that a single operator cannot unilaterally modify the delegation (add or remove trust anchors or nameservers) when other operators are present. This applies both when the setup is intentional and when it is unintentional (such as in the case of lame-delegation hijacking). As a consequence, the delegation's records can only be modified when zones are synchronized across operators, unanimously reflecting the domain owner's intentions. Both availability and integrity of the domain's DNS service benefit from this policy. In order to resolve situations in which consensus about child zone contents cannot be reached (e.g., because one of the nameserver operators is uncooperative), Parental Agents SHOULD continue to accept DS and NS/glue update requests from the domain owner via an authenticated out-of-band channel (such as Extensible Provisioning Protocol (EPP) ), irrespective of the adoption of automated delegation maintenance. Availability of such an interface also enables recovery from a situation where the private key is no longer available for signing the CDS/CDNSKEY or CSYNC records in the child zone.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent. This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy. RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records). It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document introduces an in-band method for DNS operators to publish arbitrary information about the zones for which they are authoritative, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document establishes the DS enrollment method described in Section 4 of this document as the preferred method over those from Section 3 of RFC 8078. It also updates RFC 7344. Informative References deSEC Enabling support for automatic acceptance of DNSSEC Delegation Signer (DS) parameters from the Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error and success reporting, and multi-party issues such as concurrent updates. This document describes recommendations about how these points are best addressed in practice. Work in Progress UC San Diego University of Twente University of Twente DNS Coffee UC San Diego UC San Diego CAIDA/UC San Diego IMC '20: Proceedings of the ACM Internet Measurement Conference, pp. 281-294 UC San Diego UC San Diego UC San Diego CAIDA/UC San Diego IMC '21: Proceedings of the 21st ACM Internet Measurement Conference, pp. 673-686 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describes these key-management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.

Failure Scenarios due to Inconsistencies The following scenarios are informative 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 nameserver steps out of line and the parent is not careful, DNS resolution and/or validation will break down. When several DNS providers are involved, this undermines the very guarantees of operator independence that multi-provider configurations are intended to provide.

DS Breakage due to Replication Lag If an authoritative nameserver is lagging behind during a key rollover, the parent may see different CDS/CDNSKEY RRsets depending on the nameserver contacted. This may cause old and new DS RRsets to be deployed in an alternating fashion and without the awareness of the zone maintainer, who may then inadvertently break the chain of trust by prematurely removing a DNSKEY still referenced by a (stale) CDS/CDNSKEY RRset. While foreseen in , the solution specified there requires parents to keep state on CDS/CDNSKEY RRsets. This document achieves the same without this burden and, in case the parent reports consistency errors downstream, can also help detection of the child-side replication issue by the operator.

Escalation of Lame Delegation Takeover A delegation may include a nonexistent NS hostname, for example, due to a typo or the nameserver's domain registration having expired. (Re-)registering such a non-resolvable nameserver domain allows a third party to run authoritative DNS service for all domains delegated to that NS hostname, serving responses different from the legitimate ones. This strategy for hijacking (at least part of the) DNS traffic and spoofing responses is not new but is surprisingly common . It is also known that DNSSEC reduces the impact of such an attack, as validating resolvers will reject illegitimate responses due to lack of signatures consistent with the delegation's DS records. On the other hand, if the delegation is not protected by DNSSEC, the rogue nameserver is not only able to serve unauthorized responses without detection: it is even possible for the attacker to escalate the nameserver takeover to a full domain takeover. In particular, the rogue nameserver can publish CDS/CDNSKEY records. If those are processed by the parent without ensuring consistency with other authoritative nameservers, the delegation will, with some patience, get secured with the attacker's DNSSEC keys. Of course, as the parent's query (or sometimes queries) need to hit the attacker's nameserver, this requires some statistical luck, but, eventually, it will succeed. As responses served by the remaining legitimate nameservers are not signed with these keys, validating resolvers will start rejecting them. Once DNSSEC is established, the attacker can use CSYNC to remove other nameservers from the delegation at will (and potentially add new ones under their control) or change glue records to point to the attacker's nameservers. This enables the attacker to position itself as the only party providing authoritative DNS service for the victim domain, significantly augmenting the attack's impact.

Multi-Provider (Permanent Multi-Signer)

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 delegation. As a result, the zone is broken (at least for some queries).

NS Breakage A similar scenario affects the CSYNC record, which is used to update the delegation's NS record set at the parent. For example, the issue occurs 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 in a way that breaks resolution or silently reduces the multi-provider setup to a single-provider setup.

Bogus Provider Change (Temporary Multi-Signer) Transferring DNS service for a domain name 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 own copy of the zone. Once the parent learns about 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 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 handover, the old provider is removed by inverting these steps with swapped roles. The multi-signer phase of this process breaks when the new provider, perhaps unaware of the situation and its intricacies, fails to include the old provider's keys in the DNSKEY (and CDS/CDNSKEY) record sets. One obvious consequence is that whenever the resolver happens to retrieve the DNSKEY record set from the new provider, the old provider's RRSIGs no longer validate, causing SERVFAIL to be returned. However, an even worse consequence can occur when the parent performs their next CDS/CDNSKEY scan. 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 (who still appears in the delegation) is prematurely 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.

Acknowledgments In order of first contribution or review: , , , , , , , , , , , , , , , , , and .

Author's Address SSE - Secure Systems Engineering GmbH

Hauptstraße 3 Berlin 10827 Germany pth@systemsecurity.com