Hi Roy, Please see some responses below, prefixed with YS.
Thanks, Yaron On 05/07/2023, 14:31, "Roy Arends" <r...@dnss.ec <mailto:r...@dnss.ec>> wrote: Yaron, many thanks for your review. Comments inline: > On 26 Jun 2023, at 13:24, Yaron Sheffer via Datatracker <nore...@ietf.org > <mailto:nore...@ietf.org>> wrote: > > Reviewer: Yaron Sheffer > Review result: Has Nits > > I am not a DNS expert so these may or may not be real issues. But I would > appreciate the authors' clarifications. > > - The error reports are unauthenticated. Some possible implications include: > (1) Operators may choose to implement automated responses to error reports, > and > will not consider that the source of the reports is untrusted. > (2) An adversary > may create massive error report flooding to camouflage an attack. At minimum, > I > suggest to mention these risks in the security considerations. Will do. > > - "Authentication significantly increases the burden on the reporting resolver > without any benefit to the monitoring agent, authoritative server or reporting > resolver." I'm not sure I agree there's no benefit: a known, trusted set of > reporting resolvers can provide a higher level of confidence in the error > reports, and potentially enable more automated processing of these reports. > CDNs may become such trusted resolvers, for example. I will tone down the dismissive language and just use the following: "Authentication significantly increases the burden on the reporting resolver, however, a known, trusted set of reporting resolvers can provide a higher level of confidence in the error reports, and potentially enable more automated processing of these reports.” (I’ve used your text as guidance) YS: I'm not sure I understand the proposed text, because the draft does not provide a way (namely, authentication) to establish a "known, trusted set of resolvers". Unless there's a way to authenticate these reports that I'm not familiar with. > - In general, is there value to error reporting in the absence of (aggregated) > reporting on success? In other words, when evaluating a stream of errors, > isn't > it important to measure the percentage of errors as part of the overall number > of requests for a particular domain? Absolutely. However, I wanted to avoid predicting how the reporting agent is going to implement its analysis and reporting functions. YS: understood. It just seems to me that we're not providing the agent with enough input for this analysis. And I guess I was suggesting to add a feature: aggregated (or random, sample based) reporting on *successful* name resolution. > - This is yet another DNS covert channel. Should we mention it in the Security > Considerations? Is it though? If it is, isn’t all DNS susceptible to being a covert channel? Isn’t any traffic, not just DNS, susceptible of being another covert channel? YS: fair enough. > - What is the broader effect of avoiding DNSSEC for the agent domain? Does it > interfere with policies (and their automated enforcement) such as "sign > everything under .tld"? This should be dealt with in the relevant policy area. > - More formally, there is no normative language around avoiding DNSSEC. Is it > a > SHOULD? YS: even if you deem DNSSEC policy to be out of scope, the question about normative language still stands. Or at least guidance on when this mitigation is recommended. > > - DNS query name minimization - shouldn't there be some guidance on this? > Clearly minimization does not apply to the actual error portion of the report > QNAME. Clearly? An agent domain can setup its servers in various ways, say, a single agent domain “uk.error.com”, and subsequently delegate: uk._er.uk <http://er.uk/>.error.com <http://er.uk/>.error.com> co.uk <http://co.uk/>._er.uk.error.com <http://co.uk/>._er.uk.error.com> <http://er.uk.error.com/> <http://er.uk.error.com/>> police.uk <http://police.uk/>._er.uk.error.com <http://police.uk/>._er.uk.error.com> <http://er.uk.error.com/> <http://er.uk.error.com/>> Some_org.co.uk._er.uk.error.com <http://er.uk.error.com/> <http://er.uk.error.com/>> You’ll see that a single error for “example.co.uk <http://example.co.uk/> <http://example.co.uk/>>” may be delegated a few times before it reaches the target server. Hope this helps, Thanks for the review Yaron! Warmly, Roy > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > <https://www.ietf.org/mailman/listinfo/dnsop> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop