Hi Paul, > On 13 Dec 2023, at 02:18, Paul Wouters via Datatracker <nore...@ietf.org> > wrote: > > 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!-9fTr-2RRG09dHnz39uLcrAci6nlcN56ehFD79sPYiVBz9R5TuAxXCCdbYC-_7P2BpkvQ9vXeHUme3sQp-316Q$ > [ietf[.]org] > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/__;!!PtGJab4!-9fTr-2RRG09dHnz39uLcrAci6nlcN56ehFD79sPYiVBz9R5TuAxXCCdbYC-_7P2BpkvQ9vXeHUme3tZroFZtw$ > [datatracker[.]ietf[.]org] > > > > ---------------------------------------------------------------------- > 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 ?
It is explicitly specified in section 3: A report query is for a DNS TXT resource record type. And again explicitly in section 4: The resulting report query is sent as a standard DNS query for a TXT DNS resource record type by the reporting resolver. > 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) Will add it here as well, just to be complete. > While no guidance on (TXT?) Yes, as explicitly written in section 4: This document gives no guidance on the content of the TXT resource record RDATA for this record. > 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. Can you provide an example of such consideration? Or a reference to one in an existing document? > 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. This is to avoid cascading errors. > 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. I don’t understand. Error reporting should be done if foobar.fi fails to validate, but should abort if foobar.fi fails to resolve? > 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. I will add that to 6.4 “choosing an agent domain" > 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? That is correct. As of the publication of the latest version of this draft, there is no such thing as multiple q-types. If that ever comes to fruition in the global DNS, I will do a error-reporting-bis. Warmly, Roy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
