Skip to main content

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

Request Review of draft-ietf-dnsop-dns-error-reporting
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2023-10-30
Requested 2023-10-16
Authors Roy Arends , Matt Larson
I-D last updated 2023-11-05
Completed reviews Dnsdir Telechat review of -07 by James Gannon (diff)
Intdir Telechat review of -07 by Carlos Pignataro (diff)
Tsvart Telechat review of -07 by Gorry Fairhurst (diff)
Dnsdir Early review of -04 by James Gannon (diff)
Secdir Early review of -04 by Yaron Sheffer (diff)
Tsvart Last Call review of -06 by Gorry Fairhurst (diff)
Dnsdir Last Call review of -06 by David C Lawrence (diff)
Secdir Last Call review of -06 by Yaron Sheffer (diff)
Genart Last Call review of -06 by Peter E. Yee (diff)
Assignment Reviewer Peter E. Yee
State Completed
Request Last Call review on draft-ietf-dnsop-dns-error-reporting by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/3_abALrxwD69YBzgWnKxXfRB85k
Reviewed revision 06 (document currently at 08)
Result Ready w/nits
Completed 2023-11-05
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".