Internet Engineering Task Force (IETF) P. Thomassen
Request for Comments: 9975 SSE
Updates: 7344, 7477 May 2026
Category: Standards Track
ISSN: 2070-1721
Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, "Automating DNSSEC Delegation Trust Maintenance" (RFC 7344) provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters that the parent can ingest. Similarly, "Child-to-Parent Synchronization in DNS" (RFC 7477) specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g., Registries and Registrars) can query these records from the child and, after validation, use them to update the parent-side Resource Record Sets (RRsets) of the delegation.
DNS 委任のメンテナンスには、委任の親側の DS および NS レコード セットを時折変更する必要があります。DS レコードの場合、「DNSSEC 委任信頼メンテナンスの自動化」(RFC 7344) は、親が取り込むことができる将来の DS パラメーターを保持する CDS レコードや CDNSKEY レコードを子が公開できるようにすることで自動化を提供します。同様に、「DNS における子から親への同期」(RFC 7477) では、委任の NS (およびグルー) レコードの必要な更新を示す CSYNC レコードが指定されています。親側のエンティティ (レジストリやレジストラなど) は、子からこれらのレコードをクエリし、検証後にそれらを使用して委任の親側のリソース レコード セット (RRset) を更新できます。
This document specifies under which conditions the target states expressed via CDS/CDNSKEY and CSYNC records are considered "consistent". Parent-side entities accepting such records from the child have to ensure that update requests retrieved from different authoritative nameservers satisfy these consistency requirements before taking any action based on them.
この文書は、CDS/CDNSKEY および CSYNC レコードを介して表現されるターゲット状態が「一貫している」とみなされる条件を指定します。子からそのようなレコードを受け入れる親側エンティティは、異なる権限のあるネームサーバーから取得した更新リクエストがこれらの一貫性要件を満たしていることを確認してから、それらに基づいてアクションを実行する必要があります。
This document updates RFCs 7344 and 7477.
この文書は RFC 7344 および 7477 を更新します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9975.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9975 で入手できます。
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
1.1. Requirements Notation
1.2. Terminology
2. Updates to RFCs 7344 and 7477
3. Processing Requirements
3.1. CDS and CDNSKEY
3.2. CSYNC
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Failure Scenarios due to Inconsistencies
A.1. DS Breakage due to Replication Lag
A.2. Escalation of Lame Delegation Takeover
A.3. Multi-Provider (Permanent Multi-Signer)
A.3.1. DS Breakage
A.3.2. NS Breakage
A.4. Bogus Provider Change (Temporary Multi-Signer)
Acknowledgments
Author's Address
[RFC7344] automates DNS Security Extensions (DNSSEC) delegation trust maintenance by having the child publish CDS and/or CDNSKEY records that describe the prospective DS parameters. Similarly, [RFC7477] specifies CSYNC records indicating a desired update of the delegation's NS and associated glue records. Parent-side entities (e.g., Registries and Registrars) can use these records to update the corresponding records of the delegation.
[RFC7344] は、子に予想される DS パラメータを記述する CDS および/または CDNSKEY レコードを公開させることにより、DNS Security Extensions (DNSSEC) 委任信頼の維持を自動化します。同様に、[RFC7477] は、委任の NS および関連するグルーレコードの望ましい更新を示す CSYNC レコードを指定しています。親側のエンティティ (レジストリやレジストラなど) は、これらのレコードを使用して、委任の対応するレコードを更新できます。
For ingesting CSYNC records, Section 3.1 of [RFC7477] advocates that Parental Agents limit queries to a single authoritative nameserver (as done in normal resolution). [RFC7344] (on CDS/CDNSKEY) has a corresponding section (Section 6.1 of [RFC7344]) that contains no provision for how specifically queries for these records should be done.
CSYNC レコードの取り込みに関して、[RFC7477] のセクション 3.1 は、ペアレンタル エージェントが (通常の解決で行われるように) クエリを単一の権威ネームサーバーに制限することを提唱しています。[RFC7344] (CDS/CDNSKEY に関する) には、対応するセクション ([RFC7344] のセクション 6.1) があり、これらのレコードに対するクエリを具体的にどのように実行するかについての規定は含まれていません。
Retrieving records from just one authoritative server (e.g., by directing queries towards a trusted validating resolver) works well under ideal operating scenarios. However, problems may arise if CDS/CDNSKEY/CSYNC record sets are inconsistent across authoritative nameserver either because they are out of sync (e.g., during a Key Signing Key (KSK) rollover) or because they are not controlled by the same entity (e.g., in a multi-signer setup [RFC8901]).
1 つの権威サーバーからのみレコードを取得する (たとえば、信頼できる検証リゾルバーにクエリを送信するなど) ことは、理想的な運用シナリオではうまく機能します。ただし、CDS/CDNSKEY/CSYNC レコード セットが同期していないため (例: 鍵署名鍵 (KSK) ロールオーバー中)、またはそれらが同じエンティティによって制御されていないため (例: マルチ署名者設定 [RFC8901])、権威ネームサーバー間で一貫性がない場合、問題が発生する可能性があります。
In such cases, if CDS/CDNSKEY/CSYNC records are retrieved from one nameserver only ("naively", without a consistency check), each nameserver can unilaterally trigger an update of the delegation's DS or NS record set.
このような場合、CDS/CDNSKEY/CSYNC レコードが 1 つのネームサーバーのみから (一貫性チェックなしで「単純に」) 取得される場合、各ネームサーバーは委任の DS または NS レコード セットの更新を一方的にトリガーできます。
For example, a single provider in a multi-signer setup may (accidentally or maliciously) cause another provider's trust anchors and/or nameservers to be removed from the delegation. This can occur both when the multi-signer configuration is temporary (e.g., during a provider change) and when it is permanent (e.g., for redundancy). In any case, a single provider should not be in the position to remove any other provider's records from the delegation.
たとえば、複数署名者セットアップ内の単一のプロバイダーが (偶然または悪意を持って) 別のプロバイダーのトラスト アンカーやネームサーバーを委任から削除する可能性があります。これは、マルチ署名者の構成が一時的な場合 (プロバイダーの変更中など) と永続的な場合 (冗長性など) の両方で発生する可能性があります。いずれの場合も、単一のプロバイダーが他のプロバイダーの記録を委任から削除できる立場にあるべきではありません。
Similar breakage can occur when the delegation has lame nameservers, where an attacker may illegitimately initialize a DS record set and then manipulate the delegation's NS record set at will. More detailed examples are given in Appendix A.
同様の破損は、委任のネームサーバーが不十分な場合に発生する可能性があり、攻撃者が DS レコード セットを不正に初期化し、委任の NS レコード セットを自由に操作する可能性があります。より詳細な例は付録 A に記載されています。
For a CDS/CDNSKEY/CSYNC consumer, it is generally impossible to estimate the impact of a requested delegation update unless all of the child's authoritative nameservers are inspected. At the same time, applying an automated delegation update "MUST NOT break the current delegation" (per [RFC7344], Section 4.1), i.e., it must not hamper availability or validatability of the Child's resolution. As part of a more holistic treatment of the problem space, [DS-AUTOMATION] provides more-specific guidance on such safety checks.
CDS/CDNSKEY/CSYNC コンシューマの場合、子の権限のあるネームサーバーをすべて検査しない限り、要求された委任更新の影響を推定することは一般に不可能です。同時に、自動委任更新の適用は「現在の委任を壊してはなりません」([RFC7344]、セクション 4.1 に従って)、つまり、子の解決の可用性や検証性を妨げてはなりません。問題領域のより総合的な処理の一環として、[DS-AUTOMATION] は、そのような安全性チェックに関するより具体的なガイダンスを提供します。
Therefore, this document specifies that parent-side entities need to ensure that the updates indicated by CDS/CDNSKEY and CSYNC record sets are plausibly consistent across the child's nameservers before taking any action based on these records.
したがって、この文書では、親側エンティティは、CDS/CDNSKEY および CSYNC レコード セットによって示される更新が、これらのレコードに基づいてアクションを実行する前に、子のネームサーバー間で妥当な一貫性があることを確認する必要があると規定しています。
Readers are expected to be familiar with DNSSEC [RFC9364], in particular, [RFC4033], [RFC4034], [RFC4035], [RFC7344], and [RFC7477]. For an overview of related operational practices, refer to [RFC6781] and [RFC8901].
読者は、DNSSEC [RFC9364]、特に [RFC4033]、[RFC4034]、[RFC4035]、[RFC7344]、および [RFC7477] に精通していることが期待されます。関連する運用慣行の概要については、[RFC6781] および [RFC8901] を参照してください。
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] で説明されているように解釈されます。
Multi-provider setup:
マルチプロバイダーのセットアップ:
A constellation where several providers independently operate authoritative DNS service for a domain, usually for purposes of redundancy. This includes setups both with and without DNSSEC.
通常は冗長性を目的として、複数のプロバイダーがドメインに対して権威 DNS サービスを独立して運用するコンスタレーション。これには、DNSSEC を使用するセットアップと使用しないセットアップの両方が含まれます。
Multi-signer setup:
複数署名者のセットアップ:
A multi-provider setup for a DNSSEC-enabled domain with multiple independent signing entities [RFC8901]. Such a setup may be permanent (for redundancy) or temporary (for continuity of DNSSEC operation while changing the provider of a domain that normally uses a single one).
複数の独立した署名エンティティを備えた DNSSEC 対応ドメインのマルチプロバイダー設定 [RFC8901]。このようなセットアップは、永続的 (冗長性のため) または一時的 (通常は単一のドメインを使用するドメインのプロバイダーを変更する際の DNSSEC 操作の継続のため) の場合があります。
Otherwise, the terminology in this document is as defined in [RFC7344].
それ以外の場合、この文書の用語は [RFC7344] で定義されているとおりです。
Section 4.1 of [RFC7344] lists acceptance rules for CDS/CDNSKEY records. This list is extended with the consistency requirements defined in this document. This document does not modify any other part of [RFC7344].
[RFC7344] のセクション 4.1 には、CDS/CDNSKEY レコードの受け入れ規則がリストされています。このリストは、この文書で定義されている一貫性要件によって拡張されています。この文書は [RFC7344] の他の部分を変更しません。
Sections 3.1 and 4.2 of [RFC7477] have logic for deciding from which nameserver to query CSYNC information. This logic is replaced with the CSYNC consistency requirements defined in this document.
[RFC7477] のセクション 3.1 および 4.2 には、どのネームサーバーから CSYNC 情報をクエリするかを決定するためのロジックが含まれています。このロジックは、このドキュメントで定義されている CSYNC 一貫性要件に置き換えられます。
Consistency requirements that apply equally to CDS/CDNSKEY and CSYNC are listed first; type-specific consistency criteria are described in separate subsections.
CDS/CDNSKEY と CSYNC に同様に適用される一貫性要件が最初にリストされます。タイプ固有の一貫性基準については、別のサブセクションで説明します。
In order to determine plausible consistency of CDS/CDNSKEY or CSYNC RRsets across the child's nameservers, the Parental Agent MUST fetch all IP addresses for each nameserver hostname as listed in the Child's delegation from the Parent using a validating resolver, including any available glue records. Before acting on any CDS/ CDNSKEY or CSYNC record for the child, the Parental Agent MUST have established plausible consistency by querying all of these IP addresses for the record set(s) in question, as per the guidelines spelled out in the following subsections.
子のネームサーバー全体にわたる CDS/CDNSKEY または CSYNC RRset の妥当な一貫性を判断するために、親エージェントは、検証リゾルバーを使用して、有効なグルー レコードを含む、親からの子の委任にリストされている各ネームサーバーのホスト名のすべての IP アドレスをフェッチしなければなりません (MUST)。子供の CDS/CDNSKEY または CSYNC レコードに作用する前に、ペアレンタル エージェントは、次のサブセクションで説明するガイドラインに従って、問題のレコード セットについてこれらすべての IP アドレスをクエリすることによって、妥当な一貫性を確立しなければなりません (MUST)。
In all cases, consistency is REQUIRED across received responses only. (A NODATA response (see [RFC9499]) is a received response.)
すべての場合において、一貫性は受信した応答間でのみ必要です。(NODATA 応答 ([RFC9499] を参照) は受信された応答です。)
When a response cannot be obtained from a given nameserver, the Parental Agent SHOULD attempt to obtain it at a later time, before concluding that the nameserver is permanently unreachable and removing it from consideration. A configurable retry schedule is RECOMMENDED to increase the likelihood of collecting data from all nameservers. An exponential back-off schedule (e.g., 5, 10, 20, 40, ... minutes) provides a balance between faster task completion while accommodating transient unreachability. To sidestep localized routing issues, the Parental Agent MAY also attempt contacting the nameserver from another network vantage point.
指定されたネームサーバーから応答を取得できない場合、親エージェントは、そのネームサーバーが永久にアクセスできないと結論付けて考慮から除外する前に、後で応答を取得しようとすべきです(SHOULD)。すべてのネームサーバーからデータを収集する可能性を高めるために、構成可能な再試行スケジュールを設定することが推奨されます。指数関数的なバックオフ スケジュール (例: 5、10、20、40 分など) は、一時的な到達不能に対応しながら、タスクの迅速な完了との間のバランスを提供します。ローカライズされたルーティングの問題を回避するために、ペアレンタル エージェントは、別のネットワーク上の有利なポイントからネームサーバーへの接続を試みてもよい(MAY)。
If an inconsistent state is encountered, the Parental Agent MUST abort the operation. Specifically, it MUST NOT delete or alter any existing RRset that would have been deleted or altered, and it MUST NOT create any RRsets that would have been created had the nameservers given consistent responses.
矛盾した状態が発生した場合、親エージェントは操作を中止しなければなりません (MUST)。具体的には、削除または変更されるはずの既存の RRset を削除または変更してはなりません。また、ネームサーバーが一貫した応答を与えた場合に作成される RRset を作成してはなりません。
To accommodate transient inconsistencies (e.g., replication delays), implementations MAY be configurable to undertake a retry of the full process, repeating all queries (suggested default: enabled with exponential back-off).
一時的な不整合(例、レプリケーションの遅延)に対応するために、実装はプロセス全体の再試行を開始し、すべてのクエリを繰り返すように構成できてもよい(MAY) (推奨されるデフォルト: 指数関数的バックオフで有効)。
Any pending queries can immediately be dequeued when encountering a response that confirms the status quo, either implicitly (NODATA) or explicitly (via a response that matches the current delegation state). This is because any subsequent responses could only confirm that nothing needs to happen or give an inconsistent result in which case nothing needs to happen. The parent may apply local policy in determining whether the requested update is consistent or not with the status quo, as illustrated in the type-specific sections below. In any case, queries may be continued across all nameservers for reporting purposes.
保留中のクエリは、暗黙的 (NODATA) または明示的 (現在の委任状態と一致する応答を介して) 現状を確認する応答を受信すると、すぐにデキューできます。これは、後続の応答では、何も起こる必要がないことを確認することしかできないか、矛盾した結果が返される可能性があり、その場合は何も起こる必要がないためです。以下のタイプ固有のセクションで説明するように、親は、要求された更新が現状と一致しているかどうかを判断する際にローカル ポリシーを適用できます。いずれの場合も、レポートの目的ですべてのネームサーバーにわたってクエリを継続できます。
Existing requirements for ensuring integrity remain in effect. In particular, DNSSEC signatures MUST be requested and validated for all queries unless otherwise noted.
整合性を確保するための既存の要件は引き続き有効です。特に、特に記載がない限り、すべてのクエリに対して DNSSEC 署名を要求し、検証する必要があります。
When retrieving a Child's CDS/CDNSKEY RRset for DNSSEC delegation trust maintenance, the Parental Agent, knowing both the Child zone name and its NS hostnames, MUST ascertain that queries are made against all nameservers listed in the Child's delegation from the Parent. The Parental Agent MUST also ensure that each key referenced in any of the received answers is also referenced in all other received responses (subject to the CDS digest type considerations below) or that responses consistently indicate a request for removal of the entire DS RRset ([RFC8078], Section 6).
DNSSEC 委任の信頼維持のために子の CDS/CDNSKEY RRset を取得するとき、親エージェントは、子ゾーン名とその NS ホスト名の両方を知っているため、親からの子の委任にリストされているすべてのネームサーバーに対してクエリが行われていることを確認しなければなりません (MUST)。また、親エージェントは、受信した応答のいずれかで参照されている各キーが、他のすべての受信応答でも参照されていること (以下の CDS ダイジェスト タイプの考慮事項に従って)、または応答が一貫して DS RRset 全体の削除要求を示していることを保証しなければなりません ([RFC8078]、セクション 6)。
In other words, CDS/CDNSKEY records at the Child zone apex must be fetched directly from each reachable authoritative server as determined by the delegation's NS record set. When a key is referenced in an eligible CDS record set but not the CDNSKEY record set (or vice versa), or returned by one nameserver but is missing from at least one other nameserver's answer, the CDS/CDNSKEY state MUST be considered inconsistent. Similarly, the state MUST be considered inconsistent if there is a CDS or CDNSKEY response that indicates a removal request for the DS RRset whereas another response indicates no change (NODATA) or a DS update.
つまり、子ゾーンの頂点にある CDS/CDNSKEY レコードは、委任の NS レコード セットによって決定される、到達可能な各権限サーバーから直接フェッチする必要があります。キーが適格な CDS レコード セットで参照されているが CDNSKEY レコード セットでは参照されていない (またはその逆)、または 1 つのネームサーバーによって返されたが、少なくとも 1 つの他のネームサーバーの回答にキーが欠落している場合、CDS/CDNSKEY 状態は矛盾していると見なされなければなりません (MUST)。同様に、DS RRset の削除要求を示す CDS または CDNSKEY 応答があり、別の応答が変更なし (NODATA) または DS 更新を示す場合、状態は矛盾していると見なされなければなりません (MUST)。
CDS records MUST be considered for consistency only 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.
CDS レコードは、「ダイジェスト アルゴリズム」レジストリ [DS-IANA] の「DNSSEC 委任の実装」列でダイジェスト タイプ フィールドが「MUST」に指定されている場合にのみ、一貫性を考慮しなければなりません (MUST)。特にダイジェスト タイプがサポートされていない場合、他のダイジェスト タイプとのレコードの一貫性を検証する必要はありません。そのような記録は無視できます。
Independently of this, the parent may, as a matter of local policy, make its own choice regarding the hash digest types used when publishing a DS RRset (notwithstanding the requirements specified in [DS-IANA]). (The set of keys referenced in the DS RRset is not up to local policy. Only if all keys from the CDNSKEY RRset and eligible CDS records are included is the DS RRset considered consistent.)
これとは独立して、親は、ローカル ポリシーの問題として、([DS-IANA] で指定されている要件にもかかわらず) DS RRset を公開するときに使用されるハッシュ ダイジェスト タイプに関して独自の選択を行うことができます。(DS RRset で参照されるキーのセットは、ローカル ポリシーに従っていません。CDNSKEY RRset と適格な CDS レコードのすべてのキーが含まれている場合にのみ、DS RRset は一貫していると見なされます。)
During initial DS provisioning (DNSSEC bootstrapping), conventional DNSSEC validation for CDS/CDNSKEY responses is not (yet) available; in this case, authenticated bootstrapping [RFC9615] should be used.
初期 DS プロビジョニング (DNSSEC ブートストラップ) では、CDS/CDNSKEY 応答に対する従来の DNSSEC 検証は (まだ) 利用できません。この場合、認証されたブートストラップ [RFC9615] を使用する必要があります。
A CSYNC-based workflow generally consists of:
CSYNC ベースのワークフローは通常、次のもので構成されます。
1. querying the CSYNC (and possibly SOA) record to determine which data records shall be synchronized from child to parent, and
1. CSYNC (および場合によっては SOA) レコードをクエリして、どのデータ レコードが子から親に同期されるかを決定します。
2. querying for these data records (e.g., NS) before placing them in the parent zone.
2. これらのデータ レコード (NS など) を親ゾーンに配置する前にクエリを実行します。
If the below conditions are not met during these steps, the CSYNC state MUST be considered inconsistent.
これらのステップ中に以下の条件が満たされない場合、CSYNC 状態は矛盾していると見なされなければなりません (MUST)。
When querying the CSYNC record, the Parental Agent MUST ascertain that queries are made against all nameservers listed in the Child's delegation from the Parent and ensure that the record's immediate flag and type bitmap are equal across received responses.
CSYNC レコードをクエリするとき、親エージェントは、親からの子の委任にリストされているすべてのネームサーバーに対してクエリが行われていることを確認し、受信した応答全体でレコードの即時フラグとタイプ ビットマップが等しいことを確認しなければなりません。
The CSYNC record's SOA serial field and soaminimum flag might legitimately differ across nameservers (such as in multi-provider setups); thus, equality is not required across responses. Instead, for a given response, processing of these values MUST occur with respect to the SOA record as obtained from the same nameserver. If the resulting per-nameserver assessments of whether the update is permissible do not all agree, the CSYNC state MUST be considered inconsistent.
CSYNC レコードの SOA シリアル フィールドと soaminimum フラグは、ネームサーバー間で正当に異なる場合があります (マルチプロバイダー設定など)。したがって、応答全体で平等である必要はありません。代わりに、特定の応答について、同じネームサーバーから取得された SOA レコードに関してこれらの値の処理が行われなければなりません (MUST)。更新が許可されるかどうかのネームサーバーごとの結果の評価がすべて一致しない場合、CSYNC 状態は矛盾していると見なされなければなりません (MUST)。
Further, when retrieving the data record sets as indicated in the CSYNC record (such as NS or A/AAAA records), the Parental Agent MUST ascertain that all queries are made against all nameservers from which a CSYNC record was received and ensure that all of them return responses with equal rdata sets (including cases where all are empty).
さらに、CSYNC レコードに示されているデータ レコード セット (NS または A/AAAA レコードなど) を取得する場合、親エージェントは、CSYNC レコードの受信元であるすべてのネームサーバーに対してすべてのクエリが行われていることを確認し、すべてのネームサーバーが等しい rdata セット (すべてが空の場合を含む) で応答を返すことを確認しなければなりません。
As an example of local policy, the parent may choose to accept glue records only for in-domain or sibling NS hostnames [RFC9499].
ローカル ポリシーの例として、親はドメイン内または兄弟 NS ホスト名に対してのみグルー レコードを受け入れることを選択できます [RFC9499]。
Other CSYNC processing rules from Section 3 of [RFC7477] remain in place without modification. For example, when the NS type flag is present, associated NS processing has to occur before potential glue updates to ensure that glue addresses match the right set of nameservers. Also, when the type bitmap contains the A/AAAA flags, corresponding address queries are only to be sent for NS hostnames that are in bailiwick, while out-of-bailiwick NS records are ignored. Refer to Sections 3.2.2 and 4.3 of [RFC7477] for more details.
[RFC7477] のセクション 3 の他の CSYNC 処理規則は、変更されることなくそのまま残ります。たとえば、NS タイプ フラグが存在する場合、グルー アドレスが適切なネームサーバーのセットと一致することを確認するために、潜在的なグルー更新の前に関連する NS 処理を実行する必要があります。また、タイプ ビットマップに A/AAAA フラグが含まれている場合、対応するアドレス クエリは bailiwick 内にある NS ホスト名に対してのみ送信され、bailiwick 外の NS レコードは無視されます。詳細については、[RFC7477] のセクション 3.2.2 および 4.3 を参照してください。
CSYNC-based updates may cause validation or even insecure resolution to break (e.g., by changing the delegation to a set of nameservers that do not serve required DNSKEY records or do not know the zone at all). Parental Agents SHOULD check that CSYNC-based updates, if applied, do not break the delegation.
CSYNC ベースの更新により、検証が中断されたり、安全でない解決が中断されたりする可能性があります (たとえば、必要な DNSKEY レコードを提供しない、またはゾーンをまったく知らない一連のネームサーバーに委任を変更することによって)。親エージェントは、CSYNC ベースの更新が適用されている場合、委任が中断されないことを確認する必要があります (SHOULD)。
This document has no IANA actions.
この文書には IANA のアクションはありません。
The level of rigor mandated by this document is needed to prevent publication of half-baked DS or delegation NS RRsets (authorized only under an insufficient subset of authoritative nameservers), ensuring that a single operator cannot unilaterally modify the delegation (add or remove trust anchors or nameservers) when other operators are present. This applies both when the setup is intentional and when it is unintentional (such as in the case of lame-delegation hijacking).
この文書で義務付けられている厳格さのレベルは、中途半端な DS または委任 NS RRset (権限のあるネームサーバーの不十分なサブセットの下でのみ認可される) の公開を防止し、他のオペレーターが存在するときに単一のオペレーターが委任を一方的に変更 (トラスト アンカーまたはネームサーバーの追加または削除) できないようにするために必要です。これは、セットアップが意図的である場合と、意図的ではない場合 (不完全な委任のハイジャックの場合など) の両方に当てはまります。
As a consequence, the delegation's records can only be modified when zones are synchronized across operators, unanimously reflecting the domain owner's intentions. Both availability and integrity of the domain's DNS service benefit from this policy.
結果として、ドメイン所有者の意図を満場一致で反映して、オペレーター間でゾーンが同期されている場合にのみ、委任の記録を変更できます。このポリシーは、ドメインの DNS サービスの可用性と整合性の両方にメリットをもたらします。
In order to resolve situations in which consensus about child zone contents cannot be reached (e.g., because one of the nameserver operators is uncooperative), Parental Agents SHOULD continue to accept DS and NS/glue update requests from the domain owner via an authenticated out-of-band channel (such as Extensible Provisioning Protocol (EPP) [RFC5730]), irrespective of the adoption of automated delegation maintenance. Availability of such an interface also enables recovery from a situation where the private key is no longer available for signing the CDS/CDNSKEY or CSYNC records in the child zone.
子ゾーンのコンテンツについての合意に達できない状況(例、ネームサーバーオペレーターの1つが非協力的であるため)を解決するために、親エージェントは、自動委任メンテナンスの採用に関係なく、認証された帯域外チャネル(Extensible Provisioning Protocol (EPP) [RFC5730]など)を介してドメイン所有者からのDSおよびNS/グルー更新リクエストを受け入れ続ける必要があります(SHOULD)。このようなインターフェイスを利用できると、子ゾーンの CDS/CDNSKEY または CSYNC レコードに署名するために秘密キーが利用できなくなった状況からの回復も可能になります。
[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>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[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>.
[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>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[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>.
[DS-AUTOMATION]
Sheng, S. and P. Thomassen, "Operational Recommendations
for DNSSEC Delegation Signer (DS) Automation", Work in
Progress, Internet-Draft, draft-ietf-dnsop-ds-automation-
09, 22 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-dnsop-ds-automation-09>.
[DS-IANA] IANA, "DNSSEC Delegation Signer (DS) Resource Record (RR)
Type Digest Algorithms",
<https://www.iana.org/assignments/ds-rr-types>.
[LAME1] Akiwate, G., Jonker, M., Sommese, R., Foster, I., Voelker,
G. M., Savage, S., and K. Claffy, "Unresolved Issues:
Prevalence, Persistence, and Perils of Lame Delegations",
IMC '20: Proceedings of the ACM Internet Measurement
Conference, pp. 281-294, DOI 10.1145/3419394.3423623, 27
October 2020, <https://doi.org/10.1145/3419394.3423623>.
[LAME2] Akiwate, G., Savage, S., Voelker, G. M., and K. Claffy,
"Risky BIZness: risks derived from registrar name
management", IMC '21: Proceedings of the 21st ACM Internet
Measurement Conference, pp. 673-686,
DOI 10.1145/3487552.3487816, 2 November 2021,
<https://doi.org/10.1145/3487552.3487816>.
[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>.
[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>.
[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>.
The following scenarios are informative examples of how things can go wrong when consistency is not enforced by the parent during CDS/CDNSKEY/CSYNC processing. Other scenarios that cause similar (or perhaps even more) harm may exist.
次のシナリオは、CDS/CDNSKEY/CSYNC 処理中に親によって一貫性が強制されない場合に問題が発生する可能性がある例を示しています。同様の（あるいはそれ以上の）害を引き起こす他のシナリオも存在する可能性があります。
The common feature of these scenarios is that if one nameserver steps out of line and the parent is not careful, DNS resolution and/or validation will break down. When several DNS providers are involved, this undermines the very guarantees of operator independence that multi-provider configurations are intended to provide.
これらのシナリオに共通する特徴は、1 つのネームサーバーが基準から外れ、親が注意しないと、DNS 解決や検証が機能しなくなることです。複数の DNS プロバイダーが関与すると、マルチプロバイダー構成が提供することを目的としたオペレーターの独立性の保証自体が損なわれます。
If an authoritative nameserver is lagging behind during a key rollover, the parent may see different CDS/CDNSKEY RRsets depending on the nameserver contacted. This may cause old and new DS RRsets to be deployed in an alternating fashion and without the awareness of the zone maintainer, who may then inadvertently break the chain of trust by prematurely removing a DNSKEY still referenced by a (stale) CDS/CDNSKEY RRset.
権限のあるネームサーバーがキーのロールオーバー中に遅れている場合、接続されたネームサーバーに応じて、親には異なる CDS/CDNSKEY RRset が表示される可能性があります。これにより、ゾーン管理者の認識なしに古い DS RRset と新しい DS RRset が交互に展開される可能性があり、ゾーン管理者は、(古い) CDS/CDNSKEY RRset によってまだ参照されている DNSKEY を時期尚早に削除して、信頼のチェーンを誤って切断する可能性があります。
While foreseen in Section 6.2 of [RFC7344], the solution specified there requires parents to keep state on CDS/CDNSKEY RRsets. This document achieves the same without this burden and, in case the parent reports consistency errors downstream, can also help detection of the child-side replication issue by the operator.
[RFC7344] のセクション 6.2 で予見されていますが、そこで指定されている解決策では、親が CDS/CDNSKEY RRset の状態を保持する必要があります。このドキュメントは、このような負担を伴うことなく同じことを実現しており、親がダウンストリームで整合性エラーを報告した場合に備えて、オペレータによる子側のレプリケーションの問題の検出にも役立ちます。
A delegation may include a nonexistent NS hostname, for example, due to a typo or the nameserver's domain registration having expired. (Re-)registering such a non-resolvable nameserver domain allows a third party to run authoritative DNS service for all domains delegated to that NS hostname, serving responses different from the legitimate ones.
委任には、タイプミスやネームサーバーのドメイン登録の期限切れなどにより、存在しない NS ホスト名が含まれる場合があります。このような解決不可能なネームサーバー ドメインを (再) 登録すると、サードパーティがその NS ホスト名に委任されたすべてのドメインに対して権威 DNS サービスを実行し、正規のものとは異なる応答を提供することが可能になります。
This strategy for hijacking (at least part of the) DNS traffic and spoofing responses is not new but is surprisingly common [LAME1] [LAME2]. It is also known that DNSSEC reduces the impact of such an attack, as validating resolvers will reject illegitimate responses due to lack of signatures consistent with the delegation's DS records.
DNS トラフィック (少なくとも一部) をハイジャックして応答をスプーフィングするこの戦略は新しいものではありませんが、驚くほど一般的です [LAME1] [LAME2]。また、検証リゾルバーは、委任の DS レコードと一致する署名がないために不正な応答を拒否するため、DNSSEC がそのような攻撃の影響を軽減することも知られています。
On the other hand, if the delegation is not protected by DNSSEC, the rogue nameserver is not only able to serve unauthorized responses without detection: it is even possible for the attacker to escalate the nameserver takeover to a full domain takeover.
一方、委任が DNSSEC によって保護されていない場合、不正なネームサーバーは検出されずに不正な応答を提供できるだけでなく、攻撃者がネームサーバーの乗っ取りを完全なドメインの乗っ取りにエスカレートする可能性さえあります。
In particular, the rogue nameserver can publish CDS/CDNSKEY records. If those are processed by the parent without ensuring consistency with other authoritative nameservers, the delegation will, with some patience, get secured with the attacker's DNSSEC keys. Of course, as the parent's query (or sometimes queries) need to hit the attacker's nameserver, this requires some statistical luck, but, eventually, it will succeed. As responses served by the remaining legitimate nameservers are not signed with these keys, validating resolvers will start rejecting them.
特に、不正なネームサーバーは CDS/CDNSKEY レコードを公開する可能性があります。これらが他の権威ネームサーバーとの一貫性を保証せずに親によって処理された場合、委任はある程度の忍耐を持って攻撃者の DNSSEC キーで保護されます。もちろん、親のクエリ (または場合によってはクエリ) が攻撃者のネームサーバーにアクセスする必要があるため、これにはある程度の統計上の幸運が必要ですが、最終的には成功します。残りの正当なネームサーバーによって提供される応答はこれらのキーで署名されていないため、検証リゾルバーはそれらを拒否し始めます。
Once DNSSEC is established, the attacker can use CSYNC to remove other nameservers from the delegation at will (and potentially add new ones under their control) or change glue records to point to the attacker's nameservers. This enables the attacker to position itself as the only party providing authoritative DNS service for the victim domain, significantly augmenting the attack's impact.
DNSSEC が確立されると、攻撃者は CSYNC を使用して、他のネームサーバーを委任から自由に削除したり (制御下に新しいネームサーバーを追加する可能性もあります)、攻撃者のネームサーバーを指すようにグルー レコードを変更したりすることができます。これにより、攻撃者は自分自身を被害ドメインに権威 DNS サービスを提供する唯一の当事者として位置づけることができ、攻撃の影響が大幅に増大します。
While performing a key rollover and adjusting the corresponding CDS/ CDNSKEY records, a provider could accidentally publish CDS/CDNSKEY records that only include its own keys.
キー ロールオーバーを実行し、対応する CDS/CDNSKEY レコードを調整しているときに、プロバイダーが誤って独自のキーのみを含む CDS/CDNSKEY レコードを公開する可能性があります。
When the parent happens to retrieve the records from a nameserver controlled by this provider, the other providers' DS records would be removed from the delegation. As a result, the zone is broken (at least for some queries).
親がこのプロバイダーによって制御されるネームサーバーからレコードを取得すると、他のプロバイダーの DS レコードが委任から削除されます。その結果、ゾーンは (少なくとも一部のクエリでは) 壊れます。
A similar scenario affects the CSYNC record, which is used to update the delegation's NS record set at the parent. For example, the issue occurs when a provider accidentally includes only their own set of hostnames in the local NS record set or publishes an otherwise flawed NS record set.
同様のシナリオは、親に設定されている委任の NS レコードを更新するために使用される CSYNC レコードに影響します。たとえば、プロバイダーがローカル NS レコード セットに誤って独自のホスト名のセットのみを含めたり、欠陥のある NS レコード セットを公開したりした場合に、この問題が発生します。
If the parent then observes a CSYNC signal and fetches the flawed NS record set without ensuring consistency across nameservers, the delegation may be updated in a way that breaks resolution or silently reduces the multi-provider setup to a single-provider setup.
その後、親が CSYNC 信号を監視し、ネームサーバー間での一貫性を確保せずに欠陥のある NS レコード セットをフェッチすると、解決を壊す方法で委任が更新されるか、マルチプロバイダーのセットアップが単一プロバイダーのセットアップに黙って縮小される可能性があります。
Transferring DNS service for a domain name from one (signing) DNS provider to another, without going insecure, necessitates a brief period during which the domain is operated in multi-signer mode. First, the providers include each other's signing keys as DNSKEY and CDS/CDNSKEY records in their own copy of the zone. Once the parent learns about the updated CDS/CDNSKEY record set at the old provider, the delegation's DS record set is updated. Then, after waiting for cache expiration, the new provider's NS hostnames can be added to the zone's NS record set so that queries start balancing across both providers. To conclude the handover, the old provider is removed by inverting these steps with swapped roles.
ドメイン名の DNS サービスを、安全性を損なうことなく、ある (署名している) DNS プロバイダーから別の DNS プロバイダーに移行するには、ドメインをマルチ署名者モードで運用する短期間が必要です。まず、プロバイダーは、互いの署名キーを DNSKEY および CDS/CDNSKEY レコードとして独自のゾーンのコピーに含めます。親が古いプロバイダーで更新された CDS/CDNSKEY レコード セットを認識すると、委任の DS レコード セットが更新されます。次に、キャッシュの有効期限が切れるのを待った後、新しいプロバイダーの NS ホスト名をゾーンの NS レコード セットに追加して、両方のプロバイダー間でクエリのバランスを開始することができます。ハンドオーバーを完了するには、役割を交換してこれらの手順を逆にして古いプロバイダーを削除します。
The multi-signer phase of this process breaks when the new provider, perhaps unaware of the situation and its intricacies, fails to include the old provider's keys in the DNSKEY (and CDS/CDNSKEY) record sets. One obvious consequence is that whenever the resolver happens to retrieve the DNSKEY record set from the new provider, the old provider's RRSIGs no longer validate, causing SERVFAIL to be returned.
このプロセスの複数署名者フェーズは、新しいプロバイダーがおそらく状況とその複雑さに気づいておらず、DNSKEY (および CDS/CDNSKEY) レコード セットに古いプロバイダーのキーを含めることに失敗したときに中断されます。明らかな結果の 1 つは、リゾルバーが新しいプロバイダーから DNSKEY レコード セットを取得するたびに、古いプロバイダーの RRSIG が検証されなくなり、SERVFAIL が返されることです。
However, an even worse consequence can occur when the parent performs their next CDS/CDNSKEY scan. The incorrect CDS/CDNSKEY record set is fetched from the new provider and used to update the delegation's DS record set. As a result, the old provider (who still appears in the delegation) is prematurely removed from the domain's DNSSEC chain of trust. The new DS record set authenticates the new provider's DNSKEYs only, and DNSSEC validation fails for all answers served by the old provider.
ただし、親が次の CDS/CDNSKEY スキャンを実行するときに、さらに悪い結果が発生する可能性があります。間違った CDS/CDNSKEY レコード セットが新しいプロバイダーからフェッチされ、委任の DS レコード セットの更新に使用されます。その結果、古いプロバイダー (委任にまだ表示されている) は、ドメインの DNSSEC 信頼チェーンから時期尚早に削除されます。新しい DS レコード セットは新しいプロバイダーの DNSKEY のみを認証し、古いプロバイダーが提供するすべての回答について DNSSEC 検証は失敗します。
In order of first contribution or review: Viktor Dukhovni, Wes Hardaker, Libor Peltan, Oli Schacher, David Blacka, Charlie Kaufman, Michael Bauland, Patrick Mevzek, Joe Abley, Ondřej Caletka, Ondřej Surý, Mohamed Boucadair, Vijay Gurbani, Gorry Fairhurst, Paul Wouters, Andy Newton, Mike Bishop, and Warren Kumari.
最初の投稿またはレビューの順: Viktor Dukhovni、Wes Hardaker、Libor Peltan、Oli Schacher、David Blacka、Charlie Kaufman、Michael Bauland、Patrick Mevzek、Joe Abley、Ondřej Caletka、Ondřej Surý、Mohamed Boucadair、Vijay Gurbani、Gorry Fairhurst、Paul Wouters、Andy Newton、Mikeビショップとウォーレン・クマリ。
Peter Thomassen
SSE - Secure Systems Engineering GmbH
Hauptstraße 3
10827 Berlin
Germany
Email: pth@systemsecurity.com