[要約] DNSエラー報告は、権威サーバーのオペレーターに、解決できないか検証できないDNSリソースレコードに関する報告を提供する軽量な報告メカニズムです。ドメイン所有者やDNSホスティング組織は、これらの報告を使用してドメインホスティングを改善できます。報告はRFC 8914で説明される拡張DNSエラーに基づいています。
Internet Engineering Task Force (IETF) R. Arends
Request for Comments: 9567 M. Larson
Category: Standards Track ICANN
ISSN: 2070-1721 April 2024
DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914.
DNSエラーレポートは、解決または検証に失敗したDNSリソースレコードに関するレポートを権威あるサーバーのオペレーターに提供する軽量レポートメカニズムです。ドメイン所有者またはDNSホスティング組織は、これらのレポートを使用してドメインホスティングを改善できます。レポートは、RFC 8914で説明されている拡張DNSエラーに基づいています。
When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME; thus, the very act of sending the query is to report the error.
誤った構成または攻撃のためにドメイン名が解決または検証に失敗した場合、権威あるサーバーのオペレーターはこれを認識していない可能性があります。このフィードバックの欠如を軽減するために、このドキュメントでは、検証型のリゾルバーが権威あるサーバーによって指定された監視エージェントにエラーを自動的に信号する方法について説明します。エラーはQNAMEでエンコードされています。したがって、クエリを送信するまさにその行為は、エラーを報告することです。
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/rfc9567.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9567で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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
2. Requirements Notation
3. Terminology
4. Overview
4.1. Example
5. EDNS0 Option Specification
6. DNS Error Reporting Specification
6.1. Reporting Resolver Specification
6.1.1. Constructing the Report Query
6.2. Authoritative Server Specification
6.3. Monitoring Agent Specification
7. IANA Considerations
8. Operational Considerations
8.1. Choosing an Agent Domain
8.2. Managing Caching Optimizations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
When an authoritative server serves a stale DNSSEC-signed zone, the cryptographic signatures over the resource record sets (RRsets) may have lapsed. A validating resolver will fail to validate these resource records.
権威あるサーバーが古いDNSECに署名したゾーンを提供する場合、リソースレコードセット（RRSET）の暗号化署名が失効している可能性があります。検証リゾルバーは、これらのリソースレコードの検証に失敗します。
Similarly, when there is a mismatch between the Delegation Signer (DS) records at a parent zone and the key signing key at the child zone, a validating resolver will fail to authenticate records in the child zone.
同様に、親ゾーンでの代表団の署名者（DS）レコードとチャイルドゾーンでのキー署名キーの間に不一致がある場合、検証済みのリゾルバーはチャイルドゾーンでレコードを認証できません。
These are two of several failure scenarios that may go unnoticed for some time by the operator of a zone.
これらは、ゾーンのオペレーターによってしばらく見過ごされる可能性のあるいくつかの障害シナリオのうちの2つです。
Today, there is no direct relationship between operators of validating resolvers and authoritative servers. Outages are often noticed indirectly by end users and reported via email or social media (if reported at all).
今日、リゾルバーを検証するオペレーターと権威あるサーバーの間に直接的な関係はありません。多くの場合、停止はエンドユーザーによって間接的に気づかれ、電子メールまたはソーシャルメディアを介して報告されます（まったく報告されている場合）。
When records fail to validate, there is no facility to report this failure in an automated way. If there is any indication that an error or warning has happened, it may be buried in log files of the resolver or not logged at all.
レコードが検証に失敗した場合、この障害を自動化した方法で報告する施設はありません。エラーまたは警告が発生していることを示すものがある場合、リゾルバーのログファイルに埋め込まれるか、まったく記録されていない可能性があります。
This document describes a method that can be used by validating resolvers to report DNSSEC validation errors in an automated way.
このドキュメントでは、リゾルバーを検証してDNSSEC検証エラーを自動化された方法で報告することで使用できる方法について説明します。
It allows an authoritative server to announce a monitoring agent to which validating resolvers can report issues if those resolvers are configured to do so.
これにより、権威あるサーバーは、それらのリゾルバーがそうするように構成されている場合、検証型のリゾルバーが問題を報告できる監視エージェントを発表することができます。
The burden to report a failure falls on the validating resolver. It is important that the effort needed to report failure is low, with minimal impact to its main functions. To accomplish this goal, the DNS itself is utilized to report the error.
失敗を報告する負担は、検証済みのリゾルバーにあります。障害を報告するために必要な努力が低いことが重要であり、その主な機能には最小限の影響を与えています。この目標を達成するために、DNS自体がエラーを報告するために利用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses DNS terminology defined in BCP 219 [RFC9499]. This document also defines and uses the following terms:
このドキュメントでは、BCP 219 [RFC9499]で定義されたDNS用語を使用しています。このドキュメントは、次の用語も定義および使用します。
Reporting resolver:
レポートリゾルバー：
A validating resolver that supports DNS error reporting.
DNSエラーレポートをサポートする検証リゾルバー。
Report query:
レポートクエリ：
The DNS query used to report an error. A report query is for a DNS TXT resource record type. The content of the error report is encoded in the QNAME of a DNS request to the monitoring agent.
エラーの報告に使用されるDNSクエリ。レポートクエリは、DNS TXTリソースレコードタイプのものです。エラーレポートの内容は、監視エージェントへのDNSリクエストのQNAMEにエンコードされます。
Monitoring agent:
監視エージェント：
An authoritative server that receives and responds to report queries. This facility is indicated by a domain name, referred to as the "agent domain".
クエリのレポートに受信して応答する権威あるサーバー。この機能は、「エージェントドメイン」と呼ばれるドメイン名で示されています。
Agent domain:
エージェントドメイン：
A domain name that is returned in the EDNS0 Report-Channel option and indicates where DNS resolvers can send error reports.
EDNS0レポートチャネルオプションで返され、DNSリゾルバーがエラーレポートを送信できる場所を示します。
An authoritative server indicates support for DNS error reporting by including an EDNS0 Report-Channel option with OPTION-CODE 18 and the agent domain in the response. The agent domain is a fully qualified, uncompressed domain name in DNS wire format. The authoritative server MUST NOT include this option in the response if the configured agent domain is empty or is the null label (which would indicate the DNS root).
権威あるサーバーは、Option-Code 18と応答にエージェントドメインを含むEDNS0レポートチャネルオプションを含めることにより、DNSエラーレポートのサポートを示します。エージェントドメインは、DNSワイヤ形式の完全に適格で非圧縮ドメイン名です。構成されたエージェントドメインが空であるか、nullラベル（DNSルートを示す）である場合、権威あるサーバーは応答にこのオプションを含めてはなりません。
The authoritative server includes the EDNS0 Report-Channel option unsolicited. That is, the option is included in a response despite the EDNS0 Report-Channel option being absent in the request.
権威あるサーバーには、EDNS0レポートチャネルオプションがunloclitedを含みます。つまり、EDNS0レポートチャネルオプションがリクエストに存在しないにもかかわらず、オプションは応答に含まれています。
If the authoritative server has indicated support for DNS error reporting and there is an issue that can be reported via extended DNS errors, the reporting resolver encodes the error report in the QNAME of the report query. The reporting resolver builds this QNAME by concatenating the "_er" label, the QTYPE, the QNAME that resulted in failure, the extended DNS error code (as described in [RFC8914]), the label "_er" again, and the agent domain. See the example in Section 4.1 and the specification in Section 6.1.1. Note that a regular RCODE is not included because the RCODE is not relevant to the extended DNS error code.
権威あるサーバーがDNSエラーレポートのサポートを示しており、拡張されたDNSエラーを介して報告できる問題がある場合、レポートリゾルバーはレポートクエリのQNAMEのエラーレポートをエンコードします。レポートリゾルバーは、「_er」ラベル、qtype、障害をもたらしたqname、拡張DNSエラーコード（[rfc8914]で説明されている）、ラベル「_ er」、およびエージェントドメインを連結することにより、このqNameを構築します。セクション4.1の例とセクション6.1.1の仕様を参照してください。rcodeは拡張DNSエラーコードに関連していないため、通常のRcodeは含まれていません。
The resulting report query is sent as a standard DNS query for a TXT DNS resource record type by the reporting resolver.
結果のレポートクエリは、レポートリゾルバーによってTXT DNSリソースレコードタイプの標準DNSクエリとして送信されます。
The report query will ultimately arrive at the monitoring agent. A response is returned by the monitoring agent, which in turn can be cached by the reporting resolver. This caching is essential. It dampens the number of report queries sent by a reporting resolver for the same problem (that is, with caching, one report query per TTL is sent). However, certain optimizations, such as those described in [RFC8020] and [RFC8198], may reduce the number of error report queries as well.
レポートクエリは、最終的に監視エージェントに到着します。監視エージェントによって応答が返され、レポートリゾルバーがキャッシュできます。このキャッシングは不可欠です。同じ問題についてレポートリゾルバーによって送信されたレポートクエリの数を減衰させます（つまり、キャッシュすると、TTLごとに1つのレポートクエリが送信されます）。ただし、[RFC8020]や[RFC8198]に記載されているような特定の最適化は、エラーレポートクエリの数も減らす可能性があります。
This document gives no guidance on the content of the RDATA in the TXT resource record.
このドキュメントは、TXTリソースレコードのRDATAのコンテンツに関するガイダンスを提供しません。
A query for "broken.test.", type A, is sent by a reporting resolver.
「broken.test。」のクエリ、タイプAは、レポートリゾルバーによって送信されます。
The domain "test." is hosted on a set of authoritative servers. One of these authoritative servers serves a stale version of the "test." zone. This authoritative server has an agent domain configured as "a01.agent-domain.example.".
ドメイン「テスト」。権威あるサーバーのセットでホストされています。これらの権威あるサーバーの1つは、「テスト」の古いバージョンを提供します。ゾーン。この権威あるサーバーには、「a01.agent-domain.example」として構成されたエージェントドメインがあります。
The authoritative server with the stale "test." zone receives the request for "broken.test.". It returns a response that includes the EDNS0 Report-Channel option with the domain name "a01.agent-domain.example.".
古い「テスト」を備えた権威あるサーバー。ゾーンは「broken.test」のリクエストを受け取ります。ドメイン名「a01.agent-domain.example」を含むEDNS0レポートチャネルオプションを含む応答を返します。
The reporting resolver is unable to validate the "broken.test." RRset for type A (an RR type with value 1), due to an RRSIG record with an expired signature.
レポートリゾルバーでは、「broken.test」を検証できません。期限切れの署名を持つRRSIGレコードのため、タイプA（値1のRRタイプ）のRRSET。
The reporting resolver constructs the QNAME "_er.1.broken.test.7._er.a01.agent-domain.example." and resolves it. This QNAME indicates extended DNS error 7 occurred while trying to validate "broken.test." for a type A (an RR type with value 1) record.
レポートリゾルバーは、QName "_er.1.broken.test.7._er.a01.agent-domain.exampleを構築します。"そしてそれを解決します。このQNameは、「broken.test」の検証を試みたときに拡張されたDNSエラー7が発生したことを示します。タイプA（値1のRRタイプ）レコードの場合。
When this query is received at the monitoring agent (the operators of the authoritative server for "a01.agent-domain.example."), the agent can determine the "test." zone contained an expired signature record (extended DNS error 7) for type A for the domain name "broken.test.". The monitoring agent can contact the operators of "test." to fix the issue.
このクエリが監視エージェント（「a01.agent-domain.example。」の権威あるサーバーの演算子）で受信されると、エージェントは「テスト」を決定できます。ゾーンには、ドメイン名「broken.test」のタイプAの有効期限切れの署名レコード（拡張DNSエラー7）が含まれていました。監視エージェントは、「テスト」のオペレーターに連絡できます。問題を修正します。
This method uses an EDNS0 [RFC6891] option to indicate the agent domain in DNS responses. The option is structured as follows:
この方法では、EDNS0 [RFC6891]オプションを使用して、DNS応答でエージェントドメインを示します。オプションは次のように構成されています。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = 18 | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AGENT DOMAIN /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Field definition details:
フィールド定義の詳細：
OPTION-CODE:
オプションコード：
2 octets; an EDNS0 code that is used in an EDNS0 option to indicate support for error reporting. The name for this EDNS0 option code is Report-Channel.
2オクテット;EDNS0オプションで使用されるEDNS0コードは、エラーレポートのサポートを示しています。このEDNS0オプションコードの名前はレポートチャネルです。
OPTION-LENGTH:
オプション長：
2 octets; contains the length of the AGENT DOMAIN field in octets.
2オクテット;オクテットのエージェントドメインフィールドの長さが含まれています。
AGENT DOMAIN:
エージェントドメイン：
A fully qualified domain name [RFC9499] in uncompressed DNS wire format.
非圧縮DNSワイヤ形式の完全資格のドメイン名[RFC9499]。
The various errors that a reporting resolver may encounter are listed in [RFC8914]. Note that not all listed errors may be supported by the reporting resolver. This document does not specify what is or is not an error.
レポートリゾルバーが遭遇する可能性のあるさまざまなエラーは、[RFC8914]にリストされています。すべてのリストされたエラーがレポートリゾルバーによってサポートされるわけではないことに注意してください。このドキュメントでは、エラーとは何かを指定していません。
The DNS class is not specified in the error report.
DNSクラスは、エラーレポートでは指定されていません。
Care should be taken when additional DNS resolution is needed to resolve the QNAME that contains the error report. This resolution itself could trigger another error report to be created. A maximum expense or depth limit MUST be used to prevent cascading errors.
エラーレポートを含むQNAMEを解決するために追加のDNS解像度が必要な場合は、注意する必要があります。この解像度自体は、別のエラーレポートを作成する可能性があります。カスケードエラーを防ぐために、最大費用または深度制限を使用する必要があります。
The EDNS0 Report-Channel option MUST NOT be included in queries.
EDNS0レポートチャネルオプションをクエリに含めてはなりません。
The reporting resolver MUST NOT use DNS error reporting if the authoritative server returned an empty AGENT DOMAIN field in the EDNS0 Report-Channel option.
Reporting Resolverは、権威あるサーバーがEDNS0レポートチャネルオプションで空のエージェントドメインフィールドを返した場合、DNSエラーレポートを使用してはなりません。
For the monitoring agent to gain more confidence that the report is not spoofed, the reporting resolver SHOULD send error reports over TCP [RFC7766] or other connection-oriented protocols or SHOULD use DNS Cookies [RFC7873]. This makes it harder to falsify the source address.
監視エージェントがレポートがスプーフィングされていないというより多くの自信を得るために、レポートリゾルバーはTCP [RFC7766]または他の接続指向のプロトコルを介してエラーレポートを送信するか、DNS Cookie [RFC7873]を使用する必要があります。これにより、ソースアドレスを偽造することが難しくなります。
A reporting resolver MUST validate responses received from the monitoring agent. There is no special treatment for responses to error-reporting queries. Section 9 ("Security Considerations") contains the rationale behind this.
レポートリゾルバーは、監視エージェントから受信した回答を検証する必要があります。エラー報告クエリに対する応答に対する特別な治療はありません。セクション9（「セキュリティ上の考慮事項」）には、この背後にある根拠が含まれています。
The QNAME for the report query is constructed by concatenating the following elements:
レポートクエリのQNameは、次の要素を連結することによって構築されます。
* A label containing the string "_er".
* 文字列「_er」を含むラベル。
* The QTYPE that was used in the query that resulted in the extended DNS error, presented as a decimal value, in a single DNS label. If additional QTYPEs were present in the query, such as described in [MULTI-QTYPES], they are represented as unique, ordered decimal values separated by a hyphen. As an example, if both QTYPE A and AAAA were present in the query, they are presented as the label "1-28".
* 単一のDNSラベルで、10進値として表示される拡張DNSエラーをもたらしたクエリで使用されたQTYPE。[Multi-QTypes]に記載されているようなクエリに追加のQTypesが存在する場合、それらはハイフンによって区切られた一意の順序付けられた小数値として表されます。例として、QType AとAAAAの両方がクエリに存在する場合、それらはラベル「1-28」として提示されます。
* The list of non-null labels representing the query name that is the subject of the DNS error report.
* DNSエラーレポートの主題であるクエリ名を表す非ヌルラベルのリスト。
* The extended DNS error code, presented as a decimal value, in a single DNS label.
* 単一のDNSラベルで小数点として表示される拡張DNSエラーコード。
* A label containing the string "_er".
* 文字列「_er」を含むラベル。
* The agent domain. The agent domain as received in the EDNS0 Report-Channel option set by the authoritative server.
* エージェントドメイン。権威あるサーバーによって設定されたEDNS0レポートチャネルオプションで受信されたエージェントドメイン。
If the QNAME of the report query exceeds 255 octets, it MUST NOT be sent.
レポートクエリのQNameが255オクテットを超える場合、送信してはなりません。
The "_er" labels allow the monitoring agent to differentiate between the agent domain and the faulty query name. When the specified agent domain is empty, or is a null label (despite being not allowed in this specification), the report query will have "_er" as a top-level domain, and not the top-level domain from the query name that was the subject of this error report. The purpose of the first "_er" label is to indicate that a complete report query has been received instead of a shorter report query due to query minimization.
「_er」ラベルにより、監視エージェントはエージェントドメインと故障したクエリ名を区別できます。指定されたエージェントドメインが空の場合、またはnullラベルである場合（この仕様では許可されていないにもかかわらず）、レポートクエリにはトップレベルのドメインとして「_er」があり、クエリ名のトップレベルドメインではなく、このエラーレポートの対象でした。最初の「_er」ラベルの目的は、クエリの最小化により、より短いレポートクエリの代わりに完全なレポートクエリが受信されたことを示すことです。
The authoritative server MUST NOT include more than one EDNS0 Report-Channel option in a response.
権威あるサーバーは、応答に複数のEDNS0レポートチャネルオプションを含めることはできません。
The authoritative server includes the EDNS0 Report-Channel option unsolicited in responses. There is no requirement that the EDNS0 Report-Channel option be present in queries.
権威あるサーバーには、回答が承認されていないEDNS0レポートチャネルオプションが含まれています。EDNS0レポートチャネルオプションがクエリに存在するという要件はありません。
It is RECOMMENDED that the authoritative server for the agent domain reply with a positive response (i.e., not with NODATA or NXDOMAIN) containing a TXT record.
TXTレコードを含む肯定的な応答（つまり、nodataまたはnxdomainではなく）を使用して、エージェントドメインの権威あるサーバーを応答することをお勧めします。
The monitoring agent SHOULD respond to queries received over UDP that have no DNS Cookie set with a response that has the truncation bit (TC bit) set to challenge the resolver to requery over TCP.
監視エージェントは、DNS CookieセットがないUDPを介して受信したクエリに応答する必要があります。TCPを介してリクリーにリゾルバーに挑戦するように設定された回答（TCビット）が設定されています。
IANA has assigned the following in the "DNS EDNS0 Option Codes (OPT)" registry:
IANAは、「DNS EDNS0オプションコード（OPT）」レジストリで以下を割り当てました。
+=======+================+==========+===========+
| Value | Name | Status | Reference |
+=======+================+==========+===========+
| 18 | Report-Channel | Standard | RFC 9567 |
+-------+----------------+----------+-----------+
Table 1
IANA has assigned the following in the "Underscored and Globally Scoped DNS Node Names" registry:
IANAは、「Undercored and Global Scoped DNSノード名」レジストリで以下を割り当てました。
+=========+============+===========+
| RR Type | _NODE NAME | Reference |
+=========+============+===========+
| TXT | _er | RFC 9567 |
+---------+------------+-----------+
Table 2
It is RECOMMENDED that the agent domain be kept relatively short to allow for a longer QNAME in the report query. The agent domain MUST NOT be a subdomain of the domain it is reporting on. That is, if the authoritative server hosts the foo.example domain, then its agent domain MUST NOT end in foo.example.
レポートクエリでより長いQNameを許可するために、エージェントドメインを比較的短く保つことをお勧めします。エージェントドメインは、報告しているドメインのサブドメインである必要があります。つまり、権威あるサーバーがfoo.exampleドメインをホストしている場合、そのエージェントドメインはfoo.exampleで終了してはなりません。
The reporting resolver may utilize various caching optimizations that inhibit subsequent error reporting to the same monitoring agent.
レポートリゾルバーは、同じ監視エージェントへの後続のエラー報告を阻害するさまざまなキャッシング最適化を利用する場合があります。
If the monitoring agent were to respond with NXDOMAIN (name error), [RFC8020] states that any name at or below that domain should be considered unreachable, and negative caching would prohibit subsequent queries for anything at or below that domain for a period of time, depending on the negative TTL [RFC2308].
監視エージェントがNXDomain（名前エラー）で応答する場合、[RFC8020]は、そのドメイン以下の名前は到達不能と見なされるべきであり、負のキャッシュはそのドメイン以下の後続のクエリを一定期間禁止すると述べています。、負のTTL [RFC2308]に依存します。
Since the monitoring agent may not know the contents of all the zones for which it acts as a monitoring agent, the monitoring agent MUST NOT respond with NXDOMAIN for domains it is monitoring because that could inhibit subsequent queries. One method to avoid NXDOMAIN is to use a wildcard domain name [RFC4592] in the zone for the agent domain.
監視エージェントは、監視剤として機能するすべてのゾーンの内容を知らない可能性があるため、監視剤は、後続のクエリを阻害できるため、監視でNXDomainで応答してはなりません。NxDomainを回避する1つの方法は、エージェントドメインのゾーンでWildCardドメイン名[RFC4592]を使用することです。
When the agent domain is signed, a resolver may use aggressive negative caching (described in [RFC8198]). This optimization makes use of NSEC and NSEC3 (without opt-out) records and allows the resolver to do the wildcard synthesis. When this happens, the resolver does not send subsequent queries because it will be able to synthesize a response from previously cached material.
エージェントドメインに署名された場合、リゾルバーは積極的なネガティブキャッシュを使用する場合があります（[RFC8198]で説明）。この最適化により、NSECおよびNSEC3（オプトアウトなし）レコードが使用され、リゾルバーがワイルドカード合成を行うことができます。これが起こると、リゾルバーは以前にキャッシュされた素材からの応答を合成できるため、後続のクエリを送信しません。
A solution is to avoid DNSSEC for the agent domain. Signing the agent domain will incur an additional burden on the reporting resolver, as it has to validate the response. However, this response has no utility to the reporting resolver other than dampening the query load for error reports.
解決策は、エージェントドメインのDNSSECを回避することです。エージェントドメインに署名すると、応答を検証する必要があるため、レポートリゾルバーに追加の負担が発生します。ただし、この応答には、エラーレポートのクエリ負荷を減衰させる以外に、レポートリゾルバーのユーティリティはありません。
Use of DNS error reporting may expose local configuration mistakes in the reporting resolver, such as stale DNSSEC trust anchors, to the monitoring agent.
DNSエラーレポートの使用により、描かれたDNSSECトラストアンカーなどのレポートリゾルバーのローカル構成ミスが監視エージェントに公開される場合があります。
DNS error reporting SHOULD be done using DNS query name minimization [RFC9156] to improve privacy.
DNSエラーレポートは、DNSクエリ名の最小化[RFC9156]を使用してプライバシーを改善する必要があります。
DNS error reporting is done without any authentication between the reporting resolver and the authoritative server of the agent domain.
DNSエラーレポートは、レポートリゾルバーとエージェントドメインの信頼できるサーバーの間に認証なしで実行されます。
Resolvers that send error reports SHOULD send them over TCP [RFC7766] or SHOULD use DNS Cookies [RFC7873]. This makes it hard to falsify the source address. The monitoring agent SHOULD respond to queries received over UDP that have no DNS Cookie set with a response that has the truncation bit (TC bit) set to challenge the resolver to requery over TCP.
エラーレポートを送信するリゾルバーは、TCP [RFC7766]を介してそれらを送信するか、DNS Cookie [RFC7873]を使用する必要があります。これにより、ソースアドレスを偽造することが難しくなります。監視エージェントは、DNS CookieセットがないUDPを介して受信したクエリに応答する必要があります。TCPを介してリクリーにリゾルバーに挑戦するように設定された回答（TCビット）が設定されています。
Well-known addresses of reporting resolvers can provide a higher level of confidence in the error reports and potentially enable more automated processing of these reports.
レポートリゾルバーのよく知られたアドレスは、エラーレポートにより高いレベルの信頼性を提供し、これらのレポートのより自動化された処理を可能にする可能性があります。
Monitoring agents that receive error reports over UDP should consider that the source of the reports and the reports themselves may be false.
UDPを介してエラーレポートを受け取る監視エージェントは、レポートとレポート自体のソースが虚偽である可能性があることを考慮する必要があります。
The method described in this document will cause additional queries by the reporting resolver to authoritative servers in order to resolve the report query.
このドキュメントで説明されている方法は、レポートクエリを解決するために、信頼できるサーバーへのレポートリゾルバーによる追加のクエリを引き起こします。
This method can be abused by intentionally deploying broken zones with agent domains that are delegated to victims. This is particularly effective when DNS requests that trigger error messages are sent through open resolvers [RFC9499] or widely distributed network monitoring systems that perform distributed queries from around the globe.
この方法は、被害者に委任されたエージェントドメインを使用して壊れたゾーンを意図的に展開することにより、乱用することができます。これは、DNSがトリガーエラーメッセージがオープンリゾルバー[RFC9499]または世界中から分散クエリを実行する広く分散したネットワーク監視システムを介して送信されることを要求する場合に特に効果的です。
An adversary may create massive error report flooding to camouflage an attack.
敵は、攻撃をカモフラージュするために大規模なエラーレポートの洪水を引き起こす可能性があります。
Though this document gives no guidance on the content of the RDATA in the TXT resource record, if the RDATA content is logged, the monitoring agent MUST assume the content can be malicious and take appropriate measures to avoid exploitation. One such method could be to log in hexadecimal. This would avoid remote code execution through logging string attacks, such as the vulnerability described in [CVE-2021-44228].
このドキュメントは、TXTリソースレコードのRDATAのコンテンツに関するガイダンスを提供しませんが、RDATAコンテンツが記録されている場合、監視エージェントは、搾取を避けるためにコンテンツが悪意を持ち、適切な対策を講じることができると仮定する必要があります。そのような方法の1つは、16進数にログインすることです。これにより、[CVE-2021-44228]に記載されている脆弱性など、ロギング文字列攻撃を介してリモートコードの実行が回避されます。
The rationale behind mandating DNSSEC validation for responses from a reporting agent, even if the agent domain is proposed to remain unsigned, is to mitigate the risk of a downgrade attack orchestrated by adversaries. In such an attack, a victim's legitimately signed domain could be deceptively advertised as an agent domain by malicious actors. Consequently, if the validating resolver treats it as unsigned, it is exposed to potential cache poisoning attacks. By enforcing DNSSEC validation, this vulnerability is preemptively addressed.
報告エージェントからの応答のDNSSEC検証の義務的根拠は、たとえエージェントドメインが署名されたままであると提案されている場合でも、敵によって倒れた攻撃のリスクを軽減することです。このような攻撃では、被害者の合法的に署名されたドメインは、悪意のある俳優によってエージェントドメインとして誤って宣伝される可能性があります。その結果、検証型のリゾルバーがそれを署名していないと扱う場合、潜在的なキャッシュ中毒攻撃にさらされます。DNSSEC検証を実施することにより、この脆弱性は先制的に対処されます。
[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>.
[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>.
[CVE-2021-44228]
CVE, "CVE-2021-44228", 26 November 2021,
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-
2021-44228>.
[MULTI-QTYPES]
Bellis, R., "DNS Multiple QTYPEs", Work in Progress,
Internet-Draft, draft-ietf-dnssd-multi-qtypes-00, 4
December 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-dnssd-multi-qtypes-00>.
[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>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.
[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>.
[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>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[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>.
[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
Name Minimisation to Improve Privacy", RFC 9156,
DOI 10.17487/RFC9156, November 2021,
<https://www.rfc-editor.org/info/rfc9156>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
This document is based on an idea by Roy Arends and David Conrad. The authors would like to thank Peter van Dijk, Stephane Bortzmeyer, Shane Kerr, Vladimir Cunat, Paul Hoffman, Philip Homburg, Mark Andrews, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay, Dick Franks, Ben Schwartz, Yaron Sheffer, Viktor Dukhovni, Wes Hardaker, James Gannon, Tim Wicinski, Warren Kumari, Gorry Fairhurst, Benno Overeinder, Paul Wouters, and Petr Spacek for their contributions.
このドキュメントは、Roy ArendsとDavid Conradのアイデアに基づいています。著者は、ピーター・ヴァン・ディック、ステファン・ボルツマイヤー、シェーン・カー、ウラジミール・カナト、ポール・ホフマン、フィリップ・ホンブルク、マーク・アンドリュース、リボール・ペルタン、マティ・テロップ、トム・カーペイ、ディック・フランク、ベン・シュワルツ、ヤロン・シェファー、Dukhovni、Wes Hardaker、James Gannon、Tim Wicinski、Warren Kumari、Gorry Fairhurst、Benno Overeinder、Paul Wouters、Petr Spacekの貢献。
Roy Arends
ICANN
Email: roy.arends@icann.org
Matt Larson
ICANN
Email: matt.larson@icann.org