DNS Error Reporting
draft-ietf-dnsop-dns-error-reporting-08

Thanks for this useful and readable specification. I have one comment –

Section 6.1 says, “The EDNS0 Report-Channel option MUST NOT be included in queries.” Section 6.2 says, “There is no requirement that the EDNS0 Report-Channel option is present in queries.” While the two are not technically in conflict, the second understates; it seems like you could, and should, remove it. But perhaps there’s some subtlety I’m not understanding here.

This is a cool idea.  Thanks for advancing it.

I support Paul's DISCUSS position.

In the shepherd writeup, when there are implementations, it's helpful to include names or links to them.

Thank you to Yaron Sheffer for the SECDIR review.

Thanks for working on this specification. Thanks to Gorry for the TSVART review.


I have only two questions 

 - is this protocol (error reporting) not applicable to DoQ? The question came as TCP is the preferred transport and only tells what to do when UDP is used for queries and reports, so wondering what happens when QUIC is as transport for DNS. 

 - what would be a typical rate of error reporting?

Thanks to Gorry Fairhurst for the TSVART review -- I would appreciate an email response to that review, though I think you've addressed more or all of the comments.

Hi,

Thanks for this document.

DNS really isn't my area of expertise, and it may be that if I was very familiar with DNS and DNS deployment then the approach taken here for error reporting would seems like the obvious and pragmatic choice.  Specifically, I do appreciate that this is a lightweight solution, and the solution may well be good enough to achieve its goals of better error reporting without too much effort and without causing too much confusion.

But, without the domain knowledge, I'm not particularly enamored on the approach of overloading the error reporting onto the basic DNS query mechanism rather than a separate message type or channel.  It feels a bit like if the only thing that you have is a hammer, then everything looks like a nail ... and ultimately I'm concerned that the error reports that looks like a query, but are not really a query, may end up being confusing in logs, debugging, etc., for non-expert users.  Hopefully, this doesn't happen when it gets deployed, and if it does then I guess that the plan B option of deprecating this approach and specifying a more heavyweight out of band mechanism always exists.