Benno Overeinder <[email protected]> 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
