rfc9859v1.txt   rfc9859.txt 
skipping to change at line 91 skipping to change at line 91
7.1. Normative References 7.1. Normative References
7.2. Informative References 7.2. Informative References
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
A.2. Similar Issues for DS Maintenance and Beyond A.2. Similar Issues for DS Maintenance and Beyond
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
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
skipping to change at line 130 skipping to change at line 130
delegation maintenance (such as DS or NS update hints), a service to delegation maintenance (such as DS or NS update hints), a service to
accept these notifications will need to be made available. Depending accept these notifications will need to be made available. Depending
on the context, this service may be run by the parent operator or by on the context, this service may be run by the parent operator or by
a designated entity who is in charge of handling the domain's a designated entity who is in charge of 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 or not of the details of the parent-side relationships (e.g., whether or not
there is a registrar.) 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-all publishing it at a child-specific name. (A catch-all endpoint may be
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
skipping to change at line 167 skipping to change at line 167
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 ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
Figure 1: DSYNC RDATA Wire Format
RRtype: The type of generalized NOTIFY that this DSYNC RR defines RRtype: The type of generalized NOTIFY that this DSYNC RR defines
the desired target address for (see the "Resource Record (RR) the desired target address for (see the "Resource Record (RR)
TYPEs" registry). For now, only CDS and CSYNC are supported TYPEs" registry at <https://www.iana.org/assignments/dns-
values, with the former indicating an updated CDS or CDNSKEY parameters/>). For now, only CDS and CSYNC are supported values,
record set. with the former indicating an updated CDS or CDNSKEY record set.
Scheme: The mode used for contacting the desired notification 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:
skipping to change at line 210 skipping to change at line 214
* The Target field is represented as a <domain-name> (Section 5.1 of * The Target field is represented as a <domain-name> (Section 5.1 of
[RFC1035]). [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 corresponds to that DSYNC record and
DNS transport [RFC1035]. using 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 the RRtype. They merely specify a method Schemes are independent of the RRtype. They merely specify a method
skipping to change at line 251 skipping to change at line 255
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 that zones containing DSYNC RRtype and Scheme. It is RECOMMENDED that zones containing DSYNC
records with DNSSEC be secure. 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 if the parent operator processing for some or all delegations, or if the parent operator
wants to forward notifications to some other party, a default wants to relay notifications to some other party, a default
notification target may 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.
skipping to change at line 367 skipping to change at line 371
_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). Then go to step 2. (This is to enable as _dsync.example). Then go to step 2. (This is to enable
zone 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.
Therefore, it is RECOMMENDED that the child delay 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 EDNS0 In order to learn about such failures, senders MAY include an EDNS0
Report-Channel option [RFC9567] in the NOTIFY message to request that Report-Channel option [RFC9567] in the NOTIFY message to request that
the receiving side report any errors by making a report query with an the receiving side report any errors by making a report query with an
appropriate extended DNS error code as described in [RFC8914]. (The appropriate extended DNS error (EDE) code as described in [RFC8914].
prohibition of this option in queries ([RFC9567], Section 6.1) only (The prohibition of this option in queries ([RFC9567], Section 6.1)
applies to resolver queries and thus does not cover NOTIFY messages.) only applies to resolver queries and thus does not cover NOTIFY
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 that follows 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,
how the parent-side parties are organized is inconsequential: 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
skipping to change at line 453 skipping to change at line 470
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 EDNS0 Report-Channel option If the NOTIFY message contains an EDNS0 Report-Channel option
[RFC9567] with an agent domain subordinate or equal to one of the [RFC9567] with an agent domain subordinate or equal to one of the
NS hostnames listed in the delegation, the processing party NS hostnames listed in the delegation, the processing party
SHOULD report any errors occurring during CDS/CDNSKEY/CSYNC SHOULD report any errors occurring during CDS/CDNSKEY/CSYNC
processing by sending a report query with an appropriate extended processing by sending a report query with an appropriate EDE code
DNS error 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), the NOTIFY-related state SHOULD be cleared, notification), the NOTIFY-related state SHOULD be cleared,
reverting to the default scanning schedule for this child. reverting to the default scanning schedule for this child.
skipping to change at line 523 skipping to change at line 540
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 applies, even under unreasonable events. the work applies, even under unforeseen events.
Therefore, receivers 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 the processing load from garbage limiting also mitigates the processing load from garbage
notifications. 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
skipping to change at line 570 skipping to change at line 587
IANA has created the following new registry in the "Domain Name IANA has created the following new registry in the "Domain Name
System (DNS) Parameters" registry group: System (DNS) Parameters" registry group:
Name: DSYNC: Location of Synchronization Endpoints Name: DSYNC: Location of Synchronization Endpoints
Registration Procedure: Expert Review Registration Procedure: Expert Review
Reference: RFC 9859 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) | RFC 9859 | | | 0 | Null scheme (no-op) | RFC 9859 |
+--------+---------+----------+-----------------------+-----------+ +--------+-------------------+--------------------------+-----------+
| CDS | 1 | NOTIFY | Delegation management | RFC 9859 | | CDS | 1 (NOTIFY) | Delegation management | RFC 9859 |
+--------+---------+----------+-----------------------+-----------+ +--------+-------------------+--------------------------+-----------+
| CSYNC | 1 | NOTIFY | Delegation management | RFC 9859 | | CSYNC | 1 (NOTIFY) | Delegation management | RFC 9859 |
+--------+---------+----------+-----------------------+-----------+ +--------+-------------------+--------------------------+-----------+
| | 2-127 | | Unassigned | | | | 2-127 | Unassigned | |
+--------+---------+----------+-----------------------+-----------+ +--------+-------------------+--------------------------+-----------+
| | 128-255 | | Reserved for Private | RFC 9859 | | | 128-255 | Reserved for Private | RFC 9859 |
| | | | Use | | | | | Use | |
+--------+---------+----------+-----------------------+-----------+ +--------+-------------------+--------------------------+-----------+
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
skipping to change at line 614 skipping to change at line 631
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 have purpose. For example, the mnemonic should be indicative and have
a plausible connection to the scheme's notification mechanism. a plausible connection to the scheme's notification mechanism.
6.3. _dsync Underscore Name 6.3. _dsync Underscore Name
Per [RFC8552], IANA has registered the following entries to the Per [RFC8552], IANA has registered the following entries to the
"Underscored and Globally Scoped DNS Node Names" registry within the "Underscored and Globally Scoped DNS Node Names" registry within the
"Domain Name System (DNS) Parameters" registry group: "Domain Name System (DNS) Parameters" registry group:
skipping to change at line 708 skipping to change at line 725
DOI 10.17487/RFC9567, April 2024, DOI 10.17487/RFC9567, April 2024,
<https://www.rfc-editor.org/info/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/info/rfc9615>. <https://www.rfc-editor.org/info/rfc9615>.
7.2. Informative References 7.2. Informative References
[DNSSEC-AUTO]
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/info/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/info/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/info/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 server. The basic idea was to zone had been updated in the primary server. The basic idea was to
augment the traditional "pull" mechanism (a periodic SOA query) with augment the original "pull" mechanism (a periodic SOA query) with a
a "push" mechanism (a Notify) for a common case that was otherwise "push" mechanism (a NOTIFY) for a common case that was otherwise very
very inefficient (due to either slow convergence or wasteful and inefficient (due to either slow convergence or wasteful and overly
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, scanning for CDS and CSYNC records is rather slow (as in,
infrequent). infrequent).
skipping to change at line 777 skipping to change at line 787
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 [DNSSEC-AUTO] is conceivable, the detailed in multi-signer setups [RFC8901] is conceivable, the detailed
specification is left for future work. specification is left for future work.
Acknowledgements Acknowledgements
In order of first contribution or review: Joe Abley, Mark Andrews, The authors acknowledge the contributions and reviews of the
Christian Elmerot, Ólafur Guðmundsson, Paul Wouters, Brian Dickson, following individuals (in order of their first contribution or
Warren Kumari, Patrick Mevzek, Tim Wicinski, Q Misell, Stefan Ubbink, 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 Matthijs Mekking, Kevin P. Fleming, Nicolai Leymann, Giuseppe
Fioccola, Peter Yee, Tony Li, Paul Wouters, Roman Danyliw, Peter van Fioccola, Peter Yee, Tony Li, Paul Wouters, Roman Danyliw, Peter van
Dijk, John Scudder, and Éric Vyncke. 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
 End of changes. 28 change blocks. 
74 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.48.