DNS Error Reporting
How a validating resolver tells an authoritative server's operator about DNS failures by sending one specially named query.
Arends, R. and M. Larson, "DNS Error Reporting", RFC 9567, DOI 10.17487/RFC9567, April 2024, <https://www.rfc-editor.org/info/rfc9567>.
@misc{rfc9567,
series = {Request for Comments},
number = 9567,
howpublished = {RFC 9567},
publisher = {RFC Editor},
doi = {10.17487/RFC9567},
url = {https://www.rfc-editor.org/info/rfc9567},
author = {R. Arends and M. Larson},
title = {{DNS Error Reporting}},
pagetotal = 11,
year = 2024,
month = apr,
} RFC text
Contents
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
Abstract
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.
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.
Status of This Memo
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.
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 (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
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
1. Introduction
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.
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.
These are two of several failure scenarios that may go unnoticed for
some time by the operator of a zone.
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.
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.
2. Requirements Notation
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.
3. Terminology
This document uses DNS terminology defined in BCP 219 [RFC9499].
This document also defines and uses the following terms:
Reporting resolver: A validating resolver that supports DNS error
reporting.
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.
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.
4. Overview
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).
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.
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.
The resulting report query is sent as a standard DNS query for a TXT
DNS resource record type by the reporting resolver.
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.
This document gives no guidance on the content of the RDATA in the
TXT resource record.
4.1. Example
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
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.".
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.".
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.
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.
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.
5. EDNS0 Option Specification
This method uses an EDNS0 [RFC6891] option to indicate the agent
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
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.
OPTION-LENGTH: 2 octets; contains the length of the AGENT DOMAIN
field in octets.
AGENT DOMAIN: A fully qualified domain name [RFC9499] in
uncompressed DNS wire format.
6. DNS Error Reporting Specification
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.
The DNS class is not specified in the error report.
6.1. Reporting Resolver Specification
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.
The EDNS0 Report-Channel option MUST NOT be included in queries.
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.
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.
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.
6.1.1. Constructing the Report Query
The QNAME for the report query is constructed by concatenating the
following elements:
* A label containing the string "_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".
* The list of non-null labels representing the query name that is
the subject of the DNS error report.
* The extended DNS error code, presented as a decimal value, in a
single DNS label.
* A label containing the string "_er".
* The agent domain. The agent domain as received in the EDNS0
Report-Channel option set by the authoritative server.
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 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.
6.2. Authoritative Server Specification
The authoritative server MUST NOT include more than one EDNS0 Report-
Channel option in a response.
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.
6.3. Monitoring Agent Specification
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.
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.
7. IANA Considerations
IANA has assigned the following in the "DNS EDNS0 Option Codes (OPT)"
registry:
+=======+================+==========+===========+
| 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:
+=========+============+===========+
| RR Type | _NODE NAME | Reference |
+=========+============+===========+
| TXT | _er | RFC 9567 |
+---------+------------+-----------+
Table 2
8. Operational Considerations
8.1. Choosing an Agent Domain
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.
8.2. Managing Caching Optimizations
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].
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.
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.
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.
9. Security Considerations
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 error reporting SHOULD be done using DNS query name minimization
[RFC9156] to improve privacy.
DNS error reporting is done without any authentication between the
reporting resolver and the authoritative server of the agent domain.
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.
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.
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.
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].
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.
10. References
10.1. Normative References
[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>.
10.2. Informative References
[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>.
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
Roy Arends
ICANN
Email: roy.arends@icann.org
Matt Larson
ICANN
Email: matt.larson@icann.org
AI ELI5
On this page
§1The Problem of Silent Failures
A zone can fail without its operator noticing. An authoritative server may serve a stale DNSSEC-signed zone whose signatures have lapsed, or the Delegation Signer (DS) records at the parent may not match the key signing key in the child. In both cases a validating resolver fails to validate the records.
The RFC notes that there is no direct relationship between operators of validating resolvers and authoritative servers. Outages are usually noticed indirectly by end users, and any sign of the error may be buried in resolver logs or not logged at all.
DNS error reporting lets an authoritative server name a monitoring agent, and lets validating resolvers that are configured for it report problems there. The burden falls on the resolver, so the effort is kept low by using DNS itself to carry the report.
If a street sign falls down, the town may not notice until someone tells them. This gives drivers an easy way to drop a note in the town's mailbox.
§4How Error Reporting Works
An authoritative server announces support by adding an EDNS0 Report-Channel option, OPTION-CODE 18, to its response. The option carries the agent domain. The server includes it unsolicited, meaning even when the request did not contain the option. It MUST NOT include the option if the configured agent domain is empty or the null label.
When a reporting resolver meets an issue that can be described by an extended DNS error (RFC 8914), it builds a report query: a TXT query whose QNAME encodes the error. The query ultimately reaches the monitoring agent, which returns a response that the resolver can cache. This caching is essential, because it limits reports to about one report query per TTL for the same problem.
The RFC gives no guidance on the content of the TXT record data in the response.
A server hangs up a sign saying 'send problem notes to this mailbox'. A helper who finds a problem writes the details right on the envelope, so just mailing it is the whole report.
§5The Report-Channel Option and Report Query
The EDNS0 option has an OPTION-CODE of 18 (2 octets), an OPTION-LENGTH (2 octets) giving the length of the agent domain field in octets, and an AGENT DOMAIN, a fully qualified domain name in uncompressed DNS wire format.
The report query QNAME is built by concatenating, in order:
- a label
_er; - the QTYPE as a decimal value in a single label (several QTYPEs are joined by hyphens in ordered form, such as
1-28); - the labels of the query name that failed;
- the extended DNS error code as a decimal value in a single label;
- a second
_erlabel; - the agent domain.
If the resulting QNAME exceeds 255 octets, it MUST NOT be sent. The two _er labels let the monitoring agent tell the agent domain from the faulty name; the first one also shows that a complete report query arrived rather than a shorter one produced by query minimization. The DNS class is not included in the report.
The report is an address that spells out what went wrong, such as 'type A, broken.test, error 7'. Reading the address tells the agent everything.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
OPTION-CODE | OPTION-CODE | 2 bytes | 18 | EDNS0 option code for error reporting. |
OPTION-LENGTH | OPTION-LENGTH | 2 bytes | Length of the agent domain field in octets. |
§4.1A Worked Example
A reporting resolver queries broken.test. for type A. One authoritative server for test. serves a stale version of the zone and has the agent domain a01.agent-domain.example., which it returns in the Report-Channel option.
The resolver cannot validate the A RRset because an RRSIG record has an expired signature. It builds and resolves the QNAME _er.1.broken.test.7._er.a01.agent-domain.example.. This says that extended DNS error 7 occurred while validating broken.test. for type A (RR type 1).
The operators of the monitoring agent see the query, learn that test. had an expired signature, and can contact the operators of test. to fix it.
The note says 'the sign for broken.test has a stale date', and the town hall can phone the person in charge of that sign.
- Query broken.test. A
- Response with Report-Channel optionAgent domain a01.agent-domain.example.
- TXT _er.1.broken.test.7._er.a01.agent-domain.example.Reports extended DNS error 7.
- TXT response
§6Rules for Each Party
Reporting resolvers must use a maximum expense or depth limit so that resolving the report QNAME cannot trigger cascading error reports. They MUST NOT include the Report-Channel option in queries, and MUST NOT report if the authoritative server returned an empty agent domain. To give the agent confidence that a report is not spoofed, they SHOULD send reports over TCP or other connection-oriented protocols, or SHOULD use DNS Cookies. They MUST validate responses from the agent like any other.
Authoritative servers MUST NOT include more than one Report-Channel option in a response.
Monitoring agents are RECOMMENDED to answer with a positive response containing a TXT record, not NODATA or NXDOMAIN. They SHOULD answer UDP queries that have no DNS Cookie with the truncation (TC) bit set, challenging the resolver to retry over TCP.
Each helper has a job. The one who reports checks they are not starting an endless chain of notes, and the one who receives asks 'prove it is really you' before trusting a note.
§8Choosing an Agent Domain and Caching
The agent domain is RECOMMENDED to be short, leaving room for a longer QNAME. It MUST NOT be a subdomain of the domain it reports on: a server hosting foo.example must not use an agent domain ending in foo.example.
Caching can suppress later reports. If the agent answered NXDOMAIN, resolvers following RFC 8020 would treat everything at or below that name as unreachable, and negative caching would block further queries for a time. The monitoring agent therefore MUST NOT respond with NXDOMAIN for domains it monitors. One approach is a wildcard in the agent domain's zone.
If the agent domain is signed, aggressive negative caching (RFC 8198) may let the resolver synthesize answers and stop sending reports. The RFC suggests avoiding DNSSEC for the agent domain, since the response has no use to the resolver beyond dampening report load.
If the mailbox keeps saying 'nobody lives here', helpers stop sending mail. So the agent must always answer with something friendly.
§9Security and Privacy
Reports can expose local mistakes in the reporting resolver, such as stale DNSSEC trust anchors, to the monitoring agent. Reporting SHOULD use DNS query name minimization (RFC 9156) to improve privacy.
There is no authentication between the reporting resolver and the agent domain's authoritative server. That is why resolvers should use TCP or DNS Cookies, and why agents receiving reports over UDP should consider that the source and the contents may be false. Well-known addresses of reporting resolvers can raise confidence in reports.
The method causes additional queries to authoritative servers. It can also be abused by deliberately deploying broken zones whose agent domains are delegated to victims, especially when triggering queries are sent through open resolvers or widely distributed network monitoring systems.
Anyone can write a note, so the town hall should be careful not to believe every one, and nobody should be tricked into flooding a neighbor's mailbox.