Viktor,
> On 11 Jul 2023, at 01:11, Viktor Dukhovni 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
