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

[Viktor Dukhovni <[e-mail]>]

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/

* 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.

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.

-- 
    Viktor.