[要約] RFC 10026は、子DNSオペレーターから提示されるDNSSEC委任署名者(DS)のパラメーターを自動で受け入れる仕組みを運用する際の推奨事項をまとめたBest Current Practiceです。レジストリやレジストラーである親エージェントが判断する必要のある受理チェック、エラーおよび成功の通知、同時更新のような複数者にまたがる問題について、実務上どう対処するのが望ましいかを示します。
Internet Engineering Task Force (IETF) S. Sheng
Request for Comments: 10026
BCP: 246 P. Thomassen
Category: Best Current Practice deSEC
ISSN: 2070-1721 July 2026
Enabling support for automatic acceptance of DNSSEC Delegation Signer (DS) parameters from the Child DNS operator (via RFCs 7344, 8078, and 9615) requires the Parental Agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error and success reporting, and multi-party issues such as concurrent updates. This document describes recommendations about how these points are best addressed in practice.
子 DNS オペレーターからの DNSSEC 委任署名者 (DS) パラメーターの自動受け入れのサポート (RFC 7344、8078、および 9615 経由) を有効にするには、親エージェント (多くの場合レジストリまたはレジストラ) が、受け入れチェック、エラーと成功のレポート、および同時更新などのマルチパーティの問題に関して多くの技術的な決定を行う必要があります。この文書では、これらの点に実際にどのように対処するのが最善であるかについての推奨事項について説明します。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベスト プラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。BCP の詳細については、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/rfc10026.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10026 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
2.1. Requirements Notation
3. Recommendations for Deployments of DS Automation
4. Acceptance Checks and Safety Measures
4.1. Recommendations
4.2. Analysis
4.2.1. Continuity of Resolution
4.2.2. Timing, TTLs, and Caching
4.2.3. CDS vs. CDNSKEY
5. Reporting and Transparency
5.1. Recommendations
5.2. Analysis
6. Registration Locks
6.1. Recommendations
6.2. Analysis
6.2.1. Registrar vs. Registry Lock
6.2.2. Detailed Rationale
7. Multiple Submitting Parties and Suspension of Automation
7.1. Recommendations
7.2. Analysis
7.2.1. Necessity of Non-Automatic Updates
7.2.2. Impact of Non-Automatic Updates: When to Suspend
Automation
7.2.3. Concurrent Automatic Updates
8. IANA Considerations
9. Operational Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Recommendations Overview
A.1. Acceptance Checks and Safety Measures
A.2. Reporting and Transparency
A.3. Registration Locks
A.4. Multiple Submitting Parties and Suspension of Automation
Acknowledgments
Authors' Addresses
[RFC7344], [RFC8078], and [RFC9615] automate DNSSEC [RFC9364] delegation trust maintenance by having the child publish Child DS (CDS) and/or Child DNSKEY (CDNSKEY) records, which indicate the delegation's desired DNSSEC parameters ("DS automation").
[RFC7344]、[RFC8078]、および [RFC9615] は、子に子 DS (CDS) および/または子 DNSKEY (CDNSKEY) レコードを公開させることで、DNSSEC [RFC9364] 委任の信頼維持を自動化します。これらのレコードは、委任の必要な DNSSEC パラメータを示します (「DS 自動化」)。
Parental Agents using these protocols have to make a number of technical decisions relating to issues of acceptance checks, timing, error reporting, locks, etc. Additionally, when using the registrant-registrar-registry (RRR) model (as is common amongst top-level domains (TLDs)), both the registrar and the registry can effect parent-side changes to the delegation. In such a situation, additional opportunities for implementation differences arise.
これらのプロトコルを使用する親エージェントは、受け入れチェック、タイミング、エラー報告、ロックなどの問題に関連する多くの技術的な決定を下す必要があります。さらに、登録者-レジストラ-レジストリ (RRR) モデル (トップレベル ドメイン (TLD) では一般的です) を使用する場合、レジストラとレジストリの両方が委任に対する親側の変更を行うことができます。このような状況では、実装上の差異がさらに発生する可能性が生じます。
Not all existing DS automation deployments have made the same choices with respect to these questions, leading to somewhat inconsistent behavior. From the perspective of a domain holder with domain names under various TLDs, this may be unexpected and confusing.
既存の DS 自動化展開のすべてがこれらの質問に関して同じ選択を行っているわけではないため、多少一貫性のない動作が発生しています。さまざまな TLD でドメイン名を持つドメイン所有者の観点からすると、これは予期せぬことであり、混乱を招く可能性があります。
In the following sections, operational questions are first raised and answered with the corresponding recommendations. Each section is concluded with an analysis of its recommendations and related considerations. A combined view of the recommendations from all sections is given in Appendix A.
次のセクションでは、運用に関する質問が最初に提起され、対応する推奨事項で回答されます。各セクションは、その推奨事項と関連する考慮事項の分析で終わります。すべてのセクションの推奨事項を組み合わせた図を付録 A に示します。
Readers are expected to be familiar with DNSSEC [RFC9364] [RFC9615] [RFC9859] [RFC9975].
読者は、DNSSEC [RFC9364] [RFC9615] [RFC9859] [RFC9975] に精通していることが期待されます。
The core issues addressed in the document are derived from Section 4.4 of [SAC126]. Readers are referred to this report for additional background.
この文書で取り上げられている中心的な問題は、[SAC126] のセクション 4.4 に由来しています。追加の背景については、このレポートを参照してください。
The term "Parental Agent" is used as defined in Section 1.1 of [RFC7344]. The document also uses terms defined in [RFC9499], in particular:
「親エージェント」という用語は、[RFC7344] のセクション 1.1 で定義されているように使用されます。この文書では、[RFC9499] で定義されている用語、特に次の用語も使用しています。
* DNS operator
* DNSオペレーター
* Registry
* レジストリ
* Registrant
* 登録者
* Registrar
* レジストラ
In addition, the document makes use of the following terms:
さらに、この文書では次の用語が使用されています。
Child zone:
子ゾーン:
DNS zone whose delegation is in the Parent zone.
委任が親ゾーンにある DNS ゾーン。
Child (DNS operator):
子 (DNS オペレーター):
DNS operator responsible for a Child zone.
子ゾーンを担当する DNS オペレーター。
Parent zone:
親ゾーン:
DNS zone that holds a delegation for a Child zone.
子ゾーンの委任を保持する DNS ゾーン。
Parent:
親：
The operator responsible for a Parent zone and thus involved with the maintenance of the delegation's DNSSEC parameters (in particular, the acceptance of these parameters and the publication of corresponding DS records).
親ゾーンを担当するオペレーターであり、委任の DNSSEC パラメーターの保守 (特に、これらのパラメーターの受け入れと対応する DS レコードの公開) に関与します。
RRR Model:
RRRモデル:
The registrant-registrar-registry (RRR) interaction framework, where registrants interact with a registrar to register and manage domain names and registrars interact with the domain's registry for the provision and management of domain names on the registrant's behalf. This model is common amongst TLDs.
登録者-レジストラー-レジストリ (RRR) 対話フレームワーク。登録者はレジストラと対話してドメイン名の登録と管理を行い、レジストラはドメインのレジストリと対話して、登録者に代わってドメイン名の提供と管理を行います。このモデルは TLD 間で一般的です。
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] で説明されているように解釈されます。
The guidelines for deploying DS automation set out in this document are meant to achieve more uniform treatment across suffixes -- minimizing user surprise and providing baseline safety and uniformity of behavior. They are also intended to prevent disruption of DNS and DNSSEC functionality. At a minimum, compliance with this RFC requires support for both DNSSEC bootstrapping [RFC9615] and subsequent updates [RFC7344] [RFC8078] under the implementation guidance below.
このドキュメントで説明されている DS 自動化の導入ガイドラインは、サフィックス全体でより均一な処理を実現することを目的としており、ユーザーの驚きを最小限に抑え、ベースラインの安全性と動作の均一性を提供します。これらは、DNS および DNSSEC 機能の中断を防ぐことも目的としています。この RFC に準拠するには、少なくとも、以下の実装ガイダンスに基づいて、DNSSEC ブートストラップ [RFC9615] とその後の更新 [RFC7344] [RFC8078] の両方をサポートする必要があります。
The recommendations optimize interoperability and safety. In certain cases, local policy may take precedence, such as when a registry is subjected to national cryptographic policy requirements. However, not following any requirements designated with the "SHOULD" key word will generally lead to undesirable effects of ambiguity and interoperability issues. When implementing these recommendations, operators MUST mitigate issues arising from any particular deviation.
推奨事項により、相互運用性と安全性が最適化されます。レジストリが国の暗号化ポリシー要件の対象となる場合など、特定の場合には、ローカル ポリシーが優先されることがあります。ただし、「SHOULD」キーワードで指定された要件に従わないと、一般に、あいまいさおよび相互運用性の問題による望ましくない影響が生じます。これらの推奨事項を実装する場合、オペレーターは特定の逸脱から生じる問題を軽減しなければなりません。
Registries with additional requirements on DS update checks MAY implement any additional checks in line with local policy.
DS 更新チェックに関する追加要件があるレジストリは、ローカル ポリシーに従って追加チェックを実装してもよい(MAY)。
This section provides recommendations to address the following operational questions:
このセクションでは、次の運用上の問題に対処するための推奨事項を示します。
* What kind of acceptance checks should be performed on DS parameters?
* DS パラメータに対してどのような種類の受け入れチェックを実行する必要がありますか?
* Should these checks be performed upon acceptance or also continually when in place?
* これらのチェックは、受け入れ時に実行する必要がありますか、それとも実施中に継続的に実行する必要がありますか?
* How do TTLs and caching impact DS provisioning? How important is timing in a child key change?
* TTL とキャッシュは DS プロビジョニングにどのような影響を与えますか?子キーの変更のタイミングはどのくらい重要ですか?
* Are parameters for DS automation best conveyed as CDNSKEY or CDS records or both?
* DS 自動化のパラメータは、CDNSKEY レコード、CDS レコード、あるいはその両方として伝達されるのが最適ですか?
1. Entities performing automated DS maintenance MUST verify:
1. 自動 DS メンテナンスを実行するエンティティは、以下を確認する必要があります。
a. the unambiguous intent of each DS bootstrapping or update request as per [RFC9975], by checking its consistency both
a. [RFC9975] に従って、各 DS ブートストラップまたは更新リクエストの明確な意図を、両方の一貫性をチェックすることによって確認します。
* between any published CDS and CDNSKEY records and
* 公開された CDS レコードと CDNSKEY レコードの間、および
* across all authoritative nameservers in the delegation,
* 委任内のすべての権限のあるネームサーバーにわたって、
and
そして
b. that the resulting DS record set would allow continued DNSSEC validation if deployed
b. 導入された場合、結果として得られる DS レコード セットにより DNSSEC 検証を継続できること
and cancel the update if the verifications do not succeed.
検証が成功しなかった場合は、更新をキャンセルします。
2. Parent-side entities (such as registries) SHOULD allow for effective rollback by reducing a DS record set's TTL to a value between 5-15 minutes when a new set of records is published, and restore the previous (or, if unavailable, default) TTL value at a later occasion (but not before the previous DS RRset's TTL has expired).
2. 親側エンティティ (レジストリなど) は、新しいレコード セットが公開されるときに DS レコード セットの TTL を 5 ～ 15 分の値に減らすことで効果的なロールバックを可能にし、後で (ただし、以前の DS RRset の TTL の有効期限が切れる前に) 以前の (または、使用できない場合はデフォルトの) TTL 値を復元する必要があります。
Besides a prudent choice of TTL, prompt DS changes also require timely discovery of update requests. For recommended methods, see Section 4.2.2.
TTL を賢明に選択することに加えて、DS の変更を迅速に行うには、更新リクエストをタイムリーに検出することも必要です。推奨される方法については、セクション 4.2.2 を参照してください。
3. DNS operators MUST publish both CDNSKEY and CDS records (unless the parent's preference is known) and follow best practice for the choice of hash digest type [DS-IANA].
3. DNS オペレーターは、CDNSKEY レコードと CDS レコードの両方を公開し (親の設定が不明な場合を除く)、ハッシュ ダイジェスト タイプ [DS-IANA] の選択に関するベスト プラクティスに従わなければなりません (MUST)。
To maintain the basic resolution function, it is critical to avoid deployment of flawed DS record sets in the Parent zone. It is therefore necessary for the Parent to verify that the DS record set resulting from an automated (or even manual) update does not break DNSSEC validation if deployed and otherwise cancel the update.
基本的な解決機能を維持するには、親ゾーンに欠陥のある DS レコード セットの展開を避けることが重要です。したがって、親は、自動 (または手動) 更新によって生成された DS レコード セットが、展開されている場合は DNSSEC 検証を中断しないことを確認し、そうでない場合は更新をキャンセルする必要があります。
This is best achieved by:
これを実現するには、次の方法が最適です。
1. verifying that consistent CDS/CDNSKEY responses are served by all of the delegation's nameservers [RFC9975];
1. 一貫した CDS/CDNSKEY 応答が委任のすべてのネームサーバーによって提供されることを検証する [RFC9975]。
2. verifying that the resulting DS Resource Record set (RRset) does not break the delegation if applied ([RFC7344], Section 4.1), i.e., it provides at least one valid path for validators to use ([RFC6840], Section 5.11). This is the case if the child's DNSKEY RRset has a valid RRSIG signature from a key that is referenced by at least one DS record, with the digest type and signing algorithm values designated as "RECOMMENDED" or "MUST" in the "Use for DNSSEC Validation" columns of the relevant IANA registries ([DS-IANA] and [DNSKEY-IANA]). Note that these checks need not be enforced when provisioning DS records manually in order to enable the use of other digest types or algorithms for potentially non-interoperable purposes.
2. 結果として得られる DS リソース レコード セット (RRset) が、適用された場合に委任を中断しないこと ([RFC7344]、セクション 4.1)、つまり、バリデーターが使用する有効なパスを少なくとも 1 つ提供すること ([RFC6840]、セクション 5.11) を検証します。これは、子の DNSKEY RRset に少なくとも 1 つの DS レコードによって参照される鍵からの有効な RRSIG 署名があり、関連する IANA レジストリ ([DS-IANA] および [DNSKEY-IANA]) の「DNSSEC 検証に使用」列でダイジェスト タイプと署名アルゴリズムの値が「RECOMMENDED」または「MUST」として指定されている場合に当てはまります。DS レコードを手動でプロビジョニングする場合、相互運用できない可能性のある目的で他のダイジェスト タイプまたはアルゴリズムを使用できるようにするために、これらのチェックを強制する必要はないことに注意してください。
Even without an update being requested, Parents may occasionally check whether the current DS contents would still be acceptable if they were newly submitted in CDS/CDNSKEY form (see Section 4). Any failures -- such as a missing DNSKEY due to improper rollover timing ([RFC6781], Section 4.1) or changed algorithm requirements -- can then be communicated in line with Section 5.1, without altering or removing the existing DS RRset.
更新が要求されていなくても、保護者は、現在の DS コンテンツが CDS/CDNSKEY 形式で新たに送信された場合に引き続き受け入れられるかどうかを確認することがあります (セクション 4 を参照)。不適切なロールオーバー タイミング ([RFC6781]、セクション 4.1) または変更されたアルゴリズム要件による DNSKEY の欠落などの障害は、既存の DS RRset を変更または削除することなく、セクション 5.1 に従って通信できます。
For timely execution of DS provisioning requests, it is important to discover them reasonably quickly. The best way to do so is for the Child DNS operator to send an [RFC9859] notification to the parent (Sections 4.1 and 4.2 of [RFC9859]). In addition to publication of the relevant notification targets, this requires the advertised endpoint to actually listen (Sections 3 and 4.3 of [RFC9859]). By explicitly naming a responsible endpoint, this method also resolves potential contention between registry and registrar when the RRR model is used (see Section 7.2.3). Note that periodic scanning is a suboptimal alternative as it introduces policy-dependent delays and does not scale well for large zones.
DS プロビジョニング リクエストをタイムリーに実行するには、リクエストを合理的に迅速に検出することが重要です。そうするための最良の方法は、子 DNS オペレータが [RFC9859] 通知を親に送信することです ([RFC9859] のセクション 4.1 および 4.2)。関連する通知ターゲットの公開に加えて、これには、アドバタイズされたエンドポイントが実際にリッスンする必要があります ([RFC9859] のセクション 3 および 4.3)。この方法では、責任のあるエンドポイントを明示的に指定することで、RRR モデルの使用時にレジストリとレジストラ間の潜在的な競合も解決します (セクション 7.2.3 を参照)。定期的なスキャンは、ポリシーに依存した遅延が発生し、大規模なゾーンでは適切に拡張できないため、次善の代替手段であることに注意してください。
To further reduce the impact of any misconfigured DS record set -- be it from automated or from manual provisioning -- the option to quickly roll back the delegation's DNSSEC parameters is of great importance. This is achieved by setting a comparatively low TTL on the DS record set in the parent domain, at the cost of reduced resiliency against nameserver unreachability due to the earlier expiration of cached records. The availability risk can be mitigated by limiting such TTLs to a brief time period after a change to the DS configuration, during which rollbacks are most likely to occur.
自動プロビジョニングまたは手動プロビジョニングによる、誤った DS レコード セットの影響をさらに軽減するには、委任の DNSSEC パラメータを迅速にロールバックするオプションが非常に重要です。これは、親ドメインの DS レコード セットに比較的低い TTL を設定することで実現されますが、その代わりに、キャッシュされたレコードの有効期限が早くなり、ネームサーバーに到達できなくなることに対する回復力が低下します。可用性のリスクは、ロールバックが発生する可能性が最も高い DS 構成の変更後の短期間にこのような TTL を制限することで軽減できます。
Registries therefore should significantly lower the DS RRset's TTL for some time following bootstrapping or an update. Pragmatic values for the reduced TTL value range between 5-15 minutes. Using values below 5 minutes risks excessive queries, and using values greater than 15 minutes may impact recovery from operational mistakes.
したがって、ブートストラップまたは更新後のしばらくの間、レジストリは DS RRset の TTL を大幅に下げる必要があります。短縮 TTL 値の実際的な値の範囲は 5 ～ 15 分です。5 分未満の値を使用すると過剰なクエリが発生する危険性があり、15 分を超える値を使用すると操作ミスからの回復に影響を与える可能性があります。
Note that recent measurements have demonstrated low TTLs like the above to have negligible impact on the overall load of a registry's authoritative nameserver infrastructure [LowTTL].
最近の測定では、上記のような低い TTL がレジストリの権威ネームサーバー インフラストラクチャ [LowTTL] の全体的な負荷に与える影響はごくわずかであることが実証されていることに注意してください。
The reduction should be in effect at least for a couple of days and until the previous DS record set has expired from caches, i.e., the period during which the low-TTL is applied typically will significantly exceed the normal TTL value. When using the Extensible Provisioning Protocol (EPP) [RFC5730], the domain <info> command described in Section 2.1.1.2 of [RFC9803] can be used by the registrar to obtain the registry's TTL policy.
この削減は、少なくとも数日間、以前の DS レコード セットがキャッシュから期限切れになるまで有効である必要があります。つまり、低 TTL が適用される期間は通常、通常の TTL 値を大幅に超えます。Extensible Provisioning Protocol (EPP) [RFC5730] を使用する場合、レジストラは [RFC9803] のセクション 2.1.1.2 で説明されているドメイン <info> コマンドを使用して、レジストリの TTL ポリシーを取得できます。
While this approach enables quick rollbacks, timing of the desired DS update process itself is largely governed by the previous DS RRset's TTL and therefore does not generally benefit from an overall speed-up. Note also that nothing is gained from first lowering the TTL of the old DS RRset: Such an additional step would, in fact, require another wait period while resolver caches adjust. For the sake of completeness, there likewise is no point to increasing any DS TTL values beyond their normal value.
このアプローチにより迅速なロールバックが可能になりますが、必要な DS 更新プロセス自体のタイミングは以前の DS RRset の TTL によって主に支配されるため、一般に全体的な高速化の恩恵は受けられません。古い DS RRset の TTL を最初に下げても何も得られないことにも注意してください。このような追加の手順では、実際には、リゾルバー キャッシュが調整されるまでさらに待機時間が必要になります。完全を期すために、DS TTL 値を通常の値を超えて増やすことも同様に意味がありません。
DS records can be generated from information provided either in DS format (CDS) or in DNSKEY format (CDNSKEY). While the format of CDS records is identical to that of DS records (so the record data can be taken verbatim), generation of a DS record from CDNSKEY information involves computing a hash.
DS レコードは、DS 形式 (CDS) または DNSKEY 形式 (CDNSKEY) で提供された情報から生成できます。CDS レコードの形式は DS レコードの形式と同じですが (そのためレコード データをそのまま取得できます)、CDNSKEY 情報からの DS レコードの生成にはハッシュの計算が含まれます。
Whether a Parent processes CDS or CDNSKEY records depends on their preference:
親が CDS レコードを処理するか CDNSKEY レコードを処理するかは、親の設定によって異なります。
* Processing (and storing) CDNSKEY information allows the Parent to control the choice of hash algorithms. The Parent may then unilaterally regenerate DS records with a different choice of hash algorithm(s) whenever deemed appropriate.
* CDNSKEY 情報を処理 (および保存) することにより、親はハッシュ アルゴリズムの選択を制御できるようになります。その後、親は、適切とみなされる場合にはいつでも、異なるハッシュ アルゴリズムを選択して一方的に DS レコードを再生成できます。
* Processing CDS information allows the Child DNS operator to control the hash digest type used in DS records, enabling the Child DNS operator to deploy (for example) experimental hash digests and removing the need for registry-side changes when additional digest types become available.
* CDS 情報を処理すると、子 DNS オペレータは DS レコードで使用されるハッシュ ダイジェスト タイプを制御できるようになり、子 DNS オペレータが (たとえば) 実験的なハッシュ ダイジェストを展開できるようになり、追加のダイジェスト タイプが利用可能になったときにレジストリ側を変更する必要がなくなります。
The need to make a choice in the face of this dichotomy is not specific to DS automation: Even when DNSSEC parameters are relayed to the Parent through conventional channels, the Parent has to make some choice about which format(s) to accept.
この二分法に直面して選択を行う必要があるのは、DS 自動化に特有のものではありません。DNSSEC パラメータが従来のチャネルを通じて親に中継される場合でも、親はどの形式を受け入れるかについて何らかの選択をする必要があります。
As there exists no protocol for Child DNS operators to discover a Parent's input format preference, interoperability requires publication of both CDNSKEY as well as CDS records, in line with Section 5 of [RFC7344]. The choice of hash digest type should follow current best practice [DS-IANA].
子 DNS オペレータが親の入力形式設定を検出するためのプロトコルが存在しないため、相互運用性を確保するには、[RFC7344] のセクション 5 に従って、CDNSKEY と CDS レコードの両方の公開が必要です。ハッシュ ダイジェスト タイプの選択は、現在のベスト プラクティス [DS-IANA] に従う必要があります。
Publishing the same information in two different formats is not ideal. Still, it is much less complex and costly than burdening the Child DNS operator with discovering each Parent's current policy. Also, it is very easily automated. Operators should ensure that published RRsets are consistent with each other.
同じ情報を 2 つの異なる形式で公開することは理想的ではありません。それでも、各親の現在のポリシーを検出するという子 DNS オペレータの負担に比べれば、はるかに複雑さとコストが軽減されます。また、非常に簡単に自動化できます。オペレーターは、公開された RRset が相互に一貫していることを確認する必要があります。
If both RRsets are published, Parents are expected to verify consistency between them by verifying that they refer to the same set of keys [RFC9975]. By not second-guessing inconsistencies (such as by RRset recency) and instead rejecting them, responsibility to clearly express each update request is placed on the Child DNS operator.
両方の RRset が公開されている場合、親は、それらが同じ鍵セットを参照していることを検証することによって、それらの間の一貫性を検証することが期待されます [RFC9975]。不一致を後から推測せず (RRset の最新性などにより) 拒否することで、各更新リクエストを明確に表現する責任が子 DNS オペレータに課されます。
CDS records need only be considered for CDNSKEY consistency when their digest type field is designated as "MUST" in the "Implement for DNSSEC Delegation" column of the "Digest Algorithms" registry [DS-IANA]. Consistency of records with other digest types need not be verified, especially when the digest type is unsupported; such records can be ignored. Note that this does not imply a restriction on the DS hash digest types: If no inconsistencies are found, the parent can publish DS records with whatever digest type(s) it prefers.
CDS レコードは、「ダイジェスト アルゴリズム」レジストリ [DS-IANA] の「DNSSEC 委任の実装」列でダイジェスト タイプ フィールドが「MUST」に指定されている場合にのみ、CDNSKEY の整合性を考慮する必要があります。特にダイジェスト タイプがサポートされていない場合、他のダイジェスト タイプとのレコードの一貫性を検証する必要はありません。そのような記録は無視できます。これは DS ハッシュ ダイジェスト タイプに対する制限を意味するものではないことに注意してください。矛盾が見つからない場合、親は希望するダイジェスト タイプで DS レコードを公開できます。
This section provides recommendations to address the following operational question:
このセクションでは、次の運用上の問題に対処するための推奨事項を示します。
* Should a failed (or even successful) DS update trigger a notification to anyone?
* DS アップデートが失敗した (または成功した) 場合、誰かに通知を送信する必要がありますか?
1. For certain DS updates (see analysis (Section 5.2)) and for DS deactivation, relevant points of contact known to the parent-side entity (registry or registrar) SHOULD be notified.
1. 特定の DS 更新 (分析 (セクション 5.2) を参照) および DS の非アクティブ化については、親側エンティティ (レジストリまたはレジストラ) に知られている関連連絡先に通知する必要があります(SHOULD)。
2. For error conditions, the child DNS operator and the domain's technical contact (if applicable) SHOULD be notified first. The registrant SHOULD NOT be notified unless the problem persists for a prolonged amount of time (e.g., three days).
2. エラー状態については、子 DNS オペレーターとドメインの技術担当者 (該当する場合) に最初に通知する必要があります (SHOULD)。問題が長期間(たとえば、3日間)継続しない限り、登録者に通知すべきではありません。
3. Child DNS operators SHOULD be notified of errors using a report query [RFC9567] to the agent domain as described in Section 4 of [RFC9859]. Note that this requires listening to notifications and that appropriate notification targets are in place (Section 3 of [RFC9859]).
3. [RFC9859] のセクション 4 で説明されているように、子 DNS オペレータはエージェント ドメインへのレポート クエリ [RFC9567] を使用してエラーを通知されるべきです (SHOULD)。これには通知をリッスンする必要があり、適切な通知ターゲットが設定されていることが必要であることに注意してください ([RFC9859] のセクション 3)。
Notifications to humans (domain holder) will be performed in accordance with the communication preferences established with the parent-side entity. The same condition SHOULD NOT be reported unnecessarily frequently to the same recipient.
人間（ドメイン所有者）への通知は、親側エンティティとの間で設定された通信設定に従って行われます。同じ状況を同じ受信者に不必要に頻繁に報告すべきではありません。
4. In the RRR model, registries performing DS automation SHOULD inform the registrar of any DS record changes via the EPP Change Poll Extension [RFC8590] or a similar channel.
4. RRR モデルでは、DS 自動化を実行するレジストリは、DS レコードの変更を EPP Change Poll Extension [RFC8590] または同様のチャネル経由でレジストラに通知する必要があります (SHOULD)。
5. The currently active DS configuration SHOULD be made accessible to the registrant (or their designated party) through the customer portal available for domain management. The DS update history MAY be made available in the same way.
5. 現在アクティブな DS 設定は、ドメイン管理に利用できるカスタマー ポータルを通じて登録者 (またはその指定当事者) がアクセスできるようにすべきです (SHOULD)。DS の更新履歴も同様の方法で利用できるようにしてもよい (MAY)。
When accepting or rejecting a DS update, it cannot be assumed that relevant parties are aware of what's happening. For example, a registrar may not know when an automatic DS update is performed by the registry. Similarly, a Child DNS operator may not be aware when their CDS/CDNSKEY RRsets are out of sync across nameservers, causing them to be ignored.
DS アップデートを承認または拒否する場合、関係者が何が起こっているかを認識しているとは考えられません。たとえば、レジストラは、レジストリによって自動 DS 更新がいつ実行されるかを知らない場合があります。同様に、子 DNS オペレータは、CDS/CDNSKEY RRset がネームサーバー間で同期していない場合に気づかない可能性があり、その結果無視されることがあります。
To help involved parties act appropriately and in a timely manner, entities performing automated DS maintenance should report on conditions they encounter. The following success situations may be of particular interest:
関係者が適切かつタイムリーに行動できるよう、自動 DS 保守を実行する事業体は、遭遇した状況を報告する必要があります。次の成功状況は特に興味深いかもしれません。
1. A DS RRset has been provisioned:
1. DS RRset がプロビジョニングされました。
a. manually;
a. 手動で;
b. due to commencing DS automation (either via DNSSEC bootstrapping or for the first time after a manual change; see Section 7);
b. DS 自動化の開始によるもの (DNSSEC ブートストラップ経由、または手動変更後の初回のいずれか。セクション 7 を参照)。
c. automatically, as an update to an existing DS RRset that had itself been automatically provisioned.
c. これは、それ自体が自動的にプロビジョニングされた既存の DS RRset への更新として自動的に行われます。
2. The DS RRset has been removed:
2. DS RRset は削除されました。
a. manually;
a. 手動で;
b. automatically, using a delete signal ([RFC8078], Section 4).
b. 削除シグナルを使用して自動的に削除されます ([RFC8078]、セクション 4)。
In addition, there are error conditions worthy of being reported:
さらに、報告する価値のあるエラー状態があります。
3. A pending DS update cannot be applied due to an error condition. There are various scenarios where an automated DS update might have been requested but can't be fulfilled. These include:
3. エラー状態のため、保留中の DS 更新を適用できません。自動 DS アップデートがリクエストされても実行できないさまざまなシナリオが考えられます。これらには次のものが含まれます。
a. The new DS record set would break validation/resolution or is not acceptable to the Parent for some other reason (see Section 4).
a. 新しい DS レコード セットは検証/解決に失敗するか、その他の理由で親に受け入れられません (セクション 4 を参照)。
b. A lock prevents DS automation (see Section 6).
b. ロックは DS の自動化を妨げます (セクション 6 を参照)。
4. No DS update is due, but it was determined that the Child zone is no longer compatible with the existing DS record set (e.g., DS RRset only references non-existing keys).
4. DS 更新の予定はありませんが、子ゾーンは既存の DS レコード セットと互換性がなくなったと判断されました (たとえば、DS RRset は存在しないキーのみを参照します)。
In these latter two cases, the entity performing DS automation would be justified to attempt communicating the situation. Potential recipients are:
後者の 2 つのケースでは、DS 自動化を実行するエンティティが状況の伝達を試みることが正当化されます。潜在的な受信者は次のとおりです。
* Child DNS operator, preferably by making a report query [RFC9567] to the agent domain listed in the EDNS0 Report-Channel option of the DS update notification that triggered the DS update ([RFC9859], Section 4) or else via email to the address contained in the Child zone's SOA RNAME field (see Sections 3.3.13 and 8 of [RFC1035]);
* 子 DNS オペレーター。できれば、DS 更新をトリガーした DS 更新通知の EDNS0 レポートチャネル オプションにリストされているエージェント ドメインに対してレポート クエリ [RFC9567] を実行する ([RFC9859]、セクション 4)、または子ゾーンの SOA RNAME フィールドに含まれるアドレスに電子メールで送信する ([RFC1035] のセクション 3.3.13 および 8 を参照)。
* Registrar (if DS automation is performed by the registry);
* レジストラ (DS 自動化がレジストリによって実行される場合)。
* Registrant (domain holder; in non-technical language, such as "DNSSEC security for your domain has been enabled and will be maintained automatically"), or technical contact, in accordance with the communication preferences established with the parent-side entity.
* 親側エンティティと確立された通信設定に従って、登録者 (ドメイン所有者。「ドメインの DNSSEC セキュリティが有効になり、自動的に維持されます」などの非技術的な表現)、または技術担当者。
For manual updates (case 1a), commencing DS automation (case 1b), and deactivating DNSSEC (case 2), it seems worthwhile to notify both the domain's technical contact (if applicable) and the registrant. This will typically lead to one notification during normal operation of a domain. (Case 1c, the regular operation of automation, is not an interesting condition to report to a human.)
手動更新 (ケース 1a)、DS 自動化の開始 (ケース 1b)、および DNSSEC の非アクティブ化 (ケース 2) については、ドメインの技術担当者 (該当する場合) と登録者の両方に通知する価値があると思われます。これにより、通常、ドメインの通常の操作中に 1 つの通知が送信されます。(ケース 1c、自動化の定期的な動作は、人間に報告するには興味深い状態ではありません。)
For error conditions (cases 3 and 4), the registrant need not always be involved. It seems advisable to first notify the domain's technical contact and the DNS operator serving the affected Child zone, and only if the problem persists for a prolonged amount of time (e.g., three days), notify the registrant.
エラー状態 (ケース 3 および 4) の場合、登録者が常に関与する必要はありません。まず、ドメインの技術担当者と、影響を受ける子ゾーンを担当する DNS オペレーターに通知し、問題が長期間 (たとえば、3 日間) 継続する場合にのみ、登録者に通知することをお勧めします。
When the RRR model is used and the registry performs DS automation, the registrar should always stay informed of any DS record changes, e.g., via the EPP Change Poll Extension [RFC8590].
RRR モデルが使用され、レジストリが DS 自動化を実行する場合、レジストラは、たとえば EPP Change Poll Extension [RFC8590] などを介して、DS レコードの変更を常に通知し続ける必要があります。
Overly frequent reporting of the same condition to the same recipient is discouraged (e.g., no more than twice in a row). For example, when CDS and CDNSKEY records are inconsistent and prevent DS initialization, the registrant may be notified twice. Additional notifications may be sent with some back-off mechanism (in increasing intervals).
同じ受信者に同じ状態を過度に頻繁に報告することは推奨されません (例: 連続 2 回まで)。たとえば、CDS レコードと CDNSKEY レコードに一貫性がなく、DS の初期化が妨げられる場合、登録者に 2 回通知される可能性があります。追加の通知は、何らかのバックオフ メカニズムを使用して (間隔を増やして) 送信される場合があります。
The registrant (or their designated party) should be able to retrieve the current DS configuration through the customer portal available for domain management. Failure to provide the registrant a means to inspect the current configuration after it has been changed may hinder recovery from operational incidents because the registrant may have out-of-date information.
登録者 (または登録者が指定した当事者) は、ドメイン管理に利用できるカスタマー ポータルを通じて現在の DS 構成を取得できる必要があります。変更後の現在の構成を検査する手段を登録者に提供しないと、登録者が古い情報を持っている可能性があるため、運用上のインシデントからの回復が妨げられる可能性があります。
Ideally, the history of DS updates would also be available. However, due to the associated state requirements and the lack of direct operational impact, implementation of this is optional. If supported by the registry, the DS TTL currently in effect can be obtained using the RDAP TTL extension [RDAP-TTL].
理想的には、DS のアップデート履歴も利用できるようになります。ただし、関連する州の要件と運用上の直接的な影響がないため、これの実装はオプションです。レジストリでサポートされている場合、現在有効な DS TTL は、RDAP TTL 拡張 [RDAP-TTL] を使用して取得できます。
For troubleshooting, dispute resolution, and post-incident analysis, it is instrumental for the Parental Agent to retain structured records of each DS automation decision, including timestamp, triggering CDS/CDNSKEY RRsets, notification channel, authoritative nameservers consulted, verification results, decision outcome, and the applied DS RRset or cancellation reason.
トラブルシューティング、紛争解決、インシデント後の分析では、タイムスタンプ、CDS/CDNSKEY RRset のトリガー、通知チャネル、参照された権威ネームサーバー、検証結果、決定結果、適用された DS RRset またはキャンセルの理由など、DS 自動化の各決定の構造化された記録をペアレンタル エージェントが保持することが役立ちます。
This section provides recommendations to address the following operational question:
このセクションでは、次の運用上の問題に対処するための推奨事項を示します。
* How does DS automation interact with other registration state parameters, such as registration locks?
* DS オートメーションは、登録ロックなどの他の登録状態パラメーターとどのように対話しますか?
1. To secure ongoing operations, automated DS maintenance MUST NOT be suspended based on a registrar update lock alone (such as EPP status clientUpdateProhibited [RFC5731]).
1. 進行中の操作を保護するために、自動 DS メンテナンスをレジストラ更新ロック (EPP ステータス clientUpdateProhibited [RFC5731] など) のみに基づいて一時停止してはなりません (MUST NOT)。
2. When performed by the registry, automated DS maintenance MUST NOT be suspended based on a registry update lock alone (such as EPP status serverUpdateProhibited [RFC5731]).
2. レジストリによって実行される場合、自動 DS メンテナンスは、レジストリ更新ロック (EPP ステータスの serverUpdateProhibited [RFC5731] など) のみに基づいて一時停止してはなりません (MUST NOT)。
Registries and registrars can set various types of locks for domain registrations, usually upon the registrant's request. An overview of standardized locks using EPP, for example, is given in Section 2.3 of [RFC5731]. Some registries may offer additional (or other) types of locks whose meaning and set/unset mechanisms are defined according to a proprietary policy.
レジストリとレジストラは、通常は登録者の要求に応じて、ドメイン登録に対してさまざまなタイプのロックを設定できます。たとえば、EPP を使用した標準化されたロックの概要は、[RFC5731] のセクション 2.3 に記載されています。一部のレジストリでは、その意味および設定/設定解除メカニズムが独自のポリシーに従って定義されている追加 (または他の) タイプのロックを提供する場合があります。
While some locks clearly should have no impact on DS automation (such as transfer or deletion locks), other types of locks, in particular "update locks", deserve a closer analysis.
一部のロック (転送ロックや削除ロックなど) は明らかに DS の自動化に影響を与えませんが、他の種類のロック、特に「更新ロック」については詳細な分析が必要です。
A registrar-side update lock (such as clientUpdateProhibited in EPP) protects against various types of accidental or malicious change (like unintended changes through the registrar's customer portal). Its security model does not prevent the registrar's (nor the registry's) actions. This is because a registrar-side lock can be removed by the registrar without an out-of-band interaction.
レジストラ側の更新ロック (EPP の clientUpdateProhibited など) は、さまざまなタイプの偶発的または悪意のある変更 (レジストラのカスタマー ポータルを介した意図しない変更など) から保護します。そのセキュリティ モデルは、レジストラ (またはレジストリ) のアクションを妨げません。これは、レジストラ側のロックは、帯域外の対話を行わずにレジストラによって削除できるためです。
Under such a security model, no tangible security benefit is gained by preventing automated DS maintenance based on a registrar lock alone, while preventing it would make maintenance needlessly difficult. It is therefore not justified to suspend automation when such a lock is present.
このようなセキュリティ モデルでは、レジストラ ロックのみに基づいて自動 DS メンテナンスを防止しても、目に見えるセキュリティ上の利点は得られません。また、防止するとメンテナンスが不必要に困難になります。したがって、そのようなロックが存在する場合に自動化を一時停止することは正当化されません。
When a registry-side update lock is in place, the registrar cannot apply any changes (for security or delinquency or other reasons). However, it does not protect against changes made by the registry itself. This is exemplified by the serverUpdateProhibited EPP status, which demands only that the registrar's "[r]equests to update the object [...] MUST be rejected" (Section 2.3 of [RFC5731]). This type of lock therefore precludes DS automation by the registrar, while registry-side automation remains unaffected.
レジストリ側の更新ロックが設定されている場合、レジストラは (セキュリティ、滞納、またはその他の理由により) 変更を適用できません。ただし、レジストリ自体による変更を防ぐことはできません。これは、レジストラの「オブジェクトの更新要求は [...] 拒否されなければならない」 ([RFC5731] のセクション 2.3) だけを要求する、serverUpdateProhibited EPP ステータスによって例示されます。したがって、このタイプのロックはレジストラによる DS 自動化を妨げますが、レジストリ側の自動化は影響を受けません。
DS automation by the registry is consistent with Section 2.3 of [RFC5731], which explicitly notes that an EPP server (registry) may override status values set by an EPP client (registrar), subject to local server policies. The risk that DS changes from registry-side DS automation might go unnoticed by the registrar is mitigated by sending change notifications to the registrar; see Recommendation 4 of Section 5.
レジストリによる DS 自動化は、[RFC5731] のセクション 2.3 と一致しています。このセクションでは、EPP サーバー (レジストリ) は、ローカル サーバー ポリシーに従って、EPP クライアント (レジストラ) によって設定されたステータス値をオーバーライドできることが明示的に記載されています。レジストリ側の DS 自動化による DS の変更がレジストラに気づかれないリスクは、レジストラに変更通知を送信することで軽減されます。セクション 5 の推奨事項 4 を参照してください。
Pre-DNSSEC, it was possible for a registration to be set up once, then locked and left alone (no maintenance required). With DNSSEC comes a change to this operational model: The configuration may have to be maintained in order to remain secure and operational. For example, the Child DNS operator may switch to another signing algorithm if the previous one is no longer deemed appropriate or roll its Secure Entry Point (SEP) key for other reasons. Such changes entail updating the delegation's DS records.
DNSSEC 以前は、登録を一度セットアップし、その後ロックして放置することが可能でした (メンテナンスは必要ありません)。DNSSEC では、この運用モデルに変更が加えられています。安全性と運用性を維持するには、構成を維持する必要がある場合があります。たとえば、子 DNS オペレータは、前の署名アルゴリズムが適切でなくなった場合に別の署名アルゴリズムに切り替えたり、他の理由でセキュア エントリ ポイント (SEP) キーをロールしたりすることがあります。このような変更には、委任の DS レコードの更新が必要になります。
If authenticated, these operations do not qualify as accidental or malicious changes but as legitimate and normal activity for securing ongoing operation. The CDS/CDNSKEY method provides an automatic, authenticated means to convey DS bootstrapping and update requests [RFC9615] [RFC7344]. The resulting operation is subject to the parent's acceptance checks; in particular, it is not applied when it would break the delegation (see Section 4).
認証された場合、これらの操作は偶発的または悪意のある変更とはみなされず、進行中の操作を保護するための正当な通常のアクティビティとして認められます。CDS/CDNSKEY メソッドは、DS ブートストラップおよび更新リクエストを伝達するための自動認証された手段を提供します [RFC9615] [RFC7344]。結果の操作は、親の受け入れチェックの対象になります。特に、委任を破棄する場合には適用されません (セクション 4 を参照)。
Given that registrar locks protect against unintended changes (such as through the customer portal) while not preventing actions done by the registrar (or the registry) itself, such a lock is not suitable for defending against actions performed illegitimately by the registrar or registry (e.g., due to compromise). Any attack on the registration data that is feasible in the presence of a registrar lock is also feasible regardless of whether DS maintenance is done automatically; in other words, DS automation is orthogonal to the attack vector that a registrar lock protects against.
レジストラ ロックは、レジストラ (またはレジストリ) 自体によって行われるアクションは妨げないものの、意図しない変更 (カスタマー ポータルなどによる) を防ぐことを考えると、そのようなロックは、レジストラまたはレジストリによって (セキュリティ侵害などにより) 不正に実行されるアクションを防御するのには適していません。レジストラ ロックが存在する場合に実行可能な登録データに対する攻撃は、DS メンテナンスが自動的に行われるかどうかに関係なく実行可能です。言い換えれば、DS オートメーションは、レジストラ ロックが保護する攻撃ベクトルとは直交しています。
Considering that automated DS bootstrapping and update requests are required to be authenticated and validated for correctness, honoring such requests -- while in the registrant's interest -- comes with no additional associated risk when compared to other authenticated update methods. Suspending automated DS maintenance therefore is not justified.
自動化された DS ブートストラップおよび更新リクエストは認証され、その正確性が検証される必要があることを考慮すると、そのようなリクエストを受け入れることは、登録者の利益につながる一方で、他の認証された更新方法と比較した場合、追加の関連リスクは伴いません。したがって、DS の自動メンテナンスを一時停止することは正当化されません。
Following this line of thought, at the time of document writing, some registries (e.g., .ch/.cz/.li) perform automated DS maintenance even when an "update lock" is in place. Registries offering proprietary locks should carefully consider for each lock whether its scope warrants suspension.
この考え方に従うと、ドキュメントの作成時に、一部のレジストリ (.ch/.cz/.li など) は、「更新ロック」が設定されている場合でも自動 DS メンテナンスを実行します。独自のロックを提供するレジストリは、ロックごとに、その範囲が一時停止に値するかどうかを慎重に検討する必要があります。
In case of a domain not yet secured with DNSSEC, automatic DS initialization is not required to maintain ongoing operation; however, authenticated DNSSEC bootstrapping [RFC9615] might be requested. Besides being in the interest of security, the fact that a Child is requesting DS initialization through an authenticated method expresses the registrant's intent to have the delegation secured.
DNSSEC でまだ保護されていないドメインの場合、継続的な運用を維持するために自動 DS 初期化は必要ありません。ただし、認証された DNSSEC ブートストラップ [RFC9615] が要求される場合があります。セキュリティ上の理由に加えて、チャイルドが認証された方法を通じて DS の初期化を要求しているという事実は、委任を保護したいという登録者の意図を表しています。
Further, some domains are equipped with an update lock by default. Not honoring DNSSEC bootstrapping requests then imposes an additional burden on the registrant, who has to unlock and relock the domain in order to facilitate DS provisioning after registration. This is a needless cost especially for large domain portfolios. It is also unexpected, as the registrant already has arranged for the necessary CDS/CDNSKEY records to be published. DS initialization and rollovers therefore should be treated the same way with respect to locks.
さらに、一部のドメインにはデフォルトで更新ロックが装備されています。DNSSEC ブートストラップ リクエストを受け付けないと、登録者に追加の負担がかかり、登録後に DS プロビジョニングを容易にするためにドメインのロックを解除して再ロックする必要があります。これは、特に大規模なドメイン ポートフォリオの場合、不必要なコストとなります。また、登録者は必要な CDS/CDNSKEY レコードの公開をすでに手配しているため、これは予期せぬことでもあります。したがって、DS の初期化とロールオーバーは、ロックに関して同じように扱う必要があります。
This section provides recommendations to address the following operational questions:
このセクションでは、次の運用上の問題に対処するための推奨事項を示します。
* How are conflicts resolved when DS parameters are accepted through multiple channels (e.g., via a conventional channel and via automation)?
* DS パラメータが複数のチャネル (従来のチャネルや自動化など) を通じて受け入れられる場合、競合はどのように解決されますか?
* In case both the registry and the registrar are automating DS provisioning, how are potential collisions resolved?
* レジストリとレジストラの両方が DS プロビジョニングを自動化している場合、潜在的な衝突はどのように解決されますか?
1. Registries and registrars MUST provide another (e.g., manual) channel for DS maintenance in order to enable recovery when the Child has lost access to its signing key(s). This out-of-band channel is also needed when a DNS operator does not support DS automation or refuses to cooperate.
1. レジストリとレジストラは、チャイルドが署名キーへのアクセスを失った場合に回復できるように、DS メンテナンス用の別の (例: 手動) チャネルを提供しなければなりません (MUST)。この帯域外チャネルは、DNS オペレータが DS 自動化をサポートしていない場合、または協力を拒否した場合にも必要になります。
2. DS bootstrapping and update requests MUST be executed at the next publication opportunity after verification of their authenticity, regardless of whether they are received in-band or via an out-of-band channel.
2. DS ブートストラップおよび更新リクエストは、帯域内で受信されたか帯域外チャネル経由で受信されたかに関係なく、その真正性が検証された後、次の公開の機会に実行されなければなりません (MUST)。
3. When processing a CDS/CDNSKEY "delete" signal to remove the entire DS record set ([RFC8078], Section 4), DS automation MUST NOT be suspended. For all other removal requests (such as when received via EPP or a web form), DS automation SHOULD be suspended until a new DS record set has been provisioned, in order to prevent accidental re-initialization when the registrant intended to disable DNSSEC.
3. When processing a CDS/CDNSKEY "delete" signal to remove the entire DS record set ([RFC8078], Section 4), DS automation MUST NOT be suspended.他のすべての削除リクエスト (EPP または Web フォーム経由で受信した場合など) については、登録者が DNSSEC を無効にするつもりだったときに誤って再初期化されるのを防ぐために、新しい DS レコード セットがプロビジョニングされるまで DS 自動化を一時停止する必要があります (SHOULD)。
4. Whenever a non-empty DS record set is provisioned, through whichever channel, DS automation SHOULD NOT (or no longer) be suspended (including after an earlier removal).
4. 空ではない DS レコード セットがプロビジョニングされるときは、どのチャネルを通じてでも、DS 自動化を一時停止してはなりません (以前の削除後も含めて)。
5. In the RRR model, a registry MUST NOT automatically initialize DS records when it is known that the registrar does not provide a way for the domain holder to later disable DNSSEC. If the registrar has declared that it performs automated DS maintenance, the registry SHOULD publish the registrar's notification endpoint [RFC9859] (if applicable) instead of their own and refrain from registry-side DS automation.
5. RRR モデルでは、ドメイン所有者が後で DNSSEC を無効にする方法をレジストラが提供しないことがわかっている場合、レジストリは DS レコードを自動的に初期化してはなりません (MUST NOT)。レジストラが自動 DS メンテナンスを実行すると宣言した場合、レジストリは独自の通知エンドポイント [RFC9859] (該当する場合) を公開し、レジストリ側の DS 自動化を控えるべきです(SHOULD)。
In the RRR model, there are multiple channels through which DS parameters can be accepted:
RRR モデルには、DS パラメーターを受け入れることができる複数のチャネルがあります。
* The registry can retrieve information about an intended DS provisioning request automatically from the Child DNS operator and apply the it directly;
* レジストリは、対象の DS プロビジョニング リクエストに関する情報を子 DNS オペレーターから自動的に取得し、それを直接適用できます。
* The registrar can retrieve the same and relay it to the registry;
* レジストラは同じものを取得してレジストリに中継できます。
* The registrar can obtain the information from the registrant through another channel (such as a non-automated "manual update" via web form submission) and relay it to the registry.
* レジストラは、別のチャネル (Web フォーム送信による非自動の「手動更新」など) を通じて登録者から情報を取得し、それをレジストリに中継できます。
There are several considerations in this context, as discussed in the following subsections.
以下のサブセクションで説明するように、これに関連していくつかの考慮事項があります。
Under special circumstances, it may be necessary to perform a non-automatic DS update. One important example is when the key used for authentication of DS updates is destroyed: In this case, an automatic key rollover is impossible as the Child DNS operator can no longer authenticate the associated information. Another example is when several providers are involved, but one no longer cooperates (e.g., when removing a provider from a multi-provider setup). Disabling all other DS management interfaces therefore poses significant operational risk.
特殊な状況では、非自動の DS アップデートを実行する必要がある場合があります。重要な例の 1 つは、DS 更新の認証に使用されるキーが破壊された場合です。この場合、子 DNS オペレーターは関連情報を認証できなくなるため、自動キー ロールオーバーは不可能になります。別の例は、複数のプロバイダーが関与しているが、1 つのプロバイダーが連携しなくなった場合です (マルチプロバイダー設定からプロバイダーを削除する場合など)。したがって、他のすべての DS 管理インターフェイスを無効にすると、重大な運用上のリスクが生じます。
Similarly, when the registrar is known to not support DNSSEC (especially to not provide a means to remove a DS RRset), registries are cautioned against automatically initializing DS records, in order to prevent situations in which a misconfigured or undesired DS RRset cannot be repaired by the registrant.
同様に、レジストラが DNSSEC をサポートしていないことがわかっている場合 (特に DS RRset を削除する手段を提供していない場合)、構成が間違っていたり、望ましくない DS RRset を登録者が修復できない状況を防ぐために、レジストリは DS レコードを自動的に初期化しないよう警告されます。
When an out-of-band (e.g., manual) DS update is performed while CDS/ CDNSKEY records referencing the previous DS RRset's keys are present, the delegation's DS records may be reset to their previous state at the next run of the automation process. This section discusses in which situations it is appropriate to suspend DS automation after such a non-automatic update.
以前の DS RRset のキーを参照する CDS/CDNSKEY レコードが存在する間にアウトオブバンド (手動など) DS 更新が実行されると、次回の自動化プロセスの実行時に、委任の DS レコードが以前の状態にリセットされる可能性があります。このセクションでは、このような非自動更新の後に DS 自動化を一時停止するのが適切な状況について説明します。
One option is to suspend DS automation after a manual DS update but only until a resumption signal is observed. In the past, it was proposed that seeing an updated SOA serial in the Child zone may serve as a resumption signal. However, as any arbitrary modification of zone contents -- including the regular updating of DNSSEC signature validity timestamps -- typically causes an SOA serial change, resumption of DS automation after a serial change comes with a high risk of surprise. Additional issues arise if nameservers have different serial offsets (e.g., in a multi-provider setup). This practice therefore is NOT RECOMMENDED.
1 つのオプションは、DS を手動で更新した後、再開の信号が観測されるまで DS 自動化を一時停止することです。過去には、Child ゾーンで更新された SOA シリアルを確認することが再開信号として機能する可能性があると提案されました。ただし、DNSSEC 署名の有効性タイムスタンプの定期的な更新を含む、ゾーンの内容の任意の変更は通常、SOA シリアル変更を引き起こすため、シリアル変更後の DS 自動化の再開には予期せぬ危険が伴います。ネームサーバーのシリアル オフセットが異なる場合 (マルチプロバイダー設定など)、追加の問題が発生します。したがって、この方法は推奨されません。
Note also that "automatic rollback" due to old CDS/CDNSKEY RRsets can only occur if they are signed with a key authorized by one of the new DS records. Acceptance checks described in Section 4 further ensure that updates do not break validation.
古い CDS/CDNSKEY RRset による「自動ロールバック」は、新しい DS レコードの 1 つによって承認されたキーで署名されている場合にのみ発生することにも注意してください。セクション 4 で説明されている受け入れチェックにより、更新が検証を中断しないことがさらに保証されます。
Removal of a DS record set is triggered either through a CDS/CDNSKEY "delete" signal observed by the party performing the automation ([RFC8078], Section 4) or by receiving a removal request out-of-band (e.g., via EPP or a web form). In the first case, the registrant can expect automation to be kept active for the delegation to facilitate later DS bootstrapping. In the second case, it is likely that the registrant intends to disable DNSSEC for the domain, and DS automation is best suspended (until a new DS record is provisioned somehow).
DS レコードセットの削除は、自動化を実行する当事者によって観測される CDS/CDNSKEY「削除」信号 ([RFC8078]、セクション 4) を通じて、または帯域外で削除リクエストを受信することによって (例: EPP または Web フォーム経由で) トリガーされます。最初のケースでは、登録者は、後の DS ブートストラップを容易にするために、委任に対して自動化がアクティブに維持されることを期待できます。2 番目のケースでは、登録者がドメインの DNSSEC を無効にするつもりである可能性が高く、DS 自動化は (何らかの方法で新しい DS レコードがプロビジョニングされるまで) 一時停止するのが最適です。
One may ask how a registry can know whether a removal request received via EPP was the result of the registrar observing a CDS/ CDNSKEY "delete" signal. It turns out that the registry does not need to know that; in fact, the advice works out nicely regardless of who does the automation:
EPP 経由で受信した削除要求が、レジストラが CDS/CDNSKEY の「削除」信号を監視した結果であるかどうかをレジストリがどのようにして知ることができるのか疑問に思う人もいるかもしれません。レジストリはそれを知る必要がないことがわかりました。実際、誰が自動化を行うかに関係なく、このアドバイスはうまく機能します。
a. Only registry: If the registry performs automation, then the registry will consider any request received from the registrar as out-of-band (in the context of this automation). When such requests demand removal of the entire DS record set, the registry therefore should suspend automation.
a. レジストリのみ: レジストリが自動化を実行する場合、レジストリは、(この自動化のコンテキストにおいて) レジストラから受信したリクエストを帯域外とみなします。したがって、そのようなリクエストで DS レコード セット全体の削除が要求される場合、レジストリは自動化を一時停止する必要があります。
b. Only registrar: The registrar can always distinguish between removal requests obtained from a CDS/CDNSKEY "delete" signal and other registrant requests and suspend automation as appropriate.
b. レジストラのみ: レジストラは、CDS/CDNSKEY の「削除」信号から取得した削除リクエストと他の登録者のリクエストを常に区別し、必要に応じて自動化を一時停止できます。
c. In the (undesirable) case that both parties automate, there are two cases:
c. 双方が自動化する（望ましくない）ケースには、次の 2 つのケースがあります。
* If the registrant submits a manual removal request to the registrar, it is out-of-band from the registrar perspective (e.g., web form) and also for the registry (e.g., EPP). As a consequence, both will suspend automation (which is the correct result).
* 登録者が手動の削除リクエストをレジストラに送信した場合、それはレジストラの観点 (Web フォームなど) からはアウトオブバンドであり、レジストリ (EPP など) にとってもアウトオブバンドです。結果として、両方とも自動化を一時停止します (これは正しい結果です)。
* If a CDS/CDNSKEY "delete" signal causes the registrar to request DS removal from the registry, then the registry will suspend automation (because the removal request is received out-of-band, such as via EPP). This is independent of whether the registry's automation has already seen the signal. The registrar, however, will be aware of the in-band nature of the request and not suspend automation (which is also the correct result).
* CDS/CDNSKEY の「削除」信号によってレジストラがレジストリからの DS の削除を要求すると、レジストリは自動化を一時停止します (削除要求は EPP 経由などの帯域外で受信されるため)。これは、レジストリの自動化がすでにシグナルを認識しているかどうかには関係ありません。ただし、レジストラはリクエストのインバンドの性質を認識しており、自動化を一時停止しません (これも正しい結果です)。
As a side effect, this works towards avoiding redundant automation at the registry.
副作用として、これはレジストリでの冗長な自動化を回避する方向に機能します。
All in all:
全体として：
* It is advisable to generally not suspend in-band DS automation when an out-of-band DS update has occurred.
* 通常、帯域外 DS 更新が発生したときに帯域内 DS 自動化を一時停止しないことをお勧めします。
* An exception to this rule is when the entire DS record set was removed through an out-of-band request, in which case the registrant likely wants to disable DNSSEC for the domain. DS automation should then be suspended so that automatic re-initialization (bootstrapping) does not occur.
* このルールの例外は、帯域外リクエストを通じて DS レコード セット全体が削除された場合です。この場合、登録者はドメインの DNSSEC を無効にすることを希望する可能性があります。その後、自動再初期化 (ブートストラップ) が発生しないように、DS オートメーションを一時停止する必要があります。
* In all other cases, any properly authenticated DS updates received, including through an automated method, are to be considered as the current intent of the domain holder.
* それ以外のすべての場合、受信した適切に認証された DS アップデート (自動化された方法を含む) は、ドメイン所有者の現在の意図とみなされます。
When the RRR model is used, there is a potential for collision if both the registry and the registrar are automating DS provisioning by scanning the child for CDS/CDNSKEY records. No disruptive consequences are expected if both parties perform DS automation. An exception is when, during a key rollover, the registry and registrar see different versions of the Child's DS update requests, such as when CDS/CDNSKEY records are retrieved from different vantage points. Although unlikely due to Recommendation 1a of Section 4, this may lead to flapping of DS updates. However, it is not expected to be harmful as either DS RRset will allow for the validation function to continue to work, as ensured by Recommendation 1b of Section 4. The effect subsides as the Child's state eventually becomes consistent (roughly within the child's replication delay); any flapping until then will be a minor nuisance only.
RRR モデルを使用する場合、レジストリとレジストラの両方が CDS/CDNSKEY レコードの子をスキャンすることによって DS プロビジョニングを自動化している場合、競合が発生する可能性があります。双方が DS 自動化を実行しても、破壊的な結果は予想されません。例外は、キー ロールオーバー中に、CDS/CDNSKEY レコードが別の有利なポイントから取得される場合など、レジストリとレジストラが子の DS 更新リクエストの異なるバージョンを認識する場合です。セクション 4 の推奨事項 1a により可能性は低いですが、これにより DS アップデートのフラッピングが発生する可能性があります。ただし、セクション 4 の推奨事項 1b で保証されているように、どちらの DS RRset でも検証機能が動作し続けることができるため、有害であるとは予想されません。子の状態が最終的に一貫性を持つようになると (およそ子のレプリケーション遅延内で)、影響は治まります。それまでの羽ばたきはほんの少し迷惑になるだけです。
The issue disappears entirely when scanning is replaced by notifications that trigger DS maintenance through one party's designated endpoint [RFC9859] and can otherwise be mitigated if the registry and registrar agree that only one of them will perform scanning.
この問題は、スキャンが、一方の指定されたエンドポイント [RFC9859] を介して DS メンテナンスをトリガーする通知に置き換えられると完全に解消されます。また、レジストリとレジストラがどちらか一方のみがスキャンを実行することに同意した場合は、軽減できます。
As a standard aspect of key rollovers [RFC6781], the Child DNS operator is expected to monitor propagation of Child zone updates to all authoritative nameserver instances and only proceed to the next step once replication has succeeded everywhere and the DS record set was subsequently updated (and in no case before the DS RRset's TTL has passed). Any breakage resulting from improper timing on the Child side is outside of the Parent's sphere of influence and thus cannot be handled with only parent-side changes.
キー ロールオーバー [RFC6781] の標準的な側面として、子 DNS オペレーターは、すべての権限のあるネームサーバー インスタンスへの子ゾーンの更新の伝播を監視し、レプリケーションがすべての場所で成功し、その後 DS レコード セットが更新された場合にのみ次のステップに進むことが期待されています (DS RRset の TTL が経過する前は決してそうではありません)。子側のタイミングミスによる破損は親の影響範囲外となるため、親側の変更だけでは対応できません。
This document has no IANA actions.
この文書には IANA のアクションはありません。
The document provides operational recommendations for DNSSEC DS automation. There are no additional operational considerations beyond those listed in Appendix A.
このドキュメントでは、DNSSEC DS 自動化の運用に関する推奨事項を提供します。付録 A に記載されているもの以外に、追加の運用上の考慮事項はありません。
The recommendations in this document are designed to improve the safety and interoperability of DNSSEC delegation maintenance. Relevant security implications and various trade-offs are explained in the analysis subsections above. This section notes additional aspects worth considering.
このドキュメントの推奨事項は、DNSSEC 委任メンテナンスの安全性と相互運用性を向上させることを目的としています。関連するセキュリティへの影響とさまざまなトレードオフについては、上記の分析サブセクションで説明します。このセクションでは、考慮に値する追加の側面について説明します。
When inconsistencies between CDS/CDNSKEY RRsets are ignored (contrary to Recommendation 4.1.1.a), a number of security risks result. For example, when a nameserver domain expires and is re-registered maliciously, the adversary may be able to initialize a DS RRset and subsequently redelegate the domain using CSYNC synchronization [RFC7477], resulting in a full hijack of the domain. For details, refer to Appendix A of [RFC9975].
CDS/CDNSKEY RRset 間の不一致が無視されると (推奨事項 4.1.1.a に反して)、多くのセキュリティ リスクが発生します。たとえば、ネームサーバー ドメインの有効期限が切れ、悪意を持って再登録された場合、攻撃者は DS RRset を初期化し、その後 CSYNC 同期 [RFC7477] を使用してドメインを再委任することができ、その結果、ドメインが完全にハイジャックされる可能性があります。詳細については、[RFC9975] の付録 A を参照してください。
Similar risks of total adversarial control exist when the child's SEP key is compromised, as this key can authorize DS update or removal requests if consistently published on all nameservers. This reinforces that loss of key control poses severe risks; utmost care must be taken when managing SEP keys.
子の SEP キーが侵害された場合にも、完全な敵対的制御の同様のリスクが存在します。これは、このキーがすべてのネームサーバーで一貫して公開されている場合、DS の更新または削除リクエストを承認できるためです。これは、鍵の制御が失われると重大なリスクが生じることを裏付けています。SEP キーを管理する場合は、細心の注意を払う必要があります。
When a domain is stripped of its DNSSEC protection by removing the DS RRset -- either manually or using an automatic delete signal (Recommendation 7.1.3) -- DNSSEC security guarantees and associated benefits are no longer in effect. For example, an email operator may enforce DNS-Based Authentication of Named Entities (DANE) [RFC7672] for domains previously observed to support it and, as a result, experience a service disruption in email delivery. Both child and parent DNS operators MUST take such service disruptions into account when considering removal of the DS RRset for their zone.
手動または自動削除シグナル (推奨事項 7.1.3) を使用して、DS RRset を削除してドメインから DNSSEC 保護が剥奪されると、DNSSEC のセキュリティ保証と関連する利点は無効になります。たとえば、電子メール オペレータは、DNS ベースの名前付きエンティティ認証 (DANE) [RFC7672] をサポートしていることが以前に観察されたドメインに対して強制し、その結果、電子メール配信のサービス中断が発生する可能性があります。子 DNS オペレーターと親 DNS オペレーターの両方は、ゾーンの DS RRset の削除を検討する際に、このようなサービスの中断を考慮する必要があります。
[DNSKEY-IANA]
IANA, "DNS Security Algorithm Numbers",
<https://www.iana.org/assignments/dns-sec-alg-numbers>.
[DS-IANA] IANA, "DNSSEC Delegation Signer (DS) Resource Record (RR)
Type Digest Algorithms",
<https://www.iana.org/assignments/ds-rr-types>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the
Extensible Provisioning Protocol (EPP)", RFC 8590,
DOI 10.17487/RFC8590, May 2019,
<https://www.rfc-editor.org/info/rfc8590>.
[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>.
[RFC9859] Stenstam, J., Thomassen, P., and J. Levine, "Generalized
DNS Notifications", RFC 9859, DOI 10.17487/RFC9859,
September 2025, <https://www.rfc-editor.org/info/rfc9859>.
[RFC9975] Thomassen, P., "Clarifications on CDS/CDNSKEY and CSYNC
Consistency", RFC 9975, DOI 10.17487/RFC9975, May 2026,
<https://www.rfc-editor.org/info/rfc9975>.
[LowTTL] Špaček, P., "DS and DNSKEY low TTL experiments", DNS OARC
41, 6 September 2023, <https://indico.dns-
oarc.net/event/47/contributions/1010/attachments/958/1811/
DS%20and%20DNSKEY%20TTL%20experiment.pdf>.
[RDAP-TTL] Brown, G., "RDAP Extension for DNS Time-To-Live (TTL
Values)", Work in Progress, Internet-Draft, draft-ietf-
regext-rdap-ttl-extension-12, 27 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-
rdap-ttl-extension-12>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009,
<https://www.rfc-editor.org/info/rfc5731>.
[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>.
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
DOI 10.17487/RFC6840, February 2013,
<https://www.rfc-editor.org/info/rfc6840>.
[RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS",
RFC 7477, DOI 10.17487/RFC7477, March 2015,
<https://www.rfc-editor.org/info/rfc7477>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015,
<https://www.rfc-editor.org/info/rfc7672>.
[RFC9803] Brown, G., "Extensible Provisioning Protocol (EPP) Mapping
for DNS Time-to-Live (TTL) Values", RFC 9803,
DOI 10.17487/RFC9803, June 2025,
<https://www.rfc-editor.org/info/rfc9803>.
[SAC126] ICANN Security and Stability Advisory Committee (SSAC),
"SAC126: DNSSEC Delegation Signer (DS) Record Automation",
12 August 2024, <https://itp.cdn.icann.org/en/files/
security-and-stability-advisory-committee-ssac-reports/
sac-126-16-08-2024-en.pdf>.
For ease of review and referencing, the recommendations from this document are reproduced here without further comment. For background and analysis, refer to Sections 4-7.
レビューと参照を容易にするために、この文書の推奨事項を、追加のコメントなしでここに再掲します。背景と分析については、セクション 4 ～ 7 を参照してください。
1. Entities performing automated DS maintenance MUST verify:
1. 自動 DS メンテナンスを実行するエンティティは、以下を確認する必要があります。
a. the unambiguous intent of each DS bootstrapping or update request as per [RFC9975], by checking its consistency both
a. [RFC9975] に従って、各 DS ブートストラップまたは更新リクエストの明確な意図を、両方の一貫性をチェックすることによって確認します。
* between any published CDS and CDNSKEY records and
* 公開された CDS レコードと CDNSKEY レコードの間、および
* across all authoritative nameservers in the delegation,
* 委任内のすべての権限のあるネームサーバーにわたって、
and
そして
b. that the resulting DS record set would allow continued DNSSEC validation if deployed
b. 導入された場合、結果として得られる DS レコード セットにより DNSSEC 検証を継続できること
and cancel the update if the verifications do not succeed.
検証が成功しなかった場合は、更新をキャンセルします。
2. Parent-side entities (such as registries) SHOULD allow for effective rollback by reducing a DS record set's TTL to a value between 5-15 minutes when a new set of records is published, and restore the previous (or, if unavailable, default) TTL value at a later occasion (but not before the previous DS RRset's TTL has expired).
2. 親側エンティティ (レジストリなど) は、新しいレコード セットが公開されるときに DS レコード セットの TTL を 5 ～ 15 分の値に減らすことで効果的なロールバックを可能にし、後で (ただし、以前の DS RRset の TTL の有効期限が切れる前に) 以前の (または、使用できない場合はデフォルトの) TTL 値を復元する必要があります。
Besides a prudent choice of TTL, prompt DS changes also require timely discovery of update requests. For recommended methods, see Section 4.2.2.
TTL を賢明に選択することに加えて、DS の変更を迅速に行うには、更新リクエストをタイムリーに検出することも必要です。推奨される方法については、セクション 4.2.2 を参照してください。
3. DNS operators MUST publish both CDNSKEY and CDS records (unless the parent's preference is known) and follow best practice for the choice of hash digest type [DS-IANA].
3. DNS オペレーターは、CDNSKEY レコードと CDS レコードの両方を公開し (親の設定が不明な場合を除く)、ハッシュ ダイジェスト タイプ [DS-IANA] の選択に関するベスト プラクティスに従わなければなりません (MUST)。
1. For certain DS updates (see analysis (Section 5.2)) and for DS deactivation, relevant points of contact known to the parent-side entity (registry or registrar) SHOULD be notified.
1. 特定の DS 更新 (分析 (セクション 5.2) を参照) および DS の非アクティブ化については、親側エンティティ (レジストリまたはレジストラ) に知られている関連連絡先に通知する必要があります(SHOULD)。
2. For error conditions, the child DNS operator and the domain's technical contact (if applicable) SHOULD be notified first. The registrant SHOULD NOT be notified unless the problem persists for a prolonged amount of time (e.g., three days).
2. エラー状態については、子 DNS オペレーターとドメインの技術担当者 (該当する場合) に最初に通知する必要があります (SHOULD)。問題が長期間(たとえば、3日間)継続しない限り、登録者に通知すべきではありません。
3. Child DNS operators SHOULD be notified of errors using a report query [RFC9567] to the agent domain as described in Section 4 of [RFC9859]. Note that this requires listening to notifications and that appropriate notification targets are in place (Section 3 of [RFC9859]).
3. [RFC9859] のセクション 4 で説明されているように、子 DNS オペレータはエージェント ドメインへのレポート クエリ [RFC9567] を使用してエラーを通知されるべきです (SHOULD)。これには通知をリッスンする必要があり、適切な通知ターゲットが設定されていることが必要であることに注意してください ([RFC9859] のセクション 3)。
Notifications to humans (domain holder) will be performed in accordance with the communication preferences established with the parent-side entity. The same condition SHOULD NOT be reported unnecessarily frequently to the same recipient.
人間（ドメイン所有者）への通知は、親側エンティティとの間で設定された通信設定に従って行われます。同じ状況を同じ受信者に不必要に頻繁に報告すべきではありません。
4. In the RRR model, registries performing DS automation SHOULD inform the registrar of any DS record changes via the EPP Change Poll Extension [RFC8590] or a similar channel.
4. RRR モデルでは、DS 自動化を実行するレジストリは、DS レコードの変更を EPP Change Poll Extension [RFC8590] または同様のチャネル経由でレジストラに通知する必要があります (SHOULD)。
5. The currently active DS configuration SHOULD be made accessible to the registrant (or their designated party) through the customer portal available for domain management. The DS update history MAY be made available in the same way.
5. 現在アクティブな DS 設定は、ドメイン管理に利用できるカスタマー ポータルを通じて登録者 (またはその指定当事者) がアクセスできるようにすべきです (SHOULD)。DS の更新履歴も同様の方法で利用できるようにしてもよい (MAY)。
1. To secure ongoing operations, automated DS maintenance MUST NOT be suspended based on a registrar update lock alone (such as EPP status clientUpdateProhibited [RFC5731]).
1. 進行中の操作を保護するために、自動 DS メンテナンスをレジストラ更新ロック (EPP ステータス clientUpdateProhibited [RFC5731] など) のみに基づいて一時停止してはなりません (MUST NOT)。
2. When performed by the registry, automated DS maintenance MUST NOT be suspended based on a registry update lock alone (such as EPP status serverUpdateProhibited [RFC5731]).
2. レジストリによって実行される場合、自動 DS メンテナンスは、レジストリ更新ロック (EPP ステータスの serverUpdateProhibited [RFC5731] など) のみに基づいて一時停止してはなりません (MUST NOT)。
1. Registries and registrars MUST provide another (e.g., manual) channel for DS maintenance in order to enable recovery when the Child has lost access to its signing key(s). This out-of-band channel is also needed when a DNS operator does not support DS automation or refuses to cooperate.
1. レジストリとレジストラは、チャイルドが署名キーへのアクセスを失った場合に回復できるように、DS メンテナンス用の別の (例: 手動) チャネルを提供しなければなりません (MUST)。この帯域外チャネルは、DNS オペレータが DS 自動化をサポートしていない場合、または協力を拒否した場合にも必要になります。
2. DS bootstrapping and update requests MUST be executed at the next publication opportunity after verification of their authenticity, regardless of whether they are received in-band or via an out-of-band channel.
2. DS ブートストラップおよび更新リクエストは、帯域内で受信されたか帯域外チャネル経由で受信されたかに関係なく、その真正性が検証された後、次の公開の機会に実行されなければなりません (MUST)。
3. When processing a CDS/CDNSKEY "delete" signal to remove the entire DS record set ([RFC8078], Section 4), DS automation MUST NOT be suspended. For all other removal requests (such as when received via EPP or a web form), DS automation SHOULD be suspended until a new DS record set has been provisioned, in order to prevent accidental re-initialization when the registrant intended to disable DNSSEC.
3. CDS/CDNSKEY の「削除」信号を処理して DS レコードセット全体を削除するとき ([RFC8078]、セクション 4)、DS 自動化を一時停止してはなりません (MUST NOT)。他のすべての削除リクエスト (EPP または Web フォーム経由で受信した場合など) については、登録者が DNSSEC を無効にするつもりだったときに誤って再初期化されるのを防ぐために、新しい DS レコード セットがプロビジョニングされるまで DS 自動化を一時停止する必要があります (SHOULD)。
4. Whenever a non-empty DS record set is provisioned, through whichever channel, DS automation SHOULD NOT (or no longer) be suspended (including after an earlier removal).
4. 空ではない DS レコード セットがプロビジョニングされるときは、どのチャネルを通じてでも、DS 自動化を一時停止してはなりません (以前の削除後も含めて)。
5. In the RRR model, a registry MUST NOT automatically initialize DS records when it is known that the registrar does not provide a way for the domain holder to later disable DNSSEC. If the registrar has declared that it performs automated DS maintenance, the registry SHOULD publish the registrar's notification endpoint [RFC9859] (if applicable) instead of their own and refrain from registry-side DS automation.
5. RRR モデルでは、ドメイン所有者が後で DNSSEC を無効にする方法をレジストラが提供しないことがわかっている場合、レジストリは DS レコードを自動的に初期化してはなりません (MUST NOT)。レジストラが自動 DS メンテナンスを実行すると宣言した場合、レジストリは独自の通知エンドポイント [RFC9859] (該当する場合) を公開し、レジストリ側の DS 自動化を控えるべきです(SHOULD)。
The authors would like to thank the members of ICANN's Security and Stability Advisory Committee (SSAC) who wrote the [SAC126] report on which this document is based.
著者らは、この文書の基礎となっている [SAC126] レポートを執筆した ICANN のセキュリティと安定性諮問委員会 (SSAC) のメンバーに感謝の意を表します。
Additional thanks are extended to the following individuals (in the order of their first contribution or review): Barbara Jantzen, Matt Pounsett, Matthijs Mekking, Ondřej Caletka, Oli Schacher, Kim Davies, Jim Reid, Q Misell, Scott Hollenbeck, Tamás Csillag, Philip Homburg, Shumon Huque (Document Shepherd), Libor Peltan, Josh Simpson, Johan Stenstam, Stefan Ubbink, Viktor Dukhovni, Hugo Salgado, Wes Hardaker, Mohamed Boucadair (responsible Area Director), Meir Goldman, Thomas Fossati, Peter van Dijk, Jiankang Yao, Donald Eastlake, James Gannon, Roman Danyliw, Andy Newton, Éric Vyncke, Mike Bishop, Mahesh Jethanandani, Deb Cooley, Charles Eckel, Christopher Inacio, and Ketan Talaulikar.
さらに次の方々に感謝の意を表します (最初の寄稿またはレビューの順に): Barbara Jantzen、Matt Pounsett、Matthijs Mekking、Ondřej Caletka、Oli Schacher、Kim Davies、Jim Reid、Q Misell、Scott Hollenbeck、Tamás Csillag、Philip Homburg、Shumon Huque (Document Shepherd)、Libor Peltan、Josh Simpson、ヨハン・ステンスタム、ステファン・ウビンク、ヴィクトル・ドゥホブニ、ウーゴ・サルガド、ウェス・ハーダカー、モハメド・ブーカデア（エリアディレクター担当）、メイア・ゴールドマン、トーマス・フォッサティ、ピーター・ファン・ダイク、ジャンカン・ヤオ、ドナルド・イーストレイク、ジェームズ・ギャノン、ローマン・ダニリュー、アンディ・ニュートン、エリック・ヴィンケ、マイク・ビショップ、マヘシュ・ジェサナンダニ、デブクーリー、チャールズ・エッケル、クリストファー・イナシオ、ケタン・タラウリカー。
Steve Sheng
Email: steve.sheng@gmail.com
Peter Thomassen
deSEC
Email: peter@desec.io