Hi Roy, I like the idea of an out-of-band error reporting and therefore I like the proposition of this draft.
One of the things I have a hard time visualizing though is how this could be used for more than reporting DNSSEC specific errors. With the option not being signed in the first place, it does not seem that DNSSEC is a requirement to be able to leverage this functionality, hence it would be great to think how we can make this work for more than DNSSEC-only errors. As it is, the requirement for the EDNS0 option to be in the response, while it does offer some properties such as controlling sampling rate…, essentially will prevent any report of answers which are not properly formatted in the first place, or never received like when a resolver is not able to reach any authorities for a given name, when resolver start falling back on staled data, and possibly in the future, failing to reach over an advertised encrypted channel… There is likely value for an authoritative resolver operator to be able to get report for those issues too. The title of the draft: "DNS Error Reporting" would let one believe that it is a somewhat generic mechanism, but I don't think it is as is. Actually, while DNSSEC is not named in the title/abstract, the examples in the abstract are DNSSEC specific, the wording in the rest of the document refers for the most part to "validating resolvers". Should this be a "DNSSEC Error Reporting" draft? or a "DNS Error Reporting" draft, but then the function of "validating" itself should be less emphasized? While a validating resolver can report more type of errors than a non-validating resolvers, validation is not a requirement to be able to report. On Tue, Nov 9, 2021 at 3:07 PM Roy Arends <[email protected]> wrote: > Dear WG, > > Change 3) There as a lot of descriptive text what implementations should > and shouldn’t do, and what configurations should and shouldn’t do. This was > found to be overly descriptive and pedantic, and has now been removed. > I see that the security consideration about not reporting errors from an encrypted channel (over a supposedly unencrypted channel) has been removed. Wouldn’t it make sense to leave it in order to avoid leaking traffic for queries that were not previously visible on the network? Possibly requiring than an encrypted channel (equal or stronger, for whatever definition that may be) is used to send such reports if needed? This would also make sure the mechanism is going to work once the ADo* mechanisms are ironed out. Thanks, Manu > > There was a request to put the markdown version of the document in GitHub. > This has now been placed here: > https://github.com/RoyArends/draft-ietf-dnsop-dns-error-reporting > > New version: > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01.txt > Diffs: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01 > > Warm regards, > > Roy Arends > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
