RFC 9859

Generalized DNS Notifications

📅 published September 2025, from ietf

RFC 9859: Generalized DNS Notifications 💖 (part 1 of 4)

Title block 🎀

  • Title: Generalized DNS Notifications
  • Number: RFC 9859
  • Category: Standards Track ✨
  • Date: September 2025
  • ISSN: 2070-1721
  • Stream: Internet Engineering Task Force (IETF)
  • Authors: J. Stenstam (The Swedish Internet Foundation), P. Thomassen (deSEC, Secure Systems Engineering), and J. Levine (Standcore LLC) 👑
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🦋

Abstract 🌸

okay so this doc takes DNS NOTIFY (RFC 1996) and levels it up. Originally NOTIFY was just for zone transfer hints, but now it's getting extended so other kinds of actions that never had a trigger can get kicked off through DNS. 💅 A notification is basically a nudge that tells the receiver to start a predefined action right now instead of waiting for its usual schedule. It does NOT change the action itself, including any security checks the action might use. Iconic restraint 🙈

To make this work, there's a new way to find the receiver endpoint for these notifications: a brand-new DSYNC record type. The notification types get tracked in a new registry, and the first ones supported are parental NS and DS record updates, including DNSSEC bootstrapping. Main character energy for DNS, fr fr ✨

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). More info on Internet Standards is in Section 2 of RFC 7841. 🫶

For the current status of this document, any errata, and how to send feedback, check https://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) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License. 🧚

Table of Contents 🍓

1.  Introduction
  1.1.  Design Goals for Delegation Maintenance
  1.2.  Requirements Notation
2.  DSYNC RR Type
  2.1.  Wire Format
  2.2.  Presentation Format
  2.3.  Semantics
3.  Publication of Notification Targets
  3.1.  Wildcard Method
  3.2.  Child-specific Method
4.  Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications
  4.1.  Endpoint Discovery
  4.2.  Sending Notifications
    4.2.1.  Timeouts and Error Handling
    4.2.2.  Roles
  4.3.  Processing of NOTIFY Messages for Delegation Maintenance
5.  Security Considerations
6.  IANA Considerations
  6.1.  DSYNC RR Type
  6.2.  DSYNC Scheme Registration
  6.3.  _dsync Underscore Name
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  Efficiency and Convergence Issues in DNS Scanning
  A.1.  Original NOTIFY for Zone Transfer Nudging
  A.2.  Similar Issues for DS Maintenance and Beyond
Acknowledgements
Authors' Addresses

1. Introduction 💖

the original DNS notifications [RFC1996] (we're calling them "NOTIFY(SOA)" here) get sent from a primary server to a secondary server so the secondary catches up to a new version of the zone faster. This fixed a big inefficiency in the original protocol, and it was a huge win. ✨

Now the same kind of inefficiency is showing up in new use cases, especially delegation maintenance (DS and NS record updates). Just like with NOTIFY(SOA), a new set of notification types would be a massive win, because the DNS infrastructure could totally sidestep these inefficiencies. More context is in Appendix A. 🦋

This doc mainly covers applying generalized notifications to delegation maintenance, but future extensions for other applications (like multi-signer key exchange) are possible. 🌸

No DNS protocol changes are introduced here. The mechanism just uses a wider range of DNS messages that the protocol already allows. 🫶

You're expected to already know DNSSEC [RFC9364], including [RFC6781], [RFC7344], [RFC7477], [RFC7583], [RFC8078], [RFC8901], and [RFC9615]. DNS-specific terms are defined in [RFC9499]. 📚

1.1. Design Goals for Delegation Maintenance 🧁

When the parent operator wants notifications for delegation maintenance (like DS or NS update hints), a service needs to exist to accept them. Depending on the situation, that service might be run by the parent operator, or by a designated entity in charge of handling the domain's delegation data (like a domain registrar). 🎀

It makes sense to keep the number of steps the notification sender has to take, just to figure out where the NOTIFY goes, as small as possible. So the lookup should be ignorant of the details of parent-side relationships (for example, whether or not there's a registrar). The way to do that is to parameterize the lookup with the child's name. The parent operator can then announce the notification endpoint in a delegation-specific way by publishing it at a child-specific name. (A catch-all endpoint can be indicated with a wildcard.) 💅

So the solution here is for the parent operator to publish the address where someone listens for notifications, in a child-specific way (see Section 3). Potential senders can easily work out the parent's name and then look up that info (see Section 4.1). 🌈

1.2. Requirements Notation ⭐

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

2. DSYNC RR Type 👑

This section defines the DSYNC RR type, which later gets used to discover notification endpoints. 💜

2.1. Wire Format 🧚

The DSYNC RDATA wire format is encoded like this:

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

Figure 1: DSYNC RDATA Wire Format 🌸

RRtype: this is the type of generalized NOTIFY that this DSYNC RR defines the desired 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. The former means an updated CDS or CDNSKEY record set. 🦋

Scheme: this is the mode used for contacting the desired notification address. It's 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 live in the registry created in Section 6.2. ✨

Port: this is the transport port number on the target host of the notification service. It's a 16-bit unsigned integer in network byte order. Records with value 0 are ignored by consumers. 🍓

Target: this is the fully-qualified, uncompressed domain name of the target host that provides the service of listening for generalized notifications of the specified type. This name MUST resolve to one or more address records. 🫶

2.2. Presentation Format 💖

The presentation format of the RDATA portion goes like this:

  • The RRtype field is shown as a mnemonic from the "Resource Record (RR) TYPEs" registry. 🎀
  • The Scheme field is shown by its mnemonic if it's assigned (see Section 6.2). Otherwise it's an unsigned decimal integer. 💅
  • The Port field is shown as an unsigned decimal integer. 🌈
  • The Target field is shown as a <domain-name> (Section 5.1 of [RFC1035]). 🧁

2.3. Semantics 🔥

For now, the only scheme defined is 1 (mnemonic: NOTIFY). When a parent publishes a DSYNC record with this scheme, they're saying they'd like child operators to send them a NOTIFY message (see Section 4) whenever a new CDS/CDNSKEY/CSYNC RRset gets published. The message goes to the address and port number that match that DSYNC record, using conventional DNS transport [RFC1035]. 👑

Example (for the owner names of these records, see Section 3):

IN DSYNC  CDS   NOTIFY 5359 cds-scanner.example.net.
IN DSYNC  CSYNC NOTIFY 5360 csync-scanner.example.net.

If other mechanisms are ever needed, other schemes can be defined to handle those requirements with alternative logic. 🌸

Schemes are independent of the RRtype. They just specify a method of contacting the target, whereas the RRtype is part of the notification payload. 💜

3. Publication of Notification Targets 🧚

To use generalized notifications, the sender has to know where to direct each NOTIFY message. This section describes the procedure for discovering that notification target. 🦋

Heads up: generalized NOTIFY messages are just one way to make automated delegation maintenance more efficient. Other options, like contacting the parent operator via an API or DNS Update [RFC2136], may or may not be a better fit in individual cases. Like generalized notifications, they also need a way to figure out where to send API or DNS Update requests. ⭐

Because the publication mechanism is meant for more than just generalized notifications, this section specifies one unified approach that works no matter which notification method you pick. 🌈

Parent operators who take part in the discovery scheme for delegation maintenance notifications MUST publish endpoint information using the record type defined in Section 2, 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 isn't needed, the parent can publish a static wildcard DSYNC record. 💖

3.1. Wildcard Method 🌸

Sometimes the parent operator does the CDS/CDNSKEY or CSYNC processing for some or all of its delegations, or wants to pass notifications along to someone else. For that, you can set a default notification target with a wildcard record, like this:

*._dsync.example.  IN DSYNC  CDS   NOTIFY port target
*._dsync.example.  IN DSYNC  CSYNC NOTIFY port target

Indirect delegation management models are a thing too, so the notification target can relay notifications to a third party. ICANN's model has the registrar doing this, for example 💅. How those arrangements actually work is out of scope for this document, so we're not going there today.

If the parent operator can't publish wildcard records for some reason, the wildcard label can be dropped from the DSYNC owner name and the record published at the _dsync label instead. Ngl, this one is NOT RECOMMENDED 🙈. It adds an extra step during discovery (see Section 4.1), which is a lot of extra work for something that could've been simple.

3.2. Child-specific Method 🦋

You can also publish child-specific records. The idea is that you strip the parent zone's labels off the child's Fully Qualified Domain Name (FQDN), and whatever is left gets used in place of the wildcard label. So cute, right? 🎀

Say a registrar is selling domains like child.example, which is delegated from the example zone. If the registrar provides the notification endpoint, something like rr-endpoint.example:5300, the parent can publish that information like this:

child._dsync.example.  IN DSYNC  CDS NOTIFY 5300 rr-endpoint.example.

4. Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications ✨

Okay so, delegation maintenance notifications are here to fix the inefficiencies that come with scanning child zones for CDS/CDNSKEY records [RFC7344] [RFC8078] [RFC9615]. Nobody wants to keep checking everything over and over, so this is a huge glow-up. (If you want the full tea on what's wrong with the old way, check out Appendix A 💜.)

NOTIFY messages for delegation maintenance MUST be formatted as described in [RFC1996], with the qtype field swapped out as appropriate. 💅

Now, the CDS/CDNSKEY dichotomy is a whole vibe. The NOTIFY(CDS) message, which is a NOTIFY with qtype=CDS, is defined to flag any child-side changes that are about to lead to an update of DS records 🔥. The thing is, the child DNS operator usually has no idea whether the parent side uses CDS records or prefers CDNSKEY, or whether that preference changes over time. So it seems like a smart move to publish both types of records, ideally with the automation features that most common authoritative nameserver software offers to keep them consistent ✨.

When the parent-side recipient (usually a registry or a registrar) gets a NOTIFY(CDS), it SHOULD run the same DNS lookups and verifications for DNSSEC bootstrapping [RFC9615] or DS maintenance [RFC7344] [RFC8078] that it would otherwise run on a timer. Basically, it skips the waiting 🧚.

CSYNC [RFC7477] has the same inefficiency, and it can be handled the same way. The child sends a NOTIFY(CSYNC) message, which is a NOTIFY with qtype=CSYNC, to an address where the parent operator (or someone they designate) is listening for CSYNC notifications 🌈.

Either way, the notification speeds things up by telling the recipient that a particular child zone has just published new CDS, CDNSKEY, and/or CSYNC records. It's a little hint that says "hey, go look now" 💖.

4.1. Endpoint Discovery 🔍

To find the target for outgoing delegation maintenance notifications, the notification sender MUST go through these steps:

  1. Build the lookup name by inserting the _dsync label after the first label of the delegation owner name.
  2. Do a lookup of type DSYNC for that lookup name, and validate the response if DNSSEC is enabled. If this gives you a positive DSYNC answer, return it 👑.
  3. If the query gave you a negative response:
    • If the response's SOA record shows that the parent is more than one label away from the _dsync label, build a new lookup name by inserting the _dsync label into the delegation owner name just before the parent zone labels you worked out from the negative response. Then go back to step 2.

Here's an example. Say subsub.sub.child.example is delegated from example (and not from sub.child.example or child.example). The first DSYNC query for it goes to subsub._dsync.sub.child.example. That's expected to come back negative from example, so you then need to query subsub.sub.child._dsync.example 🙈.

  • Otherwise, if the lookup name has any labels in front of the _dsync label, remove them to build a new lookup name, like _dsync.example. Then go back to step 2. (This is what makes zone structures without wildcards work ✨.)
  • Otherwise, return null, which means there's no notification target available 💀.

4.2. Sending Notifications 📬

When you create or change a CDS/CDNSKEY/CSYNC RRset in the child zone, the DNS operator SHOULD send a suitable notification to one of the endpoints found as described in Section 4.1. Send the notification to the right endpoint, bestie 🫶.

A NOTIFY message can only carry information about changes to one child zone. So when several child zones change, the sender MUST send a separate notification for each one. No cramming them together 🙅‍♀️.

Here's the timing problem. When a primary name server publishes a new RRset in the child, there's usually a delay before every publicly visible copy of the zone catches up. If the primary sends the notification at the exact moment of publication, CDS/CDNSKEY/CSYNC processing might run before the matching records are actually being served. Then the update can look inconsistent or go undetected, and it doesn't get applied. Oof 😭.

So, it is RECOMMENDED that the child would delay sending notifications to the recipient until it can make sure there's a consistent public view of the relevant records 🎀.

4.2.1. Timeouts and Error Handling ⏰

NOTIFY messages are expected to get a response from the recipient ([RFC1996], Section 4.7). If no response comes back, senders SHOULD use the same logic they'd use for SOA notifications ([RFC1996], Sections 3.5 and 3.6).

The recipient might fail to act on the delegation update request for all kinds of reasons. For example, it could break the continuity requirement in [RFC7344], Section 4.1. These failures can happen asynchronously, even after the NOTIFY response has already been sent 🥲.

If you want to find out about those failures, senders MAY include an EDNS0 Report-Channel option [RFC9567] in the NOTIFY message. That asks the receiving side to report any errors by making a report query with a suitable extended DNS error (EDE) code, as described in [RFC8914]. (The ban on this option in queries ([RFC9567], Section 6.1) only applies to resolver queries, so it doesn't cover NOTIFY messages. Good to know, right? 🤓)

When you include this EDNS0 option, the second label (QTYPE) of the report query name equals the qtype from the NOTIFY message. Its agent domain MUST be subordinate to, or equal to, one of the NS hostnames listed in the child's delegation in the parent zone. This is what keeps malicious senders from tricking the NOTIFY recipient into sending unsolicited report queries to random unrelated third parties. Major protection moment 🛡️✨.

For example, say a NOTIFY(CDS) message comes in for example.com with the agent domain errors.ns1.example.net. If the requested DS update turns out to break the delegation, 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

4.2.2. Roles 👯

The CDS/CDNSKEY/CSYNC processing that follows a NOTIFY will often be done by the registry. But the protocol expects that in some setups (especially for ICANN gTLDs), registrars might take that job over. In that case, the current registrar notification endpoint can be published, so notifications go to the right place 💜.

How registry and registrar sort out their arrangement is out of scope for this document. The protocol just makes it possible to set things up so that, from the child's point of view, it doesn't matter how the parent-side parties are organized. Notifications are simply sent to the published address. Iconic, honestly 👑.

There's also a security angle here that I think is kind of genius 🧠. A notification by itself never causes a change. It can only speed up the next check for the same thing. Because of that, the sender's identity isn't crucial. So an arbitrary party, like a service that's separate from a nameserver, can send the notifications. That means this works even before nameserver software has built-in support for it 🦋.

4.3. Processing of NOTIFY Messages for Delegation Maintenance 🧾

The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC) processing.

NOTIFY messages that carry notification payloads (records) for more than one child zone MUST be discarded, because sending them is an error 🚫.

Otherwise, when a (possibly forwarded) NOTIFY message for a particular child zone arrives at the published notification endpoint, the receiving side (the parent registry or registrar) has two options:

  1. Acknowledge receipt by sending a NOTIFY response as described in [RFC1996], 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 [RFC9567] with an agent domain that's subordinate to, or equal to, one of the NS hostnames listed in the delegation, the processing party SHOULD report any errors that happen during CDS/CDNSKEY/CSYNC processing. It does that by sending a report query with a suitable EDE code, as described in [RFC8914]. Reporting may be done asynchronously, which means outside of the NOTIFY transaction 📣.

When you're using periodic scanning, notifications preempt the scanning timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/CSYNC RRset really is new or has changed, the corresponding child's timer may be reset, and the scanning frequency can be reduced (for example, to once a week) 🐣. If a CDS/CDNSKEY/CSYNC change is detected later through scanning, without a notification having been received, the NOTIFY-related state SHOULD be cleared, and the child goes back to the default scanning schedule 🔄.

When CDS/CDNSKEY/CSYNC scanning support is introduced at the same time as NOTIFY support, backwards compatibility considerations about the scanning interval don't apply. So a low-frequency scanning schedule MAY be used by default in that case 🌙.

  1. Don't act on the notification. To prevent retries, recipients SHOULD acknowledge the notification by sending a NOTIFY response, even when they're ignoring the request. If it's feasible, combine that with a report query, as described above. One reason to do this might be a rate limit (see Section 5), and in that case, "Blocked" (15) may be a suitable extended DNS error code 🚧.

Going with the first option makes a big difference in convergence time, meaning the time between publishing a new CDS/CDNSKEY/CSYNC record in the child and publishing the resulting DS. That's a major win for the child 🏆.

And if you also modify the scanning schedule to be less frequent, on top of scheduling an immediate check for the child zone of the notification, the cost of providing the scanning service goes down too. Everyone wins, periodt 💖✨.

5. Security Considerations 🔐💀

Okay bestie, this is the serious part, so pay attention 🫶. If an action gets triggered by a DNS NOTIFY, it runs on the same security model the receiving party would use if something else triggered it. The notification only changes the timing ⏰. For example, DS bootstrapping works the same way no matter what triggered it, and that includes all the security and authentication requirements (e.g., [RFC9615]) that the parent registry/registrar has picked to apply. Iconic consistency 💅.

The original NOTIFY spec dodges most security drama by not trusting the info inside the NOTIFY message at all. It only uses it to "enter the state it would if the zone's refresh timer had expired" (Section 4.7 of [RFC1996]). Minimal trust, maximum vibes 🌸.

This same security model gets reused for generalized NOTIFY messages. So it seems impossible to change how the recipient behaves, except by speeding up when the different checks kick off ⚡. As a result, notifications can be locked down with access control mechanisms, but that's not a requirement 🙈.

When a notification arrives, the receiving party will usually send one or more outbound queries for the records it cares about. For example, NOTIFY(CDS) will cause CDS/CDNSKEY queries 🔍. When this happens over standard DNS, the size of those queries is comparable to the NOTIFY messages themselves, so any amplification attempts are totally futile 🙅‍♀️. The number of queries triggered per notification is also capped, because a NOTIFY message can refer to one child only 🧸.

BUT (and this is a big but 😭), when the outgoing query goes over encrypted transport, some amplification is possible, both for bandwidth and for computational burden. In that case, the usual principle of bounding the work still applies, even when unforeseen events happen 🛡️.

So, 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 helps with the processing load from garbage notifications 🗑️.

Alternative solutions, like signing notifications and validating their signatures, appear significantly more expensive without any tangible benefit 💸.

Heads up 👀: To make room for schemes that are authenticated outside of DNSSEC (such as via SIG(0)), zones containing DSYNC records are not required to be signed.

Here's the tea ☕. Spoofed DSYNC responses would stop notifications from reaching their legitimate target, and a different party may get unsolicited notifications. BUT both of those effects can also happen when DNSSEC is in the picture, so it's not a DNSSEC-only problem 🤷‍♀️. The illegitimate target can also learn notification contents in real time, which may be a privacy concern for the sender 🕵️. If that's a worry, the sender may choose to ignore unsigned DSYNC records 🔒.

6. IANA Considerations 🗂️

6.1. DSYNC RR Type 🧾

IANA has registered DSYNC in the "Resource Record (RR) TYPEs" registry under the "Domain Name System (DNS) Parameters" registry group, like this:

Type:  DSYNC
Value:  66
Meaning:  Endpoint discovery for delegation synchronization
Reference:  RFC 9859

6.2. DSYNC Scheme Registration 🎀

IANA has created a brand 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 of the registry look like this 👇:

+========+===================+==========================+===========+
| 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     | RFC 9859  |
|        |                   | Use                      |           |
+--------+-------------------+--------------------------+-----------+

                                  Table 1

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 [RFC8126]. Expert Reviewers should take the points below into consideration. They're experts though, so they should be given substantial latitude 🧐✨:

  • Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests, so they can make sure the usage won't duplicate one that's 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 🔔.

6.3. _dsync Underscore Name 🌈

Per [RFC8552], IANA has registered the following entry in 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  |
+---------+------------+-----------+

                                 Table 2

7. References 📚

7.1. Normative References 💜

7.2. Informative References 🦋

Appendix A. Efficiency and Convergence Issues in DNS Scanning ✨

A.1. Original NOTIFY for Zone Transfer Nudging

okay so [RFC1996] is the one that introduced the DNS NOTIFY message 💌, and it was a whole glow-up for secondary servers! 🦋 The goal was to speed up convergence when a zone got updated on the primary. The basic idea was to keep the original "pull" mechanism (a periodic SOA query 🔍) and add a "push" mechanism (a NOTIFY 📣) for a common case that was otherwise super inefficient. Either the updates arrived really slowly, or the secondary was wastefully and overly frequently scanning 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. [RFC1996] addressed the time-and-cost trade-off between a secondary server frequently checking for new versions of a zone and infrequent checks. It did this by replacing scheduled scanning with the more efficient NOTIFY mechanism 🧠✨.

A.2. Similar Issues for DS Maintenance and Beyond

Today we have similar issues with slow updates of DNS data even though the data has already been published 🌸. The two most obvious cases are CDS and CSYNC scanners, which are 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 between two scanning runs 🤏. However, frequent scanning for CDS and CDNSKEY records is costly 💸, and infrequent scanning causes slower convergence (i.e., the delay until the DS RRset is updated) 😩.

Unlike 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 [RFC7477] 🔁. Again, given that CSYNC records change only rarely, frequent scanning of a large number of delegations seems disproportionately costly. Meanwhile, infrequent scanning causes slower convergence (the delay until the delegation is updated) 🕒.

While use of the NOTIFY mechanism for coordinating the key exchange in multi-signer setups [RFC8901] 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): 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, and Oli Schacher 🌟👑.

Authors' Addresses 💌

Johan Stenstam
The Swedish Internet Foundation
Email: johan.stenstam@internetstiftelsen.se


Peter Thomassen
deSEC, Secure Systems Engineering
Email: peter@desec.io


John Levine
Standcore LLC
Email: standards@standcore.com
📦 where this page comes from