Viktor, > On 11 Jul 2023, at 01:11, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Mon, Jul 10, 2023 at 03:48:34PM -0700, internet-dra...@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This Internet-Draft is a work item of the Domain Name >> System Operations (DNSOP) WG of the IETF. >> >> Title : DNS Error Reporting >> Authors : Roy Arends >> Matt Larson >> Filename : draft-ietf-dnsop-dns-error-reporting-05.txt >> Pages : 11 >> Date : 2023-07-10 > > Some comments on on the -05 update. > > * Spelling: s/unsollicited/unsolicited/
Ack. Will fix. > > * Substance: The new text suggests using TCP **and** cookies: > > Resolvers that send error reports SHOULD send these over TCP > [RFC7766] and SHOULD use DNS COOKIEs [RFC7873]. This makes it > hard to falsify the source address. The monitoring agent SHOULD > respond to queries received over UDP with the truncation bit (TC > bit) set to challenge the resolver to re-query over TCP. > > I don't believe it is at all common to combine TCP with cookies, > typically cookies are used over UDP, with fallback to TCP (sans > cookies) if the server's cookie is missing or invalid. > > So above should be "either TCP **or** COOKIES". If error reports are > infrequent no recent cookies will be cached for the monitoring agent, > and obtaining a cookie will require a round trip. So perhaps simplest > to just use TCP. Will fix. > I don't yet see any text about rate-limiting of reports beyond per > qname/qtype/info-code caching. And yet the resolver has significant > additional context: > > - The IP address of the problem nameserver. > > * It can rate-limit the frequency of reports per nameserver IP. > > - The server zone. > > * It can rate-limit the frequency of reports per zone. > > The per IP limit can be significantly more "generous", than the per-zone > limit, because some nameservers serve O(1M) zones, of which a few > thousand might exhibit a problem, while the server's overall health is > fine. Reports for many different qnames in the same zone are likely > to be substantially redundant. If the resolver has rate-limiting features, it should apply them to these queries as well, and not ring fence these queries as special. I am not willing to over-specify the resolver behaviour for this. I am willing to specify that any rate limiting features should also apply to these queries. Roy _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
