Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

Hi Roy,

It seems those 2 paragraphs are conflicting with each others:

On the one hand the aggressive use of DNSSEC-validated cache is suggested
for the reporting agent:

```

This caching is essential.  It ensures that the number of reports
   sent by a reporting resolver for the same problem is dampened, i.e.
   once per TTL, however, certain optimizations such as [RFC8020
<https://datatracker.ietf.org/doc/html/rfc8020>] and

   [RFC8198 <https://datatracker.ietf.org/doc/html/rfc8198>] may reduce the
number of error reporting queries as well.
```

But on the other hand, it is not recommended to sign the reporting agent domain.

```
A solution is to avoid DNSSEC for the reporting agent domain.
   Signing the agent domain will incur an additional burden on the
   reporting resolver, as it has to validate the response.  However,

   this response has no utility to the reporting resolver.
```

Manu

On Tue, Nov 9, 2021 at 3:07 PM Roy Arends <roy@dnss.ec> wrote:

> Dear WG,
>
> After the October 26, IETF DNSOP interim WG on DNS Error Reporting, the
> document editors have made the following changes to reflect the discussion:
>
> Change 1) Due to qname minimisation, the reporting agent may not know that
> the reported string has been shortened. There were a few options suggested,
> such as adding a label counter. However, the most straightforward option
> seemed to be to start the reporting query with an _er label as well.
>
> Change 2) There was an observation by developers that some authoritative
> servers do not parse (unknown) EDNS0 options correctly, leading to an
> additional roundtrip by the resolver. It was suggested that authoritative
> servers could return the new EDNS0 option “unsolicited”. This is already
> the case for Extended DNS errors. We have adopted this suggestion. It was
> also pointed out that this kind of unsolicited behaviour can be surveyed.
> We believe that one such effort is underway.
>
> Change 3) There as a lot of descriptive text what implementations should
> and shouldn’t do, and what configurations should and shouldn’t do. This was
> found to be overly descriptive and pedantic, and has now been removed.
>
> There was a request to put the markdown version of the document in GitHub.
> This has now been placed here:
> https://github.com/RoyArends/draft-ietf-dnsop-dns-error-reporting
>
> New version:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01.txt
> Diffs:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01
>
> Warm regards,
>
> Roy Arends
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>