[要約] RFC 8482は、QTYPE=ANYを持つDNSクエリに対して最小サイズの応答を提供するためのガイドラインです。その目的は、ネットワークのトラフィックを削減し、DNSサーバーの負荷を軽減することです。
Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 8482 Afilias
Updates: 1034, 1035 O. Gudmundsson
Category: Standards Track M. Majkowski
ISSN: 2070-1721 Cloudflare Inc.
E. Hunt
ISC
January 2019
Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
QTYPE = ANYを持つDNSクエリへの最小サイズの応答の提供
Abstract
概要
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.
ドメインネームシステム（DNS）は、クエリタイプ（QTYPE） "ANY"を指定します。権限のあるDNSサーバーのオペレーターは、セキュリティ、パフォーマンス、またはその他の理由により、ローカルポリシーの理由により、このようなクエリに応答しないことを選択する場合があります。
The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.
DNS仕様には、この状況におけるDNSサーバーまたはクライアントの動作に関する特定のガイダンスは含まれていません。このドキュメントは、そのようなガイダンスを提供することを目的としています。
This document updates RFCs 1034 and 1035.
このドキュメントは、RFC 1034および1035を更新します。
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 https://www.rfc-editor.org/info/rfc8482.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8482で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Motivations for Use of ANY Queries ..............................3
3. General Approach ................................................4
4. Behavior of DNS Responders ......................................5
4.1. Answer with a Subset of Available RRsets ...................5
4.2. Answer with a Synthesized HINFO RRset ......................5
4.3. Answer with Best Guess as to Intention .....................6
4.4. Transport Considerations ...................................6
5. Behavior of DNS Initiators ......................................7
6. HINFO Considerations ............................................7
7. Updates to RFCs 1034 and 1035 ...................................7
8. Implementation Experience .......................................8
9. Security Considerations .........................................8
10. IANA Considerations ............................................9
11. References .....................................................9
11.1. Normative References ......................................9
11.2. Informative References ....................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.
ドメインネームシステム（DNS）は、クエリタイプ（QTYPE） "ANY"を指定します。権限のあるDNSサーバーのオペレーターは、セキュリティ、パフォーマンス、またはその他の理由により、ローカルポリシーの理由により、このようなクエリに応答しないことを選択する場合があります。
The DNS specification [RFC1034] [RFC1035] does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.
DNS仕様[RFC1034] [RFC1035]には、この状況でのDNSサーバーまたはクライアントの動作に関する特定のガイダンスは含まれていません。このドキュメントは、そのようなガイダンスを提供することを目的としています。
This document uses terminology specific to the Domain Name System (DNS), descriptions of which can be found in [RFC8499].
このドキュメントでは、ドメインネームシステム（DNS）に固有の用語を使用しています。その説明は、[RFC8499]にあります。
[RFC1035] defined type 255 to be "*". However, DNS implementations commonly use the keyword "ANY" to refer to that type code; this document follows that common usage.
[RFC1035]タイプ255を "*"と定義しました。ただし、DNSの実装では通常、キーワード「ANY」を使用してそのタイプコードを参照します。このドキュメントは、その一般的な使用法に従っています。
In this document, "ANY query" refers to a DNS meta-query with QTYPE=ANY. An "ANY response" is a response to such a query.
このドキュメントでは、「ANYクエリ」はQTYPE = ANYのDNSメタクエリを指します。 「すべての応答」は、そのようなクエリに対する応答です。
In this document, "conventional ANY response" means an ANY response that is constructed in accordance with the algorithm documented in Section 4.3.2 of [RFC1034] and specifically without implementing any of the mechanisms described in this document.
このドキュメントでは、「従来のANYレスポンス」とは、[RFC1034]のセクション4.3.2に記載されているアルゴリズムに従って構築されたANYレスポンスを意味し、特にこのドキュメントで説明されているメカニズムを実装していません。
In an exchange of DNS messages between two hosts, this document refers to the host sending a DNS request as the "initiator" and the host sending a DNS response as the "responder".
2つのホスト間でのDNSメッセージの交換では、このドキュメントでは、DNS要求を送信するホストを「イニシエーター」と呼び、DNS応答を送信するホストを「レスポンダー」と呼びます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
ANY queries are legitimately used for debugging and checking the state of a DNS server for a particular name.
ANYクエリは、特定の名前のDNSサーバーの状態をデバッグおよびチェックするために正当に使用されます。
ANY queries are sometimes used as an attempt to reduce the number of queries needed to get information, e.g., to obtain MX, A, and AAAA resource record sets (RRsets) for a mail domain in a single query. However, there is no documented guidance available for this use case, and some implementations have been observed not to function as their developers expected. If implementers assume that an ANY query will ultimately be received by an authoritative server and will fetch all existing RRsets, they should include a fallback mechanism to use when that does not happen.
ANYクエリは、単一のクエリでメールドメインのMX、A、AAAAリソースレコードセット（RRset）を取得するなど、情報を取得するために必要なクエリの数を減らす試みとして使用されることがあります。ただし、この使用例で利用できる文書化されたガイダンスはなく、一部の実装では、開発者の期待どおりに機能しないことが確認されています。実装者がANYクエリが最終的に権限のあるサーバーによって受信され、すべての既存のRRsetをフェッチすると想定する場合、実装者はそれが起こらないときに使用するフォールバックメカニズムを含める必要があります。
ANY queries are frequently used to exploit the amplification potential of DNS servers and resolvers using spoofed source addresses and UDP transport (see [RFC5358]). Having the ability to return small responses to such queries makes DNS servers less attractive amplifiers.
ANYクエリは、スプーフィングされたソースアドレスとUDPトランスポートを使用してDNSサーバーとリゾルバーの増幅の可能性を悪用するために頻繁に使用されます（[RFC5358]を参照）。このようなクエリに対して小さな応答を返す機能があると、DNSサーバーのアンプの魅力が低下します。
ANY queries are sometimes used to help mine authoritative-only DNS servers for zone data, since they are expected to return all RRsets for a particular query name. If DNS operators prefer to reduce the potential for information leaks, they might choose not to send large ANY responses.
ANYクエリは、特定のクエリ名のすべてのRRsetを返すことが期待されているため、ゾーンデータの権威のみのDNSサーバーのマイニングに役立つ場合があります。 DNSオペレーターが情報漏えいの可能性を減らすことを好む場合、大きなANY応答を送信しないことを選択する場合があります。
Some authoritative-only DNS server implementations require additional processing in order to send a conventional ANY response; avoiding that processing expense might be desirable.
一部の権限のあるDNSサーバーの実装では、従来のANY応答を送信するために追加の処理が必要です。その処理費用を回避することが望ましい場合があります。
This proposal provides a mechanism for an authoritative DNS server to signal that conventional ANY queries are not supported for a particular QNAME. It does so in a way that is both compatible with and triggers desirable behavior by unmodified clients (e.g., DNS resolvers).
この提案は、権威あるDNSサーバーが、特定のQNAMEに対して従来のANYクエリがサポートされていないことを通知するメカニズムを提供します。これは、変更されていないクライアント（DNSリゾルバーなど）と互換性があり、望ましい動作をトリガーする方法で行われます。
Alternative proposals for dealing with ANY queries have been discussed. One approach proposes using a new RCODE to signal that an authoritative server did not answer ANY queries in the standard way. This approach was found to have an undesirable effect on both resolvers and authoritative-only servers; resolvers receiving an unknown RCODE would resend the same query to all available authoritative servers rather than suppress future ANY queries for the same QNAME.
ANYクエリを処理するための代替案が議論されました。 1つのアプローチでは、新しいRCODEを使用して、権限のあるサーバーが標準的な方法でクエリに応答しなかったことを通知します。このアプローチは、リゾルバーと信頼できるサーバーの両方に望ましくない影響を与えることがわかっています。不明なRCODEを受信したリゾルバーは、同じQNAMEに対する今後のANYクエリを抑制するのではなく、使用可能なすべての権限のあるサーバーに同じクエリを再送信します。
The proposal described in this document avoids that outcome by returning a non-empty RRset in the ANY response, which provides resolvers with something to cache and effectively suppresses repeat queries to the same or different authoritative DNS servers.
このドキュメントで説明する提案では、ANY応答で空ではないRRsetを返すことでその結果を回避しています。これにより、リゾルバにキャッシュするものを提供し、同じまたは異なる信頼できるDNSサーバーへの繰り返しクエリを効果的に抑制します。
Below are the three different modes of behavior by DNS responders when processing queries with QNAMEs that exist, QCLASS=IN, and QTYPE=ANY. Operators and implementers are free to choose whichever mechanism best suits their environment.
以下は、存在するQNAME、QCLASS = IN、およびQTYPE = ANYでクエリを処理するときのDNSレスポンダによる3つの異なる動作モードです。オペレーターと実装者は、自分の環境に最適なメカニズムを自由に選択できます。
1. A DNS responder can choose to select one or a larger subset of the available RRsets at the QNAME.
1. DNSレスポンダは、QNAMEで使用可能なRRsetの1つまたはより大きなサブセットを選択することを選択できます。
2. A DNS responder can return a synthesized HINFO resource record. See Section 6 for discussion of the use of HINFO.
2. DNSレスポンダは、合成されたHINFOリソースレコードを返すことができます。 HINFOの使用については、セクション6を参照してください。
3. A resolver can try to give out the most likely records the requester wants. This is not always possible, and the result might well be a large response.
3. リゾルバーは、リクエスターが必要とする可能性が最も高いレコードを提供しようとすることができます。これは常に可能であるとは限りません。その結果、応答が大きくなる可能性があります。
Except as described below in this section, the DNS responder MUST follow the standard algorithms when constructing a response.
このセクションで以下に説明する場合を除いて、DNSレスポンダは、応答を構築するときに標準アルゴリズムに従う必要があります。
A DNS responder that receives an ANY query MAY decline to provide a conventional ANY response or MAY instead send a response with a single RRset (or a larger subset of available RRsets) in the answer section.
ANYクエリを受信したDNSレスポンダは、従来のANY応答を提供することを拒否するか、代わりに、応答セクションで単一のRRset（または使用可能なRRsetsのより大きなサブセット）で応答を送信する場合があります。
The RRsets returned in the answer section of the response MAY consist of a single RRset owned by the name specified in the QNAME. Where multiple RRsets exist, the responder SHOULD choose a small subset of those available to reduce the amplification potential of the response.
応答の応答セクションで返されるRRsetは、QNAMEで指定された名前が所有する単一のRRsetで構成されている場合があります。複数のRRsetが存在する場合、レスポンダは、利用可能なものの小さなサブセットを選択して、応答の増幅の可能性を減らす必要があります。
If the zone is signed, appropriate RRSIG records MUST be included in the answer.
ゾーンが署名されている場合、適切なRRSIGレコードを回答に含める必要があります。
Note that this mechanism does not provide any signaling to indicate to a client that an incomplete subset of the available RRsets has been returned.
このメカニズムは、利用可能なRRsetの不完全なサブセットが返されたことをクライアントに示すシグナリングを提供しないことに注意してください。
If there is no CNAME present at the owner name matching the QNAME, the resource record returned in the response MAY instead be synthesized. In this case, a single HINFO resource record SHOULD be returned. The CPU field of the HINFO RDATA SHOULD be set to "RFC8482". The OS field of the HINFO RDATA SHOULD be set to the null string to minimize the size of the response.
QNAMEと一致する所有者名にCNAMEが存在しない場合、応答で返されたリソースレコードが代わりに合成される場合があります。この場合、単一のHINFOリソースレコードが返される必要があります（SHOULD）。 HINFO RDATAのCPUフィールドは "RFC8482"に設定する必要があります（SHOULD）。応答のサイズを最小限に抑えるために、HINFO RDATAのOSフィールドをNULL文字列に設定する必要があります（SHOULD）。
The TTL encoded for the synthesized HINFO resource record SHOULD be chosen by the operator of the DNS responder to be large enough to suppress frequent subsequent ANY queries from the same initiator with the same QNAME, understanding that a TTL that is too long might make policy changes relating to ANY queries difficult to change in the future. The specific value used SHOULD be configurable by the operator of the nameserver according to local policy, based on the familiar considerations involved in choosing a TTL value for any resource record in any zone.
合成されたHINFOリソースレコード用にエンコードされたTTLは、DNSレスポンダーのオペレーターが、同じQNAMEを持つ同じイニシエーターからの頻繁な後続のANYクエリを抑制するのに十分な大きさに選択する必要があります（長すぎるTTLはポリシーを変更する可能性があることを理解しています）将来変更が困難なクエリに関するもの。使用される特定の値は、任意のゾーンの任意のリソースレコードのTTL値の選択に関連する一般的な考慮事項に基づいて、ローカルポリシーに従ってネームサーバーのオペレーターによって構成可能である必要があります（SHOULD）。
If the DNS query includes DO=1 and the QNAME corresponds to a zone that is known by the responder to be signed, a valid RRSIG for the RRsets in the answer (or authority if answer is empty) section MUST be returned. In the case of DO=0, the RRSIG SHOULD be omitted.
DNSクエリにDO = 1が含まれ、QNAMEがレスポンダーによって署名されていることがわかっているゾーンに対応する場合、回答（または回答が空の場合は機関）セクションのRRsetの有効なRRSIGを返す必要があります。 DO = 0の場合、RRSIGは省略されるべきです（SHOULD）。
A system that receives an HINFO response SHOULD NOT infer that the response was generated according to this specification and apply any special processing of the response because, in general, it is not possible to tell with certainty whether the HINFO RRset received was synthesized. In particular, systems SHOULD NOT rely upon the HINFO RDATA described in this section to distinguish between synthesized and non-synthesized HINFO RRsets.
HINFO応答を受信するシステムは、一般に、受信したHINFO RRsetが合成されたかどうかを確実に伝えることができないため、応答がこの仕様に従って生成されたことを推測して、応答の特別な処理を適用する必要があります（SHOULD NOT）。特に、システムは、このセクションで説明するHINFO RDATAに依存して、合成されたものと合成されていないHINFO RRsetを区別するべきではありません（SHOULD NOT）。
In some cases, it is possible to guess what the initiator wants in the answer (but not always). Some implementations have implemented the spirit of this document by returning all RRsets of RRTYPE CNAME, MX, A, and AAAA that are present at the owner name while suppressing others. This heuristic seems to work well in practice; it satisfies the needs of some applications whilst suppressing other RRsets such as TXT and DNSKEY that can often contribute to large responses. Whilst some applications may be satisfied by this behavior, the resulting responses in the general case are larger than in the approaches described in Sections 4.1 and 4.2.
場合によっては、開始者が回答に何を求めているかを推測することができます（ただし、常にではありません）。一部の実装では、所有者名に存在するRRTYPE CNAME、MX、A、およびAAAAのすべてのRRsetを返し、他のRRsetを返して、このドキュメントの精神を実装しています。このヒューリスティックは実際にはうまくいくようです。一部のアプリケーションのニーズを満たしつつ、TXTやDNSKEYなどの他のRRsetを抑制して、多くの場合、大きな応答に寄与する可能性があります。一部のアプリケーションはこの動作で満たされる場合がありますが、一般的な場合の結果の応答は、セクション4.1および4.2で説明されているアプローチよりも大きくなります。
As before, if the zone is signed and the DO bit is set on the corresponding query, an RRSIG RRset MUST be included in the response.
以前と同様に、ゾーンが署名され、対応するクエリでDOビットが設定されている場合、RRSIG RRsetが応答に含まれている必要があります。
A DNS responder MAY behave differently when processing ANY queries received over different transports, e.g., by providing a conventional ANY response over TCP whilst using one of the other mechanisms specified in this document in the case where a query was received using UDP.
たとえば、UDPを使用してクエリが受信された場合に、このドキュメントで指定されている他のメカニズムのいずれかを使用しながら、TCPを介して従来のANY応答を提供することにより、DNSレスポンダは異なるトランスポートを介して受信されたANYクエリを処理するときに異なる動作をする場合があります。
Implementers MAY provide configuration options to allow operators to specify different behavior over different transports.
実装者は、オペレーターがさまざまなトランスポート上でさまざまな動作を指定できるようにする構成オプションを提供する場合があります。
A DNS initiator that sends a query with QTYPE=ANY and receives a response containing an HINFO resource record or a single RRset, as described in Section 4, MAY cache the response in the normal way. Such cached resource records SHOULD be retained in the cache following normal caching semantics, as with any other response received from a DNS responder.
セクション4で説明されているように、QTYPE = ANYでクエリを送信し、HINFOリソースレコードまたは単一のRRsetを含む応答を受信するDNSイニシエーターは、通常の方法で応答をキャッシュできます（MAY）。このようなキャッシュされたリソースレコードは、DNSレスポンダから受信した他の応答と同様に、通常のキャッシュセマンティクスに従ってキャッシュに保持する必要があります（SHOULD）。
A DNS initiator MAY suppress queries with QTYPE=ANY in the event that the local cache contains a matching HINFO resource record with the CPU field of the HINFO RDATA, as described in Section 4. A DNS initiator MAY instead respond to such queries with the contents of the local cache in the usual way.
セクション4で説明されているように、ローカルキャッシュにHINFO RDATAのCPUフィールドと一致するHINFOリソースレコードが含まれている場合、DNSイニシエーターはQTYPE = ANYのクエリを抑制してもよい（MAY）。通常の方法でローカルキャッシュの。
It is possible that the synthesized HINFO RRset in an ANY response, once cached by the initiator, might suppress subsequent queries from the same initiator with QTYPE=HINFO. Thus, the use of HINFO in this proposal would effectively mask the HINFO RRset present in the zone.
ANY応答で合成されたHINFO RRsetは、イニシエーターによってキャッシュされると、QTYPE = HINFOを使用して同じイニシエーターからの後続の照会を抑制する可能性があります。したがって、この提案でHINFOを使用すると、ゾーンに存在するHINFO RRsetが効果的にマスクされます。
Operators of authoritative servers who serve zones that rely upon conventional use of the HINFO RRTYPE SHOULD sensibly choose the "single RRset" method described in this document or select another type.
HINFO RRTYPEの従来の使用に依存するゾーンにサービスを提供する信頼できるサーバーのオペレーターは、このドキュメントで説明されている「単一のRRset」メソッドを慎重に選択するか、別のタイプを選択する必要があります。
The HINFO RRTYPE is believed to be rarely used in the DNS at the time of writing, based on observations made in passive DNS and at recursive and authoritative DNS servers.
HINFO RRTYPEは、パッシブDNSおよび再帰的で信頼できるDNSサーバーで行われた観察に基づいて、執筆時点でDNSで使用されることはまれであると考えられています。
This document extends the specification for processing ANY queries described in Section 4.3.2 of [RFC1034].
このドキュメントは、[RFC1034]のセクション4.3.2で説明されているANYクエリを処理するための仕様を拡張します。
It is important to note that returning a subset of available RRsets when processing an ANY query is legitimate and consistent with [RFC1035]; it can be argued that ANY does not always mean ALL, as used in Section 3.2.3 of [RFC1035]. The main difference here is that the TC bit SHOULD NOT be set in the response, thus indicating that this is not a complete answer.
ANYクエリを処理するときに利用可能なRRsetのサブセットを返すことは正当であり、[RFC1035]と一貫していることに注意することが重要です。 [RFC1035]のセクション3.2.3で使用されているように、ANYが常にALLを意味するわけではないと主張できます。ここでの主な違いは、応答でTCビットを設定する必要がある（SHOULD NOT）ことで、これは完全な答えではないことを示しています。
This document describes optional behavior for both DNS initiators and responders; implementation of the guidance provided by this document is OPTIONAL.
このドキュメントでは、DNSイニシエーターとレスポンダーの両方のオプションの動作について説明します。このドキュメントで提供されるガイダンスの実装はオプションです。
RRSIG queries (i.e., queries with QTYPE=RRSIG) are similar to ANY queries in the sense that they have the potential to generate large responses as well as extra work for the responders that process them, e.g., in the case where signatures are generated on the fly. RRSIG RRsets are not usually obtained using such explicit queries but are rather included in the responses for other RRsets that the RRSIGs cover. This document does not specify appropriate behavior for RRSIG queries; however, future such advice might well benefit from consistency with and experience with the approaches for ANY queries described here.
RRSIGクエリ（つまり、QTYPE = RRSIGのクエリ）は、大きな応答を生成する可能性があるだけでなく、それらを処理するレスポンダのための追加の作業（たとえば、署名がはえ。 RRSIG RRsetは通常、このような明示的なクエリを使用して取得されるのではなく、RRSIGがカバーする他のRRsetの応答に含まれます。このドキュメントでは、RRSIGクエリの適切な動作を指定していません。ただし、将来のそのようなアドバイスは、ここで説明されているANYクエリのアプローチとの一貫性と経験から恩恵を受ける可能性があります。
In October 2015, the Cloudflare authoritative nameserver implementation implemented the HINFO response. A few minor problems were reported and have since been resolved.
2015年10月、Cloudflareの権威あるネームサーバーの実装により、HINFO応答が実装されました。いくつかの小さな問題が報告され、それ以降解決されました。
An implementation of the subset-mode response to ANY queries was implemented in NSD 4.1 in 2016.
ANYクエリに対するサブセットモード応答の実装は、2016年にNSD 4.1で実装されました。
An implementation of a single RRset response to an ANY query was made for BIND9 by Tony Finch, and that functionality was subsequently made available in production releases starting in BIND 9.11.
ANYクエリに対する単一のRRset応答の実装がBIND9に対してトニーフィンチによって行われ、その機能はその後、BIND 9.11以降の製品リリースで利用可能になりました。
Queries with QTYPE=ANY are frequently observed as part of reflection attacks, since a relatively small query can be used to elicit a large response. This is a desirable characteristic if the goal is to maximize the amplification potential of a DNS server as part of a volumetric attack. The ability of a DNS operator to suppress such responses on a particular server makes that server a less useful amplifier.
比較的小さなクエリを使用して大きな応答を引き出すことができるため、QTYPE = ANYのクエリはリフレクション攻撃の一部として頻繁に観察されます。これは、ボリューム攻撃の一部としてDNSサーバーの増幅の可能性を最大化することを目的とする場合に望ましい特性です。 DNSオペレーターが特定のサーバーでそのような応答を抑制する機能があると、そのサーバーはあまり役に立たない増幅器になります。
The optional behavior described in this document to reduce the size of responses to queries with QTYPE=ANY is compatible with the use of DNSSEC by both initiator and responder.
このドキュメントで説明されている、QTYPE = ANYのクエリへの応答のサイズを削減するオプションの動作は、イニシエーターとレスポンダーの両方によるDNSSECの使用と互換性があります。
IANA has updated the following entry in the "Resource Record (RR) TYPEs" registry [RR_TYPES]:
IANAは、「Resource Record（RR）TYPEs」レジストリ[RR_TYPES]の次のエントリを更新しました。
+------+-------+-------------------------------+--------------------+
| TYPE | Value | Meaning | Reference |
+------+-------+-------------------------------+--------------------+
| * | 255 | A request for some or all | [RFC1035][RFC6895] |
| | | records the server has | [RFC8482] |
| | | available | |
+------+-------+-------------------------------+--------------------+
[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>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <https://www.rfc-editor.org/info/rfc5358>.
[RFC5358] Damas、J。およびF. Neves、「Preventing Use of Recursive Nameservers in Reflector Attacks」、BCP 140、RFC 5358、DOI 10.17487 / RFC5358、2008年10月、<https://www.rfc-editor.org/ info / rfc5358>。
[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] Eastlake 3rd、D。、「ドメインネームシステム（DNS）IANAに関する考慮事項」、BCP 42、RFC 6895、DOI 10.17487 / RFC6895、2013年4月、<https://www.rfc-editor.org/info/rfc6895 >。
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499] Hoffman、P.、Sullivan、A。、およびK. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https://www.rfc-editor.org/ info / rfc8499>。
[RR_TYPES] IANA, "Domain Name System (DNS) Parameters", <https://www.iana.org/assignments/dns-parameters>.
[RR_TYPES] IANA、「ドメインネームシステム（DNS）パラメータ」、<https://www.iana.org/assignments/dns-parameters>。
Acknowledgements
謝辞
David Lawrence provided valuable observations and concrete suggestions. Jeremy Laidman helped make the document better. Tony Finch realized that this document was valuable and implemented it while under attack. Richard Gibson identified areas where more detail and accuracy were useful. A large number of other people also provided comments and suggestions; we thank them all for the feedback.
デビッド・ローレンスは貴重な観察と具体的な提案を提供しました。ジェレミー・レイドマンは、ドキュメントの改善に貢献しました。トニーフィンチは、このドキュメントが貴重であることを認識し、攻撃を受けている間に実装しました。リチャードギブソンは、より詳細で正確な方が役立つ領域を特定しました。他の多くの人々もコメントや提案を提供しました。フィードバックに感謝します。
Authors' Addresses
著者のアドレス
Joe Abley Afilias 300-184 York Street London, ON N6A 1B5 Canada
Joe Abley Afilias 300-184 York Street London、ON N6A 1B5 Canada
Phone: +1 519 670 9327
Email: jabley@afilias.info
Olafur Gudmundsson Cloudflare Inc.
Olafur Gudmundsson Cloudflare Inc.
Email: olafur+ietf@cloudflare.com
Marek Majkowski Cloudflare Inc.
マレクマイコウスキークラウドフレア
Email: marek@cloudflare.com
Evan Hunt ISC 950 Charter St Redwood City, CA 94063 United States of America
エヴァンハントISC 950チャーターセントレッドウッドシティ、カリフォルニア州94063アメリカ合衆国
Email: each@isc.org