> On 9 Jun 2023, at 16:38, Wes Hardaker <[email protected]> wrote: > > Benno Overeinder <[email protected]> writes: > >> This starts a Working Group Last Call for: >> draft-ietf-dnsop-dns-error-reporting. > > Overall: I support the publication of this document and believe it is a > good addition to the DNS specifications. > > Some suggestions: > > - section 1: "reported via social media" -> "report via E-Mail or social > media" -- anyone subscribed to dns-operations and various *og lists > will know that a lot of errors are reported to operational communities > over email.
Ack. Will add. > - Terminology: Why is a reporting resolver listed as validating here? > From what I can tell from the rest of the document, this should be a > more generic reporting mechanism even if the examples are DNSSEC > related. The EDE document has many errors that have nothing to do > with DNSSEC (filtering being one example). Ack. Will remove the term. > - Terminology: Report Query's last sentence is hard to read. Maybe "The > content of the error report is encoded in the QNAME of a DNS request > to the reporting agent." Better. Will change. > - TBD: Terminology: Monitoring agent: I'm not sure that the monitoring agent > has to respond or not? The monitoring agent has to respond. This will dampen the amount of subsequent requests if the reporting resolver caches the response. That is a good thing. Leaving a request without a response may cause timeouts and re-querying, eating up resources. Thanks for the heads-up, will make it clear! > - Terminology: Agent Domain isn't really describing what the agent > domain actually is used for, but rather just where it's encoded. How > about "A domain name which is returned in the DNS Error Reporting > EDNS0 option that indicates where DNS resolvers can send error reports." Better. > - section 5: option-code "indicates error reporting support is TBD". I > suggest it would more clearly understood if it included a reference to > the fact it's an EDNS0 code: "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" Ack. Better. Will change. > - 6.1 reporting resolver specification: "The EDNS0 report channel option > MUST NOT be included in queries" -- above you label it as > "Report-Channel" and I suggest you be consistent with the usage > everywhere (I didn't check if "report channel" in lower case with a > space exists elsewhere too) Will make it consistent. > - 6.2: I'm not sure the reason behind this requirement. Why would it > matter if more than one agent supported *receiving* reports? I think > the real requirement should be that authoritative servers SHOULD only > send a single reporting agent to a client and thus only a single > Reporting Channel EDNS0 option. (I could even argue this should be a > MUST.) But on the server side (either the authoritative server or the > report-receiving authoritative server) I don't see the point in > putting this restriction on them. Ack. The intent was always to have a single agent domain in a response, not more. I “translated” this requirement back to simply have a single one per zone, to avoid the specification of a selection algorithm that specifies which agent domain (if there is more than one) to send back. > - security considerations: In the last paragraph I'd mention that there > is a concern that large measurement query networks (RIPE atlas) or > bot-networks could misuse this and likely achieve an amplification > attack against a name put in the reporting option. I actually wonder > if it would be good to put in a time-bound rate limit to the number of > error reports that should be sent anywhere as I have concerns that > this could be too easily misused and caching may not be a completely > sufficient mitigation. That, IMHO is already captured by the last paragraph. I did not explicitly write a recipe of how to do that, and which servers could be used for that :-). Could you suggest text to improve the last paragraph without naming services? Thanks Wes, this is really helpful and much appreciated. Warmly, Roy > > -- > Wes Hardaker > USC/ISI > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
