Re: [DNSOP] DNSOPWorking Group Last call for draft-ietf-dnsop-dns-error-reporting

[Roy Arends <[e-mail]>]

> On 9 Jun 2023, at 16:38, Wes Hardaker <[e-mail]> wrote:
> 
> Benno Overeinder <[e-mail]> writes:
> 
>> This starts a Working Group Last Call for:
>> draft-ietf-dnsop-dns-error-reporting.
> 
> Overall: I support the publication of this document and believe it is a
> good addition to the DNS specifications.
> 
> Some suggestions:
> 
> - section 1: "reported via social media" -> "report via E-Mail or social
>  media" -- anyone subscribed to dns-operations and various *og lists
>  will know that a lot of errors are reported to operational communities
>  over email.

Ack. Will add.

> - Terminology: Why is a reporting resolver listed as validating here?
>  From what I can tell from the rest of the document, this should be a
>  more generic reporting mechanism even if the examples are DNSSEC
>  related.  The EDE document has many errors that have nothing to do
>  with DNSSEC (filtering being one example).

Ack. Will remove the term.

> - Terminology: Report Query's last sentence is hard to read.  Maybe "The
>  content of the error report is encoded in the QNAME of a DNS request
>  to the reporting agent."

Better. Will change.

> - TBD: Terminology: Monitoring agent: I'm not sure that the monitoring agent
>  has to respond or not?

The monitoring agent has to respond. This will dampen the amount of subsequent requests if the reporting resolver caches the response. That is a good thing. Leaving a request without a response may cause timeouts and re-querying, eating up resources.

Thanks for the heads-up, will make it clear!

> - Terminology: Agent Domain isn't really describing what the agent
>  domain actually is used for, but rather just where it's encoded.  How
>  about "A domain name which is returned in the DNS Error Reporting
>  EDNS0 option that indicates where DNS resolvers can send error reports."

Better.

> - section 5: option-code "indicates error reporting support is TBD".  I
>  suggest it would more clearly understood if it included a reference to
>  the fact it's an EDNS0 code: "an EDNS0 code that is used in an EDNS0
>  option to indicate support for error reporting.  The name for this
>  EDNS0 option code is Report-Channel"

Ack. Better. Will change.

> - 6.1 reporting resolver specification: "The EDNS0 report channel option
>  MUST NOT be included in queries" -- above you label it as
>  "Report-Channel" and I suggest you be consistent with the usage
>  everywhere (I didn't check if "report channel" in lower case with a
>  space exists elsewhere too)

Will make it consistent.

> - 6.2: I'm not sure the reason behind this requirement.  Why would it
>  matter if more than one agent supported *receiving* reports?  I think
>  the real requirement should be that authoritative servers SHOULD only
>  send a single reporting agent to a client and thus only a single
>  Reporting Channel EDNS0 option.  (I could even argue this should be a
>  MUST.)  But on the server side (either the authoritative server or the
>  report-receiving authoritative server) I don't see the point in
>  putting this restriction on them.

Ack. The intent was always to have a single agent domain in a response, not more. I “translated” this requirement back to simply have a single one per zone, to avoid the specification of a selection algorithm that specifies which agent domain (if there is more than one) to send back.

> - security considerations: In the last paragraph I'd mention that there
>  is a concern that large measurement query networks (RIPE atlas) or
>  bot-networks could misuse this and likely achieve an amplification
>  attack against a name put in the reporting option.  I actually wonder
>  if it would be good to put in a time-bound rate limit to the number of
>  error reports that should be sent anywhere as I have concerns that
>  this could be too easily misused and caching may not be a completely
>  sufficient mitigation.

That, IMHO is already captured by the last paragraph. I did not explicitly write a recipe of how to do that, and which servers could be used for that :-). Could you suggest text to improve the last paragraph without naming services?

Thanks Wes, this is really helpful and much appreciated.

Warmly,

Roy

> 
> -- 
> Wes Hardaker
> USC/ISI
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop