rfc9859.original   rfc9859.txt 
DNSOP Working Group J. Stenstam Internet Engineering Task Force (IETF) J. Stenstam
Internet-Draft The Swedish Internet Foundation Request for Comments: 9859 The Swedish Internet Foundation
Intended status: Standards Track P. Thomassen Category: Standards Track P. Thomassen
Expires: 20 September 2025 deSEC, Secure Systems Engineering ISSN: 2070-1721 deSEC, Secure Systems Engineering
J. Levine J. Levine
Standcore LLC Standcore LLC
19 March 2025 September 2025
Generalized DNS Notifications Generalized DNS Notifications
draft-ietf-dnsop-generalized-notify-09
Abstract Abstract
This document generalizes and extends the use of DNS NOTIFY (RFC This document generalizes and extends the use of DNS NOTIFY (RFC
1996) beyond conventional zone transfer hints, to allow triggering 1996) beyond conventional zone transfer hints to allow other types of
other types of actions via the DNS that were previously lacking a actions that were previously lacking a trigger mechanism to be
trigger mechanism. Notifications merely nudge the receiver to triggered via the DNS. Notifications merely nudge the receiver to
initiate a predefined action promptly (instead of on a schedule); initiate a predefined action promptly (instead of on a schedule);
they do not alter the action itself (including any security checks it they do not alter the action itself (including any security checks it
might employ). might employ).
To enable this functionality, a method for discovering the receiver To enable this functionality, a method for discovering the receiver
endpoint for such notification messages is introduced, via the new endpoint for such notification messages is introduced, via the new
DSYNC record type. Notification types are recorded in a new DSYNC record type. Notification types are recorded in a new
registry, with initial support for parental NS and DS record updates registry, with initial support for parental NS and DS record updates
including DNSSEC bootstrapping. including DNSSEC bootstrapping.
TO BE REMOVED: This document is being collaborated on in Github at:
https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify
(https://github.com/peterthomassen/draft-ietf-dnsop-generalized-
notify). The most recent working version of the document, open
issues, etc. should all be available there. The authors (gratefully)
accept pull requests.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 20 September 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9859.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Design Goals for Delegation Maintenance . . . . . . . . . 3 1.1. Design Goals for Delegation Maintenance
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Notation
2. DSYNC RR Type . . . . . . . . . . . . . . . . . . . . . . . . 4 2. DSYNC RR Type
2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Wire Format
2.2. Presentation Format . . . . . . . . . . . . . . . . . . . 5 2.2. Presentation Format
2.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Semantics
3. Publication of Notification Targets . . . . . . . . . . . . . 6 3. Publication of Notification Targets
3.1. Wildcard Method . . . . . . . . . . . . . . . . . . . . . 6 3.1. Wildcard Method
3.2. Child-specific Method . . . . . . . . . . . . . . . . . . 7 3.2. Child-specific Method
4. Delegation Maintenance: CDS/CDNSKEY and CSYNC 4. Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications
Notifications . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Endpoint Discovery
4.1. Endpoint Discovery . . . . . . . . . . . . . . . . . . . 8 4.2. Sending Notifications
4.2. Sending Notifications . . . . . . . . . . . . . . . . . . 9 4.2.1. Timeouts and Error Handling
4.2.1. Timeouts and Error Handling . . . . . . . . . . . . . 9 4.2.2. Roles
4.2.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Processing of NOTIFY Messages for Delegation Maintenance
4.3. Processing of NOTIFY Messages for Delegation 5. Security Considerations
Maintenance . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. DSYNC RR Type
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.2. DSYNC Scheme Registration
6.1. DSYNC RR Type . . . . . . . . . . . . . . . . . . . . . . 13 6.3. _dsync Underscore Name
6.2. DSYNC Scheme Registration . . . . . . . . . . . . . . . . 13 7. References
6.3. _dsync Underscore Name . . . . . . . . . . . . . . . . . 14 7.1. Normative References
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References
7.1. Child DNS Operator-side . . . . . . . . . . . . . . . . . 15 Appendix A. Efficiency and Convergence Issues in DNS Scanning
7.2. Parent-side . . . . . . . . . . . . . . . . . . . . . . . 15 A.1. Original NOTIFY for Zone Transfer Nudging
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 A.2. Similar Issues for DS Maintenance and Beyond
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgements
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Efficiency and Convergence Issues in DNS Scanning . 17
A.1. Original NOTIFY for Zone Transfer Nudging . . . . . . . . 17
A.2. Similar Issues for DS Maintenance and Beyond . . . . . . 18
Appendix B. Change History (to be removed before publication) . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Traditional DNS notifications [RFC1996], which are here referred to The original DNS notifications [RFC1996], which are here referred to
as "NOTIFY(SOA)", are sent from a primary server to a secondary 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 server to minimize the latter's convergence time to a new version of
the zone. This mechanism successfully addresses a significant the zone. This mechanism successfully addresses a significant
inefficiency in the original protocol. inefficiency in the original protocol.
Today similar inefficiencies occur in new use cases, in particular Today, similar inefficiencies occur in new use cases, in particular
delegation maintenance (DS and NS record updates). Just as in the delegation maintenance (DS and NS record updates). Just as in the
NOTIFY(SOA) case, a new set of notification types will have a major NOTIFY(SOA) case, a new set of notification types will have a major
positive benefit by allowing the DNS infrastructure to completely positive benefit by allowing the DNS infrastructure to completely
sidestep these inefficiencies. For additional context, see sidestep these inefficiencies. For additional context, see
Appendix A. Appendix A.
Although this document primarily deals with applying generalized Although this document primarily deals with applying generalized
notifications to the delegation maintenance use case, future notifications to the delegation maintenance use case, future
extension for other applications (such as multi-signer key exchange) extension for other applications (such as multi-signer key exchange)
is possible. is possible.
No DNS protocol changes are introduced by this document. The No DNS protocol changes are introduced by this document. Instead,
mechanism instead makes use of a wider range of DNS messages allowed the mechanism makes use of a wider range of DNS messages allowed by
by the protocol. the protocol.
Readers are expected to be familiar with DNSSEC [RFC9364], including Readers are expected to be familiar with DNSSEC [RFC9364], including
[RFC6781], [RFC7344], [RFC7477], [RFC7583], [RFC8078], [RFC8901], and [RFC6781], [RFC7344], [RFC7477], [RFC7583], [RFC8078], [RFC8901], and
[RFC9615]. DNS-specific terminology can be found in [RFC9499]. [RFC9615]. DNS-specific terminology can be found in [RFC9499].
1.1. Design Goals for Delegation Maintenance 1.1. Design Goals for Delegation Maintenance
When the parent operator is interested in notifications for When the parent operator is interested in notifications for
delegation maintenance (such as DS or NS update hints), a service delegation maintenance (such as DS or NS update hints), a service to
will need to be made available for accepting these notifications. accept these notifications will need to be made available. Depending
Depending on the context, this service may be run by the parent on the context, this service may be run by the parent operator or by
operator themselves, or by a designated entity who is in charge of a designated entity who is in charge of handling the domain's
handling the domain's delegation data (such as a domain registrar). delegation data (such as a domain registrar).
It seems desirable to minimize the number of steps that the It seems desirable to minimize the number of steps that the
notification sender needs to perform in order to figure out where to notification sender needs to perform in order to figure out where to
send the NOTIFY. This suggests that the lookup process be ignorant send the NOTIFY. This suggests that the lookup process be ignorant
of the details of the parent-side relationships (e.g., whether there of the details of the parent-side relationships (e.g., whether or not
is a registrar or not). This is addressed by parameterizing the there is a registrar). This is addressed by parameterizing the
lookup with the name of the child. The parent operator may then lookup with the name of the child. The parent operator may then
(optionally) announce the notification endpoint in a delegation- announce the notification endpoint in a delegation-specific way by
specific way, by publishing it at a child-specific name. (A catch- publishing it at a child-specific name. (A catch-all endpoint may be
all endpoint may be indicated by wildcarding.) indicated by wildcarding.)
The solution proposed here is thus for the parent operator to publish The solution specified here is thus for the parent operator to
the address where someone listens for notifications, in a child- publish the address where someone listens for notifications, in a
specific way (see Section 3). Potential senders can easily determine child-specific way (see Section 3). Potential senders can easily
the name of the parent and then look up that information (see determine the name of the parent and then look up that information
Section 4.1). (see Section 4.1).
1.2. Requirements Notation 1.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. DSYNC RR Type 2. DSYNC RR Type
This section defines the DSYNC RR type which is subsequently used for This section defines the DSYNC RR type, which is subsequently used
discovering notification endpoints. for discovering notification endpoints.
2.1. Wire Format 2.1. Wire Format
The DSYNC RDATA wire format is encoded as follows: 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 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 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 | RRtype | Scheme | Port
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target ... / | Target ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
RRtype The type of generalized NOTIFY that this DSYNC RR defines the Figure 1: DSYNC RDATA Wire Format
desired target address for (see "Resource Record (RR) TYPEs" IANA
registry). 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 RRtype: 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,
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 address. This is an 8-bit unsigned integer. Records with value 0
(null scheme) are ignored by consumers. Value 1 is described in (null scheme) are ignored by consumers. Value 1 is described in
this document, and values 128-255 are reserved for private use. this document, and values 128-255 are Reserved for Private Use.
All other values are currently unassigned. Other values are currently unassigned. Future assignments are
maintained in the registry created in Section 6.2.
Port The port on the target host of the notification service. This Port: The transport port number on the target host of the
is a 16-bit unsigned integer in network byte order. Records with notification service. This is a 16-bit unsigned integer in
value 0 are ignored by consumers. network byte order. Records with value 0 are ignored by
consumers.
Target The fully-qualified, uncompressed domain name of the target Target: The fully-qualified, uncompressed domain name of the target
host providing the service of listening for generalized host providing the service of listening for generalized
notifications of the specified type. This name MUST resolve to notifications of the specified type. This name MUST resolve to
one or more address records. one or more address records.
2.2. Presentation Format 2.2. Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
* The RRtype field is represented as a mnemonic from the "Resource * The RRtype field is represented as a mnemonic from the "Resource
Record (RR) TYPEs" registry. Record (RR) TYPEs" registry.
* The Scheme field is represented by its mnemonic if assigned (see * The Scheme field is represented by its mnemonic if assigned (see
Section 6.2), otherwise as an unsigned decimal integer. Section 6.2), and is otherwise represented as an unsigned decimal
integer.
* The Port field is 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> ([RFC1035], * The Target field is represented as a <domain-name> (Section 5.1 of
Section 5.1). [RFC1035]).
2.3. Semantics 2.3. Semantics
For now, the only scheme defined is 1 (mnemonic: NOTIFY). By For now, the only scheme defined is 1 (mnemonic: NOTIFY). By
publishing a DSYNC record with this scheme, a parent indicates that publishing a DSYNC record with this scheme, a parent indicates that
they would like child operators to send them a NOTIFY message (see they would like child operators to send them a NOTIFY message (see
Section 4) upon publication of a new CDS/CDNSKEY/CSYNC RRset, to the Section 4) upon publication of a new CDS/CDNSKEY/CSYNC RRset to the
address and port listed in that DSYNC record and using conventional address and port number that correspond to that DSYNC record, using
[RFC1035] DNS transport. conventional DNS transport [RFC1035].
Example (for the owner names of these records, see Section 3): Example (for the owner names of these records, see Section 3):
IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net. IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net.
IN DSYNC CSYNC NOTIFY 5360 csync-scanner.example.net. IN DSYNC CSYNC NOTIFY 5360 csync-scanner.example.net.
Should a need for other mechanisms arise, other schemes may be Should a need for other mechanisms arise, other schemes may be
defined to deal with such requirements using alternative logic. defined to deal with such requirements using alternative logic.
Schemes are independent of RRtype. They merely specify a method of Schemes are independent of the RRtype. They merely specify a method
contacting the target (whereas the RRtype is part of the notification of contacting the target (whereas the RRtype is part of the
payload). notification payload).
3. Publication of Notification Targets 3. Publication of Notification Targets
To use generalized notifications, it is necessary for the sender to To use generalized notifications, it is necessary for the sender to
know where to direct each NOTIFY message. This section describes the know where to direct each NOTIFY message. This section describes the
procedure for discovering that notification target. procedure for discovering that notification target.
Note that generalized NOTIFY messages are but one mechanism for Note that generalized NOTIFY messages are but one mechanism for
improving the efficiency of automated delegation maintenance. Other improving the efficiency of automated delegation maintenance. Other
alternatives, such as contacting the parent operator via an API or alternatives, such as contacting the parent operator via an API or
DNS Update ([RFC2136]), may (or may not) be more suitable in DNS Update [RFC2136], may (or may not) be more suitable in individual
individual cases. Like generalized notifications, they similarly cases. Like generalized notifications, they similarly require a
require a means for discovering where to send the API or DNS Update means for discovering where to send the API or DNS Update requests.
requests.
As the scope for the publication mechanism is wider than only to As the scope for the publication mechanism is wider than only to
support generalized notifications, a unified approach that works support generalized notifications, a unified approach that works
independently of the notification method is specified in this independently of the notification method is specified in this
section. section.
Parent operators participating in the discovery scheme for the Parent operators participating in the discovery scheme for the
purpose of delegation maintenance notifications MUST publish endpoint purpose of delegation maintenance notifications MUST publish endpoint
information using the record type defined in Section 2 under the information using the record type defined in Section 2 under the
_dsync subdomain of the parent zone, as described in the following _dsync subdomain of the parent zone, as described in the following
subsections. subsections.
There MUST NOT be more than one DSYNC record for each combination of There MUST NOT be more than one DSYNC record for each combination of
RRtype and Scheme. It is RECOMMENDED to secure zones containing RRtype and Scheme. It is RECOMMENDED that zones containing DSYNC
DSYNC records with DNSSEC. records be secured with DNSSEC.
For practical purposes, the parent operator MAY delegate the _dsync For practical purposes, the parent operator MAY delegate the _dsync
domain as a separate zone, and/or synthesize records under it. If domain as a separate zone and/or synthesize records under it. If
child-specificity is not needed, the parent can publish a static child-specificity is not needed, the parent can publish a static
wildcard DSYNC record. wildcard DSYNC record.
3.1. Wildcard Method 3.1. Wildcard Method
If the parent operator itself performs CDS/CDNSKEY or CSYNC If the parent operator itself performs CDS/CDNSKEY or CSYNC
processing for some or all delegations, or wants to forward processing for some or all delegations, or if the parent operator
notifications to some other party, a default notification target may wants to relay notifications to some other party, a default
be specified as follows: notification target may be specified as follows:
*._dsync.example. IN DSYNC CDS NOTIFY port target *._dsync.example. IN DSYNC CDS NOTIFY port target
*._dsync.example. IN DSYNC CSYNC NOTIFY port target *._dsync.example. IN DSYNC CSYNC NOTIFY port target
To accommodate indirect delegation management models, the designated To accommodate indirect delegation management models, the designated
notification target may relay notifications to a third party (such as notification target may relay notifications to a third party (such as
the registrar, in ICANN's model). The details of such arrangements the registrar, in ICANN's model). The details of such arrangements
are out of scope for this document. are out of scope for this document.
If for some reason the parent operator cannot publish wildcard If for some reason the parent operator cannot publish wildcard
records, the wildcard label may be dropped from the DSYNC owner name records, the wildcard label may be dropped from the DSYNC owner name
(i.e., it may be published at the _dsync label instead). This (i.e., it may be published at the _dsync label instead). This
practice requires an additional step during discovery (see practice requires an additional step during discovery (see
Section 4.1), and is therefore NOT RECOMMENDED. Section 4.1) and is therefore NOT RECOMMENDED.
3.2. Child-specific Method 3.2. Child-specific Method
It is also possible to publish child-specific records where the It is also possible to publish child-specific records where the
parent zone's labels are stripped from the child's FQDN and the parent zone's labels are stripped from the child's Fully Qualified
result is used in place of the wildcard label. Domain Name (FQDN), and the result is used in place of the wildcard
label.
As an example, consider a registrar offering domains like As an example, consider a registrar offering domains like
child.example, delegated from example zone. If the registrar child.example, delegated from example zone. If the registrar
provides the notification endpoint, e.g., rr-endpoint.example:5300, provides the notification endpoint, e.g., rr-endpoint.example:5300,
the parent may publish this information as follows: the parent may publish this information as follows:
child._dsync.example. IN DSYNC CDS NOTIFY 5300 rr-endpoint.example. child._dsync.example. IN DSYNC CDS NOTIFY 5300 rr-endpoint.example.
4. Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications 4. Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications
Delegation maintenance notifications address the inefficiencies Delegation maintenance notifications address the inefficiencies
related to scanning child zones for CDS/CDNSKEY records related to scanning child zones for CDS/CDNSKEY records [RFC7344]
[RFC7344][RFC8078][RFC9615]. (For an overview of the issues, see [RFC8078] [RFC9615]. (For an overview of the issues, see
Appendix A.) Appendix A.)
NOTIFY messages for delegation maintenance MUST be formatted as NOTIFY messages for delegation maintenance MUST be formatted as
described in [RFC1996], with the qtype field replaced as appropriate. described in [RFC1996], with the qtype field replaced as appropriate.
To address the CDS/CDNSKEY dichotomy, the NOTIFY(CDS) message (with To address the CDS/CDNSKEY dichotomy, the NOTIFY(CDS) message (with
qtype=CDS) is defined to indicate any child-side changes pertaining qtype=CDS) is defined to indicate any child-side changes pertaining
to an upcoming update of DS records. As the child DNS operator to an upcoming update of DS records. As the child DNS operator
generally is unaware of whether the parent side consumes CDS records generally is unaware of whether the parent side consumes CDS records
or prefers CDNSKEY, or when that policy changes, it seems advisable or prefers CDNSKEY, or when that policy changes, it seems advisable
to publish both types of records, preferably using automation to publish both types of records, preferably using automation
features of common authoritative nameserver software for ensuring features of common authoritative nameserver software for ensuring
consistency. consistency.
Upon receipt of NOTIFY(CDS), the parent-side recipient (typically, Upon receipt of NOTIFY(CDS), the parent-side recipient (typically,
registry or registrar) SHOULD initiate the same DNS lookups and registry or registrar) SHOULD initiate the same DNS lookups and
verifications for DNSSEC bootstrapping [RFC9615] or DS maintenance verifications for DNSSEC bootstrapping [RFC9615] or DS maintenance
[RFC7344][RFC8078] that would otherwise be triggered based on a [RFC7344] [RFC8078] that would otherwise be triggered based on a
timer. timer.
The CSYNC [RFC7477] inefficiency may be similarly treated, with the The CSYNC [RFC7477] inefficiency may be similarly treated, with the
child sending a NOTIFY(CSYNC) message (with qtype=CSYNC) to an child sending a NOTIFY(CSYNC) message (with qtype=CSYNC) to an
address where the parent operator (or a designated party) is address where the parent operator (or a designated party) is
listening for CSYNC notifications. listening for CSYNC notifications.
In both cases the notification will speed up processing times by In both cases, the notification will speed up processing times by
providing the recipient with a hint that a particular child zone has providing the recipient with a hint that a particular child zone has
published new CDS, CDNSKEY and/or CSYNC records. published new CDS, CDNSKEY, and/or CSYNC records.
4.1. Endpoint Discovery 4.1. Endpoint Discovery
To locate the target for outgoing delegation maintenance To locate the target for outgoing delegation maintenance
notifications, the notification sender MUST perform the following notifications, the notification sender MUST perform the following
steps: steps:
1. Construct the lookup name, by inserting the _dsync label after 1. Construct the lookup name by inserting the _dsync label after the
the first label of the delegation owner name. first label of the delegation owner name.
2. Perform a lookup of type DSYNC for the lookup name, and validate 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 the response if DNSSEC is enabled. If this results in a positive
DSYNC answer, return it. DSYNC answer, return it.
3. If the query resulted in a negative response: 3. If the query resulted in a negative response:
* If the response's SOA record indicates that the parent is more * If the response's SOA record indicates that the parent is more
than one label away from the _dsync label, construct a new than one label away from the _dsync label, construct a new
lookup name by inserting the _dsync label into the delegation lookup name by inserting the _dsync label into the delegation
owner name just before the parent zone labels inferred from owner name just before the parent zone labels inferred from
the negative response, and go to step 2. the negative response. Then go to step 2.
For example, assume that subsub.sub.child.example is delegated For example, assume that subsub.sub.child.example is delegated
from example (and not from sub.child.example or from example (and not from sub.child.example or
child.example). The initial DSYNC query relating to it is child.example). The initial DSYNC query relating to it is
thus directed at subsub._dsync.sub.child.example. This is thus directed at subsub._dsync.sub.child.example. This is
expected to result in a negative response from example, and expected to result in a negative response from example, and
another query for subsub.sub.child._dsync.example is then another query for subsub.sub.child._dsync.example is then
required. required.
* Otherwise, if the lookup name has any labels in front of the * Otherwise, if the lookup name has any labels in front of the
_dsync label, remove them to construct a new lookup name (such _dsync label, remove them to construct a new lookup name (such
as _dsync.example), and go to step 2. (This is to enable zone as _dsync.example). Then go to step 2. (This is to enable
structures without wildcards.) zone structures without wildcards.)
* Otherwise, return null (no notification target available). * Otherwise, return null (no notification target available).
4.2. Sending Notifications 4.2. Sending Notifications
When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child
zone, the DNS operator SHOULD send a suitable notification to one of zone, the DNS operator SHOULD send a suitable notification to one of
the endpoints discovered as described in the previous section. the endpoints discovered as described in Section 4.1.
A NOTIFY message can only carry information about changes concerning A NOTIFY message can only carry information about changes concerning
one child zone. When there are changes to several child zones, the one child zone. When there are changes to several child zones, the
sender MUST send a separate notification for each one. sender MUST send a separate notification for each one.
When a primary name server publishes a new RRset in the child, there 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 typically is a time delay until all publicly visible copies of the
zone are updated. If the primary sends a notification at the exact zone are updated. If the primary sends a notification at the exact
time of publication, there is a potential for CDS/CDNSKEY/CSYNC time of publication, there is a potential for CDS/CDNSKEY/CSYNC
processing to be attempted before the corresponding records are processing to be attempted before the corresponding records are
served. As a result, a desired update may not be detected (or appear served. As a result, a desired update may not be detected (or appear
inconsistent), preventing it from being applied. inconsistent), preventing it from being applied.
It is therefore RECOMMENDED that the child delays sending Therefore, it is RECOMMENDED that the child would delay sending
notifications to the recipient until a consistent public view of the notifications to the recipient until a consistent public view of the
pertinent records is ensured. pertinent records could be ensured.
4.2.1. Timeouts and Error Handling 4.2.1. Timeouts and Error Handling
NOTIFY messages are expected to elicit a response from the recipient NOTIFY messages are expected to elicit a response from the recipient
([RFC1996] Section 4.7). If no response is received, senders SHOULD ([RFC1996], Section 4.7). If no response is received, senders SHOULD
employ the same logic as for SOA notifications ([RFC1996] Sections employ the same logic as for SOA notifications ([RFC1996], Sections
3.5 and 3.6). 3.5 and 3.6).
The recipient's attempt to act upon the delegation update request may 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 fail for a variety of reasons (e.g., due to violation of the
continuity requirement set forth in [RFC7344] Section 4.1). Such continuity requirement set forth in [RFC7344], Section 4.1). Such
failures may occur asynchronously, even after the NOTIFY response has failures may occur asynchronously, even after the NOTIFY response has
been sent. been sent.
In order to learn about such failures, senders MAY include an In order to learn about such failures, senders MAY include an EDNS0
[RFC9567] EDNS0 Report-Channel option in the NOTIFY message to Report-Channel option [RFC9567] in the NOTIFY message to request that
request the receiving side to report any errors by making a report the receiving side report any errors by making a report query with an
query with an appropriate extended DNS error code as described in appropriate extended DNS error (EDE) code as described in [RFC8914].
[RFC8914]. (The prohibition of this option in queries ([RFC9567], (The prohibition of this option in queries ([RFC9567], Section 6.1)
Section 6.1) only applies to resolver queries and thus does not cover only applies to resolver queries and thus does not cover NOTIFY
NOTIFY messages.) messages.)
When including this EDNS0 option, its agent domain MUST be When including this EDNS0 option, the second label (QTYPE) of the
subordinate or equal to one of the NS hostnames, as listed in the report query name is equal to the qtype received in the NOTIFY
child's delegation in the parent zone. This is to prevent malicious message. Its agent domain MUST be subordinate or equal to one of the
senders from causing the NOTIFY recipient to send unsolicited report NS hostnames, as listed in the child's delegation in the parent zone.
queries to unrelated third parties. 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
4.2.2. Roles 4.2.2. Roles
While the CDS/CDNSKEY/CSYNC processing following the receipt of a While the CDS/CDNSKEY/CSYNC processing that follows the receipt of a
NOTIFY will often be performed by the registry, the protocol NOTIFY will often be performed by the registry, the protocol
anticipates that in some contexts (especially for ICANN gTLDs), anticipates that in some contexts (especially for ICANN gTLDs)
registrars may take on the task. In such cases, the current registrars may take on the task. In such cases, the current
registrar notification endpoint may be published, enabling registrar notification endpoint may be published, enabling
notifications to be directed to the appropriate target. The notifications to be directed to the appropriate target. The
mechanics of how this is arranged between registry and registrar are mechanics of how this is arranged between registry and registrar are
out of scope for this document; the protocol only offers the out of scope for this document; the protocol only offers the
possibility to arrange things such that from the child perspective, possibility to arrange things such that from the child perspective,
it is inconsequential how the parent-side parties are organized: how the parent-side parties are organized is inconsequential:
notifications are simply sent to the published address. Notifications are simply sent to the published address.
Because of the security model where a notification by itself never 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 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 for the same thing), the sender's identity is not crucial. This
opens up the possibility of having an arbitrary party (e.g., a side- opens up the possibility of having an arbitrary party (e.g., a
car service) send the notifications, enabling this functionality even service separate from a nameserver) send the notifications, enabling
before the emergence of native support in nameserver software. this functionality even before the emergence of built-in support in
nameserver software.
4.3. Processing of NOTIFY Messages for Delegation Maintenance 4.3. Processing of NOTIFY Messages for Delegation Maintenance
The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC) The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC)
processing. processing.
NOTIFY messages carrying notification payloads (records) for more NOTIFY messages carrying notification payloads (records) for more
than one child zone MUST be discarded, as sending them is an error. than one child zone MUST be discarded, as sending them is an error.
Otherwise, upon receipt of a (potentially forwarded) NOTIFY message Otherwise, upon receipt of a (potentially forwarded) NOTIFY message
for a particular child zone at the published notification endpoint, for a particular child zone at the published notification endpoint,
the receiving side (parent registry or registrar) has two options: the receiving side (parent registry or registrar) has two options:
1. Acknowledge receipt by sending a NOTIFY response as described in 1. Acknowledge receipt by sending a NOTIFY response as described in
[RFC1996] Section 4.7, and schedule an immediate check of the [RFC1996], Section 4.7, and schedule an immediate check of the
CDS/CDNSKEY/CSYNC RRsets published by that particular child zone CDS/CDNSKEY/CSYNC RRsets published by that particular child zone
(as appropriate for the type of NOTIFY received). (as appropriate for the type of NOTIFY received).
If the NOTIFY message contains an [RFC9567] EDNS0 Report-Channel If the NOTIFY message contains an EDNS0 Report-Channel option
option with an agent domain subordinate or equal to one of the NS [RFC9567] with an agent domain subordinate or equal to one of the
hostnames listed in the delegation, the processing party SHOULD NS hostnames listed in the delegation, the processing party
report any errors occurring during CDS/CDNSKEY/CSYNC processing SHOULD report any errors occurring during CDS/CDNSKEY/CSYNC
by sending a report query with an appropriate extended DNS error processing by sending a report query with an appropriate EDE code
code as described in [RFC8914]. Reporting may be done as described in [RFC8914]. Reporting may be done asynchronously
asynchronously (outside of the NOTIFY transaction). (outside of the NOTIFY transaction).
When using periodic scanning, notifications preempt the scanning When using periodic scanning, notifications preempt the scanning
timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/ timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/
CSYNC RRset is indeed new or has changed, the corresponding CSYNC RRset is indeed new or has changed, the corresponding
child's timer may be reset and the scanning frequency reduced 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 (e.g., to once a week). If a CDS/CDNSKEY/CSYNC change is later
detected through scanning (without having received a detected through scanning (without having received a
notification), NOTIFY-related state SHOULD be cleared, reverting notification), the NOTIFY-related state SHOULD be cleared,
to the default scanning schedule for this child. reverting to the default scanning schedule for this child.
When introducing CDS/CDNSKEY/CSYNC scanning support at the same When introducing CDS/CDNSKEY/CSYNC scanning support at the same
time as NOTIFY support, backwards compatibility considerations time as NOTIFY support, backwards compatibility considerations
regarding the scanning interval do not apply; a low-frequency regarding the scanning interval do not apply; a low-frequency
scanning schedule MAY thus be used by default in such cases. scanning schedule MAY thus be used by default in such cases.
2. Do not act upon the notification. To prevent retries, recipients 2. Do not act upon the notification. To prevent retries, recipients
SHOULD acknowledge the notification by sending a NOTIFY response SHOULD acknowledge the notification by sending a NOTIFY response
even when otherwise ignoring the request, combined with a report even when otherwise ignoring the request, combined with a report
query if feasible (see above). One reason to do this may be a query if feasible (see above). One reason to do this may be a
skipping to change at page 11, line 39 skipping to change at line 508
providing improved service for the child. providing improved service for the child.
If, in addition to scheduling an immediate check for the child zone If, in addition to scheduling an immediate check for the child zone
of the notification, the scanning schedule is also modified to be of the notification, the scanning schedule is also modified to be
less frequent, the cost of providing the scanning service will be less frequent, the cost of providing the scanning service will be
reduced. reduced.
5. Security Considerations 5. Security Considerations
If an action is triggered by the receipt of a DNS NOTIFY, its If an action is triggered by the receipt of a DNS NOTIFY, its
execution relies on the same security model which the receiving party execution relies on the same security model that the receiving party
would apply if the action had been triggered by something else. This would apply if the action were triggered by something else. This is
is because the notification affects the action's timing alone. For because the notification affects the action's timing alone. For
example, DS bootstrapping is expected to be performed the same way example, DS bootstrapping is expected to be performed the same way,
independently of the type of trigger; this includes all security and independently of the type of trigger; this includes all security and
authentication requirements (e.g., [RFC9615]) which the parent authentication requirements (e.g., [RFC9615]) that the parent
registry/registrar has chosen to apply. registry/registrar has chosen to apply.
The original NOTIFY specification sidesteps most security issues by The original NOTIFY specification sidesteps most security issues by
not relying on the information in the NOTIFY message in any way, and 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 instead only using it to "enter the state it would if the zone's
refresh timer had expired" (Section 4.7 of [RFC1996]). refresh timer had expired" (Section 4.7 of [RFC1996]).
This security model is reused for generalized NOTIFY messages. It This security model is reused for generalized NOTIFY messages.
therefore seems impossible to affect the behaviour of the recipient Therefore, it seems impossible to affect the behaviour of the
of the NOTIFY other than by hastening the timing for when different recipient of the NOTIFY other than by hastening the timing for when
checks are initiated. As a consequence, while notifications different checks are initiated. As a consequence, while
themselves can be secured via access control mechanisms, this is not notifications themselves can be secured via access control
a requirement. mechanisms, this is not a requirement.
The receipt of a notification message will, in general, cause the In general, the receipt of a notification message will cause the
receiving party to perform one or more outbound queries for the receiving party to perform one or more outbound queries for the
records of interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEY records of interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEY
queries). When done using standard DNS, the size of these queries is queries). When done using standard DNS, the size of these queries is
comparable to that of the NOTIFY messages themselves, rendering any comparable to that of the NOTIFY messages themselves, rendering any
amplification attempts futile. The number of queries triggered per amplification attempts futile. The number of queries triggered per
notification is also limited by the requirement that a NOTIFY message notification is also limited by the requirement that a NOTIFY message
can refer to one child only. can refer to one child only.
However, when the outgoing query occurs via encrypted transport, some However, when the outgoing query occurs via encrypted transport, some
amplification is possible, both with respect to bandwidth and amplification is possible, both with respect to bandwidth and
computational burden. In this case, the usual principle of bounding computational burden. In this case, the usual principle of bounding
the work, even under unreasonable events, applies. the work applies, even under unforeseen events.
Receivers therefore MUST implement rate limiting for notification Therefore, receivers MUST implement rate limiting for notification
processing. It is RECOMMENDED to configure rate limiting processing. It is RECOMMENDED to configure rate limiting
independently for both the notification's source IP address and the independently for both the notification's source IP address and the
name of the zone that is conveyed in the NOTIFY message. Rate name of the zone that is conveyed in the NOTIFY message. Rate
limiting also mitigates processing load from garbage notifications. limiting also mitigates the processing load from garbage
notifications.
Alternative solutions (such as signing notifications and validating Alternative solutions (such as signing notifications and validating
their signatures) appear significantly more expensive without their signatures) appear significantly more expensive without
tangible benefit. tangible benefit.
In order to facilitate schemes that are authenticated outside of In order to facilitate schemes that are authenticated outside of
DNSSEC (such as via SIG(0)), zones containing DSYNC records are not DNSSEC (such as via SIG(0)), zones containing DSYNC records are not
required to be signed. Spoofed DSYNC responses would prevent required to be signed. Spoofed DSYNC responses would prevent
notifications from reaching their legitimate target, and a different notifications from reaching their legitimate target, and a different
party may receive unsolicited notifications; both effects, however, party may receive unsolicited notifications; however, both effects
can also be achieved in the presence of DNSSEC. The illegitimate can also be achieved in the presence of DNSSEC. The illegitimate
target is also enabled to learn notification contents in real-time, 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 which may be a privacy concern for the sender. If so, the sender may
choose to ignore unsigned DSYNC records. choose to ignore unsigned DSYNC records.
6. IANA Considerations 6. IANA Considerations
*Note to the RFC Editor*: In this section, please replace occurrences
of "(this document)" with a proper reference.
6.1. DSYNC RR Type 6.1. DSYNC RR Type
IANA is requested to update the "Resource Record (RR) TYPEs" registry IANA has registered DSYNC in the "Resource Record (RR) TYPEs"
under the "Domain Name System (DNS) Parameters" registry group as registry under the "Domain Name System (DNS) Parameters" registry
follows: group as follows:
Type DSYNC
Value 66
Meaning Endpoint discovery for delegation synchronization
Reference (this document) Type: DSYNC
Value: 66
Meaning: Endpoint discovery for delegation synchronization
Reference: RFC 9859
6.2. DSYNC Scheme Registration 6.2. DSYNC Scheme Registration
IANA is requested to create and maintain the following new registry IANA has created the following new registry in the "Domain Name
in the "Domain Name System (DNS) Parameters" registry group: System (DNS) Parameters" registry group:
Name DSYNC: Location of Synchronization Endpoints
Assignment Policy Expert Review
Reference (this document) Name: DSYNC: Location of Synchronization Endpoints
Registration Procedure: Expert Review
Reference: RFC 9859
The initial contents for the registry are as follows: The initial contents for the registry are as follows:
+========+=========+==========+=====================+===========+ +========+===================+==========================+===========+
| RRtype | Scheme | Mnemonic | Purpose | Reference | | RRtype | Scheme (Mnemonic) | Purpose | Reference |
+========+=========+==========+=====================+===========+ +========+===================+==========================+===========+
| | 0 | | Null scheme (no-op) | (this | | | 0 | Null scheme (no-op) | RFC 9859 |
| | | | | document) | +--------+-------------------+--------------------------+-----------+
+--------+---------+----------+---------------------+-----------+ | CDS | 1 (NOTIFY) | Delegation management | RFC 9859 |
| CDS | 1 | NOTIFY | Delegation | (this | +--------+-------------------+--------------------------+-----------+
| | | | management | document) | | CSYNC | 1 (NOTIFY) | Delegation management | RFC 9859 |
+--------+---------+----------+---------------------+-----------+ +--------+-------------------+--------------------------+-----------+
| CSYNC | 1 | NOTIFY | Delegation | (this | | | 2-127 | Unassigned | |
| | | | management | document) | +--------+-------------------+--------------------------+-----------+
+--------+---------+----------+---------------------+-----------+ | | 128-255 | Reserved for Private | RFC 9859 |
| | 2-127 | | Unassigned | | | | | Use | |
+--------+---------+----------+---------------------+-----------+ +--------+-------------------+--------------------------+-----------+
| | 128-255 | | Reserved (private | (this |
| | | | use) | document) |
+--------+---------+----------+---------------------+-----------+
Table 1 Table 1
Requests to register additional entries MUST include the following Requests to register additional entries MUST include the following
fields: fields:
RRtype An RRtype that is defined for use RRtype: An RRtype that is defined for use
Scheme: The mode used for contacting the desired notification
Scheme The mode used for contacting the desired notification address address
Mnemonic: The scheme's shorthand string used in presentation format
Mnemonic The scheme's shorthand string used in presentation format Purpose: Use case description
Reference: Location of specification or registration source
Purpose Use case description
Reference Location of specification or registration source
Registration requests are to be recorded by IANA after Expert Review Registration requests are to be recorded by IANA after Expert Review
[RFC8126]. Expert reviewers should take into consideration the [RFC8126]. Expert Reviewers should take the points below into
following points, but are being designated as experts for a reason, consideration; however, they are experts and should be given
so they should be given substantial latitude: substantial latitude:
* Point squatting should be discouraged. Reviewers are encouraged * Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments. registered and that the point is likely to be used in deployments.
The code points tagged as "Private Use" are intended for testing The code points tagged as "Private Use" are intended for testing
purposes and closed environments. Code points in other ranges purposes and closed environments. Code points in other ranges
should not be assigned for testing. should not be assigned for testing.
* A specification of a scheme is desirable, but early assignment * A specification of a scheme is desirable, but early assignment
before a specification is available is also possible. When before a specification is available is also possible. When
specifications are not provided, the description provided needs to specifications are not provided, the description provided needs to
have sufficient information to identify what the point is being have sufficient information to identify what the point is being
used for. used for. A scheme number may have exactly one mnemonic.
* Experts should take into account that field values are fit for * Experts should take into account that field values are fit for
purpose. For example, the mnemonic should be indicative and and purpose. For example, the mnemonic should be indicative and have
have a plausible connection to the scheme's notification a plausible connection to the scheme's notification mechanism.
mechanism.
6.3. _dsync Underscore Name 6.3. _dsync Underscore Name
Per [RFC8552], IANA is requested to add the following entries to the Per [RFC8552], IANA has registered the following entries to the
"Underscored and Globally Scoped DNS Node Names" registry: "Underscored and Globally Scoped DNS Node Names" registry within the
"Domain Name System (DNS) Parameters" registry group:
+---------+------------+-----------------+
| RR Type | _NODE NAME | Reference |
+---------+------------+-----------------+
| DSYNC | _dsync | (this document) |
+---------+------------+-----------------+
7. Implementation Status
*Note to the RFC Editor*: please remove this entire section before
publication.
Johan Stenstam's experimental nameserver implements this draft
(https://github.com/johanix/tdns).
7.1. Child DNS Operator-side
* IronDNS implementation under way
* deSEC implementation under way (Q1/2025)
7.2. Parent-side
* SWITCH (.CH/.LI) implementation is under way.
* .SE/.NU will implement this once it is an RFC.
8. Acknowledgements +=========+============+===========+
| RR Type | _NODE NAME | Reference |
+=========+============+===========+
| DSYNC | _dsync | RFC 9859 |
+---------+------------+-----------+
In order of first contribution or review: Joe Abley, Mark Andrews, Table 2
Christian Elmerot, Ólafur Guðmundsson, Paul Wouters, Brian Dickson,
Warren Kumari, 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.
9. References 7. References
9.1. Normative References 7.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/rfc/rfc1996>. August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/rfc/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014, DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/rfc/rfc7344>. <https://www.rfc-editor.org/info/rfc7344>.
[RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS",
RFC 7477, DOI 10.17487/RFC7477, March 2015, RFC 7477, DOI 10.17487/RFC7477, March 2015,
<https://www.rfc-editor.org/rfc/rfc7477>. <https://www.rfc-editor.org/info/rfc7477>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078, the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017, DOI 10.17487/RFC8078, March 2017,
<https://www.rfc-editor.org/rfc/rfc8078>. <https://www.rfc-editor.org/info/rfc8078>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves", Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/rfc/rfc8552>. <https://www.rfc-editor.org/info/rfc8552>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914, Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020, DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/rfc/rfc8914>. <https://www.rfc-editor.org/info/rfc8914>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023, RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/rfc/rfc9364>. <https://www.rfc-editor.org/info/rfc9364>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024, RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/rfc/rfc9499>. <https://www.rfc-editor.org/info/rfc9499>.
[RFC9567] Arends, R. and M. Larson, "DNS Error Reporting", RFC 9567, [RFC9567] Arends, R. and M. Larson, "DNS Error Reporting", RFC 9567,
DOI 10.17487/RFC9567, April 2024, DOI 10.17487/RFC9567, April 2024,
<https://www.rfc-editor.org/rfc/rfc9567>. <https://www.rfc-editor.org/info/rfc9567>.
[RFC9615] Thomassen, P. and N. Wisiol, "Automatic DNSSEC [RFC9615] Thomassen, P. and N. Wisiol, "Automatic DNSSEC
Bootstrapping Using Authenticated Signals from the Zone's Bootstrapping Using Authenticated Signals from the Zone's
Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024, Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024,
<https://www.rfc-editor.org/rfc/rfc9615>. <https://www.rfc-editor.org/info/rfc9615>.
9.2. Informative References
[I-D.ietf-dnsop-dnssec-automation] 7.2. Informative References
Wisser, U., Huque, S., and J. Stenstam, "DNSSEC
automation", Work in Progress, Internet-Draft, draft-ietf-
dnsop-dnssec-automation-03, 19 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
dnssec-automation-03>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012, DOI 10.17487/RFC6781, December 2012,
<https://www.rfc-editor.org/rfc/rfc6781>. <https://www.rfc-editor.org/info/rfc6781>.
[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
"DNSSEC Key Rollover Timing Considerations", RFC 7583, "DNSSEC Key Rollover Timing Considerations", RFC 7583,
DOI 10.17487/RFC7583, October 2015, DOI 10.17487/RFC7583, October 2015,
<https://www.rfc-editor.org/rfc/rfc7583>. <https://www.rfc-editor.org/info/rfc7583>.
[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
Blacka, "Multi-Signer DNSSEC Models", RFC 8901, Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
DOI 10.17487/RFC8901, September 2020, DOI 10.17487/RFC8901, September 2020,
<https://www.rfc-editor.org/rfc/rfc8901>. <https://www.rfc-editor.org/info/rfc8901>.
Appendix A. Efficiency and Convergence Issues in DNS Scanning Appendix A. Efficiency and Convergence Issues in DNS Scanning
A.1. Original NOTIFY for Zone Transfer Nudging A.1. Original NOTIFY for Zone Transfer Nudging
[RFC1996] introduced the concept of a DNS Notify message which was [RFC1996] introduced the concept of a DNS NOTIFY message, which was
used to improve the convergence time for secondary servers when a DNS used to improve the convergence time for secondary servers when a DNS
zone had been updated in the primary. The basic idea was to augment zone had been updated in the primary server. The basic idea was to
the traditional "pull" mechanism (a periodic SOA query) with a "push" augment the original "pull" mechanism (a periodic SOA query) with a
mechanism (a Notify) for a common case that was otherwise very "push" mechanism (a NOTIFY) for a common case that was otherwise very
inefficient (due to either slow convergence or wasteful overly inefficient (due to either slow convergence or wasteful and overly
frequent scanning of the primary for changes). frequent scanning of the primary for changes).
While it is possible to indicate how frequently checks should occur While it is possible to indicate how frequently checks should occur
(via the SOA Refresh parameter), these checks did not allow catching (via the SOA Refresh parameter), these checks did not allow catching
zone changes that fall between checkpoints. [RFC1996] addressed the zone changes that fall between checkpoints. [RFC1996] addressed the
optimization of the time-and-cost trade-off between a secondary optimization of the time-and-cost trade-off between a secondary
checking frequently for new versions of a zone, and infrequent server frequently checking for new versions of a zone and infrequent
checking, by replacing scheduled scanning with the more efficient checks by replacing scheduled scanning with the more efficient NOTIFY
NOTIFY mechanism. mechanism.
A.2. Similar Issues for DS Maintenance and Beyond A.2. Similar Issues for DS Maintenance and Beyond
Today, we have similar issues with slow updates of DNS data in spite 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 of the data having been published. The two most obvious cases are
CDS and CSYNC scanners deployed in a growing number of TLD CDS and CSYNC scanners deployed in a growing number of TLD
registries. Because of the large number of child delegations, registries. Because of the large number of child delegations,
scanning for CDS and CSYNC records is rather slow (as in infrequent). scanning for CDS and CSYNC records is rather slow (as in,
infrequent).
It is only a very small number of the delegations that will have Only a very small number of the delegations will have updated a CDS
updated CDS or CDNSKEY record in between two scanning runs. However, or CDNSKEY record in between two scanning runs. However, frequent
frequent scanning for CDS and CDNSKEY records is costly, and scanning for CDS and CDNSKEY records is costly, and infrequent
infrequent scanning causes slower convergence (i.e., delay until the scanning causes slower convergence (i.e., delay until the DS RRset is
DS RRset is updated). updated).
Unlike in the original case, where the primary is able to suggest the Unlike in the original case, where the primary is able to suggest the
scanning interval via the SOA Refresh parameter, an equivalent scanning interval via the SOA Refresh parameter, an equivalent
mechanism does not exist for DS-related scanning. mechanism does not exist for DS-related scanning.
All of the above also applies to automated NS and glue record All of the above also applies to automated NS and glue record
maintenance via CSYNC scanning [RFC7477]. Again, given that CSYNC maintenance via CSYNC scanning [RFC7477]. Again, given that CSYNC
records change only rarely, frequent scanning of a large number of records change only rarely, frequent scanning of a large number of
delegations seems disproportionately costly, while infrequent delegations seems disproportionately costly, while infrequent
scanning causes slower convergence (delay until the delegation is scanning causes slower convergence (delay until the delegation is
updated). updated).
While use of the NOTIFY mechanism for coordinating the key exchange While use of the NOTIFY mechanism for coordinating the key exchange
in multi-signer setups [I-D.ietf-dnsop-dnssec-automation] is in multi-signer setups [RFC8901] is conceivable, the detailed
conceivable, the detailed specification is left for future work. specification is left for future work.
Appendix B. Change History (to be removed before publication)
* draft-ietf-dnsop-generalized-notify-09
Leftover editorial changes
* draft-ietf-dnsop-generalized-notify-08
IESG review editorial changes
Added guidelines for expert review (IESG feedback)
Nits from Dnsdir telechat review
* draft-ietf-dnsop-generalized-notify-07
IESG review changes (notable: scheme now has mnemonic; else
editorial)
Nits from Opsdir telechat review
* draft-ietf-dnsop-generalized-notify-06
Nits from Genart review
Nits from Opsdir review
Nits from Dnsdir review
* draft-ietf-dnsop-generalized-notify-05
Editorial changes
* draft-ietf-dnsop-generalized-notify-04
Add section on Implementation Status
Use assigned DSYNC RRtype value
Define DSYNC presentation format
Make all needed IANA requests
Editorial changes
* draft-ietf-dnsop-generalized-notify-03
Include DNSSEC bootstrapping use case
Remove sections with approaches not pursued
Editorial changes
* draft-ietf-dnsop-generalized-notify-02
Nits by Tim Wicinski
Dnsdir feedback
Specify timeout and error handling
Editorial nits
Reserve scheme value 0
* draft-ietf-dnsop-generalized-notify-01
Reserve scheme values 128-255
Rename NOTIFY rrtype to DSYNC (to distinguish from NOTIFY message)
Describe endpoint discovery
Discussion on garbage notifications
More discussion on amplification risks
Clean-up, editorial changes
* draft-ietf-dnsop-generalized-notify-00
Revision after adoption.
* draft-thomassen-dnsop-generalized-dns-notify-02
Add rationale for staying in band
Add John as an author
* draft-thomassen-dnsop-generalized-dns-notify-01
Mention Ry-to-Rr forwarding to accommodate RRR model
Add port number flexibility
Add scheme parameter
Drop SRV-based alternative in favour of new NOTIFY RR
Editorial improvements
* draft-thomassen-dnsop-generalized-dns-notify-00 Acknowledgements
Initial public draft. 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 Authors' Addresses
Johan Stenstam Johan Stenstam
The Swedish Internet Foundation The Swedish Internet Foundation
Email: johan.stenstam@internetstiftelsen.se Email: johan.stenstam@internetstiftelsen.se
Peter Thomassen Peter Thomassen
deSEC, Secure Systems Engineering deSEC, Secure Systems Engineering
Email: peter@desec.io Email: peter@desec.io
John Levine John Levine
Standcore LLC Standcore LLC
Email: standards@standcore.com Email: standards@standcore.com
 End of changes. 108 change blocks. 
422 lines changed or deleted 287 lines changed or added

This html diff was produced by rfcdiff 1.48.