The Swedish Internet Foundation

johan.stenstam@internetstiftelsen.se

deSEC, Secure Systems Engineering

peter@desec.io

Standcore LLC

standards@standcore.com

OPS dnsop Delegation Automation DS DNSSEC This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints to allow other types of actions that were previously lacking a trigger mechanism to be triggered via the DNS. Notifications merely nudge the receiver to initiate a predefined action promptly (instead of on a schedule); they do not alter the action itself (including any security checks it might employ). To enable this functionality, a method for discovering the receiver endpoint for such notification messages is introduced, via the new DSYNC record type. Notification types are recorded in a new registry, with initial support for parental NS and DS record updates including DNSSEC bootstrapping.

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) 2025 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
  • .  Design Goals for Delegation Maintenance
  • .  Requirements Notation
• .  DSYNC RR Type
  • .  Wire Format
  • .  Presentation Format
  • .  Semantics
• .  Publication of Notification Targets
  • .  Wildcard Method
  • .  Child-specific Method
• .  Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications
  • .  Endpoint Discovery
  • .  Sending Notifications
    • .  Timeouts and Error Handling
    • .  Roles
  • .  Processing of NOTIFY Messages for Delegation Maintenance
• .  Security Considerations
• .  IANA Considerations
  • .  DSYNC RR Type
  • .  DSYNC Scheme Registration
  • .  _dsync Underscore Name
• .  References
  • .  Normative References
  • .  Informative References
• .  Efficiency and Convergence Issues in DNS Scanning
  • .  Original NOTIFY for Zone Transfer Nudging
  • .  Similar Issues for DS Maintenance and Beyond
• Acknowledgements
• Authors' Addresses

Introduction The original DNS notifications , which are here referred to as "NOTIFY(SOA)", are sent from a primary server to a secondary server to minimize the latter's convergence time to a new version of the zone. This mechanism successfully addresses a significant inefficiency in the original protocol. Today, similar inefficiencies occur in new use cases, in particular delegation maintenance (DS and NS record updates). Just as in the NOTIFY(SOA) case, a new set of notification types will have a major positive benefit by allowing the DNS infrastructure to completely sidestep these inefficiencies. For additional context, see . Although this document primarily deals with applying generalized notifications to the delegation maintenance use case, future extension for other applications (such as multi-signer key exchange) is possible. No DNS protocol changes are introduced by this document. Instead, the mechanism makes use of a wider range of DNS messages allowed by the protocol. Readers are expected to be familiar with DNSSEC , including , , , , , , and . DNS-specific terminology can be found in .

Design Goals for Delegation Maintenance When the parent operator is interested in notifications for delegation maintenance (such as DS or NS update hints), a service to accept these notifications will need to be made available. Depending on the context, this service may be run by the parent operator or by a designated entity who is in charge of handling the domain's delegation data (such as a domain registrar). It seems desirable to minimize the number of steps that the notification sender needs to perform in order to figure out where to send the NOTIFY. This suggests that the lookup process be ignorant of the details of the parent-side relationships (e.g., whether or not there is a registrar). This is addressed by parameterizing the lookup with the name of the child. The parent operator may then announce the notification endpoint in a delegation-specific way by publishing it at a child-specific name. (A catch-all endpoint may be indicated by wildcarding.) The solution specified here is thus for the parent operator to publish the address where someone listens for notifications, in a child-specific way (see ). Potential senders can easily determine the name of the parent and then look up that information (see ).

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.

DSYNC RR Type This section defines the DSYNC RR type, which is subsequently used for discovering notification endpoints.

Wire Format The DSYNC RDATA wire format is encoded as follows:

DSYNC RDATA Wire Format 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RRtype | Scheme | Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/

RRtype:

The type of generalized NOTIFY that this DSYNC RR defines the desired target address for (see the "Resource Record (RR) TYPEs" registry at ). For now, only CDS and CSYNC are supported values, with the former indicating an updated CDS or CDNSKEY record set.

Scheme:

The mode used for contacting the desired notification address. This is an 8-bit unsigned integer. Records with value 0 (null scheme) are ignored by consumers. Value 1 is described in this document, and values 128-255 are Reserved for Private Use. Other values are currently unassigned. Future assignments are maintained in the registry created in .

Port:

The transport port number on the target host of the notification service. This is a 16-bit unsigned integer in network byte order. Records with value 0 are ignored by consumers.

Target:

The fully-qualified, uncompressed domain name of the target host providing the service of listening for generalized notifications of the specified type. This name MUST resolve to one or more address records.

Presentation Format The presentation format of the RDATA portion is as follows:

• The RRtype field is represented as a mnemonic from the "Resource Record (RR) TYPEs" registry.
• The Scheme field is represented by its mnemonic if assigned (see ), and is otherwise represented as an unsigned decimal integer.
• The Port field is represented as an unsigned decimal integer.
• The Target field is represented as a <domain-name> ().

Semantics For now, the only scheme defined is 1 (mnemonic: NOTIFY). By publishing a DSYNC record with this scheme, a parent indicates that they would like child operators to send them a NOTIFY message (see ) upon publication of a new CDS/CDNSKEY/CSYNC RRset to the address and port number that correspond to that DSYNC record, using conventional DNS transport . Example (for the owner names of these records, see ): IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net. IN DSYNC CSYNC NOTIFY 5360 csync-scanner.example.net. Should a need for other mechanisms arise, other schemes may be defined to deal with such requirements using alternative logic. Schemes are independent of the RRtype. They merely specify a method of contacting the target (whereas the RRtype is part of the notification payload).

Publication of Notification Targets To use generalized notifications, it is necessary for the sender to know where to direct each NOTIFY message. This section describes the procedure for discovering that notification target. Note that generalized NOTIFY messages are but one mechanism for improving the efficiency of automated delegation maintenance. Other alternatives, such as contacting the parent operator via an API or DNS Update , may (or may not) be more suitable in individual cases. Like generalized notifications, they similarly require a means for discovering where to send the API or DNS Update requests. As the scope for the publication mechanism is wider than only to support generalized notifications, a unified approach that works independently of the notification method is specified in this section. Parent operators participating in the discovery scheme for the purpose of delegation maintenance notifications MUST publish endpoint information using the record type defined in under the _dsync subdomain of the parent zone, as described in the following subsections. There MUST NOT be more than one DSYNC record for each combination of RRtype and Scheme. It is RECOMMENDED that zones containing DSYNC records be secured with DNSSEC. For practical purposes, the parent operator MAY delegate the _dsync domain as a separate zone and/or synthesize records under it. If child-specificity is not needed, the parent can publish a static wildcard DSYNC record.

Wildcard Method If the parent operator itself performs CDS/CDNSKEY or CSYNC processing for some or all delegations, or if the parent operator wants to relay notifications to some other party, a default notification target may be specified as follows: *._dsync.example. IN DSYNC CDS NOTIFY port target *._dsync.example. IN DSYNC CSYNC NOTIFY port target To accommodate indirect delegation management models, the designated notification target may relay notifications to a third party (such as the registrar, in ICANN's model). The details of such arrangements are out of scope for this document. If for some reason the parent operator cannot publish wildcard records, the wildcard label may be dropped from the DSYNC owner name (i.e., it may be published at the _dsync label instead). This practice requires an additional step during discovery (see ) and is therefore NOT RECOMMENDED.

Child-specific Method It is also possible to publish child-specific records where the parent zone's labels are stripped from the child's Fully Qualified Domain Name (FQDN), and the result is used in place of the wildcard label. As an example, consider a registrar offering domains like child.example, delegated from example zone. If the registrar provides the notification endpoint, e.g., rr-endpoint.example:5300, the parent may publish this information as follows: child._dsync.example. IN DSYNC CDS NOTIFY 5300 rr-endpoint.example.

Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications Delegation maintenance notifications address the inefficiencies related to scanning child zones for CDS/CDNSKEY records . (For an overview of the issues, see .) NOTIFY messages for delegation maintenance MUST be formatted as described in , with the qtype field replaced as appropriate. To address the CDS/CDNSKEY dichotomy, the NOTIFY(CDS) message (with qtype=CDS) is defined to indicate any child-side changes pertaining to an upcoming update of DS records. As the child DNS operator generally is unaware of whether the parent side consumes CDS records or prefers CDNSKEY, or when that policy changes, it seems advisable to publish both types of records, preferably using automation features of common authoritative nameserver software for ensuring consistency. Upon receipt of NOTIFY(CDS), the parent-side recipient (typically, registry or registrar) SHOULD initiate the same DNS lookups and verifications for DNSSEC bootstrapping or DS maintenance that would otherwise be triggered based on a timer. The CSYNC inefficiency may be similarly treated, with the child sending a NOTIFY(CSYNC) message (with qtype=CSYNC) to an address where the parent operator (or a designated party) is listening for CSYNC notifications. In both cases, the notification will speed up processing times by providing the recipient with a hint that a particular child zone has published new CDS, CDNSKEY, and/or CSYNC records.

Endpoint Discovery To locate the target for outgoing delegation maintenance notifications, the notification sender MUST perform the following steps:

1. Construct the lookup name by inserting the _dsync label after the first label of the delegation owner name.
2. Perform a lookup of type DSYNC for the lookup name, and validate the response if DNSSEC is enabled. If this results in a positive DSYNC answer, return it.
3. If the query resulted in a negative response:
   • If the response's SOA record indicates that the parent is more than one label away from the _dsync label, construct a new lookup name by inserting the _dsync label into the delegation owner name just before the parent zone labels inferred from the negative response. Then go to step 2. For example, assume that subsub.sub.child.example is delegated from example (and not from sub.child.example or child.example). The initial DSYNC query relating to it is thus directed at subsub._dsync.sub.child.example. This is expected to result in a negative response from example, and another query for subsub.sub.child._dsync.example is then required.
   • Otherwise, if the lookup name has any labels in front of the _dsync label, remove them to construct a new lookup name (such as _dsync.example). Then go to step 2. (This is to enable zone structures without wildcards.)
   • Otherwise, return null (no notification target available).

Sending Notifications When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child zone, the DNS operator SHOULD send a suitable notification to one of the endpoints discovered as described in . A NOTIFY message can only carry information about changes concerning one child zone. When there are changes to several child zones, the sender MUST send a separate notification for each one. When a primary name server publishes a new RRset in the child, there typically is a time delay until all publicly visible copies of the zone are updated. If the primary sends a notification at the exact time of publication, there is a potential for CDS/CDNSKEY/CSYNC processing to be attempted before the corresponding records are served. As a result, a desired update may not be detected (or appear inconsistent), preventing it from being applied. Therefore, it is RECOMMENDED that the child would delay sending notifications to the recipient until a consistent public view of the pertinent records could be ensured.

Timeouts and Error Handling NOTIFY messages are expected to elicit a response from the recipient (, Section 4.7). If no response is received, senders SHOULD employ the same logic as for SOA notifications (, Sections 3.5 and 3.6). The recipient's attempt to act upon the delegation update request may fail for a variety of reasons (e.g., due to violation of the continuity requirement set forth in ). Such failures may occur asynchronously, even after the NOTIFY response has been sent. In order to learn about such failures, senders MAY include an EDNS0 Report-Channel option in the NOTIFY message to request that the receiving side report any errors by making a report query with an appropriate extended DNS error (EDE) code as described in . (The prohibition of this option in queries () only applies to resolver queries and thus does not cover NOTIFY messages.) When including this EDNS0 option, the second label (QTYPE) of the report query name is equal to the qtype received in the NOTIFY message. Its agent domain MUST be subordinate or equal to one of the NS hostnames, as listed in the child's delegation in the parent zone. This is to prevent malicious senders from causing the NOTIFY recipient to send unsolicited report queries to unrelated third parties. For example, when receiving a NOTIFY(CDS) message for "example.com" with agent domain "errors.ns1.example.net", and when the requested DS update is found to break the delegation, then the following report query with EDE code 6 (DNSSEC Bogus) may be made (preferably over TCP): qname: _er.59.example.com.6._er.errors.ns1.example.net. qtype: TXT

Roles While the CDS/CDNSKEY/CSYNC processing that follows the receipt of a NOTIFY will often be performed by the registry, the protocol anticipates that in some contexts (especially for ICANN gTLDs) registrars may take on the task. In such cases, the current registrar notification endpoint may be published, enabling notifications to be directed to the appropriate target. The mechanics of how this is arranged between registry and registrar are out of scope for this document; the protocol only offers the possibility to arrange things such that from the child perspective, how the parent-side parties are organized is inconsequential: Notifications are simply sent to the published address. Because of the security model where a notification by itself never causes a change (it can only speed up the time until the next check for the same thing), the sender's identity is not crucial. This opens up the possibility of having an arbitrary party (e.g., a service separate from a nameserver) send the notifications, enabling this functionality even before the emergence of built-in support in nameserver software.

Processing of NOTIFY Messages for Delegation Maintenance The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC) processing. NOTIFY messages carrying notification payloads (records) for more than one child zone MUST be discarded, as sending them is an error. Otherwise, upon receipt of a (potentially forwarded) NOTIFY message for a particular child zone at the published notification endpoint, the receiving side (parent registry or registrar) has two options:

1. Acknowledge receipt by sending a NOTIFY response as described in , Section 4.7, and schedule an immediate check of the CDS/CDNSKEY/CSYNC RRsets published by that particular child zone (as appropriate for the type of NOTIFY received). If the NOTIFY message contains an EDNS0 Report-Channel option with an agent domain subordinate or equal to one of the NS hostnames listed in the delegation, the processing party SHOULD report any errors occurring during CDS/CDNSKEY/CSYNC processing by sending a report query with an appropriate EDE code as described in . Reporting may be done asynchronously (outside of the NOTIFY transaction). When using periodic scanning, notifications preempt the scanning timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/CSYNC RRset is indeed new or has changed, the corresponding child's timer may be reset and the scanning frequency reduced (e.g., to once a week). If a CDS/CDNSKEY/CSYNC change is later detected through scanning (without having received a notification), the NOTIFY-related state SHOULD be cleared, reverting to the default scanning schedule for this child. When introducing CDS/CDNSKEY/CSYNC scanning support at the same time as NOTIFY support, backwards compatibility considerations regarding the scanning interval do not apply; a low-frequency scanning schedule MAY thus be used by default in such cases.
2. Do not act upon the notification. To prevent retries, recipients SHOULD acknowledge the notification by sending a NOTIFY response even when otherwise ignoring the request, combined with a report query if feasible (see above). One reason to do this may be a rate limit (see ), in which case "Blocked" (15) may be a suitable extended DNS error code.

Implementing the first option will significantly decrease the convergence time (between publication of a new CDS/CDNSKEY/CSYNC record in the child and publication of the resulting DS), thereby providing improved service for the child. If, in addition to scheduling an immediate check for the child zone of the notification, the scanning schedule is also modified to be less frequent, the cost of providing the scanning service will be reduced.

Security Considerations If an action is triggered by the receipt of a DNS NOTIFY, its execution relies on the same security model that the receiving party would apply if the action were triggered by something else. This is because the notification affects the action's timing alone. For example, DS bootstrapping is expected to be performed the same way, independently of the type of trigger; this includes all security and authentication requirements (e.g., ) that the parent registry/registrar has chosen to apply. The original NOTIFY specification sidesteps most security issues by not relying on the information in the NOTIFY message in any way and instead only using it to "enter the state it would if the zone's refresh timer had expired" (Section 4.7 of ). This security model is reused for generalized NOTIFY messages. Therefore, it seems impossible to affect the behaviour of the recipient of the NOTIFY other than by hastening the timing for when different checks are initiated. As a consequence, while notifications themselves can be secured via access control mechanisms, this is not a requirement. In general, the receipt of a notification message will cause the receiving party to perform one or more outbound queries for the records of interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEY queries). When done using standard DNS, the size of these queries is comparable to that of the NOTIFY messages themselves, rendering any amplification attempts futile. The number of queries triggered per notification is also limited by the requirement that a NOTIFY message can refer to one child only. However, when the outgoing query occurs via encrypted transport, some amplification is possible, both with respect to bandwidth and computational burden. In this case, the usual principle of bounding the work applies, even under unforeseen events. Therefore, receivers MUST implement rate limiting for notification processing. It is RECOMMENDED to configure rate limiting independently for both the notification's source IP address and the name of the zone that is conveyed in the NOTIFY message. Rate limiting also mitigates the processing load from garbage notifications. Alternative solutions (such as signing notifications and validating their signatures) appear significantly more expensive without tangible benefit. In order to facilitate schemes that are authenticated outside of DNSSEC (such as via SIG(0)), zones containing DSYNC records are not required to be signed. Spoofed DSYNC responses would prevent notifications from reaching their legitimate target, and a different party may receive unsolicited notifications; however, both effects can also be achieved in the presence of DNSSEC. The illegitimate target is also enabled to learn notification contents in real time, which may be a privacy concern for the sender. If so, the sender may choose to ignore unsigned DSYNC records.

IANA Considerations

DSYNC RR Type IANA has registered DSYNC in the "Resource Record (RR) TYPEs" registry under the "Domain Name System (DNS) Parameters" registry group as follows:

Type:

DSYNC

Value:

66

Meaning:

Endpoint discovery for delegation synchronization

Reference:

RFC 9859

DSYNC Scheme Registration IANA has created the following new registry in the "Domain Name System (DNS) Parameters" registry group:

Name:

DSYNC: Location of Synchronization Endpoints

Registration Procedure:

Expert Review

Reference:

RFC 9859

The initial contents for the registry are as follows:

RRtype	Scheme (Mnemonic)	Purpose	Reference
	0	Null scheme (no-op)	RFC 9859
CDS	1 (NOTIFY)	Delegation management	RFC 9859
CSYNC	1 (NOTIFY)	Delegation management	RFC 9859
	2-127	Unassigned
	128-255	Reserved for Private Use	RFC 9859

Requests to register additional entries MUST include the following fields:

RRtype:

An RRtype that is defined for use

Scheme:

The mode used for contacting the desired notification address

Mnemonic:

The scheme's shorthand string used in presentation format

Purpose:

Use case description

Reference:

Location of specification or registration source

Registration requests are to be recorded by IANA after Expert Review . Expert Reviewers should take the points below into consideration; however, they are experts and should be given substantial latitude:

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The code points tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.
• A specification of a scheme is desirable, but early assignment before a specification is available is also possible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. A scheme number may have exactly one mnemonic.
• Experts should take into account that field values are fit for purpose. For example, the mnemonic should be indicative and have a plausible connection to the scheme's notification mechanism.

_dsync Underscore Name Per , IANA has registered the following entries to the "Underscored and Globally Scoped DNS Node Names" registry within the "Domain Name System (DNS) Parameters" registry group:

RR Type	_NODE NAME	Reference
DSYNC	_dsync	RFC 9859

References Normative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK] 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. Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [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. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. 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. 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. DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914. When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME; thus, the very act of sending the query is to report the error. 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 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. This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process. 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.

Efficiency and Convergence Issues in DNS Scanning

Original NOTIFY for Zone Transfer Nudging introduced the concept of a DNS NOTIFY message, which was used to improve the convergence time for secondary servers when a DNS zone had been updated in the primary server. The basic idea was to augment the original "pull" mechanism (a periodic SOA query) with a "push" mechanism (a NOTIFY) for a common case that was otherwise very inefficient (due to either slow convergence or wasteful and overly frequent scanning of the primary for changes). While it is possible to indicate how frequently checks should occur (via the SOA Refresh parameter), these checks did not allow catching zone changes that fall between checkpoints. addressed the optimization of the time-and-cost trade-off between a secondary server frequently checking for new versions of a zone and infrequent checks by replacing scheduled scanning with the more efficient NOTIFY mechanism.

Similar Issues for DS Maintenance and Beyond Today, we have similar issues with slow updates of DNS data in spite of the data having been published. The two most obvious cases are CDS and CSYNC scanners deployed in a growing number of TLD registries. Because of the large number of child delegations, scanning for CDS and CSYNC records is rather slow (as in, infrequent). Only a very small number of the delegations will have updated a CDS or CDNSKEY record in between two scanning runs. However, frequent scanning for CDS and CDNSKEY records is costly, and infrequent scanning causes slower convergence (i.e., delay until the DS RRset is updated). Unlike in the original case, where the primary is able to suggest the scanning interval via the SOA Refresh parameter, an equivalent mechanism does not exist for DS-related scanning. All of the above also applies to automated NS and glue record maintenance via CSYNC scanning . Again, given that CSYNC records change only rarely, frequent scanning of a large number of delegations seems disproportionately costly, while infrequent scanning causes slower convergence (delay until the delegation is updated). While use of the NOTIFY mechanism for coordinating the key exchange in multi-signer setups is conceivable, the detailed specification is left for future work.

Acknowledgements The authors acknowledge the contributions and reviews of the following individuals (in order of their first contribution or review): , , , , , , , , , , , , , , , , , , , , , , , and .

Authors' Addresses The Swedish Internet Foundation

johan.stenstam@internetstiftelsen.se

deSEC, Secure Systems Engineering

peter@desec.io

Standcore LLC

standards@standcore.com