Early Review of draft-ietf-dnsop-dns-error-reporting-04
review-ietf-dnsop-dns-error-reporting-04-secdir-early-sheffer-2023-06-26-00

I am not a DNS expert so these may or may not be real issues. But I would
appreciate the authors' clarifications.

- The error reports are unauthenticated. Some possible implications include:
(1) Operators may choose to implement automated responses to error reports, and
will not consider that the source of the reports is untrusted. (2) An adversary
may create massive error report flooding to camouflage an attack. At minimum, I
suggest to mention these risks in the security considerations.

- "Authentication significantly increases the burden on the reporting resolver
without any benefit to the monitoring agent, authoritative server or reporting
resolver." I'm not sure I agree there's no benefit: a known, trusted set of
reporting resolvers can provide a higher level of confidence in the error
reports, and potentially enable more automated processing of these reports.
CDNs may become such trusted resolvers, for example.

- In general, is there value to error reporting in the absence of (aggregated)
reporting on success? In other words, when evaluating a stream of errors, isn't
it important to measure the percentage of errors as part of the overall number
of requests for a particular domain?

- This is yet another DNS covert channel. Should we mention it in the Security
Considerations?

- What is the broader effect of avoiding DNSSEC for the agent domain? Does it
interfere with policies (and their automated enforcement) such as "sign
everything under .tld"?

- More formally, there is no normative language around avoiding DNSSEC. Is it a
SHOULD?

- DNS query name minimization - shouldn't there be some guidance on this?
Clearly minimization does not apply to the actual error portion of the report
QNAME.