[要約] 要約：RFC 8020は、DNSのNXDOMAIN応答に関する問題を解決するためのガイドラインです。 目的：このRFCの目的は、NXDOMAIN応答の正確な定義と、その応答の使用方法に関する一貫性を提供することです。
Internet Engineering Task Force (IETF) S. Bortzmeyer
Request for Comments: 8020 AFNIC
Updates: 1034, 2308 S. Huque
Category: Standards Track Verisign Labs
ISSN: 2070-1721 November 2016
NXDOMAIN: There Really Is Nothing Underneath
NXDOMAIN：下には何もありません
Abstract
概要
This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
このドキュメントでは、DNSリゾルバーがNXDOMAINの応答コードを含む応答を受け取ったときに、拒否されたドメイン名と、その下にあるすべての名前が存在しないことを明確に述べています。
This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.
このドキュメントでは、RFC 1034を明確にし、RFC 2308の一部を変更します。両方を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8020.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8020で入手できます。
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 and Background .....................................2
1.1. Terminology ................................................3
2. Rules ...........................................................3
3. Updates to RFCs .................................................5
3.1. Updates to RFC 1034 ........................................5
3.2. Updates to RFC 2308 ........................................5
4. Benefits ........................................................5
5. Possible Issues .................................................6
6. Implementation Considerations ...................................6
7. Security Considerations .........................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
Appendix A. Why can't we just use the owner name of the returned
SOA? ...................................................9
Appendix B. Related Approaches .....................................9
Acknowledgments ....................................................9
Authors' Addresses ................................................10
The DNS protocol [RFC1035] defines response code 3 as "Name Error", or "NXDOMAIN" [RFC2308], which means that the queried domain name does not exist in the DNS. Since domain names are represented as a tree of labels ([RFC1034], Section 3.1), nonexistence of a node implies nonexistence of the entire subtree rooted at this node.
DNSプロトコル[RFC1035]は、応答コード3を「名前エラー」または「NXDOMAIN」[RFC2308]として定義しています。これは、照会されたドメイン名がDNSに存在しないことを意味します。ドメイン名はラベルのツリーとして表されるため（[RFC1034]、セクション3.1）、ノードが存在しないことは、このノードをルートとするサブツリー全体が存在しないことを意味します。
The DNS iterative resolution algorithm precisely interprets the NXDOMAIN signal in this manner. If it encounters an NXDOMAIN response code from an authoritative server, it immediately stops iteration and returns the NXDOMAIN response to the querier.
DNS反復解決アルゴリズムは、この方法でNXDOMAIN信号を正確に解釈します。権限のあるサーバーからのNXDOMAIN応答コードを検出すると、すぐに反復を停止し、NXDOMAIN応答をクエリアに返します。
However, in most known existing resolvers today, a cached nonexistence for a domain is not considered "proof" that there can be no child domains underneath. This is due to an ambiguity in [RFC1034] that failed to distinguish Empty Non-Terminal (ENT) names ([RFC7719]) from nonexistent names (Section 3.1). The distinction became especially important for the development of DNSSEC, which provides proof of nonexistence. [RFC4035], Section 3.1.3.2, describes how security-aware authoritative name servers make the distinction, but no existing RFCs describe the behavior for recursive name servers.
ただし、今日知られているほとんどの既存のリゾルバーでは、ドメインのキャッシュされた非存在は、その下に子ドメインがないことの「証拠」とは見なされません。これは、空の非ターミナル（ENT）名（[RFC7719]）と存在しない名前（セクション3.1）を区別できなかった[RFC1034]のあいまいさが原因です。この区別は、存在しないことの証明を提供するDNSSECの開発にとって特に重要になりました。 [RFC4035]のセクション3.1.3.2は、セキュリティ対応の権威ネームサーバーがどのように区別するかについて説明していますが、既存のRFCは再帰的なネームサーバーの動作を説明していません。
This document specifies that an NXDOMAIN response for a domain name means that no child domains underneath the queried name exist either; furthermore, it means that DNS resolvers should interpret cached nonexistence in this manner. Since the domain names are organized in a tree, it is a simple consequence of the tree structure: nonexistence of a node implies nonexistence of the entire subtree rooted at this node.
このドキュメントでは、ドメイン名に対するNXDOMAIN応答は、照会された名前の下にある子ドメインも存在しないことを意味することを指定しています。さらに、DNSリゾルバーはキャッシュされた非存在をこのように解釈する必要があることを意味します。ドメイン名はツリーに編成されているため、ツリー構造の単純な結果です。ノードが存在しないことは、このノードをルートとするサブツリー全体が存在しないことを意味します。
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]で説明されているように解釈されます。
"QNAME": defined in [RFC1034] and in [RFC1035], Section 4.1.2, but, because [RFC2308] provides a different definition, we repeat the original one here: the QNAME is the domain name in the question section.
「QNAME」：[RFC1034]と[RFC1035]のセクション4.1.2で定義されていますが、[RFC2308]は別の定義を提供するため、ここでは元の定義を繰り返します。QNAMEは質問セクションのドメイン名です。
"Denied name": the domain name whose existence has been denied by a response RCODE of NXDOMAIN. In most cases, it is the QNAME but, because of [RFC6604], it is not always the case.
「拒否された名前」：NXDOMAINの応答RCODEによって存在が拒否されたドメイン名。ほとんどの場合、それはQNAMEですが、[RFC6604]のため、常にそうであるとは限りません。
Other terms are defined in [RFC1034], [RFC1035], and (like NXDOMAIN itself) in the more recent [RFC7719].
他の用語は、[RFC1034]、[RFC1035]、および（NXDOMAIN自体と同様に）より最近の[RFC7719]で定義されています。
The domain name space is conceptually defined in terms of a tree structure. The implementation of a DNS resolver/cache MAY use a tree or other data structures. The cache being a subset of the data in the domain name space, it is much easier to reason about it in terms of that tree structure and to describe things in those terms (names under/above, descendant names, subtrees, etc.). In fact, the DNS algorithm description in [RFC1034] even states an assumption that the cache is a tree structure, so the precedent is already well established: see its Section 4.3.2, which says "The following algorithm assumes that the RRs are organized in several tree structures, one for each zone, and another for the cache..." So, in this document, each time we talk about a tree or tree operations, we're referring to the model, not to the actual implementation.
ドメインネームスペースは、概念的にはツリー構造で定義されます。 DNSリゾルバー/キャッシュの実装は、ツリーまたは他のデータ構造を使用する場合があります。キャッシュはドメイン名前空間のデータのサブセットであり、そのツリー構造の観点からそれについて推論し、それらの用語（下/上にある名前、子孫の名前、サブツリーなど）で物事を説明する方がはるかに簡単です。実際、[RFC1034]のDNSアルゴリズムの説明には、キャッシュがツリー構造であるという仮定も記載されているため、前例はすでに十分に確立されています。セクション4.3.2を参照してください。「次のアルゴリズムは、RRが編成されていることを前提としています。つまり、このドキュメントでは、ツリーまたはツリーの操作について話すたびに、実際の実装ではなくモデルを参照しています。
When an iterative caching DNS resolver receives an NXDOMAIN response, it SHOULD store it in its cache and then all names and resource record sets (RRsets) at or below that node SHOULD be considered unreachable. Subsequent queries for such names SHOULD elicit an NXDOMAIN response.
反復キャッシングDNSリゾルバーがNXDOMAIN応答を受信すると、それをキャッシュに格納する必要があり（SHOULD）、そのノード以下のすべての名前とリソースレコードセット（RRset）は到達不能と見なされるべきです（SHOULD）。そのような名前に対する後続のクエリは、NXDOMAIN応答を引き出す必要があります（SHOULD）。
But, if a resolver has cached data under the NXDOMAIN cut, it MAY continue to send it as a reply (until the TTL of this cached data expires), since this may avoid additional processing when a query is received. Section 6 provides more information about this.
ただし、リゾルバーがNXDOMAINカットの下でデータをキャッシュしている場合、クエリを受信したときに追加の処理を回避できるため、リゾルバーは（このキャッシュデータのTTLが期限切れになるまで）応答として送信し続けることができます。セクション6では、これについて詳しく説明します。
Another exception is that a validating resolver MAY decide to implement the "NXDOMAIN cut" behavior (described in the first paragraph of this section) only when the NXDOMAIN response has been validated with DNSSEC. See Section 7 for the rationale.
別の例外は、検証リゾルバがNXDOMAIN応答がDNSSECで検証された場合のみ、「NXDOMAINカット」動作（このセクションの最初の段落で説明）を実装することを決定する場合があることです。根拠については、セクション7を参照してください。
The fact that a subtree does not exist is not forever: [RFC2308], Section 3, already describes the amount of time that an NXDOMAIN response may be cached (the "negative TTL").
サブツリーが存在しないという事実は永遠ではありません。[RFC2308]、セクション3には、NXDOMAIN応答がキャッシュされる可能性のある時間（「負のTTL」）がすでに記述されています。
If the NXDOMAIN response due to a cached nonexistence is from a DNSSEC-signed zone, then it will have accompanying NSEC or NSEC3 records that authenticate the nonexistence of the name. For a descendant name of the original NXDOMAIN name, the same set of NSEC or NSEC3 records proves the nonexistence of the descendant name. The iterative, caching resolver MUST return these NSEC or NSEC3 records in the response to the triggering query if the query had the DNSSEC OK (DO) bit set.
キャッシュされた非存在によるNXDOMAIN応答がDNSSEC署名ゾーンからのものである場合、名前の非存在を認証する付随するNSECまたはNSEC3レコードがあります。元のNXDOMAIN名の子孫名の場合、NSECまたはNSEC3レコードの同じセットは、子孫名が存在しないことを証明します。クエリにDNSSEC OK（DO）ビットが設定されている場合、反復キャッシングリゾルバは、トリガークエリへの応答でこれらのNSECまたはNSEC3レコードを返す必要があります。
Warning: if there is a chain of CNAME (or DNAME), the name that does not exist is the last of the chain ([RFC6604]) and not the QNAME. The NXDOMAIN stored in the cache is for the denied name, not always for the QNAME.
警告：CNAME（またはDNAME）のチェーンがある場合、存在しない名前はチェーンの最後（[RFC6604]）であり、QNAMEではありません。キャッシュに格納されているNXDOMAINは拒否された名前用であり、常にQNAME用ではありません。
As an example of the consequence of these rules, consider two successive queries to a resolver with a nonexisting domain 'foo.example': the first is for 'foo.example' (which results in an NXDOMAIN) and the second for 'bar.foo.example' (which also results in an NXDOMAIN). Many resolvers today will forward both queries. However, following the rules in this document ("NXDOMAIN cut"), a resolver would cache the first NXDOMAIN response, as a sign of nonexistence, and then immediately return an NXDOMAIN response for the second query, without transmitting it to an authoritative server.
これらのルールの結果の例として、存在しないドメイン「foo.example」を持つリゾルバへの2つの連続したクエリを考えます。最初のクエリは「foo.example」（NXDOMAINになる）と2番目のクエリは「bar」です。 foo.example '（これもNXDOMAINになります）。今日の多くのリゾルバは両方のクエリを転送します。ただし、このドキュメントのルール（「NXDOMAINカット」）に従って、リゾルバーは最初のNXDOMAIN応答を存在しないことの印としてキャッシュし、2番目のクエリのNXDOMAIN応答を権限のあるサーバーに送信せずにすぐに返します。
If the first request is for 'bar.foo.example' and the second for 'baz.foo.example', then the first NXDOMAIN response won't tell anything about 'baz.foo.example'; therefore, the second query will be transmitted as it was before the use of "NXDOMAIN cut" optimization (see Appendix A).
最初の要求が「bar.foo.example」に対するもので、2番目の要求が「baz.foo.example」に対するものである場合、最初のNXDOMAIN応答は「baz.foo.example」について何も伝えません。したがって、2番目のクエリは、「NXDOMAINカット」最適化を使用する前と同じように送信されます（付録Aを参照）。
This document clarifies possible ambiguities in [RFC1034] that did not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719]) from nonexistent names, and it refers to subsequent documents that do. ENTs are nodes in the DNS that do not have resource record sets associated with them but have descendant nodes that do. The correct response to ENTs is NODATA (i.e., a response code of NOERROR and an empty answer section). Additional clarifying language on these points is provided in Section 7.16 of [RFC2136] and in Sections 2.2.2 and 2.2.3 of [RFC4592].
このドキュメントは、空の非ターミナル（ENT）名（[RFC7719]）を存在しない名前から明確に区別しなかった[RFC1034]の可能性のある曖昧さを明確にし、それを行う後続のドキュメントを参照します。 ENTは、リソースレコードセットが関連付けられていないが、子孫ノードが関連付けられているDNSのノードです。 ENTへの正しい応答はNODATAです（つまり、NOERRORの応答コードと空の応答セクション）。これらの点に関する追加の明確な文言は、[RFC2136]のセクション7.16、および[RFC4592]のセクション2.2.2および2.2.3に記載されています。
The second paragraph of Section 5 in [RFC2308] states the following:
[RFC2308]のセクション5の2番目の段落は次のように述べています。
A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response.
名前エラー（NXDOMAIN）に起因する否定応答は、キャッシュされ、否定応答がキャッシュされた同じ<QNAME、QCLASS>に対する別のクエリに応答して取得および返されるようにする必要があります。
This document revises that paragraph to the following:
このドキュメントでは、この段落を次のように改訂します。
A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response, or where the QNAME is a descendant of the original QNAME and the QCLASS is the same.
名前エラー（NXDOMAIN）に起因する否定応答は、キャッシュされ、否定応答がキャッシュされた同じ<QNAME、QCLASS>に対する別のクエリに応答して取得および返されるように、またはQNAMEが元のQNAMEとQCLASSの子孫は同じです。
Section 2 above elaborates on the revised rule and specifies when it may be reasonable to relax or ignore it.
上記のセクション2は、改訂されたルールについて詳述し、それを緩和または無視することが合理的である場合を指定しています。
The main benefit is a better efficiency of the caches. In the example above, the resolver sends only one query instead of two, the second one being answered from the cache. This will benefit the entire DNS ecosystem, since the authoritative name servers will have less unnecessary traffic to process.
主な利点は、キャッシュの効率が向上することです。上記の例では、リゾルバは2つではなく1つのクエリのみを送信し、2番目のクエリはキャッシュから応答されます。権威のあるネームサーバーは処理する必要のないトラフィックが少ないため、これはDNSエコシステム全体に利益をもたらします。
The correct behavior (in [RFC1034] and made clearer in this document) is especially useful when combined with QNAME minimization [RFC7816] since it will allow a resolver to stop searching as soon as an NXDOMAIN is encountered.
正しい動作（[RFC1034]で、このドキュメントでより明確になっています）は、QNAME最小化[RFC7816]と組み合わせると、NXDOMAINが検出されるとすぐにリゾルバーが検索を停止できるため、特に役立ちます。
"NXDOMAIN cut" may also help mitigate certain types of random QNAME attacks [joost-dnsterror] and [balakrichenan-dafa888], where there is a fixed suffix that does not exist. In these attacks against the authoritative name server, queries are sent to resolvers for a QNAME composed of a fixed suffix ("dafa888.wf" in one of the articles above), which is typically nonexistent, and a random prefix, different for each request. A resolver receiving these requests has to forward them to the authoritative servers. With "NXDOMAIN cut", a system administrator would just have to send to the resolver a query for the fixed suffix, the resolver would get a NXDOMAIN and then would stop forwarding the queries. (It would be better if the SOA record in the NXDOMAIN response were sufficient to find the nonexisting domain, but this is not the case, see Appendix A.)
「NXDOMAINカット」は、特定の種類のランダムなQNAME攻撃[joost-dnsterror]と[balakrichenan-dafa888]の緩和にも役立つ場合があります。この場合、存在しない固定サフィックスがあります。権威ネームサーバーに対するこれらの攻撃では、クエリは、通常は存在しない固定サフィックス（上記の記事のいずれかで「dafa888.wf」）と、リクエストごとに異なるランダムプレフィックスで構成されるQNAMEのリゾルバーに送信されます。 。これらのリクエストを受け取ったリゾルバは、権限のあるサーバーにリクエストを転送する必要があります。 「NXDOMAINカット」を使用すると、システム管理者はリゾルバに固定サフィックスのクエリを送信するだけでよく、リゾルバはNXDOMAINを取得し、クエリの転送を停止します。 （NXDOMAIN応答のSOAレコードで、存在しないドメインを見つけるのに十分であるとよいでしょうが、そうではありません。付録Aを参照してください。）
Let's assume that the Top-Level Domain (TLD) example exists, but foobar.example is not delegated (so the example's name servers will reply NXDOMAIN for a query about anything.foobar.example). A system administrator decides to name the internal machines of his organization under office.foobar.example and uses a trick of his resolver to forward requests about this zone to his local authoritative name servers. "NXDOMAIN cut" would create problems here; depending on the order of requests to the resolver, it may have cached the nonexistence from example and therefore "deleted" everything under it. This document assumes that such a setup is rare and does not need to be supported.
トップレベルドメイン（TLD）の例が存在するが、foobar.exampleは委任されていないと想定します（したがって、例のネームサーバーは、anything.foobar.exampleに関するクエリに対してNXDOMAINに応答します）。システム管理者は、office.foobar.exampleの下にある組織の内部マシンに名前を付けることを決定し、リゾルバーのトリックを使用して、このゾーンに関する要求をローカルの権威ネームサーバーに転送します。 「NXDOMAINカット」はここで問題を引き起こします。リゾルバへのリクエストの順序によっては、存在しないものをサンプルからキャッシュし、その下にあるすべてを「削除」した可能性があります。このドキュメントでは、このような設定はまれであり、サポートする必要がないことを前提としています。
Today, another possible issue exists; we see authoritative name servers that reply to ENT ([RFC7719], Section 6) with NXDOMAIN instead of the normal NODATA ([RFC7719], Section 3).
今日、別の問題が存在する可能性があります。通常のNODATA（[RFC7719]、セクション3）ではなくNXDOMAINを使用してENT（[RFC7719]、セクション6）に応答する信頼できるネームサーバーが表示されます。
Such name servers are definitely wrong and have always been. Their behaviour is incompatible with DNSSEC. Given the advantages of "NXDOMAIN cut", there is little reason to support this behavior.
そのようなネームサーバーは間違いなく間違っており、常に間違っています。それらの動作はDNSSECと互換性がありません。 「NXDOMAINカット」の利点を考えると、この動作をサポートする理由はほとんどありません。
This section is non-normative and is composed only of various things that may be useful for implementors. A recursive resolver may implement its cache in many ways. The most obvious one is a tree data structure, because it fits the data model of domain names. But, in practice, other implementations are possible, as well as various optimizations (such as a tree, augmented by an index of some common domain names).
このセクションは非規範的であり、実装者に役立つ可能性のあるさまざまなもののみで構成されています。再帰リゾルバは、さまざまな方法でキャッシュを実装できます。最も明白なのは、ドメイン名のデータモデルに適合するため、ツリーデータ構造です。ただし、実際には、他の実装やさまざまな最適化（ツリーなど、一部の一般的なドメイン名のインデックスで補強されたもの）も可能です。
If a resolver implements its cache as a tree (without any optimization), one way to follow the rules in Section 2 is as follows: when receiving the NXDOMAIN, prune the subtree of positive cache entries at that node or delete all individual cache entries for names below that node. Then, when searching downward in its cache, this iterative caching DNS resolver will stop searching if it encounters a cached nonexistence.
リゾルバーがそのキャッシュをツリーとして（最適化なしで）実装する場合、セクション2のルールに従う1つの方法は次のとおりです：NXDOMAINを受け取ったら、そのノードで正のキャッシュエントリーのサブツリーをプルーニングするか、すべての個々のキャッシュエントリーを削除しますそのノードの下の名前。次に、キャッシュを下方向に検索するときに、この反復キャッシュDNSリゾルバーは、キャッシュされた非存在に遭遇すると検索を停止します。
Some resolvers may have a cache that is NOT organized as a tree (but, for instance, as a dictionary); therefore, they have a reason to ignore the rules of Section 2. So these rules use SHOULD and not MUST.
一部のリゾルバーには、ツリーとして（ただし、たとえば、辞書として）編成されていないキャッシュがある場合があります。したがって、これらにはセクション2のルールを無視する理由があります。したがって、これらのルールは、MUSTではなくSHOULDを使用します。
The technique described in this document may help against a denial-of-service attack named "random qnames" described in Section 4.
このドキュメントで説明されている手法は、セクション4で説明されている「ランダムqnames」という名前のサービス拒否攻撃を防ぐのに役立ちます。
If a resolver does not validate the answers with DNSSEC, or if the zone is not signed, the resolver can of course be poisoned with a false NXDOMAIN, thus, "deleting" a part of the domain name tree. This denial-of-service attack is already possible without the rules of this document (but "NXDOMAIN cut" may increase its effects). The only solution is to use DNSSEC.
リゾルバーがDNSSECで回答を検証しない場合、またはゾーンが署名されていない場合、リゾルバーはもちろん偽のNXDOMAINで汚染される可能性があるため、ドメイン名ツリーの一部が「削除」されます。このサービス拒否攻撃は、このドキュメントのルールなしではすでに可能です（ただし、「NXDOMAINカット」はその影響を増大させる可能性があります）。唯一の解決策はDNSSECを使用することです。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <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>。
[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, <http://www.rfc-editor.org/info/rfc2136>.
[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 、<http://www.rfc-editor.org/info/rfc2136>。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <http://www.rfc-editor.org/info/rfc2308>.
[RFC2308]アンドリュース、M。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、DOI 10.17487 / RFC2308、1998年3月、<http://www.rfc-editor.org/info/rfc2308>。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, <http://www.rfc-editor.org/info/rfc4592>.
[RFC4592]ルイス、E。、「ドメインネームシステムにおけるワイルドカードの役割」、RFC 4592、DOI 10.17487 / RFC4592、2006年7月、<http://www.rfc-editor.org/info/rfc4592>。
[RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits Clarification", RFC 6604, DOI 10.17487/RFC6604, April 2012, <http://www.rfc-editor.org/info/rfc6604>.
[RFC6604] Eastlake 3rd、D。、「xNAME RCODE and Status Bits Clarification」、RFC 6604、DOI 10.17487 / RFC6604、2012年4月、<http://www.rfc-editor.org/info/rfc6604>。
[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>。
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7719] Hoffman、P.、Sullivan、A。、およびK. Fujiwara、「DNS用語」、RFC 7719、DOI 10.17487 / RFC7719、2015年12月、<http://www.rfc-editor.org/info/rfc7719 >。
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, <http://www.rfc-editor.org/info/rfc7816>.
[RFC7816] Bortzmeyer、S。、「プライバシーを改善するためのDNSクエリ名の最小化」、RFC 7816、DOI 10.17487 / RFC7816、2016年3月、<http://www.rfc-editor.org/info/rfc7816>。
[DNSRRR] Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness", Work in Progress, draft-vixie-dnsext-resimprove-00, June 2010.
[DNSRRR] Vixie、P.、Joffe、R。、およびF. Neves、「回復力、堅牢性、および応答性のためのDNSリゾルバーの改善」、Work in Progress、draft-vixie-dnsext-resimprove-00、2010年6月。
[NSEC] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of NSEC/NSEC3", Work in Progress, draft-ietf-dnsop-nsec-aggressiveuse-04, September 2016.
[NSEC]藤原健一郎、加藤明夫、およびW.クマリ、「NSEC / NSEC3の積極的な使用」、作業中、draft-ietf-dnsop-nsec-aggressiveuse-04、2016年9月。
[joost-dnsterror] Joost, M., "About DNS Attacks and ICMP Destination Unreachable Reports", December 2014, <http://www.michael-joost.de/dnsterror.html>.
[joost-dnsterror] Joost、M。、「DNS攻撃とICMP宛先到達不能レポートについて」、2014年12月、<http://www.michael-joost.de/dnsterror.html>。
[balakrichenan-dafa888] Balakrichenan, S., "Disturbance in the DNS - "Random qnames", the dafa888 DoS attack"", October 2014, <https://indico.dns-oarc.net/event/20/session/3/ contribution/3>.
[balakrichenan-dafa888] Balakrichenan、S。、「DNSの障害-「ランダムなqnames」、dafa888 DoS攻撃」、2014年10月、<https://indico.dns-oarc.net/event/20/session/ 3 /貢献/ 3>。
Appendix A. Why can't we just use the owner name of the returned SOA?
付録A.返されたSOAの所有者名だけを使用できないのはなぜですか？
In this document, we deduce the nonexistence of a domain only for NXDOMAIN answers where the denied name was the exact domain. If a resolver sends a query to the name servers of the TLD example, asking for the mail exchange (MX) record for www.foobar.example, and subsequently receives a NXDOMAIN, it can only register the fact that www.foobar.example (and everything underneath) does not exist. This is true regardless of whether or not the accompanying SOA record is for the domain example only. One cannot infer that foobar.example is nonexistent. The accompanying SOA record indicates the apex of the zone, not the closest existing domain name. So, using the owner name of the SOA record in the authority section to deduce "NXDOMAIN cuts" is currently definitely not OK.
このドキュメントでは、拒否された名前が正確なドメインであったNXDOMAINの回答に対してのみ、ドメインが存在しないことを推測します。リゾルバーがTLDサンプルのネームサーバーにクエリを送信し、www.foobar.exampleのメール交換（MX）レコードを要求し、その後NXDOMAINを受信した場合、www.foobar.example（とその下にあるすべてのものは存在しません。これは、付随するSOAレコードがドメインの例だけのものかどうかに関係なく当てはまります。 foobar.exampleが存在しないと推測することはできません。付随するSOAレコードは、最も近い既存のドメイン名ではなく、ゾーンの頂点を示しています。そのため、権限セクションでSOAレコードの所有者名を使用して「NXDOMAINカット」を推定することは、現時点では間違いなく問題です。
Deducing the nonexistence of a node from the SOA in the NXDOMAIN reply may certainly help with random qnames attacks, but this is out-of-scope for this document. It would require addressing the problems mentioned in the first paragraph of this section. A possible solution is, when receiving a NXDOMAIN with a SOA that is more than one label up in the tree, to send requests for the domains that are between the QNAME and the owner name of the SOA. (A resolver that does DNSSEC validation or QNAME minimization will need to do it anyway.)
NXDOMAIN応答のSOAからノードが存在しないことを推測すると、ランダムなqnames攻撃に役立つ可能性がありますが、これはこのドキュメントの範囲外です。このセクションの最初の段落で述べた問題に対処する必要があります。考えられる解決策は、ツリー内に複数のラベルがあるSOAを含むNXDOMAINを受信したときに、QNAMEとSOAの所有者名の間にあるドメインにリクエストを送信することです。 （とにかく、DNSSEC検証またはQNAME最小化を行うリゾルバーは、それを行う必要があります。）
The document [NSEC] describes another way to address some of the same concerns (decreasing the traffic for nonexisting domain names). Unlike "NXDOMAIN cut", it requires DNSSEC, but it is more powerful since it can synthesize NXDOMAINs for domains that were not queried.
ドキュメント[NSEC]は、同じ問題のいくつかに対処する別の方法を説明しています（存在しないドメイン名のトラフィックを減らします）。 「NXDOMAINカット」とは異なり、DNSSECが必要ですが、照会されなかったドメインのNXDOMAINを合成できるため、より強力です。
Acknowledgments
謝辞
The main idea in this document is taken from [DNSRRR], Section 3, "Stopping Downward Cache Search on NXDOMAIN". Thanks to its authors, Paul Vixie, Rodney Joffe, and Frederico Neves. Additionally, Tony Finch, Ted Lemon, John Levine, Jinmei Tatuya, Bob Harold, and Duane Wessels provided valuable feedback and suggestions.
このドキュメントの主なアイデアは、[DNSRRR]、セクション3、「Stopping Downward Cache Search on NXDOMAIN」からの引用です。著者のPaul Vixie、Rodney Joffe、およびFrederico Nevesに感謝します。さらに、Tony Finch、Ted Lemon、John Levine、Jinmei Tatuya、Bob Harold、およびDuane Wesselsは、貴重なフィードバックと提案を提供しました。
Authors' Addresses
著者のアドレス
Stephane Bortzmeyer AFNIC 1, rue Stephenson Montigny-le-Bretonneux 78180 France
ステファンボルツマイヤーAFNIC 1、rue Stephenson Montigny-le-Bretonneux 78180 France
Phone: +33 1 39 30 83 46
Email: bortzmeyer+ietf@nic.fr
URI: https://www.afnic.fr/
Shumon Huque Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America
Shumon Huque Verisign Labs 12061 Bluemont Way Reston、VA 20190アメリカ合衆国
Email: shuque@verisign.com
URI: http://www.verisignlabs.com/