rfc9567.original   rfc9567.txt 
dnsop R. Arends Internet Engineering Task Force (IETF) R. Arends
Internet-Draft M. Larson Request for Comments: 9567 M. Larson
Intended status: Standards Track ICANN Category: Standards Track ICANN
Expires: 5 September 2024 4 March 2024 ISSN: 2070-1721 April 2024
DNS Error Reporting DNS Error Reporting
draft-ietf-dnsop-dns-error-reporting-08
Abstract Abstract
DNS error reporting is a lightweight reporting mechanism that DNS error reporting is a lightweight reporting mechanism that
provides the operator of an authoritative server with reports on DNS provides the operator of an authoritative server with reports on DNS
resource records that fail to resolve or validate. A domain owner or resource records that fail to resolve or validate. A domain owner or
DNS hosting organization can use these reports to improve domain DNS hosting organization can use these reports to improve domain
hosting. The reports are based on extended DNS errors as described hosting. The reports are based on extended DNS errors as described
in [RFC8914]. in RFC 8914.
When a domain name fails to resolve or validate due to a When a domain name fails to resolve or validate due to a
misconfiguration or an attack, the operator of the authoritative misconfiguration or an attack, the operator of the authoritative
server may be unaware of this. To mitigate this lack of feedback, server may be unaware of this. To mitigate this lack of feedback,
this document describes a method for a validating resolver to this document describes a method for a validating resolver to
automatically signal an error to a monitoring agent specified by the automatically signal an error to a monitoring agent specified by the
authoritative server. The error is encoded in the QNAME, thus the authoritative server. The error is encoded in the QNAME; thus, the
very act of sending the query is to report the error. very act of sending the query is to report the error.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 5 September 2024. 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.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Example
5. EDNS0 Option Specification . . . . . . . . . . . . . . . . . 5 5. EDNS0 Option Specification
6. DNS error reporting specification . . . . . . . . . . . . . . 6 6. DNS Error Reporting Specification
6.1. Reporting Resolver Specification . . . . . . . . . . . . 6 6.1. Reporting Resolver Specification
6.1.1. Constructing the Report Query . . . . . . . . . . . . 6 6.1.1. Constructing the Report Query
6.2. Authoritative server specification . . . . . . . . . . . 7 6.2. Authoritative Server Specification
6.3. Monitoring agent specification . . . . . . . . . . . . . 7 6.3. Monitoring Agent Specification
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations
8. Operational Considerations . . . . . . . . . . . . . . . . . 8 8. Operational Considerations
8.1. Choosing an agent domain . . . . . . . . . . . . . . . . 8 8.1. Choosing an Agent Domain
8.2. Managing Caching Optimizations . . . . . . . . . . . . . 8 8.2. Managing Caching Optimizations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses
1. Introduction 1. Introduction
When an authoritative server serves a stale DNSSEC-signed zone, the When an authoritative server serves a stale DNSSEC-signed zone, the
cryptographic signatures over the resource record sets (RRsets) may cryptographic signatures over the resource record sets (RRsets) may
have lapsed. A validating resolver will fail to validate these have lapsed. A validating resolver will fail to validate these
resource records. resource records.
Similarly, when there is a mismatch between the Delegation Signer Similarly, when there is a mismatch between the Delegation Signer
(DS) records at a parent zone and the key signing key at the child (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 zone, a validating resolver will fail to authenticate records in the
child zone. child zone.
These are two of several failure scenarios that may go unnoticed for These are two of several failure scenarios that may go unnoticed for
some time by the operator of a zone. some time by the operator of a zone.
Today, there is no direct relationship between operators of Today, there is no direct relationship between operators of
validating resolvers and authoritative servers. Outages are often validating resolvers and authoritative servers. Outages are often
noticed indirectly by end users, and reported via E-Mail or social noticed indirectly by end users and reported via email or social
media (if reported at all). media (if reported at all).
When records fail to validate, there is no facility to report this When records fail to validate, there is no facility to report this
failure in an automated way. If there is any indication that an 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 error or warning has happened, it may be buried in log files of the
resolver or not logged at all. resolver or not logged at all.
This document describes a method that can be used by validating This document describes a method that can be used by validating
resolvers to report DNSSEC validation errors in an automated way. resolvers to report DNSSEC validation errors in an automated way.
It allows an authoritative server to announce a monitoring agent It allows an authoritative server to announce a monitoring agent to
where validating resolvers can report issues if those resolvers are which validating resolvers can report issues if those resolvers are
configured to do so. configured to do so.
The burden to report a failure falls on the validating resolver. It The burden to report a failure falls on the validating resolver. It
is important that the effort needed to report failure is low, with is important that the effort needed to report failure is low, with
minimal impact to its main functions. To accomplish this goal, the minimal impact to its main functions. To accomplish this goal, the
DNS itself is utilized to report the error. DNS itself is utilized to report the error.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
DNS Terminology used in this document is from BCP 219 [RFC8499], with This document uses DNS terminology defined in BCP 219 [RFC9499].
these additions: This document also defines and uses the following terms:
Reporting resolver: In the context of this document, "reporting Reporting resolver: A validating resolver that supports DNS error
resolver" is used as a shorthand for a validating resolver that reporting.
supports DNS error reporting.
Report query: The DNS query used to report an error is called a Report query: The DNS query used to report an error. A report query
report query. A report query is for a DNS TXT resource record is for a DNS TXT resource record type. The content of the error
type. The content of the error report is encoded in the QNAME of report is encoded in the QNAME of a DNS request to the monitoring
a DNS request to the monitoring agent. agent.
Monitoring agent: An authoritative server that receives and responds Monitoring agent: An authoritative server that receives and responds
to report queries. This facility is indicated by a domain name, to report queries. This facility is indicated by a domain name,
referred to as the agent domain. referred to as the "agent domain".
Agent domain: A domain name which is returned in the DNS Error Agent domain: A domain name that is returned in the EDNS0 Report-
Reporting EDNS0 option that indicates where DNS resolvers can send Channel option and indicates where DNS resolvers can send error
error reports. reports.
4. Overview 4. Overview
An authoritative server indicates support for DNS error reporting by An authoritative server indicates support for DNS error reporting by
including an EDNS0 Report-Channel option with OPTION-CODE [TBD] and including an EDNS0 Report-Channel option with OPTION-CODE 18 and the
the agent domain in the response. The agent domain is a fully agent domain in the response. The agent domain is a fully qualified,
qualified, uncompressed domain name in DNS wire format. The uncompressed domain name in DNS wire format. The authoritative
authoritative server MUST NOT include this option in the response if server MUST NOT include this option in the response if the configured
the configured agent domain is empty, or is the null label (which agent domain is empty or is the null label (which would indicate the
would indicate the DNS root). DNS root).
The authoritative server includes the EDNS0 Report-Channel option The authoritative server includes the EDNS0 Report-Channel option
unsolicited. That is, the option is included in a response despite unsolicited. That is, the option is included in a response despite
the EDNS0 Report-Channel option being absent in the request. the EDNS0 Report-Channel option being absent in the request.
If the authoritative server has indicated support for DNS error If the authoritative server has indicated support for DNS error
reporting and there is an issue that can be reported via extended DNS reporting and there is an issue that can be reported via extended DNS
errors, the reporting resolver encodes the error report in the QNAME errors, the reporting resolver encodes the error report in the QNAME
of the report query. The reporting resolver builds this QNAME by of the report query. The reporting resolver builds this QNAME by
concatenating the _er label, the QTYPE, the QNAME that resulted in concatenating the "_er" label, the QTYPE, the QNAME that resulted in
failure, the extended error code (as described in [RFC8914]), the failure, the extended DNS error code (as described in [RFC8914]), the
label "_er" again, and the agent domain. See the example in label "_er" again, and the agent domain. See the example in
Section 4.1. Note that a regular RCODE is not included because the Section 4.1 and the specification in Section 6.1.1. Note that a
RCODE is not relevant to the extended error code. regular RCODE is not included because the RCODE is not relevant to
the extended DNS error code.
The resulting report query is sent as a standard DNS query for a TXT The resulting report query is sent as a standard DNS query for a TXT
DNS resource record type by the reporting resolver. DNS resource record type by the reporting resolver.
The report query will ultimately arrive at the monitoring agent. A The report query will ultimately arrive at the monitoring agent. A
response is returned by the monitoring agent, which in turn can be response is returned by the monitoring agent, which in turn can be
cached by the reporting resolver. This caching is essential. It cached by the reporting resolver. This caching is essential. It
dampens the number of report queries sent by a reporting resolver for dampens the number of report queries sent by a reporting resolver for
the same problem, that is, once per TTL. However, certain the same problem (that is, with caching, one report query per TTL is
optimizations such as [RFC8020] and [RFC8198] may reduce the number sent). However, certain optimizations, such as those described in
of error report queries as well. [RFC8020] and [RFC8198], may reduce the number of error report
queries as well.
This document gives no guidance on the content of the TXT resource This document gives no guidance on the content of the RDATA in the
record RDATA for this record. TXT resource record.
4.1. Example 4.1. Example
A query for "broken.test.", type A, is sent by a reporting resolver. A query for "broken.test.", type A, is sent by a reporting resolver.
The domain "test." is hosted on a set of authoritative servers. One The domain "test." is hosted on a set of authoritative servers. One
of these authoritative servers serves a stale version of the "test." of these authoritative servers serves a stale version of the "test."
zone. This authoritative server has an agent domain configured: zone. This authoritative server has an agent domain configured as
"a01.agent-domain.example.". "a01.agent-domain.example.".
The authoritative server with the stale "test." zone receives the The authoritative server with the stale "test." zone receives the
request for "broken.test". It returns a response that includes the request for "broken.test.". It returns a response that includes the
EDNS0 Report-Channel option with the domain name "a01.agent- EDNS0 Report-Channel option with the domain name "a01.agent-
domain.example.". domain.example.".
The reporting resolver is unable to validate the "broken.test" RRset The reporting resolver is unable to validate the "broken.test."
for type 1 (an A record), due to an RRSIG record with an expired RRset for type A (an RR type with value 1), due to an RRSIG record
signature. with an expired signature.
The reporting resolver constructs the QNAME The reporting resolver constructs the QNAME
"_er.1.broken.test.7._er.a01.agent-domain.example." and resolves it. "_er.1.broken.test.7._er.a01.agent-domain.example." and resolves it.
This QNAME indicates extended DNS error 7 occurred while trying to This QNAME indicates extended DNS error 7 occurred while trying to
validate "broken.test." type 1 record. validate "broken.test." for a type A (an RR type with value 1)
record.
When this query is received at the monitoring agent (the operators of When this query is received at the monitoring agent (the operators of
the authoritative server for a01.agent-domain.example), the agent can the authoritative server for "a01.agent-domain.example."), the agent
determine the "test." zone contained an expired signature record can determine the "test." zone contained an expired signature record
(extended error 7) for type A for the domain name "broken.test.". (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 The monitoring agent can contact the operators of "test." to fix the
issue. issue.
5. EDNS0 Option Specification 5. EDNS0 Option Specification
This method uses an EDNS0 [RFC6891] option to indicate the agent This method uses an EDNS0 [RFC6891] option to indicate the agent
domain in DNS responses. The option is structured as follows: domain in DNS responses. The option is structured as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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 = TBD | OPTION-LENGTH | | OPTION-CODE = 18 | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AGENT DOMAIN / / AGENT DOMAIN /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Field definition details: Field definition details:
OPTION-CODE: 2 octets; an EDNS0 code that is used in an EDNS0 option 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 to indicate support for error reporting. The name for this EDNS0
option code is Report-Channel. option code is Report-Channel.
OPTION-LENGTH: 2-octets; contains the length of the AGENT DOMAIN OPTION-LENGTH: 2 octets; contains the length of the AGENT DOMAIN
field in octets. field in octets.
AGENT DOMAIN: A fully qualified domain name [RFC8499] in AGENT DOMAIN: A fully qualified domain name [RFC9499] in
uncompressed DNS wire format. uncompressed DNS wire format.
6. DNS error reporting specification 6. DNS Error Reporting Specification
The various errors that a reporting resolver may encounter are listed The various errors that a reporting resolver may encounter are listed
in [RFC8914]. Note that not all listed errors may be supported by in [RFC8914]. Note that not all listed errors may be supported by
the reporting resolver. This document does not specify what is or is the reporting resolver. This document does not specify what is or is
not an error. not an error.
The DNS class is not specified in the error report. The DNS class is not specified in the error report.
6.1. Reporting Resolver Specification 6.1. Reporting Resolver Specification
Care should be taken when more DNS resolving is needed to resolve the Care should be taken when additional DNS resolution is needed to
error reporting QNAME. This resolving itself could trigger another resolve the QNAME that contains the error report. This resolution
error reporting to be created. A maximum expense or depth limit MUST itself could trigger another error report to be created. A maximum
be used to prevent cascading errors. expense or depth limit MUST be used to prevent cascading errors.
The EDNS0 Report-Channel option MUST NOT be included in queries. The EDNS0 Report-Channel option MUST NOT be included in queries.
The reporting resolver MUST NOT use DNS error reporting if the The reporting resolver MUST NOT use DNS error reporting if the
authoritative server returned an empty agent domain field in the authoritative server returned an empty AGENT DOMAIN field in the
EDNS0 Report-Channel option. EDNS0 Report-Channel option.
For the benefit of the monitoring agent to get more confidence that For the monitoring agent to gain more confidence that the report is
the report is not spoofed, the reporting resolver SHOULD send error not spoofed, the reporting resolver SHOULD send error reports over
reports over TCP [RFC7766] or other connection oriented protocols or TCP [RFC7766] or other connection-oriented protocols or SHOULD use
SHOULD use DNS COOKIEs [RFC7873]. This makes it harder to falsify DNS Cookies [RFC7873]. This makes it harder to falsify the source
the source address. address.
A reporting resolver MUST validate responses received from the A reporting resolver MUST validate responses received from the
monitoring agent. There is no special treatment for responses to monitoring agent. There is no special treatment for responses to
error-reporting queries. The Security Considerations section error-reporting queries. Section 9 ("Security Considerations")
contains the rationale behind this. contains the rationale behind this.
6.1.1. Constructing the Report Query 6.1.1. Constructing the Report Query
The QNAME for the report query is constructed by concatenating the The QNAME for the report query is constructed by concatenating the
following elements: following elements:
* A label containing the string "_er". * A label containing the string "_er".
* The QTYPE that was used in the query that resulted in the extended * 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. DNS error, presented as a decimal value, in a single DNS label.
If additional QTYPEs were present in the query, such as described If additional QTYPEs were present in the query, such as described
in [I-D.ietf-dnssd-multi-qtypes], they are represented as unique, in [MULTI-QTYPES], they are represented as unique, ordered decimal
ordered decimal values separated by a hyphen. As an example, if values separated by a hyphen. As an example, if both QTYPE A and
both QTYPE A and AAAA were present in the query, they are AAAA were present in the query, they are presented as the label
presented as the label "1-28". "1-28".
* The list of non-null labels representing the query name which is * The list of non-null labels representing the query name that is
the subject of the DNS error report. the subject of the DNS error report.
* The extended DNS error, presented as a decimal value, in a single * The extended DNS error code, presented as a decimal value, in a
DNS label. single DNS label.
* A label containing the string "_er". * A label containing the string "_er".
* The agent domain. The agent domain as received in the EDNS0 * The agent domain. The agent domain as received in the EDNS0
Report-Channel option set by the authoritative server. Report-Channel option set by the authoritative server.
If the report query QNAME exceeds 255 octets, it MUST NOT be sent. If the QNAME of the report query exceeds 255 octets, it MUST NOT be
sent.
The "_er" labels allow the monitoring agent to differentiate between The "_er" labels allow the monitoring agent to differentiate between
the agent domain and the faulty query name. When the specified agent the agent domain and the faulty query name. When the specified agent
domain is empty, or a null label (despite being not allowed in this domain is empty, or is a null label (despite being not allowed in
specification), the report query will have "_er" as a top-level this specification), the report query will have "_er" as a top-level
domain as a result and not the original query. The purpose of the domain, and not the top-level domain from the query name that was the
first "_er" label is to indicate that a complete report query has subject of this error report. The purpose of the first "_er" label
been received, instead of a shorter report query due to query is to indicate that a complete report query has been received instead
minimization. of a shorter report query due to query minimization.
6.2. Authoritative server specification 6.2. Authoritative Server Specification
The authoritative server MUST NOT include more than one EDNS0 Report- The authoritative server MUST NOT include more than one EDNS0 Report-
Channel option in a response. Channel option in a response.
The authoritative server includes the EDNS0 Report-Channel option The authoritative server includes the EDNS0 Report-Channel option
unsolicited in responses. There is no requirement that the EDNS0 unsolicited in responses. There is no requirement that the EDNS0
Report-Channel option is present in queries. Report-Channel option be present in queries.
6.3. Monitoring agent specification 6.3. Monitoring Agent Specification
It is RECOMMENDED that the authoritative server for the agent domain It is RECOMMENDED that the authoritative server for the agent domain
replies with a positive response (i.e., not NODATA or NXDOMAIN) reply with a positive response (i.e., not with NODATA or NXDOMAIN)
containing a TXT record. containing a TXT record.
The monitoring agent SHOULD respond to queries received over UDP that The monitoring agent SHOULD respond to queries received over UDP that
have no DNS COOKIE set with a response that has the truncation bit have no DNS Cookie set with a response that has the truncation bit
(TC bit) set to challenge the resolver to re-query over TCP. (TC bit) set to challenge the resolver to requery over TCP.
7. IANA Considerations 7. IANA Considerations
IANA is requested to assign the following DNS EDNS0 option code IANA has assigned the following in the "DNS EDNS0 Option Codes (OPT)"
registry: registry:
Value Name Status Reference +=======+================+==========+===========+
----- -------------- -------- --------------- | Value | Name | Status | Reference |
TBD Report-Channel Standard [this document] +=======+================+==========+===========+
| 18 | Report-Channel | Standard | RFC 9567 |
+-------+----------------+----------+-----------+
IANA is requested to assign the following Underscored and Globally Table 1
Scoped DNS Node Name registry:
RR Type _NODE NAME Reference IANA has assigned the following in the "Underscored and Globally
----- ---------- --------- Scoped DNS Node Names" registry:
TXT _er [this document]
+=========+============+===========+
| RR Type | _NODE NAME | Reference |
+=========+============+===========+
| TXT | _er | RFC 9567 |
+---------+------------+-----------+
Table 2
8. Operational Considerations 8. Operational Considerations
8.1. Choosing an agent domain 8.1. Choosing an Agent Domain
It is RECOMMENDED that the agent domain be kept relatively short to 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 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 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 authoritative server hosts the foo.example domain, then its agent
domain MUST NOT end in foo.example. domain MUST NOT end in foo.example.
8.2. Managing Caching Optimizations 8.2. Managing Caching Optimizations
The reporting resolver may utilize various caching optimizations that The reporting resolver may utilize various caching optimizations that
skipping to change at page 9, line 21 skipping to change at line 399
A solution is to avoid DNSSEC for the agent domain. Signing the A solution is to avoid DNSSEC for the agent domain. Signing the
agent domain will incur an additional burden on the reporting agent domain will incur an additional burden on the reporting
resolver, as it has to validate the response. However, this response resolver, as it has to validate the response. However, this response
has no utility to the reporting resolver other than dampening the has no utility to the reporting resolver other than dampening the
query load for error reports. query load for error reports.
9. Security Considerations 9. Security Considerations
Use of DNS error reporting may expose local configuration mistakes in Use of DNS error reporting may expose local configuration mistakes in
the reporting resolver, such as stale DNSSEC trust anchors to the the reporting resolver, such as stale DNSSEC trust anchors, to the
monitoring agent. monitoring agent.
DNS error reporting SHOULD be done using DNS query name minimization DNS error reporting SHOULD be done using DNS query name minimization
[RFC9156] to improve privacy. [RFC9156] to improve privacy.
DNS error reporting is done without any authentication between the DNS error reporting is done without any authentication between the
reporting resolver and the authoritative server of the agent domain. reporting resolver and the authoritative server of the agent domain.
Resolvers that send error reports SHOULD send these over TCP Resolvers that send error reports SHOULD send them over TCP [RFC7766]
[RFC7766] or SHOULD use DNS COOKIEs [RFC7873]. This makes it hard to or SHOULD use DNS Cookies [RFC7873]. This makes it hard to falsify
falsify the source address. The monitoring agent SHOULD respond to the source address. The monitoring agent SHOULD respond to queries
queries received over UDP that have no DNS COOKIE set with a response received over UDP that have no DNS Cookie set with a response that
that has the truncation bit (TC bit) set to challenge the resolver to has the truncation bit (TC bit) set to challenge the resolver to
re-query over TCP. requery over TCP.
Well-known addresses of reporting resolvers can provide a higher Well-known addresses of reporting resolvers can provide a higher
level of confidence in the error reports, and potentially enable more level of confidence in the error reports and potentially enable more
automated processing of these reports. automated processing of these reports.
Monitoring agents that receive error reports over UDP should consider Monitoring agents that receive error reports over UDP should consider
that the source of the reports and the reports itself may be false. that the source of the reports and the reports themselves may be
false.
The method described in this document will cause additional queries The method described in this document will cause additional queries
by the reporting resolver to authoritative servers in order to by the reporting resolver to authoritative servers in order to
resolve the report query. resolve the report query.
This method can be abused by intentionally deploying broken zones This method can be abused by intentionally deploying broken zones
with agent domains that are delegated to victims. This is with agent domains that are delegated to victims. This is
particularly effective when DNS requests that trigger error messages particularly effective when DNS requests that trigger error messages
are sent through open resolvers [RFC8499] or widely distributed are sent through open resolvers [RFC9499] or widely distributed
network monitoring systems that perform distributed queries from network monitoring systems that perform distributed queries from
around the globe. around the globe.
An adversary may create massive error report flooding to camouflage An adversary may create massive error report flooding to camouflage
an attack. an attack.
Though this document gives no guidance on the content of the TXT Though this document gives no guidance on the content of the RDATA in
resource record RDATA for this record, if the RDATA content is the TXT resource record, if the RDATA content is logged, the
logged, it MUST assume the content can be malicious and take monitoring agent MUST assume the content can be malicious and take
appropriate meassures to avoid exploitation. One such method could appropriate measures to avoid exploitation. One such method could be
be to log in hexadecimal. This would avoid remote code execution to log in hexadecimal. This would avoid remote code execution
through logging string attacks such as [CVE-2021-44228]. through logging string attacks, such as the vulnerability described
in [CVE-2021-44228].
The rationale behind mandating DNSSEC validation for responses from a The rationale behind mandating DNSSEC validation for responses from a
reporting agent, even if the agent domain is proposed to remain reporting agent, even if the agent domain is proposed to remain
unsigned, is to mitigate the risk of a downgrade attack orchestrated unsigned, is to mitigate the risk of a downgrade attack orchestrated
by adversaries. In such an attack, a victim's legitimately signed by adversaries. In such an attack, a victim's legitimately signed
domain could be deceptively advertised as an agent domain by domain could be deceptively advertised as an agent domain by
malicious actors. Consequently, if the validating resolver treats it malicious actors. Consequently, if the validating resolver treats it
as unsigned, it is exposed to potential cache poisoning attacks. By as unsigned, it is exposed to potential cache poisoning attacks. By
enforcing DNSSEC validation, this vulnerability is preemptively enforcing DNSSEC validation, this vulnerability is preemptively
addressed. addressed.
10. Acknowledgements 10. References
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.
11. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 10.2. Informative References
[CVE-2021-44228] [CVE-2021-44228]
Common Vulnerabilities and Exposures, "CVE-2021-44228", 10 CVE, "CVE-2021-44228", 26 November 2021,
December 2021, <https://cve.mitre.org/cgi-bin/ <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-
cvename.cgi?name=CVE-2021-44228>. 2021-44228>.
[I-D.ietf-dnssd-multi-qtypes] [MULTI-QTYPES]
Bellis, R., "DNS Multiple QTYPEs", Work in Progress, Bellis, R., "DNS Multiple QTYPEs", Work in Progress,
Internet-Draft, draft-ietf-dnssd-multi-qtypes-00, 4 Internet-Draft, draft-ietf-dnssd-multi-qtypes-00, 4
December 2023, <https://datatracker.ietf.org/doc/html/ December 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-dnssd-multi-qtypes-00>. draft-ietf-dnssd-multi-qtypes-00>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>. <https://www.rfc-editor.org/info/rfc2308>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
skipping to change at page 12, line 5 skipping to change at line 511
<https://www.rfc-editor.org/info/rfc7873>. <https://www.rfc-editor.org/info/rfc7873>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>. November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>. July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914, Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020, DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>. <https://www.rfc-editor.org/info/rfc8914>.
[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
Name Minimisation to Improve Privacy", RFC 9156, Name Minimisation to Improve Privacy", RFC 9156,
DOI 10.17487/RFC9156, November 2021, DOI 10.17487/RFC9156, November 2021,
<https://www.rfc-editor.org/info/rfc9156>. <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>.
Acknowledgements
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.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
ICANN ICANN
Email: roy.arends@icann.org Email: roy.arends@icann.org
Matt Larson Matt Larson
ICANN ICANN
Email: matt.larson@icann.org Email: matt.larson@icann.org
 End of changes. 63 change blocks. 
172 lines changed or deleted 182 lines changed or added

This html diff was produced by rfcdiff 1.48.