Generalized DNS Notifications
Extracted elements (29)
Notifications do not carry authoritative data and cannot alter the action they trigger. This design allows the sender's identity to be non-crucial, enabling arbitrary third-party services (not just nameservers) to send notifications, facilitating adoption before native nameserver support is widespread.
NOTIFY(CDS) is defined to represent any child-side DS-related change (covering both CDS and CDNSKEY records) because the child DNS operator generally is unaware of whether the parent consumes CDS or CDNSKEY, and that preference may change over time. Publishing both record types is advisable.
The endpoint discovery mechanism is parameterized by the child name so that the lookup process is ignorant of parent-side relationships (e.g., whether a registrar is involved). The parent publishes notification endpoints in a delegation-specific way under _dsync, allowing senders to locate the correct endpoint with a single lookup without needing to know the internal structure of the parent operation.
Generalized NOTIFY messages are formatted identically to RFC 1996 NOTIFY messages, with only the qtype field changed (CDS or CSYNC instead of SOA). This reuse of the existing wire format and transport means no DNS protocol changes are required.
A NOTIFY message can only carry information about changes for one child zone; when multiple child zones change, the sender MUST send a separate notification for each one.
If no response to a NOTIFY message is received, senders SHOULD employ the same retry logic as for SOA notifications per RFC 1996 Sections 3.5 and 3.6.
It is RECOMMENDED that the child delay sending notifications until a consistent public view of the pertinent records can be ensured, to avoid the parent attempting CDS/CDNSKEY/CSYNC processing before records are fully propagated.
NOTIFY messages carrying notification payloads for more than one child zone MUST be discarded, as sending them is an error.
NOTIFY messages for delegation maintenance MUST be formatted as described in RFC 1996, with the qtype field replaced as appropriate (CDS for DS-related updates, CSYNC for NS/glue updates).
Parent operators participating in delegation maintenance notifications MUST publish endpoint information using the DSYNC record type under the _dsync subdomain of the parent zone.
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 conveyed in the NOTIFY message.
The agent domain in an EDNS0 Report-Channel option carried in a NOTIFY message MUST be subordinate or equal to one of the NS hostnames listed in the child's delegation in the parent zone.
The Target field in a DSYNC record MUST resolve to one or more address records. Records with Scheme value 0 (null) or Port value 0 are ignored by consumers.
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.
Upon receipt of a NOTIFY(CDS), the parent-side recipient SHOULD initiate the same DNS lookups and verifications for DNSSEC bootstrapping or DS maintenance that would otherwise be triggered by a timer.
Spoofed DSYNC responses can redirect notifications to an illegitimate party, who may then learn notification contents (e.g., child zone name and publication time) in real time. Senders concerned about this privacy risk MAY choose to ignore unsigned DSYNC records.
Senders MAY include an EDNS0 Report-Channel option (RFC 9567) in the NOTIFY message to request error reporting via extended DNS error (EDE) codes (RFC 8914). The agent domain in this option MUST be subordinate to or equal to one of the NS hostnames listed in the child's delegation, preventing unsolicited queries to unrelated third parties.
The child-specific method allows per-delegation DSYNC records published at <child-label>._dsync.<parent-zone>, enabling registrars or other parties to receive notifications for specific child zones at different endpoints.
The DSYNC record type carries four fields: RRtype (the notification type, currently CDS or CSYNC), Scheme (the contact method, currently only value 1 = NOTIFY), Port (the transport port), and Target (the hostname listening for notifications). Scheme 1 (NOTIFY) instructs child operators to send a DNS NOTIFY message upon publishing new CDS/CDNSKEY/CSYNC RRsets.
The wildcard method allows a parent operator to publish a default notification endpoint via wildcard records at *._dsync.example for CDS and CSYNC types respectively. If wildcards cannot be published, the _dsync label itself may be used (without wildcard), though this is NOT RECOMMENDED as it requires an extra discovery step.
Upon receipt of a valid NOTIFY, the parent may: (1) acknowledge and schedule an immediate check of CDS/CDNSKEY/CSYNC RRsets (and optionally reduce subsequent scanning frequency), or (2) acknowledge the notification without acting on it (e.g., due to rate limiting). Recipients SHOULD always send a NOTIFY response to prevent retries even when ignoring the notification.
IANA created the 'DSYNC: Location of Synchronization Endpoints' registry under 'Domain Name System (DNS) Parameters', with Expert Review procedure. Initial entries include scheme 0 (null/no-op), scheme 1 (NOTIFY) for CDS and CSYNC delegation management, schemes 2–127 (unassigned), and 128–255 (Private Use).
IANA registered '_dsync' in the 'Underscored and Globally Scoped DNS Node Names' registry (per RFC 8552), associated with the DSYNC RR type, referencing RFC 9859.
IANA registered DSYNC with RR type value 66 in the 'Resource Record (RR) TYPEs' registry under 'Domain Name System (DNS) Parameters', with meaning 'Endpoint discovery for delegation synchronization'.
Because signing NOTIFY messages was deemed significantly more expensive without tangible benefit, the protocol does not require it. Access control mechanisms are an option but not a requirement, since a spoofed or misdirected notification can only affect timing.
The generalized NOTIFY security model reuses that of RFC 1996: a notification only affects the timing of an action; all security and authentication requirements applied to the action itself (e.g., RFC 9615 for DNSSEC bootstrapping) remain unchanged. This makes it impossible for a notification alone to alter the behavior of the recipient beyond hastening when checks occur.
When outgoing queries triggered by a NOTIFY use encrypted transport, amplification is possible in both bandwidth and computation. The usual principle of bounding the work applies; rate limiting (MUST) is the primary mitigation. The one-child-per-NOTIFY requirement also limits the number of queries triggered per notification.
Endpoint discovery proceeds as follows: (1) insert the _dsync label after the first label of the delegation owner name and query DSYNC; (2) on positive answer, return it; (3) on negative response, if the parent is more than one label away from _dsync, reconstruct the name placing _dsync just before the parent zone labels and retry; (4) otherwise strip labels in front of _dsync (e.g., _dsync.example) and retry; (5) otherwise return null.
The DSYNC RDATA wire format consists of a 16-bit RRtype field, an 8-bit Scheme field, a 16-bit Port field (network byte order), and a variable-length Target field containing a fully-qualified, uncompressed domain name.