[要約] RFC 8906は、「DNSサーバーにおける一般的な運用上の問題：通信の失敗」というタイトルの文書で、DNSサーバー間の通信失敗が原因で発生する問題とその解決策に焦点を当てています。このRFCの目的は、DNS運用者が通信障害を診断し、解決するためのガイドラインを提供することです。利用場面としては、DNSサーバーの設定や運用において、予期せぬ通信エラーに直面した際に参照されます。関連するRFCには、DNSプロトコルの基本を定義するRFC 1034やRFC 1035などがあります。
Internet Engineering Task Force (IETF) M. Andrews
Request for Comments: 8906 R. Bellis
BCP: 231 ISC
Category: Best Current Practice September 2020
ISSN: 2070-1721
A Common Operational Problem in DNS Servers: Failure to Communicate
DNSサーバーにおける一般的な動作上の問題：通信不能
Abstract
概要
The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development.
DNSはクエリ/応答プロトコルです。クエリに応答したり、誤って応答したりすることに失敗すると、即時の運用上の問題とプロトコル開発に関する長期的な問題の両方が発生します。
This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem.
このドキュメントは、一部のサーバーが応答に失敗したり誤って応答したりすることができない一般的な種類のクエリを識別します。この文書はまた、問題を識別して修復するために適用されるゾーンオペレータのための手順を示唆しています。
The document does not look at the DNS data itself, just the structure of the responses.
ドキュメントはDNSデータ自体を見ていないため、応答の構造だけです。
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/rfc8906.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8906で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Consequences
3. Common Kinds of Queries That Result in No or Bad Responses
3.1. Basic DNS Queries
3.1.1. Zone Existence
3.1.2. Unknown/Unsupported Type Queries
3.1.3. DNS Flags
3.1.4. Unknown DNS Opcodes
3.1.5. TCP Queries
3.2. EDNS Queries
3.2.1. EDNS Queries: Version Independent
3.2.2. EDNS Queries: Version Specific
3.2.3. EDNS Options
3.2.4. EDNS Flags
3.2.5. Truncated EDNS Responses
3.2.6. DO=1 Handling
3.2.7. EDNS over TCP
4. Firewalls and Load Balancers
5. Packet Scrubbing Services
6. Whole Answer Caches
7. Response Code Selection
8. Testing
8.1. Testing: Basic DNS
8.1.1. Is the server configured for the zone?
8.1.2. Testing Unknown Types
8.1.3. Testing Header Bits
8.1.4. Testing Unknown Opcodes
8.1.5. Testing TCP
8.2. Testing: Extended DNS
8.2.1. Testing Minimal EDNS
8.2.2. Testing EDNS Version Negotiation
8.2.3. Testing Unknown EDNS Options
8.2.4. Testing Unknown EDNS Flags
8.2.5. Testing EDNS Version Negotiation with Unknown EDNS
Flags
8.2.6. Testing EDNS Version Negotiation with Unknown EDNS
Options
8.2.7. Testing Truncated Responses
8.2.8. Testing DO=1 Handling
8.2.9. Testing EDNS Version Negotiation with DO=1
8.2.10. Testing with Multiple Defined EDNS Options
8.3. When EDNS Is Not Supported
9. Remediation
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Authors' Addresses
The DNS [RFC1034] [RFC1035] is a query/response protocol. Failing to respond to queries or responding incorrectly causes both immediate operational problems and long-term problems with protocol development.
DNS [RFC1034] [RFC1035]はクエリ/応答プロトコルです。クエリに応答したり、応答に誤って誤って、即時の運用上の問題とプロトコル開発に関する長期的な問題の両方が原因となります。
Failure to respond to a query is indistinguishable from packet loss without doing an analysis of query-response patterns. Additionally, failure to respond results in unnecessary queries being made by DNS clients and introduces delays to the resolution process.
クエリに応答しないと、クエリ応答パターンの分析を行わずにパケット損失と区別がつかない。さらに、応答に応じても不要なクエリがDNSクライアントによって行われ、解像度プロセスに遅延が発生します。
Due to the inability to distinguish between packet loss and nameservers or middleboxes dropping Extension Mechanisms for DNS (EDNS) [RFC6891] queries, packet loss is sometimes misclassified as lack of EDNS support, which can lead to DNSSEC validation failures.
パケット損失とネームサーバーまたはミドルボックスをDNS（EDNS）の拡張メカニズムを区別できないため、パケット損失はEDNSサポートの欠如として誤分類されることがあります。これにより、DNSSECの検証障害が発生する可能性があります。
The existence of servers that fail to respond to queries results in developers being hesitant to deploy new standards. Such servers need to be identified and remediated.
クエリに応答できないサーバーの存在は、開発者が新しい標準を展開することが躊躇しています。そのようなサーバーは識別され修復される必要があります。
The DNS has response codes that cover almost any conceivable query response. A nameserver should be able to respond to any conceivable query using them. There should be no need to drop queries because a nameserver does not understand them.
DNSには、考えられるほとんどのクエリ応答をカバーする応答コードがあります。ネームサーバーは、それらを使用して考えられるすべてのクエリに応答できるはずです。ネームサーバーがそれらを理解していないため、クエリを削除する必要はありません。
Unless a nameserver is under attack, it should respond to all DNS requests directed to it. When a nameserver is under attack, it may wish to drop packets. A common attack is to use a nameserver as an amplifier by sending spoofed packets. This is done because response packets are bigger than the queries and large amplification factors are available, especially if EDNS is supported. Limiting the rate of responses is reasonable when this is occurring, and the client should retry. However, this only works if legitimate clients are not being forced to guess whether or not EDNS queries are accepted. As long as there is still a pool of servers that don't respond to EDNS requests, clients have no way to know if the lack of response is due to packet loss, EDNS packets not being supported, or rate limiting due to the server being under attack. Misclassification of server behaviour is unavoidable when rate limiting is used until the population of servers that fail to respond to well-formed queries drops to near zero.
ネームサーバーが攻撃を受けていない限り、それに向けられたすべてのDNS要求に応答する必要があります。ネームサーバーが攻撃しているときは、パケットを削除したい場合があります。一般的な攻撃は、偽装されたパケットを送信することによってアンプとしてネームサーバーを使用することです。これは、応答パケットがクエリよりも大きいため、特にEDNSがサポートされている場合は、応答パケットがクエリよりも大きいためです。これが発生しているときに応答率を制限することが合理的であり、クライアントは再試行する必要があります。ただし、正当なクライアントがEDNSクエリが受け入れられているかどうかを推測することを強制されていない場合にのみ機能します。 EDNS要求に応答しないサーバーのプールがまだある限り、クライアントは応答の欠如がパケットの損失、サポートされていないこと、またはサーバーがサーバーのためにレート制限があるかどうかを知る方法はありません。攻撃を受けます。サーバの動作の誤分類は、適切に形成されたクエリに応答できないサーバの母集団がゼロ近くに低下するまで、レート制限が使用されるときは避けられない。
Nameservers should respond to queries even if the queried name is not for any name the server is configured to answer for. Misconfigured nameservers are a common occurrence in the DNS, and receiving queries for zones that the server is not configured for is not necessarily an indication that the server is under attack. Parent zone operators are advised to regularly check that the delegating NS records are consistent with those of the delegated zone and to correct them when they are not (Section 4.2.2 of [RFC1034], Paragraph 3). Doing this regularly should reduce the instances of broken delegations.
QUERIED NAMEが任意の名前ではなく、サーバーが答えるように設定されている場合でも、ネームサーバーはクエリに応答する必要があります。Misconfiged NameServersは、DNSでの共通の発生であり、サーバーが構成されていないゾーンのクエリは必ずしもサーバーが攻撃していることを示していません。親ゾーン演算子は、委任するNSレコードが委任ゾーンのものと一致し、それらがそうでないときにそれらを修正することを定期的にチェックする（Section 4.2.2、段落3）。これを定期的にすると、壊れた代表団のインスタンスが減少する必要があります。
This document does not try to identify all possible errors nor does it supply an exhaustive list of tests.
この文書は、考えられるすべてのエラーを特定したり、徹底的なテストのリストを提供したりしません。
Failure to follow the guidance in relevant DNS RFCs has multiple adverse consequences. Some are caused directly by the non-compliant behaviour and others as a result of workarounds forced on recursive servers. Addressing known issues now will reduce future interoperability issues as the DNS protocol continues to evolve and clients make use of newly introduced DNS features. In particular, the base DNS specification [RFC1034] [RFC1035] and the EDNS specification [RFC6891], when implemented, need to be followed.
関連するDNS RFCのガイダンスに従わないと、複数の悪影響があります。いくつかは、再帰的サーバーで強制された回避策の結果として、不適合な行動やその他によって直接引き起こされます。DNSプロトコルが進化し続け、クライアントが新しく導入されたDNS機能を利用しているため、既知の問題を解決するように既知の問題が発生するようになりました。特に、基本DNS仕様[RFC1034] [RFC1035]とEDNS仕様[RFC6891]は、実装されている場合に従う必要があります。
Some examples of known consequences include the following:
既知の結果のいくつかの例としては、以下が含まれます。
* The AD (Authenticated Data) bit in a response cannot be trusted to mean anything, as some servers incorrectly copy the flag bit from the request to the response [RFC1035] [RFC4035]. The use of the AD bit in requests is defined in [RFC6840].
* 一部のサーバーが要求からRESPONSEXのリクエストを誤ってコピーしたときに、応答のAD（認証されたデータ）ビットを信頼できません[RFC1035] [RFC4035]。リクエストのADビットの使用は[RFC6840]で定義されています。
* Widespread non-response to EDNS queries has led to recursive servers having to assume that EDNS is not supported and that fallback to plain DNS is required, potentially causing DNSSEC validation failures.
* EDNSクエリに対する非応答は、eDNSがサポートされていないと仮定し、普通のDNSへのフォールバックが必要であると仮定する再帰サーバーが必要となり、潜在的にDNSSEC検証の失敗を引き起こすことがあります。
* Widespread non-response to EDNS options requires recursive servers to decide whether to probe to see if it is the specific EDNS option or the use of EDNS in general that is causing the non-response. In the limited amount of time required to resolve a query before the client times out, this is not possible.
* EDNSオプションに対する非応答の非対応では、それが特定のEDNSオプションであるかどうか、または非応答を引き起こしているEDNSの使用を確認するためにプローブするかどうかを決定するために再帰的なサーバーが必要です。クライアントがタイムアウトする前にクエリを解決するのに必要な時間の限られた時間では、これは不可能です。
* Incorrectly returning FORMERR to an EDNS option being present leads to the recursive server not being able to determine if the server is just broken in the handling of the EDNS option or if it doesn't support EDNS at all.
* 誤ってEDNSオプションに戻ることが誤って戻ってきたオプションは、サーバーがEDNSオプションの処理で壊れている場合、またはまったくEDNSをサポートしていない場合は、再帰的なサーバーにつながります。
* Mishandling of unknown query types has contributed to the abandonment of the transition of the SPF type.
* 未知のクエリタイプの誤って犯罪は、SPFタイプの遷移の放棄に貢献しました。
* Mishandling of unknown query types has slowed up the development of DNS-Based Authentication of Named Entities (DANE) and resulted in additional rules being specified to reduce the probability of interacting with a broken server when making TLSA queries.
* 未知のクエリタイプの誤って、名前付きエンティティ（DANE）のDNSベースの認証の開発が減速し、TLSAクエリを作成するときに壊れたサーバーと対話する可能性を減らすために追加の規則が指定されています。
The consequences of servers not following the RFCs will only grow if measures are not put in place to remove non-compliant servers from the ecosystem. Working around issues due to non-compliance with RFCs is not sustainable.
RFCに従わないサーバーの影響は、エコシステムから準拠していないサーバーを削除するための対策が整っていない場合にのみ成長します。RFCの不適合による問題を回避することは持続可能ではありません。
Most (if not all) of these consequences could have been avoided if action had been taken to remove non-compliant servers as soon as people were aware of them, i.e., to actively seek out broken implementations and servers and inform their developers and operators that they need to fix their servers.
人々がそれらを認識していた、すなわち壊れた実装やサーバーを積極的に捜し出し、開発者や事業者に積極的に訓練するために、訴訟が不適合なサーバーを削除するために行動が取られた場合、これらの結果のほとんど（すべてでない場合）は回避されました。彼らは彼らのサーバーを修正する必要があります。
This section is broken down into Basic DNS requests and EDNS requests.
このセクションは、基本的なDNS要求およびEDNS要求に分類されます。
If a zone is delegated to a server, that server should respond to a SOA query for that zone with an SOA record. Failing to respond at all is always incorrect, regardless of the configuration of the server. Responding with anything other than an SOA record in the answer section indicates a bad delegation.
ゾーンがサーバーに委任されている場合、そのサーバーはSOAレコードを使用してそのゾーンのSOAクエリに応答する必要があります。サーバーの構成に関係なく、常に正しく応答しないことです。回答セクションのSOAレコード以外のもので回答すると、悪い委任が示されています。
Some servers fail to respond to unknown or unsupported types. If a server receives a query for a type that it doesn't recognise, or doesn't implement, it is expected to return the appropriate response as if it did recognise the type but does not have any data for that type, i.e., either NOERROR or NXDOMAIN. The exceptions to this are queries for Meta-RR types, which may return NOTIMP.
一部のサーバーは、未知またはサポートされていない型に応答できません。サーバーが認識されないタイプのクエリを受信した場合、または実装していない場合は、そのタイプの認識されたがそのタイプのデータがないかのように適切な応答を返すことが期待されます。NoErrorまたはNXDomain。これに対する例外は、メタRRタイプのクエリです。これはnotipを返します。
Some servers fail to respond to DNS queries with various DNS flags set, regardless of whether they are defined or still reserved. At the time of writing, there are servers that fail to respond to queries with the AD flag set to 1 and servers that fail to respond to queries with the last reserved flag set.
一部のサーバーは、定義されているか予約されているかどうかにかかわらず、さまざまなDNSフラグを使用してDNSクエリに応答できません。書き込み時には、最後の予約フラグセットを使用してクエリに応答できない1とサーバーに設定されたクエリに応答できないサーバーがあります。
Servers should respond to such queries. If the server does not know the meaning of a flag, it must not copy it to the response (Section 4.1.1 of [RFC1035]). If the server does not understand the meaning of a request, it should reply with a FORMERR response with unknown flags set to zero.
サーバーはそのようなクエリに応答する必要があります。サーバーがフラグの意味を知らない場合は、それを応答にコピーしてはいけません（[RFC1035]のセクション4.1.1）。サーバーが要求の意味を理解していない場合は、未知のフラグがゼロに設定されている以前の応答で返信する必要があります。
A non-recursive server is supposed to respond to recursive queries as if the Recursion Desired (RD) bit is not set [RFC1034].
再帰的なサーバーは、再帰（RD）ビットが設定されていない場合のように、再帰的クエリに応答することになっています[RFC1034]。
The use of previously undefined opcodes is to be expected. Since the DNS was first defined, two new opcodes have been added, UPDATE and NOTIFY.
以前に未定義のオペコードの使用は予想されます。DNSが最初に定義されているため、2つの新しいオペコードが追加、更新、通知されました。
NOTIMP is the expected rcode to an unknown or unimplemented opcode.
NOTIMPは、未知のまたは未実装のオペコードへの予想されるRCODEです。
| NOTE: while new opcodes will most probably use the current
| layout structure for the rest of the message, there is no
| requirement that anything other than the DNS header match.
All DNS servers are supposed to respond to queries over TCP [RFC7766]. While firewalls should not block TCP connection attempts, those that do should cleanly terminate the connection by sending TCP RESET or sending ICMP/ICMPv6 Administratively Prohibited messages. Dropping TCP connections introduces excessive delays to the resolution process.
すべてのDNSサーバーはTCP [RFC7766]を介したクエリに応答することになっています。ファイアウォールはTCP接続の試行をブロックしないでくださいが、TCPリセットまたはICMP / ICMPv6管理上の禁止メッセージを送信して接続をきれいに終了する必要があります。TCP接続を削除すると、解像度プロセスに過度の遅延が発生します。
EDNS queries are specified in [RFC6891].
[RFC6891]にEDNSクエリが指定されています。
Identifying servers that fail to respond to EDNS queries can be done by first confirming that the server responds to regular DNS queries, followed by a series of otherwise identical queries using EDNS, then making the original query again. A series of EDNS queries is needed, as at least one DNS implementation responds to the first EDNS query with FORMERR but fails to respond to subsequent queries from the same address for a period until a regular DNS query is made. The EDNS query should specify a UDP buffer size of 512 bytes to avoid false classification of not supporting EDNS due to response packet size.
EDNSクエリに応答できないサーバーの識別は、最初にサーバーが通常のDNSクエリに応答し、その後にEDNSを使用して一連のそうでなければ同一のクエリを再度実行することによって実行できます。少なくとも1つのDNS実装が以前のEDNSクエリに応答するが、通常のDNSクエリが行われるまで、同じアドレスからの後続のクエリに応答しないため、一連のEDNSクエリが必要です。EDNSクエリは、応答パケットサイズのためにEDNをサポートしていないという誤った分類を回避するために、512バイトのUDPバッファサイズを指定する必要があります。
If the server responds to the first and last queries but fails to respond to most or all of the EDNS queries, it is probably faulty. The test should be repeated a number of times to eliminate the likelihood of a false positive due to packet loss.
サーバーが最初と最後のクエリに応答しているが、ほとんどまたはすべてのEDNSクエリに応答できない場合は、おそらく不良です。パケット損失のために、誤損失の可能性を排除するためにテストを繰り返す必要があります。
Firewalls may also block larger EDNS responses, but there is no easy way to check authoritative servers to see if the firewall is misconfigured.
ファイアウォールは、より大きなEDNS応答をブロックすることもできますが、ファイアウォールが誤って設定されているかどうかを確認するために正式なサーバーをチェックする簡単な方法はありません。
Some servers respond correctly to EDNS version 0 queries but fail to respond to EDNS queries with version numbers that are higher than zero. Servers should respond with BADVERS to EDNS queries with version numbers that they do not support.
一部のサーバーがEDNSバージョン0クエリに正しく応答しますが、ゼロより高いバージョン番号を持つEDNSクエリに応答できません。サーバーは、サポートされていないバージョン番号を持つEDNSクエリには、BADVERSに応答する必要があります。
Some servers respond correctly to EDNS version 0 queries but fail to set QR=1 when responding to EDNS versions they do not support. Such responses may be discarded as invalid (as QR is not 1) or treated as requests (when the source port of the original request was port 53).
一部のサーバーはEDNSバージョン0クエリに正しく応答しますが、サポートしていないEDNSバージョンに応答してもQR = 1を設定できません。このような応答は無効として（QRが1ではない）、または要求として扱われる（元の要求の送信元ポートがポート53である場合）、無効として破棄されてもよい。
Some servers fail to respond to EDNS queries with EDNS options set. The original EDNS specification left this behaviour undefined [RFC2671], but the correct behaviour was clarified in [RFC6891]. Unknown EDNS options are supposed to be ignored by the server.
EDNSオプションセットを使用してEDNSクエリに応答できないサーバーが一部のサーバー。元のEDNS仕様はこの動作未定義[RFC2671]を残しましたが、[RFC6891]で正しい動作が明確にされました。不明なEDNSオプションは、サーバーによって無視されるはずです。
Some servers fail to respond to EDNS queries with EDNS flags set. Servers should ignore EDNS flags they do not understand and must not add them to the response [RFC6891].
EDNSフラグを設定したEDNSクエリにEDNSクエリに応答できないサーバーが一部のサーバーです。サーバーは、わからないEDNSフラグを無視し、それらを応答に追加してはいけません[RFC6891]。
Some EDNS-aware servers fail to include an OPT record when a truncated response is sent. An OPT record is supposed to be included in a truncated response [RFC6891].
切り捨てられた応答が送信されると、一部のEDNS対応サーバーはOPTレコードを含めることができません。オプトレコードは、切り捨てられた応答に含まれるはずです[RFC6891]。
Some EDNS-aware servers fail to honour the advertised EDNS UDP buffer size and send oversized responses [RFC6891]. Servers must send UDP responses no larger than the advertised EDNS UDP buffer size.
一部のEDN-Awareサーバーは、アドバタイズされたEDNS UDPバッファサイズを尊重し、特大の応答を送信しました[RFC6891]。サーバーは、アドバタイズされたEDNS UDPバッファサイズ以下のUDP応答を送信する必要があります。
Some nameservers incorrectly only return an EDNS response when the DNSSEC OK (DO) bit [RFC3225] is 1 in the query. Servers that support EDNS should always respond to EDNS requests with EDNS responses.
DNSSEC OK（DO）ビット[RFC3225]がクエリ内の1ビット[RFC3225]のときにのみ、NameServersが誤ってEDNS応答のみを返します。EDNをサポートするサーバーは、EDNS応答を使用してEDNS要求に常に応答する必要があります。
Some nameservers fail to copy the DO bit to the response despite clearly supporting DNSSEC by returning an RRSIG records to EDNS queries with DO=1. Nameservers that support DNSSEC are expected to copy the DO bit from the request to the response.
DOSSECをDO = 1でEDNSクエリに返すことによってDNSSECを明確にサポートするにもかかわらず、DNSSECを明確にサポートしているにもかかわらず、一部のネームサーバーはDOビットをコピーすることに失敗します。DNSSECをサポートするネームサーバーは、要求からDOビットを応答にコピーすることが期待されています。
Some EDNS-aware servers incorrectly limit the TCP response sizes to the advertised UDP response size. This breaks DNS resolution to clients where the response sizes exceed the advertised UDP response size despite the server and the client being capable of sending and receiving larger TCP responses, respectively. It effectively defeats setting TC=1 in UDP responses.
一部のEDNS対応サーバーは、Adverted UDP応答サイズにTCP応答サイズを誤って制限しています。これは、サーバーとクライアントがそれぞれ大きなTCP応答を送受信することができるにもかかわらず、応答サイズがアドバタイズされたUDP応答サイズを超えるクライアントにDNS解決を解決します。UDP応答でTC = 1の設定を効果的に無効にします。
Firewalls and load balancers can affect the externally visible behaviour of a nameserver. Tests for conformance should to be done from outside of any firewall so that the system is tested as a whole.
ファイアウォールとロードバランサは、ネームサーバーの外部から見える動作に影響を与える可能性があります。適合性のテストは、システムが全体としてテストされるように、ファイアウォールの外部から行われるべきです。
Firewalls and load balancers should not drop DNS packets that they don't understand. They should either pass the packets or generate an appropriate error response.
ファイアウォールとロードバランサは、わからないDNSパケットを削除しないでください。それらはパケットを渡すか、適切なエラー応答を生成する必要があります。
Requests for unknown query types are normal client behaviour and should not be construed as an attack. Nameservers have always been expected to be able to handle such queries.
不明なクエリタイプに対する要求は通常のクライアントの動作であり、攻撃として解釈されるべきではありません。ネームサーバーは常にそのようなクエリを処理できると予想されています。
Requests for unknown query classes are normal client behaviour and should not be construed as an attack. Nameservers have always been expected to be able to handle such queries.
不明なクエリクラスの要求は通常のクライアントの動作であり、攻撃として解釈されるべきではありません。ネームサーバーは常にそのようなクエリを処理できると予想されています。
Requests with unknown opcodes are normal client behaviour and should not be construed as an attack. Nameservers have always been expected to be able to handle such queries.
不明なオペコードの要求は通常のクライアントの動作であり、攻撃として解釈されるべきではありません。ネームサーバーは常にそのようなクエリを処理できると予想されています。
Requests with unassigned flags set (DNS or EDNS) are expected client behaviour and should not be construed as an attack. The behaviour for unassigned flags is to ignore them in the request and to not set them in the response. Dropping DNS/EDNS packets with unassigned flags makes it difficult to deploy extensions that make use of them due to the need to reconfigure and update firewalls.
未割り当てフラグセット（DNSまたはEDNS）を持つ要求は、クライアントの動作が予想されており、攻撃として解釈されるべきではありません。未割り当てフラグの動作は、要求内でそれらを無視し、それらを応答に設定しないことです。割り当てられていないフラグを持つDNS / EDNSパケットのドロップは、ファイアウォールを再設定して更新する必要があるため、それらを使用する拡張機能を展開することを困難にします。
Requests with unknown EDNS options are expected client behaviour and should not be construed as an attack. The correct behaviour for unknown EDNS options is to ignore their presence when constructing a reply.
不明なEDNSオプションを使用した要求は、クライアントの動作が期待されており、攻撃として解釈されるべきではありません。不明なEDNSオプションの正しい動作は、返信を構築するときにプレゼンスを無視することです。
Requests with unknown EDNS versions are expected client behaviour and should not be construed as an attack. The correct behaviour for unknown EDNS versions is to return BADVERS along with the highest EDNS version the server supports. Dropping EDNS packets breaks EDNS version negotiation.
不明なEDNSバージョンのリクエストは、クライアントの動作が予想されており、攻撃として解釈されるべきではありません。Unknown EDNSバージョンの正しい動作は、サーバーがサポートする最も高いEDNSバージョンと共にバージョンを返すことです。EDNSパケットを削除すると、EDNSのバージョンネゴシエーションが破損します。
Firewalls should not assume that there will only be a single response message to a request. There have been proposals to use EDNS to signal that multiple DNS messages be returned rather than a single UDP message that is fragmented at the IP layer.
ファイアウォールは、要求に単一の応答メッセージしかないと仮定しないでください。IP層で断片化されている単一のUDPメッセージではなく、複数のDNSメッセージが返されることを通知するためにEDNSを使用することが提案されています。
DNS, and EDNS in particular, are designed to allow clients to be able to use new features against older servers without having to validate every option. Indiscriminate blocking of messages breaks that design.
DNS、および特にEDNは、すべてのオプションを検証する必要なしに、クライアントが古いサーバーに対して新しい機能を使用できるようにするように設計されています。メッセージの欠けているブロッキングはそのデザインを破ります。
However, there may be times when a nameserver mishandles messages with a particular flag, EDNS option, EDNS version field, opcode, type or class field, or combination thereof to the point where the integrity of the nameserver is compromised. Firewalls should offer the ability to selectively reject messages using an appropriately constructed response based on all these fields while awaiting a fix from the nameserver vendor. Returning FORMERR or REFUSED are two potential error codes to return.
ただし、ネームサーバーが特定のフラグ、EDNSオプション、EDNSバージョンフィールド、オペコード、タイプ、またはクラスフィールド、または名前サーバーの整合性が損なわれているポイントへのメッセージとのメッセージを誤ってメッセージを送信する場合があります。ファイアウォールは、ネームサーバーベンダーからの修正を待っている間に、これらすべてのフィールドに基づいて適切に構築された応答を使用してメッセージを選択的に拒否する機能を提供する必要があります。以前の返却または拒否は、戻るための2つの潜在的なエラーコードです。
Packet scrubbing services are used to filter out undesired traffic, including but not limited to denial-of-service traffic. This is often done using heuristic analysis of the traffic.
パケットスクラビングサービスは、サービス拒否トラフィックを含むがこれらに限定されない、望ましくないトラフィックを除去するために使用される。これは、トラフィックのヒューリスティック分析を使用して行われます。
Packet scrubbing services can affect the externally visible behaviour of a nameserver in a similar way to firewalls. If an operator uses a packet scrubbing service, they should check that legitimate queries are not being blocked.
パケットスクラビングサービスは、ファイアウォールと同様の方法でネームサーバーの外部から見える動作に影響を与える可能性があります。オペレータがパケットスクラビングサービスを使用している場合、それらは正当なクエリがブロックされていないことを確認する必要があります。
Packet scrubbing services, unlike firewalls, are also turned on and off in response to denial-of-service attacks. One needs to take care when choosing a scrubbing service.
ファイアウォールとは異なり、パケットスクラビングサービスもサービス拒否攻撃に応じてオンオフされます。スクラビングサービスを選択するときは、注意する必要があります。
Ideally, operators should run these tests against a packet scrubbing service to ensure that these tests are not seen as attack vectors.
理想的には、演算子はパケットスクラビングサービスに対してこれらのテストを実行して、これらのテストが攻撃ベクトルとして見られないようにしてください。
Whole answer caches take a previously constructed answer and return it to a subsequent query for the same question. However, they can return the wrong response if they do not take all of the relevant attributes of the query into account.
回答キャッシュ全体は以前に構築された答えを取り、それを同じ質問に対して後続のクエリに戻します。ただし、クエリの関連する属性を考慮に入れない場合、それらは間違った応答を返すことができます。
In addition to the standard tuple of <qname,qtype,qclass>, a non-exhaustive set of attributes that must be considered include: RD, AD, CD, OPT record, DO, EDNS buffer size, EDNS version, EDNS options, and transport.
<qname、qtype、qclass>の標準タプルに加えて、考慮されなければならない網羅的な属性のセットは、次のとおりです.RD、AD、CD、OPT RECORD、DO、EDNSバッファサイズ、EDNSオプション、および輸送。
Choosing the correct response code when responding to DNS queries is important. Response codes should be chosen considering how clients will handle them.
DNSクエリに応答するときに正しい応答コードを選択することが重要です。応答コードは、クライアントがそれらをどのように処理するかを考慮して選択されるべきです。
For unimplemented opcodes, NOTIMP is the expected response code. Note: newly implemented opcodes may change the message format by extending the header, changing the structure of the records, etc. Servers are not expected to be able to parse these and should respond with a response code of NOTIMP rather than FORMERR (which would be expected if there was a parse error with a known opcode).
未実装のオペコードの場合、NOTIMPは予想される応答コードです。注：新しく実装されたオペコードは、ヘッダーを拡張し、レコードの構造を変更し、レコードの構造を変更することによってメッセージ形式を変更することがあります。サーバーはこれらを解析できることが期待されており、以前の方ではなくNOMIMPの応答コードで応答する必要があります。既知のオペコードで解析誤りがあった場合は予想されます。
For unimplemented type codes, and in the absence of other errors, the only valid response is NOERROR if the qname exists and NXDOMAIN otherwise. For Meta-RRs, NOTIMP may be returned instead.
未実装型コードの場合、および他のエラーがない場合は、QNAMEが存在し、NXDomainが存在する場合、唯一の有効な応答はNoErrorです。META-RRSの場合、NOTIMPは代わりに返される可能性があります。
If a zone cannot be loaded because it contains unimplemented type codes that are not encoded as unknown record types according to [RFC3597], then the expected response is SERVFAIL, as the whole zone should be rejected (Section 5.2 of [RFC1035]). If a zone loads, then Section 4.3.2 of [RFC1034] applies.
[RFC3597]に従って未知のレコードタイプとしてエンコードされていない未実装型コードが含まれているため、ゾーンをロードできない場合は、ゾーン全体を拒否する必要があるため、予想される応答はSERVFAILです（[RFC1035]のセクション5.2）。ゾーンがロードされている場合は、[RFC1034]のセクション4.3.2が適用されます。
If the server supports EDNS and receives a query with an unsupported EDNS version, the correct response is BADVERS [RFC6891].
サーバーがEDNSをサポートしてサポートされていないEDNSバージョンでクエリを受信した場合、正しい応答はBADVERS [RFC6891]です。
If the server does not support EDNS at all, FORMERR is the expected error code. That said, a minimal EDNS server implementation requires parsing the OPT records and responding with an empty OPT record in the additional section in most cases. There is no need to interpret any EDNS options present in the request, as unsupported EDNS options are expected to be ignored [RFC6891]. Additionally, EDNS flags can be ignored. The only part of the OPT record that needs to be examined is the version field to determine if BADVERS needs to be sent or not.
サーバーがEDNSをまったくサポートしていない場合以前は予想されるエラーコードです。つまり、最小限のEDNSサーバーの実装では、ほとんどの場合、追加のセクションでオプトレコードを解析し、空のOPTレコードを使用して応答する必要があります。サポートされていないEDNSオプションが無視されると予想されるように、要求に存在するEDNSオプションを解釈する必要はありません[RFC6891]。さらに、EDNSフラグは無視できます。検査する必要があるオプトレコードの唯一の部分は、バージョンを送信する必要があるかどうかを判断するためのバージョンフィールドです。
Testing is divided into two sections: "Basic DNS", which all servers should meet, and "Extended DNS", which should be met by all servers that support EDNS (a server is deemed to support EDNS if it gives a valid EDNS response to any EDNS query). If a server does not support EDNS, it should still respond to all the tests, albeit with error responses.
テストは2つのセクションに分かれています。 "基本DNS"が「基本DNS」に分けて、すべてのサーバーを満たす必要があります。任意のEDNSクエリ）。サーバーがEDNSをサポートしていない場合は、エラー応答に関連しても、すべてのテストに応答する必要があります。
These tests query for records at the apex of a zone that the server is nominally configured to serve. All tests should use the same zone.
これらのテストは、サーバーが名目上サービスを提供するように構成されているゾーンの頂点のレコードを照会します。すべてのテストは同じゾーンを使用する必要があります。
It is advisable to run all of the tests below in parallel so as to minimise the delays due to multiple timeouts when the servers do not respond. There are 16 queries directed to each nameserver (assuming no packet loss) testing different aspects of Basic DNS and Extended DNS.
サーバーが応答しないときに複数のタイムアウトによる遅延を最小限に抑えるように、以下のすべてのテストを並列に実行することをお勧めします。各ネームサーバーに向けられたクエリは、基本的なDNSと拡張DNのさまざまな側面をテストします。
The tests below use dig from BIND 9.11.0 [ISC]. Replace $zone with the name of the zone being used for testing. Replace $server with the name or address of the server being tested.
以下のテストはBIND 9.11.0 [ISC]からDIGを使用します。テストに使用されているゾーンの名前で$ ZONEを置き換えます。テストされているサーバーの名前またはアドレスに$ SERVERを置き換えます。
When testing, recursive servers set RD=1 and choose a zone name that is known to exist and is not being served by the recursive server. The root zone (".") is often a good candidate, as it is DNSSEC signed. RD=1, rather than RD=0, should be present in the responses for all test involving the opcode QUERY. Non-authoritative answers (AA=0) are expected when talking to a recursive server. AD=1 is only expected if the server is validating responses and one or both AD=1 or DO=1 is set in the request, otherwise AD=0 is expected.
テストすると、再帰サーバーはRD = 1を設定し、存在するゾーン名を選択し、再帰サーバーによって提供されていません。ルートゾーン（ "。"）は、署名されたDNSSECであるため、優れた候補者です。RD = 0ではなくRD = 1は、オペコードクエリを含むすべてのテストの応答に存在する必要があります。再帰的なサーバーと通信すると、権限のない回答（AA = 0）が予想されます。AD = 1は、サーバーが応答を検証していて、ad = 1またはdo = 1の両方が要求に設定されている場合にのみ予想されます。それ以外の場合はAD = 0が予想されます。
This first set of tests cover Basic DNS server behaviour and all servers should pass these tests.
この最初のテストセットは、基本的なDNSサーバーの動作をカバーし、すべてのサーバーはこれらのテストを渡す必要があります。
Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set and without EDNS.
設定されたゾーンのSOAレコードを依頼してください。このクエリは、設定されていないDNSフラグビットがEDNで行われずに行われます。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the Authoritative Answer (AA) and Query/Response (QR) bits to be set in the header; the Recursion Available (RA) bits may also be set [RFC1034]. We do not expect an OPT record to be returned [RFC6891].
回答セクション、RCODEをNoErrorに設定するゾーンのSOAレコード、およびヘッダーに設定される権限のある回答（AA）とクエリ/レスポンス（QR）ビットが予想されます。利用可能な再帰（RA）ビットも設定することができます[RFC1034]。Opt Recordが返されることを期待していません[RFC6891]。
Verify the server is configured for the zone:
サーバーがゾーンに設定されていることを確認します。
dig +noedns +noad +norec soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: flag: aa to be present
expect: flag: rd to NOT be present
expect: flag: ad to NOT be present
expect: the OPT record to NOT be present
Identifying servers that fail to respond to unknown or unsupported types can be done by making an initial DNS query for an A record, making a number of queries for an unallocated type, then making a query for an A record again. IANA maintains a registry of allocated types [IANA-DNS].
未知またはサポートされていない型に応答できないサーバーの識別は、Aレコードの最初のDNSクエリを実行し、未割り当て型のクエリをいくつか実行してから、再度Aレコードのクエリを作成することで実行できます。IANAは割り当てられた型のレジストリを管理します[IANA-DNS]。
If the server responds to the first and last queries but fails to respond to the queries for the unallocated type, it is probably faulty. The test should be repeated a number of times to eliminate the likelihood of a false positive due to packet loss.
サーバーが最初と最後のクエリに応答していても、未割り当て型のクエリに応答できない場合は、おそらく不良です。パケット損失のために、誤損失の可能性を排除するためにテストを繰り返す必要があります。
Ask for the TYPE1000 RRset at the configured zone's name. This query is made with no DNS flag bits set and without EDNS. TYPE1000 has been chosen for this purpose, as IANA is unlikely to allocate this type in the near future and it is not in a range reserved for private use [RFC6895]. Any unallocated type code could be chosen for this test.
設定されたゾーンの名前でType1000 RRSetを依頼してください。このクエリは、設定されていないDNSフラグビットがEDNで行われずに行われます。IANAが近い将来このタイプを割り当てることはほとんどないので、type1000はこの目的のために選ばれました、そしてそれは私的使用のために予約されている範囲ではありません[RFC6895]。このテストには、未割り当て型コードを選択できます。
We expect no records to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the header; RA may also be set [RFC1034]. We do not expect an OPT record to be returned [RFC6891].
回答セクションでレコードを返し、RCODEをNOERORに設定し、ヘッダーに設定されるAAとQRビットを期待しています。RAも設定することができます[RFC1034]。Opt Recordが返されることを期待していません[RFC6891]。
Check that queries for an unknown type work:
未知のタイプの作業のクエリを確認してください。
dig +noedns +noad +norec type1000 $zone @$server
expect: status: NOERROR
expect: an empty answer section.
expect: flag: aa to be present
expect: flag: rd to NOT be present
expect: flag: ad to NOT be present
expect: the OPT record to NOT be present
Ask for the SOA record of the configured zone. This query is made with only the CD DNS flag bit set, with all other DNS bits clear, and without EDNS.
設定されたゾーンのSOAレコードを依頼してください。このクエリは、他のすべてのDNSビットをクリアし、EDNSなしでCD DNSフラグビットセットのみで行われます。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the header. We do not expect an OPT record to be returned.
ゾーンのSOAレコードが回答セクションに戻されること、RCODEをNOERRORに設定し、ヘッダーに設定するAAとQRビットを期待しています。オプトレコードが返却されることを期待していません。
If the server supports DNSSEC, CD should be set in the response [RFC4035]; otherwise, CD should be clear [RFC1034].
サーバーがDNSSECをサポートしている場合は、応答でCDを設定する必要があります[RFC4035]。それ以外の場合は、CDはクリアです[RFC1034]。
Check that queries with CD=1 work:
CD = 1の作業でクエリをチェックしてください。
dig +noedns +noad +norec +cd soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: flag: aa to be present
expect: flag: rd to NOT be present
expect: flag: ad to NOT be present
expect: the OPT record to NOT be present
Ask for the SOA record of the configured zone. This query is made with only the AD DNS flag bit set, with all other DNS bits clear, and without EDNS.
設定されたゾーンのSOAレコードを依頼してください。このクエリは、AD DNSフラグビットセットのみで行われ、他のすべてのDNSビットはクリア、およびEDNSなしで行われます。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the header. We do not expect an OPT record to be returned. The purpose of this query is to detect blocking of queries with the AD bit present, not the specific value of AD in the response.
ゾーンのSOAレコードが回答セクションに戻されること、RCODEをNOERRORに設定し、ヘッダーに設定するAAとQRビットを期待しています。オプトレコードが返却されることを期待していません。このクエリの目的は、応答の特定のADの特定の値ではなく、ADビットを持つクエリのブロックを検出することです。
Check that queries with AD=1 work:
AD = 1の作業でクエリを確認してください。
dig +noedns +norec +ad soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: flag: aa to be present
expect: flag: rd to NOT be present
expect: the OPT record to NOT be present
AD use in queries is defined in [RFC6840].
Queriesでの広告使用は[RFC6840]で定義されています。
Ask for the SOA record of the configured zone. This query is made with only the final reserved DNS flag bit set, with all other DNS bits clear, and without EDNS.
設定されたゾーンのSOAレコードを依頼してください。このクエリは、他のすべてのDNSビットがクリア、およびEDNSなしで、最終予約済みDNSフラグビットセットのみで行われます。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the header; RA may be set. The final reserved bit must not be set [RFC1034]. We do not expect an OPT record to be returned [RFC6891].
ゾーンのSOAレコードが回答セクションで返され、RCODEをNoErrorに設定すると、ヘッダーに設定されているAAとQRビットが予想されます。RAを設定することができます。最終予約ビットを設定してはいけません[RFC1034]。Opt Recordが返されることを期待していません[RFC6891]。
Check that queries with the last unassigned DNS header flag work and that the flag bit is not copied to the response:
最後に未割り当てのDNSヘッダーフラグの作業とフラグビットが応答にコピーされないことを確認してください。
dig +noedns +noad +norec +zflag soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: MBZ to NOT be in the response (see below)
expect: flag: aa to be present
expect: flag: rd to NOT be present
expect: flag: ad to NOT be present
expect: the OPT record to NOT be present
MBZ (Must Be Zero) is a dig-specific indication that the flag bit has been incorrectly copied. See Section 4.1.1 of [RFC1035]:
MBZ（ゼロでなければなりません）は、フラグビットが間違ってコピーされているというDIG固有の表示です。[RFC1035]のセクション4.1.1を参照してください。
"Z Reserved for future use. Must be zero in all queries and responses."
"Z将来の使用のために予約されています。すべてのクエリと応答ではゼロでなければなりません。」
Ask for the SOA record of the configured zone. This query is made with only the RD DNS flag bit set and without EDNS.
設定されたゾーンのSOAレコードを依頼してください。このクエリは、RD DNSフラグビットセットとEDNSなしでのみ行われます。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA, QR and RD bits to be set in the header; RA may also be set [RFC1034]. We do not expect an OPT record to be returned [RFC6891].
ゾーンのSOAレコードが回答セクションで返されること、RCODEはNOERROR、およびヘッダーに設定されるAA、QR、およびRDビットを予想しています。RAも設定することができます[RFC1034]。Opt Recordが返されることを期待していません[RFC6891]。
Check that recursive queries work:
再帰的クエリが機能することを確認してください。
dig +noedns +noad +rec soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: flag: aa to be present
expect: flag: rd to be present
expect: flag: ad to NOT be present
expect: the OPT record to NOT be present
Construct a DNS message that consists of only a DNS header with opcode set to 15 (currently not allocated), no DNS header bits set, and empty question, answer, authority, and additional sections.
OPCODEが15（現在割り当てられていない）、DNSヘッダービットを設定し、空の質問、回答、権限、および追加のセクションのないDNSヘッダーのみからなるDNSメッセージを作成します。
Check that new opcodes are handled:
新しいオペコードが処理されていることを確認してください。
dig +noedns +noad +opcode=15 +norec +header-only @$server
expect: status: NOTIMP
expect: opcode: 15
expect: all sections to be empty
expect: flag: aa to NOT be present
expect: flag: rd to NOT be present
expect: flag: ad to NOT be present
expect: the OPT record to NOT be present
Whether a server accepts TCP connections can be tested by first checking that it responds to UDP queries to confirm that it is up and operating, then attempting the same query over TCP. An additional query should be made over UDP if the TCP connection attempt fails to confirm that the server under test is still operating.
サーバーがTCP接続を受け入れるかどうかは、最初にUDPクエリに応答して起動して動作していることを確認してからTCPを介して同じクエリを試みることでテストできます。TCP接続が試行されたサーバーがまだ動作していることを確認できない場合は、追加のクエリをUDPを介して行う必要があります。
Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set and without EDNS. This query is to be sent using TCP.
設定されたゾーンのSOAレコードを依頼してください。このクエリは、設定されていないDNSフラグビットがEDNで行われずに行われます。このクエリはTCPを使用して送信されます。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the header; RA may also be set [RFC1034]. We do not expect an OPT record to be returned [RFC6891].
ゾーンのSOAレコードが回答セクションで返され、RCODEをNoErrorに設定すると、ヘッダーに設定されているAAとQRビットが予想されます。RAも設定することができます[RFC1034]。Opt Recordが返されることを期待していません[RFC6891]。
Check that TCP queries work:
TCPクエリが機能していることを確認してください。
dig +noedns +noad +norec +tcp soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: flag: aa to be present
expect: flag: rd to NOT be present
expect: flag: ad to NOT be present
expect: the OPT record to NOT be present
The requirement that TCP be supported is defined in [RFC7766].
TCPをサポートする要件は[RFC7766]で定義されています。
The next set of tests cover various aspects of EDNS behaviour. If any of these tests succeed (indicating at least some EDNS support), then all of them should succeed. There are servers that support EDNS but fail to handle plain EDNS queries correctly, so a plain EDNS query is not a good indicator of lack of EDNS support.
次のテストセットは、EDNSの動作のさまざまな側面をカバーしています。これらのテストのいずれかが成功した場合（少なくともいくつかのEDNSサポートを示す）、それらのすべてが成功する必要があります。EDNSをサポートするサーバーがありますが、プレーンEDNSクエリを正しく処理できないため、プレーンEDNSクエリはEDNSサポートの不足の良いインジケータではありません。
Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS options or EDNS flags set.
設定されたゾーンのSOAレコードを依頼してください。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン0は、EDNSオプションまたはEDNSフラグが設定されていなくても使用されます。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response. The EDNS version field should be 0, and there should be no EDNS options present [RFC6891].
ゾーンのSOAレコードが回答セクションで返され、RCODEをNoErrorに設定すると、ヘッダーに設定されているAAとQRビットが予想されます。RAも設定することができます[RFC1034]。オプトレコードが返却されることを期待しています。応答に存在するEDNSフラグが存在しないはずです。EDNSバージョンフィールドは0にする必要があり、eDNSオプションが存在しない[RFC6891]。
Check that plain EDNS queries work:
PLAIN EDNSクエリが機能していることを確認してください。
dig +nocookie +edns=0 +noad +norec soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section
expect: EDNS Version 0 in response
expect: flag: aa to be present
expect: flag: ad to NOT be present
+nocookie disables sending an EDNS COOKIE option, which is otherwise enabled by default in BIND 9.11.0 (and later).
NOCookieはEDNS Cookieオプションの送信を無効にします。
Ask for the SOA record of a zone the server is nominally configured to serve. This query is made with no DNS flag bits set. EDNS version 1 is used without any EDNS options or EDNS flags set.
ゾーンのSOAレコードを要求するサーバーは名目上サービスを提供するように構成されています。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン1は、EDNSオプションまたはEDNSフラグが設定されていなくても使用されます。
We expect the SOA record for the zone to NOT be returned in the answer section with the extended rcode set to BADVERS and the QR bit to be set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response. The EDNS version field should be 0 in the response, as no other EDNS version has as yet been specified [RFC6891].
拡張rcodeがバリバーとヘッダーに設定されるQRビットにセットされた状態で、ゾーンのSOAレコードが返信セクションで返されないことを期待しています。RAも設定することができます[RFC1034]。オプトレコードが返却されることを期待しています。応答に存在するEDNSフラグが存在しないはずです。他のEDNSバージョンがまだ指定されていない場合は、応答にEDNSバージョンフィールドが0になる必要があります[RFC6891]。
Check that EDNS version 1 queries work (EDNS supported):
EDNSバージョン1クエリの作業（EDNSサポート）を確認してください。
dig +nocookie +edns=1 +noednsneg +noad +norec soa $zone @$server
expect: status: BADVERS
expect: the SOA record to NOT be present in the answer section
expect: an OPT record to be present in the additional section
expect: EDNS Version 0 in response
expect: flag: aa to NOT be present
expect: flag: ad to NOT be present
+noednsneg has been set, as dig supports EDNS version negotiation, and we want to see only the response to the initial EDNS version 1 query.
DigがEDNSバージョンネゴシエーションをサポートしているため、NoEREDnsnegが設定されており、最初のEDNSバージョン1クエリに対する応答のみを見たいと思う。
Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS flags. An EDNS option is present with a value that has not yet been assigned by IANA. We have picked an unassigned code of 100 for the example below. Any unassigned EDNS option code could have been chosen for this test.
設定されたゾーンのSOAレコードを依頼してください。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン0は、EDNSフラグなしで使用されます。eDNSオプションは、IANAによってまだ割り当てられていない値があります。以下の例では、未割り当てコード100を選びました。このテストのために、未割り当てのEDNSオプションコードが選択されている可能性があります。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response. The EDNS version field should be 0, as EDNS versions other than 0 are yet to be specified, and there should be no EDNS options present, as unknown EDNS options are supposed to be ignored by the server (Section 6.1.1 of [RFC6891]).
ゾーンのSOAレコードが回答セクションで返され、RCODEをNoErrorに設定すると、ヘッダーに設定されているAAとQRビットが予想されます。RAも設定することができます[RFC1034]。オプトレコードが返却されることを期待しています。応答に存在するEDNSフラグが存在しないはずです。0以外のEDNSバージョンはまだ指定されていないので、EDNSバージョンフィールドは0になる必要があり、未知のEDNSオプションがサーバーによって無視されることになっているため、EDNSオプションが存在しないはずです（[RFC6891]のセクション6.1.1）。
Check that EDNS queries with an unknown option work (EDNS supported):
EDNSが不明なオプション作業（EDNSサポート）でクエリを照会することを確認してください。
dig +nocookie +edns=0 +noad +norec +ednsopt=100 soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section
expect: OPT=100 to NOT be present
expect: EDNS Version 0 in response
expect: flag: aa to be present
expect: flag: ad to NOT be present
Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS options. An unassigned EDNS flag bit is set (0x40 in this case).
設定されたゾーンのSOAレコードを依頼してください。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン0は、EDNSオプションなしで使用されます。未割り当てのEDNSフラグビットが設定されます（この場合は0x40）。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response, as unknown EDNS flags are supposed to be ignored. The EDNS version field should be 0, and there should be no EDNS options present [RFC6891].
ゾーンのSOAレコードが回答セクションで返され、RCODEをNoErrorに設定すると、ヘッダーに設定されているAAとQRビットが予想されます。RAも設定することができます[RFC1034]。オプトレコードが返却されることを期待しています。未知のEDNSフラグが無視されるべきであると考えられるので、応答に存在するEDNSフラグがないはずです。EDNSバージョンフィールドは0にする必要があり、eDNSオプションが存在しない[RFC6891]。
Check that EDNS queries with unknown flags work (EDNS supported):
EDNSが不明なFlags Work（EDNSサポート）でクエリを照会することを確認してください。
dig +nocookie +edns=0 +noad +norec +ednsflags=0x40 soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section
expect: MBZ not to be present
expect: EDNS Version 0 in response
expect: flag: aa to be present
expect: flag: ad to NOT be present
MBZ (Must Be Zero) is a dig-specific indication that a flag bit has been incorrectly copied, as per Section 6.1.4 of [RFC6891].
MBZ（ゼロでなければなりません）は、[RFC6891]のセクション6.1.4に従って、フラグビットが間違ってコピーされたことを示す特定の指示です。
Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 1 is used without any EDNS options. An unassigned EDNS flag bit is set (0x40 in this case).
設定されたゾーンのSOAレコードを依頼してください。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン1は、EDNSオプションなしで使用されます。未割り当てのEDNSフラグビットが設定されます（この場合は0x40）。
We expect the SOA record for the zone to NOT be returned in the answer section with the extended rcode set to BADVERS and the QR bit to be set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response, as unknown EDNS flags are supposed to be ignored. The EDNS version field should be 0, as EDNS versions other than 0 are yet to be specified, and there should be no EDNS options present [RFC6891].
拡張rcodeがバリバーとヘッダーに設定されるQRビットにセットされた状態で、ゾーンのSOAレコードが返信セクションで返されないことを期待しています。RAも設定することができます[RFC1034]。オプトレコードが返却されることを期待しています。未知のEDNSフラグが無視されるべきであると考えられるので、応答に存在するEDNSフラグがないはずです。0以外のEDNSバージョンはまだ指定されていないため、EDNSバージョンフィールドは0になり、EDNSオプションが存在しない[RFC6891]がないはずです。
Check that EDNS version 1 queries with unknown flags work (EDNS supported):
EDNSバージョン1が不明なフラグが機能しているクエリ（EDNSサポート）を確認してください。
dig +nocookie +edns=1 +noednsneg +noad +norec +ednsflags=0x40 soa \
$zone @$server
expect: status: BADVERS
expect: SOA record to NOT be present
expect: an OPT record to be present in the additional section
expect: MBZ not to be present
expect: EDNS Version 0 in response
expect: flag: aa to NOT be present
expect: flag: ad to NOT be present
Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 1 is used. An unknown EDNS option is present. We have picked an unassigned code of 100 for the example below. Any unassigned EDNS option code could have been chosen for this test.
設定されたゾーンのSOAレコードを依頼してください。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン1が使用されます。不明なEDNSオプションが存在します。以下の例では、未割り当てコード100を選びました。このテストのために、未割り当てのEDNSオプションコードが選択されている可能性があります。
We expect the SOA record for the zone to NOT be returned in the answer section with the extended rcode set to BADVERS and the QR bit to be set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response. The EDNS version field should be 0, as EDNS versions other than 0 are yet to be specified, and there should be no EDNS options present [RFC6891].
拡張rcodeがバリバーとヘッダーに設定されるQRビットにセットされた状態で、ゾーンのSOAレコードが返信セクションで返されないことを期待しています。RAも設定することができます[RFC1034]。オプトレコードが返却されることを期待しています。応答に存在するEDNSフラグが存在しないはずです。0以外のEDNSバージョンはまだ指定されていないため、EDNSバージョンフィールドは0になり、EDNSオプションが存在しない[RFC6891]がないはずです。
Check that EDNS version 1 queries with unknown options work (EDNS supported):
EDNSバージョン1が不明なオプション作業（EDNSサポート）でクエリを含めることを確認してください。
dig +nocookie +edns=1 +noednsneg +noad +norec +ednsopt=100 soa \
$zone @$server
expect: status: BADVERS
expect: SOA record to NOT be present
expect: an OPT record to be present in the additional section
expect: OPT=100 to NOT be present
expect: EDNS Version 0 in response
expect: flag: aa to NOT be present
expect: flag: ad to NOT be present
Ask for the DNSKEY records of the configured zone, which must be a DNSSEC signed zone. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS options. The only EDNS flag set is DO. The EDNS UDP buffer size is set to 512. The intention of this query is to elicit a truncated response from the server. Most signed DNSKEY responses are bigger than 512 bytes. This test will not give a valid result if the zone is not signed.
設定されたゾーンのDNSKeyレコードを依頼してください。これは、DNSSEC署名付きゾーンでなければなりません。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン0は、EDNSオプションなしで使用されます。唯一のEDNSフラグセットはdoです。EDNS UDPバッファサイズは512に設定されています。このクエリの意図は、サーバーから切り捨てられた応答を引き出すことです。ほとんどの署名されたDNSKey応答は512バイトより大きいです。ゾーンが署名されていない場合、このテストは有効な結果を与えません。
We expect a response, the rcode to be set to NOERROR, and the AA and QR bits to be set. AD may be set in the response if the server supports DNSSEC; otherwise it should be clear; TC and RA may also be set [RFC1035] [RFC4035]. We expect an OPT record to be present in the response. There should be no EDNS flags other than DO present in the response. The EDNS version field should be 0, and there should be no EDNS options present [RFC6891].
応答、RCODEをNOERRORに設定し、AAとQRビットを設定することを期待しています。サーバーがDNSSECをサポートしている場合は、ADを応答に設定できます。それ以外の場合は明確になるはずです。TCとRAも設定できます[RFC1035] [RFC4035]。私たちは対応の中でOpt Recordが存在することを期待しています。応答に存在する以外のEDNSフラグはありません。EDNSバージョンフィールドは0にする必要があり、eDNSオプションが存在しない[RFC6891]。
If TC is not set, it is not possible to confirm that the server correctly adds the OPT record to the truncated responses or not.
TCが設定されていない場合は、サーバーがOpt Recordを切り捨てられた応答に正しく追加することを確認することはできません。
dig +norec +dnssec +bufsize=512 +ignore dnskey $zone @$server
expect: NOERROR
expect: OPT record with version set to 0
Ask for the SOA record of the configured zone, which does not need to be DNSSEC signed. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS options. The only EDNS flag set is DO.
設定されたゾーンのSOAレコードを求めます。これはDNSSECに署名されている必要はありません。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン0は、EDNSオプションなしで使用されます。唯一のEDNSフラグセットはdoです。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the response. AD may be set in the response if the server supports DNSSEC, otherwise it should be clear; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags other than DO present in the response, which should be present if the server supports DNSSEC. The EDNS version field should be 0, and there should be no EDNS options present [RFC6891].
回答セクションに戻すゾーンのSOAレコード、RCODEがNOERORに設定され、AAとQRビットが応答に設定されます。サーバーがDNSSECをサポートしている場合は、ADが応答に設定されます。それ以外の場合は明確になるはずです。RAも設定することができます[RFC1034]。オプトレコードが返却されることを期待しています。応答に存在する以外のEDNSフラグはありません。これは、サーバーがDNSSECをサポートしている場合に存在する必要があります。EDNSバージョンフィールドは0にする必要があり、eDNSオプションが存在しない[RFC6891]。
Check that DO=1 queries work (EDNS supported):
DO = 1クエリの作業（EDNSサポート）を確認してください。
dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section
expect: DO=1 to be present if an RRSIG is in the response
expect: EDNS Version 0 in response
expect: flag: aa to be present
Ask for the SOA record of the configured zone, which does not need to be DNSSEC signed. This query is made with no DNS flag bits set. EDNS version 1 is used without any EDNS options. The only EDNS flag set is DO.
設定されたゾーンのSOAレコードを求めます。これはDNSSECに署名されている必要はありません。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン1は、EDNSオプションなしで使用されます。唯一のEDNSフラグセットはdoです。
We expect the SOA record for the zone NOT to be returned in the answer section, the extended rcode to be set to BADVERS, and the QR bit to be set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags other than DO present in the response, which should be there if the server supports DNSSEC. The EDNS version field should be 0, and there should be no EDNS options present [RFC6891].
回答セクションで返されないゾーンのSOAレコード、拡張RCODE、拡張RCODE、およびヘッダーに設定されるQRビットが予想されます。RAも設定することができます[RFC1034]。オプトレコードが返却されることを期待しています。応答に存在しない以外のEDNSフラグはありません。これは、サーバーがDNSSECをサポートしている場合はそこにあるはずです。EDNSバージョンフィールドは0にする必要があり、eDNSオプションが存在しない[RFC6891]。
Check that EDNS version 1, DO=1 queries work (EDNS supported):
EDNSバージョン1、DO = 1の照会作業（EDNSサポート）を確認します。
dig +nocookie +edns=1 +noednsneg +noad +norec +dnssec soa \
$zone @$server
expect: status: BADVERS
expect: SOA record to NOT be present
expect: an OPT record to be present in the additional section
expect: DO=1 to be present if the EDNS version 0 DNSSEC query test
returned DO=1
expect: EDNS Version 0 in response
expect: flag: aa to NOT be present
Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 0 is used. A number of defined EDNS options are present (NSID [RFC5001], DNS COOKIE [RFC7873], EDNS Client Subnet [RFC7871], and EDNS Expire [RFC7314]).
設定されたゾーンのSOAレコードを依頼してください。このクエリは、DNSフラグビットを設定しないで行われます。EDNSバージョン0が使用されます。いくつかの定義されたEDNSオプションが存在する（NSID [RFC5001]、DNS Cookie [RFC7873]、EDNSクライアントサブネット[RFC7871]、およびEDNSの有効期限[RFC7314]）。
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response. The EDNS version field should be 0. Any of the requested EDNS options supported by the server and permitted server configuration may be returned [RFC6891].
ゾーンのSOAレコードが回答セクションで返され、RCODEをNoErrorに設定すると、ヘッダーに設定されているAAとQRビットが予想されます。RAも設定することができます[RFC1034]。オプトレコードが返却されることを期待しています。応答に存在するEDNSフラグが存在しないはずです。EDNSバージョンフィールドは0にする必要があります。サーバーでサポートされている要求されたEDNSオプションと許可されたサーバー構成のいずれかを返すことができます[RFC6891]。
Check that EDNS queries with multiple defined EDNS options work:
複数の定義済みのEDNSオプションの作業を使用してEDNSクエリを確認してください。
dig +edns=0 +noad +norec +cookie +nsid +expire +subnet=0.0.0.0/0 \
soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section
expect: EDNS Version 0 in response
expect: flag: aa to be present
expect: flag: ad to NOT be present
If EDNS is not supported by the nameserver, we expect a response to each of the above queries. That response may be a FORMERR error response, or the OPT record may just be ignored.
EDNSがネームサーバーでサポートされていない場合は、上記の各クエリに対する応答が期待されます。その応答は旧エラー応答であり得るか、またはオプトレコードは無視されてもよい。
Some nameservers only return an EDNS response when a particular EDNS option or flag (e.g., DO=1) is present in the request. This behaviour is not compliant behaviour and may hide other incorrect behaviour from the above tests. Retesting with the triggering option/flag present will expose this misbehaviour.
特定のEDNSオプションまたはフラグ（例えば、DO = 1）が要求に存在する場合にのみ、NameServersがEDNS応答を返すだけです。この現象は準拠していない行動ではなく、上記のテストから他の不正確な動作を隠すことがあります。トリガーオプション/フラグが存在して再テストすると、この不正行為がさらされます。
Nameserver operators are generally expected to test their own infrastructure for compliance to standards. The above tests should be run when new systems are brought online and should be repeated periodically to ensure continued interoperability.
NameServer演算子は一般に、規格への準拠のために独自のインフラストラクチャをテストすることが予想されます。上記のテストは、新しいシステムがオンラインになったときに実行されるべきであり、継続的な相互運用性を確実にするために定期的に繰り返されるべきです。
Domain registrants who do not maintain their own DNS infrastructure are entitled to a DNS service that conforms to standards and interoperates well. Registrants who become aware that their DNS operator does not have a well-maintained or compliant infrastructure should insist that their service provider correct issues and switch providers if they do not.
独自のDNSインフラストラクチャを維持しないドメイン登録は、標準に準拠しているDNSサービスを提供し、順守することができます。彼らのDNS演算子が維持されていない、または準拠したインフラストラクチャを持っていないことを知っている登録者は、彼らのサービスプロバイダーがそうでなければプロバイダーを正しく変更し、スイッチを切り替えることを主張するべきです。
In the event that an operator experiences problems due to the behaviour of nameservers outside their control, the above tests will help in narrowing down the precise issue(s), which can then be reported to the relevant party.
オペレータが自分の管理外のネームサーバーの動作のために問題を経験した場合、上記のテストは正確な問題を絞り込むのに役立ちます。これは関連当事者に報告されることができます。
If contact information for the operator of a misbehaving nameserver is not already known, the following methods of communication could be considered:
誤動作ネームサーバのオペレータの連絡先情報がまだわかっていない場合、以下の通信方法が考慮され得る。
* the RNAME of the zone authoritative for the name of the misbehaving server
* 誤動作サーバの名前に対するゾーンの名前
* the RNAME of zones for which the offending server is authoritative
* 問題のあるサーバーが権威あるゾーンの名前
* administrative or technical contacts listed in the registration information for the parent domain of the name of the misbehaving server or for zones for which the nameserver is authoritative
* 誤動作サーバーの名前の親ドメインまたはネームサーバーが信頼できるゾーンの登録情報にリストされている管理または技術的な連絡先
* the registrar or registry for such zones
* そのようなゾーンのレジストラまたはレジストリ
* DNS-specific, operational fora (e.g., mailing lists)
* DNS固有の運用上の運用上（例えば、メーリングリスト）
Operators of parent zones may wish to regularly test the authoritative nameservers of their child zones. However, parent operators can have widely varying capabilities in terms of notification or remediation depending on whether they have a direct relationship with the child operator. Many Top-Level Domain (TLD) registries, for example, cannot directly contact their registrants and may instead need to communicate through the relevant registrar. In such cases, it may be most efficient for registrars to take on the responsibility for testing the nameservers of their registrants, since they have a direct relationship.
親ゾーンの演算子は、子ゾーンの信頼できるネームサーバーを定期的にテストしたいと思うかもしれません。ただし、親演算子は、子演算子との直接関係があるかどうかに応じて、通知または修復の点で広く変化する機能を持つことができます。たとえば、多くの最上位ドメイン（TLD）レジストリは、それらの登録者に直接連絡することはできず、代わりに関連レジストラを介して通信する必要があるかもしれません。そのような場合、彼らは直接の関係を持つので、レジストラに登録者のネームサーバーをテストする責任を負うことが最も効率的かもしれません。
When notification is not effective at correcting problems with a misbehaving nameserver, parent operators can choose to remove NS record sets (and glue records below) that refer to the faulty server until the servers are fixed. This should only be done as a last resort and with due consideration, as removal of a delegation can have unanticipated side effects. For example, other parts of the DNS tree may depend on names below the removed zone cut, and the parent operator may find themselves responsible for causing new DNS failures to occur.
不正なネームサーバーに関する問題の補正に通知が効果的でない場合、親演算子は、サーバーが固定されるまで、障害のあるサーバーを参照するNSレコードセット（および下の接着レコード）を削除することを選択できます。これは最後の手段としてのみ行われるべきであり、代表団の除去が予期しない副作用を持つことができるので、十分な手段として行われるべきです。たとえば、DNSツリーの他の部分は、削除されたゾーンカットの下の名前に依存し、親オペレータは新しいDNSの障害が発生した原因となる可能性があります。
Testing protocol compliance can potentially result in false reports of attempts to attack services from Intrusion Detection Services and firewalls. All of the tests are well-formed (though not necessarily common) DNS queries. None of the tests listed above should cause any harm to a protocol-compliant server.
プロトコルコンプライアンスのテストは潜在的に侵入検知サービスやファイアウォールからサービスを攻撃する試みの誤った報告をもたらす可能性があります。すべてのテストは整形式（必ずしも一般的ではないが）DNSクエリを整形する。上記のテストのどれも、プロトコル準拠サーバーに害を及ぼします。
Relaxing firewall settings to ensure EDNS compliance could potentially expose a critical implementation flaw in the nameserver. Nameservers should be tested for conformance before relaxing firewall settings.
リラックスしたファイアウォール設定の設定EDNSコンプライアンスがネームサーバーに重要な実装欠陥を潜在的に公開できるようにすることができるようにします。ファイアウォール設定をリラックスする前に、ネームサーバーを適合性のためにテストする必要があります。
When removing delegations for non-compliant servers, there can be a knock-on effect on other zones that require these zones to be operational for the nameservers addresses to be resolved.
準拠していないサーバーの代行を削除するときは、これらのゾーンが解決されるネームサーバーアドレスに対して動作可能であることを必要とする他のゾーンにノックオン効果がある可能性があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https：//www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, DOI 10.17487/RFC3225, December 2001, <https://www.rfc-editor.org/info/rfc3225>.
[RFC3225] Conrad、D.、「DNSSECのレゾルバのサポートの表示」、RFC 3225、DOI 10.17487 / RFC3225、2001年12月、<https://www.rfc-editor.org/info/rfc3225>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、M.、Massey、D.、およびS. Rose、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、<https://www.rfc-editor.org/info/rfc4035>。
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, <https://www.rfc-editor.org/info/rfc6840>.
[RFC6840] Weiler、S.、ED。2013年2月、<https://ww.rfc-editor.org/info/rfc6840、<https：//ww.rfc-editor.org/info/rfc6840、<https://www.rfc-editor.org/info/rfc6840>。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891] Damas、J.、Graff、M.、およびP.Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<https：//www.rfc-editor.org/info/rfc6891>。
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC6895]イーストレイク3RD、D.、「ドメインネームシステム（DNS）IANA考慮事項」、BCP 42、RFC 6895、DOI 10.17487 / RFC6895、2013年4月、<https：//www.rfc-editor.org/info/rfc6895>。
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>.
[RFC7766]ディッキンソン、J.、Dickinson、S.、Bellis、R.、Mankin、A.、D.ウェース、「TCPの輸送 - 実施要件」、RFC 7766、DOI 10.17487 / RFC7766、2016年3月、<https://www.rfc-editor.org/info/rfc7766>。
[IANA-DNS] IANA, "Domain Name System (DNS) Parameters", <https://www.iana.org/assignments/dns-parameters/>.
[IANA-DNS] IANA、「ドメインネームシステム（DNS）パラメータ」、<https：//www.iana.org/assignments/dns-parameters/>。
[ISC] "Internet Systems Consortuim", <https://www.isc.org/>.
[ISC]「インターネットシステムコンソーシアム」、<https://www.isc.org/>。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, DOI 10.17487/RFC2671, August 1999, <https://www.rfc-editor.org/info/rfc2671>.
[RFC2671] Vixie、P.、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、DOI 10.17487 / RFC2671、1999年8月、<https://www.rfc-editor.org/info/rfc2671>。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC3597] Gustafsson、A。、「未知のDNSリソースレコード（RR）タイプの取り扱い」、RFC 3597、DOI 10.17487 / RFC3597、2003年9月、<https：//www.rfc-editor.org/info/rfc3597>。
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", RFC 5001, DOI 10.17487/RFC5001, August 2007, <https://www.rfc-editor.org/info/rfc5001>.
[RFC5001] Austein、R.、 "DNSネームサーバー識別子（NSID）オプション"、RFC 5001、DOI 10.17487 / RFC5001、2007年8月、<https://www.rfc-editor.org/info/rfc5001>。
[RFC7314] Andrews, M., "Extension Mechanisms for DNS (EDNS) EXPIRE Option", RFC 7314, DOI 10.17487/RFC7314, July 2014, <https://www.rfc-editor.org/info/rfc7314>.
[RFC7314] Andrews、M.、「DNS（EDNS）の拡張メカニズム」、RFC 7314、DOI 10.17487 / RFC7314、2014年7月、<https://www.rfc-editor.org/info/rfc7314>。
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <https://www.rfc-editor.org/info/rfc7871>.
[RFC7871] Contavalli、C、Van Der Gaast、W.、Lawrence、D.、およびW.Kumari、「DNSクエリのクライアントサブネット」、RFC 7871、DOI 10.17487 / RFC7871、2016年5月、<https：// www.rfc-editor.org / info / rfc7871>。
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, <https://www.rfc-editor.org/info/rfc7873>.
[RFC7873]イーストレイク3RD、D.およびM. Andrews、「ドメインネームシステム（DNS）クッキー」、RFC 7873、DOI 10.17487 / RFC7873、2016年5月、<https：//www.rfc-editor.org/info/rfc7873>。
Acknowledgements
謝辞
The contributions of Matthew Pounsett and Tim Wicinski are gratefully acknowledged.
Matthew PounsettとTim Wicinskiの貢献は感謝しています。
Authors' Addresses
著者の住所
M. Andrews Internet Systems Consortium PO Box 360 Newmarket, NH 03857 United States of America
M. AndrewsインターネットシステムコンソーシアムPO BOX 360 Newmarket、NH 03857アメリカ合衆国
Email: marka@isc.org
Ray Bellis Internet Systems Consortium PO Box 360 Newmarket, NH 03857 United States of America
Ray BellisインターネットシステムコンソーシアムPO BOX 360 Newmarket、NH 03857アメリカ
Email: ray@isc.org