Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-05.txt

[Roy Arends <[e-mail]>]

Viktor,

> On 11 Jul 2023, at 01:11, Viktor Dukhovni <[e-mail]> wrote:
> 
> On Mon, Jul 10, 2023 at 03:48:34PM -0700, [e-mail] 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