Last Call Review of draft-ietf-dnsop-dns-error-reporting-06
review-ietf-dnsop-dns-error-reporting-06-genart-lc-yee-2023-11-05-00
review-ietf-dnsop-dns-error-reporting-06-genart-lc-yee-2023-11-05-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-dnsop-dns-error-reporting-06 Reviewer: Peter Yee Review Date: 2023-11-05 IETF LC End Date: 2023-10-30 IESG Telechat date: Not scheduled for a telechat Summary: This is an interesting re-use of DNS to report DNS resolving errors to a monitoring agent. The approach seems straightforward as written. I have minor concerns (some arising from not having a deep background in DNS) and there are a couple of nits. [Ready with nits] Major issues: N/A Minor issues: It seems like this would make every single response to a query larger due to including the agent domain in the response. I don't know if this added burden (even to resolvers that don't understand the Reporting-Channel option) will cause problems, but it certainly might make some responses too large for a UDP response. I'm guessing that the additional bytes sent aren't expected to be problematic from an overall bandwidth perspective for most authoritative servers. This scheme does feel like something of a hack (in the grand tradition of DNS hackery), burying so much information in the QNAME, but I suppose this reuse is more likely to be implemented than using some other logging protocol that might not already be built into DNS resolvers nor have the caching abilities that are used to reduce the number of queries to the agent to report errors. Nits/editorial comments: Append a comma to the one occurrence of "i.e.". Change "Well known" to "Well-known".