Reviewer: Yaron Sheffer Review result: Has Nits 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
