Internet Engineering Task Force (IETF) D. Wessels
Request for Comments: 9520 W. Carroll
Updates: 2308, 4035, 4697 M. Thomas
Category: Standards Track Verisign
ISSN: 2070-1721 December 2023
In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data, (2) a response indicating the requested data does not exist, or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type.
DNSでは、リゾルバーはキャッシュを使用して、エンドユーザーのレイテンシを減らし、権威ある名前サーバーにロードします。解像度のプロセスは、3つのタイプの応答のいずれかをもたらす場合があります。（1）要求されたデータを含む応答、（2）要求されたデータが存在しないことを示す応答、または（3）解像度の障害による非応答リゾルバーがデータの存在に関する有用な情報を受け取っていません。このドキュメントは、3番目のタイプのみに関係しています。
RFC 2308 specifies requirements for DNS negative caching. There, caching of TYPE 2 responses is mandatory and caching of TYPE 3 responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures.
RFC 2308は、DNSネガティブキャッシュの要件を指定します。そこで、タイプ2の応答のキャッシュが必須であり、タイプ3応答のキャッシュはオプションです。このドキュメントは、RFC 2308を更新して、DNS解像度の障害に負のキャッシュが必要です。
RFC 4035 allows DNSSEC validation failure caching. This document updates RFC 4035 to require caching for DNSSEC validation failures.
RFC 4035を使用すると、DNSSEC検証障害キャッシングが可能になります。このドキュメントは、RFC 4035を更新して、DNSSEC検証障害のキャッシュが必要です。
RFC 4697 prohibits aggressive requerying for NS records at a failed zone's parent zone. This document updates RFC 4697 to expand this requirement to all query types and to all ancestor zones.
RFC 4697は、失敗したゾーンの親ゾーンでのNSレコードの積極的な補充を禁止しています。このドキュメントは、RFC 4697を更新して、この要件をすべてのクエリタイプとすべての祖先ゾーンに拡張します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9520.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9520で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Motivation
1.2. Related Work
1.3. Terminology
2. Conditions That Lead to DNS Resolution Failures
2.1. SERVFAIL Responses
2.2. REFUSED Responses
2.3. Timeouts and Unreachable Servers
2.4. Delegation Loops
2.5. Alias Loops
2.6. DNSSEC Validation Failures
2.7. FORMERR Responses
3. Requirements for Caching DNS Resolution Failures
3.1. Retries and Timeouts
3.2. Caching
3.3. Requerying Delegation Information
3.4. DNSSEC Validation Failures
4. IANA Considerations
5. Security Considerations
6. Privacy Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
Caching has always been a fundamental component of DNS resolution on the Internet. For example, [RFC0882] states:
キャッシュは、常にインターネット上のDNS解像度の基本的な要素です。たとえば、[RFC0882]は次のように述べています。
The sheer size of the database and frequency of updates suggest that it must be maintained in a distributed manner, with local caching to improve performance.
データベースの膨大なサイズと更新の頻度は、パフォーマンスを改善するためにローカルキャッシュを使用して、分散方法で維持する必要があることを示唆しています。
The early DNS RFCs ([RFC0882], [RFC0883], [RFC1034], and [RFC1035]) primarily discuss caching in the context of what [RFC2308] calls "positive responses", that is, when the response includes the requested data. In this case, a TTL is associated with each Resource Record (RR) in the response. Resolvers can cache and reuse the data until the TTL expires.
初期のDNS RFCS（[RFC0882]、[RFC0883]、[RFC1034]、[RFC1035]）は、[RFC2308]が「肯定的な応答」と呼ぶコンテキストで主にキャッシュについて議論します。この場合、TTLは応答の各リソースレコード（RR）に関連付けられています。リゾルバーは、TTLの有効期限が切れるまでデータをキャッシュして再利用できます。
Section 4.3.4 of [RFC1034] describes negative response caching, but notes it is optional and only talks about name errors (NXDOMAIN). This is the origin of using the SOA MINIMUM field as a negative caching TTL.
[RFC1034]のセクション4.3.4では、負の応答キャッシングについて説明しますが、オプションであり、名前エラー（NXDomain）についてのみ語っています。これは、SOA最小フィールドを負のキャッシュTTLとして使用する起源です。
[RFC2308] updated [RFC1034] to specify new requirements for DNS negative caching, including making it mandatory for caching resolvers to cache name error (NXDOMAIN) and no data (NODATA) responses when an SOA record is available to provide a TTL. [RFC2308] further specified optional negative caching for two DNS resolution failure cases: server failure and dead/unreachable servers.
[RFC2308]は[RFC2034]を更新して、DNSネガティブキャッシュの新しい要件を指定しました。これには、TTLを提供するためにSOAレコードが利用できるSOAレコードが利用可能な場合、キャッシュリゾルバーが名前をキャッシュするためのキャッシュのキャッシュのキャッシュ（Nodata）応答を必須にすることが含まれます。[RFC2308] 2つのDNS解像度障害ケースのオプションのネガティブキャッシングをさらに指定しました：サーバー障害と死んだ/到達不可能なサーバー。
This document updates [RFC2308] to require negative caching of all DNS resolution failures and provides additional examples of resolution failures, [RFC4035] to require caching for DNSSEC validation failures, as well as [RFC4697] to expand the scope of prohibiting aggressive requerying for NS records at a failed zone's parent zone to all query types and to all ancestor zones.
このドキュメントは[RFC2308]を更新して、すべてのDNS解像度の障害の負のキャッシュを必要とし、解像度障害の追加の例を提供します[RFC4035]は、DNSSEC検証障害のキャッシュを必要とします。失敗したゾーンの親ゾーンで、すべてのクエリタイプとすべての祖先ゾーンに記録します。
Operators of DNS services have known for some time that recursive resolvers become more aggressive when they experience resolution failures. A number of different anecdotes, experiments, and incidents support this claim.
DNSサービスのオペレーターはしばらくの間、解像度の障害を経験すると再帰的なリゾルバーがより攻撃的になることが知られています。多くの異なる逸話、実験、および事件がこの主張を支持しています。
In December 2009, a secondary server for a number of in-addr.arpa subdomains saw its traffic suddenly double, and queries of type DNSKEY in particular increase by approximately two orders of magnitude, coinciding with a DNSSEC key rollover by the zone operator [DNSSEC-ROLLOVER]. This predated a signed root zone, and an operating system vendor was providing non-root trust anchors to the recursive resolver, which became out of date following the rollover. Unable to validate responses for the affected in-addr.arpa zones, recursive resolvers aggressively retried their queries.
2009年12月、多数のADDR.ARPAサブドメインのセカンダリサーバーでは、トラフィックが突然2倍になり、特にタイプDNSKEYのクエリは約2桁増加し、ゾーンオペレーターによるDNSSECキーロールオーバーと一致します[DNSSECECE-転がる]。これは署名されたルートゾーンであり、オペレーティングシステムベンダーは、ロールオーバー後に時代遅れになった再帰リゾルバーに非ルートトラストアンカーを提供していました。影響を受けるADDR.ARPAゾーンの応答を検証できないため、再帰的なリゾルバーはクエリを積極的に再試行しました。
In 2016, the Internet infrastructure company Dyn experienced a large attack that impacted many high-profile customers. As documented in a technical presentation detailing the attack (see [RETRY-STORM]), Dyn staff wrote:
2016年、インターネットインフラカンパニーDynは、多くの有名な顧客に影響を与える大きな攻撃を経験しました。攻撃を詳述した技術的なプレゼンテーションで文書化されているように（[Retry-Storm]を参照）、Dynのスタッフは次のように書いています。
At this point we are now experiencing botnet attack traffic and what is best classified as a "retry storm"
この時点で、私たちは現在、ボットネット攻撃トラフィックと「再試行嵐」として最適なものを経験しています
Looking at certain large recursive platforms > 10x normal volume
特定の大きな再帰プラットフォームを見て、通常のボリューム> 10倍
In 2018, the root zone Key Signing Key (KSK) was rolled over [KSK-ROLLOVER]. Throughout the rollover period, the root servers experienced a significant increase in DNSKEY queries. Before the rollover, a.root-servers.net and j.root-servers.net together received about 15 million DNSKEY queries per day. At the end of the revocation period, they received 1.2 billion per day: an 80x increase. Removal of the revoked key from the zone caused DNSKEY queries to drop to post-rollover but pre-revoke levels, indicating there is still a population of recursive resolvers using the previous root trust anchor and aggressively retrying DNSKEY queries.
2018年、ルートゾーンキーの署名キー（KSK）が[KSK-Rollover]を巻き込まれました。ロールオーバー期間中、ルートサーバーはDNSKEYクエリの大幅な増加を経験しました。ロールオーバーの前に、A.Root-Servers.netとJ.Root-Servers.netを一緒に受け取り、1日あたり約1500万件のDNSKEYクエリを受け取りました。取り消し期間の終わりに、彼らは1日あたり12億を受け取りました。これは80倍の増加です。ゾーンから取り消されたキーを削除すると、DNSKEYクエリは転倒後に低下しましたが、レボーク前のレベルになり、以前のルートトラストアンカーを使用して再帰的なリゾルバーの集団があり、DNSKEYクエリを積極的に再試行しています。
In 2021, Verisign researchers used botnet query traffic to demonstrate that certain large public recursive DNS services exhibit very high query rates when all authoritative name servers for a zone return refused (REFUSED) or server failure (SERVFAIL) responses (see [BOTNET]). When the authoritative servers were configured normally, query rates for a single botnet domain averaged approximately 50 queries per second. However, with the servers configured to return SERVFAIL, the query rate increased to 60,000 per second. Furthermore, increases were also observed at the root and Top-Level Domain (TLD) levels, even though delegations at those levels were unchanged and continued operating normally.
2021年、Verisignの研究者はBotnetクエリトラフィックを使用して、特定の大規模な公共の再帰DNSサービスが、ゾーンリターンのすべての信頼できる名前サーバーが拒否（拒否）またはサーバー障害（サーバー）応答（[botnetを参照））を示すことを実証しました。権威あるサーバーが正常に構成されている場合、単一のボットネットドメインのクエリレートの平均クエリは毎秒約50クエリでした。ただし、サーバーがServFailを返すように構成されている場合、クエリレートは1秒あたり60,000に増加しました。さらに、これらのレベルの代表団は変更されず、正常に動作し続けているにもかかわらず、ルートレベルおよびトップレベルのドメイン（TLD）レベルでも増加が観察されました。
Later that same year, on October 4, Facebook experienced a widespread and well-publicized outage [FB-OUTAGE]. During the 6-hour outage, none of Facebook's authoritative name servers were reachable and did not respond to queries. Recursive name servers attempting to resolve Facebook domains experienced timeouts. During this time, query traffic on the .COM/.NET infrastructure increased from 7,000 to 900,000 queries per second [OUTAGE-RESOLVER].
同じ年の後半、10月4日、Facebookは広く公表された停止[FBOUTAGE]を経験しました。6時間の停止中、Facebookの権威ある名前サーバーはどれも到達可能であり、クエリに応答しませんでした。Facebookドメインを解決しようとする再帰名サーバーは、タイムアウトを経験しています。この間、.com/.NETインフラストラクチャのクエリトラフィックは、秒あたり7,000から900,000のクエリに増加しました[停止リゾルバー]。
[RFC2308] describes negative caching for four types of DNS queries and responses: name errors, no data, server failures, and dead/ unreachable servers. It places the strongest requirements on negative caching for name errors and no data responses, while server failures and dead servers are left as optional.
[RFC2308]は、4種類のDNSクエリと応答のネガティブキャッシングを説明しています：名前エラー、データなし、サーバー障害、および死んだ/到達不可能なサーバー。ネームエラーとデータ応答のためのネガティブキャッシングに最も強い要件を置きますが、サーバーの障害とデッドサーバーはオプションとして残ります。
[RFC4697] is a Best Current Practice that documents observed resolution misbehaviors. It describes a number of situations that can lead to excessive queries from recursive resolvers, including requerying for delegation data, lame servers, responses blocked by firewalls, and records with zero TTL. [RFC4697] makes a number of recommendations, varying from "SHOULD" to "MUST".
[RFC4697]は、解像度の不正行為を観察された文書化された最良の現在の慣行です。委任データのリクエリ、ラメサーバー、ファイアウォールによってブロックされた応答、ゼロTTLのレコードなど、再帰的なリゾルバーからの過度のクエリにつながる可能性のある多くの状況について説明します。[RFC4697]は、「必要」から「必須」までさまざまな多くの推奨事項を作成します。
[THUNDERING-HERD] describes "The DNS thundering herd problem" as a situation arising when cached data expires at the same time for a large number of users. Although that document is not focused on negative caching, it does describe the benefits of combining multiple identical queries to upstream name servers. That is, when a recursive resolver receives multiple queries for the same name, class, and type that cannot be answered from cached data, it should combine or join them into a single upstream query rather than emit repeated identical upstream queries.
[Thundering-Herd]は、「DNS Thundering Herdの問題」を、キャッシュされたデータが同時に多くのユーザーにとって有効期限が切れると発生する状況として説明しています。そのドキュメントはネガティブキャッシュに焦点を合わせていませんが、複数の同一のクエリを上流の名前サーバーと組み合わせることの利点を説明しています。つまり、キャッシュデータから回答できない同じ名前、クラス、タイプの複数のクエリを再帰的なリゾルバーが受信する場合、繰り返される同一のアップストリームクエリを発するのではなく、それらを結合または単一のアップストリームクエリに結合または結合する必要があります。
[RFC5452], "Measures for Making DNS More Resilient against Forged Answers", includes a section that describes the phenomenon known as "Birthday Attacks". Here, again, the problem arises when a recursive resolver emits multiple identical upstream queries. Multiple outstanding queries make it easier for an attacker to guess and correctly match some of the DNS message parameters, such as the port number and ID field. This situation is further exacerbated in the case of timeout-based resolution failures. Of course, DNSSEC is a suitable defense to spoofing attacks.
[RFC5452]、「鍛造回答に対してDNSをより回復力を高めるための尺度」には、「誕生日攻撃」として知られる現象を説明するセクションが含まれています。ここでも、再帰的なリゾルバーが複数の同一の上流クエリを放出すると問題が発生します。複数の発行済みクエリにより、攻撃者がポート番号やIDフィールドなどのDNSメッセージパラメーターの一部を推測し、正しく一致させることが容易になります。この状況は、タイムアウトベースの解像度の障害の場合、さらに悪化しています。もちろん、DNSSECは攻撃をスプーフィングするのに適した防御です。
[RFC8767] describes "Serving Stale Data to Improve DNS Resiliency". This permits a recursive resolver to return possibly stale data when it is unable to refresh cached, expired data. It introduces the idea of a failure recheck timer and says:
[RFC8767]は、「DNS回復力を改善するための古いデータの提供」を説明しています。これにより、キャッシュされた期限切れのデータを更新できない場合、再帰的なリゾルバーが古いデータを返すことができます。失敗の再確認タイマーのアイデアを紹介し、次のように言います。
Attempts to refresh from non-responsive or otherwise failing authoritative nameservers are recommended to be done no more frequently than every 30 seconds.
非応答性または失敗した権威ある名前サーバーから更新しようとする試みは、30秒ごとに頻繁に行わないことをお勧めします。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
DNS transport:
DNS輸送：
In this document, "DNS transport" means a protocol used to transport DNS messages between a client and a server. This includes "classic DNS" transports, i.e., DNS-over-UDP and DNS-over-TCP [RFC1034] [RFC7766], as well as newer encrypted DNS transports, such as DNS-over-TLS [RFC7858], DNS-over-HTTPS [RFC8484], DNS-over-QUIC [RFC9250], and similar communication of DNS messages using other protocols. Note: at the time of writing, not all DNS transports are standardized for all types of servers but may become standardized in the future.
このドキュメントでは、「DNS Transport」とは、クライアントとサーバー間でDNSメッセージを輸送するために使用されるプロトコルを意味します。これには、「クラシックDNS」トランスポート、つまりDNS-Over-UDPおよびDNS-Over-TCP [RFC1034] [RFC7766]、およびDNS-over-TLS [RFC7858]、DNS-over-over-over-over-over-over-over-over-overなどの新しい暗号化されたDNSトランスポンドが含まれます。-HTTPS [RFC8484]、DNS-Over-Quic [RFC9250]、および他のプロトコルを使用したDNSメッセージの同様の通信。注：執筆時点では、すべてのDNSトランスポートがすべてのタイプのサーバーに対して標準化されているわけではありませんが、将来的に標準化される可能性があります。
A DNS resolution failure occurs when none of the servers available to a resolver client provide any useful response data for a particular query name, type, and class. A response is considered useful when it provides either the requested data, a referral to a descendant zone, or an indication that no data exists at the given name.
DNS解像度の障害は、リゾルバークライアントが利用できるサーバーが特定のクエリ名、タイプ、およびクラスの有用な応答データを提供しない場合に発生します。応答は、要求されたデータ、子孫ゾーンへの紹介、または指定された名前にデータが存在しないことを示している場合に有用であると見なされます。
It is common for resolvers to have multiple servers from which to choose for a particular query. For example, in the case of stub-to-recursive, the stub resolver may be configured with multiple recursive resolver addresses. In the case of recursive-to-authoritative, a given zone usually has more than one name server (NS record), each of which can have multiple IP addresses and multiple DNS transports.
リソースバーが特定のクエリ用に選択できる複数のサーバーを持つことが一般的です。たとえば、スタブツーリュール型の場合、スタブリゾルバーは、複数の再帰的なリゾルバーアドレスで構成される場合があります。再帰的から承認への場合、特定のゾーンには通常、複数の名前サーバー（NSレコード）があり、それぞれが複数のIPアドレスと複数のDNSトランスポートを持つことができます。
Nothing in this document prevents a resolver from retrying a query at a different server or the same server over a different DNS transport. In the case of timeouts, a resolver can retry the same server and DNS transport a limited number of times.
このドキュメントには、リゾルバーが異なるサーバーまたは同じサーバーで異なるDNSトランスポートを再試行することを妨げるものはありません。タイムアウトの場合、リゾルバーは同じサーバーを再試行し、DNSは限られた回数を輸送できます。
If any one of the available servers provides a useful response, then it is not considered a resolution failure. However, if none of the servers for a given query tuple <name, type, class> provide a useful response, the result is a resolution failure.
利用可能なサーバーのいずれかが有用な応答を提供する場合、解像度の障害とは見なされません。ただし、特定のクエリtuple <name、type、class>のサーバーが有用な応答を提供しない場合、結果は解像度障害です。
Note that NXDOMAIN and NOERROR/NODATA responses are not conditions for resolution failure. In these cases, the server is providing a useful response, indicating either that a name does not exist or that no data of the requested type exists at the name. These negative responses can be cached as described in [RFC2308].
NxDomainおよびNoError/Nodata応答は、解像度障害の条件ではないことに注意してください。これらの場合、サーバーは有用な応答を提供しており、名前が存在しないか、要求されたタイプのデータが名前に存在しないことを示しています。これらの負の反応は、[RFC2308]に記載されているようにキャッシュできます。
The remainder of this section describes a number of different conditions that can lead to resolution failure. This section is not exhaustive. Additional conditions may be expected to cause similar resolution failures.
このセクションの残りの部分では、解像度の障害につながる可能性のあるさまざまな条件について説明します。このセクションは網羅的ではありません。追加の条件は、同様の解像度の障害を引き起こすと予想される場合があります。
Server failure is defined in [RFC1035] as: "The name server was unable to process this query due to a problem with the name server." A server failure is signaled by setting the RCODE field to SERVFAIL.
サーバーの障害は、[RFC1035]で次のように定義されています。「名前サーバーの問題があるため、このクエリを処理できませんでした。」サーバーの障害は、Rcodeフィールドをサーブファイルに設定することにより信号を送ります。
Authoritative servers return SERVFAIL when they don't have any valid data for a zone. For example, a secondary server has been configured to serve a particular zone but is unable to retrieve or refresh the zone data from the primary server.
権威あるサーバーは、ゾーンの有効なデータがない場合にサーブファイルを返します。たとえば、特定のゾーンにサービスを提供するようにセカンダリサーバーが構成されていますが、プライマリサーバーからゾーンデータを取得または更新できません。
Recursive servers return SERVFAIL in response to a number of different conditions, including many described below.
再帰サーバーは、以下で説明する多くの条件を含む、さまざまな条件に応じてサーブファイルを返します。
Although the extended DNS errors method exists "primarily to extend SERVFAIL to provide additional information," it "does not change the processing of RCODEs" [RFC8914]. This document operates at the level of resolution failure and does not concern particular causes.
拡張されたDNSエラー法は「主にサーブファイルを拡張して追加情報を提供するために」存在しますが、それは「RCODESの処理を変更しません」[RFC8914]。このドキュメントは、解像度の障害のレベルで動作し、特定の原因に関するものではありません。
A name server returns a message with the RCODE field set to REFUSED when it refuses to process the query, e.g., for policy or other reasons [RFC1035].
名前サーバーは、ポリシーやその他の理由により、クエリの処理を拒否したときに拒否されるように設定されたRcodeフィールドでメッセージを返します[RFC1035]。
Authoritative servers generally return REFUSED when processing a query for which they are not authoritative. For example, a server that is configured to be authoritative for only the example.net zone may return REFUSED in response to a query for example.com.
権威あるサーバーは、一般に、権威者ではないクエリを処理するときに拒否されます。たとえば、example.netゾーンのみに対して権威あるように構成されているサーバーは、emply.comのクエリに応じて拒否されたことを返すことができます。
Recursive servers generally return REFUSED for query sources that do not match configured access control lists. For example, a server that is configured to allow queries from only 2001:db8:1::/48 may return REFUSED in response to a query from 2001:db8:5::1.
通常、再帰サーバーは、構成されたアクセス制御リストと一致しないクエリソースに対して拒否されました。たとえば、2001年のみのクエリを許可するように構成されているサーバー：db8：1 ::/48は、2001年からのクエリに応じて拒否されることができます：db8：5 :: 1。
A timeout occurs when a resolver fails to receive any response from a server within a reasonable amount of time. Additionally, a DNS transport may more quickly indicate lack of reachability in a way that wouldn't be considered a timeout: for example, an ICMP port unreachable message, a TCP "connection refused" error, or a TLS handshake failure. [RFC2308] refers to these conditions collectively as "dead / unreachable servers".
タイムアウトは、リゾルバーが合理的な時間内にサーバーから応答を受け取らなかったときに発生します。さらに、DNSトランスポートは、タイムアウトとは見なされない方法で到達可能性の欠如をより迅速に示している可能性があります。たとえば、ICMPポートの到達不可能なメッセージ、TCPの「接続が拒否された」エラー、またはTLSの握手障害。[RFC2308]は、これらの条件をまとめて「死んだ /到達不可能なサーバー」と呼びます。
Note that resolver implementations may have two types of timeouts: a smaller timeout that might trigger a query retry and a larger timeout after which the server is considered unresponsive. Section 3.1 discusses the requirements for resolvers when retrying queries.
Resolverの実装には、2種類のタイムアウトがある場合があることに注意してください。クエリの再試行をトリガーする可能性のある小さなタイムアウトと、サーバーが反応しないと見なされるより大きなタイムアウトです。セクション3.1では、クエリを再試行するときのリゾルバーの要件について説明します。
Timeouts can present a particular problem for negative caching, depending on how the resolver handles multiple outstanding queries for the same <query name, type, class> tuple. For example, consider a very popular website in a zone whose name servers are all unresponsive. A recursive resolver might receive tens or hundreds of queries per second for that website. If the recursive server implementation joins these outstanding queries together, then it only sends one recursive-to-authoritative query for the numerous pending stub-to-recursive queries. However, if the implementation does not join outstanding queries together, then it sends one recursive-to-authoritative query for each stub-to-recursive query. If the incoming query rate is high and the timeout is large, this might result in hundreds or thousands of recursive-to-authoritative queries while waiting for an authoritative server to time out.
タイムアウトは、同じ<クエリ名、タイプ、クラス>タプルの複数の未解決のクエリをリゾルバーがどのように処理するかに応じて、ネガティブキャッシングの特定の問題を提示できます。たとえば、名前サーバーがすべて反応しないゾーンに非常に人気のあるWebサイトを検討してください。再帰的なリゾルバーは、そのウェブサイトの数十秒または数百のクエリを受け取る場合があります。再帰的なサーバーの実装がこれらの未解決のクエリを結合する場合、それは多数の保留されているスタブから再帰的なクエリに対して1つの再帰的なクエリのみを送信します。ただし、実装が卓越したクエリを結合しない場合、各スタブから再回帰的クエリに対して1つの再帰的なクエリを送信します。着信クエリレートが高く、タイムアウトが大きい場合、これにより、権威あるサーバーがタイムアウトするのを待っている間に、数百または数千の再帰的なクエリが生じる可能性があります。
A recursive resolver that does not join outstanding queries together is more susceptible to Birthday Attacks ([RFC5452], Section 5), especially when those queries result in timeouts.
卓越したクエリを結合しない再帰的なリゾルバーは、特にそれらのクエリがタイムアウトにつながる場合、誕生日攻撃（[RFC5452]、セクション5）の影響を受けやすくなります。
A delegation loop, or cycle, can occur when one domain utilizes name servers in a second domain, and the second domain uses name servers in the first. For example:
委任ループ、またはサイクルは、1つのドメインが2番目のドメインで名前サーバーを使用し、2番目のドメインが最初のドメインでネームサーバーを使用すると発生する可能性があります。例えば：
FOO.EXAMPLE. NS NS1.EXAMPLE.COM.
FOO.EXAMPLE. NS NS2.EXAMPLE.COM.
EXAMPLE.COM. NS NS1.FOO.EXAMPLE.
EXAMPLE.COM. NS NS2.FOO.EXAMPLE.
In this example, no names under foo.example or example.com can be resolved because of the delegation loop. Note that a delegation loop may involve more than two domains. A resolver that does not detect delegation loops may generate DDoS-levels of attack traffic to authoritative name servers, as documented in the TsuNAME vulnerability [TsuNAME].
この例では、委任ループのために、foo.exampleまたはembler.comの下の名前は解決できません。委任ループには3つ以上のドメインが含まれる場合があることに注意してください。委任ループを検出しないリゾルバーは、Tsunameの脆弱性[Tsuname]に文書化されているように、権威ある名前サーバーへの攻撃トラフィックのDDOSレベルを生成する可能性があります。
An alias loop, or cycle, can occur when one CNAME or DNAME RR refers to a second name, which, in turn, is specified as an alias for the first. For example:
エイリアスループ、またはサイクルは、1つのCNAMEまたはDNAME RRが2番目の名前を参照している場合に発生します。これは、最初の名前のエイリアスとして指定されます。例えば：
APP.FOO.EXAMPLE. CNAME APP.EXAMPLE.NET.
APP.EXAMPLE.NET. CNAME APP.FOO.EXAMPLE.
The need to detect CNAME loops has been known since at least [RFC1034], which states in Section 3.6.2:
CNAMEループを検出する必要性は、セクション3.6.2に記載されている少なくとも[RFC1034]以来知られています。
Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error.
もちろん、堅牢性の原則により、CNAMEチェーンまたはループが表示された場合、ドメインソフトウェアが失敗しないでください。CNAMEチェーンに従って、cnameループをエラーとして信号します。
For zones that are signed with DNSSEC, a resolution failure can occur when a security-aware resolver believes it should be able to establish a chain of trust for an RRset but is unable to do so, possibly after trying multiple authoritative name servers. DNSSEC validation failures may be due to signature mismatch, missing DNSKEY RRs, problems with denial-of-existence records, clock skew, or other reasons.
DNSSECで署名されたゾーンの場合、セキュリティ認識リゾルバーがRRSetの信頼チェーンを確立できると考えている場合、おそらく複数の権威ある名前サーバーを試した後、そうすることができないと考えている場合、解決障害が発生する可能性があります。DNSSEC検証の障害は、署名の不一致、DNSKEY RRSの欠落、存在拒否記録の問題、時計のスキュー、またはその他の理由によるものである可能性があります。
Section 4.7 of [RFC4035] already discusses the requirements and reasons for caching validation failures. Section 3.4 of this document strengthens those requirements.
[RFC4035]のセクション4.7は、キャッシュ検証障害の要件と理由についてすでに説明しています。このドキュメントのセクション3.4は、これらの要件を強化します。
A name server returns a message with the RCODE field set to FORMERR when it is unable to interpret the query [RFC1035]. FORMERR responses are often associated with problems processing Extension Mechanisms for DNS (EDNS(0)) [RFC6891]. Authoritative servers may return FORMERR when they do not implement EDNS(0), or when EDNS(0) option fields are malformed, but not for unknown EDNS(0) options.
名前サーバーは、クエリ[RFC1035]を解釈できない場合、rcodeフィールドがFOMERRに設定されたメッセージを返します。Formerrの応答は、多くの場合、DNS（EDNS（0））[RFC6891]の拡張メカニズムの処理問題に関連しています。権威あるサーバーは、EDN（0）を実装していない場合、またはEDNS（0）オプションフィールドが奇形であるが、未知のEDN（0）オプションではない場合、Formerrを返す場合があります。
Upon receipt of a FORMERR response, some recursive clients will retry their queries without EDNS(0), while others will not. Nonetheless, resolution failures from FORMERR responses are rare.
FOMERRの応答を受け取ると、一部の再帰的なクライアントはEDN（0）なしでクエリを再試行しますが、他のクライアントはそうしません。それにもかかわらず、FORMERRの応答からの解像度の障害はまれです。
A resolver MUST NOT retry a given query to a server address over a given DNS transport more than twice (i.e., three queries in total) before considering the server address unresponsive over that DNS transport for that query.
リゾルバーは、特定のDNSトランスポートを2回以上（つまり、合計3つのクエリ）、サーバーアドレスがそのクエリのDNSトランスポートを反応しないと考える前に、特定のDNSトランスポート上のサーバーアドレスに再試行してはなりません。
A resolver MAY retry a given query over a different DNS transport to the same server if it has reason to believe the DNS transport is available for that server and is compatible with the resolver's security policies.
Resolverは、DNSトランスポートがそのサーバーで利用可能であり、Resolverのセキュリティポリシーと互換性があると考える理由がある場合、同じサーバーへの異なるDNSトランスポートを介して特定のクエリを再試行する場合があります。
This document does not place any requirements on how long an implementation should wait before retrying a query (aka a timeout value), which may be implementation or configuration dependent. It is generally expected that typical timeout values range from 3 to 30 seconds.
このドキュメントでは、実装または構成に依存する可能性のあるクエリ（別名タイムアウト値）を再試行する前に、実装が待機する時間に関する要件はありません。一般に、典型的なタイムアウト値の範囲は3〜30秒です。
Resolvers MUST implement a cache for resolution failures. The purpose of this cache is to eliminate repeated upstream queries that cannot be resolved. When an incoming query matches a cached resolution failure, the resolver MUST NOT send any corresponding outgoing queries until after the cache entries expire.
リゾルバーは、解像度障害のためにキャッシュを実装する必要があります。このキャッシュの目的は、解決できない繰り返し上流のクエリを排除することです。着信クエリがキャッシュ解像度の障害と一致する場合、リゾルバーは、キャッシュエントリが期限切れになるまで、対応する発信クエリを送信してはなりません。
Implementation details for such a cache are not specified in this document. The implementation might cache different resolution failure conditions differently. For example, DNSSEC validation failures might be cached according to the queried name, class, and type, whereas unresponsive servers might be cached only according to the server's IP address. Developers should document their implementation choices so that operators know what behaviors to expect when resolution failures are cached.
このようなキャッシュの実装の詳細は、このドキュメントでは指定されていません。実装は、異なる解像度の障害条件を異なる方法でキャッシュする可能性があります。たとえば、DNSSEC検証障害は、クエリの名前、クラス、およびタイプに従ってキャッシュされる可能性がありますが、反応しないサーバーはサーバーのIPアドレスに従ってのみキャッシュされる場合があります。開発者は、オペレーターが解像度の障害がキャッシュされたときにどの動作を期待するかを知るように、実装の選択肢を文書化する必要があります。
Resolvers MUST cache resolution failures for at least 1 second. Resolvers MAY cache different types of resolution failures for different (i.e., longer) amounts of time. Consistent with [RFC2308], resolution failures MUST NOT be cached for longer than 5 minutes.
リゾルバーは、解像度の障害を少なくとも1秒間キャッシュする必要があります。リゾルバーは、異なるタイプの解像度障害を異なる（つまり、より長い）時間にキャッシュする場合があります。[RFC2308]と一致して、解像度の障害を5分以上キャッシュしてはなりません。
The minimum cache duration SHOULD be configurable by the operator. A longer cache duration for resolution failures will reduce the processing burden from repeated queries but may also increase the time to recover from transitory issues.
最小キャッシュ期間は、オペレーターが構成できる必要があります。解像度の障害のキャッシュ期間が長くなると、処理の負担が繰り返されるクエリから減少しますが、一時的な問題から回復する時間を増やす可能性があります。
Resolvers SHOULD employ an exponential or linear backoff algorithm to increase the cache duration for persistent resolution failures. For example, the initial time for negatively caching a resolution failure might be set to 5 seconds and increased after each retry that results in another resolution failure, up to a configurable maximum, not to exceed the 5-minute upper limit.
リゾルバーは、指数または線形のバックオフアルゴリズムを使用して、持続的な解像度障害のためにキャッシュ期間を増やす必要があります。たとえば、解像度の障害を否定的にキャッシュする最初の時間は5秒に設定され、各再試行の後に増加し、別の解像度障害になり、5分間の上限を超えないように、構成可能な最大値まで増加します。
Notwithstanding the above, resolvers SHOULD implement measures to mitigate resource exhaustion attacks on the failed resolution cache. That is, the resolver should limit the amount of memory and/or processing time devoted to this cache.
上記にもかかわらず、リゾルバーは、解像度の失敗キャッシュに対するリソースの使い果たし攻撃を緩和するための手段を実装する必要があります。つまり、リゾルバーは、このキャッシュに充てられたメモリおよび/または処理時間の量を制限する必要があります。
Section 2.1 of [RFC4697] identifies circumstances in which:
[RFC4697]のセクション2.1は、次のような状況を特定しています。
...every name server in a zone's NS RRSet is unreachable (e.g., during a network outage), unavailable (e.g., the name server process is not running on the server host), or misconfigured (e.g., the name server is not authoritative for the given zone, also known as "lame").
...ゾーンのNS RRSet内のすべての名前サーバーは、到達不可能（ネットワークの停止中に）、利用できない（例：名前サーバープロセスがサーバーホストで実行されていない）、または誤解されている（たとえば、名前サーバーは権威ではありません。「ラメ」とも呼ばれる特定のゾーンの場合）。
It prohibits unnecessary "aggressive requerying" to the parent of a non-responsive zone by sending NS queries.
NSクエリを送信することにより、非応答ゾーンの親に不必要な「積極的な要求」を禁止します。
The problem of aggressive requerying to parent zones is not limited to queries of type NS. This document updates the requirement from Section 2.1.1 of [RFC4697] to apply more generally:
親ゾーンへの積極的なリクエリーの問題は、タイプnsのクエリに限定されません。このドキュメントでは、[RFC4697]のセクション2.1.1の要件を更新して、より一般的に適用します。
Upon encountering a zone whose name servers are all non-responsive, a resolver MUST cache the resolution failure. Furthermore, the resolver MUST limit queries to the non-responsive zone's parent zone (and to other ancestor zones) just as it would limit subsequent queries to the non-responsive zone.
名前サーバーがすべて反応しないゾーンに遭遇すると、リゾルバーは解像度の障害をキャッシュする必要があります。さらに、リゾルバーは、その後のクエリを非応答ゾーンに制限するように、クエリを非応答ゾーンの親ゾーン（および他の祖先ゾーン）に制限する必要があります。
Section 4.7 of [RFC4035] states:
[RFC4035]のセクション4.7は次のとおりです。
To prevent such unnecessary DNS traffic, security-aware resolvers MAY cache data with invalid signatures, with some restrictions.
このような不要なDNSトラフィックを防ぐために、セキュリティ認識リゾルバーは、いくつかの制限がある無効な署名でデータをキャッシュする場合があります。
This document updates [RFC4035] with the following, stronger, requirement:
このドキュメントは、[RFC4035]を次の、より強力な要件で更新します。
To prevent such unnecessary DNS traffic, security-aware resolvers MUST cache DNSSEC validation failures, with some restrictions.
このような不要なDNSトラフィックを防ぐには、セキュリティ対応のリゾルバーがDNSSEC検証障害をキャッシュする必要があり、いくつかの制限が必要です。
One of the restrictions mentioned in [RFC4035] is to use a small TTL when caching data that fails DNSSEC validation. This is, in part, because the provided TTL cannot be trusted. The advice from Section 3.2 herein can be used as guidance on TTLs for caching DNSSEC validation failures.
[RFC4035]で言及されている制限の1つは、DNSSEC検証に失敗したデータをキャッシュするときに小さなTTLを使用することです。これは、提供されたTTLが信頼できないためです。本明細書のセクション3.2からのアドバイスは、DNSSEC検証障害をキャッシュするためのTTLSに関するガイダンスとして使用できます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
As noted in Section 3.2, an attacker might attempt a resource exhaustion attack by sending queries for a large number of names and/ or types that result in resolution failure. Resolvers SHOULD implement measures to protect themselves and bound the amount of memory devoted to caching resolution failures.
セクション3.2で述べたように、攻撃者は、解像度の障害をもたらす多数の名前および/またはタイプのクエリを送信することにより、リソースの消耗攻撃を試みることができます。リゾルバーは、自分自身を保護し、キャッシュ解像度の障害に専念するメモリの量を拘束するための測定を実装する必要があります。
A cache poisoning attack (see Section 2.2 of [RFC7873]) resulting in denial of service may be possible because failure messages cannot be signed. An attacker might generate queries and send forged failure messages, causing the resolver to cease sending queries to the authoritative name server (see Section 2.6 of [RFC4732] for a similar "data corruption attack" and Section 5.2 of [TuDoor] for a "DNSDoS attack"). However, this would require continued spoofing throughout the backoff period and repeated attacks due to the 5-minute cache limit. As in Section 4.1.12 of [RFC4686], this attack's effects would be "localized and of limited duration".
障害メッセージに署名できないため、サービスの拒否をもたらすキャッシュ中毒攻撃（[RFC7873]のセクション2.2を参照）が可能になる場合があります。攻撃者はクエリを生成し、偽造障害メッセージを送信し、リゾルバーが権威ある名前サーバーへのクエリの送信を停止する可能性があります（同様の「データ腐敗攻撃」については[RFC4732]のセクション2.6を参照し、[dnsdosos]の[Tudoor]のセクション5.2を参照してください。攻撃"）。ただし、これには、5分間のキャッシュ制限により、バックオフ期間を通して継続的なスプーフィングと繰り返し攻撃が必要です。[RFC4686]のセクション4.1.12と同様に、この攻撃の効果は「局所化され、期間が限られている」ことになります。
This specification has no impact on user privacy.
この仕様は、ユーザーのプライバシーに影響を与えません。
[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>.
[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>.
[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>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697,
October 2006, <https://www.rfc-editor.org/info/rfc4697>.
[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>.
[BOTNET] Wessels, D. and M. Thomas, "Botnet Traffic Observed at
Various Levels of the DNS Hierarchy", May 2021,
<https://indico.dns-oarc.net/event/38/contributions/841/>.
[DNSSEC-ROLLOVER]
Michaleson, G., Wallström, P., Arends, R., and G. Huston,
"Roll Over and Die?", February 2010,
<https://www.potaroo.net/ispcol/2010-02/rollover.html>.
[FB-OUTAGE]
Janardhan, S., "More details about the October 4 outage",
October 2021, <https://engineering.fb.com/2021/10/05/
networking-traffic/outage-details/>.
[KSK-ROLLOVER]
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", IMC '19: Proceedings of the
Internet Measurement Conference, Pages 1-14,
DOI 10.1145/3355369.3355570, October 2019,
<https://doi.org/10.1145/3355369.3355570>.
[OUTAGE-RESOLVER]
Verisign, "Observations on Resolver Behavior During DNS
Outages", January 2022,
<https://blog.verisign.com/security/facebook-dns-outage/>.
[RETRY-STORM]
Sullivan, A., "Dyn, DDoS, and DNS", March 2017,
<https://ccnso.icann.org/sites/default/files/file/field-
file-attach/2017-04/presentation-oracle-dyn-ddos-dns-
13mar17-en.pdf>.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983,
<https://www.rfc-editor.org/info/rfc882>.
[RFC0883] Mockapetris, P., "Domain names: Implementation
specification", RFC 883, DOI 10.17487/RFC0883, November
1983, <https://www.rfc-editor.org/info/rfc883>.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
September 2006, <https://www.rfc-editor.org/info/rfc4686>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8767] Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
to Improve DNS Resiliency", RFC 8767,
DOI 10.17487/RFC8767, March 2020,
<https://www.rfc-editor.org/info/rfc8767>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[THUNDERING-HERD]
Sivaraman, M. and C. Liu, "The DNS thundering herd
problem", Work in Progress, Internet-Draft, draft-muks-
dnsop-dns-thundering-herd-00, 25 June 2020,
<https://datatracker.ietf.org/doc/html/draft-muks-dnsop-
dns-thundering-herd-00>.
[TsuNAME] Moura, G. C. M., Castro, S., Heidemann, J., and W.
Hardaker, "TsuNAME: exploiting misconfiguration and
vulnerability to DDoS DNS", IMC '21: Proceedings of the
21st ACM Internet Measurement Conference, Pages 398-418,
DOI 10.1145/3487552.3487824, November 2021,
<https://doi.org/10.1145/3487552.3487824>.
[TuDoor] Li, X., Xu, W., Liu, B., Zhang, M., Li, Z., Zhang, J.,
Chang, D., Zheng, X., Wang, C., Chen, J., Duan, H., and Q.
Li, "TuDoor Attack: Systematically Exploring and
Exploiting Logic Vulnerabilities in DNS Response Pre-
processing with Malformed Packets", IEEE Symposium on
Security and Privacy (SP), DOI 10.1109/SP54263.2024.00046,
2024, <https://doi.ieeecomputersociety.org/10.1109/
SP54263.2024.00046>.
The authors wish to thank Mukund Sivaraman, Petr Spacek, Peter van Dijk, Tim Wicinksi, Joe Abley, Evan Hunt, Barry Leiba, Lucas Pardue, Paul Wouters, and other members of the DNSOP Working Group for their feedback and contributions.
著者は、Mukund Sivaraman、Petr Spacek、Peter Van Dijk、Tim Wicinksi、Joe Eabley、Evan Hunt、Barry Leiba、Lucas Pardue、Paul Wouters、およびDNSOPワーキンググループの他のメンバーにフィードバックと寄付について感謝したいと考えています。
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
William Carroll
Verisign
12061 Bluemont Way
Reston, VA 20190
United States of America
Phone: +1 703 948-3200
Email: wicarroll@verisign.com
URI: https://verisign.com
Matthew Thomas
Verisign
12061 Bluemont Way
Reston, VA 20190
United States of America
Phone: +1 703 948-3200
Email: mthomas@verisign.com
URI: https://verisign.com