[要約] RFC 8078は、親からのCDS/CDNSKEYを介したDSレコードの管理に関する標準化された手法を提供します。このRFCの目的は、DNSセキュリティ拡張（DNSSEC）のデプロイメントを容易にし、DSレコードの更新と管理を効率化することです。
Internet Engineering Task Force (IETF) O. Gudmundsson
Request for Comments: 8078 CloudFlare
Updates: 7344 P. Wouters
Category: Standards Track Red Hat
ISSN: 2070-1721 March 2017
Managing DS Records from the Parent via CDS/CDNSKEY
CDS / CDNSKEYを介した親からのDSレコードの管理
Abstract
概要
RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.
RFC 7344は、親と子の間の帯域内の主要なロールオーバー全体でDNS信頼を維持する方法を指定しています。このドキュメントでは、RFC 7344を情報トラックから標準トラックに昇格させています。また、初期の信頼セットアップおよび安全なエントリポイントの削除のためのメソッドも追加します。
Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.
ドメインのDNSSECステータスを変更することは、複数の無関係な関係者が関与する複雑な問題になる可能性があります。 DNSオペレーターなどの一部の関係者は、関係するすべての組織に知られていない場合もあります。インバンドシグナリングを介してDNSSECを無効にできないことは、DNSSECの大規模な採用を妨げる問題または責任と見なされます。このドキュメントでは、これらのDNSSECステータス変更のインバンドシグナリングの方法を追加します。
This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).
このドキュメントでは、新しい安全なエントリポイント（DSレコード）の最初の受け入れの展開を容易にするための合理的なポリシーについて説明します。
It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.
ドメインの移管や移動については、オペレーターが協力することが望ましいです。最良の方法は、鍵署名鍵（KSK）とゾーン署名鍵（ZSK）のロールオーバーを実行することです。それが不可能な場合は、このドキュメントで説明されている署名されていない中間状態を使用する方法を使用して、2つのパーティ間でドメインを移動できます。これにより、ドメインは一時的に署名されず、DNSスプーフィングに対して脆弱になりますが、DSとDNSKEYレコードの不一致による検証エラーの代替策よりも優先されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc8078.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8078で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introducing a DS Record . . . . . . . . . . . . . . . . . 3
1.2. Removing a DS Record . . . . . . . . . . . . . . . . . . 4
1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. The Three Uses of CDS . . . . . . . . . . . . . . . . . . . . 5
2.1. The Meaning of the CDS RRset . . . . . . . . . . . . . . 5
3. Enabling DNSSEC via CDS/CDNSKEY . . . . . . . . . . . . . . . 6
3.1. Accept Policy via Authenticated Channel . . . . . . . . . 6
3.2. Accept with Extra Checks . . . . . . . . . . . . . . . . 6
3.3. Accept after Delay . . . . . . . . . . . . . . . . . . . 7
3.4. Accept with Challenge . . . . . . . . . . . . . . . . . . 7
3.5. Accept from Inception . . . . . . . . . . . . . . . . . . 7
4. DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Promoting RFC 7344 to Standards Track . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
CDS (Child DS) and CDNSKEY (Child DNSKEY) [RFC7344] records are used to signal changes in secure entry points. This is one method to maintain delegations that can be used when the DNS operator has no other way to inform the parent that changes are needed. This document elevates [RFC7344] from Informational to Standards Track.
CDS（子DS）およびCDNSKEY（子DNSKEY）[RFC7344]レコードは、安全なエントリポイントの変更を通知するために使用されます。これは、DNSオペレーターが変更が必要であることを親に通知する他の方法がない場合に使用できる委任を維持する1つの方法です。このドキュメントは、[RFC7344]を情報トラックから標準トラックに昇格させます。
In addition, [RFC7344] lacks two different options for full automated operation to be possible. It does not define a method for the initial trust establishment, leaving it open to each parent to come up with an acceptance policy. Additionally, [RFC7344] does not provide a "delete" signal for the child to inform the parent that the DNSSEC security for its domain must be removed.
さらに、[RFC7344]には、完全に自動化された操作を可能にするための2つの異なるオプションがありません。最初の信頼確立の方法は定義されておらず、各親が受け入れポリシーを作成できるようになっています。さらに、[RFC7344]は、そのドメインのDNSSECセキュリティを削除する必要があることを親に通知する「削除」信号を子に提供しません。
Automated insertion of DS records has been limited for many zones by the requirement that all changes pass through a "Registry" of the child zone's parent. This has significantly hindered deployment of DNSSEC at a large scale for DNS hosters, as the child zone owner is often not aware or able to update DNS records such as the DS record.
DSレコードの自動挿入は、すべての変更が子ゾーンの親の「レジストリ」を通過する必要があるため、多くのゾーンで制限されています。子ゾーンの所有者はDSレコードなどのDNSレコードを認識していないか、または更新できないことが多いため、これにより、DNSホスティング業者向けの大規模なDNSSECの展開が大幅に妨げられました。
This document describes a few possible methods for the parent to accept a request by the child to add a DS record to its zone. These methods have different security properties that address different deployment scenarios, all resulting in an automated method of trust introduction.
このドキュメントでは、親が子にDSレコードをゾーンに追加する要求を受け入れるためのいくつかの可能な方法について説明します。これらの方法には、さまざまな展開シナリオに対応するさまざまなセキュリティプロパティがあり、すべて信頼の導入方法が自動化されます。
This document introduces the delete option for both CDS and CDNSKEY, allowing a child to signal to the parent to turn off DNSSEC. When a domain is moved from one DNS operator to another, sometimes it is necessary to turn off DNSSEC to facilitate the change of DNS operator. Common scenarios include:
このドキュメントでは、CDSとCDNSKEYの両方の削除オプションを紹介し、子が親にDNSSECをオフにするように通知できるようにします。ドメインをあるDNSオペレーターから別のDNSオペレーターに移動する場合、DNSオペレーターの変更を容易にするためにDNSSECをオフにする必要がある場合があります。一般的なシナリオは次のとおりです。
1. Alternative to doing a proper DNSSEC algorithm rollover due to operational limitations such as software limitations.
1. ソフトウェアの制限などの運用上の制限により、適切なDNSSECアルゴリズムのロールオーバーを実行する代わりに。
2. Moving from a DNSSEC operator to a non-DNSSEC-capable operator.
2. DNSSECオペレーターから非DNSSEC対応オペレーターへの移行。
3. Moving to an operator that cannot or does not want to do a proper DNSSEC rollover.
3. 適切なDNSSECロールオーバーを実行できない、または実行したくないオペレーターに移動する。
4. When moving between two DNS operators that use disjoint sets of algorithms to sign the zone, an algorithm rollover cannot be performed.
4. 互いに素なアルゴリズムのセットを使用してゾーンに署名する2つのDNSオペレーター間を移動する場合、アルゴリズムのロールオーバーは実行できません。
5. The domain holder no longer wants DNSSEC enabled.
5. ドメインホルダーはDNSSECを有効にする必要がなくなりました。
The lack of a "remove my DNSSEC" option is cited as a reason why some operators cannot deploy DNSSEC, as this is seen as an operational risk.
「DNSSECを削除する」オプションがないことは、運用上のリスクと見なされるため、一部の事業者がDNSSECを導入できない理由として挙げられています。
Turning off DNSSEC reduces the security of the domain and thus should only be done carefully, and that decision should be fully under the child domain's control.
DNSSECをオフにすると、ドメインのセキュリティが低下するため、慎重に行う必要があり、その決定は完全に子ドメインの管理下にある必要があります。
Signaling can happen via CDS or CDNSKEY records. The only differences between the two records are how information is represented and who calculates the DS digest. For clarity, this document uses the term "CDS" to mean "either CDS or CDNSKEY".
シグナリングは、CDSまたはCDNSKEYレコードを介して発生する可能性があります。 2つのレコードの唯一の違いは、情報の表現方法とDSダイジェストの計算者です。明確にするために、このドキュメントでは「CDS」という用語を使用して、「CDSまたはCDNSKEYのいずれか」を意味します。
When this document uses the word "parent", it implies an entity that is authorized to insert DS records into the parent zone on behalf of the child domain. Which entity this exactly is does not matter. It could be the Registrar or Reseller that the child domain was purchased from. It could be the Registry that the domain is registered in when allowed. Or it could be some other entity.
このドキュメントで「親」という単語が使用されている場合、それは、子ドメインに代わってDSレコードを親ゾーンに挿入する権限があるエンティティを意味します。これが正確にどちらのエンティティであるかは重要ではありません。子ドメインの購入元のレジストラーまたはリセラーである可能性があります。許可されている場合、ドメインが登録されているレジストリである可能性があります。または、他のエンティティである可能性もあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In general, there are three operations that a domain wants to instruct its parent to perform:
一般に、ドメインがその親に実行するように指示したい3つの操作があります。
1. Enable DNSSEC validation, i.e., place an initial DS Resource Record Set (RRset) in the parent.
1. DNSSEC検証を有効にします。つまり、最初のDSリソースレコードセット（RRset）を親に配置します。
2. Roll over the KSK. This means updating the DS records in the parent to reflect the new set of KSKs at the child. This could be an ADD operation, a DELETE operation on one or more records while keeping at least one DS RR, or a full REPLACE operation.
2. KSKをロールオーバーします。つまり、親のDSレコードを更新して、子の新しいKSKセットを反映します。これは、ADD操作、少なくとも1つのDS RRを維持しながら1つ以上のレコードに対するDELETE操作、または完全なREPLACE操作にすることができます。
3. Turn off DNSSEC validation, i.e., delete all the DS records.
3. DNSSEC検証をオフにします。つまり、すべてのDSレコードを削除します。
KSK rollover is covered in [RFC7344]. It is considered the safest use case of a CDS/CDNSKEY record as it makes no change to the trust relationship between parent and child. Introduction and removal of DS records are defined in this document. As these CDS/CDNSKEY use cases create or end the trust relationship between the parent and child, these use cases should be carefully implemented and monitored.
KSKロールオーバーは[RFC7344]でカバーされています。親子間の信頼関係に変更を加えないため、CDS / CDNSKEYレコードの最も安全な使用例と見なされます。 DSレコードの導入と削除は、このドキュメントで定義されています。これらのCDS / CDNSKEYユースケースは親子間の信頼関係を作成または終了するため、これらのユースケースは慎重に実装および監視する必要があります。
The semantic meaning of publishing a CDS RRset is interpreted to mean:
CDS RRsetを発行することの意味上の意味は、次のことを意味すると解釈されます。
Publishing a CDS or CDNSKEY record signals to the parent that the child desires that the corresponding DS records be synchronized. Every parent or parental agent should have an acceptance policy of these records for the three different use cases involved: Initial DS publication, Key rollover, and Returning to Insecure.
CDSまたはCDNSKEYレコードを公開すると、対応するDSレコードの同期を子供が望んでいることが親に通知されます。すべての親または親エージェントは、関連する3つの異なるユースケース（初期DS公開、キーロールオーバー、および安全でない状態への復帰）について、これらのレコードの受け入れポリシーを持っている必要があります。
In short, the CDS RRset is an instruction to the parent to modify the DS RRset if the CDS and DS Resets differ.
つまり、CDS RRsetは、CDSとDSのリセットが異なる場合にDS RRsetを変更するように親に指示します。
The acceptance policy for CDS in the rollover case is "seeing" according to [RFC7344]. The acceptance policy in the Delete case is seeing a (validly signed) CDS RRset with the delete operation specified in this document.
[RFC7344]によれば、ロールオーバーの場合のCDSの受け入れポリシーは「シーイング」です。削除ケースの承認ポリシーは、このドキュメントで指定されている削除操作を伴う（有効に署名された）CDS RRsetを確認しています。
There are number of different models for managing initial trust, but in the general case, the child wants to enable global validation. As long as the child is insecure, DNS answers can be forged. The goal is to promote the child from insecure to secure as soon as reasonably possible by the parent. This means that the period from the child's publication of CDS/CDNSKEY RRset to the parent publishing the synchronized DS RRset should be as short as possible.
初期信頼を管理するためのさまざまなモデルがいくつかありますが、一般的なケースでは、子はグローバル検証を有効にしたいと考えています。子供が安全でない限り、DNS回答は偽造できます。目標は、親が合理的に可能な限り早く子供を不安から安全へと促進することです。つまり、CDS / CDNSKEY RRsetの子の公開から、同期されたDS RRsetを公開する親までの期間は、できるだけ短くする必要があります。
One important use case is how a third-party DNS operator can upload its DNSSEC information to the parent, so the parent can publish a DS record for the child. In this case, there is a possibility of setting up some kind of authentication mechanism and submission mechanism that is outside the scope of this document.
重要な使用例の1つは、サードパーティのDNSオペレーターがDNSSEC情報を親にアップロードして、親が子のDSレコードを公開できるようにする方法です。この場合、このドキュメントの範囲外のある種の認証メカニズムと送信メカニズムを設定する可能性があります。
Below are some policies that parents can use. These policies assume that the notifications can be verified or authenticated.
以下は、保護者が使用できるいくつかのポリシーです。これらのポリシーは、通知を検証または認証できることを前提としています。
In this case, the parent is notified via authenticated channel UI/API that a CDS/CDNSKEY RRset exists. In the case of a CDS RRset, the parent retrieves the CDS RRset and inserts the corresponding DS RRset as requested. In the case of CDNSKEY, the parent retrieves the CDNSKEY RRset and calculates the DS record(s). Parents may limit the DS record type based on local policy. Parents SHOULD NOT refuse CDS/ CDNSKEY updates that do not (yet) have a matching DNSKEY in the child zone. This will allow the child to pre-publish a spare (and potentially offline) DNSKEY.
この場合、認証されたチャネルUI / APIを介して、CDS / CDNSKEY RRsetが存在することが親に通知されます。 CDS RRsetの場合、親はCDS RRsetを取得し、要求に応じて対応するDS RRsetを挿入します。 CDNSKEYの場合、親はCDNSKEY RRsetを取得し、DSレコードを計算します。親は、ローカルポリシーに基づいてDSレコードタイプを制限できます。親は、子ゾーンに一致するDNSKEYがない（まだ）CDS / CDNSKEY更新を拒否しないでください。これにより、子供は予備の（そして場合によってはオフラインの）DNSKEYを事前に公開できます。
In this case, the parent checks that the source of the notification is allowed to request the DS insertion. The checks could include whether this is a trusted entity, whether the nameservers correspond to the requester, whether there have been any changes in registration in the last few days, etc. The parent can also send a notification requesting a confirmation, for example, by sending email to the registrant requesting a confirmation. The end result is that the CDS RRset is accepted at the end of the checks or when the out-of-band confirmation is received. Any extra checks should have proper rate limiting in place to prevent abuse.
この場合、親は、通知のソースがDS挿入を要求できるかどうかを確認します。チェックには、これが信頼できるエンティティであるかどうか、ネームサーバーがリクエスタに対応するかどうか、過去数日間に登録に変更があったかどうかなどが含まれます。親は、たとえば、次のように確認を要求する通知を送信することもできます。確認を要求する登録者に電子メールを送信します。最終結果は、CDS RRsetがチェックの終わりに、または帯域外確認が受信されたときに受け入れられます。追加のチェックでは、乱用を防ぐために適切なレート制限を設定する必要があります。
In this case, if the parent deems the request valid, it starts monitoring the CDS RRset at the child nameservers over a period of time to make sure nothing changes. After some time or after a number of checks, preferably from different vantage points in the network, the parent accepts the CDS RRset as a valid signal to update its DS RRset for this child.
この場合、親が要求を有効であると見なすと、親は一定期間にわたって子ネームサーバーでCDS RRsetの監視を開始し、変更がないことを確認します。しばらくして、またはいくつかのチェックの後、できればネットワーク内のさまざまな視点から、親はCDS RRsetを有効な信号として受け入れ、この子のDS RRsetを更新します。
In this case, the parent instructs the requester to insert some record into the child domain to prove it has the ability to do so (i.e., it is the operator of the zone). This method imposes a new task on the parent to monitor the child zone to see if the challenge has been added to the zone. The parent should verify that the challenge is published by all the child's nameservers and should test for this challenge from various diverse network locations to increase the security of this method as much as possible.
この場合、親はリクエスタに子ドメインにレコードを挿入するように指示し、それが可能であることを証明します（つまり、それがゾーンのオペレーターであることを証明します）。このメソッドは、親に新しいタスクを課し、子ゾーンを監視して、チャレンジがゾーンに追加されているかどうかを確認します。親は、チャレンジがすべての子のネームサーバーによって公開されていることを確認し、さまざまなネットワークロケーションからこのチャレンジをテストして、この方法のセキュリティを可能な限り向上させる必要があります。
If a parent is adding a new child domain that is not currently delegated at all, it could use the child CDS/CDNSKEY RRset to immediately publish a DS RRset along with the new NS RRset. This would ensure that the new child domain is never active in an insecure state.
親が現在まったく委任されていない新しい子ドメインを追加する場合、親は子CDS / CDNSKEY RRsetを使用して、新しいNS RRsetと共にDS RRsetをすぐに公開できます。これにより、新しい子ドメインが安全でない状態でアクティブになることがなくなります。
This document defines the previously reserved DNS Security Algorithm Number of value 0 in the context of CDS and CDNSKEY records to mean that the entire DS RRset at the parent must be removed. The value 0 remains reserved for the DS and DNSKEY records.
このドキュメントでは、CDSおよびCDNSKEYレコードのコンテキストで、以前に予約されていた値0のDNSセキュリティアルゴリズム番号を定義して、親のDS RRset全体を削除する必要があることを意味します。値0はDSおよびDNSKEYレコード用に予約されたままです。
No DNSSEC validator can treat algorithm 0 as a valid signature algorithm. If a validator sees a DNSKEY or DS record with this algorithm value, it must treat it as unknown. Accordingly, the zone is treated as unsigned unless there are other algorithms present. In general, the value 0 should never be used in the context of DNSKEY and DS records.
DNSSECバリデーターは、アルゴリズム0を有効な署名アルゴリズムとして扱うことができません。バリデーターがこのアルゴリズム値を持つDNSKEYまたはDSレコードを見つけた場合、それを不明として扱う必要があります。したがって、他のアルゴリズムが存在しない限り、ゾーンは符号なしとして扱われます。一般に、値0はDNSKEYおよびDSレコードのコンテキストでは使用しないでください。
The CERT record [RFC4398] defines the value 0 similarly to mean the algorithm in the CERT record is not defined in DNSSEC.
CERTレコード[RFC4398]は、CERTレコードのアルゴリズムがDNSSECで定義されていないことを意味するのと同様に、値0を定義します。
The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below.
CDSまたはCDNSKEY RRsetの内容には1つのRRが含まれている必要があり、以下に示すように正確なフィールドのみが含まれている必要があります。
CDS 0 0 0 0
CDS 0 0 0 0
CDNSKEY 0 3 0 0
CDNSKEY 0 3 0 0
The keying material payload is represented by a single 0. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed.
鍵素材のペイロードは単一の0で表されます。このレコードは、通常のCDS / CDNSKEY RRsetが署名されるのと同じ方法で署名されます。
Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 0" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2.
厳密に言えば、DNSKEYアルゴリズムだけがDELETE操作を通知するものであるため、CDSレコードは "CDS X 0 X 0"になる可能性がありますが、明確にするために、 "0 0 0 0"表記が必須です-これはDSの定義ではありませんダイジェストアルゴリズム0。同じ引数が "CDNSKEY 0 3 0 0"にも適用されます。 2番目のフィールドの値3は、[RFC4034]のセクション2.1.2で必須です。
Once the parent has verified the CDS/CDNSKEY RRset and it has passed other acceptance tests, the parent MUST remove the DS RRset. After waiting a sufficient amount of time -- depending on the parental TTLs -- the child can start the process of turning off DNSSEC.
親がCDS / CDNSKEY RRsetを確認し、他の受け入れテストに合格したら、親はDS RRsetを削除する必要があります。親のTTLに応じて、十分な時間待機した後、子はDNSSECをオフにするプロセスを開始できます。
Turning off DNSSEC reduces the security of the domain and thus should only be done as a last resort in preventing DNSSEC validation errors due to mismatched DS and DNSKEY records.
DNSSECをオフにすると、ドメインのセキュリティが低下するため、DSとDNSKEYレコードの不一致によるDNSSEC検証エラーを防ぐための最後の手段としてのみ実行してください。
Users should keep in mind that re-establishing trust in delegation can be hard and takes time. Before deciding to complete the rollover via an unsigned state, all other options should be considered first.
ユーザーは、委任に対する信頼を再確立することは困難で時間がかかる場合があることを覚えておく必要があります。署名されていない状態でロールオーバーを完了することを決定する前に、他のすべてのオプションを最初に検討する必要があります。
A parent SHOULD ensure that when it is allowing a child to become securely delegated, it has a reasonable assurance that the CDS/ CDNSKEY RRset used to bootstrap the security is visible from a geographically and topologically diverse view. It SHOULD also ensure that the zone validates correctly if the parent publishes the DS record. A parent zone might also consider sending an email to its contact addresses to give the child zone a warning that security will be enabled after a certain amount of wait time -- thus allowing a child administrator to cancel the request.
親は、子供が安全に委任されることを許可しているときに、セキュリティのブートストラップに使用されるCDS / CDNSKEY RRsetが地理的およびトポロジ的に多様なビューから見えることを合理的に保証する必要があります。また、親がDSレコードを公開する場合、ゾーンが正しく検証されることも保証する必要があります。親ゾーンは、連絡先アドレスに電子メールを送信して、子ゾーンに一定の待機時間後にセキュリティが有効になるという警告を与えることを検討することもできます。これにより、子管理者はリクエストをキャンセルできます。
This document describes a few possible acceptance criteria for the initial trust establishment. Due to a large variety of legal frameworks surrounding parent domains (Top-Level Domain (TLDs) in particular), this document cannot give a definitive list of valid acceptance criteria. Parental zones should look at the listed methods and pick the most secure method possible within their legal and technical scenario, possibly further securing the acceptance criteria, as long as the deployed method still enables a fully automated method for non-direct parties such as third-party DNS hosters.
このドキュメントでは、最初の信頼を確立するためのいくつかの受け入れ基準について説明します。親ドメイン（特にトップレベルドメイン（TLD））を取り巻く法的枠組みは多岐にわたるため、このドキュメントでは有効な承認基準の明確なリストを提供できません。親ゾーンは、リストされたメソッドを確認し、法的および技術的シナリオ内で可能な最も安全なメソッドを選択する必要があります。導入されたメソッドがサードパーティなどの非直接パーティに対して完全に自動化されたメソッドを有効にする限り、おそらく受け入れ基準をさらに保護します。パーティーDNSホスター。
IANA has assigned entry number 0 in the "DNS Security Algorithm Numbers" registry as follows:
IANAは、「DNS Security Algorithm Numbers」レジストリのエントリ番号0を次のように割り当てています。
+--------+--------------+----------+----------+---------+-----------+
| Number | Description | Mnemonic | Zone | Trans. | Reference |
| | | | Signing | Sec. | |
+--------+--------------+----------+----------+---------+-----------+
| 0 | Delete DS | DELETE | N | N | [RFC4034] |
| | | | | | [RFC4398] |
| | | | | | [RFC8078] |
+--------+--------------+----------+----------+---------+-----------+
Experience has shown that CDS and CDNSKEY are useful in the deployment of DNSSEC. [RFC7344] was published as Informational; this document elevates RFC 7344 to Standards Track.
経験上、CDSおよびCDNSKEYはDNSSECの展開に役立つことが示されています。 [RFC7344]は情報として公開されました。このドキュメントは、RFC 7344を規格トラックに昇格させます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[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, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< http://www.rfc-editor.org/info/rfc4034>。
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, <http://www.rfc-editor.org/info/rfc7344>.
[RFC7344] Kumari、W.、Gudmundsson、O。、およびG. Barwood、「Automating DNSSEC Delegation Trust Maintenance」、RFC 7344、DOI 10.17487 / RFC7344、2014年9月、<http://www.rfc-editor.org/ info / rfc7344>。
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, <http://www.rfc-editor.org/info/rfc4398>.
[RFC4398] Josefsson、S.、「証明書のドメインネームシステム（DNS）への保存」、RFC 4398、DOI 10.17487 / RFC4398、2006年3月、<http://www.rfc-editor.org/info/rfc4398>。
Acknowledgments
謝辞
We thank a number of people that have provided feedback and useful comments including Bob Harold, John Levine, Dan York, Shane Kerr, Jacques Latour, and especially Matthijs Mekking.
Bob Harold、John Levine、Dan York、Shane Kerr、Jacques Latour、特にMatthijs Mekkingをはじめ、フィードバックや有益なコメントを提供してくれた多くの人々に感謝します。
Authors' Addresses
著者のアドレス
Olafur Gudmundsson CloudFlare
オラファー・グドムンドソンCloudFlare
Email: olafur+ietf@cloudflare.com
Paul Wouters Red Hat
ポール・ウーターズレッドハット
Email: pwouters@redhat.com