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

[Wes Hardaker <[e-mail]>]

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.

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

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

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

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

- 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"

- 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)

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

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


-- 
Wes Hardaker
USC/ISI