| RFC 9859 | Generalized Notifications | September 2025 |
| Stenstam, et al. | Standards Track | [Page] |
This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyondconventional zone transfer hints to allow other types of actionsthat 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 endpointfor such notification messages is introduced, via the new DSYNC record type.Notification types are recorded in a new registry, with initial support forparental NS and DS record updates including DNSSEC bootstrapping.¶
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 athttps://www.rfc-editor.org/info/rfc9859.¶
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 (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.¶
The original DNS notifications[RFC1996], which are here referred to as"NOTIFY(SOA)", are sent from a primary server to a secondary server tominimize the latter's convergence time to a new version of thezone. This mechanism successfully addresses a significant inefficiencyin the original protocol.¶
Today, similar inefficiencies occur in new use cases, in particular delegationmaintenance (DS and NS record updates). Just as in the NOTIFY(SOA) case, a newset of notification types will have a major positive benefit byallowing the DNS infrastructure to completely sidestep theseinefficiencies. For additional context, seeAppendix A.¶
Although this document primarily deals with applying generalized notificationsto 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 mechanismmakes use of a wider range of DNS messages allowed by the protocol.¶
Readers are expected to be familiar with DNSSEC[RFC9364], including[RFC6781],[RFC7344],[RFC7477],[RFC7583],[RFC8078],[RFC8901], and[RFC9615].DNS-specific terminology can be found in[RFC9499].¶
When the parent operator is interested in notifications for delegationmaintenance (such as DS or NS update hints), a service to accept these notifications will need to bemade available. Depending on thecontext, this service may be run by the parent operatoror by a designated entity who is in charge of handling the domain'sdelegation data (such as a domain registrar).¶
It seems desirable to minimize the number of steps that the notification senderneeds to perform in order to figure out where to send the NOTIFY. This suggeststhat the lookup process be ignorant of the details of the parent-siderelationships (e.g., whether or not there is a registrar). This isaddressed by parameterizing the lookup with the name of the child. Theparent operator may then announce the notification endpointin 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 publishthe address where someone listens for notifications, in a child-specificway (seeSection 3). Potential senders can easily determine the nameof the parent and then look up that information (seeSection 4.1).¶
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.¶
This section defines the DSYNC RR type, which is subsequently used fordiscovering notification endpoints.¶
The DSYNC RDATA wire format is encoded as follows:¶
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 ... /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
The type of generalized NOTIFY that this DSYNC RR defines thedesired target address for (see the "Resource Record (RR) TYPEs"registry at<https://www.iana.org/assignments/dns-parameters/>). For now, only CDS and CSYNC are supported values, withthe former indicating an updated CDS or CDNSKEY record set.¶
The mode used for contacting the desired notification address. This is an8-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 inSection 6.2.¶
The transport port number on the target host of the notification service. Thisis a 16-bit unsigned integer in network byte order. Records withvalue 0 are ignored by consumers.¶
The fully-qualified, uncompressed domain name of the target hostproviding the service of listening for generalized notifications of thespecified type. This nameMUST resolve to one or more address records.¶
The presentation format of the RDATA portion is as follows:¶
The RRtype field is represented as a mnemonic from the "ResourceRecord (RR) TYPEs" registry.¶
The Scheme field is represented by its mnemonic if assigned (seeSection 6.2), 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> (Section 5.1 of [RFC1035]).¶
For now, the only scheme defined is 1 (mnemonic: NOTIFY). By publishing aDSYNC record with this scheme, a parent indicates that they would like childoperators to send them a NOTIFY message (seeSection 4) upon publication ofa new CDS/CDNSKEY/CSYNC RRset to the address and port number that correspond to that DSYNC record, using conventionalDNS transport[RFC1035].¶
Example (for the owner names of these records, seeSection 3):¶
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 definedto deal with such requirements using alternative logic.¶
Schemes are independent of the RRtype. They merely specify a method ofcontacting the target (whereas the RRtype is part of the notificationpayload).¶
To use generalized notifications, it is necessary for the sender to knowwhere to direct each NOTIFY message. This section describes theprocedure for discovering that notification target.¶
Note that generalized NOTIFY messages are but one mechanism forimproving the efficiency of automated delegation maintenance. Otheralternatives, such as contacting the parent operator via an API orDNS Update[RFC2136], may (or may not) be more suitable inindividual cases. Like generalized notifications, they similarly requirea means for discovering where to send the API or DNS Update requests.¶
As the scope for the publication mechanism is wider than only tosupport generalized notifications, a unified approach that worksindependently of the notification method is specified in this section.¶
Parent operators participating in the discovery scheme for the purpose ofdelegation maintenance notificationsMUST publish endpoint informationusing the record type defined inSection 2 under the_dsyncsubdomain of the parent zone, as described in the following subsections.¶
ThereMUST NOT be more than one DSYNC record for each combination ofRRtype and Scheme.It isRECOMMENDED that zones containing DSYNC records be secured with DNSSEC.¶
For practical purposes, the parent operatorMAY delegate the_dsyncdomain as a separate zone and/or synthesize records under it. Ifchild-specificity is not needed, the parent can publish a staticwildcard DSYNC record.¶
If the parent operator itself performs CDS/CDNSKEY or CSYNC processingfor some or all delegations, or if the parent operator wants to relay notifications to someother 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, thedesignated notification target may relay notifications to a third party(such as the registrar, in ICANN's model). The details of sucharrangements 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., itmay be published at the_dsync label instead). This practice requiresan additional step during discovery (seeSection 4.1) and isthereforeNOT RECOMMENDED.¶
It is also possible to publish child-specific records where the parent zone'slabels are stripped from the child's Fully Qualified Domain Name (FQDN), and the result is used in place ofthe wildcard label.¶
As an example, consider a registrar offering domains likechild.example, delegated fromexample zone. If the registrarprovides 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 notifications address the inefficiencies relatedto scanning child zones for CDS/CDNSKEY records[RFC7344][RFC8078][RFC9615]. (For an overview of the issues,seeAppendix A.)¶
NOTIFY messages for delegation maintenanceMUST be formatted as described in[RFC1996], with theqtype field replaced as appropriate.¶
To address the CDS/CDNSKEY dichotomy, the NOTIFY(CDS) message (withqtype=CDS) is defined to indicate any child-side changes pertainingto an upcoming update of DS records.As the child DNS operator generally is unaware of whether the parentside consumes CDS records or prefers CDNSKEY, or when that policychanges, it seems advisable to publish both types of records,preferably using automation features of common authoritative nameserversoftware for ensuring consistency.¶
Upon receipt of NOTIFY(CDS), the parent-side recipient (typically, registry orregistrar)SHOULD initiate the same DNS lookups and verifications forDNSSEC bootstrapping[RFC9615] or DS maintenance[RFC7344][RFC8078] that would otherwise be triggered based on atimer.¶
The CSYNC[RFC7477] inefficiency may be similarly treated, with thechild sending a NOTIFY(CSYNC) message (withqtype=CSYNC) to an addresswhere the parent operator (or a designated party) is listening for CSYNCnotifications.¶
In both cases, the notification will speed up processing times byproviding the recipient with a hint that a particular child zone haspublished new CDS, CDNSKEY, and/or CSYNC records.¶
To locate the target for outgoing delegation maintenance notifications,the notification senderMUST perform the following steps:¶
Construct the lookup name by inserting the_dsync label after thefirst label of the delegation owner name.¶
Perform a lookup of type DSYNC for the lookup name, and validate theresponse if DNSSEC is enabled. If this results in a positive DSYNC answer,return it.¶
If the query resulted in a negative response:¶
If the response's SOA record indicates that the parent is more thanone label away from the_dsync label, construct a new lookup nameby inserting the_dsync label into the delegation owner name justbefore the parent zone labels inferred from the negative response.Then go to step 2.¶
For example, assume thatsubsub.sub.child.example is delegated fromexample (and not fromsub.child.example orchild.example). Theinitial DSYNC query relating to it is thus directed atsubsub._dsync.sub.child.example. This is expected to result in anegative response fromexample, and another query forsubsub.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 (suchas_dsync.example). Then go to step 2.(This is to enable zone structures without wildcards.)¶
Otherwise, return null (no notification target available).¶
When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child zone,the DNS operatorSHOULD send a suitable notification to one of theendpoints discovered as described inSection 4.1.¶
A NOTIFY message can only carry information about changes concerning onechild zone. When there are changes to several child zones, the senderMUST send a separate notification for each one.¶
When a primary name server publishes a new RRset in the child, theretypically is a time delay until all publicly visible copies of the zoneare updated. If the primary sends a notification at the exact time ofpublication, there is a potential for CDS/CDNSKEY/CSYNC processing to beattempted before the corresponding records are served. As a result, adesired update may not be detected (or appear inconsistent), preventingit from being applied.¶
Therefore, it isRECOMMENDED that the child would delay sending notificationsto the recipient until a consistent public view of the pertinentrecords could be ensured.¶
NOTIFY messages are expected to elicit a response from the recipient([RFC1996], Section 4.7). If no response is received, sendersSHOULDemploy the same logic as for SOA notifications ([RFC1996], Sections 3.5 and 3.6).¶
The recipient's attempt to act upon the delegation update request mayfail for a variety of reasons (e.g., due to violation of the continuityrequirement set forth in[RFC7344],Section 4.1). Such failures mayoccur asynchronously, even after the NOTIFY response has been sent.¶
In order to learn about such failures, sendersMAY include anEDNS0 Report-Channel option[RFC9567] in the NOTIFY message torequest that the receiving side report any errors by making a report querywith an appropriate extended DNS error (EDE) code as described in[RFC8914].(The prohibition of this option in queries ([RFC9567],Section 6.1) onlyapplies 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 domainMUST be subordinateor equal to one of the NS hostnames, as listed in the child's delegationin the parent zone.This is to prevent malicious senders from causing the NOTIFY recipientto 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¶
While the CDS/CDNSKEY/CSYNC processing that follows the receipt of a NOTIFYwill often be performed by the registry, the protocol anticipates thatin some contexts (especially for ICANN gTLDs) registrars may take onthe task. In such cases, the current registrar notification endpoint maybe published, enabling notifications to be directed to theappropriate target. The mechanics of how this is arranged betweenregistry and registrar are out of scope for this document; the protocolonly offers the possibility to arrange things such that from the childperspective, how the parent-side parties areorganized is inconsequential: Notifications are simply sent to the published address.¶
Because of the security model where a notification by itself nevercauses a change (it can only speed up the time until the nextcheck for the same thing), the sender's identity is not crucial.This opens up the possibility of having an arbitrary party (e.g., aservice separate from a nameserver) send the notifications, enabling this functionalityeven before the emergence of built-in support in nameserver software.¶
The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC) processing.¶
NOTIFY messages carrying notification payloads (records) for morethan one child zoneMUST be discarded, as sending them is an error.¶
Otherwise, upon receipt of a (potentially forwarded) NOTIFY message fora particular child zone at the published notification endpoint,the receiving side (parent registry or registrar) has two options:¶
Acknowledge receipt by sending a NOTIFY response as described in[RFC1996], Section 4.7, and schedulean immediate check of the CDS/CDNSKEY/CSYNC RRsets published by thatparticular child zone (as appropriate for the type of NOTIFY received).¶
If the NOTIFY message contains an EDNS0 Report-Channeloption[RFC9567] with an agent domain subordinate or equal to one of the NShostnames listed in the delegation, the processing partySHOULDreport any errors occurring during CDS/CDNSKEY/CSYNC processing by sendinga report query with an appropriate EDE code asdescribed in[RFC8914]. Reporting may be done asynchronously(outside of the NOTIFY transaction).¶
When using periodic scanning, notifications preempt the scanningtimer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/CSYNC RRsetis indeed new or has changed, the corresponding child's timer maybe reset and the scanning frequency reduced (e.g., to once a week).If a CDS/CDNSKEY/CSYNC change is later detected through scanning (withouthaving received a notification), the NOTIFY-related stateSHOULD becleared, reverting to the default scanning schedule for this child.¶
When introducing CDS/CDNSKEY/CSYNC scanning support at the same timeas NOTIFY support, backwards compatibility considerationsregarding the scanning interval do not apply; a low-frequencyscanning scheduleMAY thus be used by default in such cases.¶
Do not act upon the notification. To prevent retries, recipientsSHOULD acknowledge the notification by sending a NOTIFY responseeven when otherwise ignoring the request, combined with a reportquery if feasible (see above). One reason to do this may be a ratelimit (seeSection 5), in which case "Blocked" (15) may be asuitable extended DNS error code.¶
Implementing the first option will significantly decrease theconvergence time (between publication of a new CDS/CDNSKEY/CSYNC record in thechild and publication of the resulting DS), thereby providing improvedservice for the child.¶
If, in addition to scheduling an immediate check for the child zone ofthe notification, the scanning schedule is also modified to be lessfrequent, the cost of providing the scanning service will be reduced.¶
If an action is triggered by the receipt of a DNS NOTIFY, its execution relieson the same security model that the receiving party would apply if the actionwere triggered by something else. This is because the notification affectsthe action's timing alone. For example, DS bootstrapping is expected to beperformed the same way, independently of the type of trigger; this includes allsecurity and authentication requirements (e.g.,[RFC9615]) that the parentregistry/registrar has chosen to apply.¶
The original NOTIFY specification sidesteps most security issues by notrelying on the information in the NOTIFY message in any way and insteadonly using it to "enter the state it would if the zone's refresh timerhad expired" (Section 4.7 of[RFC1996]).¶
This security model is reused for generalized NOTIFY messages. Therefore, itseems impossible to affect the behaviour of the recipient ofthe NOTIFY other than by hastening the timing for when different checksare initiated.As a consequence, while notifications themselves can be secured via accesscontrol mechanisms, this is not a requirement.¶
In general, the receipt of a notification message will cause thereceiving party to perform one or more outbound queries for the recordsof interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEYqueries). When done using standard DNS, the size of these queries iscomparable to that of the NOTIFY messages themselves, rendering anyamplification attempts futile. The number of queries triggered pernotification is also limited by the requirement that a NOTIFY messagecan refer to one child only.¶
However, when the outgoing query occurs via encrypted transport, someamplification is possible, both with respect to bandwidth andcomputational burden. In this case, the usual principle of bounding thework applies, even under unforeseen events.¶
Therefore, receiversMUST implement rate limiting for notificationprocessing. It isRECOMMENDED to configure rate limiting independentlyfor both the notification's source IP address and the name of the zonethat is conveyed in the NOTIFY message. Rate limiting also mitigatesthe processing load from garbage notifications.¶
Alternative solutions (such as signing notifications and validatingtheir signatures) appear significantly more expensive without tangiblebenefit.¶
In order to facilitate schemes that are authenticated outside of DNSSEC(such as via SIG(0)), zones containing DSYNC records are not required tobe signed. Spoofed DSYNC responses would prevent notifications fromreaching their legitimate target, and a different party may receiveunsolicited notifications; however, both effects can also be achievedin the presence of DNSSEC. The illegitimate target is also enabled tolearn notification contents in real time, which may be a privacy concernfor the sender. If so, the sender may choose to ignore unsigned DSYNCrecords.¶
IANA has registered DSYNC in the "Resource Record (RR) TYPEs" registryunder the "Domain Name System (DNS) Parameters" registry group as follows:¶
IANA has created the following new registry in the"Domain Name System (DNS) Parameters" registry group:¶
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 entriesMUST include the following fields:¶
Registration requests are to be recorded by IANA after Expert Review[RFC8126].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 plausibleconnection to the scheme's notification mechanism.¶
Per[RFC8552], 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 |
[RFC1996] introduced the concept of a DNS NOTIFY message, which was usedto improve the convergence time for secondary servers when a DNS zonehad been updated in the primary server. The basic idea was to augment theoriginal "pull" mechanism (a periodic SOA query) with a "push"mechanism (a NOTIFY) for a common case that was otherwise veryinefficient (due to either slow convergence or wasteful and overlyfrequent 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 catchingzone changes that fall between checkpoints.[RFC1996] 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.¶
Today, we have similar issues with slow updates of DNS data in spite ofthe data having been published. The two most obvious cases are CDS andCSYNC scanners deployed in a growing number of TLD registries. Because ofthe large number of child delegations, scanning for CDS and CSYNC recordsis rather slow (as in, infrequent).¶
Only a very small number of the delegations will have updateda CDS or CDNSKEY record in between two scanning runs. However, frequentscanning for CDS and CDNSKEY records is costly, and infrequent scanningcauses slower convergence (i.e., delay until the DS RRset is updated).¶
Unlike in the original case, where the primary is able to suggest thescanning interval via the SOA Refresh parameter, an equivalent mechanismdoes not exist for DS-related scanning.¶
All of the above also applies to automated NS and glue recordmaintenance via CSYNC scanning[RFC7477]. Again, given that CSYNCrecords change only rarely, frequent scanning of a large number ofdelegations seems disproportionately costly, while infrequent scanningcauses slower convergence (delay until the delegation is updated).¶
While use of the NOTIFY mechanism for coordinating the key exchange inmulti-signer setups[RFC8901] isconceivable, the detailed specification is left for future work.¶
The authors acknowledge the contributions and reviews of the following individuals (in order of their first contribution or review):Joe Abley,Mark Andrews,Christian Elmerot,Ólafur Guðmundsson,Paul Wouters,Brian Dickson,Warren Kumari,Geoff Huston,Patrick Mevzek,Tim Wicinski,Q Misell,Stefan Ubbink,Matthijs Mekking,Kevin P. Fleming,Nicolai Leymann,Giuseppe Fioccola,Peter Yee,Tony Li,Paul Wouters,Roman Danyliw,Peter van Dijk,John Scudder,Éric Vyncke, andOli Schacher.¶