Internet Engineering Task Force (IETF) J. Stenstam
Request for Comments: 9859 The Swedish Internet Foundation
Category: Standards Track P. Thomassen
ISSN: 2070-1721 deSEC, Secure Systems Engineering
J. Levine
Standcore LLC
September 2025
This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints to allow other types of actions that were previously lacking a trigger mechanism to be triggered via the DNS. Notifications merely nudge the receiver to initiate a predefined action promptly (instead of on a schedule); they do not alter the action itself (including any security checks it might employ).
このドキュメントは、従来のゾーン転送のヒントを超えてDNS通知（RFC 1996）の使用を一般化および拡張し、以前はDNSを介してトリガーメカニズムをトリガーしていた他のタイプのアクションを可能にします。通知は、（スケジュールではなく）、事前定義されたアクションを迅速に開始するように受信者に単に微調整するだけです。アクション自体を変更しません（使用する可能性のあるセキュリティチェックを含む）。
To enable this functionality, a method for discovering the receiver endpoint for such notification messages is introduced, via the new DSYNC record type. Notification types are recorded in a new registry, with initial support for parental NS and DS record updates including DNSSEC bootstrapping.
この機能を有効にするために、新しいDSYNCレコードタイプを介して、このような通知メッセージの受信エンドポイントを発見する方法が導入されます。通知タイプは新しいレジストリに記録され、DNSSECブートストラップを含む親NSおよびDSレコードの更新を初期サポートします。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9859.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9859で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Design Goals for Delegation Maintenance
1.2. Requirements Notation
2. DSYNC RR Type
2.1. Wire Format
2.2. Presentation Format
2.3. Semantics
3. Publication of Notification Targets
3.1. Wildcard Method
3.2. Child-specific Method
4. Delegation Maintenance: CDS/CDNSKEY and CSYNC Notifications
4.1. Endpoint Discovery
4.2. Sending Notifications
4.2.1. Timeouts and Error Handling
4.2.2. Roles
4.3. Processing of NOTIFY Messages for Delegation Maintenance
5. Security Considerations
6. IANA Considerations
6.1. DSYNC RR Type
6.2. DSYNC Scheme Registration
6.3. _dsync Underscore Name
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Efficiency and Convergence Issues in DNS Scanning
A.1. Original NOTIFY for Zone Transfer Nudging
A.2. Similar Issues for DS Maintenance and Beyond
Acknowledgements
Authors' Addresses
The original DNS notifications [RFC1996], which are here referred to as "NOTIFY(SOA)", are sent from a primary server to a secondary server to minimize the latter's convergence time to a new version of the zone. This mechanism successfully addresses a significant inefficiency in the original protocol.
ここでは「Notify（SOA）」と呼ばれる元のDNS通知[RFC1996]は、プライマリサーバーからセカンダリサーバーに送信され、後者の収束時間をゾーンの新しいバージョンに最小化します。このメカニズムは、元のプロトコルの有意な非効率性に成功しています。
Today, similar inefficiencies occur in new use cases, in particular delegation maintenance (DS and NS record updates). Just as in the NOTIFY(SOA) case, a new set of notification types will have a major positive benefit by allowing the DNS infrastructure to completely sidestep these inefficiencies. For additional context, see Appendix A.
今日、同様の非効率性、特に委任のメンテナンス（DSおよびNSレコードの更新）で同様の非効率性が発生しています。Notify（SOA）の場合と同様に、新しい通知タイプのセットは、DNSインフラストラクチャがこれらの非効率性を完全に回避できるようにすることにより、大きなプラスの利点をもたらします。追加のコンテキストについては、付録Aを参照してください。
Although this document primarily deals with applying generalized notifications to the delegation maintenance use case, future extension for other applications (such as multi-signer key exchange) is possible.
このドキュメントは主に、一般化された通知を委任保守のユースケースに適用することを扱っていますが、他のアプリケーションの将来の拡張（マルチシグナーキーエクスチェンジなど）が可能です。
No DNS protocol changes are introduced by this document. Instead, the mechanism makes use of a wider range of DNS messages allowed by the protocol.
このドキュメントによってDNSプロトコルの変更は導入されていません。代わりに、メカニズムは、プロトコルで許可されているより広い範囲のDNSメッセージを使用します。
Readers are expected to be familiar with DNSSEC [RFC9364], including [RFC6781], [RFC7344], [RFC7477], [RFC7583], [RFC8078], [RFC8901], and [RFC9615]. DNS-specific terminology can be found in [RFC9499].
読者は、[RFC6781]、[RFC7344]、[RFC7477]、[RFC7583]、[RFC8078]、[RFC8901]、[RFC9615]を含むDNSSEC [RFC9364]に精通していることが期待されています。DNS固有の用語は[RFC9499]に記載されています。
When the parent operator is interested in notifications for delegation maintenance (such as DS or NS update hints), a service to accept these notifications will need to be 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 delegation data (such as a domain registrar).
親オペレーターが委任メンテナンスの通知（DSやNS更新ヒントなど）に関心がある場合、これらの通知を受け入れるサービスを利用可能にする必要があります。コンテキストに応じて、このサービスは、親オペレーターまたはドメインの委任データ（ドメインレジストラなど）の処理を担当する指定されたエンティティによって実行される場合があります。
It seems desirable to minimize the number of steps that the notification sender 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 relationships (e.g., whether or not there is a registrar). This is addressed by parameterizing the lookup with the name of the child. The parent operator may then announce the notification endpoint in a delegation-specific way by publishing it at a child-specific name. (A catch-all endpoint may be indicated by wildcarding.)
Notifyの送信先を把握するために、通知送信者が実行する必要があるステップの数を最小限に抑えることが望ましいと思われます。これは、ルックアッププロセスが親側の関係の詳細について無知であることを示唆しています（たとえば、レジストラがあるかどうか）。これは、子供の名前でルックアップをパラメーター化することによって対処されます。その後、親オペレーターは、子供固有の名前で公開することにより、代表団固有の方法で通知エンドポイントを発表する場合があります。（キャッチオールエンドポイントは、ワイルドカードで示される場合があります。）
The solution specified here is thus for the parent operator to publish the address where someone listens for notifications, in a child-specific way (see Section 3). Potential senders can easily determine the name of the parent and then look up that information (see Section 4.1).
したがって、ここで指定されているソリューションは、親オペレーターが子供固有の方法で通知のために誰かが耳を傾けるアドレスを公開することです（セクション3を参照）。潜在的な送信者は、親の名前を簡単に決定し、その情報を調べることができます（セクション4.1を参照）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This section defines the DSYNC RR type, which is subsequently used for discovering notification endpoints.
このセクションでは、DSYNC RRタイプを定義します。DSYNCRRタイプは、その後通知エンドポイントの発見に使用されます。
The DSYNC RDATA wire format is encoded as follows:
DSYNC RDATAワイヤ形式は、次のようにエンコードされています。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RRtype | Scheme | Port
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
Figure 1: DSYNC RDATA Wire Format
図1：DSYNC RDATAワイヤ形式
RRtype:
RRTYPE：
The type of generalized NOTIFY that this DSYNC RR defines the desired target address for (see the "Resource Record (RR) TYPEs" registry at <https://www.iana.org/assignments/dns-parameters/>). For now, only CDS and CSYNC are supported values, with the former indicating an updated CDS or CDNSKEY record set.
一般化のタイプは、このDSYNC RRが目的のターゲットアドレスを定義していることを通知します（「リソースレコード（RR）タイプ」レジストリを参照<https://www.iana.org/assignments/dns-parameters/>）。今のところ、CDSとCSYNCのみがサポートされており、前者は更新されたCDまたはCDNSKEYレコードセットを示しています。
Scheme:
スキーム：
The mode used for contacting the desired notification address. This is an 8-bit unsigned integer. Records with value 0 (null scheme) are ignored by consumers. Value 1 is described in this document, and values 128-255 are Reserved for Private Use. Other values are currently unassigned. Future assignments are maintained in the registry created in Section 6.2.
目的の通知アドレスに連絡するために使用されるモード。これは8ビットの署名整数です。値0（nullスキーム）のレコードは、消費者によって無視されます。値1はこのドキュメントで説明されており、値128-255は私的使用のために予約されています。他の値は現在割り当てられていません。将来の割り当ては、セクション6.2で作成されたレジストリで維持されます。
Port:
ポート：
The transport port number on the target host of the notification service. This is a 16-bit unsigned integer in network byte order. Records with value 0 are ignored by consumers.
通知サービスのターゲットホストの輸送ポート番号。これは、ネットワークバイトの順序で16ビットの署名されていない整数です。値0のレコードは消費者によって無視されます。
Target:
ターゲット：
The fully-qualified, uncompressed domain name of the target host providing the service of listening for generalized notifications of the specified type. This name MUST resolve to one or more address records.
指定されたタイプの一般化された通知をリスニングするサービスを提供するターゲットホストの完全に適格で非圧縮ドメイン名。この名前は、1つ以上のアドレスレコードに解決する必要があります。
The presentation format of the RDATA portion is as follows:
RDATA部分のプレゼンテーション形式は次のとおりです。
* The RRtype field is represented as a mnemonic from the "Resource Record (RR) TYPEs" registry.
* RRTypeフィールドは、「リソースレコード（RR）タイプ」レジストリのニーモニックとして表されます。
* The Scheme field is represented by its mnemonic if assigned (see Section 6.2), and is otherwise represented as an unsigned decimal integer.
* スキームフィールドは、割り当てられている場合（セクション6.2を参照）、そのニーモニックで表され、それ以外の場合は署名されていない小数整数として表されます。
* The Port field is represented as an unsigned decimal integer.
* ポートフィールドは、署名されていない小数整数として表されます。
* The Target field is represented as a <domain-name> (Section 5.1 of [RFC1035]).
* ターゲットフィールドは、A <domain-name>（[RFC1035]のセクション5.1）として表されます。
For now, the only scheme defined is 1 (mnemonic: NOTIFY). By publishing a DSYNC record with this scheme, a parent indicates that they would like child operators to send them a NOTIFY message (see Section 4) upon publication of a new CDS/CDNSKEY/CSYNC RRset to the address and port number that correspond to that DSYNC record, using conventional DNS transport [RFC1035].
今のところ、定義されている唯一のスキームは1（Mnemonic：Notify）です。このスキームでDSYNCレコードを公開することにより、親は、従来のDNS輸送を使用して、そのDSYNCレコードに対応するアドレスとポート番号に新しいCDS/CDNSKEY/CSYNC RRSetの公開時に、子どものオペレーターに通知メッセージを送信することを望んでいることを示します[RFC1035]。
Example (for the owner names of these records, see Section 3):
例（これらのレコードの所有者名については、セクション3を参照）：
IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net.
IN DSYNC CSYNC NOTIFY 5360 csync-scanner.example.net.
Should a need for other mechanisms arise, other schemes may be defined to deal with such requirements using alternative logic.
他のメカニズムの必要性が発生した場合、代替ロジックを使用してそのような要件を処理するために他のスキームが定義される場合があります。
Schemes are independent of the RRtype. They merely specify a method of contacting the target (whereas the RRtype is part of the notification payload).
スキームはRRTYPEに依存しません。彼らは単にターゲットに接触する方法を指定するだけです（一方、RRTypeは通知ペイロードの一部です）。
To use generalized notifications, it is necessary for the sender to know where to direct each NOTIFY message. This section describes the procedure for discovering that notification target.
一般化された通知を使用するには、送信者が各通知メッセージをどこに向けるかを知る必要があります。このセクションでは、その通知ターゲットを発見する手順について説明します。
Note that generalized NOTIFY messages are but one mechanism for improving the efficiency of automated delegation maintenance. Other alternatives, such as contacting the parent operator via an API or DNS Update [RFC2136], may (or may not) be more suitable in individual cases. Like generalized notifications, they similarly require a means for discovering where to send the API or DNS Update requests.
一般化された通知メッセージは、自動委任メンテナンスの効率を改善するための1つのメカニズムにすぎないことに注意してください。APIまたはDNSアップデート[RFC2136]を介して親オペレーターに連絡するなど、他の代替手段は、個々のケースでより適している可能性があります（またはそうでない場合があります）。一般化された通知と同様に、同様に、APIまたはDNSの更新リクエストの送信先を発見するための手段が必要です。
As the scope for the publication mechanism is wider than only to support generalized notifications, a unified approach that works independently of the notification method is specified in this section.
公開メカニズムの範囲は一般化された通知をサポートするよりも広いため、通知方法とは独立して機能する統一されたアプローチをこのセクションで指定します。
Parent operators participating in the discovery scheme for the purpose of delegation maintenance notifications MUST publish endpoint information using the record type defined in Section 2 under the _dsync subdomain of the parent zone, as described in the following subsections.
以下のサブセクションで説明されているように、委任メンテナンス通知を目的として発見スキームに参加している親オペレーターは、親ゾーンの_DSYNCサブドメインの下にあるセクション2で定義されたレコードタイプを使用してエンドポイント情報を公開する必要があります。
There MUST NOT be more than one DSYNC record for each combination of RRtype and Scheme. It is RECOMMENDED that zones containing DSYNC records be secured with DNSSEC.
RRTypeとスキームの組み合わせごとに、DSYNCレコードが1つ以上ないことはありません。DSYNCレコードを含むゾーンをDNSSECで保護することをお勧めします。
For practical purposes, the parent operator MAY delegate the _dsync domain as a separate zone and/or synthesize records under it. If child-specificity is not needed, the parent can publish a static wildcard DSYNC record.
実用的な目的のために、親オペレーターは_DSYNCドメインを別のゾーンとして委任したり、その下のレコードを合成することができます。子供の特異性が必要ない場合、親は静的なワイルドカードDSYNCレコードを公開できます。
If the parent operator itself performs CDS/CDNSKEY or CSYNC processing for some or all delegations, or if the parent operator wants to relay notifications to some other party, a default notification target may be specified as follows:
親オペレーター自体が一部またはすべての代表団に対してCDS/CDNSKEYまたはCSYNC処理を実行する場合、または親オペレーターが通知を他のパーティにリレーする場合、デフォルトの通知ターゲットを次のように指定することができます。
*._dsync.example. IN DSYNC CDS NOTIFY port target
*._dsync.example. IN DSYNC CSYNC NOTIFY port target
To accommodate indirect delegation management models, the designated notification target may relay notifications to a third party (such as the registrar, in ICANN's model). The details of such arrangements are out of scope for this document.
間接委任管理モデルに対応するために、指定された通知ターゲットは、通知を第三者（ICANNのモデルでレジストラなど）に中継することができます。このような取り決めの詳細は、このドキュメントの範囲外です。
If for some reason the parent operator cannot publish wildcard records, the wildcard label may be dropped from the DSYNC owner name (i.e., it may be published at the _dsync label instead). This practice requires an additional step during discovery (see Section 4.1) and is therefore NOT RECOMMENDED.
何らかの理由で親のオペレーターがWildCardレコードを公開できない場合、WildCardラベルはDSYNCの所有者名から削除される可能性があります（つまり、代わりに_DSYNCラベルで公開される場合があります）。このプラクティスでは、発見中に追加のステップが必要であるため（セクション4.1を参照）、推奨されません。
It is also possible to publish child-specific records where the parent zone's labels are stripped from the child's Fully Qualified Domain Name (FQDN), and the result is used in place of the wildcard label.
また、親ゾーンのラベルが子供の完全資格のドメイン名（FQDN）から剥奪され、結果がワイルドカードラベルの代わりに使用される子供固有のレコードを公開することも可能です。
As an example, consider a registrar offering domains like child.example, delegated from example zone. If the registrar provides the notification endpoint, e.g., rr-endpoint.example:5300, the parent may publish this information as follows:
例として、例ゾーンから委任されたchild.exampleなどのドメインを提供するレジストラを検討してください。レジストラが通知エンドポイントを提供している場合、例えばRR-Endpoint.example：5300、親は次のようにこの情報を公開できます。
child._dsync.example. IN DSYNC CDS NOTIFY 5300 rr-endpoint.example.
Delegation maintenance notifications address the inefficiencies related to scanning child zones for CDS/CDNSKEY records [RFC7344] [RFC8078] [RFC9615]. (For an overview of the issues, see Appendix A.)
委任メンテナンス通知は、CDS/CDNSKEYレコード[RFC7344] [RFC8078] [RFC9615]の児童ゾーンのスキャンに関連する非効率性に対応しています。（問題の概要については、付録Aを参照してください。）
NOTIFY messages for delegation maintenance MUST be formatted as described in [RFC1996], with the qtype field replaced as appropriate.
[RFC1996]に記載されているように、QTYPEフィールドを必要に応じて置き換えて、委任メンテナンスの通知をフォーマットする必要があります。
To address the CDS/CDNSKEY dichotomy, the NOTIFY(CDS) message (with qtype=CDS) is defined to indicate any child-side changes pertaining to an upcoming update of DS records. As the child DNS operator generally is unaware of whether the parent side consumes CDS records or prefers CDNSKEY, or when that policy changes, it seems advisable to publish both types of records, preferably using automation features of common authoritative nameserver software for ensuring consistency.
CDS/CDNSKEYの二分法に対処するために、DSレコードの今後の更新に関する子供側の変更を示すために、Notify（CDS）メッセージ（QTYPE = CDS）が定義されています。子のDNSオペレーターは一般に、親側がCDSレコードを消費するか、CDNSKEYを好むか、またはそのポリシーが変更された場合に気づいていないため、両方のタイプのレコードを公開することをお勧めします。
Upon receipt of NOTIFY(CDS), the parent-side recipient (typically, registry or registrar) SHOULD initiate the same DNS lookups and verifications for DNSSEC bootstrapping [RFC9615] or DS maintenance [RFC7344] [RFC8078] that would otherwise be triggered based on a timer.
Notify（CDS）を受信すると、親側の受信者（通常、レジストラまたはレジストラ）は、DNSSECブートストラップ[RFC9615]またはDSメンテナンス[RFC7344] [RFC8078]の同じDNS検索と検証を開始する必要があります。
The CSYNC [RFC7477] inefficiency may be similarly treated, with the child sending a NOTIFY(CSYNC) message (with qtype=CSYNC) to an address where the parent operator (or a designated party) is listening for CSYNC notifications.
CSYNC [RFC7477]非効率性も同様に扱われ、子供は親オペレーター（または指定された当事者）がCSYNC通知を聞いているアドレスに通知（csync）メッセージ（qtype = csync）を送信します。
In both cases, the notification will speed up processing times by providing the recipient with a hint that a particular child zone has published new CDS, CDNSKEY, and/or CSYNC records.
どちらの場合も、通知は、特定のチャイルドゾーンが新しいCD、CDNSKEY、および/またはCSYNCレコードを公開しているというヒントを受信者に提供することにより、処理時間を高速化します。
To locate the target for outgoing delegation maintenance notifications, the notification sender MUST perform the following steps:
発信代表団のメンテナンス通知の目標を見つけるには、通知送信者は次の手順を実行する必要があります。
1. Construct the lookup name by inserting the _dsync label after the first label of the delegation owner name.
1. 代表団の所有者名の最初のラベルの後に_DSYNCラベルを挿入して、ルックアップ名を作成します。
2. Perform a lookup of type DSYNC for the lookup name, and validate the response if DNSSEC is enabled. If this results in a positive DSYNC answer, return it.
2. ルックアップ名のタイプDSYNCのルックアップを実行し、DNSSECが有効になっている場合は応答を検証します。これにより、DSYNCの回答が肯定的になる場合は、返してください。
3. If the query resulted in a negative response:
3. クエリが否定的な応答をもたらした場合：
* If the response's SOA record indicates that the parent is more than one label away from the _dsync label, construct a new lookup name by inserting the _dsync label into the delegation owner name just before the parent zone labels inferred from the negative response. Then go to step 2.
* 応答のSOAレコードが、親が_DSYNCラベルから複数のラベルが離れていることを示している場合、_DSYNCラベルを否定的な応答から推測する直前に_DSYNCラベルを代表団の所有者名に挿入することにより、新しいルックアップ名を作成します。次に、ステップ2に進みます。
For example, assume that subsub.sub.child.example is delegated from example (and not from sub.child.example or child.example). The initial DSYNC query relating to it is thus directed at subsub._dsync.sub.child.example. This is expected to result in a negative response from example, and another query for subsub.sub.child._dsync.example is then required.
たとえば、subsub.sub.child.exampleが例から委任されている（sub.child.exampleまたはchild.exampleからではない）と仮定します。したがって、それに関連する最初のDSYNCクエリは、subsub._dsync.sub.child.exampleに向けられています。これにより、例から否定的な応答が発生すると予想され、subsub.sub.child._dsync.exampleの別のクエリが必要です。
* Otherwise, if the lookup name has any labels in front of the _dsync label, remove them to construct a new lookup name (such as _dsync.example). Then go to step 2. (This is to enable zone structures without wildcards.)
* それ以外の場合、ルックアップ名に_DSYNCラベルの前にラベルがある場合は、それらを削除して、新しいルックアップ名（_DSYNC.exampleなど）を作成します。次に、ステップ2に進みます。（これは、ワイルドカードなしでゾーン構造を有効にするためです。）
* Otherwise, return null (no notification target available).
* それ以外の場合は、nullを返します（利用可能な通知ターゲットなし）。
When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child zone, the DNS operator SHOULD send a suitable notification to one of the endpoints discovered as described in Section 4.1.
チャイルドゾーンでCDS/CDNSKEY/CSYNC RRSETを作成または変更する場合、DNSオペレーターは、セクション4.1で説明されているように発見されたエンドポイントの1つに適切な通知を送信する必要があります。
A NOTIFY message can only carry information about changes concerning one child zone. When there are changes to several child zones, the sender MUST send a separate notification for each one.
通知メッセージは、1つの子ゾーンに関する変更に関する情報のみを伝えることができます。いくつかの子ゾーンに変更がある場合、送信者はそれぞれに個別の通知を送信する必要があります。
When a primary name server publishes a new RRset in the child, there typically is a time delay until all publicly visible copies of the zone are updated. If the primary sends a notification at the exact time of publication, there is a potential for CDS/CDNSKEY/CSYNC processing to be attempted before the corresponding records are served. As a result, a desired update may not be detected (or appear inconsistent), preventing it from being applied.
プライマリネームサーバーが子供に新しいRRSetを公開すると、通常、ゾーンのすべての公開コピーが更新されるまで時間遅延があります。プライマリが公開の正確な時点で通知を送信する場合、対応するレコードが提供される前にCDS/CDNSKEY/CSYNC処理を試みる可能性があります。その結果、目的のアップデートは検出されない（または一貫性がないように見える）場合があり、適用されないようにします。
Therefore, it is RECOMMENDED that the child would delay sending notifications to the recipient until a consistent public view of the pertinent records could be ensured.
したがって、適切な記録の一貫した公開ビューを確保するまで、子どもが受信者への通知の送信を遅らせることをお勧めします。
NOTIFY messages are expected to elicit a response from the recipient ([RFC1996], Section 4.7). If no response is received, senders SHOULD employ the same logic as for SOA notifications ([RFC1996], Sections 3.5 and 3.6).
通知メッセージは、受信者からの応答を引き出すことが期待されています（[RFC1996]、セクション4.7）。応答がない場合、送信者はSOA通知（[RFC1996]、セクション3.5および3.6）と同じロジックを使用する必要があります。
The recipient's attempt to act upon the delegation update request may fail for a variety of reasons (e.g., due to violation of the continuity requirement set forth in [RFC7344], Section 4.1). Such failures may occur asynchronously, even after the NOTIFY response has been sent.
代表団の更新リクエストに基づいて行動しようとする受信者の試みは、さまざまな理由で失敗する可能性があります（たとえば、[RFC7344]、セクション4.1に記載されている継続性要件の違反により）。そのような障害は、通知の応答が送信された後でも、非同期に発生する可能性があります。
In order to learn about such failures, senders MAY include an EDNS0 Report-Channel option [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 (EDE) code as described in [RFC8914]. (The prohibition of this option in queries ([RFC9567], Section 6.1) only applies to resolver queries and thus does not cover NOTIFY messages.)
このような障害について学ぶために、送信者は、[RFC8914]に記載されている適切な拡張DNSエラー（EDE）コードを使用してレポートクエリを作成することにより、受信側がエラーをレポートすることを要求するために、通知メッセージにEDNS0レポートチャネルオプション[RFC9567]を含めることができます。（クエリ（[RFC9567]、セクション6.1）のこのオプションの禁止は、リゾルバクエリにのみ適用されるため、通知メッセージをカバーしません。）
When including this EDNS0 option, the second label (QTYPE) of the report query name is equal to the qtype received in the NOTIFY message. Its agent domain MUST be subordinate or equal to one of the NS hostnames, as listed in the child's delegation in the parent zone. This is to prevent malicious senders from causing the NOTIFY recipient to send unsolicited report queries to unrelated third parties.
このEDNS0オプションを含める場合、レポートクエリ名の2番目のラベル（QTYPE）は、Notifyメッセージで受信したQTYPEに等しくなります。そのエージェントドメインは、親ゾーンの子供の代表団にリストされているように、NSホスト名のいずれかに下位または等しくなければなりません。これは、悪意のある送信者が通知受信者に無関係なサードパーティに未承諾のレポートクエリを送信するのを防ぐためです。
For example, when receiving a NOTIFY(CDS) message for "example.com" with agent domain "errors.ns1.example.net", and when the requested DS update is found to break the delegation, then the following report query with EDE code 6 (DNSSEC Bogus) may be made (preferably over TCP):
たとえば、エージェントドメイン「Errors.ns1.example.net」を使用して「Example.com」のNotify（CDS）メッセージを受信した場合、および要求されたDSアップデートが委任を破ることがわかった場合、EDEコード6（DNSSEC Bogus）の次のレポートクエリが作成される場合があります（TCPを超えています）。
qname: _er.59.example.com.6._er.errors.ns1.example.net.
qtype: TXT
While the CDS/CDNSKEY/CSYNC processing that follows the receipt of a NOTIFY will often be performed by the registry, the protocol anticipates that in some contexts (especially for ICANN gTLDs) registrars may take on the task. In such cases, the current registrar notification endpoint may be published, enabling notifications to be directed to the appropriate target. The mechanics of how this is arranged between registry and registrar are out of scope for this document; the protocol only offers the possibility to arrange things such that from the child perspective, how the parent-side parties are organized is inconsequential: Notifications are simply sent to the published address.
通知の受領に続くCDS/CDNSKEY/CSYNC処理は、しばしばレジストリによって実行されることがよくありますが、プロトコルは、一部のコンテキスト（特にICANN GTLDの場合）でレジストラがタスクを引き受けることができると予測しています。そのような場合、現在のレジストラ通知エンドポイントが公開される場合があり、通知を適切なターゲットに向けられるようにします。これがレジストリとレジストラの間にどのように配置されるかのメカニズムは、このドキュメントの範囲外です。このプロトコルは、子どもの観点から、親側当事者がどのように組織されるかが重要ではないように、物事を配置する可能性のみを提供します。通知は、公開された住所に送信されるだけです。
Because of the security model where a notification by itself never causes a change (it can only speed up the time until the next check for the same thing), the sender's identity is not crucial. This opens up the possibility of having an arbitrary party (e.g., a service separate from a nameserver) send the notifications, enabling this functionality even before the emergence of built-in support in nameserver software.
通知自体が変化を引き起こさないセキュリティモデルのため（同じことの次のチェックまで時間を速めることができる）、送信者の身元は重要ではありません。これにより、任意の当事者（例えば、名前サーバーとは別のサービス）が通知を送信する可能性が開かれ、名前サーバーソフトウェアに組み込みサポートが出現する前でもこの機能を可能にします。
The following algorithm applies to NOTIFY(CDS) and NOTIFY(CSYNC) processing.
次のアルゴリズムは、通知（CD）および通知（CSYNC）処理に適用されます。
NOTIFY messages carrying notification payloads (records) for more than one child zone MUST be discarded, as sending them is an error.
通知ペイロード（レコード）を含むメッセージを複数の子ゾーンに通知することは、それらを送信することはエラーであるため、破棄する必要があります。
Otherwise, upon receipt of a (potentially forwarded) NOTIFY message for a particular child zone at the published notification endpoint, the receiving side (parent registry or registrar) has two options:
それ以外の場合は、（潜在的に転送される）公開された通知エンドポイントで特定の子ゾーンのメッセージを受信すると、受信側（親レジストリまたはレジストラ）には2つのオプションがあります。
1. Acknowledge receipt by sending a NOTIFY response as described in [RFC1996], Section 4.7, and schedule an immediate check of the CDS/CDNSKEY/CSYNC RRsets published by that particular child zone (as appropriate for the type of NOTIFY received).
1. [RFC1996]、セクション4.7に記載されている通知応答を送信して領収書を確認し、その特定の子ゾーンによって公開されたCDS/CDNSKEY/CSYNC RRSetsの即時チェックをスケジュールします（受信した通知の種類に適しています）。
If the NOTIFY message contains an EDNS0 Report-Channel option [RFC9567] with an agent domain subordinate or equal to one of the NS hostnames listed in the delegation, the processing party SHOULD report any errors occurring during CDS/CDNSKEY/CSYNC processing by sending a report query with an appropriate EDE code as described in [RFC8914]. Reporting may be done asynchronously (outside of the NOTIFY transaction).
Notifyメッセージに、代表団にリストされているNSホスト名のいずれかに等しいエージェントドメインの1つに等しいEDNS0レポートチャネルオプション[RFC9567]が含まれている場合、処理党は、[RFC8914]に適切なEDEコードとレポートクエリを送信することにより、CDS/CDNSKEY/CSYNC処理中に発生するエラーを報告する必要があります。レポートは非同期に行われる場合があります（Notifyトランザクション以外）。
When using periodic scanning, notifications preempt the scanning 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 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 having received a notification), the NOTIFY-related state SHOULD be cleared, reverting to the default scanning schedule for this child.
定期的なスキャンを使用する場合、通知はスキャンタイマーを先取りします。NotifyによるチェックがCDS/ CDNSKEY/ CSYNC RRSETが実際に新しくなっているか、変更されていることがわかり、対応する子供のタイマーがリセットされ、スキャン周波数が低下する可能性があります（たとえば、週に1回）。CDS/CDNSKEY/CSYNCの変更がスキャンを通じて（通知を受け取っていない場合）後で検出された場合、Notify関連状態をクリアし、この子供のデフォルトのスキャンスケジュールに戻ります。
When introducing CDS/CDNSKEY/CSYNC scanning support at the same time as NOTIFY support, backwards compatibility considerations regarding the scanning interval do not apply; a low-frequency scanning schedule MAY thus be used by default in such cases.
通知サポートと同時にCDS/CDNSKEY/CSYNCスキャンサポートを導入する場合、スキャン間隔に関する後方互換性の考慮事項は適用されません。したがって、このような場合には、デフォルトでは、低周波スキャンスケジュールを使用できます。
2. Do not act upon the notification. To prevent retries, recipients SHOULD acknowledge the notification by sending a NOTIFY response even when otherwise ignoring the request, combined with a report query if feasible (see above). One reason to do this may be a rate limit (see Section 5), in which case "Blocked" (15) may be a suitable extended DNS error code.
2. 通知に基づいて行動しないでください。RETRIESを防ぐために、受信者は、リクエストを無視しても通知応答を送信して通知を認める必要があります。これを行う理由の1つは、レート制限（セクション5を参照）です。この場合、「ブロック」（15）は適切な拡張DNSエラーコードである可能性があります。
Implementing the first option will significantly decrease the convergence time (between publication of a new CDS/CDNSKEY/CSYNC record in the child and publication of the resulting DS), thereby providing improved service for the child.
最初のオプションを実装すると、収束時間が大幅に短縮されます（子どもに新しいCDS/CDNSKEY/CSYNCレコードの公開と結果のDSの公開の間）。
If, in addition to scheduling an immediate check for the child zone of the notification, the scanning schedule is also modified to be less frequent, the cost of providing the scanning service will be reduced.
通知の子ゾーンの即時チェックのスケジュールに加えて、スキャンスケジュールも変更されている場合、スキャンサービスを提供するコストが削減されます。
If an action is triggered by the receipt of a DNS NOTIFY, its execution relies on the same security model that the receiving party would apply if the action were triggered by something else. This is because the notification affects 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 security and authentication requirements (e.g., [RFC9615]) that the parent registry/registrar has chosen to apply.
DNS通知の受領によってアクションがトリガーされた場合、その実行は、アクションが他の何かによってトリガーされた場合、受信者が適用するのと同じセキュリティモデルに依存しています。これは、通知がアクションのタイミングだけに影響するためです。たとえば、DSブートストラップは、トリガーのタイプとは無関係に同じ方法で実行されると予想されます。これには、親レジストラ/レジストラが適用することを選択したすべてのセキュリティおよび認証要件（[RFC9615]など）が含まれます。
The original NOTIFY specification sidesteps most security issues by not relying on the information in the NOTIFY message in any way and instead only using it to "enter the state it would if the zone's refresh timer had expired" (Section 4.7 of [RFC1996]).
元のNotify Specificationは、Notifyメッセージの情報に依存せず、代わりに「ゾーンの更新タイマーが期限切れになった場合に状態を入力する」（[RFC1996]のセクション4.7）のみを使用することにより、ほとんどのセキュリティ問題をsidestepssに保証します。
This security model is reused for generalized NOTIFY messages. Therefore, it seems impossible to affect the behaviour of the recipient of the NOTIFY other than by hastening the timing for when different checks are initiated. As a consequence, while notifications themselves can be secured via access control mechanisms, this is not a requirement.
このセキュリティモデルは、一般化された通知メッセージのために再利用されます。したがって、異なるチェックが開始されたときのタイミングを早めること以外に、通知の受信者の動作に影響を与えることは不可能と思われます。結果として、通知自体はアクセス制御メカニズムを介して保護できますが、これは要件ではありません。
In general, the receipt of a notification message will cause the receiving party to perform one or more outbound queries for the records of interest (for example, NOTIFY(CDS) will cause CDS/CDNSKEY queries). When done using standard DNS, the size of these queries is comparable to that of the NOTIFY messages themselves, rendering any amplification attempts futile. The number of queries triggered per notification is also limited by the requirement that a NOTIFY message can refer to one child only.
一般に、通知メッセージの受領により、受信者は関心のある記録に対して1つ以上のアウトバウンドクエリを実行します（たとえば、通知（CD）はCD/CDNSKEYクエリを引き起こします）。標準のDNSを使用して行われた場合、これらのクエリのサイズは、通知メッセージ自体のサイズに匹敵し、増幅試行が無駄になります。通知ごとにトリガーされるクエリの数は、通知メッセージが1人の子供のみを参照できるという要件によっても制限されます。
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 unforeseen events.
ただし、暗号化されたトランスポートを介して発信クエリが発生すると、帯域幅と計算の負担に関して、いくらか増幅が可能になります。この場合、予期せぬ出来事の下でも、作業に境界を絞るという通常の原則が適用されます。
Therefore, receivers MUST implement rate limiting for notification processing. It is RECOMMENDED to configure rate limiting independently for both the notification's source IP address and the name of the zone that is conveyed in the NOTIFY message. Rate limiting also mitigates the processing load from garbage notifications.
したがって、受信者は通知処理のためにレート制限を実装する必要があります。通知のソースIPアドレスとNotifyメッセージで伝えられるゾーンの名前の両方に対して、独立してレート制限を構成することをお勧めします。レート制限は、ガベージ通知からの処理負荷も軽減します。
Alternative solutions (such as signing notifications and validating their signatures) appear significantly more expensive without tangible benefit.
代替ソリューション（通知の署名や署名の検証など）は、具体的な利益なしには大幅に高価に見えます。
In order to facilitate schemes that are authenticated outside of DNSSEC (such as via SIG(0)), zones containing DSYNC records are not required to be signed. Spoofed DSYNC responses would prevent notifications from reaching their legitimate target, and a different party may receive unsolicited notifications; however, both effects can also be achieved in the presence of DNSSEC. The illegitimate target is also enabled to learn notification contents in real time, which may be a privacy concern for the sender. If so, the sender may choose to ignore unsigned DSYNC records.
DNSSECの外部で認証されたスキーム（SIG（0）経由など）の外で認証されたスキームを容易にするために、DSYNCレコードを含むゾーンに署名する必要はありません。スプーフィングされたDSYNC応答は、通知が正当なターゲットに到達するのを防ぎ、別の当事者が未承諾の通知を受け取る場合があります。ただし、DNSSECの存在下では、両方の効果も達成できます。また、非合法ターゲットは、通知コンテンツをリアルタイムで学習することもできます。これは、送信者にとってプライバシーの懸念事項である可能性があります。その場合、送信者は、署名されていないDSYNCレコードを無視することを選択できます。
IANA has registered DSYNC in the "Resource Record (RR) TYPEs" registry under the "Domain Name System (DNS) Parameters" registry group as follows:
IANAは、「ドメイン名システム（DNS）パラメーター」レジストリグループの下にある「リソースレコード（RR）タイプ」レジストリにDSYNCを登録しています。
Type:
タイプ：
DSYNC
dsync
Value:
値：
66
66
Meaning:
意味：
Endpoint discovery for delegation synchronization
委任の同期のためのエンドポイント発見
Reference:
参照：
RFC 9859
RFC 9859
IANA has created the following new registry in the "Domain Name System (DNS) Parameters" registry group:
IANAは、「ドメイン名システム（DNS）パラメーター」レジストリグループに次の新しいレジストリを作成しました。
Name:
名前：
DSYNC: Location of Synchronization Endpoints
DSYNC：同期エンドポイントの場所
Registration Procedure:
登録手順：
Expert Review
専門家のレビュー
Reference:
参照：
RFC 9859
RFC 9859
The initial contents for the registry are as follows:
レジストリの最初の内容は次のとおりです。
+========+===================+==========================+===========+
| RRtype | Scheme (Mnemonic) | Purpose | Reference |
+========+===================+==========================+===========+
| | 0 | Null scheme (no-op) | RFC 9859 |
+--------+-------------------+--------------------------+-----------+
| CDS | 1 (NOTIFY) | Delegation management | RFC 9859 |
+--------+-------------------+--------------------------+-----------+
| CSYNC | 1 (NOTIFY) | Delegation management | RFC 9859 |
+--------+-------------------+--------------------------+-----------+
| | 2-127 | Unassigned | |
+--------+-------------------+--------------------------+-----------+
| | 128-255 | Reserved for Private | RFC 9859 |
| | | Use | |
+--------+-------------------+--------------------------+-----------+
Table 1
Requests to register additional entries MUST include the following fields:
追加のエントリを登録するリクエストには、次のフィールドを含める必要があります。
RRtype:
RRTYPE：
An RRtype that is defined for use
使用するために定義されているRRType
Scheme:
スキーム：
The mode used for contacting the desired notification address
目的の通知アドレスに連絡するために使用されるモード
Mnemonic:
ニモニック：
The scheme's shorthand string used in presentation format
スキームの速記の文字列は、プレゼンテーション形式で使用されます
Purpose:
目的：
Use case description
ユースケースの説明
Reference:
参照：
Location of specification or registration source
仕様または登録ソースの場所
Registration requests are to be recorded by IANA after Expert Review [RFC8126]. Expert Reviewers should take the points below into consideration; however, they are experts and should be given substantial latitude:
登録要求は、専門家のレビュー[RFC8126]の後にIANAによって記録されます。専門家のレビュアーは、以下のポイントを考慮に入れる必要があります。しかし、彼らは専門家であり、かなりの緯度を与えられるべきです。
* 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.
* ポイントスクワットは落胆する必要があります。レビューアは、登録リクエストに十分な情報を取得して、使用が既に登録されているものを複製しないようにし、ポイントが展開で使用される可能性が高いことを確認することをお勧めします。「プライベート使用」としてタグ付けされたコードポイントは、テスト目的と閉鎖環境を目的としています。他の範囲のコードポイントは、テスト用に割り当てられないでください。
* A specification of a scheme is desirable, but early assignment before a specification is available is also possible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. A scheme number may have exactly one mnemonic.
* スキームの仕様が望ましいですが、仕様が利用可能になる前の早期の割り当ても可能です。仕様が提供されていない場合、提供された説明には、ポイントが使用されているものを識別するのに十分な情報が必要です。スキーム番号には、ちょうど1つのニーモニックがある場合があります。
* Experts should take into account that field values are fit for purpose. For example, the mnemonic should be indicative and have a plausible connection to the scheme's notification mechanism.
* 専門家は、フィールド値が目的に適合していることを考慮する必要があります。たとえば、ニーモニックは指示的であり、スキームの通知メカニズムにもっともらしい接続を持っている必要があります。
Per [RFC8552], IANA has registered the following entries to the "Underscored and Globally Scoped DNS Node Names" registry within the "Domain Name System (DNS) Parameters" registry group:
[RFC8552]ごとに、IANAは「ドメイン名システム（DNS）パラメーター」レジストリグループ内の「アンダースコアリングされたDNSノード名」レジストリに次のエントリを登録しました。
+=========+============+===========+
| RR Type | _NODE NAME | Reference |
+=========+============+===========+
| DSYNC | _dsync | RFC 9859 |
+---------+------------+-----------+
Table 2
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>.
[RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS",
RFC 7477, DOI 10.17487/RFC7477, March 2015,
<https://www.rfc-editor.org/info/rfc7477>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017,
<https://www.rfc-editor.org/info/rfc8078>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[RFC9567] Arends, R. and M. Larson, "DNS Error Reporting", RFC 9567,
DOI 10.17487/RFC9567, April 2024,
<https://www.rfc-editor.org/info/rfc9567>.
[RFC9615] Thomassen, P. and N. Wisiol, "Automatic DNSSEC
Bootstrapping Using Authenticated Signals from the Zone's
Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024,
<https://www.rfc-editor.org/info/rfc9615>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012,
<https://www.rfc-editor.org/info/rfc6781>.
[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
"DNSSEC Key Rollover Timing Considerations", RFC 7583,
DOI 10.17487/RFC7583, October 2015,
<https://www.rfc-editor.org/info/rfc7583>.
[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
DOI 10.17487/RFC8901, September 2020,
<https://www.rfc-editor.org/info/rfc8901>.
[RFC1996] introduced the concept of a DNS NOTIFY message, which was used to improve the convergence time for secondary servers when a DNS zone had been updated in the primary server. The basic idea was to augment the original "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).
[RFC1996]は、DNS通知メッセージの概念を導入しました。これは、プライマリサーバーでDNSゾーンが更新されたときにセカンダリサーバーの収束時間を改善するために使用されました。基本的なアイデアは、それ以外の場合は非常に非効率的な一般的なケースの「プッシュ」メカニズム（通知）を使用して、元の「プル」メカニズム（周期SOAクエリ）を強化することでした（変化のためのプライマリのゆっくりした収束または無駄で過度に頻繁にスキャンするため）。
While it is possible to indicate how frequently checks should occur (via the SOA Refresh parameter), these checks did not allow catching zone changes that fall between checkpoints. [RFC1996] addressed the optimization of the time-and-cost trade-off between a secondary server frequently checking for new versions of a zone and infrequent checks by replacing scheduled scanning with the more efficient NOTIFY mechanism.
（SOAリフレッシュパラメーターを介して）チェックが発生する頻度を示すことは可能ですが、これらのチェックでは、チェックポイント間に収まるゾーンのキャッチングの変更を許可しませんでした。[RFC1996]は、スケジュールされたスキャンをより効率的な通知メカニズムに置き換えることにより、ゾーンの新しいバージョンとまれなチェックを頻繁にチェックするセカンダリサーバー間の時間とコストのトレードオフの最適化に対処しました。
Today, we have similar issues with slow updates of DNS data in spite of the data having been published. The two most obvious cases are CDS and CSYNC scanners deployed in a growing number of TLD registries. Because of the large number of child delegations, scanning for CDS and CSYNC records is rather slow (as in, infrequent).
今日、データが公開されているにもかかわらず、DNSデータの遅い更新に関する同様の問題があります。最も明白な2つのケースは、ますます多くのTLDレジストリに展開されたCDとCSYNCスキャナーです。多数の子どもの代表団のため、CDとCSYNCレコードのスキャンはかなり遅い（まれであるように）。
Only a very small number of the delegations will have updated a CDS or CDNSKEY record in between two scanning runs. However, frequent scanning for CDS and CDNSKEY records is costly, and infrequent scanning causes slower convergence (i.e., delay until the DS RRset is updated).
非常に少数の代表団のみが、2回のスキャンランの間にCDSまたはCDNSKEYレコードを更新します。ただし、CDSおよびCDNSKEYレコードの頻繁なスキャンはコストがかかり、まれなスキャンにより収束が遅くなります（つまり、DS RRSetが更新されるまで遅延）。
Unlike in the original case, where the primary is able to suggest the scanning interval via the SOA Refresh parameter, an equivalent mechanism does not exist for DS-related scanning.
プライマリがSOAリフレッシュパラメーターを介してスキャン間隔を提案できる元のケースとは異なり、DS関連のスキャンには同等のメカニズムが存在しません。
All of the above also applies to automated NS and glue record maintenance via CSYNC scanning [RFC7477]. Again, given that CSYNC records change only rarely, frequent scanning of a large number of delegations seems disproportionately costly, while infrequent scanning causes slower convergence (delay until the delegation is updated).
上記のすべては、CSYNCスキャン[RFC7477]を介した自動化されたNSおよび接着剤レコードメンテナンスにも適用されます。繰り返しになりますが、CSYNCレコードの変更はめったになく、多数の委任の頻繁なスキャンのみが不釣り合いにコストがかかりますが、まれなスキャンは収束が遅くなります（委任が更新されるまで遅延）。
While use of the NOTIFY mechanism for coordinating the key exchange in multi-signer setups [RFC8901] is conceivable, the detailed specification is left for future work.
マルチ署名者セットアップ[RFC8901]で主要な交換を調整するためのNotifyメカニズムの使用は考えられますが、詳細な仕様は将来の作業のために残されています。
The authors acknowledge the contributions and reviews of the following individuals (in order of their first contribution or review): Joe Abley, Mark Andrews, Christian Elmerot, Ólafur Guðmundsson, Paul Wouters, Brian Dickson, Warren Kumari, Geoff Huston, Patrick Mevzek, Tim Wicinski, Q Misell, Stefan Ubbink, Matthijs Mekking, Kevin P. Fleming, Nicolai Leymann, Giuseppe Fioccola, Peter Yee, Tony Li, Paul Wouters, Roman Danyliw, Peter van Dijk, John Scudder, Éric Vyncke, and Oli Schacher.
著者は、次の個人の貢献とレビューを認めています（最初の貢献またはレビューの順に）：ジョー・アンドリュース、クリスチャン・エルメロット、オラファー・ガンドソン、ポール・ウィーターズ、ブライアン・ディクソン、ウォーレン・クマリ、ジェフ・ヒューストン、パトリック・メヴゼック、ティム・ウィシンキ、フレミング、ニコライ・レイマン、ジュゼッペ・フィオッコーラ、ピーター・イー、トニー・リー、ポール・ウーターズ、ローマン・ダニリウ、ピーター・ヴァン・ディック、ジョン・スカダー、エリック・ヴィンケ、およびオリ・シャッハー。
Johan Stenstam
The Swedish Internet Foundation
Email: johan.stenstam@internetstiftelsen.se
Peter Thomassen
deSEC, Secure Systems Engineering
Email: peter@desec.io
John Levine
Standcore LLC
Email: standards@standcore.com