DNSOP Working Group J. Stenstam Internet-Draft The Swedish Internet Foundation Intended status: Standards Track P. Thomassen Expires: 15 June 2025 deSEC, Secure Systems Engineering J. Levine Standcore LLC 12 December 2024 Generalized DNS Notifications draft-ietf-dnsop-generalized-notify-04 Abstract This document extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC bootstrapping and key rollovers hints, and quicker changes to a delegation's NS record set. To enable this functionality, a method for discovering the receiver endpoint for such notification message is introduced, via the new DSYNC record type. 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 This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 15 June 2025. Stenstam, et al. Expires 15 June 2025 [Page 1] Internet-Draft Generalized Notifications December 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Design Requirements . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. DSYNC RR Type . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Presentation Format . . . . . . . . . . . . . . . . . . . 5 2.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Publication of Notification Targets . . . . . . . . . . . . . 5 3.1. Wildcard Method . . . . . . . . . . . . . . . . . . . . . 6 3.2. Child-specific Method . . . . . . . . . . . . . . . . . . 6 4. Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Endpoint Discovery . . . . . . . . . . . . . . . . . . . 7 4.2. Sending Notifications . . . . . . . . . . . . . . . . . . 8 4.2.1. Timeouts and Error Handling . . . . . . . . . . . . . 8 4.2.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Processing of NOTIFY Messages . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.1. DSYNC RR Type . . . . . . . . . . . . . . . . . . . . . . 12 6.2. DSYNC Scheme Registration . . . . . . . . . . . . . . . . 12 6.3. _dsync Underscore Name . . . . . . . . . . . . . . . . . 13 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 7.1. Child DNS Operator-side . . . . . . . . . . . . . . . . . 13 7.2. Parent-side . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Efficiency and Convergence Issues in DNS Scanning . 15 A.1. Original NOTIFY for Zone Transfer Nudging . . . . . . . . 15 A.2. Similar Issues for DS Maintenance and Beyond . . . . . . 16 Stenstam, et al. Expires 15 June 2025 [Page 2] Internet-Draft Generalized Notifications December 2024 Appendix B. Change History (to be removed before publication) . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Traditional DNS notifications [RFC1996], which are here referred to 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 the zone. This mechanism successfully addresses a significant inefficiency in the original protocol. Today similar inefficiencies occur in new use cases, in particular delegation maintenance (DS and NS record updates). Just as in the NOTIFY(SOA) case, a new set of notification types will have a major positive benefit by allowing the DNS infrastructure to completely sidestep these inefficiencies. For additional context, see Appendix A. No DNS protocol changes are introduced by this document. The mechanism instead makes use of a wider range of DNS messages allowed by the protocol. Future extension for further use cases (such as multi-signer key exchange) is possible. Readers are expected to be familiar with DNSSEC [RFC9364], including [RFC6781], [RFC7344], [RFC7477], [RFC7583], [RFC8078], [RFC8901], and [RFC9615]. DNS-specific terminology can be found in [RFC9499]. 1.1. Design Requirements When the parent operator is interested in notifications for delegation maintenance (such as DS or NS update hints), a service will need to be made available for accepting these notifications. Depending on the context, this service may be run by the parent operator themselves, or by a designated entity who is in charge of handling the domain's delegation data (such as a domain registrar). It seems desirable to minimize the number of steps that the notification sender needs to figure out where to send the NOTIFY. This suggests that the lookup process be ignorant of the details of the parent-side relationships (e.g., whether there is a registrar or not). This is addressed by parameterizing the lookup with the name of the child. The parent operator may then (optionally) announce the notification endpoint in a delegation-specific way, by publishing it at a child-specific name. (A catch-all endpoint may be indicated by wildcarding.) Stenstam, et al. Expires 15 June 2025 [Page 3] Internet-Draft Generalized Notifications December 2024 The solution proposed here is thus for the parent operator to publish the address where someone listens for notifications, in a child- specific way (see Section 3). Potential senders can easily determine the name of the parent and then look up that information (see Section 4.1). 1.2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. DSYNC RR Type 2.1. Wire Format The DSYNC RDATA wire format is encoded as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RRtype | Scheme | Port +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ RRtype The type of generalized NOTIFY that this DSYNC RR defines the 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 scheme indicates the mode used for locating the desired notification address. This is an 8 bit unsigned integer. Records with value 0 (null scheme) are ignored by consumers. Value 1 is described in this document, and values 128-255 are reserved for private use. All other values are currently unspecified. Port The port on the target host of the notification service. This is a 16 bit unsigned integer in network byte order. Target The fully-qualified, uncompressed domain name of the target host providing the service of listening for generalized notifications of the specified type. This name MUST resolve to one or more address records. Stenstam, et al. Expires 15 June 2025 [Page 4] Internet-Draft Generalized Notifications December 2024 2.2. Presentation Format The presentation format of the RDATA portion is as follows: * The RRtype field is represented as a mnemonic from the "Resource Record (RR) TYPEs" registry. * The Scheme 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 ([RFC1035], Section 5.1). 2.3. Semantics For now, the only scheme defined is scheme=1 with the interpretation that when a new CDS/CDNSKEY (or CSYNC) RRset is published, a NOTIFY(CDS) (or NOTIFY(CSYNC)) should be sent to the address and port listed in the corresponding DSYNC record. Example (for the owner names of these records, see Section 3): IN DSYNC CDS 1 5359 cds-scanner.example.net. IN DSYNC CSYNC 1 5360 csync-scanner.example.net. Should a need for other mechanisms arise, other schemes may be defined to deal with such requirements using alternative logic. 3. Publication of Notification Targets To use generalized notifications, it is necessary for the sender to know where to direct each NOTIFY message. This section describes the procedure for discovering that notification target. Note that generalized NOTIFY messages are but one mechanism for improving the efficiency of automated delegation maintenance. Other alternatives, such as contacting the parent operator via an API or DNS Update ([RFC2136]), may (or may not) be more suitable in individual cases. Like generalized notifications, they similarly require a means for discovering where to send the API or DNS Update requests. The scope for the publication mechanism is therefore wider than only to support generalized notifications, and a unified approach that works independently of the notification method is specified in this section. Stenstam, et al. Expires 15 June 2025 [Page 5] Internet-Draft Generalized Notifications December 2024 Parent operators participating in the discovery scheme for the purpose of delegation maintenance notifications MUST publish endpoint information using the record type defined in Section 2 under the _dsync subdomain of the parent zone, as described in the following subsection. There MUST NOT be more than one DSYNC record for each combination of rrtype and scheme. It is RECOMMENDED to secure the corresponding zone with DNSSEC. For practical purposes, the parent operator MAY delegate the _dsync domain as a separate zone, and/or synthesize records under it. If child-specificity is not needed, the parent can publish a static wildcard DSYNC record. 3.1. Wildcard Method If the parent operator itself performs CDS/CDNSKEY or CSYNC processing for some or all delegations, or wants to forward notifications to some other party, a default notification target may be specified as follows: *._dsync.example. IN DSYNC CDS scheme port target *._dsync.example. IN DSYNC CSYNC scheme port target To accommodate indirect delegation management models, the designated notification target may relay notifications to a third party (such as the registrar, in ICANN's model). The details of such arrangements are out of scope for this document. If for some reason the parent operator cannot publish wildcard records, the wildcard label may be dropped from the DSYNC owner name (i.e., it may be published at the _dsync label instead). This practice requires an additional step during discovery (see Section 4.1), and is therefore NOT RECOMMENDED. 3.2. Child-specific Method It is also possible to publish child-specific records, where the wildcard label is replaced by the child's FQDN with the parent zone's labels stripped. As an example, consider a registrar offering domains like child.example, delegated from example zone. If the registrar provides the notification endpoint, e.g., rr-endpoint.example:5300, the parent may publish this information as follows: child._dsync.example. IN DSYNC CDS 1 5300 rr-endpoint.example. Stenstam, et al. Expires 15 June 2025 [Page 6] Internet-Draft Generalized Notifications December 2024 4. Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications Delegation maintenance notifications address the inefficiencies related to scanning child zones for CDS/CDNSKEY records [RFC7344][RFC8078][RFC9615]. (For an overview of the issues, see Appendix A.) NOTIFY messages for delegation maintenance MUST be formatted as described in [RFC1996], with the qtype field replaced as appropriate. To address the CDS/CDNSKEY dichotomy, the NOTIFY(CDS) message (with qtype=CDS) is defined to indicate any child-side changes pertaining to an upcoming update of DS records. As the child DNS operator generally is unaware of whether the parent registry consumes CDS records or prefers CDNSKEY, or when that policy changes, it seems advisable to publish both types of records, preferably using automation features of common authoritative nameserver software for ensuring consistency. Upon receipt of NOTIFY(CDS), the recipient (the parent registry or a registrar) SHOULD initiate the same DNS lookups and verifications for DNSSEC bootstrapping [RFC9615] or DS maintenance [RFC7344][RFC8078] that would otherwise be triggered based on a timer. The CSYNC [RFC7477] inefficiency may be similarly treated, with the child sending a NOTIFY(CSYNC) message (with qtype=CSYNC) to an address where the parent operator (or a designated party) is listening for CSYNC notifications. In both cases the notification will speed up processing times by providing the recipient with a hint that a particular child zone has published new CDS, CDNSKEY and/or CSYNC records. 4.1. Endpoint Discovery To locate the target for outgoing delegation maintenance notifications, the notification sender MUST perform the following procedure: 1. Construct the lookup name, by injecting the _dsync label after the first label of the delegation owner name. 2. Perform a lookup of type DSYNC for the lookup name, and validate the response if DNSSEC is enabled. If a DSYNC RRset results, return it. 3. If the query resulted in a negative response: Stenstam, et al. Expires 15 June 2025 [Page 7] Internet-Draft Generalized Notifications December 2024 * If the response's SOA record indicates that the parent is more than one label away from the _dsync label, construct a new lookup name by inserting the _dsync label into the delegation owner name just before the parent zone labels inferred from the negative response, and go to step 2. For example, city.ise.mie.jp is delegated from jp (and not from ise.mie.jp or mie.jp!). The initial DSYNC query relating to it is thus directed at city._dsync.ise.mie.jp. This is expected to result in a negative response from jp, and another query for city.ise.mie._dsync.jp is then required; * Otherwise, if the lookup name has any labels in front of the _dsync label, remove them to construct a new lookup name (such as _dsync.jp), and go to step 2. (This is to enable zone structures without wildcards.) * Otherwise, return null (no notification target available). 4.2. Sending Notifications When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child zone, the DNS operator SHOULD send a suitable notification to one of the endpoints discovered as described in the previous section. A NOTIFY message can only carry information about changes concerning one child zone. When there are changes to several child zones, the sender MUST send a separate notification for each one. 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 zone are updated. If the primary sends a notification at the exact time of publication, there is a potential for CDS/CDNSKEY/CSYNC processing to be attempted before the corresponding records are served. As a result, a desired update may not be detected (or appear inconsistent), preventing it from being applied. It is therefore RECOMMENDED that the child delays sending notifications to the recipient until a consistent public view of the pertinent records is ensured. 4.2.1. Timeouts and Error Handling NOTIFY messages are expected to elicit a response from the recipient ([RFC1996] Section 4.7). If no response is received, senders SHOULD employ the same logic as for SOA notifications ([RFC1996] Sections 3.5 and 3.6). Stenstam, et al. Expires 15 June 2025 [Page 8] Internet-Draft Generalized Notifications December 2024 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 continuity requirement set forth in [RFC7344] Section 4.1). Such failures may occur asynchronously, even after the NOTIFY response has been sent. In order to learn about such failures, senders MAY include an [RFC9567] EDNS0 Report-Channel option in the NOTIFY message to request the receiving side to report any errors by making a report query with an appropriate extended DNS error code as described in [RFC8914]. When including this EDNS0 option, its agent domain MUST be subordinate or equal to one of the NS hostnames, as listed in the child's delegation in the parent zone. 4.2.2. Roles While the CDS/CDNSKEY/CSYNC processing following the receipt of a NOTIFY will often be performed by the registry, the protocol anticipates that in some contexts (especially for ICANN gTLDs), registrars may take on the task. In such cases, the current registrar notification endpoint may be published, enabling notifications to be directed to the appropriate target. The mechanics of how this is arranged between registry and registrar are out of scope for this document; the protocol only offers the possibility to arrange things such that from the child perspective, it is inconsequential how the parent-side parties are organized: notifications are simply sent to the published address. 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 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- car service) send the notifications, enabling this functionality even before the emergence of native support in nameserver software. 4.3. Processing of NOTIFY Messages NOTIFY(CDS) messages carrying notification payloads (records) for several child zones MUST be discarded, as sending them is an error. Upon receipt of a (potentially forwarded) valid NOTIFY(CDS) message for a particular child zone at the published address for CDS notifications, the receiving side (parent registry or registrar) has two options: Stenstam, et al. Expires 15 June 2025 [Page 9] Internet-Draft Generalized Notifications December 2024 1. Acknowledge receipt by sending a NOTIFY response as described in [RFC1996] Section 4.7 (identical to NOTIFY query, but with QR bit set) and schedule an immediate check of the CDS and CDNSKEY RRsets as published by that particular child zone. If the NOTIFY message contains an [RFC9567] EDNS0 Report-Channel option with an agent domain subordinate or equal to one of the NS hostnames listed in the delegation, the processing party SHOULD report any errors occuring during CDS/CDNSKEY processing by sending a report query with an appropriate extended DNS error code as described in [RFC8914]. When using period scanning, notifications preempt the scanning timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY RRset is indeed new or has changed, the corresponding child's timer may be reset and the scanning frequency reduced (e.g. to once a week). If a CDS/CDNSKEY change is later detected through scanning (without having received a notification), NOTIFY-related state SHOULD be cleared, reverting to the default scanning schedule for this child. When introducing CDS/CDNSKEY scanning support at the same time as NOTIFY(CDS) support, backwards compatibility considerations regarding the scanning interval do not apply; a low-frequency scanning schedule MAY thus be used by default in such cases. 2. Do not act upon the notification. To prevent retries, recipients SHOULD acknowledge the notification by sending a NOTIFY response even when otherwise ignoring the request, combined with a report query if feasible (see above). One reason to do this may be a rate limit (see Section 5), in which case "Blocked" (15) may be a suitable extended DNS error code. Implementing the first option will significantly decrease the convergence time (between publication of a new CDS/CDNSKEY record in the child and publication of the resulting DS), thereby providing improved service for the child. If, in addition to scheduling an immediate check for the child zone of the notification, the scanning schedule is also modified to be less frequent, the cost of providing the scanning service will be reduced. Upon receipt of a NOTIFY(CSYNC) to the published address for CSYNC notifications, the same options and considerations apply as for the NOTIFY(CDS). Stenstam, et al. Expires 15 June 2025 [Page 10] Internet-Draft Generalized Notifications December 2024 5. Security Considerations The original NOTIFY specification sidesteps most security issues by 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 refresh timer had expired" (Section 4.7 of [RFC1996]). This security model is reused for generalized NOTIFY messages. It therefore seems impossible to affect the behaviour of the recipient of the NOTIFY other than by hastening the timing for when different checks are initiated. The receipt of a notification message will, in general, cause the receiving party to perform one or more outbound queries for the records of interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEY queries). When done using standard DNS, the size of these queries is comparable to that of the NOTIFY messages themselves, rendering any amplification attempts futile. The number of queries triggered per notification is also limited by the requirement that a NOTIFY message can refer to one child only. However, when the outgoing query occurs via encrypted transport, some amplification is possible, both with respect to bandwidth and computational burden. In this case, the usual principle of bounding the work, even under unreasonable events, applies. Receivers therefore MUST implement rate limiting for notification processing. It is RECOMMENDED to configure rate limiting independently for both the notification's source IP address and the name of the zone that is conveyed in the NOTIFY message. Rate limiting also mitigates processing load from garbage notifications. Alternative solutions (such as signing notifications and validating their signatures) appear significantly more expensive without tangible benefit. In order to facilitate schemes that are authenticated outside of DNSSEC (such as via SIG(0)), zones containing DSYNC records are not required to be signed. Spoofed DSYNC responses would prevent notifications from reaching their legitimate target, and a different party may receive unsolicited notifications; both effects, however, can also be achieved in the presence of DNSSEC. The illegitimate 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 choose to ignore unsigned DSYNC records. Stenstam, et al. Expires 15 June 2025 [Page 11] Internet-Draft Generalized Notifications December 2024 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 IANA is requested to update the "Resource Record (RR) TYPEs" registry under the "Domain Name System (DNS) Parameters" registry group as follows: Type DSYNC Value 66 Meaning Endpoint discovery for delegation synchronization Reference (this document) 6.2. DSYNC Scheme Registration Per [RFC8552], IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" IANA web page as follows: Name DSYNC: Location of Synchronization Endpoints Assignment Policy Expert Review Reference (this document) +========+=========+========================+=================+ | RRtype | Scheme | Purpose | Reference | +========+=========+========================+=================+ | | 0 | Null scheme (no-op) | (this document) | +--------+---------+------------------------+-----------------+ | CDS | 1 | Delegation management | (this document) | +--------+---------+------------------------+-----------------+ | CSYNC | 1 | Delegation management | (this document) | +--------+---------+------------------------+-----------------+ | | 2-127 | Unassigned | | +--------+---------+------------------------+-----------------+ | | 128-255 | Reserved (private use) | (this document) | +--------+---------+------------------------+-----------------+ Table 1 Stenstam, et al. Expires 15 June 2025 [Page 12] Internet-Draft Generalized Notifications December 2024 6.3. _dsync Underscore Name IANA is requested to add the following entries to the "Underscored and Globally Scoped DNS Node Names" registry: +---------+------------+-----------------+ | 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 * .SE/.NU will implement this once it is an RFC. 8. Acknowledgements In order of first contribution: Joe Abley, Mark Andrews, Christian Elmerot, Ólafur Guðmundsson, Paul Wouters, Brian Dickson, Warren Kumari, Patrick Mevzek, Tim Wicinski 9. References 9.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, . Stenstam, et al. Expires 15 June 2025 [Page 13] Internet-Draft Generalized Notifications December 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, . [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", RFC 7477, DOI 10.17487/RFC7477, March 2015, . [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, . [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . Stenstam, et al. Expires 15 June 2025 [Page 14] Internet-Draft Generalized Notifications December 2024 [RFC9567] Arends, R. and M. Larson, "DNS Error Reporting", RFC 9567, DOI 10.17487/RFC9567, April 2024, . [RFC9615] Thomassen, P. and N. Wisiol, "Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024, . 9.2. Informative References [I-D.ietf-dnsop-dnssec-automation] Wisser, U., Huque, S., and J. Stenstam, "DNSSEC automation", Work in Progress, Internet-Draft, draft-ietf- dnsop-dnssec-automation-03, 19 October 2024, . [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, . [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, "DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI 10.17487/RFC7583, October 2015, . [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. Blacka, "Multi-Signer DNSSEC Models", RFC 8901, DOI 10.17487/RFC8901, September 2020, . Appendix A. Efficiency and Convergence Issues in DNS Scanning A.1. Original NOTIFY for Zone Transfer Nudging [RFC1996] introduced the concept of a DNS Notify message which was 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 the traditional "pull" mechanism (a periodic SOA query) with a "push" mechanism (a Notify) for a common case that was otherwise very inefficient (due to either slow convergence or wasteful overly frequent scanning of the primary for changes). While it is possible to indicate how frequently checks should occur (via the SOA Refresh parameter), these checks did not allow catching zone changes that fall between checkpoints. [RFC1996] addressed the Stenstam, et al. Expires 15 June 2025 [Page 15] Internet-Draft Generalized Notifications December 2024 optimization of the time-and-cost trade-off between a secondary checking frequently for new versions of a zone, and infrequent checking, by replacing scheduled scanning with the more efficient NOTIFY mechanism. A.2. Similar Issues for DS Maintenance and Beyond Today, we have similar issues with slow updates of DNS data in spite of the data having been published. The two most obvious cases are CDS and CSYNC scanners deployed in a growing number of TLD registries. Because of the large number of child delegations, scanning for CDS and CSYNC records is rather slow (as in infrequent). It is only a very small number of the delegations that will have updated CDS or CDNSKEY record in between two scanning runs. However, frequent scanning for CDS and CDNSKEY records is costly, and infrequent scanning causes slower convergence (i.e., delay until the DS RRset is updated). Unlike in the original case, where the primary is able to suggest the scanning interval via the SOA Refresh parameter, an equivalent mechanism does not exist for DS-related scanning. All of the above also applies to automated NS and glue record maintenance via CSYNC scanning [RFC7477]. Again, given that CSYNC records change only rarely, frequent scanning of a large number of delegations seems disproportionately costly, while infrequent scanning causes slower convergence (delay until the delegation is updated). While use of the NOTIFY mechanism for coordinating the key exchange in multi-signer setups [I-D.ietf-dnsop-dnssec-automation] is conceivable, the detailed specification is left for future work. Appendix B. Change History (to be removed before publication) * 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 Stenstam, et al. Expires 15 June 2025 [Page 16] Internet-Draft Generalized Notifications December 2024 * 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 Stenstam, et al. Expires 15 June 2025 [Page 17] Internet-Draft Generalized Notifications December 2024 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 Initial public draft. Authors' Addresses Johan Stenstam The Swedish Internet Foundation Email: johan.stenstam@internetstiftelsen.se Peter Thomassen deSEC, Secure Systems Engineering Email: peter@desec.io John Levine Standcore LLC Email: standards@standcore.com Stenstam, et al. Expires 15 June 2025 [Page 18]