rfc9859.original.xml   rfc9859.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.26 (Ruby 3.3. -ietf-dnsop-generalized-notify-09" number="9859" updates="" obsoletes="" categor
6) --> y="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" versio
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft n="3" xml:lang="en" submissionType="IETF">
-ietf-dnsop-generalized-notify-09" category="std" consensus="true" tocInclude="t
rue" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.28.0 -->
<front> <front>
<title abbrev="Generalized Notifications">Generalized DNS Notifications</tit le> <title abbrev="Generalized Notifications">Generalized DNS Notifications</tit le>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-generalized-notify -09"/> <seriesInfo name="RFC" value="9859"/>
<author initials="J." surname="Stenstam" fullname="Johan Stenstam"> <author initials="J." surname="Stenstam" fullname="Johan Stenstam">
<organization>The Swedish Internet Foundation</organization> <organization>The Swedish Internet Foundation</organization>
<address> <address>
<email>johan.stenstam@internetstiftelsen.se</email> <email>johan.stenstam@internetstiftelsen.se</email>
</address> </address>
</author> </author>
<author initials="P." surname="Thomassen" fullname="Peter Thomassen"> <author initials="P." surname="Thomassen" fullname="Peter Thomassen">
<organization>deSEC, Secure Systems Engineering</organization> <organization>deSEC, Secure Systems Engineering</organization>
<address> <address>
<email>peter@desec.io</email> <email>peter@desec.io</email>
</address> </address>
</author> </author>
<author initials="J." surname="Levine" fullname="John Levine"> <author initials="J." surname="Levine" fullname="John Levine">
<organization>Standcore LLC</organization> <organization>Standcore LLC</organization>
<address> <address>
<email>standards@standcore.com</email> <email>standards@standcore.com</email>
</address> </address>
</author> </author>
<date/> <date month="September" year="2025"/>
<area>Internet</area> <area>OPS</area>
<workgroup>DNSOP Working Group</workgroup> <workgroup>dnsop</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <!-- [rfced] Please insert any keywords (beyond those that appear in the
<?line 37?> title) for use on https://www.rfc-editor.org/search.
-->
<keyword>example</keyword>
<abstract>
<t>This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond <t>This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond
conventional zone transfer hints, to allow triggering other types of actions conventional zone transfer hints to allow other types of actions
via the DNS that were previously lacking a trigger mechanism. that were previously lacking a trigger mechanism to be triggered via the DNS.
Notifications merely nudge the receiver to initiate a predefined action promptly Notifications merely nudge the receiver to initiate a predefined action promptly
(instead of on a schedule); they do not alter the action itself (instead of on a schedule); they do not alter the action itself
(including any security checks it might employ).</t> (including any security checks it might employ).</t>
<t>To enable this functionality, a method for discovering the receiver end point <t>To enable this functionality, a method for discovering the receiver end point
for such notification messages is introduced, via the new DSYNC record type. for such notification messages is introduced, via the new DSYNC record type.
Notification types are recorded in a new registry, with initial support for Notification types are recorded in a new registry, with initial support for
parental NS and DS record updates including DNSSEC bootstrapping.</t> parental NS and DS record updates including DNSSEC bootstrapping.</t>
<t>TO BE REMOVED: This document is being collaborated on in Github at:
<eref target="https://github.com/peterthomassen/draft-ietf-dnsop-generalized-not
ify">https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify</eref
>.
The most recent working version of the document, open issues, etc. should all be
available there. The authors (gratefully) accept pull requests.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 56?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Traditional DNS notifications <xref target="RFC1996"/>, which are here referred to as <t>Traditional DNS notifications <xref target="RFC1996"/>, which are here referred to as
"NOTIFY(SOA)", are sent from a primary server to a secondary server to "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 minimize the latter's convergence time to a new version of the
zone. This mechanism successfully addresses a significant inefficiency zone. This mechanism successfully addresses a significant inefficiency
in the original protocol.</t> in the original protocol.</t>
<t>Today similar inefficiencies occur in new use cases, in particular dele gation <t>Today, similar inefficiencies occur in new use cases, in particular, de legation
maintenance (DS and NS record updates). Just as in the NOTIFY(SOA) case, a new 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 set of notification types will have a major positive benefit by
allowing the DNS infrastructure to completely sidestep these allowing the DNS infrastructure to completely sidestep these
inefficiencies. For additional context, see <xref target="context"/>.</t> inefficiencies. For additional context, see <xref target="context"/>.</t>
<t>Although this document primarily deals with applying generalized notifi cations <t>Although this document primarily deals with applying generalized notifi cations
to the delegation maintenance use case, future extension for other applications to the delegation maintenance use case, future extension for other applications
(such as multi-signer key exchange) is possible.</t> (such as multi-signer key exchange) is possible.</t>
<t>No DNS protocol changes are introduced by this document. The mechanism <t>No DNS protocol changes are introduced by this document. Instead, the m
instead makes use of a wider range of DNS messages allowed by the protocol.</t> echanism
makes use of a wider range of DNS messages allowed by the protocol.</t>
<t>Readers are expected to be familiar with DNSSEC <xref target="RFC9364"/ >, including <t>Readers are expected to be familiar with DNSSEC <xref target="RFC9364"/ >, including
<xref target="RFC6781"/>, <xref target="RFC7344"/>, <xref target="RFC7477"/>, <x ref target="RFC7583"/>, <xref target="RFC8078"/>, <xref target="RFC6781"/>, <xref target="RFC7344"/>, <xref target="RFC7477"/>, <x ref target="RFC7583"/>, <xref target="RFC8078"/>,
<xref target="RFC8901"/>, and <xref target="RFC9615"/>. <xref target="RFC8901"/>, and <xref target="RFC9615"/>.
DNS-specific terminology can be found in <xref target="RFC9499"/>.</t> DNS-specific terminology can be found in <xref target="RFC9499"/>.</t>
<section anchor="design-goals-for-delegation-maintenance"> <section anchor="design-goals-for-delegation-maintenance">
<name>Design Goals for Delegation Maintenance</name> <name>Design Goals for Delegation Maintenance</name>
<t>When the parent operator is interested in notifications for delegatio n <t>When the parent operator is interested in notifications for delegatio n
maintenance (such as DS or NS update hints), a service will need to be maintenance (such as DS or NS update hints), a service to accept these notificat
made available for accepting these notifications. Depending on the ions will need to be
context, this service may be run by the parent operator themselves, made available. Depending 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 or by a designated entity who is in charge of handling the domain's
delegation data (such as a domain registrar).</t> delegation data (such as a domain registrar).</t>
<t>It seems desirable to minimize the number of steps that the notificat ion sender <t>It seems desirable to minimize the number of steps that the notificat ion sender
needs to perform in order to figure out where to send the NOTIFY. This suggests needs to perform in order to figure out where to send the NOTIFY. This suggests
that the lookup process be ignorant of the details of the parent-side 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 relationships (e.g., whether or not there is a registrar.) This is
addressed by parameterizing the lookup with the name of the child. The addressed by parameterizing the lookup with the name of the child. The
parent operator may then (optionally) announce the notification endpoint parent operator may then (optionally) announce the notification endpoint
in a delegation-specific way, by publishing it at a child-specific name. in a delegation-specific way by publishing it at a child-specific name.
(A catch-all endpoint may be indicated by wildcarding.)</t> (A catch-all endpoint may be indicated by wildcarding.)</t>
<t>The solution proposed here is thus for the parent operator to publish <t>The solution proposed here is thus for the parent operator to publish
the address where someone listens for notifications, in a child-specific the address where someone listens for notifications, in a child-specific
way (see <xref target="signaling"/>). Potential senders can easily determine the name way (see <xref target="signaling"/>). Potential senders can easily determine the name
of the parent and then look up that information (see <xref target="discovery"/>) .</t> of the parent and then look up that information (see <xref target="discovery"/>) .</t>
</section> </section>
<section anchor="requirements-notation"> <section anchor="requirements-notation">
<name>Requirements Notation</name> <name>Requirements Notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and ",
only when, they "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
appear in all capitals, as shown here. "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<?line -6?> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t> </t>
</section> </section>
</section> </section>
<section anchor="dsyncrdtype"> <section anchor="dsyncrdtype">
<name>DSYNC RR Type</name> <name>DSYNC RR Type</name>
<t>This section defines the DSYNC RR type which is subsequently used for <t>This section defines the DSYNC RR type, which is subsequently used for
discovering notification endpoints.</t> discovering notification endpoints.</t>
<section anchor="wire-format"> <section anchor="wire-format">
<name>Wire Format</name> <name>Wire Format</name>
<t>The DSYNC RDATA wire format is encoded as follows:</t> <t>The DSYNC RDATA wire format is encoded as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
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 ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/]]></artwork>
]]></artwork> <dl spacing="normal">
<dl> <dt>RRtype:</dt>
<dt>RRtype</dt>
<dd> <dd>
<t>The type of generalized NOTIFY that this DSYNC RR defines the <t>The type of generalized NOTIFY that this DSYNC RR defines the
desired target address for (see "Resource Record (RR) TYPEs" IANA desired target address for (see the "Resource Record (RR) TYPEs"
registry). For now, only CDS and CSYNC are supported values, with registry). For now, only CDS and CSYNC are supported values, with
the former indicating an updated CDS or CDNSKEY record set.</t> the former indicating an updated CDS or CDNSKEY record set.</t>
</dd> </dd>
<dt>Scheme</dt> <dt>Scheme:</dt>
<dd> <dd>
<t>The mode used for contacting the desired notification address. Th is is an <t>The mode used for contacting the desired notification address. Th is is an
8-bit unsigned integer. Records with value 0 (null scheme) are ignored by consum ers. 8-bit unsigned integer. Records with value 0 (null scheme) are ignored by consum ers.
Value 1 is described in this document, and values 128-255 are reserved for Value 1 is described in this document, and values 128-255 are Reserved for
private use. All other values are currently unassigned.</t> Private Use. All other values are currently unassigned.</t>
</dd> </dd>
<dt>Port</dt> <dt>Port:</dt>
<dd> <dd>
<t>The port on the target host of the notification service. This <t>The port on the target host of the notification service. This
is a 16-bit unsigned integer in network byte order. Records with is a 16-bit unsigned integer in network byte order. Records with
value 0 are ignored by consumers.</t> value 0 are ignored by consumers.</t>
</dd> </dd>
<dt>Target</dt> <dt>Target:</dt>
<dd> <dd>
<t>The fully-qualified, uncompressed domain name of the target host <t>The fully-qualified, uncompressed domain name of the target host
providing the service of listening for generalized notifications of the providing the service of listening for generalized notifications of the
specified type. This name MUST resolve to one or more address records.</t> specified type. This name <bcp14>MUST</bcp14> resolve to one or more address rec ords.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="presentation-format"> <section anchor="presentation-format">
<name>Presentation Format</name> <name>Presentation Format</name>
<t>The presentation format of the RDATA portion is as follows:</t> <t>The presentation format of the RDATA portion is as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The RRtype field is represented as a mnemonic from the "Resource <t>The RRtype field is represented as a mnemonic from the "Resource
Record (RR) TYPEs" registry.</t> Record (RR) TYPEs" registry.</t>
</li> </li>
<li> <li>
<t>The Scheme field is represented by its mnemonic if assigned (see <t>The Scheme field is represented by its mnemonic, if assigned (see
<xref target="schemeregistry"/>), otherwise as an unsigned decimal integer.</t> <xref target="schemeregistry"/>), and is otherwise represented as an unsigned de
cimal integer.</t>
</li> </li>
<li> <li>
<t>The Port field is represented as an unsigned decimal integer.</t> <t>The Port field is represented as an unsigned decimal integer.</t>
</li> </li>
<li> <li>
<t>The Target field is represented as a &lt;domain-name&gt; (<xref s ection="5.1" sectionFormat="comma" target="RFC1035"/>).</t> <t>The Target field is represented as a &lt;domain-name&gt; (<xref s ection="5.1" target="RFC1035"/>).</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="semantics"> <section anchor="semantics">
<name>Semantics</name> <name>Semantics</name>
<t>For now, the only scheme defined is 1 (mnemonic: NOTIFY). By publish ing a <t>For now, the only scheme defined is 1 (mnemonic: NOTIFY). By publish ing a
DSYNC record with this scheme, a parent indicates that they would like child DSYNC record with this scheme, a parent indicates that they would like child
operators to send them a NOTIFY message (see <xref target="cnotify"/>) upon publ ication of operators to send them a NOTIFY message (see <xref target="cnotify"/>) upon publ ication of
a new CDS/CDNSKEY/CSYNC RRset, to the address and port listed in that DSYNC a new CDS/CDNSKEY/CSYNC RRset to the address and port listed in that DSYNC
record and using conventional <xref target="RFC1035"/> DNS transport.</t> record and using conventional DNS transport <xref target="RFC1035"/>.</t>
<t>Example (for the owner names of these records, see <xref target="sign aling"/>):</t> <t>Example (for the owner names of these records, see <xref target="sign aling"/>):</t>
<artwork><![CDATA[ <artwork><![CDATA[
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.
]]></artwork> ]]></artwork>
<t>Should a need for other mechanisms arise, other schemes may be define d <t>Should a need for other mechanisms arise, other schemes may be define d
to deal with such requirements using alternative logic.</t> to deal with such requirements using alternative logic.</t>
<t>Schemes are independent of RRtype. They merely specify a method of <t>Schemes are independent of the RRtype. They merely specify a method o f
contacting the target (whereas the RRtype is part of the notification contacting the target (whereas the RRtype is part of the notification
payload).</t> payload).</t>
</section> </section>
</section> </section>
<section anchor="signaling"> <section anchor="signaling">
<name>Publication of Notification Targets</name> <name>Publication of Notification Targets</name>
<t>To use generalized notifications, it is necessary for the sender to kno w <t>To use generalized notifications, it is necessary for the sender to kno w
where to direct each NOTIFY message. This section describes the where to direct each NOTIFY message. This section describes the
procedure for discovering that notification target.</t> procedure for discovering that notification target.</t>
<t>Note that generalized NOTIFY messages are but one mechanism for <t>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 (<xref target="RFC2136"/>), may (or may not) be more suitable in DNS Update <xref target="RFC2136"/>, may (or may not) be more suitable in
individual cases. Like generalized notifications, they similarly require individual cases. Like generalized notifications, they similarly require
a means for discovering where to send the API or DNS Update requests.</t> a means for discovering where to send the API or DNS Update requests.</t>
<t>As the scope for the publication mechanism is wider than only to <t>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 section.</t> independently of the notification method is specified in this section.</t>
<t>Parent operators participating in the discovery scheme for the purpose of <t>Parent operators participating in the discovery scheme for the purpose of
delegation maintenance notifications MUST publish endpoint information delegation maintenance notifications <bcp14>MUST</bcp14> publish endpoint inform ation
using the record type defined in <xref target="dsyncrdtype"/> under the <tt>_dsy nc</tt> using the record type defined in <xref target="dsyncrdtype"/> under the <tt>_dsy nc</tt>
subdomain of the parent zone, as described in the following subsections.</t> subdomain of the parent zone, as described in the following subsections.</t>
<t>There MUST NOT be more than one DSYNC record for each combination of <t>There <bcp14>MUST NOT</bcp14> be more than one DSYNC record for each co mbination of
RRtype and Scheme. RRtype and Scheme.
It is RECOMMENDED to secure zones containing DSYNC records with DNSSEC.</t> It is <bcp14>RECOMMENDED</bcp14> that zones containing DSYNC records with DNSSEC
<t>For practical purposes, the parent operator MAY delegate the <tt>_dsync be secure.</t>
</tt> <t>For practical purposes, the parent operator <bcp14>MAY</bcp14> delegate
domain as a separate zone, and/or synthesize records under it. If the <tt>_dsync</tt>
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.</t> wildcard DSYNC record.</t>
<section anchor="wildcard-method"> <section anchor="wildcard-method">
<name>Wildcard Method</name> <name>Wildcard Method</name>
<t>If the parent operator itself performs CDS/CDNSKEY or CSYNC processin g <t>If the parent operator itself performs CDS/CDNSKEY or CSYNC processin g
for some or all delegations, or wants to forward notifications to some for some or all delegations, or if the parent operator wants to forward notifica tions to some
other party, a default notification target may be specified as follows:</t> other party, a default notification target may be specified as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
*._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
]]></artwork> ]]></artwork>
<t>To accommodate indirect delegation management models, the <t>To accommodate indirect delegation management models, the
designated notification target may relay notifications to a third party designated notification target may relay notifications to a third party
(such as the registrar, in ICANN's model). The details of such (such as the registrar, in ICANN's model). The details of such
arrangements are out of scope for this document.</t> arrangements are out of scope for this document.</t>
<t>If for some reason the parent operator cannot publish wildcard record s, <t>If for some reason the parent operator cannot publish wildcard record s,
the wildcard label may be dropped from the DSYNC owner name (i.e., it the wildcard label may be dropped from the DSYNC owner name (i.e., it
may be published at the <tt>_dsync</tt> label instead). This practice requires may be published at the <tt>_dsync</tt> label instead). This practice requires
an additional step during discovery (see <xref target="discovery"/>), and is an additional step during discovery (see <xref target="discovery"/>) and is
therefore NOT RECOMMENDED.</t> therefore <bcp14>NOT RECOMMENDED</bcp14>.</t>
</section> </section>
<section anchor="child-specific-method"> <section anchor="child-specific-method">
<name>Child-specific Method</name> <name>Child-specific Method</name>
<t>It is also possible to publish child-specific records where the paren t zone's <t>It is also possible to publish child-specific records where the paren t zone's
labels are stripped from the child's FQDN and the result is used in place of labels are stripped from the child's Fully Qualified Domain Name (FQDN), and the result is used in place of
the wildcard label.</t> the wildcard label.</t>
<t>As an example, consider a registrar offering domains like <t>As an example, consider a registrar offering domains like
<tt>child.example</tt>, delegated from <tt>example</tt> zone. If the registrar <tt>child.example</tt>, delegated from <tt>example</tt> zone. If the registrar
provides the notification endpoint, e.g., <tt>rr-endpoint.example:5300</tt>, provides the notification endpoint, e.g., <tt>rr-endpoint.example:5300</tt>,
the parent may publish this information as follows:</t> the parent may publish this information as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
child._dsync.example. IN DSYNC CDS NOTIFY 5300 rr-endpoint.example. child._dsync.example. IN DSYNC CDS NOTIFY 5300 rr-endpoint.example.
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="cnotify"> <section anchor="cnotify">
<name>Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications</name> <name>Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications</name>
<t>Delegation maintenance notifications address the inefficiencies related <t>Delegation maintenance notifications address the inefficiencies related
to scanning child zones for CDS/CDNSKEY records to scanning child zones for CDS/CDNSKEY records
<xref target="RFC7344"/><xref target="RFC8078"/><xref target="RFC9615"/>. (For a n overview of the issues, <xref target="RFC7344"/><xref target="RFC8078"/> <xref target="RFC9615"/>. (For an overview of the issues,
see <xref target="context"/>.)</t> see <xref target="context"/>.)</t>
<t>NOTIFY messages for delegation maintenance MUST be formatted as describ ed in <t>NOTIFY messages for delegation maintenance <bcp14>MUST</bcp14> be forma tted as described in
<xref target="RFC1996"/>, with the <tt>qtype</tt> field replaced as appropriate. </t> <xref target="RFC1996"/>, with the <tt>qtype</tt> field replaced as appropriate. </t>
<t>To address the CDS/CDNSKEY dichotomy, the NOTIFY(CDS) message (with <t>To address the CDS/CDNSKEY dichotomy, the NOTIFY(CDS) message (with
<tt>qtype=CDS</tt>) is defined to indicate any child-side changes pertaining <tt>qtype=CDS</tt>) is defined to indicate any child-side changes pertaining
to an upcoming update of DS records. to an upcoming update of DS records.
As the child DNS operator generally is unaware of whether the parent As the child DNS operator generally is unaware of whether the parent
side consumes CDS records or prefers CDNSKEY, or when that policy side consumes CDS records or prefers CDNSKEY, or when that policy
changes, it seems advisable to publish both types of records, changes, it seems advisable to publish both types of records,
preferably using automation features of common authoritative nameserver preferably using automation features of common authoritative nameserver
software for ensuring consistency.</t> software for ensuring consistency.</t>
<t>Upon receipt of NOTIFY(CDS), the parent-side recipient (typically, regi stry or <t>Upon receipt of NOTIFY(CDS), the parent-side recipient (typically, regi stry or
registrar) SHOULD initiate the same DNS lookups and verifications for registrar) <bcp14>SHOULD</bcp14> initiate the same DNS lookups and verifications for
DNSSEC bootstrapping <xref target="RFC9615"/> or DS maintenance DNSSEC bootstrapping <xref target="RFC9615"/> or DS maintenance
<xref target="RFC7344"/><xref target="RFC8078"/> that would otherwise be trigger ed based on a <xref target="RFC7344"/> <xref target="RFC8078"/> that would otherwise be trigge red based on a
timer.</t> timer.</t>
<t>The CSYNC <xref target="RFC7477"/> inefficiency may be similarly treate d, with the <t>The CSYNC <xref target="RFC7477"/> inefficiency may be similarly treate d, with the
child sending a NOTIFY(CSYNC) message (with <tt>qtype=CSYNC</tt>) to an address child sending a NOTIFY(CSYNC) message (with <tt>qtype=CSYNC</tt>) to an address
where the parent operator (or a designated party) is listening for CSYNC where the parent operator (or a designated party) is listening for CSYNC
notifications.</t> notifications.</t>
<t>In both cases the notification will speed up processing times by <t>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.</t> published new CDS, CDNSKEY, and/or CSYNC records.</t>
<section anchor="discovery"> <section anchor="discovery">
<name>Endpoint Discovery</name> <name>Endpoint Discovery</name>
<t>To locate the target for outgoing delegation maintenance notification s, <t>To locate the target for outgoing delegation maintenance notification s,
the notification sender MUST perform the following steps:</t> the notification sender <bcp14>MUST</bcp14> perform the following steps:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<t>Construct the lookup name, by inserting the <tt>_dsync</tt> label <li>
after the <t>Construct the lookup name by inserting the <tt>_dsync</tt> label
after the
first label of the delegation owner name.</t> first label of the delegation owner name.</t>
</li> </li>
<li> <li>
<t>Perform a lookup of type DSYNC for the lookup name, and validate the <t>Perform a lookup of type DSYNC for the lookup name, and validate the
response if DNSSEC is enabled. If this results in a positive DSYNC answer, response if DNSSEC is enabled. If this results in a positive DSYNC answer,
return it.</t> return it.</t>
</li> </li>
<li> <li>
<t>If the query resulted in a negative response: </t> <t>If the query resulted in a negative response: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the response's SOA record indicates that the parent is mor e than <t>If the response's SOA record indicates that the parent is mor e than
one label away from the <tt>_dsync</tt> label, construct a new lookup name one label away from the <tt>_dsync</tt> label, construct a new lookup name
by inserting the <tt>_dsync</tt> label into the delegation owner name just by inserting the <tt>_dsync</tt> label into the delegation owner name just
before the parent zone labels inferred from the negative response, before the parent zone labels inferred from the negative response.
and go to step 2. </t> Then go to step 2.</t>
<t> <t>
For example, assume that <tt>subsub.sub.child.example</tt> is delegated from For example, assume that <tt>subsub.sub.child.example</tt> is delegated from
<tt>example</tt> (and not from <tt>sub.child.example</tt> or <tt>child.example</ tt>). The <tt>example</tt> (and not from <tt>sub.child.example</tt> or <tt>child.example</ tt>). The
initial DSYNC query relating to it is thus directed at initial DSYNC query relating to it is thus directed at
<tt>subsub._dsync.sub.child.example</tt>. This is expected to result in a <tt>subsub._dsync.sub.child.example</tt>. This is expected to result in a
negative response from <tt>example</tt>, and another query for negative response from <tt>example</tt>, and another query for
<tt>subsub.sub.child._dsync.example</tt> is then required.</t> <tt>subsub.sub.child._dsync.example</tt> is then required.</t>
</li> </li>
<li> <li>
<t>Otherwise, if the lookup name has any labels in front of the <t>Otherwise, if the lookup name has any labels in front of the
<tt>_dsync</tt> label, remove them to construct a new lookup name (such <tt>_dsync</tt> label, remove them to construct a new lookup name (such
as <tt>_dsync.example</tt>), and go to step 2. as <tt>_dsync.example</tt>). Then go to step 2.
(This is to enable zone structures without wildcards.)</t> (This is to enable zone structures without wildcards.)</t>
</li> </li>
<li> <li>
<t>Otherwise, return null (no notification target available).</t > <t>Otherwise, return null (no notification target available).</t >
</li> </li>
</ul> </ul>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="sending-notifications"> <section anchor="sending-notifications">
<name>Sending Notifications</name> <name>Sending Notifications</name>
<t>When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child zone , <t>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 the DNS operator <bcp14>SHOULD</bcp14> send a suitable notification to one of th e
endpoints discovered as described in the previous section.</t> endpoints discovered as described in the previous section.</t>
<t>A NOTIFY message can only carry information about changes concerning one <t>A NOTIFY message can only carry information about changes concerning one
child zone. When there are changes to several child zones, the sender child zone. When there are changes to several child zones, the sender
MUST send a separate notification for each one.</t> <bcp14>MUST</bcp14> send a separate notification for each one.</t>
<t>When a primary name server publishes a new RRset in the child, there <t>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 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 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 publication, there is a potential for CDS/CDNSKEY/CSYNC processing to be
attempted before the corresponding records are served. As a result, a attempted before the corresponding records are served. As a result, a
desired update may not be detected (or appear inconsistent), preventing desired update may not be detected (or appear inconsistent), preventing
it from being applied.</t> it from being applied.</t>
<t>It is therefore RECOMMENDED that the child delays sending notificatio ns <t>Therefore, it is <bcp14>RECOMMENDED</bcp14> that the child delay send ing notifications
to the recipient until a consistent public view of the pertinent to the recipient until a consistent public view of the pertinent
records is ensured.</t> records is ensured.</t>
<section anchor="timeouts-and-error-handling"> <section anchor="timeouts-and-error-handling">
<name>Timeouts and Error Handling</name> <name>Timeouts and Error Handling</name>
<t>NOTIFY messages are expected to elicit a response from the recipien t <t>NOTIFY messages are expected to elicit a response from the recipien t
(<xref target="RFC1996"/> Section 4.7). If no response is received, senders SHOU (<xref target="RFC1996"/>, Section 4.7). If no response is received, senders <bc
LD p14>SHOULD</bcp14>
employ the same logic as for SOA notifications (<xref target="RFC1996"/> Section employ the same logic as for SOA notifications (<xref target="RFC1996"/>, Sectio
s ns 3.5 and 3.6).</t>
3.5 and 3.6).</t>
<t>The recipient's attempt to act upon the delegation update request m ay <t>The recipient's attempt to act upon the delegation update request m ay
fail for a variety of reasons (e.g., due to violation of the continuity fail for a variety of reasons (e.g., due to violation of the continuity
requirement set forth in <xref target="RFC7344"/> Section 4.1). Such failures ma y requirement set forth in <xref target="RFC7344" sectionFormat="comma" section="4 .1"/>). Such failures may
occur asynchronously, even after the NOTIFY response has been sent.</t> occur asynchronously, even after the NOTIFY response has been sent.</t>
<t>In order to learn about such failures, senders MAY include an <t>In order to learn about such failures, senders <bcp14>MAY</bcp14> i
<xref target="RFC9567"/> EDNS0 Report-Channel option in the NOTIFY message to nclude an
request the receiving side to report any errors by making a report query EDNS0 Report-Channel option <xref target="RFC9567"/> in the NOTIFY message to
request that the receiving side report any errors by making a report query
with an appropriate extended DNS error code as described in with an appropriate extended DNS error code as described in
<xref target="RFC8914"/>. <xref target="RFC8914"/>.
(The prohibition of this option in queries (<xref section="6.1" sectionFormat="c omma" target="RFC9567"/>) only (The prohibition of this option in queries (<xref section="6.1" sectionFormat="c omma" target="RFC9567"/>) only
applies to resolver queries and thus does not cover NOTIFY messages.)</t> applies to resolver queries and thus does not cover NOTIFY messages.)</t>
<t>When including this EDNS0 option, its agent domain MUST be subordin ate <t>When including this EDNS0 option, its agent domain <bcp14>MUST</bcp 14> be subordinate
or equal to one of the NS hostnames, as listed in the child's delegation or equal to one of the NS hostnames, as listed in the child's delegation
in the parent zone. in the parent zone.
This is to prevent malicious senders from causing the NOTIFY recipient This is to prevent malicious senders from causing the NOTIFY recipient
to send unsolicited report queries to unrelated third parties.</t> to send unsolicited report queries to unrelated third parties.</t>
</section> </section>
<section anchor="roles"> <section anchor="roles">
<name>Roles</name> <name>Roles</name>
<t>While the CDS/CDNSKEY/CSYNC processing following the receipt of a N OTIFY <t>While the CDS/CDNSKEY/CSYNC processing that follows the receipt of a NOTIFY
will often be performed by the registry, the protocol anticipates that will often be performed by the registry, the protocol anticipates that
in some contexts (especially for ICANN gTLDs), registrars may take on in some contexts (especially for ICANN gTLDs) registrars may take on
the task. In such cases, the current registrar notification endpoint may the task. In such cases, the current registrar notification endpoint may
be published, enabling notifications to be directed to the be published, enabling notifications to be directed to the
appropriate target. The mechanics of how this is arranged between appropriate target. The mechanics of how this is arranged between
registry and registrar are out of scope for this document; the protocol registry and registrar are out of scope for this document; the protocol
only offers the possibility to arrange things such that from the child only offers the possibility to arrange things such that from the child
perspective, it is inconsequential how the parent-side parties are perspective, how the parent-side parties are
organized: notifications are simply sent to the published address.</t> organized is inconsequential: Notifications are simply sent to the published add
ress.</t>
<t>Because of the security model where a notification by itself never <t>Because of the security model where a notification by itself never
causes a change (it can only speed up the time until the next 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. 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 This opens up the possibility of having an arbitrary party (e.g., a
side-car service) send the notifications, enabling this functionality side-car service) send the notifications, enabling this functionality
even before the emergence of native support in nameserver software.</t> even before the emergence of native support in nameserver software.</t>
</section> </section>
</section> </section>
<section anchor="processing-of-notify-messages-for-delegation-maintenance" > <section anchor="processing-of-notify-messages-for-delegation-maintenance" >
<name>Processing of NOTIFY Messages for Delegation Maintenance</name> <name>Processing of NOTIFY Messages for Delegation Maintenance</name>
skipping to change at line 388 skipping to change at line 389
<t>Because of the security model where a notification by itself never <t>Because of the security model where a notification by itself never
causes a change (it can only speed up the time until the next 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. 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 This opens up the possibility of having an arbitrary party (e.g., a
side-car service) send the notifications, enabling this functionality side-car service) send the notifications, enabling this functionality
even before the emergence of native support in nameserver software.</t> even before the emergence of native support in nameserver software.</t>
</section> </section>
</section> </section>
<section anchor="processing-of-notify-messages-for-delegation-maintenance" > <section anchor="processing-of-notify-messages-for-delegation-maintenance" >
<name>Processing of NOTIFY Messages for Delegation Maintenance</name> <name>Processing of NOTIFY Messages for Delegation Maintenance</name>
<t>The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC) proc essing.</t> <t>The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC) proc essing.</t>
<t>NOTIFY messages carrying notification payloads (records) for more <t>NOTIFY messages carrying notification payloads (records) for more
than one child zone MUST be discarded, as sending them is an error.</t> than one child zone <bcp14>MUST</bcp14> be discarded, as sending them is an erro r.</t>
<t>Otherwise, upon receipt of a (potentially forwarded) NOTIFY message f or <t>Otherwise, upon receipt of a (potentially forwarded) NOTIFY message f or
a particular child zone at the published notification endpoint, a particular child zone at the published notification endpoint,
the receiving side (parent registry or registrar) has two options:</t> the receiving side (parent registry or registrar) has two options:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<li>
<t>Acknowledge receipt by sending a NOTIFY response as described in <t>Acknowledge receipt by sending a NOTIFY response as described in
<xref target="RFC1996"/> Section 4.7, and schedule <xref target="RFC1996"/>, Section 4.7, and schedule
an immediate check of the CDS/CDNSKEY/CSYNC RRsets published by that an immediate check of the CDS/CDNSKEY/CSYNC RRsets published by that
particular child zone (as appropriate for the type of NOTIFY received). </t> particular child zone (as appropriate for the type of NOTIFY received). </t>
<t> <t>
If the NOTIFY message contains an <xref target="RFC9567"/> EDNS0 Report-Channel If the NOTIFY message contains an EDNS0 Report-Channel
option with an agent domain subordinate or equal to one of the NS option <xref target="RFC9567"/> with an agent domain subordinate or equal to one
hostnames listed in the delegation, the processing party SHOULD of the NS
hostnames listed in the delegation, the processing party <bcp14>SHOULD</bcp14>
report any errors occurring during CDS/CDNSKEY/CSYNC processing by sending report any errors occurring during CDS/CDNSKEY/CSYNC processing by sending
a report query with an appropriate extended DNS error code as a report query with an appropriate extended DNS error code as
described in <xref target="RFC8914"/>. Reporting may be done asynchronously described in <xref target="RFC8914"/>. Reporting may be done asynchronously
(outside of the NOTIFY transaction). </t> (outside of the NOTIFY transaction). </t>
<t> <t>
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/CSYNC RRset timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/CSYNC RRset
is indeed new or has changed, the corresponding child's timer may 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). be reset and the scanning frequency reduced (e.g., to once a week).
If a CDS/CDNSKEY/CSYNC change is later detected through scanning (without If a CDS/CDNSKEY/CSYNC change is later detected through scanning (without
having received a notification), NOTIFY-related state SHOULD be having received a notification), the NOTIFY-related state <bcp14>SHOULD</bcp14> be
cleared, reverting to the default scanning schedule for this child. </t> cleared, reverting to the default scanning schedule for this child. </t>
<t> <t>
When introducing CDS/CDNSKEY/CSYNC scanning support at the same time When introducing CDS/CDNSKEY/CSYNC scanning support at the same time
as NOTIFY support, backwards compatibility considerations as NOTIFY support, backwards compatibility considerations
regarding the scanning interval do not apply; a low-frequency regarding the scanning interval do not apply; thus, a low-frequency
scanning schedule MAY thus be used by default in such cases.</t> scanning schedule <bcp14>MAY</bcp14> be used by default in such cases.</t>
</li> </li>
<li> <li>
<t>Do not act upon the notification. To prevent retries, recipients <t>Do not act upon the notification. To prevent retries, recipients
SHOULD acknowledge the notification by sending a NOTIFY response <bcp14>SHOULD</bcp14> 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 rate query if feasible (see above). One reason to do this may be a rate
limit (see <xref target="security"/>), in which case "Blocked" (15) may be a limit (see <xref target="security"/>), in which case Blocked (15) may be a
suitable extended DNS error code.</t> suitable extended DNS error code.</t>
</li> </li>
</ol> </ol>
<t>Implementing the first option will significantly decrease the <t>Implementing the first option will significantly decrease the
convergence time (between publication of a new CDS/CDNSKEY/CSYNC record in the convergence time (between publication of a new CDS/CDNSKEY/CSYNC record in the
child and publication of the resulting DS), thereby providing improved child and publication of the resulting DS), thereby providing improved
service for the child.</t> service for the child.</t>
<t>If, in addition to scheduling an immediate check for the child zone o f <t>If, in addition to scheduling an immediate check for the child zone o f
the notification, the scanning schedule is also modified to be less the notification, the scanning schedule is also modified to be less
frequent, the cost of providing the scanning service will be reduced.</t> frequent, the cost of providing the scanning service will be reduced.</t>
</section> </section>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>If an action is triggered by the receipt of a DNS NOTIFY, its execution relies <t>If an action is triggered by the receipt of a DNS NOTIFY, its execution relies
on the same security model which the receiving party would apply if the action on the same security model that the receiving party would apply if the action
had been triggered by something else. This is because the notification affects were triggered by something else. This is because the notification affects
the action's timing alone. For example, DS bootstrapping is expected to be the action's timing alone. For example, DS bootstrapping is expected to be
performed the same way independently of the type of trigger; this includes all performed the same way, independently of the type of trigger; this includes all
security and authentication requirements (e.g., <xref target="RFC9615"/>) which security and authentication requirements (e.g., <xref target="RFC9615"/>) that t
the parent he parent
registry/registrar has chosen to apply.</t> registry/registrar has chosen to apply.</t>
<t>The original NOTIFY specification sidesteps most security issues by not <t>The original NOTIFY specification sidesteps most security issues by not
relying on the information in the NOTIFY message in any way, and instead 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 only using it to "enter the state it would if the zone's refresh timer
had expired" (<xref section="4.7" sectionFormat="of" target="RFC1996"/>).</t> had expired" (Section 4.7 of <xref target="RFC1996"/>).</t>
<t>This security model is reused for generalized NOTIFY messages. It <t>This security model is reused for generalized NOTIFY messages. Therefor
therefore seems impossible to affect the behaviour of the recipient of e, it
seems impossible to affect the behaviour of the recipient of
the NOTIFY other than by hastening the timing for when different checks the NOTIFY other than by hastening the timing for when different checks
are initiated. are initiated.
As a consequence, while notifications themselves can be secured via access As a consequence, while notifications themselves can be secured via access
control mechanisms, this is not a requirement.</t> control mechanisms, this is not a requirement.</t>
<t>The receipt of a notification message will, in general, cause the <t>In general, the receipt of a notification message will cause the
receiving party to perform one or more outbound queries for the records receiving party to perform one or more outbound queries for the records
of interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEY 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.</t> can refer to one child only.</t>
<!-- [rfced] How may "unreasonable" be clarified? We ask because we aren't
sure if this will be completely clear to the reader.
Current:
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 applies, even under unreasonable events.
-->
<t>However, when the outgoing query occurs via encrypted transport, some <t>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 the computational burden. In this case, the usual principle of bounding the
work, even under unreasonable events, applies.</t> work applies, even under unreasonable events.</t>
<t>Receivers therefore MUST implement rate limiting for notification <t>Therefore, receivers <bcp14>MUST</bcp14> implement rate limiting for no
processing. It is RECOMMENDED to configure rate limiting independently tification
processing. It is <bcp14>RECOMMENDED</bcp14> to configure rate limiting independ
ently
for both the notification's source IP address and the name of the zone 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 that is conveyed in the NOTIFY message. Rate limiting also mitigates
processing load from garbage notifications.</t> the processing load from garbage notifications.</t>
<t>Alternative solutions (such as signing notifications and validating <t>Alternative solutions (such as signing notifications and validating
their signatures) appear significantly more expensive without tangible their signatures) appear significantly more expensive without tangible
benefit.</t> benefit.</t>
<t>In order to facilitate schemes that are authenticated outside of DNSSEC <t>In order to facilitate schemes that are authenticated outside of DNSSEC
(such as via SIG(0)), zones containing DSYNC records are not required to (such as via SIG(0)), zones containing DSYNC records are not required to
be signed. Spoofed DSYNC responses would prevent notifications from be signed. Spoofed DSYNC responses would prevent notifications from
reaching their legitimate target, and a different party may receive reaching their legitimate target, and a different party may receive
unsolicited notifications; both effects, however, can also be achieved unsolicited notifications; however, both effects can also be achieved
in the presence of DNSSEC. The illegitimate target is also enabled to in the presence of DNSSEC. The illegitimate target is also enabled to
learn notification contents in real-time, which may be a privacy concern 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 for the sender. If so, the sender may choose to ignore unsigned DSYNC
records.</t> records.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t><strong>Note to the RFC Editor</strong>: In this section, please replac e occurrences of "(this document)" with a proper reference.</t>
<section anchor="dsync-rr-type"> <section anchor="dsync-rr-type">
<name>DSYNC RR Type</name> <name>DSYNC RR Type</name>
<t>IANA is requested to update the "Resource Record (RR) TYPEs" registry <t>IANA has registered DSYNC in the "Resource Record (RR) TYPEs" registr
under the "Domain Name System (DNS) Parameters" registry group as y
follows:</t> under the "Domain Name System (DNS) Parameters" registry group as follows:</t>
<dl>
<dt>Type</dt> <dl spacing="compact" newline="false">
<dd> <dt>Type:</dt> <dd>DSYNC</dd>
<t>DSYNC</t> <dt>Value:</dt> <dd>66</dd>
</dd> <dt>Meaning:</dt> <dd>Endpoint discovery for delegation
<dt>Value</dt> synchronization</dd>
<dd> <dt>Reference:</dt> <dd>RFC 9859</dd>
<t>66</t>
</dd>
<dt>Meaning</dt>
<dd>
<t>Endpoint discovery for delegation synchronization</t>
</dd>
<dt>Reference</dt>
<dd>
<t>(this document)</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="schemeregistry"> <section anchor="schemeregistry">
<name>DSYNC Scheme Registration</name> <name>DSYNC Scheme Registration</name>
<t>IANA is requested to create and maintain the following new registry i n the <t>IANA has created the following new registry in the
"Domain Name System (DNS) Parameters" registry group:</t> "Domain Name System (DNS) Parameters" registry group:</t>
<dl> <dl spacing="compact" newline="false">
<dt>Name</dt> <dt>Name:</dt> <dd>DSYNC: Location of Synchronization Endpoints</dd>
<dd> <dt>Registration Procedure:</dt> <dd>Expert Review</dd>
<t>DSYNC: Location of Synchronization Endpoints</t> <dt>Reference:</dt> <dd>RFC 9859</dd>
</dd>
<dt>Assignment Policy</dt>
<dd>
<t>Expert Review</t>
</dd>
<dt>Reference</dt>
<dd>
<t>(this document)</t>
</dd>
</dl> </dl>
<t>The initial contents for the registry are as follows:</t> <t>The initial contents for the registry are as follows:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">RRtype</th> <th align="left">RRtype</th>
<th align="left">Scheme</th> <th align="left">Scheme</th>
<th align="left">Mnemonic</th> <th align="left">Mnemonic</th>
<th align="left">Purpose</th> <th align="left">Purpose</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> </td> <td align="left"> </td>
<td align="left">0</td> <td align="left">0</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">Null scheme (no-op)</td> <td align="left">Null scheme (no-op)</td>
<td align="left">(this document)</td> <td align="left">RFC 9859</td>
</tr> </tr>
<tr> <tr>
<td align="left">CDS</td> <td align="left">CDS</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">NOTIFY</td> <td align="left">NOTIFY</td>
<td align="left">Delegation management</td> <td align="left">Delegation management</td>
<td align="left">(this document)</td> <td align="left">RFC 9859</td>
</tr> </tr>
<tr> <tr>
<td align="left">CSYNC</td> <td align="left">CSYNC</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">NOTIFY</td> <td align="left">NOTIFY</td>
<td align="left">Delegation management</td> <td align="left">Delegation management</td>
<td align="left">(this document)</td> <td align="left">RFC 9859</td>
</tr> </tr>
<tr> <tr>
<td align="left"> </td> <td align="left"> </td>
<td align="left">2-127</td> <td align="left">2-127</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">Unassigned</td> <td align="left">Unassigned</td>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left"> </td> <td align="left"> </td>
<td align="left">128-255</td> <td align="left">128-255</td>
<td align="left"> </td> <td align="left"> </td>
<td align="left">Reserved (private use)</td> <td align="left">Reserved for Private Use</td>
<td align="left">(this document)</td> <td align="left">RFC 9859</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Requests to register additional entries MUST include the following fi <t>Requests to register additional entries <bcp14>MUST</bcp14> include t
elds:</t> he following fields:</t>
<dl> <dl spacing="compact" newline="false">
<dt>RRtype</dt> <dt>RRtype:</dt> <dd>An RRtype that is defined for use</dd>
<dd> <dt>Scheme:</dt> <dd>The mode used for contacting the desired
<t>An RRtype that is defined for use</t> notification address</dd>
</dd> <dt>Mnemonic:</dt> <dd>The scheme's shorthand string used in
<dt>Scheme</dt> presentation format</dd>
<dd> <dt>Purpose:</dt> <dd>Use case description</dd>
<t>The mode used for contacting the desired notification address</t> <dt>Reference:</dt> <dd>Location of specification or registration
</dd> source</dd>
<dt>Mnemonic</dt>
<dd>
<t>The scheme's shorthand string used in presentation format</t>
</dd>
<dt>Purpose</dt>
<dd>
<t>Use case description</t>
</dd>
<dt>Reference</dt>
<dd>
<t>Location of specification or registration source</t>
</dd>
</dl> </dl>
<t>Registration requests are to be recorded by IANA after Expert Review <xref target="RFC8126"/>. <t>Registration requests are to be recorded by IANA after Expert Review <xref target="RFC8126"/>.
Expert reviewers should take into consideration the following points, Expert Reviewers should take the points below into consideration; however,
but are being designated as experts for a reason, so they should they are experts and should be given substantial latitude:</t>
be given substantial latitude:</t>
<!-- [rfced] Is it correct that the Scheme and Mneumonic are tied together, so r
egistrations with the same mneumonic would have the same scheme value? We ask b
ecause RRtypes CDS and CSYNC both display "1" in the Scheme column in the "DSYNC
: Location of Synchronization Endpoints" registry.
Also, is it correct that the Scheme column is the range of code points available
for assignment (i.e., a separate column for values is not needed)?
Original:
* Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments.
The code points tagged as "Private Use" are intended for testing
purposes and closed environments. Code points in other ranges
should not be assigned for testing.
From the IANA registry <https://www.iana.org/assignments/dns-parameters/dns-para
meters.xhtml#dsync-location-of-synchronization-endpoints>
RRtype Scheme Mnemonic Purpose
0 Null scheme (no-op)
CDS 1 NOTIFY Delegation management
CSYNC 1 NOTIFY Delegation management
2-127 Unassigned
128-255 Reserved for Private Use
-->
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Point squatting should be discouraged. Reviewers are encouraged <t>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.</t> should not be assigned for testing.</t>
</li> </li>
<li> <li>
<t>A specification of a scheme is desirable, but early assignment be fore a <t>A specification of a scheme is desirable, but early assignment be fore a
specification is available is also possible. When 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.</t> used for.</t>
</li> </li>
<li> <li>
<t>Experts should take into account that field values are fit for pu rpose. <t>Experts should take into account that field values are fit for pu rpose.
For example, the mnemonic should be indicative and and have a plausible For example, the mnemonic should be indicative and have a plausible
connection to the scheme's notification mechanism.</t> connection to the scheme's notification mechanism.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="dsync-underscore-name"> <section anchor="dsync-underscore-name">
<name>_dsync Underscore Name</name> <name>_dsync Underscore Name</name>
<t>Per <xref target="RFC8552"/>, IANA is requested to add the following <t>Per <xref target="RFC8552"/>, IANA has registered the following entri
entries to the es to the
"Underscored and Globally Scoped DNS Node Names" registry:</t> "Underscored and Globally Scoped DNS Node Names" registry within the "Domain Nam
<artwork><![CDATA[ e System (DNS) Parameters" registry group:</t>
+---------+------------+-----------------+
| RR Type | _NODE NAME | Reference | <table>
+---------+------------+-----------------+ <thead>
| DSYNC | _dsync | (this document) | <tr><th>RR Type</th><th>_NODE NAME</th><th>Reference</th></tr>
+---------+------------+-----------------+ </thead>
]]></artwork> <tbody>
</section> <tr><td>DSYNC</td><td>_dsync</td><td>RFC 9859</td></tr>
</section> </tbody>
<section anchor="implementation-status"> </table>
<name>Implementation Status</name>
<t><strong>Note to the RFC Editor</strong>: please remove this entire sect
ion before publication.</t>
<t>Johan Stenstam's experimental nameserver implements this draft
(https://github.com/johanix/tdns).</t>
<section anchor="child-dns-operator-side">
<name>Child DNS Operator-side</name>
<ul spacing="normal">
<li>
<t>IronDNS implementation under way</t>
</li>
<li>
<t>deSEC implementation under way (Q1/2025)</t>
</li>
</ul>
</section>
<section anchor="parent-side">
<name>Parent-side</name>
<ul spacing="normal">
<li>
<t>SWITCH (.CH/.LI) implementation is under way.</t>
</li>
<li>
<t>.SE/.NU will implement this once it is an RFC.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>In order of first contribution or review:
Joe Abley, Mark Andrews, 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.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-dnsop-dnssec-automation" to="DNSSEC-AUTO" />
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC1996"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<front> 996.xml"/>
<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTI <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
FY)</title> 364.xml"/>
<author fullname="P. Vixie" initials="P." surname="Vixie"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="August" year="1996"/> 344.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t>This memo describes the NOTIFY opcode for DNS, by which a maste 477.xml"/>
r server advises a set of slave servers that the master's data has been changed <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
and that a query should be initiated to discover the new data. [STANDARDS-TRACK] 078.xml"/>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</abstract> 615.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="RFC" value="1996"/> 499.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC1996"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
</reference> 119.xml"/>
<reference anchor="RFC9364"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 174.xml"/>
<title>DNS Security Extensions (DNSSEC)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> 035.xml"/>
<date month="February" year="2023"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<abstract> 136.xml"/>
<t>This document describes the DNS Security Extensions (commonly c <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
alled "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a ha 567.xml"/>
ndful of others. One purpose is to introduce all of the RFCs in one place so tha <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
t the reader can understand the many aspects of DNSSEC. This document does not u 914.xml"/>
pdate any of those RFCs. A second purpose is to state that using DNSSEC for orig <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
in authentication of DNS data is the best current practice. A third purpose is t 126.xml"/>
o provide a single reference for other documents that want to refer to DNSSEC.</ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
t> 552.xml"/>
</abstract>
</front>
<seriesInfo name="BCP" value="237"/>
<seriesInfo name="RFC" value="9364"/>
<seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference>
<reference anchor="RFC7344">
<front>
<title>Automating DNSSEC Delegation Trust Maintenance</title>
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson
"/>
<author fullname="G. Barwood" initials="G." surname="Barwood"/>
<date month="September" year="2014"/>
<abstract>
<t>This document describes a method to allow DNS Operators to more
easily update DNSSEC Key Signing Keys using the DNS as a communication channel.
The technique described is aimed at delegations in which it is currently hard t
o move information from the Child to Parent.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7344"/>
<seriesInfo name="DOI" value="10.17487/RFC7344"/>
</reference>
<reference anchor="RFC7477">
<front>
<title>Child-to-Parent Synchronization in DNS</title>
<author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
<date month="March" year="2015"/>
<abstract>
<t>This document specifies how a child zone in the DNS can publish
a record to indicate to a parental agent that the parental agent may copy and p
rocess certain records from the child zone. The existence of the record and any
change in its value can be monitored by a parental agent and acted on depending
on local policy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7477"/>
<seriesInfo name="DOI" value="10.17487/RFC7477"/>
</reference>
<reference anchor="RFC8078">
<front>
<title>Managing DS Records from the Parent via CDS/CDNSKEY</title>
<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson
"/>
<author fullname="P. Wouters" initials="P." surname="Wouters"/>
<date month="March" year="2017"/>
<abstract>
<t>RFC 7344 specifies how DNS trust can be maintained across key r
ollovers in-band between parent and child. This document elevates RFC 7344 from
Informational to Standards Track. It also adds a method for initial trust setup
and removal of a secure entry point.</t>
<t>Changing a domain's DNSSEC status can be a complicated matter i
nvolving multiple unrelated parties. Some of these parties, such as the DNS oper
ator, might not even be known by all the organizations involved. The inability t
o disable DNSSEC via in-band signaling is seen as a problem or liability that pr
events some DNSSEC adoption at a large scale. This document adds a method for in
-band signaling of these DNSSEC status changes.</t>
<t>This document describes reasonable policies to ease deployment
of the initial acceptance of new secure entry points (DS records).</t>
<t>It is preferable that operators collaborate on the transfer or
move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zon
e Signing Key (ZSK) rollover. If that is not possible, the method using an unsig
ned intermediate state described in this document can be used to move the domain
between two parties. This leaves the domain temporarily unsigned and vulnerable
to DNS spoofing, but that is preferred over the alternative of validation failu
res due to a mismatched DS and DNSKEY record.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8078"/>
<seriesInfo name="DOI" value="10.17487/RFC8078"/>
</reference>
<reference anchor="RFC9615">
<front>
<title>Automatic DNSSEC Bootstrapping Using Authenticated Signals fr
om the Zone's Operator</title>
<author fullname="P. Thomassen" initials="P." surname="Thomassen"/>
<author fullname="N. Wisiol" initials="N." surname="Wisiol"/>
<date month="July" year="2024"/>
<abstract>
<t>This document introduces an in-band method for DNS operators to
publish arbitrary information about the zones for which they are authoritative,
in an authenticated fashion and on a per-zone basis. The mechanism allows manag
ed DNS operators to securely announce DNSSEC key parameters for zones under thei
r management, including for zones that are not currently securely delegated.</t>
<t>Whenever DS records are absent for a zone's delegation, this si
gnal enables the parent's registry or registrar to cryptographically validate th
e CDS/CDNSKEY records found at the child's apex. The parent can then provision D
S records for the delegation without resorting to out-of-band validation or weak
er types of cross-checks such as "Accept after Delay".</t>
<t>This document establishes the DS enrollment method described in
Section 4 of this document as the preferred method over those from Section 3 of
RFC 8078. It also updates RFC 7344.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9615"/>
<seriesInfo name="DOI" value="10.17487/RFC9615"/>
</reference>
<reference anchor="RFC9499">
<front>
<title>DNS Terminology</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
<date month="March" year="2024"/>
<abstract>
<t>The Domain Name System (DNS) is defined in literally dozens of
different RFCs. The terminology used by implementers and developers of DNS proto
cols, and by operators of DNS systems, has changed in the decades since the DNS
was first defined. This document gives current definitions for many of the terms
used in the DNS in a single document.</t>
<t>This document updates RFC 2308 by clarifying the definitions of
"forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and cla
rifications. Comprehensive lists of changed and new definitions can be found in
Appendices A and B.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="9499"/>
<seriesInfo name="DOI" value="10.17487/RFC9499"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC1035">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris
"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised specification of the protocol and forma
t used in the implementation of the Domain Name System. It obsoletes RFC-883. Th
is memo documents the details of the domain name client - server communication.<
/t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<seriesInfo name="DOI" value="10.17487/RFC1035"/>
</reference>
<reference anchor="RFC2136">
<front>
<title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title
>
<author fullname="P. Vixie" initials="P." role="editor" surname="Vix
ie"/>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<author fullname="J. Bound" initials="J." surname="Bound"/>
<date month="April" year="1997"/>
<abstract>
<t>Using this specification of the UPDATE opcode, it is possible t
o add or delete RRs or RRsets from a specified zone. Prerequisites are specified
separately from update operations, and can specify a dependency upon either the
previous existence or nonexistence of an RRset, or the existence of a single RR
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2136"/>
<seriesInfo name="DOI" value="10.17487/RFC2136"/>
</reference>
<reference anchor="RFC9567">
<front>
<title>DNS Error Reporting</title>
<author fullname="R. Arends" initials="R." surname="Arends"/>
<author fullname="M. Larson" initials="M." surname="Larson"/>
<date month="April" year="2024"/>
<abstract>
<t>DNS error reporting is a lightweight reporting mechanism that p
rovides the operator of an authoritative server with reports on DNS resource rec
ords that fail to resolve or validate. A domain owner or DNS hosting organizatio
n can use these reports to improve domain hosting. The reports are based on exte
nded DNS errors as described in RFC 8914.</t>
<t>When a domain name fails to resolve or validate due to a miscon
figuration or an attack, the operator of the authoritative server may be unaware
of this. To mitigate this lack of feedback, this document describes a method fo
r a validating resolver to automatically signal an error to a monitoring agent s
pecified by the authoritative server. The error is encoded in the QNAME; thus, t
he very act of sending the query is to report the error.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9567"/>
<seriesInfo name="DOI" value="10.17487/RFC9567"/>
</reference>
<reference anchor="RFC8914">
<front>
<title>Extended DNS Errors</title>
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
<author fullname="E. Hunt" initials="E." surname="Hunt"/>
<author fullname="R. Arends" initials="R." surname="Arends"/>
<author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
<author fullname="D. Lawrence" initials="D." surname="Lawrence"/>
<date month="October" year="2020"/>
<abstract>
<t>This document defines an extensible method to return additional
information about the cause of DNS errors. Though created primarily to extend S
ERVFAIL to provide additional information about the cause of DNS and DNSSEC fail
ures, the Extended DNS Errors option defined in this document allows all respons
e types to contain extended error information. Extended DNS Error information do
es not change the processing of RCODEs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8914"/>
<seriesInfo name="DOI" value="10.17487/RFC8914"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8552">
<front>
<title>Scoped Interpretation of DNS Resource Records through "Unders
cored" Naming of Attribute Leaves</title>
<author fullname="D. Crocker" initials="D." surname="Crocker"/>
<date month="March" year="2019"/>
<abstract>
<t>Formally, any DNS Resource Record (RR) may occur under any doma
in name. However, some services use an operational convention for defining speci
fic interpretations of an RRset by locating the records in a DNS branch under th
e parent domain to which the RRset actually applies. The top of this subordinate
branch is defined by a naming convention that uses a reserved node name, which
begins with the underscore character (e.g., "_name"). The underscored naming con
struct defines a semantic scope for DNS record types that are associated with th
e parent domain above the underscored branch. This specification explores the na
ture of this DNS usage and defines the "Underscored and Globally Scoped DNS Node
Names" registry with IANA. The purpose of this registry is to avoid collisions
resulting from the use of the same underscored name for different services.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="222"/>
<seriesInfo name="RFC" value="8552"/>
<seriesInfo name="DOI" value="10.17487/RFC8552"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC6781"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 781.xml"/>
<title>DNSSEC Operational Practices, Version 2</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="O. Kolkman" initials="O." surname="Kolkman"/> 583.xml"/>
<author fullname="W. Mekking" initials="W." surname="Mekking"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="R. Gieben" initials="R." surname="Gieben"/> 901.xml"/>
<date month="December" year="2012"/>
<abstract>
<t>This document describes a set of practices for operating the DN
S with security extensions (DNSSEC). The target audience is zone administrators
deploying DNSSEC.</t>
<t>The document discusses operational aspects of using keys and si
gnatures in the DNS. It discusses issues of key generation, key storage, signatu
re generation, key rollover, and related policies.</t>
<t>This document obsoletes RFC 4641, as it covers more operational
ground and gives more up-to-date requirements with respect to key sizes and the
DNSSEC operations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6781"/>
<seriesInfo name="DOI" value="10.17487/RFC6781"/>
</reference>
<reference anchor="RFC7583">
<front>
<title>DNSSEC Key Rollover Timing Considerations</title>
<author fullname="S. Morris" initials="S." surname="Morris"/>
<author fullname="J. Ihren" initials="J." surname="Ihren"/>
<author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
<author fullname="W. Mekking" initials="W." surname="Mekking"/>
<date month="October" year="2015"/>
<abstract>
<t>This document describes the issues surrounding the timing of ev
ents in the rolling of a key in a DNSSEC-secured zone. It presents timelines for
the key rollover and explicitly identifies the relationships between the variou
s parameters affecting the process.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7583"/>
<seriesInfo name="DOI" value="10.17487/RFC7583"/>
</reference>
<reference anchor="RFC8901">
<front>
<title>Multi-Signer DNSSEC Models</title>
<author fullname="S. Huque" initials="S." surname="Huque"/>
<author fullname="P. Aras" initials="P." surname="Aras"/>
<author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
<author fullname="J. Vcelak" initials="J." surname="Vcelak"/>
<author fullname="D. Blacka" initials="D." surname="Blacka"/>
<date month="September" year="2020"/>
<abstract>
<t>Many enterprises today employ the service of multiple DNS provi
ders to distribute their authoritative DNS service. Deploying DNSSEC in such an
environment may present some challenges, depending on the configuration and feat
ure set in use. In particular, when each DNS provider independently signs zone d
ata with their own keys, additional key-management mechanisms are necessary. Thi
s document presents deployment models that accommodate this scenario and describ
es these key-management requirements. These models do not require any changes to
the behavior of validating resolvers, nor do they impose the new key-management
requirements on authoritative servers not involved in multi-signer configuratio
ns.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8901"/>
<seriesInfo name="DOI" value="10.17487/RFC8901"/>
</reference>
<reference anchor="I-D.ietf-dnsop-dnssec-automation">
<front>
<title>DNSSEC automation</title>
<author fullname="Ulrich Wisser" initials="U." surname="Wisser">
</author>
<author fullname="Shumon Huque" initials="S." surname="Huque">
<organization>Salesforce</organization>
</author>
<author fullname="Johan Stenstam" initials="J." surname="Stenstam">
<organization>The Swedish Internet Foundation</organization>
</author>
<date day="19" month="October" year="2024"/>
<abstract>
<t> This document describes an algorithm and protocol to automat
e the
setup, operations, and decomissioning of Multi-Signer DNSSEC
[RFC8901] configurations. It employs Model 2 of the multi-signer
specification, where each operator has their own distinct KSK and ZSK
sets (or CSK sets), Managing DS Records from the Parent via CDS/
CDNSKEY [RFC8078], and Child-to-Parent Synchronization in DNS
[RFC7477] to accomplish this.
</t> <!-- [I-D.ietf-dnsop-dnssec-automation] IESG State: Expired as of 07/17/25 -->
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</front> ietf-dnsop-dnssec-automation.xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-dnssec-autom
ation-03"/>
</reference>
</references> </references>
</references> </references>
<?line 633?>
<section anchor="context"> <section anchor="context">
<name>Efficiency and Convergence Issues in DNS Scanning</name> <name>Efficiency and Convergence Issues in DNS Scanning</name>
<section anchor="original-notify-for-zone-transfer-nudging"> <section anchor="original-notify-for-zone-transfer-nudging">
<name>Original NOTIFY for Zone Transfer Nudging</name> <name>Original NOTIFY for Zone Transfer Nudging</name>
<t><xref target="RFC1996"/> introduced the concept of a DNS Notify messa ge which was used <t><xref target="RFC1996"/> introduced the concept of a DNS Notify messa ge, which was used
to improve the convergence time for secondary servers when a DNS zone 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 had been updated in the primary. The basic idea was to augment the
traditional "pull" mechanism (a periodic SOA query) with a "push" traditional "pull" mechanism (a periodic SOA query) with a "push"
mechanism (a Notify) for a common case that was otherwise very 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).</t> frequent scanning of the primary for changes).</t>
<t>While it is possible to indicate how frequently checks should occur <t>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. <xref target="RFC1996"/> addressed t he zone changes that fall between checkpoints. <xref target="RFC1996"/> addressed t he
optimization of the time-and-cost trade-off between a secondary checking optimization of the time-and-cost trade-off between a secondary frequent checkin
frequently for new versions of a zone, and infrequent checking, by g
for new versions of a zone and infrequent checking, by
replacing scheduled scanning with the more efficient NOTIFY mechanism.</t> replacing scheduled scanning with the more efficient NOTIFY mechanism.</t>
</section> </section>
<section anchor="similar-issues-for-ds-maintenance-and-beyond"> <section anchor="similar-issues-for-ds-maintenance-and-beyond">
<name>Similar Issues for DS Maintenance and Beyond</name> <name>Similar Issues for DS Maintenance and Beyond</name>
<t>Today, we have similar issues with slow updates of DNS data in spite of <t>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 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 CSYNC scanners deployed in a growing number of TLD registries. Because of
the large number of child delegations, scanning for CDS and CSYNC records the large number of child delegations, scanning for CDS and CSYNC records
is rather slow (as in infrequent).</t> is rather slow (as in, infrequent).</t>
<t>It is only a very small number of the delegations that will have upda <t>There is only a very small number of the delegations that will have u
ted pdated
CDS or CDNSKEY record in between two scanning runs. However, frequent CDS or CDNSKEY record in between two scanning runs. However, frequent
scanning for CDS and CDNSKEY records is costly, and infrequent scanning scanning for CDS and CDNSKEY records is costly, and infrequent scanning
causes slower convergence (i.e., delay until the DS RRset is updated).</t> causes slower convergence (i.e., delay until the DS RRset is updated).</t>
<t>Unlike in the original case, where the primary is able to suggest the <t>Unlike in the original case, where the primary is able to suggest the
scanning interval via the SOA Refresh parameter, an equivalent mechanism scanning interval via the SOA Refresh parameter, an equivalent mechanism
does not exist for DS-related scanning.</t> does not exist for DS-related scanning.</t>
<t>All of the above also applies to automated NS and glue record <t>All of the above also applies to automated NS and glue record
maintenance via CSYNC scanning <xref target="RFC7477"/>. Again, given that CSYNC maintenance via CSYNC scanning <xref target="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 scanning delegations seems disproportionately costly, while infrequent scanning
causes slower convergence (delay until the delegation is updated).</t> causes slower convergence (delay until the delegation is updated).</t>
<t>While use of the NOTIFY mechanism for coordinating the key exchange i n <t>While use of the NOTIFY mechanism for coordinating the key exchange i n
multi-signer setups <xref target="I-D.ietf-dnsop-dnssec-automation"/> is multi-signer setups <xref target="I-D.ietf-dnsop-dnssec-automation"/> is
conceivable, the detailed specification is left for future work.</t> conceivable, the detailed specification is left for future work.</t>
</section> </section>
</section> </section>
<section anchor="change-history-to-be-removed-before-publication">
<name>Change History (to be removed before publication)</name> <section anchor="acknowledgements" numbered="false">
<ul spacing="normal"> <name>Acknowledgements</name>
<li> <t>In order of first contribution or review: <contact fullname="Joe
<t>draft-ietf-dnsop-generalized-notify-09</t> Abley"/>, <contact fullname="Mark Andrews"/>, <contact
</li> fullname="Christian Elmerot"/>, <contact fullname="Ólafur
</ul> Guðmundsson"/>, <contact fullname="Paul Wouters"/>, <contact
<ul empty="true"> fullname="Brian Dickson"/>, <contact fullname="Warren Kumari"/>,
<li> <contact fullname="Patrick Mevzek"/>, <contact fullname="Tim
<t>Leftover editorial changes</t> Wicinski"/>, <contact fullname="Q Misell"/>, <contact fullname="Stefan
</li> Ubbink"/>, <contact fullname="Matthijs Mekking"/>, <contact
</ul> fullname="Kevin P. Fleming"/>, <contact fullname="Nicolai Leymann"/>,
<ul spacing="normal"> <contact fullname="Giuseppe Fioccola"/>, <contact fullname="Peter
<li> Yee"/>, <contact fullname="Tony Li"/>, <contact fullname="Paul
<t>draft-ietf-dnsop-generalized-notify-08</t> Wouters"/>, <contact fullname="Roman Danyliw"/>, <contact
</li> fullname="Peter van Dijk"/>, <contact fullname="John Scudder"/>, and
</ul> <contact fullname="Éric Vyncke"/>.</t>
<ul empty="true">
<li>
<t>IESG review editorial changes</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Added guidelines for expert review (IESG feedback)</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Nits from Dnsdir telechat review</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-ietf-dnsop-generalized-notify-07</t>
</li>
</ul>
<ul empty="true">
<li>
<t>IESG review changes (notable: scheme now has mnemonic; else editori
al)</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Nits from Opsdir telechat review</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-ietf-dnsop-generalized-notify-06</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Nits from Genart review</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Nits from Opsdir review</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Nits from Dnsdir review</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-ietf-dnsop-generalized-notify-05</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Editorial changes</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-ietf-dnsop-generalized-notify-04</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Add section on Implementation Status</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Use assigned DSYNC RRtype value</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Define DSYNC presentation format</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Make all needed IANA requests</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Editorial changes</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-ietf-dnsop-generalized-notify-03</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Include DNSSEC bootstrapping use case</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Remove sections with approaches not pursued</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Editorial changes</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-ietf-dnsop-generalized-notify-02</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Nits by Tim Wicinski</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Dnsdir feedback</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Specify timeout and error handling</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Editorial nits</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Reserve scheme value 0</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-ietf-dnsop-generalized-notify-01</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Reserve scheme values 128-255</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Rename NOTIFY rrtype to DSYNC (to distinguish from NOTIFY message)<
/t>
</li>
</ul>
<ul empty="true">
<li>
<t>Describe endpoint discovery</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Discussion on garbage notifications</t>
</li>
</ul>
<ul empty="true">
<li>
<t>More discussion on amplification risks</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Clean-up, editorial changes</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-ietf-dnsop-generalized-notify-00</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Revision after adoption.</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-thomassen-dnsop-generalized-dns-notify-02</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Add rationale for staying in band</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Add John as an author</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-thomassen-dnsop-generalized-dns-notify-01</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Mention Ry-to-Rr forwarding to accommodate RRR model</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Add port number flexibility</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Add scheme parameter</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Drop SRV-based alternative in favour of new NOTIFY RR</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Editorial improvements</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>draft-thomassen-dnsop-generalized-dns-notify-00</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Initial public draft.</t>
</li>
</ul>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA619W3rjxrXue42ijvxg0iHZrb63vI8TWZLbSrrViqSOP+/L
lwaBIgULBGgUIJluewD7+UzgDOGM4WRie93qBlJ2O44cxxIJFKpWrcu/boXp
dKq6sqvMgX5latNmVfmjKfTx2aU+a7pyUeZZVza1Vdl83prb9Kr0iqLJ62wF
AxVttuimpekW06K2zXq6DPdMa7xnM334UhVZBxd/OD68OvlZwSBm2bSbA227
Qqly3R7oru1t9+jhw5cPH6msNdmBPq0709amU3dNe7Nsm359gFN9e66/gQ/K
eqlf4YfqxmzgiiLcMD3GOSllu6wu/p5VTQ2P3hir1uWB/o+uySfaNm3XmoWF
3zYr/OW/lMr67rppD5SeKg0/ZW0P9J9n+rIzNYy0og95zX9urrM6/aJpl1ld
/kjUOdBX10Zf3pmitNd+Vvqrpq8LuoDuMKusrA70dzjWzMpYfyrlaguE60xl
DXxnkimdz2D4ZpVZ+C6a07mBGwffwKRgg8zlydFEX5q8b2FWG3jUyuqTelnW
xrRAxng2axzlT4WxJp+VzZAUr80t3JQSoo4/pQdeItnzBh72+vVRPDjtR9YW
9k/WXTLLm5VSddOugDC35gCYoV5Ef02nU53NbddmOWzo1XVpNXBevzJ1pwOj
WQ3DafMDELGwugPi99boZsGc/fbq9Ktv9ejiqyO9//Lls7Gem01TFypv6lsY
B/Yjq/SPwCTAg1ltF0DGa9gG4I2u0VlVNXfwRblcErF0A8O3utus4anwBJgX
ycNtmdGD8YndddbpOwMEWIMUlU1vq42uspx4NnOD6ZXJYetLu5qpRLbgi9bA
HXVfLA0N2prcAD1anFBZl10J8gMDweiFWQDtC5kGfNKs1l21USPYss5kBU4R
Ps+0za9N0Vdm/DmOuAEqahBOWB5yDT5DRig7a6oF3p9XfUETrjfaIvOU3UbD
KPmNhav0qlxed7Cz66rZjGewN402dTavcMawS4u+zpm0cNsEJrAyIF2Fhs3V
IBZ5c8vkTJYH27dugPQKr7J9fq3riDAwhLXZEugO48NVbVP0uSkm2tG+Nnf6
+PLbsyMcETQC7VJKXNk4UDByDdCuRPrgva1ZlsBqMN27srsWSlcwkfUa1AVO
Xa3hzrqDD2GbkeeOL92z+jWqOJyYIxywAkienjdNhwy8XsOHSKi3+ssTfXHy
5u3fTo5RVcQ8Db/PDd6cN1WVzZsWxixwB2GSr2BS/Vxn3YH6j+uuW9uDBw+W
9BlK0QMS3c7J/4OP0Mv/NfqXDAO7j/pu1diOthKWcScKGjbVItWBC3GD3DIn
ulkbWJO1vQExM10+0/a66asC5Q0ooLJb0BjCTSANM00qlTW01aMl0mXRV9Vm
DIybm3Wn1/AXPP57GLGzM9Ycq7IoKqPUJ6iEiV1I+6qrNitKEXwU2DoRvw8f
/hfoClQVP/8MrHBdAh8iw+BE4AmgH0DuSDdYtcfaZXT59nC8N6HLLBJgAYJI
ElqushblpxXxzVCWGlSD0adqBby2ApISlaqsgy341GpSUC0QPIcvypXh+5FT
U7oqVF4z5iSvVFB+chAYopLOiqKFP5D1tS2XNS0X+a02C/i1hGdsQPXS8xvQ
TyWSBrQJGMumIukuMpgwTLLK2viuEtVgDtoBORSnhpo3zyzuK3wC8tKVeY83
FaYySzZ/YA7AzNUZLmx0zJJ0NpSk8Uz/GSABUFnLxCJa0yMmTA1lwbgCJept
Ob8rgSmus1vUlqvsO9Aq68aWaFuAyWARoMfmG0U63ikj5AewQW0GMgv8gjYT
yA6Ssa5AMiokApjHzqzxajDNKS1mYOVbpLZjL9jDDgwT4AxjgLPkz59/Bpoe
VsDN/fKaFaZXAcwzJTypMFllWReB9qg2OMVI/FK2VTBLkjFPZh2T2W3LBDQz
LYqsJTERKlu2avgUP96IFDBQf9VXXTlFroFLAGzBrchjSzNGdQUEtSUIKizo
rCHqObbRfBVr26CvgeLpimck255xlTNdq+wGbhZLngEdCnh+i0M60+4NAu2g
G9rEjHsBI4Gw0BzMD2uTdyy7c6MXGXBzCZxJFBZtzcL/8vGzJyj8XpmrDx/+
CJ8/e/5iHz/nq54/fvIk+uvJ8+f8F175/OmLx+G7Fw+fv4C/ZJQXLx/SKMj2
8rxn+0+RJ2ASUwuTxG3VoARALzRVswS7C3gTp4wQEsVBbnvy8iWx0ief6GOD
O6RfNcgzuKXHgRHeBEZQ6ptrw+LEtgxVMWhTuIGtKig527FVTNUiWe57ZNix
CsgyXAU7wzLMOGo8Ia3X3pZwKUkkAE/ZBBimAOH02h4fwgpd5BF2P5nGDNYF
toMMbEPrUF7EiKvcg1agr4BibV97rhisFz5bAdi5BVWl4E+4KoMFIhXJ6CI0
BMRzd90wZZCdW+Y9YNSicgqjaJAUn4JLFAgOi88CVTK5xgGMrEXAdNqhTgAo
js9s2dY1OrEEdb+aA8/DE1HhWAaW9EWs6sDgAIsrJKrFIWB9CKFxyghwyOws
yiUKfdODbSY7Bp/hfZFeFQNiewCnYEKVf1jVNDf9GoUK7QkSFUgEyKTuvF03
HWygdX8yoaeoKBUgWd646xIWMDKz5QxtqmEUTVMpkUKeNMhAsLyxTKcEZ1Rs
F4k3jA2eB3Bp+aPbAJkfSTERBy5wU8mvy6ogBaOG248M0qEsjJo1K2tCE3UN
MpabbTJ7cEp4MWx2ENi7DKAjzrGfV+D54fzAwAAVM55HuBKnOFOjQ5DrLr+e
IuhxwzvGLYHHc2JEGBGkpsjBc0IEOVYEt2xT9Q7zgw6G6xwxAcqxtO5k+sZN
TxHqZ9oKU9hmZdAPgq/RONAgifRNGCynq1GwbmB2sm8kPSgaP/8MO3jedChF
iKGJRy3pMZNZtm6s4IzfNJXwD6lH2iDcYNAozP7eP4Sly0OdP7HBh5IyvAAc
WLYGrYvFwEUmuA8GRwOG4QKr9968u7wC0Eb/RSHA3y9O/vru9OLkGH+//Prw
9Wv/i5IrLr9+++71cfgt3Hn09s2bk7Njvhk+1clHau/N4bd7rPX33p5fnb49
O3y9x9gmtv8ZSyexAFAInDxkggz1i83bcs66+cuj8///f/efiCF4tL8PhsAZ
m/3nYJZwS2t+WlNXG/kTfT8FZt4QiiO0nWfrEjwa2FtQVYDC72ripJn6tz9W
uDvTZ3/8QiGGZtfq4kJfAbbSHz4p7KbO2wKR1s/imwO2Zf1Hbim74v42vFDg
NOmZuUW0XoO7ikaeXEMVu4Y7pc/yBn8Du4tQCxiBt1Wecnx4dQjS0pIlWWXk
UAEyawoiIXyIQMEeKApL7PzZ3/HPox3/PNaPeZCHdMFj/UQ/1c/0c/1Cv/wt
n9Egf5j+zn9olJ+AykTke35+0pfgv69M+Psc/Np/4QS2H3iFJrPTsxl4cA8+
4kkPALHRGhQH0Wg5oBZi2CsBHbFPpQ0cFrGdIquKMINn4BQdqjRSG3sXxjZ9
C5r+gt2O0cXFWF99e35i9/Tp4dmhcuGAMYP6urmbsCgdictyRM8ln49DBPC4
26winxatEWlY5EPTOnXOARWBRwWNBEMfAe77y8m3zgECfwa4nPdK6LACDvZS
Qk4FxmscApGlJgIjC/ZmFB6rXkznYJD6mrB8QfpladqZUEBcDVoBcOaoRo/a
0izGjOHR7LNBghlYUFctiOPf6Pp9fESioRKtxoqIiaP3H72YPnr6VKIw5AWz
9IPrc4uwERYK/HIIj2e/RO7D68HTbEVn1JnlhQCxiJGZVBSrYWjoNv8aQxNi
XAbQicAiE0kRENl/tpNI7N52GNiA9XeGoVVKOuVIdz+xFAuETJV88+n3PTD2
osRIFiAPcDQF7QhojOFMtB4gVnNbFo4HHOyFC9l64xfIK/c6jC54IGbcSLiM
+YUeSnYRJtMARkaThNAAgROGdp08McuKVj7H3azZ2ibaeR1/IZpZlsQqGzeN
wo82VdNTopOoNZhkVeAlrZEBWauDb1+bVVMDsKK4Cw7rxRuUzg4Bd7I9c48Q
zbjzEbCFJeAI/5AS3FFhPdIl8AhAPjSAGxeQyISZ964EFwYnWQeeKoDiK0BF
TgDdJM4pzHjfKj9iAFG39xPqP/+NuWqKG/yfX+iRBLsePn46gWVciv1+Otv3
WOrSrADql7lVyqtBChOhKuRVaxeGhkfu65Ej1IGoalCg+ssEFmcqidMKdEdU
QOOhwygg0MHg4PwgfMNIYVXeCL5XDt3a2K3B+JuYCokTOLyYc9wSVgiKGBE0
Tkw0QrNQHGID1fxA9PKDIzEwoJgpKRAjZ9RrpHJI7ETzwUxpgUoWiBf1luO6
UdIhEB/wGmUOMAGBowHpT37IMOakRw7KAzIDPYQb52TXuii2dfGlGH8Lyjk9
EwNJ1kY7mjx9/PSlzgs7tYDJYeCZ4efNarQ+gxvpP/7GZw91jthv963qUiK5
7OaH6JKP8KAmLzEUxZ/znlvn+AgvYTwLA2DMHORKtzGqZ3JS/qKmbBG4Ccsy
94bThZ0KChcYdlZZkZA/uHFpFtZ/m5CiABYYGFhRuyPykjKGtaKTMAKWtTut
C3icm6rJCpQjgM/nCZcl6VSRWwugOmwgpVQw+nWvBp+ge4nK2qBjjhFlxyrs
biGr3oC8Ku/yF0C+vAMPDKiZyobz/j2AZ0vOWIpc/6JnVD1I3wCrp4FXWgpF
AzvD3+8AbyFyB4PO+45sS4hdIxgoV2ThZAtCmJqigX0HaqwjTbgr3DnTb5G1
VMQeKCISjxns7tBFxnQSKNvD81OwdhiS0+84mjVyztbjZ6TfkWFHEknAkAVy
LxlH24NHhQGdslaowMBO9xgLxrD4TL9GxfULm0o6TkLtwJ/C9Qr5M3NxuGgL
tuM5PHMdzTzKixwy+8L9axOiBBFvhl0orQRdO0x3k77vGuXSYb+wggwsFUMK
cDXbBrmNc6KAnqyKZLLa7IRlIojIjx6cOEQpHIqYL903K8mGcs0wW5IGPjjg
bFVYc4txExT3e2LmKVwiNCQ2LERronCEYpUkGU2Xfwy2EaO2sc/8M1CpkOzr
+7/TN++BunPBfWkwBFM85KEPMLYRsIRPJpea89Ezwl2tYDiMRTjelL00aaYU
iUJaAfDnvKy9LRQth/aL1eoM45awDVFog3mPqgtwliJfJSHQ+CE2DrTPGE2s
MbEPJK7cdjD/b8nkm8NvnaiblGBCLUI31mB4sDOOWnXxABPJmxptJQZV3USY
8GU306eg7JNoFsZ8Uac2HdkvROXRhDB+5Xggw4KGDuNfEp1LVuviFPLVG2Jp
pU4XO9fHaXcXurUx+iAHkQaWCCymIyhB3qwIj2MQJ3AwEBA+u8vQRmLgt2nv
8PkpL+OONRhwIwOMckM5emDVrK92KnRnnYNAboVTPpvxnng4cC/2IP3B437E
nTH4iO9E+5jlwLDgHOOmo6Yl85aIcw1mhuJq6EJXzF4qCvPft1YMXG+2yYaV
BiXQk2gWcmQs9BLCpijp6dHh2dmnlh875hxXFCfHG1XWUjqLAU0m8Xn8MlLO
caKM2MdvPUKRZncqB3FZ03lO9Qzq0CJFJvynVTY3lYdfbbNeI25znhRvQwCf
elTOzAyxh5Jb5DHIE10inDKyJPRcSF9k3jjLZlVWxylTSq4C2kD9EbT3jlgv
BxVKTFWAqlugdhtEXVkIj9LguxdFUmRZZRufxIzC48OQvddhbG5TzfypVbRU
3kVggjKlIY0FzPDVX4/PXFwbPWsUttJyYAez5VVGLvyO7WHLjdFzFpEJRRXI
OifJk8WCUQGrRUteknrPaRC59f3Eq1KZ4nv3jeZKAlFSfliJNUhAd2dcdqI5
tfO+bafuM/fAg6ePHz58z0wnREPOcYQmHo/D+luahaf/K9rFuycPH+odk2AQ
vjspepDo2xDaS8uyPnziHEeljj8GMTgXEdc9KJmgtBg7OeREkWuIqxQTuqCo
YJiTcJ+KE89xajlJI+sRFSGAAb/FqBA4s4IlpOBGDWsRxkoNcXma7U0WSZBi
7iLsElqIYYkaVNC4xNz77xFMvJfwRGuI3TkwgTBx3WJdG5eSxaSL6VCU+XUD
2H8ziStC4IpxcPIpFMfP+t/wzfsxhyYZhVEFHYcUqLJNpByY25crgBIV+ILb
Q9FaMDK4Q5LVxuqDyxD5EkTN24eg26thgcgVIYq+zu5Ixy/i/KcIhOIZcKCQ
zL9XOISSsOrIujgxW3hO44PGXTeA3TdKpk9OISeWs+K2tNlArc0b3A1XvugN
Aj8CLt44z5pdLArYmQxLRugGMre1VGKVHXveFJOgYiZlm0VHyyRECctpJeph
KSqZY8TtHQZdqOhvTeYu2sUYbPGuwHXlukSdMYJZI1SsYPNdnA09tJBV15KR
8zWS5OmgzcJt4TwxR2zQd0pKG9Suar2kOoNcqstYEu6VRuftYBgkBAHnxpV+
Ykwxs1zYlyks7WoZsIveiQtKkhItj8K8d9gBCugQpDopYzhLziCXmzrq4sgD
KdFOSvA7kBNmd5E9tWXpPF+j05vUShAaIjlLg880sEoLOMDw1syF5A9vmxQq
EQG7a7AULAK9VANnsWArDX0HDuFSKao64S3I4gK0oF/1dWZVQC0S7pvoyAI8
8Kg7iXCfOL/v2AOTD58ETEK6q2pyx3uCJykG1nfLhizzR5gOtpU7qjzEC5UK
j4H7hzUiYDH3Z/oIxqDytbhAAqWU6hMAF4CKc+QbgLVsIRXBaHkXZWs7+cLX
evjpB0wIxHk00+cyrcw9EW9B95GttHO8k+lIWqgshGT4VOA+0BAgMeXClWVR
GhdVWSHohILbiJ8slyT4uj5+VlbbO9NOeDRQXljYDJN87LHN9z3uHQ8RaoCX
rM/cBBh+TAMe4o8ByF2+PXSu83aE2seubXC5OT9KxRVMZiya8Pgw3QPGdrx/
HIyOSMYD/douAl9tlQNGEP673nYyEOPmAZ7VgmYBlXG1q5/pFo0mPA7u47Ih
xxLh+6OZpNgRiXjImlk0b0yn9xit6Ocz/DeFp2yuY4DKQwWUOsKnoYPD6HXH
EPDUAehlF4xHcpXdzCuOFSqOGyFC6HwdDbuU5NrILGTegka3nx0yrnG9oQP7
qPBpnC1CDqA4i0ZWs4vOc0Q7lUwiPD0Fx+95/qZ2PlYxE1Z+68zRBKVrII6o
FwkV+e3HSfk6L3n2gFdbs2puDWdcqFL2XtblijjhF+sGCjs02cFFdPHIUbTz
TQbEpb5El0NLVN0mXpNFUDtcsagCSmyP6man7+9rEX36iw1p2v7EVZQ5Gl+q
RGwZPbLFvSd15AJ2wQ6xmk8goyAYiuVmIZCczlRSsbwpvjLGO8vbiJzlW5pR
ohDq4TBDlrtAL9Cw3aRe2Rzp60AybHNu2prLMB3oYO/RFZhilrgNsJqihLeI
h2NPZxLlKxQZN7d0F8tLlu7jlPgk2YVQZk9MJlX1zrxb4cPtLZjwJJWHlVyJ
SJX2BUV/+rorK4qvcYAcLgFETYGCvFmXPg9HS8GuNVfY4c1MaADAzqRsUKLB
1gL4Hw11SWl+FYXiJ3GB5NrX0g18wwfD4KBU1qJrtlpT/jroeLBYrG+Ip52L
wW0LWIYx04dcjYnaCuTRl9GI6yOpDs7TdazdCA26kjKP9DsQZ+Q4nDR4UqUo
a+5uoUJzUkqnompdACeJKzt7yvxCe2I9st1Z/R6woOxdcD0kHJbr2CNekwlF
B8zRgpAGuC2GI7if6CvYGOB89htO2hZW+7XU/267zcMyc1NhRJkpGmn5ZKpq
FPvLPgf/ZPZ8THxUNxEisq5bqpj4okrWGYp7sYLPQ/lQDqa0BFjS6MTOp1qA
SE9ppY9nz8bilPiZAvARriJXAbiW8ucDnNEnOSdkGbUAncq13QD22tJ0G3Y+
MYDpq4KLnhxV0FGVz5IyzyILgSbcqCgDjFVSOCQ1aiUF+REF94GClxiixQmQ
ncDZcL9KhsbnGswb9edNNLJqQL9OMXrKo2mcG0NAvGMnxldXV8D7TkHa+HFh
jzCBwd0EGHcQz/Hl02fo4Z2AID/UFwaD29Oja8ypA9xec0FM3Pri1XTXKEde
YSVgCfIB0GUmuEGRcrTlBlkW3SZsqGADJd8SqFDsNNVxDEZaKaU1mAbQWEN5
T6Dnxcv9J9iGMOJSn+a6nJdhA4Flw1rwkag3R9wJgQSY+P16RlUnZH8Uawgr
0AkrkFp/MwdQEZw1hjM1ZPaGuWVEAGQgQksezYbJzXOaUGUPXA0MJZkkF94C
bNVgxTXQA9sDDJZppaYXGx2wFIvCH5Sci2tAQtQ36pook3g92UsVgRtRmLBT
qDfYVjP/kNrIs5Bi9PzptIjLAPe1bUjrmCLeaCFmX0voMcpjYN8S67qLpjIE
bkruvPtlOxNcT8+EHNBxQQdFrnwDMkXdK+K2hj6d0HDJtlL6hqjcCNO44lMh
1SjjIRFL1BgUlyejjWqFki16efX6GLtNfECIa0q67AarlRQ75PYGlGrNYip9
arRXXFcYhdJ3hrlJf8QpjwkD0i2DJCXc3n1g+6RiIZNKibj7KSdEcY0dx65q
k1NEaMS7O1A/viqVpCDM9tezR58nRFaE8ihdwCEYToGU2K5Lyp2fi0PUS8vk
Inuc5jQU7CluBXoyrhyFQQDXdiNe4eWkUT1hO5y2ktZ5UxwM4+ctRbrW1Yab
KsXGR+kmqXFV6kuDsuEF0/crU/ZNcjYD9MVVfZh1rRGWKhrAUncDrXxUdgEO
+3AUMRFCNcYX7BL/0ClqjA71N9lKSDeOAS7ogrKQviLJMefgwQCRRAtgW6x1
j4l3hJqObqV6OGtBv7YIKynu5uxnRkHkKSB3Vw06DjUhgwoNz7TbzdqKDGGE
GbGskZtQscmSnVZXBCL1qYK5XfDXVYN6TeGDvPpNnGC4r0XtKolrZdUSQ83X
Kx0ZhTjyT+2jSZQzKKnZNkYj12arwUCKtUC3CBIc0xQxgKN8zUQUQnRmAp2u
rKU6gSyAU/KGS07YofmEaUR+aD8IgGd65OE9a7Q7GnI8tPsYALgvpuliTyGs
uTNPp3YAhpHYoyiqHvWqEfTp7hoxmZyU2wdPIcfissrgKQVuMfPNVuQ5QKgh
eiDf/j7sy8EAd2yBCzLpcgX2g9QnS5wI/D0ut43IQTbHRXF2k3CUpqK8OLsu
hGBzCYGPXZBLnL2hL81lMMQEv4r3JD64lgi4QLIYl0R4RN+LR3gYD0oGgCQA
EW9xnYSyJhFPggbZhpCEmzm7zGmdX0QHgRVk8xLYqX8b7OQhkpBGgj2Fmvhc
V8dAMpFgfAkmoTOHXN8ku0alt3wIht9XQo8MucDOlU0B/pRL104GxgqgGztG
VFzH1/AonN9JmWRa1twMLXaj5INLRIbv4WYJXlqqapW8BZAIxZNtltQqpU6+
Q6E0DcIvEvil3gvfZhfy0AtyLTDbBE4wTVIMDDFbjoYUkMjNeOaZf1fIS6wo
poQy9Kl8uKCD/cCud/+8kcTuhHfZzDkZG1htMKdCQAdjsQbLuLDZXBRFjh4Z
kgPxdOvCuiwCXOLkn+40TABMHFCNWcA1r+/m+TCUGEXZRQYBpQvZwy4Jq8l1
Ez3P8hvU9JbOF4AFirV3pR0S2xBxXHIDaLpZ1CN4C5rAHeiCBwV8TimYu6nf
SR5ie83olZInNZfuovnGU6iMQTKR49FMH8tTYtc/3h9As8GLaU2HbsckOCmy
FtmtLDIgW/muX7IkPArhFEqDhxwrdd0Ej4Rc5IkUNZrCJQhZEfEorI3KBWa5
ObRHlUbgzN+a8Uy/rUOhVYNEJhYRHQMjoXdI41TlCgCja4MV/ElFSmUtXY9I
Sb33ZdXkN6bY06P9p2M/kuyQi/feowkx7oCx8hVH1TgBSDk6bzkwdxoO+KA+
WwxTW86ubR0pMhK/YtAEoe9rgvBJryjXTC0Q6e2hvomrQMcSy8TuaJ+85Qpv
UyjXvOTsrZPA0wU3HEttGIWQmXUFCQ/RQDIA23Sppop5a5KKkJcGVw0GToM0
RJEPV2EyXESpcxqWG8oGPVh+xPiwA1K0pEe5BOnS+SZHiZRj7b/jGqrzQ9uY
u6aoqHDAuc4RegzHXHE8w/wAI9GtoCVBApVIquX4+MA3KvPrQRSJwQDXL5BC
cbkinpC6zgqOhSXTQhedfB6N55aFNNhcfLMtEc/A+8zppAE3MpspBv2US0jS
h8eXg/KMQY4NtH8IMfj1YqJ1Z8m5Q3WyiM/F5+YgHZ0pojytKBfXY0atc7NP
ulHEQsb1IuOItFLk4/D1g+C3s/FurCHuJmJL1NUfw+OshlQiSjmAnEJj+dwl
P1Eu8cLtAFLj6QubcFJGks7ZHVhEaQPARycZUHEll25ytICRUEmO+B42lYmz
Sxa4dAUvZUiJfIrRapAcLPJD9EGMAzuGGYU9jAFGeB93IngCHHrmcv+YWyn+
7ftgf6GxBPBWF9WFckEUKJyo0JPZjyY7Nwg7mr4NusvlEUR/yPBy+hv6g0Bi
2DwpdpGwgKt7IasESmRhuGqcTk1T3JDEpUkF1Y1xeoKNtKGzpqphEWHnTylx
h8BwrX3BfSp0xhP1K7VNFbVYTXwEiex1zK0hqh80yK5z1kh9kQIWOk+0F2Q1
VBbRuSNxmyjAujmdWeNCkE5Du4JGeLo7dIY73by0xx4+KVJ+eGSSlAw6lpwj
QX5mUnfUIKpGUfdY/+/b5tx0SqTdCjONwhSEwZtd/ly8FQhpMKAj5+MpnHKc
16McCcZVurLidrPoLBcfjfXKc43Ht8Q74CwRgYpY6Yf0h9Q3pXNUyCJUyec8
Q7aEKL6w7V83d4iHJ6540ISqJIZB5OFZ4izgyHZD6UPflDjhpoF0sdERUBMu
6yKQ1VKEllTFHLbirizI3SuI3D13AoNum/ctKGWKyDL2piOqcGa97ekIMtDH
JbZBAuGIk0Ta6FBQSdpwNwdGthGnMX5CAIoxeY4Y0UFQfMhgnGykGE7pABWB
OSa5k+O0nS8ElfTOJhiQQjlnJx0psT7UusFFmAN7CNpSTiQ4PU/aS+nCqAuc
ss18GIocErcJPv6wre8imQrjG/gdi2tstCSNwS8O7oKfMUfxH5btHUa9lu70
GRtOOSLUuRUGj+q7qKD22pSt5rpBTJCNXeY4xaykO9C0A0K6Nb64o8MSC9he
JYe3DdJwiyxH/wkX7HpKWUpaExtvrLsMIQAuMAudHMj7l6evRg/HgFl/pZ8J
B0b16opsMC9H1Zl0KoG+XDfNwoS2IHZerNhJ5yUNTtnCcqcWSxyE0YFcFaAF
MC4hZyC1QZGFYSXMfSvE5ypOAyWP+Jy5zzD4mmB4npUC6g7iD/RH4PkGoXmo
HbEuBCwNXKTVQC8PJ+eVlxTsIVE4QZqoOMrl1Fy+B+utpogQ3HGL3r+iEyHy
jSs3UWmDKwVVbBOH2OlWAFTY2YeVXHQKQ2icj7uyLeNxPOtjgMWV+uwzbl/l
oAEeHXsCPkjTfvbZgddVUkYz0aA/MmrFlv6NnJNJOdeH7I2SNMx4z3mhGPfC
E+0M7WEuUfPklB3gb5wdoR7yZRnoSoYdp/aLx5g4vKlCo+HeMUcTz1Cf8GHA
egQ7Otbn7mSt6EZNxy5j/C00ZFzx6SxMST79A/589kypNyajqNdBKJMN/TuD
hgIXmJMjk1E/Cxng9gHFVEQYOafhQgA0jQWeU3r4wj1ko3Itbmakyttsq4My
PgXW+bj/DMWATHi5I9OBft0E3/gyXbonlsUWH+RTMkbnXNUPtPwBi1RgxVi3
8it0IpGU4kYvYAFyucxha9IeG39wUDgh6Cf9xh138ZM+l1bZwQ/c5ibjPoGh
pvSj3S/Rb/Gv6c/2FzSUfw7/PPS/0Ydn4XwarOabNusxfzEgCw3F/Yd+gH28
ny0lfni8s2PwvqG45+hfMVS0wEfT/UfP0wW+8yfcDMi+tRHxUO50nWSoC3fM
zig6Y2e8c1bqQprFufYCecYkR5rCdYRfGT1JTUsqR9Thg5zlD3M6rB2POeDi
OnKQPWEy/6oDj0ANCePKSMwhn9LZZi16bgU16GE7j2u72z6dRinheRjknRyd
KumH9ba+iqU7ddOjRBqrPT6TRiX6y3XnR0e/+cOpAfmTLuPCpEQX+OPeHj3D
6hv5rqXvEOfKicpU/kD14ElYebBjrIEmCs9ioDMZDPcq+BaPjGMtrSiUTKKi
6BPgUBt5HOKfZYmoHEuUu4xLALCgqwM2oRN9zsky2O978JPIV+N5Si4VCARC
A+hJVukPb63dV3LUGCwI0YbtpTsmPRpwMaR8G3E1F/i5cVzWpecICHvM7BVh
yLfnM3ENuVOOebMKll9IXN1LiSkEr7tcLB8RwF2YdHqCD7SXeMYG1utR/EhS
KcSvlPGSit4uWy6Z9nvnIrfAjXvuRF0OEZN+h6X5hJPvpafZ5BWdDmnq2xKM
Dj9OA+AJTyklgs6H60qM3m2LVHt6TRQ9jY4dOhxy/EJOm18ZORKMDzed0DEf
hpqWsmDmpM4gcw9NxkJC+6Nhh726M07O7LoxIHNpXJXEWCTA/hvtzk2Vgei0
6HuYCgEl1W8s8DzF4SaTyMgoTnMRiU5EbrYEErvXe+fLc1dkdNQZnk6N1Jbd
RB5JwqH4cH8mVRAid9LcrZEOgsKdgA3wtCfSwUigC2oJvgnI9XpyEAvyLykg
FMY1+2CasCqNXvJAQEedA/uIPnr69BG2fe6EYKCkB4rHWRMpkNoLI/PcX1XN
nKoiLrGsyb2spODnRsBLWoX/4BHEH2I48Yfp8CccmcjnWf6k/3729vhEnx2+
OdmJbP6p0aU/GUdnwt2HUH7j6OS4uMAF79Ql/Lf/FdfFeyrSskHFzl1JAVJm
BpHHKJ0DG5++7+RTsQTlil+FEBUA+ViKldozehHLrtcM0GtPyh8edEVtx1Gb
Pu3vW+mG4COEQYJOQXPRwezpktmtucs2eA295+TeK/Tor/sPHj189HTMtUnR
EcVw7+U3p1dHX+vR7OjrB7PXp+PhMKUNI5FIzy5PHszO3nFgMkSQuNoVuYZL
4YBqsAHsZ0blMkShKHYBOpOzeBTHLed9wA5oAg9gA4w+BMHdTPSbrL0BNAVY
5w6c96PrFri/hOecVOAANd1E/+P/VNmib/Wr/h//bwWztmSlz7O+Ut80PXor
E/1li7ccl/kNfflNhv6q/kuPB8/jtTCJ/Ea/Mbc/mpsJVsDrb0Ad1vamnKi/
6jelNRgZBoZYwDDv5vOyvsGZdbD+7wAYmpsbqpD4C74ZBl9Y8xXQhz45K/Om
ykr12mwAHcOjX5WgKtcgf1+V4DfDdxN5k823BlTcVVNv9OuSp6/99C/AI6vV
cVZvqvLO3XBLK/oOJkJvpbnM+6LAsMY//hsWo/8Gwndj5L0QmHenPTkJnbXU
9R9lR085kQLzR8a7dKm9D5+4tnnio7eDJA3q639HoHDlXiVz1hdLahVICp2i
4/A5n1jTSyxCNo8OGgiReIqK3GV8VASW+kru1N2dJnXpiJDBayYsB315eIog
+iyeO43Ux3qoZ4UDPPPM4omHhcno8ajC+6XwulFd9CKNPXwDx150fNQoC1Uz
2H5AIeaxi37A5fZ6TyWX86rHAjCl1Tzn3DU2VMMEQqofowrR2xc6PZIGAlMS
mLH44p6YNHQsjqX3htDJCBiLlaxuSN02ad/OwnV2GdJSXBjNsh2nkvyRAljr
6gat/OtyxDhTYEiN3OtqkCYXkh7zx5pzotwad2tRFvKiHloOHheO3PQjx/al
s4rgA785hZP5dLOcl5xW2IXD1HH/sGpg5eIQLi0KHDQFaZhSkht32EybxcKP
Hb/BhJ5D5xGFNVPcPLyjhN+SFE5kopdrCNXd7diVrDh8Fifki7At/gwJjgz7
PffR7oBSsGdP3lMiMrzgzv2oxJQm8iW/BorfbTLRd0awn3vJCd/Mxw8i8d0b
fuTlE3TGPxbJrMvOlxnQh1LCNPdlFVh/yOKEZZSUsG3m3IvHPfAI9+RUYRUV
FaHUspfgWpSXrQSqfDbp6vWxw0D0/pFQCU0TquidBeFy30oVjosKhV/cWBYd
gOKydAjjsiBVI34nS9jJse/kokRxpvnAtRXyZHh2WoIofBte0SJqSO0+FLms
PQciEf2k2x5fCuEzW25Gaveq0uNUOH9iu2qzxZq+hE/KwnHdpk30iZyDFLcK
4grhUdJraN2SkDzvajqwdPiOHU54RUctiOJB8CDKRd7IQAK7Xff1i9pkQgXI
3/fgOlbUV+JfsuJbZ8wPwDoiIqGoTh5DWR/f+k81UeyERZXY4SxGeSfWEg9B
ZgonbwnBmQ4q5uKDLmb6cAlXTyR8QMxxFIfrXUkhsVibYW1D2O9Eg2dDtlcx
28lbN0pLb06gc4czerOPYwVOw/9GZhiyQRTrThmBbUjUrDDUYRLxkmJfF/OK
X7yDxdPJW3mA3fBkkw8f/ng6PZ5Fb+uC/wdtPQ2HuSD2oHoBzBKxX86zxZPJ
cOeHDnhlFswe8t4gzLsyoD3iuXwN/NPgAV0ucoW+RbHDkQDk/dnHvi5SfaFf
w4OprcuQ+0IhbTZ4Hz3OCxzn9OTylQDpXUN9oQ8LDAMsewA5VekOXzJxNE2P
aJCFMQVCxzHedYaFVpQvPa5tUWJQpMIddPd89CSfDyfpzPoIrsAdOnDhFHAf
qF7IOf2fU6FVWNRgXm/Xv2tez9LRXoEUt2GQHQ/a9ZXQ5jc++ikOcvJPb/sT
2VXv1ML/7nGWv6Dorg9uueQbBaopFIOXHFOkWr7cGSz+AsDFjaFOcT40kqMf
Lub4+5bzmBhE4uw7jylyL/fCCy/Yt3cHgfrXh9ExrKLz130L2Kb4fdN65Hd6
vklcRCIZ77uTGPzoUs5Z7rifml/ZSZWt7nVK6XzqkgknqQsnBHLG/kdPc/++
Mfx7CPgCKrBwdcYtZyoa2fMRHZ1MMc8ez9Ai1k4LLcbMKNyfENoFff6TvoY/
emuFI3eWWRArod4skmvTkhtw+W/oyqPKZPW0X09+h458yMvHcw0a1/+cFVxO
PAuj+DdC7hgKPkm5AmWvlRIf8Ua7bMOwhcqB3EXkqfPZ9nyi2G9/IO3vGz5S
XV9spl0zvWhdC5XE8ONTQi8uLriW0M2BSvYFKSwqgENchO91CLOMh1S0kQAc
9OXF36Z8ild8CDkemZLdSiUhukHCJhcXKXeL/y6RoN+66IesEjjRK8ca0Agz
9T8bltBy5HkAAA==
<!-- [rfced] May we expand "DS" and "NS" as Delegation Signer and Name Server up
on first usage for clarity?
FYI - we added the expansion "Fully Qualified Domain Name" for FQDN. Please
let us know if this is objectionable.
-->
<!-- [rfced] For consistency, should "Notify" be "NOTIFY" in the
Appendix? We ask because the term is fully capitalized throughout the
document, excluding the Appendix section.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
In addition, please consider whether "traditional" and "native" should be update
d for clarity. While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
ibrary/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
These are subjective terms, as they may mean the same thing for everyone.
Note that updates of this nature typically result in more precise language,
which is helpful for readers.
Current A:
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.
Current B:
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 and overly
frequent scanning of the primary for changes).
Current C:
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.
--> -->
</rfc> </rfc>
 End of changes. 106 change blocks. 
1179 lines changed or deleted 343 lines changed or added

This html diff was produced by rfcdiff 1.48.