[要約] RFC 9210 は、DNSメッセージをTCP経由で送信することをBest Current Practiceとして要求し、RFC 7766の実装要件と一致させる。この要件は、DNS通信のTCP利用に関する運用上の問題や、Best Current Practiceの遵守がない場合に生じる潜在的な運用上の問題を考慮している。
Internet Engineering Task Force (IETF) J. Kristoff
Request for Comments: 9210 Dataplane.org
BCP: 235 D. Wessels
Updates: 1123, 1536 Verisign
Category: Best Current Practice March 2022
ISSN: 2070-1721
DNS Transport over TCP - Operational Requirements
TCP - 運用要件を介したDNS輸送
Abstract
概要
This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld.
この文書はRFCS 1123と1536を更新します。この文書では、DNSメッセージを最良の現在の練習としてインターネット上でTCPを介して伝送することを許可する操作実習が必要です。この操作上の要件は、RFC 7766の実装要件に合わせて整列しています.TCPの使用には、暗号化されていないTCPと暗号化されたTLSセッションを介してDNSの両方が含まれています。この文書はまた、この形式の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/rfc9210.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9210で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. History of DNS over TCP
2.1. Uneven Transport Usage and Preference
2.2. Waiting for Large Messages and Reliability
2.3. EDNS(0)
2.4. Fragmentation and Truncation
2.5. "Only Zone Transfers Use TCP"
2.6. Reuse, Pipelining, and Out-of-Order Processing
3. DNS-over-TCP Requirements
4. Network and System Considerations
4.1. Connection Establishment and Admission
4.2. Connection Management
4.3. Connection Termination
4.4. DNS over TLS
4.5. Defaults and Recommended Limits
5. DNS-over-TCP Filtering Risks
5.1. Truncation, Retries, and Timeouts
5.2. DNS Root Zone KSK Rollover
6. Logging and Monitoring
7. IANA Considerations
8. Security Considerations
9. Privacy Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. RFCs Related to DNS Transport over TCP
A.1. RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
A.2. RFC 1536 - Common DNS Implementation Errors and Suggested
Fixes
A.3. RFC 1995 - Incremental Zone Transfer in DNS
A.4. RFC 1996 - A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)
A.5. RFC 2181 - Clarifications to the DNS Specification
A.6. RFC 2694 - DNS extensions to Network Address Translators
(DNS_ALG)
A.7. RFC 3225 - Indicating Resolver Support of DNSSEC
A.8. RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver message
size requirements
A.9. RFC 4472 - Operational Considerations and Issues with IPv6
DNS
A.10. RFC 5452 - Measures for Making DNS More Resilient against
Forged Answers
A.11. RFC 5507 - Design Choices When Expanding the DNS
A.12. RFC 5625 - DNS Proxy Implementation Guidelines
A.13. RFC 5936 - DNS Zone Transfer Protocol (AXFR)
A.14. RFC 7534 - AS112 Nameserver Operations
A.15. RFC 6762 - Multicast DNS
A.16. RFC 6891 - Extension Mechanisms for DNS (EDNS(0))
A.17. IAB RFC 6950 - Architectural Considerations on Application
Features in the DNS
A.18. RFC 7477 - Child-to-Parent Synchronization in DNS
A.19. RFC 7720 - DNS Root Name Service Protocol and Deployment
Requirements
A.20. RFC 7766 - DNS Transport over TCP - Implementation
Requirements
A.21. RFC 7828 - The edns-tcp-keepalive EDNS(0) Option
A.22. RFC 7858 - Specification for DNS over Transport Layer
Security (TLS)
A.23. RFC 7873 - Domain Name System (DNS) Cookies
A.24. RFC 7901 - CHAIN Query Requests in DNS
A.25. RFC 8027 - DNSSEC Roadblock Avoidance
A.26. RFC 8094 - DNS over Datagram Transport Layer Security
(DTLS)
A.27. RFC 8162 - Using Secure DNS to Associate Certificates with
Domain Names for S/MIME
A.28. RFC 8324 - DNS Privacy, Authorization, Special Uses,
Encoding, Characters, Matching, and Root Structure: Time for
Another Look?
A.29. RFC 8467 - Padding Policies for Extension Mechanisms for
DNS (EDNS(0))
A.30. RFC 8482 - Providing Minimal-Sized Responses to DNS Queries
That Have QTYPE=ANY
A.31. RFC 8483 - Yeti DNS Testbed
A.32. RFC 8484 - DNS Queries over HTTPS (DoH)
A.33. RFC 8490 - DNS Stateful Operations
A.34. RFC 8501 - Reverse DNS in IPv6 for Internet Service
Providers
A.35. RFC 8806 - Running a Root Server Local to a Resolver
A.36. RFC 8906 - A Common Operational Problem in DNS Servers:
Failure to Communicate
A.37. RFC 8932 - Recommendations for DNS Privacy Service
Operators
A.38. RFC 8945 - Secret Key Transaction Authentication for DNS
(TSIG)
Acknowledgments
Authors' Addresses
DNS messages are delivered using UDP or TCP communications. While most DNS transactions are carried over UDP, some operators have been led to believe that any DNS-over-TCP traffic is unwanted or unnecessary for general DNS operation. When DNS over TCP has been restricted, a variety of communication failures and debugging challenges often arise. As DNS and new naming system features have evolved, TCP as a transport has become increasingly important for the correct and safe operation of an Internet DNS. Reflecting modern usage, the DNS standards declare that support for TCP is a required part of the DNS implementation specifications [RFC7766]. This document is the equivalent of formal requirements for the operational community, encouraging system administrators, network engineers, and security staff to ensure DNS-over-TCP communications support is on par with DNS-over-UDP communications. It updates [RFC1123], Section 6.1.3.2 to clarify that all DNS resolvers and recursive servers MUST support and service both TCP and UDP queries and also updates [RFC1536] to remove the misconception that TCP is only useful for zone transfers.
DNSメッセージは、UDPまたはTCP通信を使用して配信されます。ほとんどのDNSトランザクションはUDPを介して伝送されますが、何人かの演算子は、DNS-Over-TCPトラフィックが望ましくないか、一般的なDNS操作に不要であると信じることが主導されました。 TCP上のDNSが制限されている場合、さまざまな通信障害とデバッグの課題が発生します。 DNSおよび新しい命名システムの機能が進化しているので、トランスポートとしてのTCPはインターネットDNSの正しい動作と安全な操作にとってますます重要になっています。現代の使用状況を反映して、DNS規格はTCPのサポートがDNS実装仕様の必須部分です[RFC7766]。この文書は、運用コミュニティの正式な要件と同等の要件と同等の要件で、DNS-Over-TCP通信のサポートがDNS-Over-UDP通信でPAR上にあることを確認するために、システム管理者、ネットワークエンジニア、およびセキュリティスタッフを奨励しています。 [RFC1123]、6.1.3.2項を更新するために、すべてのDNSリゾルバと再帰サーバーがTCPクエリとUDPクエリとUDPクエリの両方をサポートしてサービスを提供し、TCPがゾーン転送に役立つという誤ったコンセプトを削除する必要があることを明確にします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The curious state of disagreement between operational best practices and guidance for DNS transport protocols derives from conflicting messages operators have received from other operators, implementors, and even the IETF. Sometimes these mixed signals have been explicit; on other occasions, conflicting messages have been implicit. This section presents an interpretation of the storied and conflicting history that led to this document. This section is included for informational purposes only.
運用上のベストプラクティスとDNSトランスポートプロトコルのためのガイダンスの間の不思議な意見の相違は、競合するメッセージ演算子から他の事業者、実装者、さらにはIETFから受信しています。時々これらの混合信号は明示的であった。他の機会には、矛盾するメッセージが暗黙的になっています。このセクションでは、この文書につながったストーリーと競合する履歴の解釈を示します。このセクションは情報提供のみに含まれています。
In the original suite of DNS specifications, [RFC1034] and [RFC1035] clearly specify that DNS messages could be carried in either UDP or TCP, but they also state that there is a preference for UDP as the best transport for queries in the general case. As stated in [RFC1035]:
DNS仕様の元のスイートでは、[RFC1034]と[RFC1035]はDNSメッセージをUDPまたはTCPで実行できることを明確に指定しますが、一般的な場合のクエリの最良のトランスポートとしてUDPが優先されるように指定します。。[RFC1035]に記載されているように：
| While virtual circuits can be used for any DNS activity, datagrams
| are preferred for queries due to their lower overhead and better
| performance.
Another early, important, and influential document, [RFC1123], marks the preference for a transport protocol more explicitly:
もう1つの早い、重要で、影響力のある文書、[RFC1123]は、トランスポートプロトコルの好みをより明確にマークします。
| DNS resolvers and recursive servers MUST support UDP, and SHOULD | support TCP, for sending (non-zone-transfer) queries.
| ..DNSリゾルバと再帰サーバーはUDPをサポートしている必要があります。送信（非ゾーン転送）クエリを送信するためのTCPをサポートします。
and it further stipulates that:
そしてそれはさらにそれを規定しています：
| A name server MAY limit the resources it devotes to TCP queries,
| but it SHOULD NOT refuse to service a TCP query just because it
| would have succeeded with UDP.
Culminating in [RFC1536], DNS over TCP came to be associated primarily with the zone transfer mechanism, while most DNS queries and responses were seen as the dominion of UDP.
[RFC1536]では、TCP上のDNSを超えるDNSは主にゾーン転送メカニズムに関連しているようになりましたが、ほとんどのDNSクエリと応答はUDPの支配として見られました。
In the original specifications, the maximum DNS-over-UDP message size was enshrined at 512 bytes. However, even while [RFC1123] prefers UDP for non-zone transfer queries, it foresaw that DNS over TCP would become more popular in the future to overcome this limitation:
元の仕様では、最大DNS-over-UDPメッセージサイズが512バイトで網化されました。ただし、[RFC1123]が非ゾーン転送クエリのUDPを好む間も、TCPを介したDNSが将来的に普及しているのはこの制限を克服するようになるでしょう。
| [...] it is also clear that some new DNS record types defined in
| the future will contain information exceeding the 512 byte limit
| that applies to UDP, and hence will require TCP.
At least two new, widely anticipated developments were set to elevate the need for DNS-over-TCP transactions. The first was dynamic updates defined in [RFC2136], and the second was the set of extensions collectively known as "DNSSEC", whose operational considerations were originally given in [RFC2541] (note that [RFC2541] has been obsoleted by [RFC6781]). The former suggests that
少なくとも2つの新しく、広く予想される開発がDNS-Over-TCPトランザクションの必要性を高めるように設定されています。最初のものは[RFC2136]で定義された動的更新であり、2番目は「DNSSEC」としてまとめて知られていた一連の拡張子のセットでした。これは、「RFC2541」ではもともと演算上の考慮事項が記載されていました（[RFC2541]が[RFC6781]によって廃止されました）。。前者はそれを示唆しています
| ...requestors who require an accurate response code must use TCP.
| .....正確な応答コードを必要とする要求者はTCPを使用する必要があります。
while the latter warns that
後者がそれを警告している間
| ... larger keys increase the size of the KEY and SIG RRs. This
| increases the chance of DNS UDP packet overflow and the possible
| necessity for using higher overhead TCP in responses.
Yet, defying some expectations, DNS over TCP remained little used in real traffic across the Internet in the late 1990s. Dynamic updates saw little deployment between autonomous networks. Around the time DNSSEC was first defined, another new feature helped solidify UDP transport dominance for message transactions.
それでも、いくつかの期待を守ると、TCPを介したDNSは、1990年代後半のインターネット全体で実際のトラフィックではほとんど使用されていませんでした。動的更新は自律ネットワーク間の展開がほとんどありません。DNSSECが最初に定義されています。別の新しい機能は、メッセージトランザクションのUDPトランスポートの優位性を強化するのに役立ちました。
In 1999, the IETF published the Extension Mechanisms for DNS (EDNS(0)) in [RFC2671] (which was obsoleted by [RFC6891] in 2013). That document standardized a way for communicating DNS nodes to perform rudimentary capabilities negotiation. One such capability written into the base specification and present in every EDNS(0)- compatible message is the value of the maximum UDP payload size the sender can support. This unsigned 16-bit field specifies, in bytes, the maximum (possibly fragmented) DNS message size a node is capable of receiving over UDP. In practice, typical values are a subset of the 512- to 4096-byte range. EDNS(0) became widely deployed over the next several years, and numerous surveys (see [CASTRO2010] and [NETALYZR]) have shown that many systems support larger UDP MTUs with EDNS(0).
1999年、IETFは[2013年に[RFC2671]のDNS（EDNS（0））の拡張メカニズムを発表しました。その文書は、DNSノードを通信するために基本的な能力交渉を実行するための方法を標準化した。基本仕様に書き込まれ、eDNS（0）=互換メッセージに存在し、送信者がサポートできる最大UDPペイロードサイズの値は、基本仕様の1つが存在します。この符号なし16ビットフィールドは、バイト単位で、最大（おそらく断片化された）DNSメッセージサイズがUDPを介して受信できることを指定します。実際には、典型的な値は512から4096バイトの範囲のサブセットです。EDNS（0）は今後数年間で広く展開され、多数の調査（[CASTRO2010]と[NetAlyzr]を参照）が、多くのシステムがEDNS（0）のより大きなUDP MTUをサポートすることを示しています。
The natural effect of EDNS(0) deployment meant DNS messages larger than 512 bytes would be less reliant on TCP than they might otherwise have been. While a non-negligible population of DNS systems lacked EDNS(0) or fell back to TCP when necessary, DNS clients still strongly prefer UDP to TCP. For example, as of 2014, DNS-over-TCP transactions remained a very small fraction of overall DNS traffic received by root name servers [VERISIGN].
EDNS（0）の展開の自然な影響は、512バイトを超えるDNSメッセージを意味しています。無視できないDNSシステムの母集団は、EDN（0）を欠いていないか、必要に応じてTCPに戻ったが、DNSクライアントはまだUDPをTCPに強く好む。たとえば、2014年のように、DNS-over-TCPトランザクションは、ルートネームサーバー[Verisign]によって受信された全体的なDNSトラフィックの非常に小さい割合を維持しました。
Although EDNS(0) provides a way for endpoints to signal support for DNS messages exceeding 512 bytes, the realities of a diverse and inconsistently deployed Internet may result in some large messages being unable to reach their destination. Any IP datagram whose size exceeds the MTU of a link it transits will be fragmented and then reassembled by the receiving host. Unfortunately, it is not uncommon for middleboxes and firewalls to block IP fragments. If one or more fragments do not arrive, the application does not receive the message, and the request times out.
EDNS（0）は、512バイトを超えるDNSメッセージのサポートをサポートするためのエンドポイントをエンドポイントに提供する方法を提供しますが、多様で矛盾して展開されたインターネットの現実はいくつかの大きなメッセージが彼らの目的地に到達できない可能性があります。サイズがリンクのMTUを超えるIPデータグラムは、断片化され、次に受信ホストによって再組み立てされます。残念ながら、ミドルボックスやファイアウォールがIPフラグメントをブロックすることは珍しくありません。1つ以上のフラグメントが到着しない場合、アプリケーションはメッセージを受け取らず、要求がタイムアウトします。
For IPv4-connected hosts, the MTU is often an Ethernet payload size of 1500 bytes. This means that the largest unfragmented UDP DNS message that can be sent over IPv4 is likely 1472 bytes, although tunnel encapsulation may reduce that maximum message size in some cases.
IPv4接続ホストの場合、MTUはしばしば1500バイトのイーサネットペイロードサイズです。つまり、IPv4を介して送信できる最大の排除されていないUDP DNSメッセージは1472バイトである可能性がありますが、トンネルのカプセル化は場合によってはその最大メッセージサイズを低下させる可能性があります。
For IPv6, the situation is a little more complicated. First, IPv6 headers are 40 bytes (versus 20 without options in IPv4). Second, approximately one-third of DNS recursive resolvers use the minimum MTU of 1280 bytes [APNIC]. Third, fragmentation in IPv6 can only be done by the host originating the datagram. The need to fragment is conveyed in an ICMPv6 "Packet Too Big" message. The originating host indicates a fragmented datagram with IPv6 extension headers. Unfortunately, it is quite common for both ICMPv6 and IPv6 extension headers to be blocked by middleboxes. According to [HUSTON], some 35% of IPv6-capable recursive resolvers were unable to receive a fragmented IPv6 packet. When the originating host receives a signal that fragmentation is required, it is expected to populate its path MTU cache for that destination. The application will then retry the query after a timeout since the host does not generally retain copies of messages sent over UDP for potential retransmission.
IPv6の場合、状況はもう少し複雑です。まず、IPv6ヘッダーは40バイト（IPv4のオプションなし）です。第二に、DNS再帰リゾルバの約3分の1は、1280バイトの最小MTUを使用します[APNIC]。第3に、IPv6の断片化は、データグラムを発信するホストによってのみ行うことができます。フラグメントの必要性は、ICMPv6「パケットが大きすぎる」メッセージで伝達されます。発信元ホストは、IPv6拡張ヘッダを持つ断片化されたデータグラムを示します。残念ながら、ICMPv6とIPv6の両方の拡張ヘッダーがミドルボックスによってブロックされることは非常に一般的です。[Huston]によると、IPv6対応の再帰リゾルバの約35％が断片化されたIPv6パケットを受信できませんでした。発信元ホストが断片化が必要な信号を受信すると、その宛先のパスMTUキャッシュを入力すると予想されます。その後、ホストが潜在的な再送信のためにUDPを介して送信されたメッセージのコピーを保持していないため、アプリケーションはタイムアウト後にクエリを再試行します。
The practical consequence of all this is that DNS requestors must be prepared to retry queries with different EDNS(0) maximum message size values. Administrators of [BIND] are likely to be familiar with seeing the following message in their system logs: "success resolving ... after reducing the advertised EDNS(0) UDP packet size to 512 octets".
これすべての実用的な結果は、DNS要求者が異なるEDN（0）の最大メッセージサイズ値を持つクエリを再試行するように準備する必要があることです。[BIND]の管理者は、システムログに次のメッセージを見ることに精通している可能性があります。
Often, reducing the EDNS(0) UDP packet size leads to a successful response. That is, the necessary data fits within the smaller message size. However, when the data does not fit, the server sets the truncated flag in its response, indicating the client should retry over TCP to receive the whole response. This is undesirable from the client's point of view because it adds more latency and is potentially undesirable from the server's point of view due to the increased resource requirements of TCP.
多くの場合、EDNS（0）UDPパケットサイズを縮小すると、応答が成功します。つまり、必要なデータは小さいメッセージサイズ内に収まります。ただし、データが収まらない場合、サーバーはその応答に切り捨てられたフラグを設定します。これは、クライアントがTCPを介して応答全体を受信するように再試行することを示します。これはクライアントの観点からは望ましくありません。
Note that a receiver is unable to differentiate between packets lost due to congestion and packets (fragments) intentionally dropped by firewalls or middleboxes. Over network paths with non-trivial amounts of packet loss, larger, fragmented DNS responses are more likely to never arrive and time out compared to smaller, unfragmented responses. Clients might be misled into retrying queries with different EDNS(0) UDP packet size values for the wrong reason.
受信機は、ファイアウォールやミドルボックスによって意図的にドロップされた輻輳とパケット（フラグメント）によって失われたパケットを区別することができません。単独で断片化されていないDNS応答の単独で、断片化されていないDNS応答を持つネットワーク経路を超えるネットワークパスは、到着しない可能性が高く、未整合の反応と比較してタイムアウトします。間違った理由で、さまざまなEDN（0）UDPパケットサイズ値でクライアントを再試行することができます。
The issues around fragmentation, truncation, and TCP are driving certain implementation and policy decisions in the DNS. Notably, Cloudflare implemented a technique that minimizes the number of DNSSEC denial-of-existence records (for its online signing platform) [CLOUDFLARE] and uses an Elliptic Curve Digital Signature Algorithm (ECDSA) such that its signed responses fit easily in 512 bytes. The Key Signing Key (KSK) Rollover Design Team [DESIGNTEAM] spent a lot of time thinking and worrying about response sizes. There is growing sentiment in the DNSSEC community that RSA key sizes beyond 2048 bits are impractical and that critical infrastructure zones should transition to elliptic curve algorithms to keep response sizes manageable [ECDSA].
フラグメンテーション、切り捨て、およびTCP周辺の問題は、DNS内の特定の実装と政策決定を推進しています。特に、CloudFlareは、DNSSEC存在記録の数（オンライン署名プラットフォーム用）[CloudFlare]の数を最小限に抑える技術を実装し、署名された応答が512バイトで簡単に適合するような楕円曲線デジタル署名アルゴリズム（ECDSA）を使用しています。キー署名キー（KSK）ロールオーバーデザインチーム[DesignTeam]は、応答サイズを考えると心配していました。DNSSECコミュニティでは、2048ビットを超えるRSA鍵サイズが実用的ではなく、重要なインフラストラクチャゾーンが楕円曲線アルゴリズムに移行して対応可能な[ECDSA]を維持する必要があることを示しています。
More recently, renewed security concerns about fragmented DNS messages (see [AVOID_FRAGS] and [FRAG_POISON]) are leading implementors to consider smaller responses and lower default EDNS(0) UDP payload size values for both queriers and responders [FLAGDAY2020].
最近になったセキュリティ上の懸念が、断片化されたDNSメッセージに関する懸念がある（[vidio_frags]および[frag_poison]を参照）、最小の応答とより低いデフォルトのEDN（0）UDPペイロードサイズの値を考慮して、クライエータとレスポンダの両方のUDPペイロードサイズ値[Flabday2020]。
Today, the majority of the DNS community expects, or at least has a desire, to see DNS-over-TCP transactions occur without interference [FLAGDAY2020]. However, there has also been a long-held belief by some operators, particularly for security-related reasons, that DNS-over-TCP services should be purposely limited or not provided at all [CHES94] [DJBDNS]. A popular meme is that DNS over TCP is only ever used for zone transfers and is generally unnecessary otherwise, with filtering all DNS-over-TCP traffic even described as a best practice.
今日、DNSコミュニティの大部分は、DNS-over-TCP取引が干渉なしに発生することを確認する、または少なくとも欲求を持つことを期待しています[Fligday2020]。しかし、特にDNS-Over-TCPサービスは故意に限られているか、またはすべての[CHES94] [DJBDNS]で提供されるべきであるかどうかを特にセキュリティ関連の理由から、いくつかの演算子による長期的な信念もありました。人気のあるMEMEは、TCPを介したDNSがゾーン転送にのみ使用されているだけであり、一般に不要であり、一般に不要であり、すべてのDNS-Over-TCPトラフィックをベストプラクティスとして説明しています。
The position on restricting DNS over TCP had some justification given that historical implementations of DNS name servers provided very little in the way of TCP connection management (for example, see Section 6.1.2 of [RFC7766] for more details). However, modern standards and implementations are nearing parity with the more sophisticated TCP management techniques employed by, for example, HTTP(S) servers and load balancers.
TCPを介したDNSを制限する位置は、TCP接続管理の邪魔にならないDNSネームサーバの履歴実装がほとんど設けられていることを考えると、いくつかの正当化を示しました（詳細についてはRFC7766のセクション6.1.2を参照）。しかし、現代の標準と実装は、例えばHTTP（S）サーバーとロードバランサによって採用されているより洗練されたTCP管理技術との間でパリティに近づいています。
The idea that a TCP connection can support multiple transactions goes back as far as [RFC0883], which states: "Multiple messages may be sent over a virtual circuit." Although [RFC1035], which updates the former, omits this particular detail, it has been generally accepted that a TCP connection can be used for more than one query and response.
TCP接続が複数のトランザクションをサポートできるという考えは、[RFC0883]のように戻ってきます。前者を更新する[RFC1035]は、この特定の詳細を省略していますが、一般に、TCP接続を複数のクエリと応答に使用できることが認められています。
[RFC5966] clarifies that servers are not required to preserve the order of queries and responses over any transport. [RFC7766], which updates the former, further encourages query pipelining over TCP to achieve performance on par with UDP. A server that sends out-of-order responses to pipelined queries avoids head-of-line blocking when the response for a later query is ready before the response to an earlier query.
[RFC5966]サーバーがあらゆるトランスポートにわたってクエリと応答の順序を保持する必要がないことを明確にします。前者を更新する[RFC7766]は、UDPとPARでパフォーマンスを達成するためにTCPを介してパイプライン化をクエリすることを奨励します。パイプラインクエリに順序を除外するサーバーは、後のクエリの応答が以前のクエリへの応答の前に準備ができたときに行頭ブロックを回避します。
However, TCP can potentially suffer from a different head-of-line blocking problem due to packet loss. Since TCP itself enforces ordering, a single lost segment delays delivery of data in any following segments until the lost segment is retransmitted and successfully received.
しかしながら、TCPはパケット損失のために異なる線の遮断問題を潜在的に被る可能性がある。TCP自体が順序付けを強制するので、単一の失われたセグメントは、失われたセグメントが再送信され正常に受信されるまで、任意のセグメント内のデータの配信を遅らせる。
An average increase in DNS message size (e.g., due to DNSSEC), the continued development of new DNS features (Appendix A), and a denial-of-service mitigation technique (Section 8) all show that DNS-over-TCP transactions are as important to the correct and safe operation of the Internet DNS as ever, if not more so. Furthermore, there has been research that argues connection-oriented DNS transactions may provide security and privacy advantages over UDP transport [TDNS]. In fact, the standard for DNS over TLS [RFC7858] is just this sort of specification. Therefore, this document makes explicit that it is undesirable for network operators to artificially inhibit DNS-over-TCP transport.
DNSメッセージサイズの平均増加（例えば、DNSSECによる）、新しいDNS機能の継続開発（付録A）、およびサービス拒否緩和技術（セクション8）はすべて、DNS-over-TCPトランザクションがあることを示しています。これまでにない場合は、インターネットDNSの正しい安全な操作にとって重要です。さらに、接続指向のDNSトランザクションを主張することができる研究は、UDPトランスポート[TDNS]よりもセキュリティとプライバシーの利点を提供する可能性がありました。実際、TLS上のDNSの標準[RFC7858]は、この種の仕様です。したがって、この文書は、ネットワーク事業者がDNS-Over-TCPトランスポートを人為的に阻害するのが望ましくないことを明確にします。
Section 6.1.3.2 of [RFC1123] is updated as follows:
[RFC1123]のセクション6.1.3.2は次のように更新されます。
OLD:
年：
| DNS resolvers and recursive servers MUST support UDP, and SHOULD | support TCP, for sending (non-zone-transfer) queries.
| ..DNSリゾルバと再帰サーバーはUDPをサポートしている必要があります。送信（非ゾーン転送）クエリを送信するためのTCPをサポートします。
NEW:
新着：
| All DNS resolvers and servers MUST support and service both UDP | and TCP queries.
| ..すべてのDNSリゾルバーとサーバーはUDPをサポートしてサービスを提供する必要があります。そしてTCPクエリ
Note that:
ご了承ください：
* DNS servers (including forwarders) MUST support and service TCP for receiving queries so that clients can reliably receive responses that are larger than what either side considers too large for UDP.
* DNSサーバー（フォワーダーを含む）は、クライアントがUDPに対して大きすぎると考えるものよりも大きい応答を確実に受信できるように、クエリを受信するためのTCPをサポートしてサービスを提供しなければなりません。
* DNS clients MUST support TCP for sending queries so that they can retry truncated UDP responses as necessary.
* DNSクライアントは、必要に応じて切り捨てられたUDP応答を再試行できるように、クエリを送信するためのTCPをサポートしている必要があります。
Furthermore, the requirement in Section 6.1.3.2 of [RFC1123] around limiting the resources a server devotes to queries is hereby updated:
さらに、[RFC1123]のセクション6.1.3.2の要件はリソースを制限することを特徴としています。
OLD:
年：
| A name server MAY limit the resources it devotes to TCP queries,
| but it SHOULD NOT refuse to service a TCP query just because it
| would have succeeded with UDP.
NEW:
新着：
| A name server MAY limit the resources it devotes to queries, but
| it MUST NOT refuse to service a query just because it would have
| succeeded with another transport protocol.
Lastly, Section 1 of [RFC1536] is updated to eliminate the misconception that TCP is only useful for zone transfers:
最後に、[RFC1536]のセクション1は更新され、TCPがゾーン転送にのみ有用であるという誤ったコンセプトを排除します。
OLD:
年：
| DNS implements the classic request-response scheme of client-
| server interaction. UDP is, therefore, the chosen protocol for
| communication though TCP is used for zone transfers.
NEW:
新着：
| DNS implements the classic request-response scheme of client-| server interaction.
| ..DNSはクライアントの古典的な要求 - 応答スキームを実装します。サーバーの対話
The filtering of DNS over TCP is harmful in the general case. DNS resolver and server operators MUST support and provide DNS service over both UDP and TCP transports. Likewise, network operators MUST allow DNS service over both UDP and TCP transports. It is acknowledged that DNS-over-TCP service can pose operational challenges that are not present when running DNS over UDP alone, and vice versa. However, the potential damage incurred by prohibiting DNS-over-TCP service is more detrimental to the continued utility and success of the DNS than when its usage is allowed.
TCP上のDNSのフィルタリングは一般的な場合に有害です。DNSリゾルバとサーバー演算子は、UDPトランスポートとTCPトランスポートの両方にわたってDNSサービスをサポートして提供する必要があります。同様に、ネットワーク事業者はUDPトランスポートとTCPトランスポートの両方でDNSサービスを許可する必要があります。DNS-over-TCPサービスは、UDPを介してDNSを実行しているときに存在しない運用上の課題を引き起こす可能性があることが認識されています。ただし、DNS-over-TCPサービスを禁止することで発生した潜在的な損害は、その使用が許可されているときよりもDNSの継続的な有用性と成功にとって有害です。
This section describes measures that systems and applications can take to optimize performance over TCP and to protect themselves from TCP-based resource exhaustion and attacks.
このセクションでは、システムとアプリケーションがTCPを介したパフォーマンスを最適化し、TCPベースのリソースの枯渇と攻撃から自分自身を保護するためにかかることが尺度について説明します。
Resolvers and other DNS clients should be aware that some servers might not be reachable over TCP. For this reason, clients MAY track and limit the number of TCP connections and connection attempts to a single server. Reachability problems can be caused by network elements close to the server, close to the client, or anywhere along the path between them. Mobile clients that cache connection failures MAY do so on a per-network basis or MAY clear such a cache upon change of network.
リゾルバと他のDNSクライアントは、一部のサーバーがTCPを介して到達できない可能性があることに注意する必要があります。このため、クライアントはTCP接続の数を追跡し、単一のサーバーへの接続試行を行うことがあります。到達可能性の問題は、ネットワーク要素がサーバーの近くに、クライアントの近く、またはそれらの間のパスに沿った場所にアクセスすることができます。接続失敗をキャッシュ接続したモバイルクライアントは、ネットワークごとにそうすることができ、またはネットワークの変更時にそのようなキャッシュをクリアすることができます。
Additionally, DNS clients MAY enforce a short timeout on unestablished connections rather than rely on the host operating system's TCP connection timeout, which is often around 60-120 seconds (i.e., due to an initial retransmission timeout of 1 second, the exponential back-off rules of [RFC6298], and a limit of six retries as is the default in Linux).
さらに、DNSクライアントは、ホストオペレーティングシステムのTCP接続タイムアウトに依存していなくても、不可欠な接続で短いタイムアウトを強制することができます。これは、しばしば約60~120秒（すなわち、1秒の最初の再送信タイムアウト、指数関数的なバックオフのために[RFC6298]の規則、およびLinuxのデフォルトと同様に6回の再試行の制限）。
The SYN flooding attack is a denial-of-service method affecting hosts that run TCP server processes [RFC4987]. This attack can be very effective if not mitigated. One of the most effective mitigation techniques is SYN cookies, described in Section 3.6 of [RFC4987], which allows the server to avoid allocating any state until the successful completion of the three-way handshake.
SYNフラッディング攻撃は、TCPサーバープロセス[RFC4987]を実行するホストに影響を与えるサービス拒否方法です。この攻撃は軽減されない場合は非常に効果的です。最も効果的な緩和技術の1つは[RFC4987]のセクション3.6で説明されているSYN Cookieであり、サーバーは3方向ハンドシェイクが正常に完了するまで任意の状態を割り当てることができます。
Services not intended for use by the public Internet, such as most recursive name servers, SHOULD be protected with access controls. Ideally, these controls are placed in the network, well before any unwanted TCP packets can reach the DNS server host or application. If this is not possible, the controls can be placed in the application itself. In some situations (e.g., attacks), it may be necessary to deploy access controls for DNS services that should otherwise be globally reachable. See also [RFC5358].
ほとんどの再帰的ネームサーバなどの公衆インターネットによる使用を意図していないサービスは、アクセス制御で保護する必要があります。理想的には、これらのコントロールはネットワーク内に配置され、不要なTCPパケットはDNSサーバーのホストまたはアプリケーションに到達する可能性があります。これが不可能な場合は、コントロールをアプリケーション自体に配置できます。状況によっては（例えば、攻撃）、そうでなければグローバルに到達可能であるべきであるDNSサービスのためのアクセス制御を展開することが必要かもしれない。[RFC5358]も参照してください。
The FreeBSD and NetBSD operating systems have an "accept filter" feature ([accept_filter]) that postpones delivery of TCP connections to applications until a complete, valid request has been received. The dns_accf(9) filter ensures that a valid DNS message is received. If not, the bogus connection never reaches the application. The Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can provide some of the same benefits as the BSD accept filter feature. These features are implemented as low-level socket options and are not activated automatically. If applications wish to use these features, they need to make specific calls to set the right options, and administrators may also need to configure the applications to appropriately use the features.
FreeBSDおよびNetBSDオペレーティングシステムには、完全で有効な要求が受信されるまでアプリケーションへのTCP接続の配信を延期する「フィルタ」機能（[accept_filter]）があります。DNS_ACCF（9）フィルタは、有効なDNSメッセージを受信したことを確認します。そうでなければ、ボーガス接続はアプリケーションに届かない。Linux TCP_DEFER_ACCEPT機能は、スコープが制限されていますが、BSD ACCEPT FILTER機能と同じ利点の一部を提供できます。これらの機能は低レベルのソケットオプションとして実装されており、自動的にはアクティブ化されていません。アプリケーションがこれらの機能を使用したい場合は、正しいオプションを設定するための特定の呼び出しを行う必要があり、管理者は機能を適切に使用するようにアプリケーションを構成する必要があるかもしれません。
Per [RFC7766], applications and administrators are advised to remember that TCP MAY be used before sending any UDP queries. Networks and applications MUST NOT be configured to refuse TCP queries that were not preceded by a UDP query.
[RFC7766]ごとに、アプリケーションと管理者は、UDPクエリを送信する前にTCPを使用できることを覚えておくことをお勧めします。ネットワークとアプリケーションは、UDPクエリの前に記載されていないTCPクエリを拒否するように設定してはいけません。
TCP Fast Open (TFO) [RFC7413] allows TCP clients to shorten the handshake for subsequent connections to the same server. TFO saves one round-trip time in the connection setup. DNS servers SHOULD enable TFO when possible. Furthermore, DNS servers clustered behind a single service address (e.g., anycast or load balancing) SHOULD either use the same TFO server key on all instances or disable TFO for all members of the cluster.
TCP Fast Open（TFO）[RFC7413]は、TCPクライアントが同じサーバーへの後続の接続のハンドシェイクを短縮できます。TFOは接続設定で1回のラウンドトリップ時間を節約します。可能であれば、DNSサーバーはTFOを有効にする必要があります。さらに、単一のサービスアドレスの背後にあるDNSサーバ（例えば、エニーキャストまたはロードバランシング）は、すべてのインスタンスで同じTFOサーバキーを使用するか、クラスタのすべてのメンバーに対してTFOを無効にする必要があります。
DNS clients MAY also enable TFO. At the time of this writing, it is not implemented or is disabled by default on some operating systems. [WIKIPEDIA_TFO] describes applications and operating systems that support TFO.
DNSクライアントはTFOも可能になる可能性があります。この書き込み時には、オペレーティングシステムによっては実装されていないか、デフォルトで無効にされています。[Wikipedia_tfo]は、TFOをサポートするアプリケーションとオペレーティングシステムについて説明しています。
Since host memory for TCP state is a finite resource, DNS clients and servers SHOULD actively manage their connections. Applications that do not actively manage their connections can encounter resource exhaustion leading to denial of service. For DNS, as in other protocols, there is a trade-off between keeping connections open for potential future use and the need to free up resources for new connections that will arrive.
TCP状態のホストメモリは有限リソースであるため、DNSクライアントとサーバーはアクティブに接続を管理する必要があります。接続を積極的に管理していないアプリケーションは、サービス拒否につながるリソースの枯渇に遭遇する可能性があります。DNSの場合、他のプロトコルのように、潜在的な将来の使用のために接続を開くと、到着する新しい接続のためのリソースを解放する必要性を解決するためのトレードオフがあります。
Operators of DNS server software SHOULD be aware that operating system and application vendors MAY impose a limit on the total number of established connections. These limits may be designed to protect against DDoS attacks or performance degradation. Operators SHOULD understand how to increase these limits if necessary and the consequences of doing so. Limits imposed by the application SHOULD be lower than limits imposed by the operating system so that the application can apply its own policy to connection management, such as closing the oldest idle connections first.
DNSサーバソフトウェアの演算子は、オペレーティングシステムとアプリケーションベンダが確立された接続の総数に制限を課す可能性があることに注意してください。これらの制限は、DDOS攻撃やパフォーマンスの低下から保護するように設計されている可能性があります。オペレータは、必要に応じてこれらの制限を増やす方法とその結果を理解する必要があります。アプリケーションによって課される制限は、最初に最も古いアイドル接続を閉じるなどの接続管理に独自のポリシーを適用できるように、オペレーティングシステムによって課される制限よりも低くなければなりません。
DNS server software MAY provide a configurable limit on the number of established connections per source IP address or subnet. This can be used to ensure that a single or small set of users cannot consume all TCP resources and deny service to other users. Note, however, that if this limit is enabled, it possibly limits client performance while leaving some TCP resources unutilized. Operators SHOULD be aware of these trade-offs and ensure this limit, if configured, is set appropriately based on the number and diversity of their users and whether users connect from unique IP addresses or through a shared Network Address Translator (NAT) [RFC3022].
DNSサーバーソフトウェアは、送信元IPアドレスまたはサブネットごとに確立された接続数に設定可能な制限を提供できます。これは、ユーザーの単一または小さなセットのユーザーがすべてのTCPリソースを消費し、サービスを他のユーザーに拒否できないようにするために使用できます。ただし、この制限が有効になっている場合は、TCPリソースを未使用にしながらクライアントパフォーマンスを制限する可能性があります。オペレータはこれらのトレードオフに注意し、設定されている場合には、ユーザーの数と多様性に基づいてこの制限を確実に設定し、ユーザーの数と多様性に基づいて、ユーザーが一意のIPアドレスから接続するか、共有ネットワークアドレストランスレータ（NAT）[RFC3022]。
DNS server software SHOULD provide a configurable timeout for idle TCP connections. This can be used to free up resources for new connections and to ensure that idle connections are eventually closed. At the same time, it possibly limits client performance while leaving some TCP resources unutilized. For very busy name servers, this might be set to a low value, such as a few seconds. For less busy servers, it might be set to a higher value, such as tens of seconds. DNS clients and servers SHOULD signal their timeout values using the edns-tcp-keepalive EDNS(0) option [RFC7828].
DNSサーバーソフトウェアは、アイドルTCP接続のための設定可能なタイムアウトを提供する必要があります。これは、新しい接続のためのリソースを解放し、アイドル接続が最終的に閉じられていることを確認するために使用できます。同時に、いくつかのTCPリソースを未使用にしながらクライアントパフォーマンスを制限する可能性があります。非常に忙しいネームサーバの場合、これは数秒などの低い値に設定される可能性があります。より少ないビジーサーバーの場合は、数十秒などの値に設定されます。DNSクライアントとサーバーは、EDNS-TCP-KeepAlive EDNS（0）オプション[RFC7828]を使用して、それらのタイムアウト値をシグナリングする必要があります。
DNS server software MAY provide a configurable limit on the number of transactions per TCP connection. This can help protect against unfair connection use (e.g., not releasing connection slots to other clients) and network evasion attacks.
DNSサーバーソフトウェアは、TCP接続ごとのトランザクション数に設定可能な制限を提供できます。これは、不当な接続の使用から保護するのに役立ちます（例えば、他のクライアントへの接続スロットを解放しない）とネットワーク回避攻撃を受けています。
Similarly, DNS server software MAY provide a configurable limit on the total duration of a TCP connection. This can help protect against unfair connection use, slow read attacks, and network evasion attacks.
同様に、DNSサーバソフトウェアは、TCP接続の合計期間に設定可能な制限を提供することができる。これは、不正な接続の使用、遅い攻撃、およびネットワーク回避攻撃から保護するのに役立ちます。
Since clients may not be aware of server-imposed limits, clients utilizing TCP for DNS need to always be prepared to re-establish connections or otherwise retry outstanding queries.
クライアントはサーバーに課された制限に気付かない可能性があるため、DNSにTCPを利用するクライアントは、接続を再確立するか、または優れた優れたクエリを再試行するように常に準備する必要があります。
The TCP peer that initiates a connection close retains the socket in the TIME_WAIT state for some amount of time, possibly a few minutes. It is generally preferable for clients to initiate the close of a TCP connection so that busy servers do not accumulate many sockets in the TIME_WAIT state, which can cause performance problems or even denial of service. The edns-tcp-keepalive EDNS(0) option [RFC7828] can be used to encourage clients to close connections.
接続を開始するTCPピアは、閉じるTIME_WAIT状態のソケットを数時間、おそらく数分間保持します。クライアントは、クライアントがTCP接続の近くを開始することが一般に、ビジーサーバがTime_Wait状態で多くのソケットを蓄積しないように、パフォーマンスの問題やサービス拒否を引き起こす可能性があるように、TCP接続の閉じることが好ましい。EDNS-TCP-KeepAlive EDNS（0）オプション[RFC7828]は、クライアントに接続を閉じることを奨励するために使用できます。
On systems where large numbers of sockets in TIME_WAIT are observed (as either a client or a server) and are affecting an application's performance, it may be tempting to tune local TCP parameters. For example, the Linux kernel has a "sysctl" parameter named net.ipv4.tcp_tw_reuse, which allows connections in the TIME_WAIT state to be reused in specific circumstances. Note, however, that this affects only outgoing (client) connections and has no impact on servers. In most cases, it is NOT RECOMMENDED to change parameters related to the TIME_WAIT state. It should only be done by those with detailed knowledge of both TCP and the affected application.
time_wait内の多数のソケットが（クライアントまたはサーバとして）観察されており、アプリケーションのパフォーマンスに影響を与えているシステムでは、ローカルTCPパラメータを調整することを魅力的である可能性があります。たとえば、Linuxカーネルには、net.ipv4.tcp_tw_reuseという名前の "sysctl"パラメータがあり、TIME_WAIT状態の接続を特定の状況で再利用できます。ただし、これは発信（クライアント）接続のみに影響し、サーバーに影響を与えません。ほとんどの場合、time_wait状態に関連するパラメータを変更することはお勧めできません。それはTCPと影響を受けるアプリケーションの両方の詳細な知識を持つ人々によってのみ行われるべきです。
DNS messages may be sent over TLS to provide privacy between stubs and recursive resolvers. [RFC7858] is a Standards Track document describing how this works. Although DNS over TLS utilizes TCP port 853 instead of port 53, this document applies equally well to DNS over TLS. Note, however, that DNS over TLS is only defined between stubs and recursives at the time of this writing.
DNSメッセージはTLSを介して送信されて、スタブと再帰的なリゾルバの間でプライバシーを提供できます。[RFC7858]は、この機能を説明する標準トラック文書です。DNS over TLSはポート53の代わりにTCPポート853を利用していますが、この文書はTLSを介してDNSにも同様に適用されます。ただし、TLSを介したDNSは、この書き込み時にスタブと再帰生の間でのみ定義されていることに注意してください。
The use of TLS places even stronger operational burdens on DNS clients and servers. Cryptographic functions for authentication and encryption require additional processing. Unoptimized connection setup with TLS 1.3 [RFC8446] takes one additional round trip compared to TCP. Connection setup times can be reduced with TCP Fast Open and TLS False Start [RFC7918] for TLS 1.2. TLS 1.3 session resumption does not reduce round-trip latency because no application profile for use of TLS 0-RTT data with DNS has been published at the time of this writing. However, TLS session resumption can reduce the number of cryptographic operations, and in TLS 1.2, session resumption does reduce the number of additional round trips from two to one.
TLSの使用は、DNSクライアントとサーバー上のより強い運用上の負担をもたらします。認証および暗号化のための暗号化関数は追加の処理を必要とします。TLS 1.3 [RFC8446]を使用したオプション化されていない接続設定は、TCPと比較して追加の往復1回の旅行を取ります。TCP Fast OpenとTLS False Start [RFC7918]がTLS 1.2の場合は、接続設定時間を短縮できます。TLS 1.3セッションの再開は、DNSを使用してTLS 0-RTTデータを使用するためのアプリケーションプロファイルがこの書き込み時に公開されていないため、往復の待ち時間を短縮しません。ただし、TLSセッションの再開は暗号操作の数を減らすことができ、TLS 1.2ではセッションの再開は2から1への追加の往復の数を減らすことができます。
A survey of features and defaults was conducted for popular open-source DNS server implementations at the time of writing. This section documents those defaults and makes recommendations for configurable limits that can be used in the absence of any other information. Any recommended values in this document are only intended as a starting point for administrators that are unsure of what sorts of limits might be reasonable. Operators SHOULD use application-specific monitoring, system logs, and system monitoring tools to gauge whether their service is operating within or exceeding these limits and adjust accordingly.
執筆時点での人気のあるオープンソースDNSサーバー実装の機能とデフォルトの調査が行われました。このセクションでは、これらのデフォルトを文書化し、他の情報がない場合に使用できる設定可能な制限に関する推奨事項を作成します。この文書の推奨値は、どのような種類の制限が妥当であるかがわからない管理者の出発点としてのみ意図されています。オペレータは、アプリケーション固有の監視、システムログ、およびシステム監視ツールを使用して、それらのサービスがこれらの制限内で動作しているかそれを超えているかどうかをゲージし、それに応じて調整する必要があります。
Most open-source DNS server implementations provide a configurable limit on the total number of established connections. Default values range from 20 to 150. In most cases, where the majority of queries take place over UDP, 150 is a reasonable limit. For services or environments where most queries take place over TCP or TLS, 5000 is a more appropriate limit.
ほとんどのオープンソースのDNSサーバー実装は、確立された接続の総数に設定可能な制限を提供します。デフォルト値は20から150の範囲です。ほとんどの場合、クエリの大部分がUDPよりも発生すると、150は妥当な制限です。ほとんどのクエリがTCPまたはTLSを介して行われるサービスや環境の場合、5000はより適切な制限です。
Only some open-source implementations provide a way to limit the number of connections per source IP address or subnet, but the default is to have no limit. For environments or situations where it may be necessary to enable this limit, 25 connections per source IP address is a reasonable starting point. The limit should be increased when aggregated by subnet or for services where most queries take place over TCP or TLS.
いくつかのオープンソースの実装だけが、送信元IPアドレスまたはサブネットごとに接続数を制限する方法を提供しますが、デフォルトでは制限がありません。この制限を有効にする必要がある環境や状況については、送信元IPアドレスごとに25個の接続が妥当な開始点です。サブネットによって集約されるとき、またはほとんどのクエリがTCPまたはTLSを介して行われるサービスの場合、制限は増加する必要があります。
Most open-source implementations provide a configurable idle timeout on connections. Default values range from 2 to 30 seconds. In most cases, 10 seconds is a reasonable default for this limit. Longer timeouts improve connection reuse, but busy servers may need to use a lower limit.
ほとんどのオープンソースの実装は、接続に設定可能なアイドルタイムアウトを提供します。デフォルト値は2から30秒の範囲です。ほとんどの場合、10秒はこの制限の合理的なデフォルトです。より長いタイムアウトは接続の再利用を改善しますが、ビジーサーバーは下限を使用する必要があるかもしれません。
Only some open-source implementations provide a way to limit the number of transactions per connection, but the default is to have no limit. This document does not offer advice on particular values for such a limit.
一部のオープンソースの実装だけが接続ごとにトランザクション数を制限する方法を提供しますが、デフォルトでは制限がありません。この文書は、そのような限界の特定の値に関するアドバイスを提供しません。
Only some open-source implementations provide a way to limit the duration of connection, but the default is to have no limit. This document does not offer advice on particular values for such a limit.
接続期間を制限する方法を提供するいくつかのオープンソースの実装だけが、デフォルトでは制限がないことです。この文書は、そのような限界の特定の値に関するアドバイスを提供しません。
Networks that filter DNS over TCP risk losing access to significant or important pieces of the DNS namespace. For a variety of reasons, a DNS answer may require a DNS-over-TCP query. This may include large message sizes, lack of EDNS(0) support, or DDoS mitigation techniques (including Response Rate Limiting [RRL]); additionally, perhaps some future capability that is as yet unforeseen will also demand TCP transport.
TCPを介してDNSをフィルタリングするネットワークは、DNS名前空間の重要なまたは重要な部分へのアクセスを失うリスクを失います。さまざまな理由で、DNS回答はDNS-Over-TCPクエリを必要とする可能性があります。これには、大きなメッセージサイズ、EDNS（0）のサポートの欠如、またはDDOS緩和技術（応答率制限を含む）が含まれます。さらに、おそらく将来の能力がまだ予期していない能力もTCP輸送を要求するでしょう。
For example, [RFC7901] describes a latency-avoiding technique that sends extra data in DNS responses. This makes responses larger and potentially increases the effectiveness of DDoS reflection attacks. The specification mandates the use of TCP or DNS cookies [RFC7873].
たとえば、[RFC7901]は、DNS応答に追加のデータを送信する待ち時間回避技術を説明しています。これにより、応答が大きくなり、DDOS反射攻撃の有効性が向上します。仕様はTCPまたはDNS Cookie [RFC7873]の使用を義務付けています。
Even if any or all particular answers have consistently been returned successfully with UDP in the past, this continued behavior cannot be guaranteed when DNS messages are exchanged between autonomous systems. Therefore, filtering of DNS over TCP is considered harmful and contrary to the safe and successful operation of the Internet. This section enumerates some of the known risks at the time of this writing when networks filter DNS over TCP.
過去にUDPとともに一貫して返された場合でも、DNSメッセージが自律システム間で交換されると、この継続的な動作を保証することはできません。したがって、TCPを介したDNSのフィルタリングは有害と考えられ、インターネットの安全で成功した操作とは反対に考えられます。このセクションでは、ネットワークがTCPを介してDNSをフィルタリングしたときのこの書き込み時に、既知のリスクの一部を列挙します。
Networks that filter DNS over TCP may inadvertently cause problems for third-party resolvers as experienced by [TOYAMA]. For example, a resolver receives queries for a moderately popular domain. The resolver forwards the queries to the domain's authoritative name servers, but those servers respond with the TC bit set. The resolver retries over TCP, but the authoritative server blocks DNS over TCP. The pending connections consume resources on the resolver until they time out. If the number and frequency of these truncated-and-then-blocked queries are sufficiently high, the resolver wastes valuable resources on queries that can never be answered. This condition is generally not easily or completely mitigated by the affected DNS resolver operator.
TCPを介してDNSをフィルタリングするネットワークは、[富山]が経験するようにサードパーティのリゾルバに問題を引き起こす可能性があります。たとえば、リゾルバは適度に人気のあるドメインのクエリを受け取ります。リゾルバはクエリをドメインの権限のあるネームサーバーに転送しますが、それらのサーバーはTCビットセットで応答します。リゾルバはTCPを介して再試行されますが、権限のあるサーバーはTCPを介してDNSをブロックします。保留中の接続は、それらがタイムアウトするまでレゾルバ上のリソースを消費します。これらの切り捨てられたおよび遮断されたクエリの数と周波数が十分に高い場合、レゾルバは答えられないクエリ上の貴重なリソースを浪費します。この状態は、影響を受けるDNSリゾルバ演算子によって一般的に簡単にも完全に軽減されていません。
The plans for deploying DNSSEC KSK for the root zone highlighted a potential problem in retrieving the root zone key set [LEWIS]. During some phases of the KSK rollover process, root zone DNSKEY responses were larger than 1280 bytes, the IPv6 minimum MTU for links carrying IPv6 traffic [RFC8200]. There was some concern that any DNS server unable to receive large DNS messages over UDP, or any DNS message over TCP, would experience disruption while performing DNSSEC validation [KSK_ROLLOVER_ARCHIVES].
ルートゾーンにDNSSEC KSKをデプロイするための計画は、ルートゾーンキーセット[LEWIS]を取得する際の潜在的な問題を強調表示しました。KSKロールオーバープロセスのフェーズの場合、ルートゾーンDNSKEY応答は1280バイトを超え、IPv6トラフィックを搭載したリンクのIPv6最小MTU [RFC8200]。UDPよりも大規模なDNSメッセージ、またはTCPを介してDNSメッセージを受信できないDNSサーバーは、DNSSEC検証の実行中に中断を経験することがあります。
However, during the year-long postponement of the KSK rollover, there were no reported problems that could be attributed to the 1414 octet DNSKEY response when both the old and new keys were published in the zone. Additionally, there were no reported problems during the two-month period when the old key was published as revoked and the DNSKEY response was 1425 octets in size [ROLL_YOUR_ROOT].
ただし、KSKロールオーバーの年間延期中に、古いキーと新しいキーの両方がゾーン内に公開されたときに1414オクテットDNSKEY応答に起因する可能性がある報告された問題はありませんでした。さらに、古いキーが取り消されたとおりに公開され、DNSKEY応答が2ヶ月の間に、DNSKEY応答が1425オクテットのサイズ[roll_your_root]であると報告されていませんでした。
Developers of applications that log or monitor DNS SHOULD NOT ignore TCP due to the perception that it is rarely used or is hard to process. Operators SHOULD ensure that their monitoring and logging applications properly capture DNS messages over TCP. Otherwise, attacks, exfiltration attempts, and normal traffic may go undetected.
DNSをログまたは監視するアプリケーションの開発者は、それがめったに使用されない、または処理が難しいという認識のためにTCPを無視しないでください。演算子は、監視アプリケーションとロギングアプリケーションがTCPを介してDNSメッセージを正しくキャプチャするようにする必要があります。それ以外の場合は、攻撃、排除の試行、および通常のトラフィックが検出されない可能性があります。
DNS messages over TCP are in no way guaranteed to arrive in single segments. In fact, a clever attacker might attempt to hide certain messages by forcing them over very small TCP segments. Applications that capture network packets (e.g., with libpcap [libpcap]) SHOULD implement and perform full TCP stream reassembly and analyze the reassembled stream instead of the individual packets. Otherwise, they are vulnerable to network evasion attacks [phrack]. Furthermore, such applications need to protect themselves from resource exhaustion attacks by limiting the amount of memory allocated to tracking unacknowledged connection state data. dnscap [dnscap] is an open-source example of a DNS logging program that implements TCP stream reassembly.
TCPを介したDNSメッセージは、単一セグメントに到着することは決して保証されていません。実際、巧妙な攻撃者は、非常に小さいTCPセグメントを超えてそれらを強制することによって特定のメッセージを非表示にすることを試みるかもしれません。ネットワークパケットをキャプチャするアプリケーション（たとえば、libpcap [libpcap]）は、完全なTCPストリームの再構成を実装し実行し、個々のパケットの代わりに再組み立てされたストリームを分析する必要があります。それ以外の場合は、ネットワーク回避攻撃の脆弱性があります[Phrack]。さらに、このようなアプリケーションは、未確認の接続状態データを追跡するために割り当てられたメモリの量を制限することによって、リソースの枯渇攻撃から自分自身を保護する必要があります。DNScap [DNScap]は、TCPストリームの再構成を実装するDNSロギングプログラムのオープンソースの例です。
Developers SHOULD also keep in mind connection reuse, query pipelining, and out-of-order responses when building and testing DNS monitoring applications.
開発者はまた、DNS監視アプリケーションを構築およびテストするときに、接続の再利用、クエリパイプライン化、および順序外回答を維持する必要があります。
As an alternative to packet capture, some DNS server software supports dnstap [dnstap] as an integrated monitoring protocol intended to facilitate wide-scale DNS monitoring.
パケットキャプチャの代わりに、一部のDNSサーバソフトウェアは、ワイドスケールDNS監視を容易にすることを目的とした統合監視プロトコルとしてDNSTAP [DNSTAP]をサポートしています。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This document, providing operational requirements, is the companion to the implementation requirements of DNS over TCP provided in [RFC7766]. The security considerations from [RFC7766] still apply.
この文書は、運用上の要件を提供することで、[RFC7766]に提供されたTCPを介したDNSの実装要件のコンパニオンです。[RFC7766]からのセキュリティ上の考慮事項はまだ適用されます。
Ironically, returning truncated DNS-over-UDP answers in order to induce a client query to switch to DNS over TCP has become a common response to source-address-spoofed, DNS denial-of-service attacks [RRL]. Historically, operators have been wary of TCP-based attacks, but in recent years, UDP-based flooding attacks have proven to be the most common protocol attack on the DNS. Nevertheless, a high rate of short-lived DNS transactions over TCP may pose challenges. In fact, [DAI21] details a class of IP fragmentation attacks on DNS transactions if the IP Identifier field (16 bits in IPv4 and 32 bits in IPv6) can be predicted and a system is coerced to fragment rather than retransmit messages. While many operators have provided DNS-over-TCP service for many years without duress, past experience is no guarantee of future success.
皮肉なことに、TCPを介したDNSに切り替えるためにクライアントクエリを誘導するために、トランケートクエリを誘導するために、Source-AddressスプーフィングDNS拒否攻撃[RRL]に対する共通の対応となっています。歴史的に、オペレーターはTCPベースの攻撃に警備員が務めていますが、近年、UDPベースの洪水攻撃はDNSに対する最も一般的なプロトコル攻撃であることが証明されています。それにもかかわらず、TCP上の短寿命のDNS取引の高率は課題を提起する可能性があります。実際には、[DAI21] DNSトランザクションのクラスのIPフラグメンテーション攻撃のクラスIP識別子フィールド（IPv6内のIPv4および32ビット）を予測することができ、システムが再送信メッセージではなくフラグメントに強制されます。多くのオペレーターが長年にわたってDNS-over-TCPサービスを提供していますが、過去の経験は将来の成功を保証しません。
DNS over TCP is similar to many other Internet TCP services. TCP threats and many mitigation strategies have been well documented in a series of documents such as [RFC4953], [RFC4987], [RFC5927], and [RFC5961].
TCP上のDNSは他の多くのインターネットTCPサービスと似ています。TCPの脅威と多くの緩和戦略は、[RFC4953]、[RFC4987]、[RFC5927]、[RFC5961]などの一連の文書によく文書化されています。
As mentioned in Section 6, applications that implement TCP stream reassembly need to limit the amount of memory allocated to connection tracking. A failure to do so could lead to a total failure of the logging or monitoring application. Imposition of resource limits creates a trade-off between allowing some stream reassembly to continue and allowing some evasion attacks to succeed.
第6章で述べたように、TCPストリームを実装するアプリケーションは、接続追跡に割り当てられているメモリの量を制限する必要があります。そうしないと、ロギングまたは監視アプリケーションの完全な障害が発生する可能性があります。リソース制限の課題は、いくつかのストリームの再組み立てを継続し、いくつかの回避攻撃を成功させることを可能にすることによってトレードオフを作成します。
This document recommends that DNS servers enable TFO when possible. [RFC7413] recommends that a pool of servers behind a load balancer with a shared server IP address also share the key used to generate Fast Open cookies to prevent inordinate fallback to the three-way handshake (3WHS). This guidance remains accurate but comes with a caveat: compromise of one server would reveal this group-shared key and allow for attacks involving the other servers in the pool by forging invalid Fast Open cookies.
このドキュメントでは、可能であればDNSサーバーがTFOを有効にすることをお勧めします。[RFC7413]共有サーバーのIPアドレスを持つロードバランサの背後にあるサーバーのプールも、3WAYハンドシェイク（3WHS）への不適切なフォールバックを防ぐために高速なオープンクッキーを生成するためのキーを共有することをお勧めします。このガイダンスは正確なままですが、1つのサーバーの妥協点がこのグループ共有キーを明らかにし、無効なオープンクッキーを鍛造することによってプール内の他のサーバーを含む攻撃を可能にします。
Since DNS over both UDP and TCP uses the same underlying message format, the use of one transport instead of the other does not change the privacy characteristics of the message content (i.e., the name being queried). A number of protocols have recently been developed to provide DNS privacy, including DNS over TLS [RFC7858], DNS over DTLS [RFC8094], DNS over HTTPS [RFC8484], with even more on the way.
UDPおよびTCPの両方にわたるDNSは同じ基礎となるメッセージフォーマットを使用するので、他方の一方のトランスポートの使用はメッセージコンテンツのプライバシー特性を変更しない（すなわち、照会されている名前）。最近、DNSを含むDNSプライバシーを提供するために最近、DNSプライバシーを提供し、DNSのDNS、DTLS [RFC8094]、https [RFC8484]を介して提供されています。
Because TCP is somewhat more complex than UDP, some characteristics of a TCP conversation may enable DNS client fingerprinting and tracking that is not possible with UDP. For example, the choice of initial sequence numbers, window size, and options might be able to identify a particular TCP implementation or even individual hosts behind shared resources such as NATs.
TCPはUDPよりもやや複雑であるため、TCP会話のいくつかの特性は、UDPで不可能なDNSクライアントの指紋処理と追跡を可能にします。たとえば、初期シーケンス番号、ウィンドウサイズ、およびオプションの選択は、特定のTCP実装を識別できます。また、NATSなどの共有リソースの背後にある個々のホストでも識別できます。
[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>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.
[RFC2181] ELZ、R.およびR. BUSH、「DNS仕様への説明」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<https：//www.rfc-editor.org/info/rfc2181>。
[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>。
[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 - 実装要件上のDNS輸送」、RFC 7766、DOI 10.17487 / RFC7766、2016年3月、<https://www.rfc-editor.org/info/rfc7766>。
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <https://www.rfc-editor.org/info/rfc7828>.
[RFC7828] Wouters、P.、Cormy、J.、Dickinson、S.、およびR. Bellis、「EDNS-TCP-Keepalive EDNS0オプション」、RFC 7828、DOI 10.17487 / RFC7828、2016年4月、<https：//www.rfc-editor.org/info/rfc7828>。
[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）Cookie」、RFC 7873、DOI 10.17487 / RFC7873、2016年5月、<https：//www.rfc-editor.org/info/rfc7873>。
[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>。
[accept_filter] FreeBSD, "FreeBSD accept_filter(9)", June 2000, <https://www.freebsd.org/cgi/man.cgi?query=accept_filter>.
[accept_filter] FreeBSD、 "freebsd accept_filter（9）"、2000年6月、<https://www.freebsd.org/cgi/man.cgi?query=accept_filter>。
[APNIC] Huston, G., "DNS XL", October 2020, <https://labs.apnic.net/?p=1380>.
[APNIC] Huston、G.、 "DNS XL"、2020年10月、<https://labs.apnic.net/?p=1380>。
[AVOID_FRAGS] Fujiwara, K. and P. Vixie, "Fragmentation Avoidance in DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-avoid-fragmentation-06, 23 December 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-06>.
[避け_frags] Fujiwara、K.およびP.Vixie、「DNSの断片化回避」、進行中の作業、インターネットドラフト、ドラフト - IETF-DNSop-vide-fragmentation-06、<https：// DataTracker。ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-06>。
[BIND] Internet Systems Consortium, "BIND 9", <https://www.isc.org/bind/>.
[BIND]インターネットシステムコンソーシアム、「バインド9」、<https://www.isc.org/bind/>。
[CASTRO2010] Castro, S., Zhang, M., John, W., Wessels, D., and K. claffy, "Understanding and Preparing for DNS Evolution", DOI 10.1007/978-3-642-12365-8_1, April 2010, <https://doi.org/10.1007/978-3-642-12365-8_1>.
[Castro2010] Castro、S.、Zhang、M.、John、W.、Wessels、D.、K.Claffy、「DNS Evolutionのための理解と準備」、DOI 10.1007 / 978-3-642-12365-8_1、2010年4月、<https：//doi.org/10.1007/978-3-642-12365-8_1>。
[CHES94] Cheswick, W. and S. Bellovin, "Firewalls and Internet Security: Repelling the Wily Hacker", First Edition, 1994.
[Ches94]チェスウィック、W.およびS.Bellovin、「ファイアウォールとインターネットセキュリティ：Wily Hackerの忌避」、初版、1994年。
[CLOUDFLARE] Grant, D., "Economical With The Truth: Making DNSSEC Answers Cheap", June 2016, <https://blog.cloudflare.com/black-lies/>.
[CloudFlare] Grant、D.、「真実の経済的：DNSSECの答えをする：2016年6月、<https：//blog.cloudflare.com/black-lies/>。
[DAI21] Dai, T., Shulman, H., and M. Waidner, "DNS-over-TCP Considered Vulnerable", DOI 10.1145/3472305.3472884, July 2021, <https://doi.org/10.1145/3472305.3472884>.
[DAI21] DAI、T.、Shulman、H.、およびM.Waidner、「DNS-Over-TCPは、脆弱なTCPと見なされる」、DOI 10.1145 / 3472305.3472884、<https://doi.org/10.1145/3472305.3472884>。
[DESIGNTEAM] ICANN, "Root Zone KSK Rollover Plan", March 2016, <https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf>.
[DesignTeam] ICANN、「ルートゾーンKSKロールオーバープラン」、2016年3月、<https：//www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf>。
[DJBDNS] Bernstein, D., "When are TCP queries sent?", November 2002, <https://cr.yp.to/djbdns/tcp.html#why>.
[DJBDNS] Bernstein、D.、「TCPクエリはいつ送信されますか？」、2002年11月、<https：//cr.yp.to/djbdns/tcp.html#なぜ>。
[dnscap] DNS-OARC, "DNSCAP", February 2014, <https://www.dns-oarc.net/tools/dnscap>.
[DNScap] DNS-OARC、「DNScap」、2014年2月、<https：//www.dns-oarc.net/tools/dnscap>。
[dnstap] "dnstap", <https://dnstap.info>.
[DNSTAP] "dnstap"、<https://dnstap.info>。
[ECDSA] van Rijswijk-Deij, R., Sperotto, A., and A. Pras, "Making the Case for Elliptic Curves in DNSSEC", DOI 10.1145/2831347.2831350, October 2015, <https://dl.acm.org/doi/10.1145/2831347.2831350>.
[ECDSA] van Rijswijk-deij、R.、Sperotto、A.、A. PRA、「DNSSECの楕円曲線の場合は、2015年10月10日、<https：//dl.acm.org/doi/10.1145/2831347.2831350>。
[FLAGDAY2020] DNS Software and Service Providers, "DNS Flag Day 2020", October 2020, <https://dnsflagday.net/2020/>.
[Flafday2020] DNSソフトウェアおよびサービスプロバイダー、「DNS Flag Day 2020」、2020年10月、<https：//dnsflagday.net/2020/>。
[FRAG_POISON] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", May 2012, <https://arxiv.org/pdf/1205.4011.pdf>.
[Frag_Poison] Herzberg、A.およびH. Shulman、「断片化とみなす」、2012年5月、<https：//arxiv.org/pdf/1205.4011.pdf>。
[HUSTON] Huston, G., "Dealing with IPv6 fragmentation in the DNS", August 2017, <https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/>.
[Huston] Huston、G. 2017年8月、<https://blog.apnic.net/2017/08/22/2017/08/22/dealing-ipv6-fragmentation-dns/>。
[KSK_ROLLOVER_ARCHIVES] ICANN, "KSK Rollover List Archives", January 2019, <https://mm.icann.org/pipermail/ksk-rollover/2019-January/ date.html>.
[KSK_ROLOROVER_ARCIVES] ICANN、「KSKロールオーバーリストアーカイブ」、2019年1月、<https：//mm.icann.org/pipermail/ksk-rollover/2019-january/date.html>。
[LEWIS] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74, May 2017, <https://ripe74.ripe.net/presentations/25-RIPE74-lewis-submission.pdf>.
[ルイス] Lewis、E.、 "2017 DNSSEC KSKロールオーバー"、熟した74、ripe 74、<https：//ripe74.ripe.net/presentations/25-ripe74-alwis-submission.pdf>。
[libpcap] The Tcpdump Group, "Tcpdump and Libpcap", <https://www.tcpdump.org>.
[libpcap] tcpdumpグループ "tcpdumpとlibpcap"、<https://www.tcpdump.org>。
[NETALYZR] Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, "Netalyzr: Illuminating The Edge Network", DOI 10.1145/1879141.1879173, November 2010, <https://doi.org/10.1145/1879141.1879173>.
[Netalyzr] Kreibich、C.、Weaver、N.、Nechaev、B.、およびV.Paxson、「Netalyzr：エッジネットワークを照らす」、DOI 10.1145 / 1879141.1879173、2010年11月、<https：//doi.org/10.1145/ 1879141.1879173>。
[phrack] horizon, "Defeating Sniffers and Intrusion Detection Systems", Phrack Magazine, December 1998, <http://phrack.org/issues/54/10.html>.
[Phrack] Horizo n、「スニファーと侵入検知システムを破る」、Phrack Magazine、1998年12月、<http://phrack.org/issues/54/10.html>。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] Postel、J.、 "User Datagram Protocol"、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https：//www.rfc-editor.org/info/rfc793>。
[RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983, <https://www.rfc-editor.org/info/rfc883>.
[RFC0883] Mockapetris、P.、 "ドメイン名：実装仕様"、RFC 883、DOI 10.17487 / RFC0883、1983年11月、<https://www.rfc-editor.org/info/rfc883>。
[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>。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1123] Braden、R.、Ed。、「インターネットホストの要求 - アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<https：//www.rfc-editor.org/info/ RFC1123>。
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, <https://www.rfc-editor.org/info/rfc1536>.
[RFC1536] Kumar、A.、Postel、J.、Neuman、C.、Danzig、P.、S. Miller、「一般的なDNS実装エラーと提案された修正」、RFC 1536、DOI 10.17487 / RFC1536、1993年10月、<https://www.rfc-editor.org/info/rfc1536>。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, <https://www.rfc-editor.org/info/rfc1995>.
[RFC1995] ohta、M。、「DNSのインクリメンタルゾーン転送」、RFC 1995、DOI 10.17487 / RFC1995、1996年8月、<https://www.rfc-editor.org/info/rfc1995>。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC1996] Vixie、P.、「ゾーン変更の迅速な通知（DNS通知）」、RFC 1996、DOI 10.17487 / RFC1996、1996年8月、<https://www.rfc-editor.org/info/rfc1996>。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、ED。、Thomson、S.、Rekhter、Y.、およびJ.Bound、「ドメイン名システム（DNSアップデート）の「動的更新」、RFC 2136、DOI 10.17487 / RFC2136、1997年4月<https：//www.rfc-editor.org/info/rfc2136>。
[RFC2541] Eastlake 3rd, D., "DNS Security Operational Considerations", RFC 2541, DOI 10.17487/RFC2541, March 1999, <https://www.rfc-editor.org/info/rfc2541>.
[RFC2541]イーストレイク3RD、D.、「DNSセキュリティ運用上の考慮事項」、RFC 2541、DOI 10.17487 / RFC2541、1999年3月、<https：//www.rfc-editor.org/info/rfc2541>。
[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>。
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September 1999, <https://www.rfc-editor.org/info/rfc2694>.
[RFC2694] SRISERSH、P.、TSIRTSIS、G.、Akkiraju、P.、およびA. HEFFERNAN、「ネットワークアドレストランスレータへのDNS拡張（DNS_ALG）」、RFC 2694、DOI 10.17487 / RFC2694、1999年9月、<https：//www.rfc-editor.org/info/rfc2694>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.
[RFC3022] SRISURESH、P.およびK。EGEVANG、「伝統的なIPネットワークアドレス翻訳者（伝統的なNAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<https：//www.rfc-editor.org/info/RFC3022>。
[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>。
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, DOI 10.17487/RFC3226, December 2001, <https://www.rfc-editor.org/info/rfc3226>.
[RFC3226] Gudmundsson、O.、 "DNSSECおよびIPv6 A6 Aware Server / Resolverメッセージサイズ要件"、RFC 3226、DOI 10.17487 / RFC3226、2001年12月、<https：//www.rfc-editor.org/info/rfc3226>。
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006, <https://www.rfc-editor.org/info/rfc4472>.
[RFC4472] Durand、A.、Ihren、J.、およびP.Savola、「IPv6 DNSの運用上の考慮事項および問題」、RFC 4472、DOI 10.17487 / RFC4472、2006年4月、<https：//www.rfc-編集者。ORG / INFO / RFC4472>。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, <https://www.rfc-editor.org/info/rfc4953>.
[RFC4953] 2007年7月、<https://www.rfc-editor.org/info/rfc4953、<https://www.rfc- editor.org/info/rfc4953、<https://www.rfc-editor.org/info/rfc4953>。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.
[RFC4987] EDDY、W。、「TCP SYNフラッディング攻撃および共通の軽減」、RFC 4987、DOI 10.17487 / RFC4987、2007年8月、<https：//www.rfc-editor.org/info/rfc4987>。
[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.F.Neves、「リフレクター攻撃における再帰ネームサーバーの使用の予防」、BCP 140、RFC 5358、DOI 10.17487 / RFC5358、2008年10月、<https：//www.rfc-editor.org/情報/ RFC5358>。
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, <https://www.rfc-editor.org/info/rfc5452>.
[RFC5452] Hubert、A.およびR. van Mook、「鍛造回答に対してDNSを弾力をもとにするための対策」、RFC 5452、DOI 10.17487 / RFC 5452、2009年1月、<https：//www.rfc-editor.org/info/ RFC5452>。
[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., "Design Choices When Expanding the DNS", RFC 5507, DOI 10.17487/RFC5507, April 2009, <https://www.rfc-editor.org/info/rfc5507>.
[RFC5507] IAB、Faltstrom、P.、ED。、Austein、R.、Ed。、およびP。Koch、ED。、「DNSの拡大時の設計の選択」、RFC 5507、DOI 10.17487 / RFC5507、2009年4月、<https://www.rfc-editor.org/info/rfc5507>。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <https://www.rfc-editor.org/info/rfc5625>.
[RFC5625] Bellis、R.、 "DNSプロキシ実装ガイドライン"、BCP 152、RFC 5625、DOI 10.17487 / RFC5625、2009年8月、<https：//www.rfc-editor.org/info/rfc5625>。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-editor.org/info/rfc5927>.
[RFC5927] Gont、F。、「TCPに対するICMP攻撃」、RFC 5927、DOI 10.17487 / RFC5927、2010年7月、<https：//www.rfc-editor.org/info/rfc5927>。
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, <https://www.rfc-editor.org/info/rfc5936>.
[RFC5936] Lewis、E、A.ホエン、「DNSゾーン転送プロトコル（AXFR）」、RFC 5936、DOI 10.17487 / RFC5936、2010年6月、<https：//www.rfc-editor.org/info/ RFC5936>。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <https://www.rfc-editor.org/info/rfc5961>.
[RFC5961] Ramaiah、A.、Stewart、R.およびM. Dalal、「窓内攻撃へのTCPの堅牢性の向上」、RFC 5961、DOI 10.17487 / RFC5961、2010年8月、<https：///www.rfc-editor.org/info/rfc5961>。
[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation Requirements", RFC 5966, DOI 10.17487/RFC5966, August 2010, <https://www.rfc-editor.org/info/rfc5966>.
[RFC5966] Bellis、R.、 "DNS輸送 - 実装要件"、RFC 5966、DOI 10.17487 / RFC5966、2010年8月、<https：//www.rfc-editor.org/info/rfc5966>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J.、およびM.Sargent、「コンピューティングTCPの再送信タイマー」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：///www.rfc-editor.org/info/rfc6298>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S.およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https：//www.rfc-editor.org/info/rfc6762>。
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-editor.org/info/rfc6781>.
[RFC6781] Kolkman、O.、Mekking、W.、R.Gieben、「DNSSEC運用慣行、バージョン2」、RFC 6781、DOI 10.17487 / RFC6781、2012年12月、<https：//www.rfc-editor.org/ info / rfc6781>。
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, <https://www.rfc-editor.org/info/rfc6950>.
[RFC6950] Peterson、J.、Kolkman、O.、Tschofenig、H.、およびB. Aboba、RFC 6950、DOI 10.17487 / RFC6950、2013年10月、<https：//www.rfc-editor.org/info/rfc6950>。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S.、A. Jain、 "TCP Fast Open"、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：///www.rfc-編集者.ORG / INFO / RFC7413>。
[RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", RFC 7477, DOI 10.17487/RFC7477, March 2015, <https://www.rfc-editor.org/info/rfc7477>.
[RFC7477]ハーメー、W、「DNSの子間同期」、RFC 7477、DOI 10.17487 / RFC7477、2015年3月、<https：//www.rfc-editor.org/info/rfc7477>。
[RFC7534] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations", RFC 7534, DOI 10.17487/RFC7534, May 2015, <https://www.rfc-editor.org/info/rfc7534>.
[RFC7534]能力、J.およびW.Sotomayor、 "AS112ネームサーバー操作"、RFC 7534、DOI 10.17487 / RFC7534、2015年5月、<https：//www.rfc-editor.org/info/rfc7534>。
[RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service Protocol and Deployment Requirements", BCP 40, RFC 7720, DOI 10.17487/RFC7720, December 2015, <https://www.rfc-editor.org/info/rfc7720>.
[RFC7720]ブランチェット、M.およびL-j。LIMAN、「DNSルートネームサービスプロトコルと展開要件」、BCP 40、RFC 7720、DOI 10.17487 / RFC7720、2015年12月、<https：//www.rfc-editor.org/info/rfc7720>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] HU、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D.、およびP.HOFFMAN、「トランスポート層セキュリティ（TLS）のDNSの仕様、RFC 7858、DOI10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, DOI 10.17487/RFC7901, June 2016, <https://www.rfc-editor.org/info/rfc7901>.
[RFC7901] Wouters、P.、DNSの「チェーンクエリ要求」、RFC 7901、DOI 10.17487 / RFC7901、2016年6月、<https：//www.rfc-editor.org/info/rfc7901>。
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <https://www.rfc-editor.org/info/rfc7918>.
[RFC7918] Langley、A。、Modadugu、N.、B. Moeller、「トランスポート層セキュリティ（TLS）偽のスタート」、RFC 7918、DOI 10.17487 / RFC7918、2016年8月、<https：//www.rfc-編集者.org / info / rfc7918>。
[RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, DOI 10.17487/RFC8027, November 2016, <https://www.rfc-editor.org/info/rfc8027>.
[RFC8027]ハーメー、W.、Gudmundsson、O.、およびS.Krishnaswamy、「DNSSEC Roadblock Dreavance」、BCP 207、RFC 8027、DOI 10.17487 / RFC8027、2016年11月、<https：//www.rfc-editor.org/ info / rfc8027>。
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.
[RFC8094] Reddy、T.、Wing、D.、およびP.Atil、「DNS overデータグラムトランスポート層セキュリティ（DNS）、RFC 8094、DOI 10.17487 / RFC8094、2017年2月、<https：///www.rfc-editor.org/info/rfc8094>。
[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/info/rfc8162>.
[RFC8162] HOFFMAN、P.およびJ.Schlyter、「S / MIMEのドメイン名と証明書を関連付けるためのセキュアDNSの使用」、RFC 8162、DOI 10.17487 / RFC8162、2017年5月、<https：//www.rfc-editor。ORG / INFO / RFC8162>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] The's、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
[RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?", RFC 8324, DOI 10.17487/RFC8324, February 2018, <https://www.rfc-editor.org/info/rfc8324>.
[RFC8324] Klensin、J.、 "DNSのプライバシー、承認、特別な用途、エンコーディング、文字、マッチング、およびルート構造：別の外観のための時間：2018年2月、2018年2月、2018年2月、<https：//www.rfc-editor.org/info/rfc8324>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, October 2018, <https://www.rfc-editor.org/info/rfc8467>.
[RFC8467] MayRhofer、A.「DNSの拡張メカニズム（EDNS（0））のパディングポリシー、RFC 8467、DOI 10.17487 / RFC8467、2018年10月、<https：//www.rfc-editor.org/info/RFC8467>。
[RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 2019, <https://www.rfc-editor.org/info/rfc8482>.
[RFC8482]、J.、Gudmundsson、O.、Majkowski、M.、およびE. Hunt、「Qtype = Any」、RFC 8482、DOI 10.17487 / RFC8482、2019年1月、<https://www.rfc-editor.org/info/rfc8482>。
[RFC8483] Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr, "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483, October 2018, <https://www.rfc-editor.org/info/rfc8483>.
[RFC8483] Song、L.、Ed。、Liu、D.、Vixie、P.、Katro、A.、およびS。Kerr、 "Yeti DNS Testbed"、RFC 8483、DOI 10.17487 / RFC8483、2018年10月、<HTTPS//www.rfc-editor.org/info/rfc8483>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] Hoffman、P.およびP.Mcmanus、「DNS over HTTPS（DOH）」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https：//www.rfc-editor.org/info/rfc8484>。
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Lemon, T., and T. Pusateri, "DNS Stateful Operations", RFC 8490, DOI 10.17487/RFC8490, March 2019, <https://www.rfc-editor.org/info/rfc8490>.
[RFC8490] Bellis、R.、Cheshire、S.、Dickinson、J.、Dickinson、S.、Lemon、T.、およびT.Pusateri、「DNSステートフルオペレーションズ」、RFC 8490、DOI 10.17487 / RFC8490、2019年3月、<https://www.rfc-editor.org/info/rfc8490>。
[RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, <https://www.rfc-editor.org/info/rfc8501>.
[RFC8501]ハワード、L.、「インターネットサービスプロバイダのIPv6の逆DNS」、RFC 8501、DOI 10.17487 / RFC8501、2018年11月、<https：//www.rfc-editor.org/info/rfc8501>。
[RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, <https://www.rfc-editor.org/info/rfc8806>.
[RFC8806] kumari、W.およびP.Hoffman、 "リゾルバのローカルのルートサーバーの実行"、RFC 8806、DOI 10.17487 / RFC8806、2020年6月、<https://www.rfc-editor.org/info/rfc8806>。
[RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem in DNS Servers: Failure to Communicate", BCP 231, RFC 8906, DOI 10.17487/RFC8906, September 2020, <https://www.rfc-editor.org/info/rfc8906>.
[RFC8906] Andrews、M.およびR. Bellis、「DNSサーバにおける一般的な運用上の問題：コミュニケーションの失敗」、BCP 231、RFC 8906、DOI 10.17487 / RFC8906、2020年9月、<https：//www.rfc-編集者.org / info / rfc8906>。
[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and A. Mankin, "Recommendations for DNS Privacy Service Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, October 2020, <https://www.rfc-editor.org/info/rfc8932>.
[RFC8932]ディッキンソン、S.、Overeinder、B.、Van Rijswijk-Deij、R.、A. Mankin、「DNSプライバシーサービスオペレータのための推奨事項」、BCP 232、RFC 8932、DOI 10.17487 / RFC8932、2020年10月、<https://www.rfc-editor.org/info/rfc8932>。
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, November 2020, <https://www.rfc-editor.org/info/rfc8945>.
[RFC8945] DuPont、F.、Morris、S.、Vixie、P.、EastLake 3RD、D.、Gudmundsson、O.、B.Welienmton、「DNS（TSIG）の秘密鍵取引認証」、STD 93、RFC8945、DOI 10.17487 / RFC8945、2020年11月、<https：//www.rfc-editor.org/info/rfc8945>。
[ROLL_YOUR_ROOT] Müller, M., Thomas, M., Wessels, D., Hardaker, W., Chung, T., Toorop, W., and R. van Rijswijk-Deij, "Roll, Roll, Roll Your Root: A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover", DOI 10.1145/3355369.3355570, October 2019, <https://dl.acm.org/doi/10.1145/3355369.3355570>.
[Roll_Your_root]ミュラー、M.、Thomas、M.、Wessels、D.、Hardaker、W.、Chung、T.、Toorop、W.、R. van Rijswijk-Deij、Rol、Roll、Rovel Rool：2019年10月、<https：//dl.acm.org/doi/10.1145/3355369.33555770、<https://dl.acm.org/doi/10.1145/3355369.3355570>。
[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting (DNS RRL)", ISC-TN-2012-1-Draft1, April 2012.
[RRL] Vixie、P.およびV.Schryver、「DNS応答率制限（DNS RRL）」、ISC-TN-2012-1-Draft1、2012年4月1日。
[TDNS] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N. Somaiya, "Connection-Oriented DNS to Improve Privacy and Security", DOI 10.1109/SP.2015.18, May 2015, <https://doi.org/10.1109/SP.2015.18>.
[TDNS] Zhu、L.、Heidemann、J.、Wessels、D.、Mankin、A。、およびN. Somaiya、「プライバシーとセキュリティを向上させるための接続指向DN」、DOI 10.1109 / Sp.2015.18、2015.18、<https://doi.org/10.1109/SP.2015.18>。
[TOYAMA] Toyama, K., Ishibashi, K., Toyono, T., Ishino, M., Yoshimura, C., and K. Fujiwara, "DNS Anomalies and Their Impacts on DNS Cache Servers", NANOG 32, October 2004.
[富山]富山、K.、石橋、K。、豊野、T.、石野、M.、Yoshimura、C.、K.藤原、「DNSの異常とそのDNSキャッシュサーバーへの影響」、Nanog 32、2004年10月。
[VERISIGN] Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in Root Server DITL Data", DNS-OARC 2014 Fall Workshop, October 2014.
[Verisign] Thomas、M.およびD.ウェース、「ルートサーバーDITLデータのTCPトラフィックの分析」、DNS-OARC 2014秋ワークショップ、2014年10月。
[WIKIPEDIA_TFO] Wikipedia, "TCP Fast Open", February 2022, <https://en.wikipedia.org/w/ index.php?title=TCP_Fast_Open&oldid=1071397204>.
[Wikipedia_TFO]ウィキペディア、「TCP Fast Open」、2022年2月、<https：//en.wikipedia.org/w/ index.php？title = tcp_fast_open＆oldid = 1071397204>。
This section enumerates all known RFCs with a status of Internet Standard, Proposed Standard, Informational, Best Current Practice, or Experimental that either implicitly or explicitly make assumptions or statements about the use of TCP as a transport for the DNS germane to this document.
このセクションでは、この文書へのDNS GermaneのトランスポートとしてのTCPの使用に関するTCPの使用に関するTCPの使用に関する仮定または明示的に仮定または明示的に仮定または明示的に仮定すること、または明示的に仮定または明示的に仮定すること、または明示的に仮定または明示的に仮定すること、または明示的に、この文書へのTCPの使用に関する仮定または明示的に仮定または明示的に仮定をする、または実験を行うすべての既知のRFCを列挙します。
The Internet Standard [RFC1035] is the base DNS specification that explicitly defines support for DNS over TCP.
インターネット標準[RFC1035]は、TCPを介したDNSのサポートを明示的に定義する基本DNS仕様です。
The Informational document [RFC1536] states that UDP is "the chosen protocol for communication though TCP is used for zone transfers." That statement should now be considered in its historical context and is no longer a proper reflection of modern expectations.
情報文書[RFC1536]は、UDPが「ゾーン転送に使用されているが、通信のための選択されたプロトコル」であると述べている。その声明はその歴史的な文脈で考慮されるべきであり、もはや現代の期待の適切な反映ではありません。
The Proposed Standard [RFC1995] documents the use of TCP as the fallback transport when Incremental Zone Transfer (IXFR) responses do not fit into a single UDP response. As with Authoritative Transfer (AXFR), IXFR messages are typically delivered over TCP by default in practice.
提案された標準[RFC1995]は、増分ゾーン転送（IXFR）応答が単一のUDP応答に適合しないときのフォールバックトランスポートとしてのTCPの使用を文書化しています。権威転送（AXFR）と同様に、IXFRメッセージは通常、実際にはTCPを介して配信されます。
A.4. RFC 1996 - A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
A.4. RFC 1996 - ゾーンの変更の迅速な通知のためのメカニズム（DNS Notify）
The Proposed Standard [RFC1996] suggests that a primary server may decide to issue NOTIFY messages over TCP. In practice, NOTIFY messages are generally sent over UDP, but this specification leaves open the possibility that the choice of transport protocol is up to the primary server; therefore, a secondary server ought to be able to operate over both UDP and TCP.
提案された標準[RFC1996]は、プライマリサーバがTCPを介して通知メッセージを発行することを決定することができることを示唆しています。実際には、通知メッセージは一般的にUDPを介して送信されますが、この仕様の葉はトランスポートプロトコルの選択がプライマリサーバまで開いている可能性を開きます。したがって、セカンダリサーバはUDPとTCPの両方を介して動作することができるべきである。
The Proposed Standard [RFC2181] includes clarifying text on how a client should react to the TC bit set on responses. It is advised that the response be discarded and the query resent using TCP.
提案された標準[RFC2181]は、クライアントが応答に設定されたTCビットにどのように反応するかについてのテキストを明確にすることを含む。応答が破棄され、クエリがTCPを使用して再実行されることをお勧めします。
The Informational document [RFC2694] enumerates considerations for NAT devices to properly handle DNS traffic. This document is noteworthy in its suggestion that "[t]ypically, TCP is used for AXFR requests," as further evidence that helps explain why DNS over TCP may have often been treated very differently than DNS over UDP in operational networks.
情報文書[RFC2694]は、DNSトラフィックを適切に処理するためのNATデバイスの考慮事項を列挙します。この文書は、「[t] yply、TCPがAXFR要求に使用されているという提案では、「TCPはAXFR要求に使用されています」と、TCPを介したDNSが稼働中の企業のUDPよりもDNSよりも非常に異なる場合が考えられる可能性があるということです。
The Proposed Standard [RFC3225] makes statements indicating that DNS over TCP is "detrimental" as a result of increased traffic, latency, and server load. This document is a companion to the next document in the RFC Series that describes the requirement for EDNS(0) support for DNSSEC.
提案された標準[RFC3225]は、トラフィック、待ち時間、およびサーバーの負荷が増加した結果として、TCPを介したDNSが「有害な」であることを示すステートメントを示しています。このドキュメントは、DNSSECのEDNS（0）サポートの要件を記述するRFCシリーズの次の文書のコンパニオンです。
A.8. RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver message size requirements
A.8. RFC 3226 - DNSSECとIPv6 A6 AWARAWAREサーバ/リゾルバメッセージサイズ要件
Although updated by later DNSSEC RFCs, the Proposed Standard [RFC3226] strongly argues in favor of UDP messages instead of TCP, largely for performance reasons. The document declares EDNS(0) a requirement for DNSSEC servers and advocates that packet fragmentation may be preferable to TCP in certain situations.
後のDNSSEC RFCによって更新されましたが、提案された標準[RFC3226]は、パフォーマンス上の理由から、TCPの代わりにUDPメッセージを支持して強く主張します。この文書は、EDNS（0）をDNSSECサーバーの要件を宣言し、パケットの断片化が特定の状況でTCPよりも好ましい場合があると宣言します。
The Informational document [RFC4472] notes that IPv6 data may increase DNS responses beyond what would fit in a UDP message. What is particularly noteworthy, but perhaps less common today than when this document was written, is that it refers to implementations that truncate data without setting the TC bit to encourage the client to resend the query using TCP.
情報文書[RFC4472]は、IPv6データがUDPメッセージに収まるものを超えてDNS応答を増加させる可能性があることに注意してください。特に注目に値するのは、この文書が書かれたときよりも今日の一般的な一般的な一般的なものではありませんが、TCPを使用してクエリを再送信するようにクライアントを促すためにTCビットを設定せずにデータを切り捨てる実装を指すことです。
A.10. RFC 5452 - Measures for Making DNS More Resilient against Forged Answers
A.10. RFC 5452 - 鍛造回答に対してDNSをより回復力にするための対策
The Proposed Standard [RFC5452] arose as public DNS systems began to experience widespread abuse from spoofed queries, resulting in amplification and reflection attacks against unwitting victims. One of the leading justifications for supporting DNS over TCP to thwart these attacks is briefly described in Section 9.3 of [RFC5452] ("Spoof Detection and Countermeasure").
提案された標準[RFC5452]は、公共のDNSシステムが偽装されたクエリから広範囲の虐待を経験し始め、その結果、拒否されていない犠牲者に対する増幅および反射攻撃が可能になりました。TCPを介したDNSを支援するための主要な正当化の1つは、これらの攻撃を妨害した。
The Informational document [RFC5507] was largely an attempt to dissuade new DNS data types from overloading the TXT resource record type. In so doing, it summarizes the conventional wisdom of DNS design and implementation practices. The authors suggest TCP overhead and stateful properties pose challenges compared to UDP and imply that UDP is generally preferred for performance and robustness.
情報文書[RFC5507]は、TXTリソースレコードタイプのオーバーロードから新しいDNSデータ型を解読しようとしていました。そうすることで、それはDNS設計と実装慣行の従来の知恵を要約しています。著者らは、TCPのオーバーヘッドとステートフルな特性をUDPと比較して課題と比較して課題を提案し、UDPが一般に性能と堅牢性に好ましいことを意味します。
The Best Current Practice document [RFC5625] provides DNS proxy implementation guidance including the mandate that a proxy "MUST [...] be prepared to receive and forward queries over TCP" even though it suggests that, historically, TCP transport has not been strictly mandatory in stub resolvers or recursive servers.
最良の現在の練習文書[RFC5625]は、歴史的にTCPトランスポートが厳しくないことを示唆していても、プロキシ「...はTCPを介してクエリを受信して転送する準備」を含むDNSプロキシ実装ガイダンスを提供します。スタブリゾルバまたは再帰サーバーで必須です。
The Proposed Standard [RFC5936] provides a detailed specification for the zone transfer protocol, as originally outlined in the early DNS standards. AXFR operation is limited to TCP and not specified for UDP. This document discusses TCP usage at length.
提案された標準[RFC5936]は、当初の初期のDNS規格で概説されているように、ゾーン転送プロトコルの詳細な仕様を提供します。AXFR動作はTCPに制限され、UDPには指定されていません。この文書では、TCPの使用法が長さです。
The Informational document [RFC7534] enumerates the requirements for operation of AS112 project DNS servers. New AS112 nodes are tested for their ability to provide service on both UDP and TCP transports, with the implication that TCP service is an expected part of normal operations.
情報文書[RFC7534]は、AS112 Project DNSサーバーの操作の要件を列挙します。新しいAS112ノードは、UDPトランスポートとTCPトランスポートの両方にサービスを提供する能力についてテストされ、TCPサービスが通常の操作の期待される部分であることを意味します。
In the Proposed Standard [RFC6762], the TC bit is deemed to have essentially the same meaning as described in the original DNS specifications. That is, if a response with the TC bit set is received, "[...] the querier SHOULD reissue its query using TCP in order to receive the larger response."
提案された標準[RFC6762]では、TCビットは元のDNS仕様に記載されていると本質的に同じ意味を有すると見なされる。すなわち、TCビットセットによる応答が受信された場合、「[...]は、より大きな応答を受けるためにTCPを使用してクエリを再発行する必要があります。」
The Internet Standard [RFC6891] helped slow the use of and need for DNS-over-TCP messages. This document highlights concerns over server load and scalability in widespread use of DNS over TCP.
インターネット標準[RFC6891]は、DNS-Over-TCPメッセージの使用と必要性を遅くしました。この文書は、TCPを介したDNSの広範な使用におけるサーバーの負荷とスケーラビリティに関する懸念を示しています。
A.17. IAB RFC 6950 - Architectural Considerations on Application Features in the DNS
A.17. IAB RFC 6950 - DNSにおけるアプリケーション機能に関するアーキテクチャの考慮事項
The Informational document [RFC6950] draws attention to large data in the DNS. TCP is referenced in the context as a common fallback mechanism and counter to some spoofing attacks.
情報文書[RFC6950]は、DNS内の大きなデータに注意を描きます。TCPは、コンテキストで、一般的なフォールバックメカニズムとして参照されており、スプーフィング攻撃に対抗します。
The Proposed Standard [RFC7477] specifies an RRType and a protocol to signal and synchronize NS, A, and AAAA resource record changes from a child-to-parent zone. Since this protocol may require multiple requests and responses, it recommends utilizing DNS over TCP to ensure the conversation takes place between a consistent pair of end nodes.
提案された標準[RFC7477]は、LRTypeとNS、A、およびAAAAリソースレコードの変更を子間ゾーンから変更し、同期させるプロトコルを指定します。このプロトコルは複数の要求と応答を必要とする可能性があるため、会話が一貫したエンドノードの間で行われるように、TCPを介してDNSを利用することをお勧めします。
A.19. RFC 7720 - DNS Root Name Service Protocol and Deployment Requirements
A.19. RFC 7720 - DNSルートネームサービスプロトコルと展開要件
The Best Current Practice document [RFC7720] declares that root name service "MUST support UDP [RFC0768] and TCP [RFC0793] transport of DNS queries and responses."
最良の現在の練習文書[RFC7720]は、ルートネームサービス「UDP [RFC0768]とDNSクエリと応答のTCP [RFC0793]のトランスポートをサポートする必要があります。
The Proposed Standard [RFC7766] instructs DNS implementors to provide support for carrying DNS-over-TCP messages in their software and might be considered the direct ancestor of this operational requirements document. The implementation requirements document codifies mandatory support for DNS-over-TCP in compliant DNS software but makes no recommendations to operators, which we seek to address here.
提案された標準[RFC7766]は、DNS実装者に、DNS-Over-TCPメッセージを自分のソフトウェアで伝送するためのサポートを提供し、この運用要件文書の直接祖先と見なされる可能性があります。実装要件文書は、準拠DNSソフトウェアでのDNS-over-TCPの必須サポートをコード化しますが、ここでアドレスを求める演算子に推奨されません。
The Proposed Standard [RFC7828] defines an EDNS(0) option to negotiate an idle timeout value for long-lived DNS-over-TCP connections. Consequently, this document is only applicable and relevant to DNS-over-TCP sessions and between implementations that support this option.
提案された標準[RFC7828]は、長寿命のDNS-Over-TCP接続のアイドルタイムアウト値をネゴシエートするためのEDNS（0）オプションを定義します。その結果、この文書は、DNS-Over-TCPセッションとこのオプションをサポートする実装間にのみ適用されます。
A.22. RFC 7858 - Specification for DNS over Transport Layer Security (TLS)
A.22. RFC 7858 - トランスポート層のセキュリティ（TLS）に対するDNSの指定
The Proposed Standard [RFC7858] defines a method for putting DNS messages into a TCP-based encrypted channel using TLS. This specification is noteworthy for explicitly targeting the stub-to-recursive traffic but does not preclude its application from recursive-to-authoritative traffic.
提案された標準[RFC7858]は、TLSを使用してDNSメッセージをTCPベースの暗号化チャネルに入れるための方法を定義します。この仕様は、スタブから再帰的なトラフィックを明示的にターゲティングするのに注目に値するが、そのアプリケーションを再帰的に信頼できるトラフィックから排除しない。
The Proposed Standard [RFC7873] describes an EDNS(0) option to provide additional protection against query and answer forgery. This specification mentions DNS over TCP as an alternative mechanism when DNS cookies are not available. The specification does make mention of DNS-over-TCP processing in two specific situations. In one, when a server receives only a client cookie in a request, the server should consider whether the request arrived over TCP, and if so, it should consider accepting TCP as sufficient to authenticate the request and respond accordingly. In another, when a client receives a BADCOOKIE reply using a fresh server cookie, the client should retry using TCP as the transport.
提案された標準[RFC7873]は、クエリと答えの偽造に対する追加の保護を提供するためのEDNS（0）オプションを記述します。この仕様は、DNS Cookieが利用できない場合の代替メカニズムとしてTCPを介してDNSを示しています。仕様は、2つの特定の状況でDNS-Over-TCP処理について言及しています。1つでは、サーバーが要求でクライアントクッキーのみを受信すると、サーバーは要求がTCPを介して到着したかどうかを検討する必要があります。そうすれば、リクエストを認証して応答するのに十分なTCPを受け入れることを検討する必要があります。別のものでは、クライアントがフレッシュサーバーCookieを使用してBadCookieの返信を受信すると、クライアントはTCPをトランスポートとして再試行する必要があります。
The Experimental specification [RFC7901] describes an EDNS(0) option that can be used by a security-aware validating resolver to request and obtain a complete DNSSEC validation path for any single query. This document requires the use of DNS over TCP or a transport mechanism verified by a source IP address such as EDNS-COOKIE [RFC7873].
実験的仕様[RFC7901]は、セキュリティ対応の検証リゾルバによって使用されるEDNS（0）オプションを、任意の単一のクエリのための完全なDNSSEC検証パスを要求して取得することによって使用できるようにします。この文書では、EDNS-Cookie [RFC7873]などの送信元IPアドレスによって検証されたTCPを介したDNSまたはトランスポートメカニズムを使用する必要があります。
The Best Current Practice document [RFC8027] details observed problems with DNSSEC deployment and mitigation techniques. Network traffic blocking and restrictions, including DNS-over-TCP messages, are highlighted as one reason for DNSSEC deployment issues. While this document suggests these sorts of problems are due to "non-compliant infrastructure", the scope of the document is limited to detection and mitigation techniques to avoid so-called DNSSEC roadblocks.
最良の現在の練習文書[RFC8027] DNSSEC展開と緩和技術に関する問題を見守った。DNS-over-TCPメッセージを含むネットワークトラフィックブロックと制限は、DNSSEC展開の問題の1つの理由として強調表示されています。この文書はこれらの種類の問題が「不適合なインフラストラクチャ」のためであることを示唆しているが、文書の範囲は、いわゆるDNSSEC障害を回避するための検出および緩和技術に限定される。
The Experimental specification [RFC8094] details a protocol that uses a datagram transport (UDP) but stipulates that "DNS clients and servers that implement DNS over DTLS MUST also implement DNS over TLS in order to provide privacy for clients that desire Strict Privacy [...]." This requirement implies DNS over TCP must be supported in case the message size is larger than the path MTU.
実験仕様[RFC8094]は、データグラムトランスポート（UDP）を使用するが、「DNSを介してDNSを実装するDNSクライアントとサーバも、厳格なプライバシーを希望するクライアシーを提供するためにDNSクライアントとサーバーも実装する必要があります..。]」メッセージサイズがパスMTUより大きい場合には、この要件はTCPを介してDNSをサポートする必要があります。
A.27. RFC 8162 - Using Secure DNS to Associate Certificates with Domain Names for S/MIME
A.27. RFC 8162 - SECURE DNSの使用証明書をS / MIMEのドメイン名に関連付ける
The Experimental specification [RFC8162] describes a technique to authenticate user X.509 certificates in an S/MIME system via the DNS. The document points out that the new experimental resource record types are expected to carry large payloads, resulting in the suggestion that "applications SHOULD use TCP -- not UDP -- to perform queries for the SMIMEA resource record."
実験仕様[RFC8162]は、DNSを介してS / MIMEシステム内のユーザーX.509証明書を認証するための技術を説明しています。この文書は、新しい実験リソースレコードタイプが大きなペイロードを持つことが期待されていることを指摘しており、「アプリケーションはTCP - Not UDPを使用してSMIMEAリソースレコードのクエリを実行するように使用する必要がある」と指摘しています。
A.28. RFC 8324 - DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?
A.28. RFC 8324 - DNSプライバシー、承認、特殊用途、エンコード、文字、マッチング、およびルート構造：別の外観の時間？
The Informational document [RFC8324] briefly discusses the common role and challenges of DNS over TCP throughout the history of DNS.
情報文書[RFC8324]は、DNSの履歴全体を通してTCPを介したDNSの共通の役割と課題について簡単に説明しています。
A.29. RFC 8467 - Padding Policies for Extension Mechanisms for DNS (EDNS(0))
A.29. RFC 8467 - DNSの拡張メカニズムのためのパディングポリシー（EDNS（0））
The Experimental document [RFC8467] reminds implementors to consider the underlying transport protocol (e.g., TCP) when calculating the padding length when artificially increasing the DNS message size with an EDNS(0) padding option.
実験文書[RFC8467]は、EDNS（0）パディングオプションを使用してDNSメッセージサイズを人為的に増やすときにパディング長を計算するときに、基礎となるトランスポートプロトコル（例えば、TCP）を検討するように実装者を思い出させます。
A.30. RFC 8482 - Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
A.30. RFC 8482 - qtype = anyを持つDNSクエリに対する最小サイズの応答を提供します。
The Proposed Standard [RFC8482] describes alternative ways that DNS servers can respond to queries of type ANY, which are sometimes used to provide amplification in DDoS attacks. The specification notes that responders may behave differently, depending on the transport. For example, minimal-sized responses may be used over UDP transport, while full responses may be given over TCP.
提案された標準[RFC8482]は、DNSサーバーがANYのクエリに応答できる代替方法を示し、これはDDOS攻撃での増幅を提供するために使用されることがあります。仕様は、トランスポートによっては応答者が異なる動作が悪くなる可能性があります。例えば、最小サイズの応答をUDP輸送に由来することができ、一方、完全な反応はTCPを介して与えられることがある。
The Informational document [RFC8483] describes a testbed environment that highlights some DNS-over-TCP behaviors, including issues involving packet fragmentation and operational requirements for TCP stream assembly in order to conduct DNS measurement and analysis.
情報文書[RFC8483]は、DNS測定と分析を行うために、パケットの断片化とTCPストリームアセンブリの運用要件を含む問題を含む、いくつかのDNS-over-TCPビヘイビアを強調するテストベッド環境を説明しています。
The Proposed Standard [RFC8484] defines a protocol for sending DNS queries and responses over HTTPS. This specification assumes TLS and TCP for the underlying security and transport layers, respectively. Self-described as a technique that more closely resembles a tunneling mechanism, DoH nevertheless likely implies DNS over TCP in some sense, if not directly.
提案された標準[RFC8484]は、httpsを介してDNSクエリと応答を送信するためのプロトコルを定義します。この仕様は、それぞれ基礎となるセキュリティ層およびトランスポート層のTLSおよびTCPを想定しています。それにもかかわらず、DOHは、直接的ではない場合は、ある意味でTCPを介してDNSを意味する可能性が高い。
The Proposed Standard [RFC8490] updates the base protocol specification with a new OPCODE to help manage stateful operations in persistent sessions, such as those that might be used by DNS over TCP.
提案された標準[RFC8490]は、TCPを介してDNSで使用される可能性があるものなど、永続的セッションでのステートフル操作を管理するのに役立つ、新しいオペコードを使用して基本プロトコルの仕様を更新します。
The Informational document [RFC8501] identifies potential operational challenges with dynamic DNS, including denial-of-service threats. The document suggests TCP may provide some advantages but that updating hosts would need to be explicitly configured to use TCP instead of UDP.
情報文書[RFC8501]は、サービス拒否の脅威を含む、動的DNSを備えた潜在的な運用上の課題を特定します。この文書はTCPがいくつかの利点を提供することを示唆しているが、更新ホストをUDPの代わりにTCPを使用するように明示的に構成される必要があることを提案する。
The Informational document [RFC8806] describes how to obtain and operate a local copy of the root zone with examples showing how to pull from authoritative sources using a DNS-over-TCP zone transfer.
情報文書[RFC8806]は、DNS-over-TCPゾーン転送を使用して権限のあるソースから引く方法を示す、ルートゾーンのローカルコピーを取得および操作する方法を説明します。
A.36. RFC 8906 - A Common Operational Problem in DNS Servers: Failure to Communicate
A.36. RFC 8906 - DNSサーバにおける一般的な動作上の問題：通信不能
The Best Current Practice document [RFC8906] discusses a number of DNS operational failure scenarios and how to avoid them. This includes discussions involving DNS-over-TCP queries, EDNS over TCP, and a testing methodology that includes a section on verifying DNS-over-TCP functionality.
最良の現在の練習文書[RFC8906]は、いくつかのDNS運用障害シナリオとそれらを回避する方法について説明します。これには、DNS-Over-TCPクエリ、TCPを介したEDNS、およびDNS-Over-TCP機能の検証に関するセクションを含むテスト方法論が含まれます。
The Best Current Practice document [RFC8932] presents privacy considerations to DNS privacy service operators. These mechanisms sometimes include the use of TCP and are therefore susceptible to information leakage such as TCP-based fingerprinting. This document also references an earlier draft version of this document.
最良の現在の練習文書[RFC8932]は、DNSプライバシーサービス事業者へのプライバシーに関する考慮事項を提示します。これらのメカニズムはTCPの使用を含むことがあり、したがってTCPベースのフィンガープリントのような情報漏洩の影響を受けやすい。この文書では、この文書の以前のドラフトバージョンを参照しています。
The Internet Standard [RFC8945] recommends that a client use TCP if truncated TSIG messages are received.
Truncated TSIGメッセージを受信した場合、クライアントがTCPを使用することをお勧めします。
Acknowledgments
謝辞
This document was initially motivated by feedback from students who pointed out that they were hearing contradictory information about filtering DNS-over-TCP messages. Thanks in particular to a teaching colleague, JPL, who perhaps unknowingly encouraged the initial research into the differences between what the community has historically said and did. Thanks to all the NANOG 63 attendees who provided feedback for an early talk on this subject.
この文書は、DNS-over-TCPメッセージのフィルタリングに関する矛盾する情報を聴覚していることを指摘した学生からのフィードバックによって最初に動機づけられました。特に教育の同僚に感謝しています。この主題に関する早期話のためのフィードバックを提供したすべてのNanog 63出席者のおかげで。
The following individuals provided an array of feedback to help improve this document: Joe Abley, Piet Barber, Sara Dickinson, Tony Finch, Bob Harold, Paul Hoffman, Geoff Huston, Tatuya Jinmei, Puneet Sood, and Richard Wilhelm. The authors are also indebted to the contributions stemming from discussion in the TCPM Working Group meeting at IETF 104. Any remaining errors or imperfections are the sole responsibility of the document authors.
次の個人は、この文書を改善するのに役立つフィードバックの配列を提供しました。著者らはまた、IETF 104でのTCPMワーキンググループ会議での議論から生じる貢献にも依存しています。残りのエラーや不完全性は、文書著者の唯一の責任です。
Authors' Addresses
著者の住所
John Kristoff
Dataplane.org
Chicago, IL 60605
United States of America
Phone: +1 312 493 0305
Email: jtk@dataplane.org
URI: https://dataplane.org/jtk/
Duane Wessels Verisign 12061 Bluemont Way Reston, VA 20190 United States of America Phone: +1 703 948 3200 Email: dwessels@verisign.com URI: https://verisign.com
Duane Wessels Verisign 12061 BlueMont Way Reston、VA 20190アメリカ合衆国電話：1 703 948 3200 Eメール：dwessels@verisign.com URI：https：//verisign.com