[要約] RFC 8027は、DNSSECの導入における障害を回避するためのガイドラインを提供するものであり、DNSSECの展開を促進することを目的としています。
Internet Engineering Task Force (IETF) W. Hardaker
Request for Comments: 8027 USC/ISI
BCP: 207 O. Gudmundsson
Category: Best Current Practice CloudFlare
ISSN: 2070-1721 S. Krishnaswamy
Parsons
November 2016
DNSSEC Roadblock Avoidance
DNSSECロードブロッキングの回避
Abstract
概要
This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face.
このドキュメントでは、検証DNSリゾルバー、スタブリゾルバー、またはアプリケーションが非準拠インフラストラクチャ内で発生する可能性がある問題について説明します。潜在的な検出および軽減手法の概要を説明します。このドキュメントの目的は、DNSSECソフトウェア/システムが直面する可能性があるネットワークの問題を検出して克服するための共有アプローチを作成することです。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc8027.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8027で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Notation ...................................................3
1.2. Background .................................................3
1.3. Implementation Experiences .................................4
1.3.1. Test Zone Implementation ............................4
2. Goals ...........................................................4
3. Detecting DNSSEC Non-compliance .................................5
3.1. Determining DNSSEC Support in Recursive Resolvers ..........5
3.1.1. Supports UDP Answers ................................6
3.1.2. Supports TCP Answers ................................6
3.1.3. Supports EDNS0 ......................................6
3.1.4. Supports the DO Bit .................................7
3.1.5. Supports the AD Bit DNSKEY Algorithms 5 and/or 8 ....7
3.1.6. Returns RRSIG for Signed Answer .....................7
3.1.7. Supports Querying for DNSKEY Records ................8
3.1.8. Supports Querying for DS Records ....................8
3.1.9. Supports Negative Answers with NSEC Records .........8
3.1.10. Supports Negative Answers with NSEC3 Records .......9
3.1.11. Supports Queries Where DNAME Records Lead
to an Answer .......................................9
3.1.12. Permissive DNSSEC .................................10
3.1.13. Supports Unknown RRtypes ..........................10
3.2. Direct Network Queries ....................................10
3.2.1. Support for Remote UDP over Port 53 ................10
3.2.2. Support for Remote UDP with Fragmentation ..........11
3.2.3. Support for Outbound TCP over Port 53 ..............11
3.3. Support for DNSKEY and DS Combinations ....................11
4. Aggregating the Results ........................................12
4.1. Resolver Capability Description ...........................12
5. Roadblock Avoidance ............................................13
5.1. Partial Resolver Usage ....................................16
5.1.1. Known Insecure Lookups .............................16
5.1.2. Partial NSEC/NSEC3 Support .........................16
6. Start-Up and Network Connectivity Issues .......................16
6.1. What to Do ................................................17
7. Quick Test .....................................................17
7.1. Test Negative Answers Algorithm 5 .........................17
7.2. Test Algorithm 8 ..........................................18
7.3. Test Algorithm 13 .........................................18
7.4. Fails When DNSSEC Does Not Validate .......................18
8. Security Considerations ........................................18
9. Normative References ...........................................18
Acknowledgments ...................................................19
Authors' Addresses ................................................19
This document describes problems observable during DNSSEC ([RFC4034] [RFC4035]) deployment that derive from non-compliant infrastructure. It poses potential detection and mitigation techniques.
このドキュメントでは、非準拠のインフラストラクチャから派生したDNSSEC（[RFC4034] [RFC4035]）の展開中に観察可能な問題について説明します。それは潜在的な検出と緩和技術を提起します。
In this document, a "Host Validator" can either be a validating stub-resolver, such as a library that an application has linked in, or a validating resolver daemon running on the same machine. It may or may not be trying to use upstream caching resolvers during its own resolution process; both cases are covered by the tests defined in this document.
このドキュメントでは、「ホストバリデーター」は、アプリケーションがリンクしたライブラリなどの検証スタブリゾルバーか、同じマシンで実行されている検証リゾルバーデーモンのいずれかです。独自の解決プロセス中にアップストリームキャッシングリゾルバーを使用しようとする場合としない場合があります。どちらの場合も、このドキュメントで定義されているテストでカバーされています。
The sub-variant of this is a "Validating Forwarding Resolver", which is a resolver that is configured to use upstream Resolvers when possible. A Validating Forwarding Resolver also needs to perform the tests outlined in this document before using an upstream recursive resolver.
これのサブバリアントは「検証転送リゾルバー」です。これは、可能な場合にアップストリームリゾルバーを使用するように構成されたリゾルバーです。 Validating Forwarding Resolverは、上流の再帰リゾルバを使用する前に、このドキュメントで概説されているテストを実行する必要もあります。
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]で説明されているように解釈されます。
Deployment of DNSSEC validation is hampered by network components that make it difficult or sometimes impossible for validating resolvers to effectively obtain the DNSSEC data they need. This can occur for many different reasons including, but not limited to, the following:
DNSSEC検証の展開は、検証コンポーネントが必要なDNSSECデータを効率的に取得することを困難または場合によっては不可能にするネットワークコンポーネントによって妨げられています。これには、次のようなさまざまな理由が考えられます。
o Recursive resolvers and DNS proxies [RFC5625] not being fully DNSSEC compliant
o 再帰リゾルバとDNSプロキシ[RFC5625]がDNSSECに完全に準拠していない
o Resolvers not being DNSSEC aware
o DNSSECに対応していないリゾルバー
o "Middleboxes" actively blocking, modifying, and/or restricting outbound traffic to the DNS port (53) either UDP and/or TCP
o 「ミドルボックス」は、UDPまたはTCP、あるいはその両方のDNSポート（53）への発信トラフィックをアクティブにブロック、変更、および/または制限します。
o In-path network components not allowing UDP fragments
o UDPフラグメントを許可しないパス内ネットワークコンポーネント
This document talks about ways that a Host Validator can detect the state of the network it is attached to, and ways to hopefully circumvent the problems associated with the network defects it discovers. The tests described in this document may be performed on any validating resolver to detect and prevent problems. While these recommendations are mainly aimed at Host Validators, it is prudent to perform these tests from regular validating resolvers, just to make sure things work.
このドキュメントでは、ホストバリデーターが接続されているネットワークの状態を検出する方法と、発見したネットワーク障害に関連する問題をうまく回避する方法について説明します。このドキュメントで説明されているテストは、問題を検出して防止するために、検証リゾルバで実行できます。これらの推奨事項は主にホストバリデーターを対象としていますが、正常に動作することを確認するためだけに、定期的な検証リゾルバーからこれらのテストを実行することが賢明です。
There are situations where a host cannot talk directly to a Resolver; the tests below cannot address how to overcome that, and inconsistent results can be seen in such cases. This can happen, for instance, when there are DNS proxies/forwarders between the user and the actual resolvers.
ホストがリゾルバーと直接通信できない状況があります。以下のテストでは、それを克服する方法に対処できず、そのような場合に一貫性のない結果が見られることがあります。これは、たとえば、ユーザーと実際のリゾルバーの間にDNSプロキシ/フォワーダーがある場合に発生する可能性があります。
Multiple lessons learned from multiple implementations led to the development of this document, including (in alphabetical order) DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger, and FCC_Grade.
DNSSEC-ToolsのDNSSEC-Check、DNSSEC_Resolver_Check、dnssec-trigger、FCC_Gradeなど、複数の実装から学んだ複数のレッスンがこのドキュメントの開発につながりました（アルファベット順）。
Detecting lack of support for specified Domain Name System Key (DNSKEY) algorithms and Delegation Signer (DS) digest algorithms is outside the scope of this document, but the document provides information on how to do that. See the sample test tool: <https://github.com/ogud/DNSSEC_ALG_Check>.
指定されたドメインネームシステムキー（DNSKEY）アルゴリズムと委任署名者（DS）ダイジェストアルゴリズムのサポートの欠如を検出することは、このドキュメントの範囲外ですが、このドキュメントではその方法について説明しています。サンプルテストツール<https://github.com/ogud/DNSSEC_ALG_Check>を参照してください。
This document does describe compliance tests for algorithms 5, 7, and 13 with DS digest algorithms 1 and 2.
このドキュメントでは、DSダイジェストアルゴリズム1および2を使用したアルゴリズム5、7、および13のコンプライアンステストについて説明しています。
In this document, the "test.example.com" domain is used to refer to DNS records that contain test records that have known DNSSEC properties associated with them. For example, the "badsign-a.test.example.com" domain is used below to refer to a DNS A record where the signatures published for it are invalid (i.e., they are "bad signatures" that should cause a validation failure).
このドキュメントでは、「test.example.com」ドメインは、既知のDNSSECプロパティが関連付けられているテストレコードを含むDNSレコードを参照するために使用されます。たとえば、「badsign-a.test.example.com」ドメインは、発行された署名が無効であるDNS Aレコードを参照するために以下で使用されます（つまり、検証失敗の原因となる「悪い署名」です）。 。
At the time of this publication, the "test.dnssec-tools.org" domain implements all of these test records. Thus, it may be possible to replace "test.example.com" in this document with "test.dnssec-tools.org" when performing real-world tests.
この公開の時点では、「test.dnssec-tools.org」ドメインがこれらのテストレコードをすべて実装しています。したがって、実際のテストを実行する場合、このドキュメントの「test.example.com」を「test.dnssec-tools.org」に置き換えることが可能です。
This document is intended to show how a Host Validator can detect the capabilities of a recursive resolver and work around any problems that could potentially affect DNSSEC resolution. This enables the Host Validator to make use of the caching functionality of the recursive resolver, which is desirable in that it decreases network traffic and improves response times.
このドキュメントは、ホストバリデーターが再帰リゾルバーの機能を検出し、DNSSEC解決に影響を与える可能性のある問題を回避する方法を示すことを目的としています。これにより、ホストバリデーターは再帰リゾルバーのキャッシング機能を利用できるようになります。これは、ネットワークトラフィックを減らし、応答時間を改善するという点で望ましいです。
A Host Validator has two choices: it can wait to determine that it has problems with a recursive resolver based on the results that it is getting from real-world queries issued to it or it can proactively test for problems (Section 3) to build a workaround list ahead of time (Section 5). There are pros and cons to both of these paths that are application specific, and this document does not attempt to provide guidance about whether proactive tests should or should not be used. Either way, DNSSEC roadblock avoidance techniques ought to be used when needed and if possible.
ホストバリデーターには2つの選択肢があります。ホストバリデーターは、発行された実際のクエリから得られた結果に基づいて再帰リゾルバーに問題があることを確認するまで待つか、問題を事前にテストして（セクション3）ビルドして、事前の回避策リスト（セクション5）。これらの両方のパスにはアプリケーション固有の長所と短所があり、このドキュメントでは、プロアクティブテストを使用する必要があるかどうかについてのガイダンスは提供しません。どちらの方法でも、DNSSECロードブロッキング回避手法は、必要に応じて、可能であれば使用する必要があります。
Note: Besides being useful for Host Validators, the same tests can be used for a recursive resolver to check if its upstream connections hinder DNSSEC validation.
注：ホストバリデーターに役立つだけでなく、同じテストを再帰リゾルバーに使用して、アップストリーム接続がDNSSEC検証を妨害していないかどうかを確認できます。
This section outlines tests that a validator should perform in order to test certain features of the surrounding network. A resolver should perform these tests when first starting but MAY also perform these tests when it has detected network changes (e.g., address changes, network reattachment, or etc.).
このセクションでは、周辺ネットワークの特定の機能をテストするためにバリデーターが実行する必要があるテストの概要を説明します。リゾルバーは最初の起動時にこれらのテストを実行する必要がありますが、ネットワークの変更（アドレスの変更、ネットワークの再接続など）を検出したときにもこれらのテストを実行できます（MAY）。
Note: When performing these tests against an address, we make the following assumption about that address: it is a unicast address or an anycast [RFC4786] cluster where all servers have identical configuration and connectivity.
注：アドレスに対してこれらのテストを実行する場合、そのアドレスについて次の仮定を行います。これは、すべてのサーバーの構成と接続が同じであるユニキャストアドレスまたはエニーキャスト[RFC4786]クラスターです。
Note: When performing these tests, we also assume that the path is clear of "DNS-interfering" middleboxes, like firewalls, proxies, or forwarders. The presence of such infrastructure can easily make a recursive resolver appear to be functioning improperly. It is beyond the scope of the document as how to work around such interference, although the tests defined in this document may indicate when such misbehaving middleware is causing interference.
注：これらのテストを実行する場合、ファイアウォール、プロキシ、フォワーダーなどの「DNS干渉」ミドルボックスがパスにないことも想定しています。このようなインフラストラクチャが存在すると、再帰リゾルバが正しく機能していないように見えやすくなります。このような干渉を回避する方法については、このドキュメントの範囲外ですが、このドキュメントで定義されているテストでは、このような誤動作するミドルウェアが干渉を引き起こしている場合を示している場合があります。
Note: This document specifies two sets of tests to perform: a comprehensive one and a fast one. The fast one will detect most common problems; thus, if the fast one passes, then the comprehensive one MAY be considered passed as well.
注：このドキュメントでは、包括的テストと高速テストの2つのテストセットを指定しています。高速なものは、最も一般的な問題を検出します。したがって、速いものが通過した場合、包括的なものも通過したと見なされる場合があります。
Ideally, a Host Validator can make use of the caching present in recursive resolvers. This section discusses the tests that a recursive resolver MUST pass in order to be fully usable as a DNS cache.
理想的には、ホストバリデーターは、再帰リゾルバーに存在するキャッシングを利用できます。このセクションでは、DNSキャッシュとして完全に使用できるようにするために、再帰リゾルバーが合格しなければならないテストについて説明します。
Unless stated otherwise:
特に明記しない限り：
o all of the following tests SHOULD have the Recursion Desired (RD) flag set when sending out a query and queries SHOULD be sent over UDP.
o 次のすべてのテストでは、クエリの送信時にRecursion Desired（RD）フラグを設定する必要があり（SHOULD）、クエリはUDP経由で送信する必要があります（SHOULD）。
o the tests MUST NOT have the DNSSEC OK (DO) bit set or utilize any of the other DNSSEC-related requirements, like Extension Mechanisms for DNS (EDNS0).
o テストでは、DNSSEC OK（DO）ビットを設定したり、DNSの拡張メカニズム（EDNS0）など、他のDNSSEC関連の要件を利用してはいけません（MUST NOT）。
The tests are designed to check for support of one feature at a time.
テストは、一度に1つの機能のサポートをチェックするように設計されています。
Purpose: This tests basic DNS-over-UDP functionality to a resolver.
目的：これは、リゾルバーに対する基本的なDNS-over-UDP機能をテストします。
Test: A DNS request is sent to the resolver under test for an A record for a known existing domain, such as good-a.test.example.com.
テスト：DNS要求は、good-a.test.example.comなどの既知の既存ドメインのAレコードのテスト中のリゾルバーに送信されます。
SUCCESS: A DNS response was received that contains an A record in the answer section. (The data itself does not need to be checked.)
成功：回答セクションにAレコードを含むDNS応答が受信されました。 （データ自体を確認する必要はありません。）
Note: An implementation MAY chose not to perform the rest of the tests if this test fails, as it is highly unlikely that the resolver under test will pass any of the remaining tests.
注：テスト中のリゾルバーが残りのテストに合格する可能性はほとんどないため、このテストが失敗した場合、実装は残りのテストを実行しないことを選択できます（MAY）。
Purpose: This tests basic TCP functionality to a resolver.
目的：これは、リゾルバーに対する基本的なTCP機能をテストします。
Test: A DNS request is sent over TCP to the resolver under test for an A record for a known existing domain, such as good-a.test.example.com.
テスト：DNSリクエストは、good-a.test.example.comなどの既知の既存ドメインのAレコードのテスト中のリゾルバーにTCP経由で送信されます。
SUCCESS: A DNS response was received that contains an A record in the answer section. (The data itself does not need to be checked.)
成功：回答セクションにAレコードを含むDNS応答が受信されました。 （データ自体を確認する必要はありません。）
Purpose: Test whether a resolver properly supports the EDNS0 extension option.
目的：リゾルバーがEDNS0拡張オプションを適切にサポートしているかどうかをテストします。
Prerequisite: Supports UDP or TCP.
前提条件：UDPまたはTCPをサポートします。
Test: Send a request to the resolver under test for an A record for a known existing domain, such as good-a.test.example.com, with an EDNS0 OPT record in the additional section.
テスト：テスト対象のリゾルバーにリクエストを送信し、good-a.test.example.comなどの既知の既存ドメインのAレコードを追加セクションにEDNS0 OPTレコードとともに送信します。
SUCCESS: A DNS response was received that contains an EDNS0 option with version number 0.
成功：バージョン番号0のEDNS0オプションを含むDNS応答が受信されました。
Purpose: This tests whether a resolver has minimal support of the DO bit.
目的：これは、リゾルバーがDOビットのサポートを最小限にしているかどうかをテストします。
Prerequisite: Supports EDNS0.
前提条件：EDNS0をサポートします。
Test: Send a request to the resolver under test for an A record for a known existing domain, such as good-a.test.example.com. Set the DO bit in the outgoing query.
テスト：テスト対象のリゾルバにリクエストを送信し、good-a.test.example.comなどの既知の既存ドメインのAレコードを取得します。発信クエリにDOビットを設定します。
SUCCESS: A DNS response was received that contains the DO bit set.
成功：DOビットセットを含むDNS応答が受信されました。
Note: This only tests that the resolver set the DO bit in the response. Later tests will determine if the DO bit was actually made use of. Some resolvers successfully pass this test because they simply copy the unknown flags into the response. These resolvers will fail the later tests.
注：これは、リゾルバーが応答でDOビットを設定したことのみをテストします。その後のテストでは、DOビットが実際に使用されたかどうかを判断します。一部のリゾルバーは、不明なフラグを応答にコピーするだけなので、このテストに合格しています。これらのリゾルバーは、後のテストに失敗します。
Purpose: This tests whether the resolver is a validating resolver.
目的：これは、リゾルバーが検証リゾルバーであるかどうかをテストします。
Prerequisite: Supports the DO bit.
前提条件：DOビットをサポートします。
Test: Send requests to the resolver under test for an A record for a known existing domain in a DNSSEC-signed zone that is verifiable to a configured trust anchor, such as good-a.test.example.com using the root's published DNSKEY or DS record as a trust anchor. Set the DO bit in the outgoing query. This test should be done twice: once for a zone that contains algorithm 5 (RSASHA1) and again for algorithm 8 (RSASHA256).
テスト：ルートの公開されたDNSKEYを使用してgood-a.test.example.comなどの構成されたトラストアンカーで検証可能なDNSSEC署名ゾーン内の既知の既存ドメインのAレコードのテスト中のリゾルバーに要求を送信します。トラストアンカーとしてのDSレコード。発信クエリにDOビットを設定します。このテストは2回行う必要があります。1回はアルゴリズム5（RSASHA1）を含むゾーンで、もう1回はアルゴリズム8（RSASHA256）で行います。
SUCCESS: A DNS response was received that contains the Authentic Data (AD) bit set for algorithm 5 (RSASHA1).
成功：アルゴリズム5（RSASHA1）に設定された認証データ（AD）ビットを含むDNS応答を受信しました。
BONUS: The AD bit is set for a resolver that supports algorithm 8 (RSASHA256).
ボーナス：ADビットは、アルゴリズム8（RSASHA256）をサポートするリゾルバーに設定されます。
Purpose: This tests whether a resolver will properly return Resource Record Signature (RRSIG) records when the DO bit is set.
目的：これは、DOビットが設定されているときにリゾルバーがリソースレコード署名（RRSIG）レコードを適切に返すかどうかをテストします。
Prerequisite: Supports the DO bit.
前提条件：DOビットをサポートします。
Test: Send a request to the resolver under test for an A record for a known existing domain in a DNSSEC-signed zone, such as good-a.test.example.com. Set the DO bit in the outgoing query.
テスト：DNSSEC署名済みゾーン（good-a.test.example.comなど）内の既知の既存ドメインのAレコードについて、テスト中のリゾルバーにリクエストを送信します。発信クエリにDOビットを設定します。
SUCCESS: A DNS response was received that contains at least one RRSIG record.
成功：少なくとも1つのRRSIGレコードを含むDNS応答が受信されました。
Purpose: This tests whether a resolver can query for and receive a DNSKEY record from a signed zone.
目的：これは、リゾルバーが署名済みゾーンに対してDNSKEYレコードを照会して受信できるかどうかをテストします。
Prerequisite: Supports the DO bit.
前提条件：DOビットをサポートします。
Test: Send a request to the resolver under test for a DNSKEY record that is known to exist in a signed zone, such as test.example.com/ DNSKEY. Set the DO bit in the outgoing query.
テスト：test.example.com/ DNSKEYなどの署名済みゾーンに存在することがわかっているDNSKEYレコードについて、テスト中のリゾルバーにリクエストを送信します。発信クエリにDOビットを設定します。
SUCCESS: A DNS response was received that contains a DNSKEY record in the answer section.
成功：応答セクションにDNSKEYレコードを含むDNS応答が受信されました。
Note: Some DNSKEY Resource Record Sets (RRsets) are large and, if the network path has problems with large answers, this query may result in either a false positive or a false negative. In general, the DNSKEY queried for should be small enough to fit into a 1220-byte answer to avoid a false negative result when TCP is disabled. However, querying many zones will result in answers greater than 1220 bytes, so DNS over TCP MUST be available for DNSSEC use in general.
注：一部のDNSKEYリソースレコードセット（RRset）は大きく、ネットワークパスに大きな回答の問題がある場合、このクエリの結果、誤検知または誤検知が発生する可能性があります。一般に、照会されるDNSKEYは、TCPが無効になっている場合の偽陰性の結果を回避するために、1220バイトの回答に収まるほど小さい必要があります。ただし、多くのゾーンに対してクエリを実行すると、1220バイトを超える回答が返されるため、一般にDNSSECで使用できるようにDNS over TCPを使用できる必要があります。
Purpose: This tests whether a resolver can query for and receive a DS record from a signed zone.
目的：これは、リゾルバーが署名済みゾーンに対してDSレコードを照会して受信できるかどうかをテストします。
Prerequisite: Supports the DO bit.
前提条件：DOビットをサポートします。
Test: Send a request to the resolver under test for a DS record that is known to exist in a signed zone, such as test.example.com/DS. Set the DO bit in the outgoing query.
テスト：test.example.com/DSなどの署名済みゾーンに存在することがわかっているDSレコードについて、テスト中のリゾルバーにリクエストを送信します。発信クエリにDOビットを設定します。
SUCCESS: A DNS response was received that contains a DS record in the answer section.
成功：回答セクションにDSレコードを含むDNS応答が受信されました。
Purpose: This tests whether a resolver properly returns NextSECure (NSEC) records for a nonexisting domain in a DNSSEC-signed zone.
目的：これは、リゾルバーがDNSSEC署名ゾーン内の存在しないドメインのNextSECure（NSEC）レコードを適切に返すかどうかをテストします。
Prerequisite: Supports the DO bit.
前提条件：DOビットをサポートします。
Test: Send a request to the resolver under test for an A record that is known to not exist in an NSEC-signed zone, such as nonexistent.test.example.com. Set the DO bit in the outgoing query.
テスト：nonexistent.test.example.comなどのNSEC署名ゾーンに存在しないことがわかっているAレコードについて、テスト中のリゾルバーにリクエストを送信します。発信クエリにDOビットを設定します。
SUCCESS: A DNS response was received that contains an NSEC record.
成功：NSECレコードを含むDNS応答が受信されました。
Note: The query issued in this test MUST be sent to an NSEC-signed zone. Getting back appropriate NSEC3 records does not indicate a failure, but a bad test.
注：このテストで発行されたクエリは、NSEC署名ゾーンに送信する必要があります。適切なNSEC3レコードを取り戻すことは、失敗を示すのではなく、悪いテストです。
Purpose: This tests whether a resolver properly returns NSEC3 records ([RFC5155]) for a nonexisting domain in a DNSSEC-signed zone.
目的：これは、リゾルバーがDNSSEC署名ゾーンに存在しないドメインのNSEC3レコード（[RFC5155]）を正しく返すかどうかをテストします。
Prerequisite: Supports the DO bit.
前提条件：DOビットをサポートします。
Test: Send a request to the resolver under test for an A record that is known to be nonexistent in a zone signed using NSEC3, such as nonexistent.nsec3-ns.test.example.com. Set the DO bit in the outgoing query.
テスト：nonexistent.nsec3-ns.test.example.comなど、NSEC3を使用して署名されたゾーンに存在しないことがわかっているAレコードについて、テスト中のリゾルバーにリクエストを送信します。発信クエリにDOビットを設定します。
SUCCESS: A DNS response was received that contains an NSEC3 record.
成功：NSEC3レコードを含むDNS応答が受信されました。
Bonus: If the AD bit is set, this validator supports algorithm 7 (RSASHA1-NSEC3-SHA1).
おまけ：ADビットが設定されている場合、このバリデーターはアルゴリズム7（RSASHA1-NSEC3-SHA1）をサポートします。
Note: The query issued in this test MUST be sent to an NSEC3-signed zone. Getting back appropriate NSEC records does not indicate a failure, but a bad test.
注：このテストで発行されたクエリは、NSEC3署名ゾーンに送信する必要があります。適切なNSECレコードを取り戻すことは、失敗ではなく、悪いテストを示しています。
Purpose: This tests whether a resolver can query for an A record in a zone with a known DNAME referral for the record's parent.
目的：これは、リゾルバーが、レコードの親の既知のDNAME紹介を持つゾーンのAレコードを照会できるかどうかをテストします。
Test: Send a request to the resolver under test for an A record that is known to exist in a signed zone within a DNAME-referral child zone, such as good-a.dname-good-ns.test.example.com.
テスト：DNAME参照の子ゾーン内の署名済みゾーン（good-a.dname-good-ns.test.example.comなど）に存在することがわかっているAレコードについて、テスト中のリゾルバーにリクエストを送信します。
SUCCESS: A DNS response was received that contains a DNAME in the answer section. An RRSIG MUST also be received in the answer section that covers the DNAME record.
成功：応答セクションにDNAMEを含むDNS応答が受信されました。 RNAMEは、DNAMEレコードをカバーする回答セクションでも受信する必要があります。
Purpose: To see if a validating resolver is ignoring DNSSEC validation failures.
目的：検証するリゾルバーがDNSSEC検証エラーを無視しているかどうかを確認します。
Prerequisite: Supports the AD bit.
前提条件：ADビットをサポートします。
Test: Ask for data from a broken DNSSEC delegation, such as badsign-a.test.example.com.
テスト：badsign-a.test.example.comなど、壊れたDNSSEC委任からのデータを要求します。
SUCCESS: A reply was received with the Rcode set to SERVFAIL.
成功：RcodeがSERVFAILに設定された応答が受信されました。
Purpose: Some DNS Resolvers/gateways only support some Resource Record Types (RRtypes). This causes problems for applications that need recently defined types.
目的：一部のDNSリゾルバー/ゲートウェイは、一部のリソースレコードタイプ（RRtype）のみをサポートします。これにより、最近定義されたタイプを必要とするアプリケーションで問題が発生します。
Prerequisite: Supports UDP or TCP.
前提条件：UDPまたはTCPをサポートします。
Test: Send a request for a recently defined type or an unknown type in the 20000-22000 range, that resolves to a server that will return an answer for all types, such as alltypes.example.com (a server today that supports this is alltypes.res.dnssecready.org).
テスト：最近定義されたタイプまたは20000〜22000の範囲の不明なタイプのリクエストを送信します。これは、alltypes.example.comなどのすべてのタイプの応答を返すサーバーに解決されます（これをサポートする今日のサーバーは、 alltypes.res.dnssecready.org）。
SUCCESS: A DNS response was retrieved that contains the type requested in the answer section.
成功：応答セクションで要求されたタイプを含むDNS応答が取得されました。
If needed, a Host Validator may need to make direct queries to authoritative servers or known Open Recursive Resolvers in order to collect data. To do that, a number of key network features MUST be functional.
必要に応じて、データを収集するために、ホストバリデーターが権限のあるサーバーまたは既知のOpen Recursive Resolverに直接クエリを行う必要がある場合があります。そのためには、いくつかの主要なネットワーク機能が機能している必要があります。
Purpose: This tests basic UDP functionality to outside the local network.
目的：ローカルネットワークの外部への基本的なUDP機能をテストします。
Test: A DNS request is sent to a known distant authoritative server for a record known to be within that server's authoritative data. Example: send a query to the address of ns1.test.example.com for the good-a.test.example.com/A record.
テスト：DNS要求は、そのサーバーの信頼できるデータ内にあることがわかっているレコードについて、既知の離れた信頼できるサーバーに送信されます。例：good-a.test.example.com/Aレコードのクエリをns1.test.example.comのアドレスに送信します。
SUCCESS: A DNS response was received that contains an A record in the answer section.
成功：回答セクションにAレコードを含むDNS応答が受信されました。
Note: An implementation can use the local resolvers for determining the address of the name server that is authoritative for the given zone. The recursive bit MAY be set for this request, but it does not need to be.
注：実装では、ローカルリゾルバーを使用して、特定のゾーンに対して権限のあるネームサーバーのアドレスを決定できます。このリクエストに対して再帰ビットを設定してもかまいませんが、そうする必要はありません。
Purpose: This tests if the local network can receive fragmented UDP answers.
目的：ローカルネットワークが断片化されたUDP応答を受信できるかどうかをテストします。
Prerequisite: Local UDP traffic > 1500 bytes in size is possible.
前提条件：サイズが1500バイトを超えるローカルUDPトラフィックが可能です。
Test: A DNS request is sent over UDP to a known distant DNS address asking for a record that has an answer larger than 2000 bytes. For example, send a query for the test.example.com/DNSKEY record with the DO bit set in the outgoing query.
テスト：2000バイトを超える回答を持つレコードを要求するDNS要求がUDP経由で既知の遠隔DNSアドレスに送信されます。たとえば、送信クエリでDOビットが設定されたtest.example.com/DNSKEYレコードのクエリを送信します。
SUCCESS: A DNS response was received that contains the large answer.
成功：大きな回答を含むDNS応答が受信されました。
Note: A failure in getting large answers over UDP is not a serious problem if TCP is working.
注：TCPが機能している場合、UDPを介して大きな応答を取得できなくても、重大な問題にはなりません。
Purpose: This tests basic TCP functionality to outside the local network.
目的：ローカルネットワークの外部への基本的なTCP機能をテストします。
Test: A DNS request is sent over TCP to a known distant authoritative server for a record known to be within that server's authoritative data. Example: send a query to the address of ns1.test.example.com for the good-a.test.example.com/A record.
テスト：DNS要求は、TCPを介して、遠く離れた既知の信頼できるサーバーに送信され、そのサーバーの信頼できるデータ内にあることがわかっています。例：good-a.test.example.com/Aレコードのクエリをns1.test.example.comのアドレスに送信します。
SUCCESS: A DNS response was received that contains an A record in the answer section.
成功：回答セクションにAレコードを含むDNS応答が受信されました。
Note: An implementation can use the local resolvers for determining the address of the name server that is authoritative for the given zone. The recursive bit MAY be set for this request, but it does not need to be.
注：実装では、ローカルリゾルバーを使用して、特定のゾーンに対して権限のあるネームサーバーのアドレスを決定できます。このリクエストに対して再帰ビットを設定してもかまいませんが、そうする必要はありません。
Purpose: This test can check what algorithm combinations are supported.
目的：このテストでは、サポートされているアルゴリズムの組み合わせを確認できます。
Prerequisite: Supports the AD bit for Algorithms 5 and/or 8.
前提条件：アルゴリズム5および8のADビットをサポートします。
Test: A DNS request is sent over UDP to the resolver under test for a known combination of the DS algorithm number (N) and DNSKEY algorithm number (M) of the example form ds-N.alg-M-nsec.test.example.com. Examples:
テスト：ds-N.alg-M-nsec.test.exampleの形式のサンプルのDSアルゴリズム番号（N）とDNSKEYアルゴリズム番号（M）の既知の組み合わせについて、DNS要求がUDP経由でテスト中のリゾルバーに送信されます。 .com。例：
ds-2.alg-13-nsec.test.example.com TXT or ds-4.alg-13-nsec3.test.example.com TXT
ds-2.alg-13-nsec.test.example.com TXTまたはds-4.alg-13-nsec3.test.example.com TXT
SUCCESS: A DNS response is received with the AD bit set and with a matching record type in the answer section.
成功：ADビットがセットされ、回答セクションに一致するレコードタイプが含まれるDNS応答が受信されます。
Note: For algorithms 6 and 7, NSEC is not defined; thus, a query for alg-M-nsec3 is required. Similarly, NSEC3 is not defined for algorithms 1, 3, and 5. Furthermore, algorithms 2, 4, 9, and 11 do not currently have definitions for signed zones.
注：アルゴリズム6および7の場合、NSECは定義されていません。したがって、alg-M-nsec3のクエリが必要です。同様に、NSEC3はアルゴリズム1、3、および5に対して定義されていません。さらに、アルゴリズム2、4、9、および11には現在、署名済みゾーンの定義がありません。
Some conclusions can be drawn from the results of the above tests in an "aggregated" form. This section defines some labels to assign to a resolver under test given the results of the tests run against them.
上記のテストの結果から、「集約された」形式でいくつかの結論を導き出すことができます。このセクションでは、テストに対して実行されたテストの結果を前提として、テスト中のリゾルバーに割り当てるいくつかのラベルを定義します。
This section will group and label certain common results.
このセクションでは、特定の一般的な結果をグループ化してラベルを付けます。
Resolvers are classified into the following broad behaviors:
リゾルバーは、次の広範な動作に分類されます。
Validator: The resolver passes all DNSSEC tests and had the AD bit appropriately set.
バリデーター：リゾルバーはすべてのDNSSECテストに合格し、ADビットが適切に設定されていました。
DNSSEC-Aware: The resolver passes all DNSSEC tests, but it does not appropriately set the AD bit on answers, indicating it is not validating. A Host Validator will function fine using this resolver as a forwarder.
DNSSEC対応：リゾルバーはすべてのDNSSECテストに合格しますが、回答にADビットを適切に設定しないため、検証されないことが示されます。ホストバリデーターは、このリゾルバーをフォワーダーとして使用すると正常に機能します。
Non-DNSSEC-Capable: The resolver is not DNSSEC-aware and will make it hard for a Host Validator to operate behind it. It MAY be usable to query for data that is in known insecure sections of the DNS tree.
非DNSSEC対応：リゾルバーはDNSSECに対応していないため、ホストバリデーターがその背後で動作することが困難になります。 DNSツリーの既知の安全でないセクションにあるデータのクエリに使用できる場合があります。
Not a DNS Resolver: This is an improperly behaving resolver and should not be used at all.
DNSリゾルバーではありません：これは不適切に動作するリゾルバーであり、まったく使用しないでください。
While it would be great if all resolvers fell cleanly into one of the broad categories above, that is not the case. For that reason, it is necessary to augment the classification with a more descriptive result. This is done by adding the word "Partial" in front of Validator/DNSSEC-aware classifications, followed by sub-descriptors of what is not working.
すべてのリゾルバーが上記の広いカテゴリーの1つにきれいに分類されれば素晴らしいことですが、そうではありません。そのため、より記述的な結果で分類を拡張する必要があります。これは、Validator / DNSSEC対応の分類の前に「部分的」という単語を追加し、その後に機能していないもののサブ記述子を追加することによって行われます。
Unknown: Failed the unknown test
不明：不明なテストに失敗しました
DNAME: Failed the DNAME test
DNAME：DNAMEテストに失敗しました
NSEC3: Failed the NSEC3 test
NSEC3：NSEC3テストに失敗しました
TCP: TCP not available
TCP：TCPは利用できません
SlowBig: UDP is size limited, but TCP fallback works
SlowBig：UDPにはサイズ制限がありますが、TCPフォールバックは機能します
NoBig: TCP not available and UDP is size limited
NoBig：TCPは使用できず、UDPはサイズが制限されています
Permissive: Passes data known to fail validation
許容：検証に失敗することがわかっているデータを渡します
The goal of this document is to tie the above tests and aggregations to avoidance practices; however, the document does not specify exactly how to do that.
このドキュメントの目的は、上記のテストと集計を回避策に結びつけることです。ただし、ドキュメントではその方法を正確に指定していません。
Once we have determined what level of support is available in the network, we can determine what must be done in order to effectively act as a validating resolver. This section discusses some of the options available given the results from the previous sections.
ネットワークで利用可能なサポートのレベルを決定したら、検証リゾルバーとして効果的に機能するために何をしなければならないかを決定できます。このセクションでは、前のセクションの結果を踏まえて利用可能なオプションのいくつかについて説明します。
The general fallback approach can be described by the following sequence:
一般的なフォールバックアプローチは、次のシーケンスで説明できます。
If the resolver is labeled as "Validator" or "DNSSEC-aware":
リゾルバーが「バリデーター」または「DNSSEC対応」としてラベル付けされている場合：
Send queries through this resolver and perform local validation on the results.
このリゾルバーを介してクエリを送信し、結果に対してローカル検証を実行します。
If validation fails, try the next resolver.
検証が失敗した場合は、次のリゾルバーを試してください。
Else, if the resolver is labeled "Not a DNS Resolver" or "Non-DNSSEC-capable":
それ以外の場合、リゾルバーが「DNSリゾルバーではない」または「非DNSSEC対応」とラベル付けされている場合：
Mark it as unusable and try the next resolver.
使用不可としてマークし、次のリゾルバーを試してください。
Else if no more resolvers are configured and if direct queries are supported:
それ以外にリゾルバが構成されておらず、直接クエリがサポートされている場合：
1. Try iterating from the Root.
1. ルートから反復してみてください。
2. If the answer is SECURE/BOGUS: Return the result of the iteration.
2. 答えがSECURE / BOGUSの場合：反復の結果を返します。
3. If the answer is INSECURE: Re-query "Non-DNSSEC-capable" servers and return answers from them without the AD bit set to the client.
3. 回答がINSECUREの場合：「非DNSSEC対応」サーバーに再クエリを実行し、ADビットをクライアントに設定せずに、サーバーから回答を返します。
This will increase the likelihood that split-view unsigned answers are found.
これにより、分割ビューの署名されていない回答が見つかる可能性が高くなります。
Else:
そうしないと：
Return an error code and log a failure.
エラーコードを返し、失敗をログに記録します。
While attempting resolution through a particular recursive name server with a particular transport method that worked, any transport-specific parameters MUST be remembered in order to avoid any unnecessary fallback attempts.
機能した特定のトランスポートメソッドを使用して特定の再帰ネームサーバーを介して解決を試みる間、不要なフォールバックの試行を回避するために、トランスポート固有のパラメーターを覚えておく必要があります。
Transport-specific parameters MUST also be remembered for each authoritative name server that is queried while performing an iterative mode lookup.
トランスポート固有のパラメーターは、反復モードのルックアップを実行中に照会される各権威ネームサーバーについても覚えておく必要があります。
Any transport settings that are remembered for a particular name server MUST be periodically refreshed; they should also be refreshed when an error is encountered as described below.
特定のネームサーバーで記憶されているトランスポート設定は、定期的に更新する必要があります。以下で説明するように、エラーが発生した場合も更新する必要があります。
For a stub resolver, problems with the name server can manifest themselves under the following types of error conditions:
スタブリゾルバの場合、ネームサーバーの問題は、次のタイプのエラー状態で発生する可能性があります。
o No Response, error response, or missing DNSSEC metadata
o 応答なし、エラー応答、またはDNSSECメタデータの欠落
o Illegal Response: An illegal response is received, which prevents the validator from fetching all the necessary records required for constructing an authentication chain. This could result when referral loops are encountered, when any of the antecedent zone delegations are lame, when aliases are erroneously followed for certain RRtypes (such as Start of Authority (SOA), DNSKEYs, or DS records), or when resource records for certain types (e.g., DS) are returned from a zone that is not authoritative for such records.
o 不正な応答：不正な応答が受信されました。これにより、バリデーターが認証チェーンの構築に必要なすべての必要なレコードをフェッチできなくなります。これは、参照ループが発生した場合、先行ゾーンの委任のいずれかが不完全な場合、特定のRRtype（Start of Authority（SOA）、DNSKEY、DSレコードなど）のエイリアスが誤って追跡された場合、または特定のリソースレコードが発生した場合に発生する可能性があります。タイプ（DSなど）は、そのようなレコードに対して権限のないゾーンから返されます。
o Bogus Response: A Bogus Response is received, when the cryptographic assertions in the authentication chain do not validate properly.
o 偽の応答：認証チェーンの暗号化アサーションが適切に検証されない場合、偽の応答が受信されます。
For each of the above error conditions, a validator MAY adopt the following dynamic fallback technique, preferring a particular approach if it is known to work for a given name server or zone from previous attempts.
上記の各エラー条件について、バリデーターは次の動的フォールバック手法を採用してもよい（MAY）、特定のネームサーバーまたはゾーンで以前の試行から機能することがわかっている場合は、特定のアプローチを優先します。
o No response, error response, or missing DNSSEC metadata:
o 応答がない、エラー応答がある、またはDNSSECメタデータがない：
* Retry with different EDNS0 sizes (4096, 1492, or None).
* 異なるEDNS0サイズ（4096、1492、またはなし）で再試行します。
* Retry with TCP only.
* TCPのみで再試行します。
* Perform an iterative query starting from the Root if the previous error was returned from a lookup that had recursion enabled.
* 再帰が有効になっているルックアップから前のエラーが返された場合は、ルートから開始して反復クエリを実行します。
* Retry using an alternative transport method, if this alternative method is known (configured) to be supported by the name server in question.
* 問題のネームサーバーによってサポートされていることがわかっている（構成されている）場合は、代替のトランスポートメソッドを使用して再試行してください。
o Illegal Response
o 違法な対応
* Perform an iterative query starting from the Root if the previous error was returned from a lookup that had recursion enabled.
* 再帰が有効になっているルックアップから前のエラーが返された場合は、ルートから開始して反復クエリを実行します。
* Check if any of the antecedent zones up to the closest configured trust anchor are Insecure.
* 最も近い構成済みトラストアンカーまでの先行ゾーンが安全でないかどうかを確認します。
o Bogus Response
o 偽の応答
* Perform an iterative query starting from the Root if the previous error was returned from a lookup that had recursion enabled.
* 再帰が有効になっているルックアップから前のエラーが返された場合は、ルートから開始して反復クエリを実行します。
For each fallback technique, attempts to reach multiple potential name servers should be skewed such that the next name server is tried when the previous one returns an error or a timeout is reached.
フォールバック手法ごとに、複数の潜在的なネームサーバーに到達する試みは、前のネームサーバーがエラーを返すかタイムアウトに達したときに次のネームサーバーが試行されるように、スキューする必要があります。
The validator SHOULD remember, in its zone-specific fallback cache, any broken behavior identified for a particular zone for a duration of that zone's SOA-negative TTL.
バリデーターは、そのゾーン固有のフォールバックキャッシュで、そのゾーンのSOA負のTTLの期間中、特定のゾーンに対して識別されたすべての壊れた動作を覚えておく必要があります。
The validator MAY place name servers that exhibit broken behavior into a blacklist and bypass these name servers for all zones that they are authoritative for. The validator MUST time out entries in this name server blacklist periodically, where this interval could be set to be the same as the DNSSEC BAD cache default TTL.
バリデーターは、壊れた動作を示すネームサーバーをブラックリストに入れて、権限のあるすべてのゾーンでこれらのネームサーバーをバイパスする場合があります。バリデーターはこのネームサーバーのブラックリストのエントリを定期的にタイムアウトしなければなりません（MUST）。この間隔はDNSSEC BADキャッシュのデフォルトTTLと同じになるように設定できます。
It may be possible to use Non-DNSSEC-Capable caching resolvers in careful ways if maximum optimization is desired. This section describes some of the advanced techniques that could be implemented to use a resolver in at least a minimal way. Most of the time, this would be unnecessary; the exception being the case where none of the resolvers are fully compliant and, thus, the choice would be to use them at least minimally or not at all (and no caching benefits would be available).
最大の最適化が必要な場合、非DNSSEC対応のキャッシングリゾルバーを慎重に使用することが可能です。このセクションでは、少なくとも最小限の方法でリゾルバーを使用するために実装できるいくつかの高度な手法について説明します。ほとんどの場合、これは不要です。例外は、完全に準拠しているリゾルバーがない場合であり、したがって、少なくとも最小限に使用するか、まったく使用しないかを選択することになります（キャッシュの利点はありません）。
If a resolver is Non-DNSSEC-Capable but a section of the DNS tree has been determined to be Insecure [RFC4035], then queries to this section of the tree MAY be sent through the Non-DNSSEC-Capable caching resolver.
リゾルバーが非DNSSEC対応であるが、DNSツリーのセクションが安全でないと判断された場合[RFC4035]、ツリーのこのセクションへのクエリは、非DNSSEC対応のキャッシュリゾルバーを介して送信される場合があります。
Resolvers that understand DNSSEC generally, and understand NSEC but not NSEC3, are partially usable. These resolvers generally also lack support for unknown types, rendering them mostly useless and to be avoided.
DNSSECを一般的に理解し、NSECを理解するがNSEC3を理解しないリゾルバは、部分的に使用可能です。これらのリゾルバーは、一般に不明なタイプのサポートも欠いているため、ほとんど役に立たず、回避する必要があります。
A number of scenarios will produce either short-term or long-term connectivity issues with respect to DNSSEC validation. Consider the following cases:
多くのシナリオでは、DNSSEC検証に関して短期的または長期的な接続の問題が発生します。以下のケースを検討してください。
Time Synchronization: Time synchronization problems can occur when a device has been off for a period of time and the clock is no longer in close synchronization with "real time" or when a device always has the clock set to the same time during start-up. This will cause problems when the device needs to resolve its source of time synchronization, such as "ntp.example.com".
時刻同期：デバイスが一定期間オフになっていて、クロックが「リアルタイム」と同期していない場合、または起動時にデバイスのクロックが常に同じ時刻に設定されている場合、時刻同期の問題が発生する可能性があります。 。これにより、デバイスが「ntp.example.com」などの時刻同期のソースを解決する必要がある場合に問題が発生します。
Changing Network Properties: A newly established network connection may change state shortly after an HTTP-based paywall authentication system has been used. This is especially common in hotel, airport, and coffee-shop networks where DNSSEC, validation, and even DNS are not functional until the user proceeds through a series of forced web pages used to enable their network. The tests in Section 3 will produce very different results before and after the network authorization has succeeded. APIs exist on many operating systems to detect initial network device status changes, such as right after DHCP has finished, but few (none?) exist to detect that authentication through a paywall has succeeded.
ネットワークプロパティの変更：新しく確立されたネットワーク接続は、HTTPベースのペイウォール認証システムが使用された直後に状態を変更する場合があります。これは、ホテル、空港、コーヒーショップのネットワークで特に一般的です。DNSSEC、検証、さらにはDNSも、ユーザーがネットワークを有効にするために使用される一連の強制Webページを通過するまで機能しません。セクション3のテストでは、ネットワーク認証が成功する前後で、非常に異なる結果が生成されます。 DHCPが終了した直後など、初期のネットワークデバイスステータスの変化を検出するAPIは多くのオペレーティングシステムに存在しますが、ペイウォールを介した認証が成功したことを検出するAPIはほとんどありません（なし？）。
There are only two choices when situations like this happen:
このような状況が発生した場合、2つの選択肢しかありません。
Continue to perform DNSSEC processing, which will likely result in all DNS requests failing. This is the most secure route, but causes the most operational grief for users.
DNSSEC処理を続行します。これにより、すべてのDNS要求が失敗する可能性があります。これは最も安全なルートですが、ユーザーにとって最も運用上の問題を引き起こします。
Turn off DNSSEC support until the network proves to be usable. This allows the user to continue using the network, at the cost of security. It also allows for a denial-of-service attack if a man-in-the-middle can convince a device that DNSSEC is impossible.
ネットワークが使用可能であることが証明されるまで、DNSSECサポートをオフにします。これにより、ユーザーはセキュリティを犠牲にしてネットワークを使い続けることができます。また、中間者がDNSSECが不可能であることをデバイスに確信させることができる場合、サービス拒否攻撃を可能にします。
If the Host Validator detects that DNSSEC resolution is not possible, it SHOULD log the event and/or SHOULD report an error to the user. In the case where there is no user, no reporting can be performed; thus, the device MAY have a policy of action, like continue or fail. Until middleboxes allow DNSSEC-protected information to traverse them consistently, software implementations may need to offer this choice to let users pick the security level they require. Note that continuing without DNSSEC protection in the absence of a notification or report could lead to situations where users assume a level of security that does not exist.
ホストバリデーターは、DNSSEC解決が不可能であることを検出した場合、イベントをログに記録するか、ユーザーにエラーを報告する必要があります（SHOULD）。ユーザーがいない場合、レポートは実行できません。したがって、デバイスは続行または失敗などのアクションのポリシーを持つことができます。ミドルボックスによってDNSSECで保護された情報が一貫してそれらを通過できるようになるまで、ソフトウェア実装は、ユーザーが必要なセキュリティレベルを選択できるように、この選択を提供する必要がある場合があります。通知またはレポートがない場合にDNSSEC保護なしで続行すると、ユーザーが存在しないセキュリティレベルを想定する状況につながる可能性があることに注意してください。
The quick tests defined below make the assumption that the questions to be asked are of a real resolver; and the only real question is: "How complete is the DNSSEC support?". This quick test has been implemented in a few programs developed at IETF hackathons at IETF 93 and IETF 94. The programs use a common grading method. For each question that returns an expected answer, the resolver gets a point. If the AD bit is set as expected, the resolver gets a second point.
以下で定義されている簡単なテストは、尋ねられる質問が本当の解決者のものであるという前提を持っています。そして唯一の真の質問は、「DNSSECサポートはどの程度完全なのか？」です。このクイックテストは、IETF 93およびIETF 94のIETFハッカソンで開発されたいくつかのプログラムに実装されています。プログラムは、一般的な評価方法を使用しています。予想される回答を返す質問ごとに、リゾルバーはポイントを取得します。 ADビットが期待どおりに設定されている場合、リゾルバーは2番目のポイントを取得します。
Query: realy-doesnotexist.test.example.com. A
クエリ：realy-doesnotexist.test.example.com。あ
Answer: RCODE= NXDOMAIN, Empty Answer, Authority: NSEC-proof
Query: alg-8-nsec3.test.example.com. SOA
クエリ：alg-8-nsec3.test.example.com。 SOA
Answer: RCODE= 0, Answer: SOA record
Query: alg-13-nsec.test.example.com. SOA
クエリ：alg-13-nsec.test.example.com。 SOA
Answer: RCODE= 0, Answer: SOA record
Query: dnssec-failed.test.example.com. SOA
クエリ：dnssec-failed.test.example.com。 SOA
Answer: RCODE= SERVFAIL, empty answer, and authority, AD=0
This document discusses problems that may occur while deploying the DNSSEC protocol. It describes what may be possible to help detect and mitigate these problems. Following the outlined suggestions will result in a more secure DNSSEC-operational environment than if DNSSEC was simply disabled.
このドキュメントでは、DNSSECプロトコルの展開中に発生する可能性のある問題について説明します。これらの問題の検出と軽減に役立つ可能性のあることについて説明します。概説された提案に従うと、DNSSECを単に無効にした場合よりも、より安全なDNSSEC運用環境が得られます。
[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>。
[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, <http://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月、< http://www.rfc-editor.org/info/rfc4035>。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786] Abley、J。およびK. Lindqvist、「Operation of Anycast Services」、BCP 126、RFC 4786、DOI 10.17487 / RFC4786、2006年12月、<http://www.rfc-editor.org/info/rfc4786> 。
[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, <http://www.rfc-editor.org/info/rfc5155>.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<http： //www.rfc-editor.org/info/rfc5155>。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <http://www.rfc-editor.org/info/rfc5625>.
[RFC5625] Bellis、R。、「DNSプロキシ実装ガイドライン」、BCP 152、RFC 5625、DOI 10.17487 / RFC5625、2009年8月、<http://www.rfc-editor.org/info/rfc5625>。
Acknowledgments
謝辞
We thank the IESG and DNSOP working group members for their extensive comments and suggestions.
IESGおよびDNSOPワーキンググループメンバーの広範なコメントと提案に感謝します。
Authors' Addresses
著者のアドレス
Wes Hardaker USC/ISI P.O. Box 382 Davis, CA 95617 United States of America
うぇｓ はｒだけｒ うＳＣ／いし Ｐ。お。 ぼｘ ３８２ だゔぃｓ、 か ９５６１７ うにてｄ Ｓたてｓ おｆ あめりか
Email: ietf@hardakers.net
Olafur Gudmundsson CloudFlare San Francisco, CA 94107 United States of America
Olafur Gudmundsson CloudFlareサンフランシスコ、カリフォルニア州94107アメリカ合衆国
Email: olafur+ietf@cloudflare.com
Suresh Krishnaswamy Parsons 7110 Samuel Morse Dr Columbia, MD 21046 United States of America
Suresh Krishnaswamy Parsons 7110 Samuel Morse Drコロンビア、MD 21046アメリカ合衆国
Email: suresh@tislabs.com