[要約] RFC 8901は、DNSSEC（Domain Name System Security Extensions）の実装において、複数の署名者が関与するモデルを定義しています。この文書の目的は、DNSSECが提供するセキュリティ機能を強化し、管理の柔軟性を高めるために、複数のエンティティがDNSゾーンの署名責任を共有できるようにすることです。利用場面としては、複数の組織が共同でDNSゾーンを管理する場合や、セキュリティの冗長性を高めたい場合などが挙げられます。関連するRFCには、DNSSECの基本を定義するRFC 4033、RFC 4034、RFC 4035などがあります。
Internet Engineering Task Force (IETF) S. Huque
Request for Comments: 8901 P. Aras
Category: Informational Salesforce
ISSN: 2070-1721 J. Dickinson
Sinodun IT
J. Vcelak
NS1
D. Blacka
Verisign
September 2020
Multi-Signer DNSSEC Models
マルチ署名者DNSSECモデル
Abstract
概要
Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describes these key-management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations.
今日の多くの企業は、信頼できるDNSサービスを配布するために複数のDNSプロバイダのサービスを採用しています。このような環境でDNSSECを展開すると、使用中の設定や機能に応じて、いくつかの課題が発生する可能性があります。特に、各DNSプロバイダが独立してゾーンデータを独自のキーで署名すると、追加の鍵管理メカニズムが必要です。この文書はこのシナリオに対応する展開モデルを提示し、これらの鍵管理要件を説明しています。これらのモデルは、リゾルバを検証する動作に対する変更を必要としません。また、マルチ署名者構成に関与していない権限のあるサーバーに新しい鍵管理要件を課します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。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/rfc8901.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8901で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction and Motivation 2. Deployment Models 2.1. Multiple-Signer Models 2.1.1. Model 1: Common KSK Set, Unique ZSK Set per Provider 2.1.2. Model 2: Unique KSK Set and ZSK Set per Provider 3. Validating Resolver Behavior 4. Signing-Algorithm Considerations 5. Authenticated-Denial Considerations 5.1. Single Method 5.2. Mixing Methods 6. Key Rollover Considerations 6.1. Model 1: Common KSK, Unique ZSK per Provider 6.2. Model 2: Unique KSK and ZSK per Provider 7. Using Combined Signing Keys 8. Use of CDS and CDNSKEY 9. Key-Management-Mechanism Requirements 10. DNS Response-Size Considerations 11. IANA Considerations 12. Security Considerations 13. References 13.1. Normative References 13.2. Informative References Acknowledgments Authors' Addresses
1. 紹介と動機2.展開モデル2.1。複数署名モデル2.1.1。モデル1：一般的なKSKセット、プロバイダごとのユニークなZSKセット2.1.2。モデル2：プロバイダごとのユニークなKSKセットとZSKセット3.リゾルバの動作の検証4.署名アルゴリズムの考慮事項5.認証拒否の考慮事項5.1。単一方法5.2。ミキシングメソッド6.キーロールオーバーの考慮事項6.1。モデル1：一般的なKSK、プロバイダごとの固有のZSK 6.2。モデル2：プロバイダごとのユニークなKSKとZSK 7.複合署名キーを使用する8. CDとCDNSKeyの使用9.鍵管理メカニズムの要件10. DNS応答サイズの考慮事項11. IANAの考慮事項12.セキュリティ上の考慮事項13.1。規範的参考文献13.2。有益な参照承認著者の住所
Many enterprises today employ the service of multiple Domain Name System (DNS) [RFC1034] [RFC1035] providers to distribute their authoritative DNS service. This is primarily done for redundancy and availability, and it allows the DNS service to survive a complete, catastrophic failure of any single provider. Additionally, enterprises or providers occasionally have requirements that preclude standard zone-transfer techniques [RFC1995][RFC5936]: either nonstandardized DNS features are in use that are incompatible with zone transfer, or operationally a provider must be able to (re-)sign DNS records using their own keys. This document outlines some possible models of DNSSEC [RFC4033] [RFC4034] [RFC4035] deployment in such an environment.
今日の多くの企業は、複数ドメインネームシステム（DNS）[RFC1034] [RFC1034]プロバイダのサービスを採用して、信頼できるDNSサービスを配布します。これは主に冗長性と可用性のために行われており、DNSサービスは単一のプロバイダの完全で壊滅的な障害を生き残ることができます。さらに、企業またはプロバイダには、標準ゾーン転送技術を排除する要件がある場合があります[RFC1995] [RFC1995] [RFC5936]：ゾーン転送と互換性がない、または実行中のプロバイダがDNSに（再）行っている必要があります。独自のキーを使用してレコード。この文書では、DNSSEC [RFC4033] [RFC4034] [RFC4034] [RFC4035]の展開のいくつかの可能性が概説されています。
This document assumes a reasonable level of familiarity with DNS operations and protocol terms. Much of the terminology is explained in further detail in "DNS Terminology" [RFC8499].
この文書は、DNS操作とプロトコルの用語に合理的なレベルの精巧さを想定しています。用語の多くは「DNS用語」[RFC8499]でさらに詳細に説明されています。
If a zone owner can use standard zone-transfer techniques, then the presence of multiple providers does not require modifications to the normal deployment models. In these deployments, there is a single signing entity (which may be the zone owner, one of the providers, or a separate entity), while the providers act as secondary authoritative servers for the zone.
ゾーンの所有者が標準ゾーン転送技術を使用できる場合、複数のプロバイダの存在は通常の展開モデルに対する変更を必要としません。これらの展開では、プロバイダはゾーンのセカンダリ権限のサーバーとして機能しますが、ゾーンの所有者、プロバイダの1つ、または別のエンティティである可能性があります。
Occasionally, however, standard zone-transfer techniques cannot be used. This could be due to the use of nonstandard DNS features or the operational requirements of a given provider (e.g., a provider that only supports "online signing"). In these scenarios, the multiple providers each act like primary servers, independently signing data received from the zone owner and serving it to DNS queriers. This configuration presents some novel challenges and requirements.
ただし、標準ゾーン転送技術を使用できません。これは、標準的なDNS機能または特定のプロバイダの動作要件（例えば、「オンライン署名」をサポートするプロバイダ）の使用によるものである可能性がある。これらのシナリオでは、複数のプロバイダはそれぞれプライマリサーバのように機能し、ゾーンの所有者から受信したデータに独立して署名し、それをDNSクエリアに提供する。この構成はいくつかの新規な課題と要求を提示します。
In this category of models, multiple providers each independently sign and serve the same zone. The zone owner typically uses provider-specific APIs to update zone content identically at each of the providers and relies on the provider to perform signing of the data. A key requirement here is to manage the contents of the DNSKEY and Delegation Signer (DS) RRsets in such a way that validating resolvers always have a viable path to authenticate the DNSSEC signature chain, no matter which provider is queried. This requirement is achieved by having each provider import the public Zone Signing Keys (ZSKs) of all other providers into their DNSKEY RRsets.
モデルのこのカテゴリでは、それぞれ独立して複数のプロバイダが署名して同じゾーンにサービスを提供します。ゾーンの所有者は通常、プロバイダ固有のAPIを使用して各プロバイダでゾーンコンテンツを同じように更新し、プロバイダに依存してデータの署名を実行します。ここでの重要な要件は、リゾルバが常にDNSSECシグネチャチェーンを認証するための実行可能なパスを常に認証するように、DNSKEYおよび委任署名者（DS）RRSETの内容を管理することです。この要件は、各プロバイダを他のすべてのプロバイダのPublic Zone署名キー（ZSK）をDNSKey RRSETにインポートすることで実現されます。
These models can support DNSSEC even for the nonstandard features mentioned previously, if the DNS providers have the capability of signing the response data generated by those features. Since these responses are often generated dynamically at query time, one method is for the provider to perform online signing (also known as on-the-fly signing). However, another possible approach is to precompute all the possible response sets and associated signatures and then algorithmically determine at query time which response set and signature need to be returned.
これらのモデルは、以前に言及されていない標準機能に対してもDNSSECをサポートできます.DNSプロバイダーがこれらの機能によって生成された応答データに署名する機能を持っている場合。これらの応答はクエリ時に動的に生成されることが多いので、プロバイダがオンライン署名を実行するための1つの方法は（オンザフライ署名とも呼ばれる）。しかしながら、他の可能なアプローチは、可能なすべての応答セットおよび関連するシグネチャを事前に予測し、次に応答セットおよびシグネチャを返す必要があるクエリ時間でアルゴリズム的に決定することである。
In the models presented, the function of coordinating the DNSKEY or DS RRset does not involve the providers communicating directly with each other. Feedback from several commercial managed-DNS providers indicates that they may be unlikely to directly communicate, since they typically have a contractual relationship only with the zone owner. However, if the parties involved are agreeable, it may be possible to devise a protocol mechanism by which the providers directly communicate to share keys. Details of such a protocol are deferred to a future specification document, should there be interest.
提示されたモデルでは、DNSKEYまたはDS RRSetを調整する機能は、プロバイダが互いに直接通信することを含まない。いくつかの市販の管理対象DNSプロバイダからのフィードバックは、通常、ゾーンの所有者とのみ契約上の関係を持つので、それらが直接通信することはほとんどないかもしれないことを示しています。しかしながら、関与する当事者が賛成である場合、プロバイダがキーを共有するために直接通信するプロトコルメカニズムを考案することが可能であり得る。そのようなプロトコルの詳細は将来の仕様書に延期され、興味があるべきである。
In the descriptions below, the Key Signing Key (KSK) and Zone Signing Key (ZSK) correspond to the definitions in [RFC8499], with the caveat that the KSK not only signs the zone apex DNSKEY RRset but also serves as the Secure Entry Point (SEP) into the zone.
以下の説明では、キー署名キー（KSK）とゾーン署名キー（ZSK）は[RFC8499]の定義に対応し、KSKはゾーンApex DNSKey RRセットだけでなくセキュアエントリポイントとしても機能します。ゾーンに（SEP）。
* The zone owner holds the KSK set, manages the DS record set, and is responsible for signing the DNSKEY RRset and distributing it to the providers.
* ゾーンの所有者はKSKセットを保持し、DSレコードセットを管理し、DNSKey RRSetに署名してプロバイダに配布する責任があります。
* Each provider has their own ZSK set, which is used to sign data in the zone.
* 各プロバイダには独自のZSKセットがあり、ゾーン内のデータに署名するために使用されます。
* The providers have an API that the zone owner uses to query the ZSK public keys and insert a combined DNSKEY RRset that includes the ZSK sets of each provider and the KSK set, signed by the KSK.
* プロバイダは、ゾーンの所有者がZSK公開鍵を問い合わせるために使用し、各プロバイダのZSKセットとKSKセットを含む複合DNSKey RRSetを挿入し、KSKによって署名されたAPIを挿入します。
* Note that even if the contents of the DNSKEY RRset do not change, the zone owner needs to periodically re-sign it as signature expiration approaches. The provider API is also used to thus periodically redistribute the refreshed DNSKEY RRset.
* DNSKey RRSetの内容が変わらない場合でも、ゾーンの所有者は定期的にそれをシグネチャの有効期限アプローチとして再署名する必要があります。プロバイダAPIは、更新されたDNSKey RRSetを定期的に再配布するためにも使用されます。
* Key rollovers need coordinated participation of the zone owner to update the DNSKEY RRset (for KSK or ZSK) and the DS RRset (for KSK).
* キーロールオーバーは、DNSKey RRSet（KSKまたはZSK用）とDS RRSet（KSK用）を更新するためのゾーン所有者の協調参加を必要とします。
* (One specific variant of this model that may be interesting is a configuration in which there is only a single provider. A possible use case for this is where the zone owner wants to outsource the signing and operation of their DNS zone to a single third-party provider but still control the KSK, so that they can authorize and/or revoke the use of specific zone signing keys.)
* （面白いかもしれないこのモデルの1つの特定の変形は、単一のプロバイダーだけがある構成です。このための可能なケースは、ゾーンの所有者がDNSゾーンの署名と操作を単一の3番目にアウトソーシングしたいと考えています。パーティープロバイダーがKSKを制御しているが、特定のゾーン署名キーの使用を承認および/または取り消すことができるように。）
* Each provider has their own KSK and ZSK sets.
* 各プロバイダは独自のKSKとZSKセットを持っています。
* Each provider offers an API that the zone owner uses to import the ZSK sets of the other providers into their DNSKEY RRset.
* 各プロバイダは、ゾーンの所有者が他のプロバイダのZSKセットをDNSKey RRSetにインポートするために使用するAPIを提供します。
* The DNSKEY RRset is signed independently by each provider using their own KSK.
* DNSKEY RRSetは、各プロバイダによって独自のKSKを使用して独立して署名されています。
* The zone owner manages the DS RRset located in the parent zone. This is comprised of DS records corresponding to the KSKs of each provider.
* ゾーン所有者は、親ゾーンにあるDS RRSetを管理します。これは各プロバイダのKSKに対応するDSレコードで構成されています。
* Key rollovers need coordinated participation of the zone owner to update the DS RRset (for KSK) and the DNSKEY RRset (for ZSK).
* キーロールオーバーは、DS RRSet（KSK用）とDNSKey RRSet（ZSK用）を更新するために、ゾーン所有者の協調参加を必要とします。
The central requirement for both of the multiple-signer models (Section 2.1) is to ensure that the ZSKs from all providers are present in each provider's apex DNSKEY RRset and vouched for by either the single KSK (in Model 1) or each provider's KSK (in Model 2.) If this is not done, the following situation can arise (assuming two providers, A and B):
複数署名モデル（セクション2.1）の両方の中心的な要件は、すべてのプロバイダーからのZSKが各プロバイダーのApex DNSKey RRSetに存在し、単一のKSK（モデル1）または各プロバイダーのKSKのいずれかで贈られていることを確認することです。モデル2では、これが行われていない場合は、次のような状況が発生する可能性があります（2つのプロバイダ、AとB）。
* The validating resolver follows a referral (i.e., secure delegation) to the zone in question.
* 検証リゾルバは、問題のゾーンへの紹介（すなわち安全な委任）に従います。
* It retrieves the zone's DNSKEY RRset from one of Provider A's nameservers, authenticates it against the parent DS RRset, and caches it.
* それはプロバイダAのネームサーバからゾーンのDNSKEY RRSetを取得し、それを親DS RRSetに対して認証し、それをキャッシュします。
* At some point in time, the resolver attempts to resolve a name in the zone while the DNSKEY RRset received from Provider A is still viable in its cache.
* ある時点で、リゾルバはゾーン内の名前を解決しようとします。プロバイダAから受信したDNSKey RRSetはまだそのキャッシュで実行可能です。
* It queries one of Provider B's nameservers to resolve the name and obtains a response that is signed by Provider B's ZSK, which it cannot authenticate because this ZSK is not present in its cached DNSKEY RRset for the zone that it received from Provider A.
* プロバイダBのネームサーバーの1人の名前を照会して名前を解決し、プロバイダーBのZSKによって署名されているレスポンスを取得します。これは、プロバイダーAから受信したゾーンのキャッシュされたDNSKEY RRSETに存在しないため、認証できません。
* The resolver will not accept this response. It may still be able to ultimately authenticate the name by querying other nameservers for the zone until it elicits a response from one of Provider A's nameservers. But it has incurred the penalty of additional round trips with other nameservers, with the corresponding latency and processing costs. The exact number of additional round trips depends on details of the resolver's nameserver-selection algorithm and the number of nameservers configured at Provider B.
* リゾルバはこの応答を受け入れません。プロバイダーAのネームサーバーからの応答を引き起こすまで、ゾーンの他のネームサーバーを照会することで、最終的に名前を認証できる可能性があります。しかし、それは他のネームサーバーとの追加の往復のペナルティを受けています。追加の往復の正確な数は、リゾルバのネームサーバ選択アルゴリズムの詳細とプロバイダBで構成されたネームサーバの数によって異なります。
* It may also be the case that a resolver is unable to provide an authenticated response, because it gave up after a certain number of retries or a certain amount of delay; or it is possible that downstream clients of the resolver that originated the query timed out waiting for a response.
* また、レゾルバが認証された応答を提供できない場合でも、一定数の再試行や一定量の遅延の後にあきらめたためです。あるいは、クエリに発生したリゾルバのダウンストリームクライアントが、応答を待っていました。
Hence, it is important that the DNSKEY RRset at each provider is maintained with the active ZSKs of all participating providers. This ensures that resolvers can validate a response no matter which provider's nameservers it came from.
したがって、各プロバイダのDNSKEY RRSETは、参加しているすべてのプロバイダのアクティブなZSKで維持されることが重要です。これにより、リゾルバは、どのプロバイダのネームサーバーからもかかわらず、レスポンスを検証できるようになります。
Details of how the DNSKEY RRset itself is validated differ. In Model 1 (Section 2.1.1), one unique KSK managed by the zone owner signs an identical DNSKEY RRset deployed at each provider, and the signed DS record in the parent zone refers to this KSK. In Model 2 (Section 2.1.2), each provider has a distinct KSK and signs the DNSKEY RRset with it. The zone owner deploys a DS RRset at the parent zone that contains multiple DS records, each referring to a distinct provider's KSK. Hence, it does not matter which provider's nameservers the resolver obtains the DNSKEY RRset from; the signed DS record in each model can authenticate the associated KSK.
DNSKEY RRSET自体を検証する方法の詳細は異なります。モデル1（セクション2.1.1）では、ゾーンの所有者によって管理される1つの固有のKSKは、各プロバイダに展開された同一のDNSKey RRSetをサインし、親ゾーン内の符号付きDSレコードはこのKSKを参照します。モデル2（セクション2.1.2）では、各プロバイダには異なるKSKがあり、DNSKEY RRSETに署名します。ゾーン所有者は、それぞれが異なるプロバイダのKSKを参照する複数のDSレコードを含むDS RRSetを展開します。したがって、リゾルバがどのプロバイダのネームサーバからDNSKEY RRSETを取得したのかは関係ありません。各モデルの符号付きDSレコードは、関連するKSKを認証できます。
DNS providers participating in multi-signer models need to use a common DNSSEC signing algorithm (or a common set of algorithms if several are in use). This is because the current specifications require that if there are multiple algorithms in the DNSKEY RRset, then RRsets in the zone need to be signed with at least one DNSKEY of each algorithm, as described in [RFC4035], Section 2.2. If providers employ distinct signing algorithms, then this requirement cannot be satisfied.
多署名モデルに参加しているDNSプロバイダは、共通のDNSSEC署名アルゴリズム（または複数の場合は一般的なアルゴリズムのセット）を使用する必要があります。これは、DNSKEY RRSETに複数のアルゴリズムがある場合、[RFC4035]、セクション2.2で説明されているように、ゾーン内のRRSETを各アルゴリズムの少なくとも1つのDNSKEYで符号に署名する必要があるためです。プロバイダが明確な署名アルゴリズムを使用している場合、この要件を満たすことはできません。
Authenticated denial of existence enables a resolver to validate that a record does not exist. For this purpose, an authoritative server presents, in a response to the resolver, signed NSEC (Section 3.1.3 of [RFC4035]) or NSEC3 (Section 7.2 of [RFC5155]) records that provide cryptographic proof of this nonexistence. The NSEC3 method enhances NSEC by providing opt-out for signing insecure delegations and also adds limited protection against zone-enumeration attacks.
認証された存在拒否を使用すると、レコードが存在しないことをリゾルバが検証できます。この目的のために、信頼できるサーバーは、レゾルバに対する応答で、この存在しない暗号化の証明を提供する、NSEC（RFC4035]のセクション3.1.3）またはNSEC3（[RFC5155]のセクション7.2）レコードに署名しました。NSEC3メソッドは、不安定な委任を署名するためのオプトアウトを提供することによってNSECを強化し、ゾーン列挙型攻撃に対して制限された保護を追加します。
An authoritative server response carrying records for authenticated denial is always self-contained, and the receiving resolver doesn't need to send additional queries to complete the proof of denial. For this reason, no rollover is needed when switching between NSEC and NSEC3 for a signed zone.
認証された拒否のレコードを運ぶ権限のあるサーバーの応答は常に自己完結型であり、受信側のレゾルバーは拒否の証明を完了するために追加のクエリを送信する必要はありません。このため、符号付きゾーンのNSECとNSEC3を切り替えるときは、ロールオーバーは必要ありません。
Since authenticated-denial responses are self-contained, NSEC and NSEC3 can be used by different providers to serve the same zone. Doing so, however, defeats the protection against zone enumeration provided by NSEC3 (because an adversary can trivially enumerate the zone by just querying the providers that employ NSEC). A better configuration involves multiple providers using different authenticated denial-of-existence mechanisms that all provide zone-enumeration defense, such as precomputed NSEC3, NSEC3 white lies [RFC7129], NSEC black lies [BLACKLIES], etc. Note, however, that having multiple providers offering different authenticated-denial mechanisms may impact how effectively resolvers are able to make use of the caching of negative responses.
認証拒否応答が自己完結型であるため、NSECとNSEC3は同じゾーンを提供するためにさまざまなプロバイダによって使用できます。ただし、NSEC3が提供するゾーン列挙体に対する保護を倒す（敵対者がNSECを採用しているプロバイダに照会するだけで攻撃者が区切りに列挙できるため）。より良い構成では、Precomputed NSEC3、NSEC3ホワイト、NSECブラックが[Blooklies]などのゾーン列挙防御を提供するさまざまな認証拒否存在メカニズムを使用して複数のプロバイダーが含まれます。さまざまな認証拒否メカニズムを提供する複数のプロバイダーは、エフェクトリゾルベースがネガティブレスポンスのキャッシュを利用できるようになる可能性があります。
Usually, the NSEC and NSEC3 methods are used exclusively (i.e., the methods are not used at the same time by different servers). This configuration is preferred, because the behavior is well defined and closest to current operational practice.
通常、NSECおよびNSEC3メソッドは排他的に使用されます（すなわち、メソッドは異なるサーバによって同時に使用されない）。この構成は、行動が明確に定義され、現在の運転慣行に最も近いため好ましい。
Compliant resolvers should be able to validate zone data when different authoritative servers for the same zone respond with different authenticated-denial methods, because this is normally observed when NSEC and NSEC3 are being switched or when NSEC3PARAM is updated.
コンプライアントリゾルバーは、NSECとNSEC3が切り替えられているとき、またはNSEC3PARAMが更新されているときに、同じゾーンの異なる権限サーバーが異なる認証拒否方法で応答すると、ゾーンデータを検証できるはずです。
Resolver software may, however, be designed to handle a single transition between two authenticated denial configurations more optimally than a permanent setup with mixed authenticated-denial methods. This could make caching on the resolver side less efficient, and the authoritative servers may observe a higher number of queries. This aspect should be considered especially in the context of "Aggressive Use of DNSSEC-Validated Cache" [RFC8198].
ただし、リゾルバソフトウェアは、混合認証拒否方法を備えた恒久的な設定よりも最適な2つの認証された拒否構成間の単一の遷移を処理するように設計されている可能性があります。これにより、レゾルバー側にキャッシングが効率的に低下し、信頼できるサーバーはより多数のクエリを守ることができます。この側面は、特に「DNSSEC検証済みキャッシュの積極的な使用」[RFC8198]というコンテキストで考慮されるべきです。
In case all providers cannot be configured with the same authenticated-denial mechanism, it is recommended to limit the distinct configurations to the lowest number feasible.
すべてのプロバイダを同じ認証拒否メカニズムで設定できない場合は、異なる設定を実行可能な最小数に制限することをお勧めします。
Note that NSEC3 configuration on all providers with different NSEC3PARAM values is considered a mixed setup.
NSEC3PARAM値が異なるすべてのプロバイダのNSEC3構成は、混合設定と見なされます。
The multiple-signer (Section 2.1) models introduce some new requirements for DNSSEC key rollovers. Since this process necessarily involves coordinated actions on the part of providers and the zone owner, one reasonable strategy is for the zone owner to initiate key-rollover operations. But other operationally plausible models may also suit, such as a DNS provider initiating a key rollover and signaling their intent to the zone owner in some manner. The mechanism to communicate this intent could be some secure out-of-band channel that has been agreed upon, or the provider could offer an API function that could be periodically polled by the zone owner.
マルチマルチ署名者（セクション2.1）モデルは、DNSSECキーロールオーバーにいくつかの新しい要件を導入します。このプロセスでは、プロバイダーとゾーンの所有者の側で協調的な行動を伴うため、ゾーンの所有者がキーロールオーバー操作を開始するための1つの合理的な戦略です。しかし、他の操作的にもっともらしいモデルは、DNSプロバイダーのように、鍵のロールオーバーを開始し、ゾーンの所有者との意図をいくつかの方法でシグナリングするなどのような適用され得る。この意図を伝えるためのメカニズムは、合意された一部の安全な帯域外のチャネルである可能性があるか、プロバイダはゾーンの所有者によって定期的にポーリングされる可能性があるAPI関数を提供することができます。
For simplicity, the descriptions in this section assume two DNS providers. They also assume that KSK rollovers employ the commonly used Double-Signature KSK rollover method and that ZSK rollovers employ the Pre-Publish ZSK rollover method, as described in detail in [RFC6781]. With minor modifications, they can be easily adapted to other models, such as Double-DS KSK rollover or Double-Signature ZSK rollover, if desired. Key-use timing should follow the recommendations outlined in [RFC6781], but taking into account the additional operations needed by the multi-signer models. For example, "time to propagate data to all the authoritative servers" now includes the time to import the new ZSKs into each provider.
簡単にするために、このセクションの説明は2つのDNSプロバイダを想定しています。また、KSKロールオーバーは、一般的に使用されている二重シグネチャKSKロールオーバー法を採用し、ZSKロールオーバーが[RFC6781]に詳細に記載されているように、PREPURISH ZSKロールオーバー法を採用していると仮定する。軽微な変更では、必要に応じて、ダブルDS KSKロールオーバーまたはダブルシグネチャZSKロールオーバーなどの他のモデルに簡単に適応できます。鍵利用タイミング[RFC6781]で概説した推奨事項に従ってくださいが、マルチ署名者モデルに必要な追加操作を考慮してください。たとえば、「すべての権限サーバーにデータを伝播する時間」には、新しいZSKを各プロバイダにインポートする時間が含まれています。
* Key Signing Key Rollover: In this model, the two managed-DNS providers share a common KSK (public key) in their respective zones, and the zone owner has sole access to the private key portion of the KSK. To initiate the rollover, the zone owner generates a new KSK and obtains the DNSKEY RRset of each DNS provider using their respective APIs. The new KSK is added to each provider's DNSKEY RRset, and the RRset is re-signed with both the new and the old KSK. This new DNSKEY RRset is then transferred to each provider. The zone owner then updates the DS RRset in the parent zone to point to the new KSK and, after the necessary DS record TTL period has expired, proceeds with updating the DNSKEY RRset to remove the old KSK.
* キー署名キーロールオーバー：このモデルでは、2つの管理対象DNSプロバイダはそれぞれのゾーン内の共通のKSK（公開鍵）を共有し、ゾーンの所有者はKSKの秘密鍵部分への唯一のアクセス権を持っています。ロールオーバーを開始するために、ゾーンオーナーは新しいKSKを生成し、それぞれのAPIを使用して各DNSプロバイダのDNSKey RRセットを取得します。新しいKSKが各プロバイダのDNSKey RRSetに追加され、RRSetは新旧のKSKの両方で再署名されます。この新しいDNSKey RRSetは、各プロバイダに転送されます。その後、ゾーンの所有者は親ゾーンのDS RRSetを更新して新しいKSKを指すように、必要なDSレコードTTL期間が期限切れになった後に、古いKSKを削除するためにDNSKey RRSetの更新を進めます。
* Zone Signing Key Rollover: In this model, each DNS provider has separate Zone Signing Keys. Each provider can choose to roll their ZSK independently by coordinating with the zone owner. Provider A would generate a new ZSK and communicate their intent to perform a rollover (note that Provider A cannot immediately insert this new ZSK into their DNSKEY RRset, because the RRset has to be signed by the zone owner). The zone owner obtains the new ZSK from Provider A. It then obtains the current DNSKEY RRset from each provider (including Provider A), inserts the new ZSK into each DNSKEY RRset, re-signs the DNSKEY RRset, and sends it back to each provider for deployment via their respective key-management APIs. Once the necessary time period has elapsed (i.e., all zone data has been re-signed by the new ZSK and propagated to all authoritative servers for the zone, plus the maximum zone-TTL value of any of the data in the zone that has been signed by the old ZSK), Provider A and the zone owner can initiate the next phase of removing the old ZSK and re-signing the resulting new DNSKEY RRset.
* ゾーン署名キーロールオーバー：このモデルでは、各DNSプロバイダには別々のゾーン署名キーがあります。各プロバイダは、ゾーンの所有者との調整によってZSKを独立してロールすることを選択できます。プロバイダAは新しいZSKを生成し、ロールオーバーを実行するために自分の意図を伝えます（プロバイダAがゾーンの所有者によって署名されなければならないため、DNSKey RRSetにすぐにこの新しいZSKをDNSKey RRSetに挿入できません）。ゾーンの所有者はプロバイダAから新しいZSKを取得します。その後、各プロバイダ（プロバイダAを含む）から現在のDNSKey RRSetを取得し、新しいZSKを各DNSKey RRSetに挿入し、DNSKey RRSetを再サインして各プロバイダに送信します。それぞれの鍵管理APIを介した展開のため。必要な期間が経過したら（すなわち、すべてのゾーンデータが新しいZSKによって再署名され、ゾーンのすべての権威あるサーバに伝播され、ゾーン内のすべての権限サーバーに伝播されています。古いZSKによって署名されたプロバイダAとゾーンの所有者は、古いZSKを削除し、結果の新しいDNSKey RRSetに再署名することの次の段階を開始できます。
* Key Signing Key Rollover: In Model 2, each managed-DNS provider has their own KSK. A KSK roll for Provider A does not require any change in the DNSKEY RRset of Provider B but does require co-ordination with the zone owner in order to get the DS record set in the parent zone updated. The KSK roll starts with Provider A generating a new KSK and including it in their DNSKEY RRSet. The DNSKey RRset would then be signed by both the new and old KSK. The new KSK is communicated to the zone owner, after which the zone owner updates the DS RRset to replace the DS record for the old KSK with a DS record for the new KSK. After the necessary DS RRset TTL period has elapsed, the old KSK can be removed from Provider A's DNSKEY RRset.
* キー署名キーロールオーバー：モデル2では、各管理DNSプロバイダには独自のKSKがあります。プロバイダA用のKSKロールは、プロバイダBのDNSKey RRセットに変更を必要としませんが、親ゾーンで設定されたDSレコードを更新したDSレコードを取得するためにゾーン所有者との調整を必要とします。KSKロールは、プロバイダAを開始し、新しいKSKを生成し、それをDNSKEY RRSETに含めて開始します。DNSKey RRSetは、新旧のKSKの両方によって署名されます。新しいKSKはゾーンの所有者に伝達され、その後、ゾーンの所有者がDS RRSetを更新して、古いKSKのDSレコードを新しいKSKのDSレコードに置き換えます。必要なDS RRSET TTL期間が経過した後、古いKSKはプロバイダーAのDNSKEY RRSETから削除できます。
* Zone Signing Key Rollover: In Model 2, each managed-DNS provider has their own ZSK. The ZSK roll for Provider A would start with them generating a new ZSK, including it in their DNSKEY RRset, and re-signing the new DNSKEY RRset with their KSK. The new ZSK of Provider A would then be communicated to the zone owner, who would initiate the process of importing this ZSK into the DNSKEY RRsets of the other providers, using their respective APIs. Before signing zone data with the new ZSK, Provider A should wait for the DNSKEY TTL plus the time to import the ZSK into Provider B, plus the time to propagate the DNSKEY RRset to all authoritative servers of both providers. Once the necessary Pre-Publish key-rollover time periods have elapsed, Provider A and the zone owner can initiate the process of removing the old ZSK from the DNSKEY RRsets of all providers.
* ゾーン署名キーロールオーバー：モデル2では、各管理DNSプロバイダに独自のZSKがあります。プロバイダAのZSKロールは、それらを含む新しいZSKを作成し、それらを含む新しいZSKを生成し、新しいDNSKey RRSetをKSKで再署名します。その後、プロバイダAの新しいZSKは、それぞれのAPIを使用して、このZSKを他のプロバイダのDNSKey RRSetsにインポートするプロセスを開始するプロセスを開始します。新しいZSKを使用してゾーンデータを署名する前に、プロバイダAはDNSKey TTLにProvider BをプロバイダBにインポートする時間と、DNSKey RRSetを両方のプロバイダのすべての権限のあるサーバーに伝播する時間を加えてください。必要な出版事前キーロールオーバー期間が経過したら、プロバイダAとゾーンの所有者は、すべてのプロバイダのDNSKey RRSETSから古いZSKを削除するプロセスを開始できます。
A Combined Signing Key (CSK) is one in which the same key serves the purposes of both being the secure entry point (SEP) key for the zone and signing all the zone data, including the DNSKEY RRset (i.e., there is no KSK/ZSK split).
結合署名キー（CSK）は、同じキーがゾーンのセキュアエントリポイント（SEP）キーである目的との両方の目的を果たし、DNSKEY RRSetを含むすべてのゾーンデータに署名すること（すなわち、KSK /はありません。ZSKスプリット）。
Model 1 is not compatible with CSKs because the zone owner would then hold the sole signing key, and providers would not be able to sign their own zone data.
モデル1はCSKと互換性がありません。ゾーンの所有者は唯一の署名キーを保持し、プロバイダは自分のゾーンデータに署名できないでしょう。
Model 2 can accommodate CSKs without issue. In this case, any or all of the providers could employ a CSK. The DS record in the parent zone would reference the provider's CSK instead of KSK, and the public CSK would need to be imported into the DNSKEY RRsets of all of the other providers. A CSK key rollover for such a provider would involve the following: The provider generates a new CSK, installs the new CSK into the DNSKEY RRset, and signs it with both the old and new CSKs. The new CSK is communicated to the zone owner. The zone owner exports this CSK into the other provider's DNSKEY RRsets and replaces the DS record referencing the old CSK with one referencing the new one in the parent DS RRset. Once all the zone data has been re-signed with the new CSK, the old CSK is removed from the DNSKEY RRset, and the latter is re-signed with only the new CSK. Finally, the old CSK is removed from the DNSKEY RRsets of the other providers.
モデル2は問題なくCSKに対応できます。この場合、プロバイダのいずれかまたはすべてがCSKを採用することができる。親ゾーンのDSレコードは、KSKの代わりにプロバイダーのCSKを参照し、パブリックCSKを他のすべてのプロバイダのDNSKey RRSETSにインポートする必要があります。そのようなプロバイダのためのCSKキーロールオーバーは、次のものを含みます。プロバイダは新しいCSKを生成し、新しいCSKをDNSKey RRSetにインストールし、古いCSKと新しいCSKの両方でサインします。新しいCSKはゾーンの所有者に伝達されます。ゾーンの所有者はこのCSKを他のプロバイダのDNSKey RRSetsにエクスポートし、古いCSKを参照しているDSレコードを親DS RRSetにある新しいCSKを参照します。すべてのゾーンデータが新しいCSKで再署名されたら、古いCSKはDNSKey RRSetから削除され、後者は新しいCSKのみで再署名されます。最後に、古いCSKは他のプロバイダのDNSKey RRSetから削除されます。
CDS and CDNSKEY records [RFC7344][RFC8078] are used to facilitate automated updates of DNSSEC secure-entry-point keys between parent and child zones. Multi-signer DNSSEC configurations can support this, too. In Model 1, CDS/CDNSKEY changes are centralized at the zone owner. However, the zone owner will still need to push down updated signed CDNS/DNSKEY RRsets to the providers via the key-management mechanism. In Model 2, the key-management mechanism needs to support cross-importation of the CDS/CDNSKEY records, so that a common view of the RRset can be constructed at each provider and is visible to the parent zone attempting to update the DS RRset.
CDSとCDNSKEY RECORDS [RFC7344] [RFC8078]は、親ゾーンと子ゾーンの間のDNSSEC SECURE-ENTRY-POINT-POINTキーの自動更新を容易にするために使用されます。マルチ署名者DNSSEC構成もこれをサポートできます。モデル1では、CDS / CDNSKEYの変更がゾーンの所有者で集中管理されています。ただし、ゾーンの所有者は、鍵管理メカニズムを介して更新された署名されたCDNS / DNSKey RRSETをプロバイダに押し下げる必要があります。モデル2では、鍵管理メカニズムはCDS / CDNSKEYレコードのクロスインポートをサポートする必要があるため、RRSetの共通のビューは各プロバイダーで構築でき、DS RRSetを更新しようとしている親ゾーンが表示されます。
Managed-DNS providers typically have their own proprietary zone configuration and data-management APIs, commonly utilizing HTTPS and Representational State Transfer (REST) interfaces. So, rather than outlining a new API for key management here, we describe the specific functions that the provider API needs to support in order to enable the multi-signer models. The zone owner is expected to use these API functions to perform key-management tasks. Other mechanisms that can partly offer these functions, if supported by the providers, include the DNS UPDATE protocol [RFC2136] and Extensible Provisioning Protocol (EPP) [RFC5731].
管理対象DNSプロバイダは通常、独自の独自のゾーン構成およびデータ管理APIを使用しており、一般にHTTPSおよび表現状態転送（REST）インターフェイスを利用しています。したがって、ここでのキー管理のための新しいAPIの概要ではなく、マルチ署名者モデルを有効にするためにプロバイダAPIがサポートする必要がある特定の機能について説明します。ゾーンの所有者は、これらのAPI機能を使用して鍵管理タスクを実行することが期待されています。プロバイダによってサポートされている場合、これらの機能を部分的に提供できるその他のメカニズムは、DNS Update Protocol [RFC2136]とExtensible Provisioning Protocol（EPP）[RFC5731]を含みます。
* The API must offer a way to query the current DNSKEY RRset of the provider.
* APIは、プロバイダの現在のDNSKey RRセットを照会する方法を提供しなければなりません。
* For Model 1, the API must offer a way to import a signed DNSKEY RRset and replace the current one at the provider. Additionally, if CDS/CDNSKEY is supported, the API must also offer a way to import a signed CDS/CDNSKEY RRset.
* モデル1の場合、APIは署名付きDNSKey RRSetをインポートし、プロバイダの現在のものを置き換える方法を提供しなければなりません。さらに、CDS / CDNSKEYがサポートされている場合、APIは署名付きCDS / CDNSKey RRSETをインポートする方法も提供しなければなりません。
* For Model 2, the API must offer a way to import a DNSKEY record from an external provider into the current DNSKEY RRset. Additionally, if CDS/CDNSKEY is supported, the API must offer a mechanism to import individual CDS/CDNSKEY records from an external provider.
* モデル2の場合、APIは外部プロバイダから現在のDNSKey RRSetにDNSKEYレコードをインポートする方法を提供しなければなりません。さらに、CDS / CDNSKEYがサポートされている場合、APIは外部プロバイダーから個々のCDS / CDNSKEYレコードをインポートするためのメカニズムを提供する必要があります。
In Model 2, once initially bootstrapped with each other's zone-signing keys via these API mechanisms, providers could, if desired, periodically query each other's DNSKEY RRsets, authenticate their signatures, and automatically import or withdraw ZSKs in the keyset as key-rollover events happen.
モデル2では、これらのAPIメカニズムを介して互いのゾーン署名キーで最初にブートストラップされると、プロバイダは、必要に応じて、互いのDNSKey RRSetを定期的にクエリし、署名を認証し、キーロールオーバーイベントとしてキーセットでZSKを自動的にインポートまたは削除することができます。起こる。
The multi-signer models result in larger DNSKEY RRsets, so the size of a response to a query for the DNSKEY RRset will be larger. The actual size increase depends on multiple factors: DNSKEY algorithm and keysize choices, the number of providers, whether additional keys are prepublished, how many simultaneous key rollovers are in progress, etc. Newer elliptic-curve algorithms produce keys small enough that the responses will typically be far below the common Internet-path MTU. Thus, operational concerns related to IP fragmentation or truncation and TCP fallback are unlikely to be encountered. In any case, DNS operators need to ensure that they can emit and process large DNS UDP responses when necessary, and a future migration to alternative transports like DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484] may make this topic moot.
マルチ署名者モデルはより大きなDNSKEY RRSETをもたらすので、DNSKey RRSetのクエリに対する応答のサイズは大きくなります。実際のサイズの増加は、複数の要因によって異なります.DNSKEYアルゴリズムとKeySizeの選択肢、プロバイダの数、追加のキーがプレフィュードされているかどうか、追加のキーの回数などが進行中など、回答が十分に小さいキーを生成します。通常、一般的なインターネットパスMTUのはるかに下回る。したがって、IPフラグメンテーションまたは切り捨ておよびTCPフォールバックに関連する動作上の懸念は、遭遇する可能性は低い。いずれにせよ、DNS演算子は、必要に応じて大規模なDNS UDP応答を発行して処理できるようにする必要があり、TLS [RFC7858]または[RFC8484]を介したDNSのDNSのような代替トランスポートへの移行は、このトピックの問題を生じさせる可能性があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
The multi-signer models necessarily involve third-party providers holding the private keys that sign the zone-owner's data. Obviously, this means that the zone owner has decided to place a great deal of trust in these providers. By contrast, the more traditional model in which the zone owner runs a hidden master and uses the zone-transfer protocol with the providers is arguably more secure, because only the zone owner holds the private signing keys, and the third-party providers cannot serve bogus data without detection by validating resolvers.
マルチ署名者モデルには、ゾーンオーナーのデータに署名する秘密鍵を保持しているサードパーティのプロバイダが必然的に含まれます。明らかに、これはゾーンの所有者がこれらのプロバイダに多大な信頼を置くことを決定したことを意味します。対照的に、ゾーンの所有者が隠されたマスターを実行し、プロバイダとのゾーン転送プロトコルを使用する伝統的なモデルは、ゾーンの所有者だけが秘密署名キーを保持し、サードパーティのプロバイダーが役立つことができないため、おそらくより安全です。リゾルバを検証して検出することなくボーバスデータ。
The zone-key import and export APIs required by these models need to be strongly authenticated to prevent tampering of key material by malicious third parties. Many providers today offer REST/HTTPS APIs that utilize a number of client-authentication mechanisms (username/ password, API keys etc) and whose HTTPS layer provides transport security and server authentication. Multifactor authentication could be used to further strengthen security. If DNS protocol mechanisms like UPDATE are being used for key insertion and deletion, they should similarly be strongly authenticated -- e.g., by employing Transaction Signatures (TSIG) [RFC2845]. Key generation and other general security-related operations should follow the guidance specified in [RFC6781].
これらのモデルに必要なゾーンキーのインポートとエクスポートAPIは、悪意のある第三者による重要な資料の改ざんを防ぐために強く認証される必要があります。多くのプロバイダーは、多くのプロバイダーがいくつかのクライアント認証メカニズム（ユーザー名/パスワード、APIキーなど）を利用し、そのHTTPSレイヤがトランスポートセキュリティとサーバー認証を提供するREST / HTTPS APIを提供します。マルチファクタ認証は、セキュリティをさらに強化するために使用できます。UPDATEのようなDNSプロトコルメカニズムが鍵の挿入および削除に使用されている場合、それらは同様に強く認証されるべきである。例えば、トランザクション署名（TSIG）[RFC2845]を使用することによって。キーの生成やその他の一般的なセキュリティ関連の操作は、[RFC6781]で指定されたガイダンスに従います。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https：//www.rfc-editor.org/info/rfc1034>。
[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>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, <https://www.rfc-editor.org/info/rfc2845>.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastleake 3RD、D.、B.Welientton、「DNS（TSIG）の秘密鍵取引認証」、RFC 2845、DOI 10.17487 / RFC2845、2000年5月、<https：//www.rfc-editor.org/info/rfc2845>。
[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>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<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>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張のためのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、<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>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、M.、Massey、D.、およびS. Rose、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、<https://www.rfc-editor.org/info/rfc4035>。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/info/rfc5155>.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R.、およびD. Blocka、 "DNSセキュリティ（DNSSEC）ハッシュ化認証済み存在拒否"、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<https：//www.rfc-editor.org/info/rfc5155>。
[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>.
[RFC6781] Kolkman、O.、Mekking、W.、R.Gieben、「DNSSEC運用慣行、バージョン2」、RFC 6781、DOI 10.17487 / RFC6781、2012年12月、<https：//www.rfc-editor.org/ info / rfc6781>。
[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>.
[RFC7344] kumari、W.、Gudmundsson、O.、およびG. Barwood、 "DNSSEC代理の信頼保全の自動化"、RFC 7344、DOI 10.17487 / RFC7344、2014年9月、<https://www.rfc-editor.org/情報/ RFC7344>。
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017, <https://www.rfc-editor.org/info/rfc8078>.
[RFC8078] Gudmundsson、O.およびP. Wouters、「CDS / CDNSKeyを介したDSレコードの管理」、RFC 8078、DOI 10.17487 / RFC8078、2017年3月、<https：//www.rfc-editor.org/info/ RFC8078>。
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8198]藤原、K。、加藤、A。、およびW.Kumari、「DNSSEC検証キャッシュの積極的な使用」、RFC 8198、DOI 10.17487 / RFC8198、2017年7月、<https：//www.rfc-編集者。ORG / INFO / RFC8198>。
[BLACKLIES] Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of Existence or Black Lies", Work in Progress, Internet-Draft, draft-valsorda-dnsop-black-lies-00, 21 March 2016, <https://tools.ietf.org/html/draft-valsorda-dnsop-black-lies-00>.
[Blooklies] Valsorda、F.およびO.Gudmundsson、「コンパクトDNSSEC存在の存在拒否」、進行中の作業、インターネットドラフト、ドラフトValsorda-DNSop-Black-Lies-00,2016、<HTTPS：//tools.ietf.org/html/draft-valsorda-dnsop-black-lies-00>
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, <https://www.rfc-editor.org/info/rfc1995>.
[RFC1995] ohta、M。、「DNSのインクリメンタルゾーン転送」、RFC 1995、DOI 10.17487 / RFC1995、1996年8月、<https://www.rfc-editor.org/info/rfc1995>。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、ED。、Thomson、S.、Rekhter、Y.、J.Bound、「ドメイン名システム（DNSアップデート）の動的更新（DNSアップデート）」、RFC 2136、DOI 10.17487 / RFC2136、1997年4月<https://www.rfc-editor.org/info/rfc2136>。
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, <https://www.rfc-editor.org/info/rfc5731>.
[RFC5731] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）ドメイン名マッピング」、STD 69、RFC 5731、DOI 10.17487 / RFC5731、2009年8月、<https://www.rfc-editor.org/info/rfc5731>。
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, <https://www.rfc-editor.org/info/rfc5936>.
[RFC5936] Lewis、E.およびA.ホエン、「DNSゾーン転送プロトコル（AXFゾーン転送プロトコル（AXFR）」、RFC 5936、DOI 10.17487 / RFC5936、2010年6月、<https://www.rfc-editor.org/info/ RFC5936>。
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, February 2014, <https://www.rfc-editor.org/info/rfc7129>.
[RFC7129] Gieben、R.およびW.Mekking、「DNSの存在の認証拒否」、RFC 7129、DOI 10.17487 / RFC7129、2014年2月、<https：//www.rfc-editor.org/info/rfc7129>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] HU、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D.、およびP.HOFFMAN、「トランスポート層セキュリティ（TLS）のDNSの仕様（TLS）」、RFC 7858、DOI10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] HOFFMAN、P.およびP.Mcmanus、「HTTPS経由のDNSクエリ（DOH）」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https：//www.rfc-editor.org/info/rfc8484>。
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499] Hoffman、P.、Sullivan、A.、K. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https：//www.rfc-editor.org/情報/ RFC8499>。
Acknowledgments
謝辞
The initial version of this document benefited from discussions with and review from Duane Wessels. Additional helpful comments were provided by Steve Crocker, Ulrich Wisser, Tony Finch, Olafur Gudmundsson, Matthijs Mekking, Daniel Migault, and Ben Kaduk.
この文書の初期版は、デュアーンウェースとの議論と見直しから恩恵を受けました。Steve Crocker、Ulrich Wisser、Tony Finch、Olrich Gudmundsson、Matthijs Mekking、Daniel Migault、Ben Kadukによって追加の役立つコメントが提供されました。
Authors' Addresses
著者の住所
Shumon Huque Salesforce 415 Mission Street, 3rd Floor San Francisco, CA 94105 United States of America
Shuquon Huque Salesforce 415ミッションストリート、サンフランシスコ、カリフォルニア州サンフランシスコ、CA 94105アメリカ合衆国
Email: shuque@gmail.com
Pallavi Aras Salesforce 415 Mission Street, 3rd Floor San Francisco, CA 94105 United States of America
Pallavi Aras Salesforce 415 Mission Street、サンフランシスコ、カリフォルニア州サンフランシスコ、CA 94105アメリカ合衆国
Email: paras@salesforce.com
John Dickinson Sinodun IT Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
John Dickinson Sinodun It Magdalen CenterオックスフォードサイエンスパークオックスフォードOX4 4GAイギリス
Email: jad@sinodun.com
Jan Vcelak NS1 55 Broad Street, 19th Floor New York, NY 10004 United States of America
Jan vcelak NS1 55 Broad Street、19階ニューヨーク、ニューヨーク、ニューヨーク州20004
Email: jvcelak@ns1.com
David Blacka Verisign 12061 Bluemont Way Reston, VA 20190 United States of America
David Blacka Verisign 12061 Bluemont Way Reston、VA 20190アメリカ合衆国
Email: davidb@verisign.com