Internet Engineering Task Force (IETF) P. Thomassen
Request for Comments: 9615 deSEC, Secure Systems Engineering (SSE)
Updates: 7344, 8078 N. Wisiol
Category: Standards Track deSEC, Technische Universität Berlin
ISSN: 2070-1721 July 2024
This document introduces an in-band method for DNS operators to publish arbitrary information about the zones for which they are authoritative, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated.
このドキュメントでは、DNSオペレーターが権威ある、認証された方法で、ゾーンごとにゾーンに関する任意の情報を公開するための帯域内の方法を紹介します。このメカニズムにより、マネージドDNSオペレーターは、現在安全に委任されていないゾーンを含め、管理下のゾーンのDNSSECキーパラメーターを安全に発表することができます。
Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay".
ゾーンの代表団にDSレコードが存在しない場合はいつでも、この信号により、親のレジストラまたはレジストラが子供の頂点で見つかったCDS/CDNSKEYレコードを暗号化することができます。その後、親は、帯域外の検証や「遅延後の受け入れ」などのクロスチェックに頼ることなく、代表団のDSレコードを提供できます。
This document establishes the DS enrollment method described in Section 4 of this document as the preferred method over those from Section 3 of RFC 8078. It also updates RFC 7344.
このドキュメントでは、このドキュメントのセクション4で説明されているDS登録方法を、RFC 8078のセクション3よりも好ましい方法として確立します。また、RFC 7344を更新します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9615.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9615で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
1.2. Requirements Notation
2. Updates to RFCs
3. Signaling
3.1. Chain of Trust
3.2. Signaling Names
4. Bootstrapping a DNSSEC Delegation
4.1. Signaling Consent to Act as the Child's Signer
4.1.1. Example
4.2. Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping
4.2.1. Example
4.3. Triggers
4.4. Limitations
5. Operational Recommendations
5.1. Child DNS Operator
5.2. Parental Agent
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
Securing a DNS delegation for the first time requires that the child's DNSSEC parameters be conveyed to the parent through some trusted channel. While the communication conceptually has to occur between the parent registry and the DNSSEC key holder, what that means exactly and how communication is coordinated traditionally depends on the relationship the child has with the parent.
DNS委任を初めて固定するには、子供のDNSSECパラメーターを信頼できるチャネルを介して親に伝える必要があります。コミュニケーションは、親レジストリとDNSSECキーホルダーの間で概念的に発生する必要がありますが、それが正確に何を意味し、コミュニケーションがどのように調整されるかは、伝統的に子供が親と持つ関係に依存します。
A typical situation is that the key is held by the child DNS operator; thus, the communication often involves this entity. In addition, depending on the circumstances, it may also involve the registrar, possibly via the registrant (for details, see Appendix A of [RFC7344].
典型的な状況は、キーが子DNSオペレーターによって保持されていることです。したがって、コミュニケーションにはしばしばこのエンティティが含まれます。さらに、状況に応じて、おそらく登録者を介してレジストラを含む場合があります（詳細については、[RFC7344]の付録Aを参照してください。
As observed in [RFC7344], these dependencies often result in a manual process that is susceptible to mistakes and/or errors. In addition, due to the annoyance factor of the process, involved parties may avoid the process of getting a DS resource record set (RRset) published in the first place.
[RFC7344]で観察されているように、これらの依存関係は、多くの場合、間違いやエラーの影響を受けやすい手動プロセスをもたらします。さらに、プロセスの迷惑要因により、関係者はそもそもDSリソースレコードセット（RRSET）を公開するプロセスを回避する場合があります。
To alleviate these problems, automated provisioning of DS records has been specified in [RFC8078]. It is based on the parental agent (registry or registrar) fetching DNSSEC key parameters from the CDS and CDNSKEY records ([RFC7344]) located at the child zone's apex, and validating them somehow. This validation can be done using the child's existing DNSSEC chain of trust if the objective is to update an existing DS RRset (such as during key rollover). However, when bootstrapping a DNSSEC delegation, the child zone has no existing DNSSEC validation path, so other means to ensure the CDS/CDNSKEY records' legitimacy must be found.
これらの問題を軽減するために、[RFC8078]でDSレコードの自動プロビジョニングが指定されています。これは、子ゾーンの頂点にあるCDSおよびCDNSKEYレコード（[RFC7344]）からDNSSECキーパラメーターを取得する親エージェント（レジストリまたはレジストラ）に基づいており、何らかの形でそれらを検証します。この検証は、既存のDS RRSet（キーロールオーバーなど）を更新する目的である場合、子供の既存のDNSSEC信頼チェーンを使用して実行できます。ただし、DNSSEC委任をブートストラップする場合、チャイルドゾーンには既存のDNSSEC検証パスがないため、CDS/CDNSKEYレコードの正当性を確保する他の手段が見つかりなければなりません。
Due to the lack of a comprehensive DNS-innate solution, either out-of-band methods have been used so far to complete the chain of trust, or cryptographic validation has been entirely dispensed with, in exchange for weaker types of cross-checks such as "Accept after Delay" (Section 3.3 of [RFC8078]). [RFC8078] does not define an in-band validation method for enabling DNSSEC.
包括的なDNS-inateソリューションがないため、これまでのところ、信頼の連鎖を完了するために帯域外の方法が使用されてきたか、暗号化の検証は、そのようなより弱いタイプのクロスチェックと引き換えに完全に省略されています。「遅延後の受け入れ」（[RFC8078]のセクション3.3）として。[RFC8078]は、DNSSECを有効にするためのバンド内検証方法を定義していません。
This document aims to close this gap by introducing an in-band method for DNS operators to publish arbitrary information about the zones for which they are authoritative, in an authenticated manner and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management. The parent can then use this signal to cryptographically validate the CDS/CDNSKEY RRsets found at an insecure child zone's apex and, upon success, secure the delegation.
このドキュメントは、DNSオペレーターが権威あるゾーンに関する任意の情報を公開し、認証された方法で、ゾーンごとに任意の情報を公開することにより、このギャップを閉じることを目的としています。このメカニズムにより、マネージドDNSオペレーターは、管理下のゾーンのDNSSECキーパラメーターを安全に発表することができます。その後、親はこの信号を使用して、安全でない子ゾーンの頂点で見つかったCDS/CDNSKEY RRSETを暗号化し、成功すると代表団を確保することができます。
While applicable to the vast majority of domains, the protocol does not support certain edge cases, such as excessively long child zone names, or DNSSEC bootstrapping for domains with in-domain nameservers only (see Section 4.4).
大多数のドメインに適用されますが、プロトコルは、ドメイン内の名前アーバーのみを持つドメインのDNSSECブートストラップなど、過度に長い子ゾーン名、またはDNSSECブートストラップなどの特定のエッジケースをサポートしていません（セクション4.4を参照）。
DNSSEC bootstrapping is just one application of the generic signaling mechanism specified in this document. Other applications might arise in the future, such as publishing operational metadata or auxiliary information that the DNS operator likes to make known (e.g., API endpoints for third-party interaction).
DNSSECブートストラップは、このドキュメントで指定された一般的なシグナル伝達メカニズムの1つのアプリケーションにすぎません。他のアプリケーションは、運用上のメタデータやDNSオペレーターが既知にするのが好きな補助情報の公開など、将来的に発生する可能性があります（例：サードパーティの相互作用のAPIエンドポイントなど）。
Readers are expected to be familiar with DNSSEC [BCP237].
読者はDNSSEC [BCP237]に精通していると予想されます。
This section defines the terminology used in this document.
このセクションでは、このドキュメントで使用されている用語を定義します。
CDS/CDNSKEY:
CDS/CDNSKEY：
This notation refers to CDS and/or CDNSKEY, i.e., one or both.
この表記は、CDおよび/またはCDNSKEY、つまり一方または両方を指します。
Child:
子供：
See Section 7 of [RFC9499].
[RFC9499]のセクション7を参照してください。
Child DNS operator:
チャイルドDNSオペレーター：
The entity that maintains and publishes the zone information for the child DNS.
子DNSのゾーン情報を維持および公開するエンティティ。
Parent:
親：
See Section 7 of [RFC9499].
[RFC9499]のセクション7を参照してください。
Parental agent:
親のエージェント：
The entity that has the authority to insert DS records into the parent zone on behalf of the child. (It could be the registry, registrar, a reseller, or some other authorized entity.)
子供に代わってDSレコードを親ゾーンに挿入する権限を持つエンティティ。（これは、レジストリ、レジストラ、再販業者、またはその他の承認されたエンティティである可能性があります。）
Signaling domain:
シグナリングドメイン：
A domain name constructed by prepending the label _signal to a hostname taken from a delegation's NS RRset. There are as many signaling domains as there are distinct NS targets.
ラベル_signalを代表団のNS RRSetから取得したホスト名に準備することによって構築されたドメイン名。異なるNSターゲットがあるのと同じくらい多くの信号ドメインがあります。
Signaling name:
信号名：
The labels that are prefixed to a signaling domain in order to identify a signaling type and a child zone's name (see Section 3.2).
シグナリングタイプとチャイルドゾーンの名前を識別するために、信号ドメインに接頭辞が付けられたラベル（セクション3.2を参照）。
Signaling record:
シグナリングレコード：
A DNS record located at a signaling name under a signaling domain. Signaling records are used by the child DNS operator to publish information about the child.
シグナリングドメインの下にある信号名にあるDNSレコード。シグナリングレコードは、子のDNSオペレーターが子供に関する情報を公開するために使用されます。
Signaling type:
シグナリングタイプ：
A signal type identifier, such as _dsboot for DNSSEC bootstrapping.
DNSSECブートストラップの_DSBootなどの信号型識別子。
Signaling zone:
シグナリングゾーン：
The zone that is authoritative for a given signaling record.
特定の信号記録に対して権威あるゾーン。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The DS enrollment methods described in Section 3 of [RFC8078] are less secure than the method described in Section 4 of this document. Therefore, child DNS operators and parental agents wishing to use CDS/CDNSKEY records for initial DS enrollment SHOULD support the authentication protocol described here.
[RFC8078]のセクション3で説明されているDS登録方法は、このドキュメントのセクション4で説明されている方法よりも安全性が低くなります。したがって、最初のDS登録にCD/CDNSKEYレコードを使用することを希望する児童DNSオペレーターと親エージェントは、ここで説明する認証プロトコルをサポートする必要があります。
In order to facilitate publication of signaling records for the purpose of DNSSEC bootstrapping (see Section 4.1), the first bullet ("Location") of Section 4.1 of [RFC7344] is removed.
DNSSECブートストラップの目的で信号記録の公開を容易にするために（セクション4.1を参照）、[RFC7344]のセクション4.1の最初の弾丸（「位置」）が削除されます。
This section describes the general mechanism by which a child DNS operator can publish an authenticated signal about a child zone. Parental agents (or any other party) can then discover and process the signal. Authenticity is ensured through standard DNSSEC validation.
このセクションでは、子供DNSオペレーターが子ゾーンに関する認証された信号を公開できる一般的なメカニズムについて説明します。親のエージェント（または他の当事者）は、信号を発見して処理できます。標準のDNSSEC検証により、信頼性が確保されます。
If a child DNS operator implements this specification, each signaling zone MUST be signed and be validatable by the parental agent (i.e., have a valid publicly resolvable DNSSEC chain of trust). This is typically achieved by securely delegating each signaling zone.
子DNSオペレーターがこの仕様を実装する場合、各信号ゾーンに署名し、親のエージェントが有効にする必要があります（つまり、有効に解決可能なDNSSECの信頼チェーンを持っています）。これは通常、各信号ゾーンを安全に委任することによって達成されます。
For example, when publishing a signal that relates to a child zone with NS records ns1.example.net and ns2.example.org, the child DNS operator needs to ensure that the parental agent has a valid DNSSEC chain of trust for the zone(s) that are authoritative for the signaling domains _signal.ns1.example.net and _signal.ns2.example.org.
たとえば、NSレコードNS1.example.netおよびNS2.example.orgを記録した子ゾーンに関連する信号を公開する場合、子DNSオペレーターは、親エージェントがゾーンに対して有効なDNSSECの信頼チェーンを持っていることを確認する必要があります（s）シグナリングドメイン_signal.ns1.example.netおよび_signal.ns2.example.orgの権威ある。
To publish information about the child zone in an authenticated fashion, the child DNS operator MUST publish one or more signaling records at a signaling name under each signaling domain.
子供ゾーンに関する情報を認証された方法で公開するには、子DNSオペレーターは、各シグナルドメインの下にある信号名で1つ以上の信号記録を公開する必要があります。
Signaling records MUST be accompanied by RRSIG records created with the corresponding signaling zone's key(s). The type and contents of these signaling records depend on the type of signal.
シグナリングレコードには、対応する信号ゾーンのキーで作成されたRRSIGレコードを添付する必要があります。これらの信号レコードのタイプと内容は、信号のタイプに依存します。
The signaling name identifies the child and the signaling type. It is identical to the child name (with the final root label removed), prefixed with a label containing the signaling type.
シグナリング名は、子供とシグナリングタイプを識別します。これは、シグナリングタイプを含むラベルが付いた、子名（最終ルートラベルが削除された）と同じです。
When the child zone's CDS/CDNSKEY RRsets are used for setting up initial trust, they need to be authenticated. This is achieved by copublishing the child's CDS/CDNSKEY RRsets as an authenticated signal as described in Section 3. The parent can discover and validate it, thus transferring trust from the child DNS operator nameservers' chain of trust to the child zone.
Child ZoneのCDS/CDNSKEY RRSETが最初の信頼を設定するために使用される場合、認証する必要があります。これは、セクション3で説明されているように、子供のCDS/CDNSKEY RRSETを認証された信号として共同出版することによって達成されます。
This protocol is not intended for updating an existing DS RRset. For this purpose, the parental agent can validate the child's CDS/CDNSKEY RRsets directly, using the chain of trust established by the existing DS RRset (Section 4 of [RFC7344]).
このプロトコルは、既存のDS RRSetを更新することを目的としていません。この目的のために、親のエージェントは、既存のDS RRSet（[RFC7344]のセクション4）によって確立された信頼のチェーンを使用して、子供のCDS/CDNSKEY RRSetsを直接検証できます。
To confirm its willingness to act as the child's delegated signer and authenticate the child's CDS/CDNSKEY RRsets, the child DNS operator MUST copublish them at the corresponding signaling name under each signaling domain, excluding those that would fall within the child domain (Section 3.2). For simplicity, the child DNS operator MAY also copublish the child's CDS/CDNSKEY RRsets under signaling domains within the child domain, although those signaling domains are not used for validation (Section 4.2).
子供の委任された署名者として行動し、子供のCDS/CDNSKEY rrsetsを認証する意欲を確認するために、子供のDNSオペレーターは、子ドメイン内に該当するものを除く、各シグナリングドメインの下の対応するシグナル名でそれらを共有する必要があります（セクション3.2）。簡単にするために、子供のDNSオペレーターは、子ドメイン内のシグナル伝達ドメインの下で子供のCDS/CDNSKEY RRSETを共有することもできますが、それらのシグナルドメインは検証には使用されません（セクション4.2）。
Unlike the CDS/CDNSKEY RRsets at the child's apex, a signaling RRset MUST be signed with the corresponding signaling zone's key(s). Its contents MUST be identical to the corresponding RRset published at the child's apex.
子供の頂点でのCDS/CDNSKEY RRSetsとは異なり、対応するシグナル伝達ゾーンのキーでシグナリングRRSETに署名する必要があります。その内容は、The Child's Apexで公開されている対応するRRSetと同一でなければなりません。
Existing use of CDS/CDNSKEY records was specified at the child apex only (Section 4.1 of [RFC7344]). This protocol extends the use of these record types to non-apex owner names for the purpose of DNSSEC bootstrapping. To exclude the possibility of semantic collision, there MUST NOT be a zone cut at a signaling name.
CDS/CDNSKEYレコードの既存の使用は、Child Apexのみで指定されました（[RFC7344]のセクション4.1）。このプロトコルは、DNSSECブートストラップを目的として、これらのレコードタイプの使用を非APEX所有者名に拡張します。セマンティック衝突の可能性を除外するために、信号名にゾーンカットが削減されてはなりません。
For the purposes of bootstrapping the child zone example.co.uk with NS records ns1.example.net, ns2.example.org, and ns3.example.co.uk, the required signaling domains are _signal.ns1.example.net and _signal.ns2.example.org.
NSレコードNS1.example.net、ns2.example.org、およびns3.example.co.ukを使用して、子ゾーンexample.co.ukをブートストラップする目的で、必要なシグナル伝達ドメインは_signal.ns1.example.net and and_signal.ns2.example.org。
In the zones containing these domains, the child DNS operator authenticates the CDS/CDNSKEY RRsets found at the child's apex by copublishing them as CDS/CDNSKEY RRsets at the names:
これらのドメインを含むゾーンでは、子供DNSオペレーターが、名前のCDS/CDNSKEY rrsetsとしてそれらを共有することにより、子供の頂点で見つかったCDS/CDNSKEY RRSetsを認証します。
_dsboot.example.co.uk._signal.ns1.example.net
_dsboot.example.co.uk._signal.ns2.example.org
These RRsets are signed with DNSSEC just like any other zone data.
これらのrrsetは、他のゾーンデータと同様にDNSSECで署名されます。
Publication of signaling records under the in-domain name _signal.ns3.example.co.uk is not required.
ドメイン内の名前の下での信号記録の公開_signal.ns3.example.co.ukは必要ありません。
To validate a child's CDS/CDNSKEY RRset for DNSSEC bootstrapping, the parental agent, knowing both the child zone name and its NS hostnames, MUST execute the following steps:
DNSSECブートストラップの子供のCDS/CDNSKEY RRSETを検証するには、子ゾーン名とそのNSホスト名の両方を知っている親エージェントは、次の手順を実行する必要があります。
Step 1: verify that the child has no DS records published at the parent and that at least one of its nameservers is outside the child domain;
ステップ1：子供が親に公開されているDSレコードがないことを確認し、その名前サーバーの少なくとも1つが子ドメインの外側にあることを確認します。
Step 2: query the CDS/CDNSKEY RRset at the child zone apex directly from each of the authoritative servers as determined by the delegation's (parent-side) NS RRset, without caching;
ステップ2：キャッシングなしで代表団（親側）ns rrsetによって決定される、各権威あるサーバーから、子ゾーン頂点でCDS/CDNSKEY RRSETを照会します。
Step 3: query the CDS/CDNSKEY RRset located at the signaling name under each signaling domain (except those falling within the child domain) using a trusted DNS resolver and enforce DNSSEC validation;
ステップ3：信頼できるDNSリゾルバーを使用して各信号ドメイン（子ドメイン内に該当するものを除く）の下にあるCDS/CDNSKEY RRSETをクエリし、DNSSEC検証を強制します。
Step 4: check (separately by record type) that all RRsets retrieved in Steps 2 and 3 have equal contents;
ステップ4：ステップ2および3で取得されたすべてのrrsetsに等しい内容があることを確認（レコードタイプごとに個別に）。
If the above steps succeed without error, the CDS/CDNSKEY RRsets are successfully verified, and the parental agent can proceed with the publication of the DS RRset under the precautions described in Section 5 of [RFC8078].
上記の手順がエラーなしで成功した場合、CDS/CDNSKEY RRSETSは正常に検証され、親のエージェントは[RFC8078]セクション5に記載されている予防措置に基づいてDS RRSetの公開を進めることができます。
The parental agent MUST abort the procedure if an error condition occurs, in particular:
特にエラー条件が発生した場合、親のエージェントは手順を中止する必要があります。
* in Step 1: the child is already securely delegated or has in-domain nameservers only;
* ステップ1では、子供はすでに安全に委任されているか、ドメイン内の名前サーバーのみがあります。
* in Step 2: any failure during the retrieval of the CDS/CDNSKEY RRset located at the child apex from any of the authoritative nameservers;
* ステップ2：CDS/CDNSKEY RRSTの検索中の障害は、いずれかの権威ある名前サーバーから子頂点にある。
* in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets located at the signaling name under any signaling domain, including failure of DNSSEC validation, or unauthenticated data (AD bit not set);
* ステップ3：DNSSEC検証の障害、または認証されていないデータ（ADビットが設定されていない）を含む、シグナリングドメインの下にあるCDS/CDNSKEY RRSETSを取得できなかった場合。
* in Step 4: inconsistent responses (for at least one of the types), including an RRset that is empty in one of Steps 2 or 3, but non-empty in the other.
* ステップ4：一貫性のない応答（少なくとも1つのタイプの場合）。手順2または3のいずれかで空であるが、もう1つは空ではないRRSetを含む。
To verify the CDS/CDNSKEY RRsets for the child example.co.uk, the parental agent (assuming that the child delegation's NS records are ns1.example.net, ns2.example.org, and ns3.example.co.uk)
子のexample.co.ukのCDS/CDNSKEY RRSETSを検証するには、親エージェント（子の代表団のNSレコードがNS1.example.net、ns2.example.org、およびns3.example.co.ukであると仮定して）
1. checks that the child domain is not yet securely delegated;
1. 子ドメインがまだ安全に委任されていないことを確認します。
2. queries the CDS/CDNSKEY RRsets for example.co.uk directly from ns1.example.net, ns2.example.org, and ns3.example.co.uk (without caching);
2. ns1.example.net、ns2.example.org、およびns3.example.co.uk（キャッシングなし）から直接、cds/cdnskey rrsetsをクエリします。
3. queries and validates the CDS/CDNSKEY RRsets located at (see Section 3.2; ns3.example.co.uk is ignored because it is in-domain)
3. にあるCDS/CDNSKEY RRSETSをクエリと検証します（セクション3.2; ns3.example.co.ukはドメイン内であるため無視されます）
_dsboot.example.co.uk._signal.ns1.example.net
_dsboot.example.co.uk._signal.ns2.example.org
4. checks that the CDS/CDNSKEY RRsets retrieved in Steps 2 and 3 agree across responses.
4. 手順2および3で取得されたCD/CDNSKEY RRSETSが回答間で一致することを確認します。
If all of these steps succeed, the parental agent can proceed to publish a DS RRset as indicated by the validated CDS/CDNSKEY RRset.
これらのすべての手順が成功した場合、親エージェントは、検証済みのCDS/CDNSKEY RRSETで示されるように、DS RRSETを公開することができます。
As in-domain signaling names do not have a chain of trust at bootstrapping time, the parental agent does not consider them during validation. Consequently, if all NS hostnames are in-domain, validation cannot be completed and DS records are not published.
ドメイン内の信号名はブートストラップ時に信頼の連鎖を持っていないため、親のエージェントは検証中にそれらを考慮しません。その結果、すべてのNSホスト名がドメイン内である場合、検証は完了できず、DSレコードは公開されません。
Parental agents SHOULD trigger the procedure described in Section 4.2 once one of the following conditions is fulfilled:
親のエージェントは、次の条件のいずれかが満たされたら、セクション4.2で説明されている手順をトリガーする必要があります。
* The parental agent receives a new or updated NS RRset for a child;
* 親のエージェントは、子供の新しいまたは更新されたNS RRSETを受け取ります。
* The parental agent receives a notification indicating that the child wishes to have its CDS/CDNSKEY RRset processed;
* 親のエージェントは、子供がCDS/CDNSKEY RRSetを処理したいことを示す通知を受け取ります。
* The parental agent encounters a signaling record during a proactive, opportunistic scan (e.g., daily queries of signaling records for some or all of its delegations);
* 親のエージェントは、積極的で日和見的なスキャン中にシグナリングレコードに遭遇します（たとえば、その代表団の一部またはすべてのシグナリングレコードの毎日のクエリ）。
* The parental agent encounters a signaling record during an NSEC walk or when parsing a signaling zone (e.g., when made available via AXFR by the child DNS operator);
* 親のエージェントは、NSECウォーク中またはシグナリングゾーンを解析するときにシグナリングレコードに遭遇します（たとえば、子供DNSオペレーターによってAXFRを介して利用可能になった場合）。
* Any other condition deemed appropriate by local policy.
* 地域のポリシーによって適切とみなされる他の条件。
Timer-based trigger mechanisms (such as scans) exhibit undesirable properties with respect to processing delay and scaling; on-demand triggers (like notifications) are preferable. Whenever possible, child DNS operators and parental agents are thus encouraged to use them, reducing both delays and the amount of scanning traffic.
タイマーベースのトリガーメカニズム（スキャンなど）は、処理遅延とスケーリングに関して望ましくない特性を示します。オンデマンドトリガー（通知など）が望ましいです。可能な限り、子供のDNSオペレーターと親のエージェントはそれらを使用することを奨励され、遅延とスキャントラフィックの量の両方を減らします。
Most types of discovery (such as daily scans of delegations) are based directly on the delegation's NS RRset. In this case, these NS names can be used as is by the bootstrapping algorithm (Section 4.2) for querying signaling records.
ほとんどの種類の発見（代表団の毎日のスキャンなど）は、代表団のNS RRSetに直接基づいています。この場合、これらのNS名は、シグナリングレコードをクエリするためにブートストラップアルゴリズム（セクション4.2）とのように使用できます。
Some discovery methods, however, do not imply reliable knowledge of the delegation's NS RRset. For example, when discovering signaling names by performing an NSEC walk or zone transfer of a signaling zone, the parental agent MUST NOT assume that a nameserver under whose signaling domain a signaling record appears is actually authoritative for the corresponding child.
ただし、一部の発見方法は、代表団のNS RRSetの信頼できる知識を意味するものではありません。たとえば、信号ゾーンのNSECウォークまたはゾーン転送を実行してシグナリング名を発見する場合、親のエージェントは、シグナリングドメインがシグナリングレコードが表示される名前サーバーが実際に対応する子供にとって権威あると想定してはなりません。
Instead, whenever a list of "bootstrappable domains" is obtained by means other than directly from the parent, the parental agent MUST ascertain that the delegation actually contains the nameserver hostname seen during discovery, and ensure that signaling-record queries are only made against the proper set of nameservers as listed in the child's delegation from the parent.
代わりに、「ブートストラップ可能なドメイン」のリストが親から直接以外の手段によって取得されるときはいつでも、親のエージェントは、委任が実際に発見中に見られる名前サーバーのホスト名を含んでいることを確認する必要があり、シグナリング記録のクエリがのみ行われることを保証する必要があります。親からの子供の代表団にリストされている適切な名前のセット。
As a consequence of Step 3 in Section 4.2, DS bootstrapping does not work for fully in-domain delegations, as no preexisting chain of trust to the child domain is available during bootstrapping. (As a workaround, one can add an out-of-domain nameserver to the initial NS RRset and remove it once bootstrapping is completed. Automation for this is available via CSYNC records, see [RFC7477].)
セクション4.2のステップ3の結果として、DSブートストラップは、ブートストラップ中に子ドメインへの既存の信頼チェーンは利用できないため、完全にドメイン内の委任では機能しません。（回避策として、初期のNS RRSetにドメイン外の名前サーバーを追加し、ブートストラップが完了したら削除できます。これの自動化はCSYNCレコードを介して利用できます。[RFC7477]を参照してください。）
Fully qualified signaling names must by valid DNS names. Label count and length requirements for DNS names (Section 3.1 of [RFC1035]) imply that the protocol does not work for unusually long child domain names or NS hostnames.
完全に適格なシグナリング名は、有効なDNS名によって必要です。DNS名のラベルカウントと長さの要件（[RFC1035]のセクション3.1）は、プロトコルが異常に長い子供ドメイン名またはNSホスト名で機能しないことを意味します。
It is possible to add CDS/CDNSKEY records and corresponding signaling records to a zone without the domain owner's explicit knowledge. To spare domain owners from being caught off guard by the ensuing DS changes, child DNS operators following this practice are advised to make that transparent, such as by informing the domain owner during zone creation (e.g., in a GUI) or by notifying them via email.
ドメイン所有者の明示的な知識なしに、CDS/CDNSKEYレコードと対応するシグナリングレコードをゾーンに追加することができます。ドメインの所有者がその後のDSの変更に不意を突かれるようにするために、このプラクティスに従って、ゾーンの作成中にドメインの所有者に通知するなど、その透明にすることをお勧めします。Eメール。
When transferring a zone to another DNS operator, the old and new child DNS operators need to cooperate to achieve a smooth transition, e.g., by using the multi-signer protocols described in [RFC8901]. If all else fails, the domain owner might have to request the removal of all DS records and have the transfer performed insecurely (see [INSEC]).
ゾーンを別のDNSオペレーターに転送する場合、古い子および新しい子のDNSオペレーターは、[RFC8901]で説明されているマルチシグナープロトコルを使用して、スムーズな遷移を達成するために協力する必要があります。他のすべてが失敗した場合、ドメインの所有者はすべてのDSレコードの削除を要求し、転送を不安定に実行する必要がある場合があります（[INSEC]を参照）。
Signaling domains SHOULD be delegated as standalone zones, so that the signaling zone's apex coincides with the signaling domain (such as _signal.ns1.example.net). While it is permissible for the signaling domain to be contained in a signaling zone of fewer labels (such as example.net), a zone cut ensures that bootstrapping activities do not require modifications of the zone containing the nameserver hostname.
シグナリングドメインは、シグナリングゾーンの頂点が信号ドメイン（_signal.ns1.example.netなど）と一致するように、スタンドアロンゾーンとして委任する必要があります。シグナリングドメインがより少ないラベル（Example.netなど）のシグナルゾーンに含まれることは許可されますが、ゾーンカットは、ブートストラップアクティビティに名前サーバーのホスト名を含むゾーンの変更を必要としないことを保証します。
Once a child DNS operator determines that specific signaling record sets have been processed (e.g., by seeing the result in the parent zone), they are advised to remove them. This will reduce the size of the signaling zone and facilitate more efficient bulk processing (such as via zone transfers).
子供のDNSオペレーターが、特定のシグナリングレコードセットが処理されたと判断したら（例えば、親ゾーンで結果を確認することにより）、それらを削除することをお勧めします。これにより、信号ゾーンのサイズが縮小され、より効率的なバルク処理が容易になります（ゾーン転送など）。
In order to ensure timely DNSSEC bootstrapping of insecure domains, stalemate situations due to mismatch of stale cached records (Step 4 of Section 4.2) need to be avoided. It is thus RECOMMENDED that queries into signaling domains be performed with an (initially) empty resolver cache, or that some other method for retrieving fresh data from authoritative servers be used.
安全でないドメインのタイムリーなDNSECブートストラップを確保するには、古いキャッシュされた記録の不一致（セクション4.2のステップ4）の不一致による膠着状態の状況を避ける必要があります。したがって、シグナリングドメインへのクエリを（最初に）空のリゾルバーキャッシュで実行するか、権威あるサーバーから新鮮なデータを取得する他の方法を使用することをお勧めします。
It is also RECOMMENDED that QNAME minimization [RFC9156] be used when resolving queries for signaling records to guard against certain attacks (see Section 6).
また、特定の攻撃を防ぐためにシグナリングレコードのクエリを解決するときにQName最小化[RFC9156]を使用することをお勧めします（セクション6を参照）。
The DNSSEC bootstrapping method introduced in this document is based on the approaches described in Section 3 of [RFC8078], but adds authentication to the CDS/CDNSKEY concept. Its security level is therefore strictly higher than that of existing approaches described in that document (e.g., "Accept after Delay"). Apart from this general improvement, the same Security Considerations apply as in [RFC8078].
このドキュメントで導入されたDNSSECブートストラップ方法は、[RFC8078]のセクション3で説明されているアプローチに基づいていますが、CDS/CDNSKEYコンセプトに認証を追加します。したがって、そのセキュリティレベルは、そのドキュメントで説明されている既存のアプローチのセキュリティレベルよりも厳密に高くなっています（たとえば、「遅延後に受け入れる」）。この一般的な改善とは別に、[RFC8078]と同じセキュリティ上の考慮事項が適用されます。
The level of rigor in Section 4.2 is needed to prevent publication of an ill-conceived DS RRset (authorized only under a subset of NS hostnames). This ensures, for example, that an operator in a multi-homed setup cannot enable DNSSEC unless all other operators agree.
セクション4.2の厳密さのレベルは、不適切なDS RRSetの公開を防ぐために必要です（NSホスト名のサブセットの下でのみ許可）。これにより、たとえば、マルチホームのセットアップのオペレーターが、他のすべてのオペレーターが同意しない限りDNSSECを有効にできないことが保証されます。
In any case, as the child DNS operator has authoritative knowledge of the child's CDS/CDNSKEY records, it can readily detect fraudulent provisioning of DS records.
いずれにせよ、子供のDNSオペレーターは子供のCDS/CDNSKEYレコードに関する権威ある知識を持っているため、DSレコードの不正なプロビジョニングを容易に検出できます。
In order to prevent the parents of nameserver hostnames from becoming a single point of failure for a delegation (both in terms of resolution availability and for the trust model of this protocol), diversifying the path from the root to the child's nameserver hostnames is advisable. For example, different and independently operated TLDs may be used for each one.
名前サーバーの両親が代表団（解像度の可用性とこのプロトコルの信頼モデルの両方で）の単一の失敗ポイントになるのを防ぐために、ルートから子供の名前サーバーへのパスを多様化することをお勧めします。たとえば、それぞれに異なる独立したTLDを使用できます。
If QNAME minimization [RFC9156] is not used when querying for signaling records, an upstream parent of a signaling domain will see those CDS/CDNSKEY queries and could respond with an authoritative answer signed with its own key, instead of sending the referral. Enabling QNAME minimization reduces the attack surface for such forgery.
QNAME最小化[RFC9156]がシグナリングレコードをクエリするときに使用されない場合、シグナリングドメインの上流の親はそれらのCD/CDNSKEYクエリを表示し、紹介を送信する代わりに独自のキーで署名した権威ある回答で応答することができます。QNameの最小化を有効にすると、そのような偽造の攻撃面が削減されます。
IANA has added the following entries to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]:
IANAは、次のエントリを「強調されたグローバルでスコープされたDNSノード名」レジストリ[RFC8552]に追加しました。
+=========+============+===========+
| RR Type | _NODE NAME | Reference |
+=========+============+===========+
| CDS | _signal | RFC 9615 |
+---------+------------+-----------+
| CDNSKEY | _signal | RFC 9615 |
+---------+------------+-----------+
Table 1
[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>.
[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>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
Name Minimisation to Improve Privacy", RFC 9156,
DOI 10.17487/RFC9156, November 2021,
<https://www.rfc-editor.org/info/rfc9156>.
[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>.
[BCP237] Best Current Practice 237,
<https://www.rfc-editor.org/info/bcp237>.
At the time of writing, this BCP comprises the following:
Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[INSEC] Hardaker, W., "Intentionally Temporarily Degraded or
Insecure", Work in Progress, Internet-Draft, draft-
hardaker-dnsop-intentionally-temporary-insec-01, 21
October 2021, <https://datatracker.ietf.org/doc/html/
draft-hardaker-dnsop-intentionally-temporary-insec-01>.
[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>.
Thanks to Brian Dickson, Ondřej Caletka, John R. Levine, Christian Elmerot, Oli Schacher, Donald Eastlake, Libor Peltan, Warren Kumari, Scott Rose, Linda Dunbar, Tim Wicinski, Paul Wouters, Paul Hoffman, Peter Yee, Benson Muite, Roman Danyliw, Éric Vyncke, and Joe Abley for reviewing draft proposals and offering comments and suggestions.
ブライアン・ディクソン、オンドル・カレットカ、ジョン・R・レヴァイン、クリスチャン・エルメロット、オリ・シャッハー、ドナルド・イーストレイク、リボール・ペルタン、ウォーレン・クマリ、スコット・ローズ、リンダ・ダンバー、ティム・ウィシンスキー、ポール・ウェーターズ、ポール・ホフマン、ピーター・イー、ベンソン・ムイト、ベンソン・ムイトドラフトの提案をレビューし、コメントや提案を提供してくれたDanyliw、éricVyncke、およびJoe Abley。
Thanks also to Steve Crocker, Hugo Salgado, and Ulrich Wisser for early-stage brainstorming.
スティーブクロッカー、ヒューゴサルガド、ウルリッヒウィザーにも、初期段階のブレーンストーミングに感謝します。
Peter Thomassen
deSEC, Secure Systems Engineering (SSE)
Berlin
Germany
Email: peter@desec.io
Nils Wisiol
deSEC, Technische Universität Berlin
Berlin
Germany
Email: nils@desec.io