[要約] RFC 9276 は、最近の運用展開経験に基づいて、NSEC3 パラメータの設定に関するガイダンスを提供し、RFC 5155 を更新します。NSEC3 は、ゾーン内の2つのドメイン名の間に存在しない名前がないことを主張することで、存在しないことの証明を提供する DNSSEC メカニズムです。
Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 9276 USC/ISI
BCP: 236 V. Dukhovni
Updates: 5155 Bloomberg, L.P.
Category: Best Current Practice August 2022
ISSN: 2070-1721
Guidance for NSEC3 Parameter Settings
NSEC3パラメーター設定のガイダンス
Abstract
概要
NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that there are no names that exist between two domain names within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. This document updates RFC 5155 with guidance about selecting NSEC3 iteration and salt parameters.
NSEC3は、ゾーン内の2つのドメイン名の間に存在する名前が存在しないと主張することにより、非存在の証明を提供するDNSSECメカニズムです。対応するNSECとは異なり、NSEC3は境界ドメイン名のペアの直接開示を回避します。このドキュメントは、最近の運用展開の経験に基づいて、NSEC3パラメーターの設定に関するガイダンスを提供します。このドキュメントは、NSEC3反復と塩パラメーターの選択に関するガイダンスでRFC 5155を更新します。
Status of This Memo
本文書の位置付け
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPの詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9276.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9276で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Notation
2. NSEC3 Parameter Value Discussions
2.1. Algorithms
2.2. Flags
2.3. Iterations
2.4. Salt
3. Recommendations for Deploying and Validating NSEC3 Records
3.1. Best Practice for Zone Publishers
3.2. Recommendation for Validating Resolvers
3.3. Recommendation for Primary and Secondary Relationships
4. Security Considerations
5. Operational Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Deployment Measurements at Time of Publication
Appendix B. Computational Burdens of Processing NSEC3 Iterations
Acknowledgments
Authors' Addresses
As with NSEC [RFC4035], NSEC3 [RFC5155] provides proof of nonexistence that consists of signed DNS records establishing the nonexistence of a given name or associated Resource Record Type (RRTYPE) in a DNSSEC-signed zone [RFC4035]. However, in the case of NSEC3, the names of valid nodes in the zone are obfuscated through (possibly multiple iterations of) hashing (currently only SHA-1 is in use on the Internet).
NSEC [RFC4035]と同様に、NSEC3 [RFC5155]は、DNSEC-Signedゾーン[RFC4035]で特定の名前または関連するリソースレコードタイプ（RRTYPE）の存在を確立する署名DNSレコードで構成される存在しない存在の証拠を提供します。ただし、NSEC3の場合、ゾーン内の有効なノードの名前は（おそらく複数の反復）ハッシュを介して難読化されています（現在、SHA-1のみがインターネットで使用されています）。
NSEC3 also provides "opt-out support", allowing for blocks of unsigned delegations to be covered by a single NSEC3 record. Use of the opt-out feature allows large registries to only sign as many NSEC3 records as there are signed DS or other Resource Record sets (RRsets) in the zone; with opt-out, unsigned delegations don't require additional NSEC3 records. This sacrifices the tamper-resistance of the proof of nonexistence offered by NSEC3 in order to reduce memory and CPU overheads.
NSEC3は「オプトアウトサポート」も提供し、単一のNSEC3レコードで署名されていない代表団のブロックをカバーできるようにします。オプトアウト機能を使用すると、大規模なレジストリは、ゾーン内に署名されたDSまたは他のリソースレコードセット（RRSET）と同じくらい多くのNSEC3レコードのみに署名できます。オプトアウトでは、署名されていない代表団は追加のNSEC3レコードを必要としません。これは、メモリとCPUのオーバーヘッドを減らすために、NSEC3が提供する非存在の証明の改ざん抵抗を犠牲にします。
NSEC3 records have a number of tunable parameters that are specified via an NSEC3PARAM record at the zone apex. These parameters are the hash algorithm, the processing flags, the number of hash iterations, and the salt. Each of these has security and operational considerations that impact both zone owners and validating resolvers. This document provides some best-practice recommendations for setting the NSEC3 parameters.
NSEC3レコードには、Zone ApexのNSEC3Paramレコードを介して指定された多くの調整可能なパラメーターがあります。これらのパラメーターは、ハッシュアルゴリズム、処理フラグ、ハッシュ反復の数、および塩です。これらのそれぞれには、ゾーンオーナーとリゾルバーの検証の両方に影響を与えるセキュリティと運用上の考慮事項があります。このドキュメントは、NSEC3パラメーターを設定するためのいくつかのベストプラクティスの推奨事項を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The following sections describe the background of the parameters for the NSEC3 and NSEC3PARAM RRTYPEs.
次のセクションでは、NSEC3およびNSEC3PARAM RRTYPEのパラメーターの背景について説明します。
The algorithm field is not discussed by this document. Readers are encouraged to read [RFC8624] for guidance about DNSSEC algorithm usage.
アルゴリズムフィールドは、このドキュメントでは説明されていません。読者は、DNSSECアルゴリズムの使用に関するガイダンスについて[RFC8624]を読むことをお勧めします。
The NSEC3PARAM flags field currently contains only reserved and unassigned flags. However, individual NSEC3 records contain the "Opt-Out" flag [RFC5155] that specifies whether that NSEC3 record provides proof of nonexistence. In general, NSEC3 with the Opt-Out flag enabled should only be used in large, highly dynamic zones with a small percentage of signed delegations. Operationally, this allows for fewer signature creations when new delegations are inserted into a zone. This is typically only necessary for extremely large registration points providing zone updates faster than real-time signing allows or when using memory-constrained hardware. Operators considering the use of NSEC3 are advised to carefully weigh the costs and benefits of choosing NSEC3 over NSEC. Smaller zones, or large but relatively static zones, are encouraged to not use the opt-opt flag and to take advantage of DNSSEC's authenticated denial of existence.
NSEC3PARAMフラグフィールドには、現在、予約済みのフラグのみが含まれています。ただし、個々のNSEC3レコードには、NSEC3レコードが存在しないことの証明を提供するかどうかを指定する「オプトアウト」フラグ[RFC5155]が含まれています。一般に、オプトアウトフラグが有効になっているNSEC3は、署名された代表団がわずかにある大きくて非常にダイナミックなゾーンでのみ使用する必要があります。運用上、これにより、ゾーンに新しい代表団が挿入されると、より少ない署名作成が可能になります。これは通常、リアルタイムの署名が許可されているよりも速いゾーンの更新を提供する非常に大きな登録ポイントにのみ必要です。NSEC3の使用を検討しているオペレーターは、NSECよりもNSEC3を選択することのコストと利点を慎重に比較検討することをお勧めします。より小さなゾーン、または大規模であるが比較的静的なゾーンは、Opt-OPTフラグを使用せず、DNSSECの認証された存在の拒否を利用することをお勧めします。
NSEC3 records are created by first hashing the input domain and then repeating that hashing using the same algorithm a number of times based on the iteration parameter in the NSEC3PARAM and NSEC3 records. The first hash with NSEC3 is typically sufficient to discourage zone enumeration performed by "zone walking" an unhashed NSEC chain.
NSEC3レコードは、最初に入力ドメインをハッシュし、NSEC3PARAMおよびNSEC3レコードの反復パラメーターに基づいて同じアルゴリズムを使用して何度もハッシュすることによって作成されます。NSEC3を使用した最初のハッシュは、通常、非粉砕されたNSECチェーンを「ゾーンウォーキング」によって実行されるゾーン列挙を思いとどまらせるのに十分です。
Note that [RFC5155] describes the Iterations field as follows
[RFC5155]が次のように反復フィールドを説明していることに注意してください
The Iterations field defines the number of additional times the hash function has been performed.
イテレーションフィールドは、ハッシュ関数が実行された追加の回数を定義します。
This means that an NSEC3 record with an Iterations field of 0 actually requires one hash iteration.
これは、0の反復フィールドを持つNSEC3レコードには、実際に1つのハッシュ反復が必要であることを意味します。
Only determined parties with significant resources are likely to try and uncover hashed values, regardless of the number of additional iterations performed. If an adversary really wants to expend significant CPU resources to mount an offline dictionary attack on a zone's NSEC3 chain, they'll likely be able to find most of the "guessable" names despite any level of additional hashing iterations.
かなりのリソースを持つ決定された関係者のみが、実行される追加の反復の数に関係なく、ハッシュされた値を明らかにしようとする可能性があります。敵が実際に重要なCPUリソースを費やして、ゾーンのNSEC3チェーンにオフラインの辞書攻撃を実施したい場合、追加のレベルのハッシュイテレーションにもかかわらず、「推測可能な」名前のほとんどを見つけることができるでしょう。
Most names published in the DNS are rarely secret or unpredictable. They are published to be memorable, used and consumed by humans. They are often recorded in many other network logs such as email logs, certificate transparency logs, web page links, intrusion-detection systems, malware scanners, email archives, etc. Many times a simple dictionary of commonly used domain names prefixes (www, mail, imap, login, database, etc.) can be used to quickly reveal a large number of labels within a zone. Because of this, there are increasing performance costs yet diminishing returns associated with applying additional hash iterations beyond the first.
DNSで公開されているほとんどの名前は、秘密や予測不可能なものではありません。それらは、人間によって記憶に残り、使用され、消費されるように出版されています。電子メールログ、証明書の透明性ログ、Webページリンク、侵入検出システム、マルウェアスキャナー、電子メールアーカイブなど、他の多くのネットワークログにしばしば記録されます。、IMAP、ログイン、データベースなど）を使用して、ゾーン内の多数のラベルをすばやく表示できます。このため、パフォーマンスコストが増加していますが、最初のものを超えて追加のハッシュ反復を適用することに関連するリターンが減少しています。
Although Section 10.3 of [RFC5155] specifies the upper bounds for the number of hash iterations to use, there is no published guidance for zone owners about good values to select. Recent academic studies have shown that NSEC3 hashing provides only moderate protection [GPUNSEC3] [ZONEENUM].
[RFC5155]のセクション10.3は、使用するハッシュイテレーションの数の上限を指定していますが、選択する良い値についてゾーン所有者に公開されたガイダンスはありません。最近の学術研究により、NSEC3ハッシュは中程度の保護のみを提供することが示されています[GPUNSEC3] [ZoneNum]。
NSEC3 records provide an additional salt value, which can be combined with a Fully Qualified Domain Name (FQDN) to influence the resulting hash, but properties of this extra salt are complicated.
NSEC3レコードは追加の塩値を提供します。これは、得られたハッシュに影響を与えるために完全に適格なドメイン名（FQDN）と組み合わせることができますが、この余分な塩の特性は複雑です。
In cryptography, salts generally add a layer of protection against offline, stored dictionary attacks by combining the value to be hashed with a unique "salt" value. This prevents adversaries from building up and remembering a single dictionary of values that can translate a hash output back to the value that it was derived from.
暗号化では、塩は一般に、一意の「塩」値とハッシュする値を組み合わせることにより、オフラインから保存された辞書攻撃に対する保護層を追加します。これにより、敵は、ハッシュ出力を導き出された値に戻すことができる価値の単一の辞書を構築して覚えていません。
In the case of DNS, the situation is different because the hashed names placed in NSEC3 records are always implicitly "salted" by hashing the FQDN from each zone. Thus, no single pre-computed table works to speed up dictionary attacks against multiple target zones. An attacker is always required to compute a complete dictionary per zone, which is expensive in both storage and CPU time.
DNSの場合、NSEC3レコードに配置されたハッシュされた名前が各ゾーンからFQDNをハッシュすることにより常に暗黙的に「塩漬け」されるため、状況は異なります。したがって、複数のターゲットゾーンに対する辞書攻撃をスピードアップするために、事前に計算されたテーブルが単一のテーブルが機能することはありません。攻撃者は常にゾーンごとに完全な辞書を計算する必要があります。これは、ストレージとCPU時間の両方で高価です。
To understand the role of the additional NSEC3 salt field, we have to consider how a typical zone walking attack works. Typically, the attack has two phases: online and offline. In the online phase, an attacker "walks the zone" by enumerating (almost) all hashes listed in NSEC3 records and storing them for the offline phase. Then, in the offline cracking phase, the attacker attempts to crack the underlying hash. In this phase, the additional salt value raises the cost of the attack only if the salt value changes during the online phase of the attack. In other words, an additional, constant salt value does not change the cost of the attack.
追加のNSEC3塩フィールドの役割を理解するには、典型的なゾーンウォーキング攻撃がどのように機能するかを検討する必要があります。通常、攻撃には、オンラインとオフラインの2つのフェーズがあります。オンラインフェーズでは、攻撃者がNSEC3レコードにリストされ、オフラインフェーズに保存されたすべてのハッシュを（ほぼ）列挙することにより、「ゾーンを歩きます」。次に、オフラインの亀裂段階で、攻撃者は下にあるハッシュを割ることを試みます。このフェーズでは、追加の塩値は、攻撃のオンラインフェーズ中に塩値が変化した場合にのみ、攻撃のコストを引き上げます。言い換えれば、追加の定数塩値は攻撃のコストを変更しません。
Changing a zone's salt value requires the construction of a complete new NSEC3 chain. This is true both when re-signing the entire zone at once and when incrementally signing it in the background where the new salt is only activated once every name in the chain has been completed. As a result, re-salting is a very complex operation, with significant CPU time, memory, and bandwidth consumption. This makes very frequent re-salting impractical and renders the additional salt field functionally useless.
ゾーンの塩値を変更するには、完全な新しいNSEC3チェーンの構築が必要です。これは、ゾーン全体を一度に再署名する場合、およびチェーン内のすべての名前が完成した場合にのみ、新しい塩が作動するバックグラウンドで段階的に署名する場合の両方です。その結果、再溶融は非常に複雑な操作であり、CPU時間、メモリ、帯域幅の消費量が大幅にあります。これにより、非常に頻繁に再沈没することが非現実的になり、追加の塩フィールドが機能的に役に立たなくなります。
The following subsections describe recommendations for the different operating realms within the DNS.
次のサブセクションでは、DNS内のさまざまな操作領域に関する推奨事項について説明します。
First, if the operational or security features of NSEC3 are not needed, then NSEC SHOULD be used in preference to NSEC3. NSEC3 requires greater computational power (see Appendix B) for both authoritative servers and validating clients. Specifically, there is a nontrivial complexity in finding matching NSEC3 records to randomly generated prefixes within a DNS zone. NSEC mitigates this concern. If NSEC3 must be used, then an iterations count of 0 MUST be used to alleviate computational burdens. Note that extra iteration counts other than 0 increase the impact of CPU-exhausting DoS attacks, and also increase the risk of interoperability problems.
まず、NSEC3の運用機能またはセキュリティ機能が必要ない場合は、NSECをNSEC3より優先して使用する必要があります。NSEC3は、権威あるサーバーと検証クライアントの両方に対して、より大きな計算能力（付録Bを参照）を必要とします。具体的には、DNSゾーン内でランダムに生成されたプレフィックスに一致するNSEC3レコードを見つけることには、非重要な複雑さがあります。NSECはこの懸念を軽減します。NSEC3を使用する必要がある場合、計算負担を軽減するために0の反復カウントを使用する必要があります。0以外の追加イテレーションカウントは、CPU疲労DOS攻撃の影響を増加させ、相互運用性の問題のリスクを高めることに注意してください。
Note that deploying NSEC with minimally covering NSEC records [RFC4470] also incurs a cost, and zone owners should measure the computational difference in deploying either [RFC4470] or NSEC3.
NSECレコード[RFC4470]を最小限に抑えるNSECの展開もコストを負担し、ゾーンオーナーは[RFC4470]またはNSEC3の展開における計算の違いを測定する必要があることに注意してください。
In short, for all zones, the recommended NSEC3 parameters are as shown below:
要するに、すべてのゾーンについて、推奨されるNSEC3パラメーターを以下に示します。
; SHA-1, no extra iterations, empty salt: ; bcp.example. IN NSEC3PARAM 1 0 0 -
;Sha-1、余分な反復、空の塩：;bcp.example。nsec3param 1 0 0-
For small zones, the use of opt-out-based NSEC3 records is NOT RECOMMENDED.
小さなゾーンの場合、オプトアウトベースのNSEC3レコードの使用は推奨されません。
For very large and sparsely signed zones, where the majority of the records are insecure delegations, opt-out MAY be used.
レコードの大部分が不安定な代表団である非常に大きくてまばらに署名されたゾーンの場合、オプトアウトが使用される場合があります。
Operators SHOULD NOT use a salt by indicating a zero-length salt value instead (represented as a "-" in the presentation format).
オペレーターは、代わりにゼロの長さの塩値を示すことで塩を使用しないでください（プレゼンテーション形式で「 - 」として表されます）。
If salts are used, note that since the NSEC3PARAM RR is not used by validating resolvers (see Section 4 of [RFC5155]), the iterations and salt parameters can be changed without the need to wait for RRsets to expire from caches. A complete new NSEC3 chain needs to be constructed and the full zone needs to be re-signed.
塩を使用する場合、nsec3param RRはリゾルバーを検証することで使用されないため（[RFC5155]セクション4を参照）、RRSetがキャッシュから期限切れになるのを待つ必要なく、反復と塩のパラメーターを変更できることに注意してください。完全な新しいNSEC3チェーンを構築する必要があり、フルゾーンを再署名する必要があります。
Because there has been a large growth of open (public) DNSSEC validating resolvers that are subject to compute resource constraints when handling requests from anonymous clients, this document recommends that validating resolvers reduce their iteration count limits over time. Specifically, validating resolver operators and validating resolver software implementers are encouraged to continue evaluating NSEC3 iteration count deployment trends and lower their acceptable iteration limits over time. Because treating a high iterations count as insecure leaves zones subject to attack, validating resolver operators and validating resolver software implementers are further encouraged to lower their default limit for returning SERVFAIL when processing NSEC3 parameters containing large iteration count values. See Appendix A for measurements taken near the time of publication of this document and potential starting points.
匿名のクライアントからのリクエストを処理する際にリソース制約を計算する対象となるオープン（パブリック）DNSSEC検証リゾルバーの大幅な成長があったため、このドキュメントでは、リソースバーの検証が繰り返しカウント制限を時間の経過とともに減らすことを推奨しています。具体的には、Resolverオペレーターの検証とResolverソフトウェアの実装者の検証は、NSEC3反復カウント展開の評価を継続し、許容可能な反復制限を時間の経過とともに下げることをお勧めします。高い反復を扱うことは、攻撃の対象となる不安定な葉のゾーンとしてカウントされるため、リゾルバーオペレーターの検証とリゾルバーソフトウェアの実装者の検証は、大きな反復カウント値を含むNSEC3パラメーターを処理する際にサーブファイルを返すためにデフォルトの制限を下げることがさらに奨励されます。このドキュメントの公開時代と潜在的な出発点の近くで撮影された測定については、付録Aを参照してください。
Validating resolvers MAY return an insecure response to their clients when processing NSEC3 records with iterations larger than 0. Note also that a validating resolver returning an insecure response MUST still validate the signature over the NSEC3 record to ensure the iteration count was not altered since record publication (see Section 10.3 of [RFC5155]).
リゾルバーの検証は、0より大きい反復でNSEC3レコードを処理する場合、クライアントに対する不安定な応答を返す場合があります。また、不安定な応答を返す検証型リゾルバーは、NSEC3レコードの署名を検証して、レコードの公開以来の反復カウントが変更されないことを確認する必要があることに注意してください。（[RFC5155]のセクション10.3を参照）。
Validating resolvers MAY also return a SERVFAIL response when processing NSEC3 records with iterations larger than 0. Validating resolvers MAY choose to ignore authoritative server responses with iteration counts greater than 0, which will likely result in returning a SERVFAIL to the client when no acceptable responses are received from authoritative servers.
リゾルバーの検証は、0より大きい反復でNSEC3レコードを処理する場合、サーブファイル応答を返すこともあります。リゾルバーの検証は、0を超えるイテレーションカウントを持つ権威あるサーバー応答を無視することを選択できます。権威あるサーバーから受け取った。
Validating resolvers returning an insecure or SERVFAIL answer to their client after receiving and validating an unsupported NSEC3 parameter from the authoritative server(s) SHOULD return an Extended DNS Error (EDE) [RFC8914] EDNS0 option of value 27. Validating resolvers that choose to ignore a response with an unsupported iteration count (and that do not validate the signature) MUST NOT return this EDE option.
リゾルバーの検証の検証は、信頼できるサーバーからサポートされていないNSEC3パラメーターを受信して検証した後、クライアントに対する不安定またはサーブファイルの回答を返すリソースバーを返します。サポートされていない反復カウントを使用した応答（および署名を検証しない）は、このEDEオプションを返してはなりません。
Note that this specification updates [RFC5155] by significantly decreasing the requirements originally specified in Section 10.3 of [RFC5155]. See the Security Considerations (Section 4) for arguments on how to handle responses with non-zero iteration count.
この仕様は、[RFC5155]のセクション10.3で最初に指定された要件を大幅に減少させることにより、[RFC5155]を更新することに注意してください。ゼロ以外の反復カウントで応答を処理する方法に関する議論については、セキュリティに関する考慮事項（セクション4）を参照してください。
Primary and secondary authoritative servers for a zone that are not being run by the same operational staff and/or using the same software and configuration must take into account the potential differences in NSEC3 iteration support.
同じ運用スタッフによって実行されていないゾーンおよび/または同じソフトウェアと構成を使用していないゾーンのプライマリおよびセカンダリストーリーサーバーは、NSEC3反復サポートの潜在的な違いを考慮に入れる必要があります。
Operators of secondary services should advertise the parameter limits that their servers support. Correspondingly, operators of primary servers need to ensure that their secondaries support the NSEC3 parameters they expect to use in their zones. To ensure reliability, after primaries change their iteration counts, they should query their secondaries with known nonexistent labels to verify the secondary servers are responding as expected.
セカンダリサービスのオペレーターは、サーバーがサポートするパラメーター制限を宣伝する必要があります。それに対応して、プライマリサーバーの演算子は、ゾーンで使用すると予想されるNSEC3パラメーターを2番目のパラメーターをサポートすることを確認する必要があります。信頼性を確保するために、プライマリーが反復カウントを変更した後、既知の存在しないラベルを使用してセカンダリを照会して、セカンダリサーバーが期待どおりに応答していることを確認する必要があります。
This entire document discusses security considerations with various parameter selections of NSEC3 and NSEC3PARAM fields.
このドキュメント全体では、NSEC3およびNSEC3PARAMフィールドのさまざまなパラメーター選択を使用したセキュリティに関する考慮事項について説明します。
The point where a validating resolver returns insecure versus the point where it returns SERVFAIL must be considered carefully. Specifically, when a validating resolver treats a zone as insecure above a particular value (say 100) and returns SERVFAIL above a higher point (say 500), it leaves the zone subject to attacker-in-the-middle attacks as if it were unsigned between these values. Thus, validating resolver operators and software implementers SHOULD set the point above which a zone is treated as insecure for certain values of NSEC3 iterations to the same as the point where a validating resolver begins returning SERVFAIL.
検証済みのリゾルバーがServfailを返すポイントと慎重に検討する必要があるポイントを慎重に検討する必要があります。具体的には、検証済みのリゾルバーがゾーンを特定の値を超えて不安定として扱い（たとえば100）、サーブファイルをより高いポイントより上（500）上に戻すと、ゾーンが攻撃者の攻撃者の攻撃を署名していないかのようにしますこれらの値の間。したがって、検証型のオペレーターとソフトウェアの実装者の検証は、ゾーンがNSEC3反復の特定の値に対して不安定として扱われるポイントを設定する必要があります。
This entire document discusses operational considerations with various parameter selections of NSEC3 and NSEC3PARAM fields.
このドキュメント全体では、NSEC3およびNSEC3PARAMフィールドのさまざまなパラメーター選択を使用した運用上の考慮事項について説明します。
IANA has allocated the following code in the First Come First Served range [RFC8126] of the "Extended DNS Error Codes" registry within the "Domain Name System (DNS) Parameters" registry:
IANAは、「ドメイン名システム（DNS）パラメーター」レジストリ内の「拡張DNSエラーコード」レジストリの最初のCome First Ferver範囲[RFC8126]に次のコードを割り当てました。
INFO-CODE: 27 Purpose: Unsupported NSEC3 iterations value Reference: RFC 9276
情報コード：27目的：サポートされていないNSEC3イテレーション値リファレンス：RFC 9276
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[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.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル修正」、RFC 4035、DOI 10.17487/RFC4035、2005年3月、<https://www.rfc-editor.org/info/rfc4035>。
[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/RFC4470, April 2006, <https://www.rfc-editor.org/info/rfc4470>.
[RFC4470] Weiler、S。およびJ. Ihren、「NSECレコードとDNSECオンライン署名を最小限に覆う」、RFC 4470、DOI 10.17487/RFC4470、2006年4月、<https：//www.rfc-editor.org/info/RFC4470>。
[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. Blacka、「DNS Security（DNSSEC）は認証された存在拒否」、RFC 5155、DOI 10.17487/RFC5155、2008年3月、<HTTPS：//www.rfc-editor.org/info/rfc5155>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, <https://www.rfc-editor.org/info/rfc8914>.
[RFC8914] Kumari、W.、Hunt、E.、Arends、R.、Hardaker、W。、およびD. Lawrence、「拡張DNSエラー」、RFC 8914、DOI 10.17487/RFC8914、2020年10月、<https：///www.rfc-editor.org/info/rfc8914>。
[GPUNSEC3] Wander, M., Schwittmann, L., Boelmann, C., and T. Weis, "GPU-Based NSEC3 Hash Breaking", DOI 10.1109/NCA.2014.27, August 2014, <https://doi.org/10.1109/NCA.2014.27>.
[GPUNSEC3] Wander、M.、Schwittmann、L.、Boelmann、C.、およびT. Weis、「GPUベースのNSEC3ハッシュブレイク」、DOI 10.1109/NCA.2014.27、2014年8月、<https://doi.org/10.1109/NCA.2014.27>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", RFC 8624, DOI 10.17487/RFC8624, June 2019, <https://www.rfc-editor.org/info/rfc8624>.
[RFC8624] Wouters、P。およびO. Sury、「DNSSECのアルゴリズムの実装要件と使用ガイダンス」、RFC 8624、DOI 10.17487/RFC8624、2019年6月、<https：//www.rfc-editor.org/fo/RFC86244>。
[ZONEENUM] Wang, Z., Xiao, L., and R. Wang, "An efficient DNSSEC zone enumeration algorithm", DOI 10.2495/MIIT130591, April 2014, <https://doi.org/10.2495/MIIT130591>.
[ZoneNum] Wang、Z.、Xiao、L。、およびR. Wang、「効率的なDNSSECゾーン列挙アルゴリズム」、DOI 10.2495/MIIT130591、2014年4月、<https://doi.org/10.2495/MIIT130591>。
At the time of publication, setting an upper limit of 100 iterations for treating a zone as insecure is interoperable without significant problems, but at the same time still enables CPU-exhausting DoS attacks.
出版時には、ゾーンを不安定に扱うための100の反復の上限を設定することは、重大な問題なく相互運用可能ですが、同時にCPUを排除するDOS攻撃を可能にします。
At the time of publication, returning SERVFAIL beyond 500 iterations appears to be interoperable without significant problems.
出版時には、500の反復を超えてサーブファイルを返すことは、重大な問題なく相互運用可能であるように見えます。
The queries per second (QPS) of authoritative servers will decrease due to computational overhead when processing DNS requests for zones containing higher NSEC3 iteration counts. The table below shows the drop in QPS for various iteration counts.
より高いNSEC3反復カウントを含むゾーンのDNS要求を処理すると、計算オーバーヘッドのために、権威あるサーバーの1秒あたりのクエリ（QPS）は減少します。以下の表は、さまざまな反復カウントのQPSの低下を示しています。
+============+=============================+
| Iterations | QPS [% of 0 Iterations QPS] |
+============+=============================+
| 0 | 100% |
+------------+-----------------------------+
| 10 | 89% |
+------------+-----------------------------+
| 20 | 82% |
+------------+-----------------------------+
| 50 | 64% |
+------------+-----------------------------+
| 100 | 47% |
+------------+-----------------------------+
| 150 | 38% |
+------------+-----------------------------+
Table 1: Drop in QPS for Various Iteration Counts
表1：さまざまな反復カウントについてQPSをドロップする
Acknowledgments
謝辞
The authors would like to thank the participants in the dns-operations discussion, which took place on mattermost hosted by DNS-OARC.
著者は、DNS-OARCがホストしたMatterで行われたDNS-Operationsディスカッションの参加者に感謝したいと思います。
Additionally, the following people contributed text or review comments to this document:
さらに、次の人々がこのドキュメントにテキストを提供するか、コメントをレビューしました。
* Vladimir Cunat
* ウラジミール・カナト
* Tony Finch
* トニー・フィンチ
* Paul Hoffman
* ポール・ホフマン
* Warren Kumari
* ウォーレン・クマリ
* Alexander Mayrhofer
* アレクサンダー・メールホーファー
* Matthijs Mekking
* Matthijs Mekking
* Florian Obser
* フロリアンオブザーブ
* Petr Spacek
* Petr Spacek
* Paul Vixie
* ポール・ビクシー
* Tim Wicinski
* ティム・ウィシンスキー
Authors' Addresses
著者のアドレス
Wes Hardaker USC/ISI Email: ietf@hardakers.net
Wes Hardaker USC/ISI電子メール：ietf@hardakers.net
Viktor Dukhovni Bloomberg, L.P. Email: ietf-dane@dukhovni.org
Viktor Dukhovni Bloomberg、L.P。電子メール：ietf-dane@dukhovni.org