Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dns-error-reporting-07: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document gives no guidance on the content of the TXT resource record RDATA for this record. Based on this, I assume the error report query is of qtype TXT, but this is not specified anywhere in the document. Someone could use a qtype of CNAME or ANY or just A or AAAA. Can this be stated explicitly ? In Section 6.1.1. Constructing the Report Query, only the QNAME construction is documented, not the QTYPE (or CLASS but there is a reference that says only IN is supported) While no guidance on (TXT?) RDATA sending is fine, there should really be a Security Consideration on what to do with any RDATA. Let's avoid another vector for log4j. The reporting resolver MUST NOT use DNS error reporting to report a failure in resolving the report query. This might be tricky to implement. The resolver might not know why another thread is resolving some A/AAAA record. For example if nohats.ca uses a reporting fqdn of foobar.fi, why shouldn't validation failures on foobar.fi try to report that to foobar.fi, if they themselves use a reporting fqdn. Similarly, recommending disabling DNSSEC for these queries can be tricky, if resolving the reporting fqdn requires a number of related DNS queries for NS, DS, A/AAAA, CNAMEs). I think it is better to not recommend this and let failures be failures. If the reporting fqdn fails to resolve, abort trying to report the failure. Which of course brings up: Should there be a consideration for the reporting fqdn not being in-domain ? eg ns1.nohats.ca serving nohats.ca should probably not use er.nohats.ca. The er QNAME construction assumes there was only 1 QTYPE. There are drafts being floated that have more than one QTYPE. How to construct the QNAME for those? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
