Re: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-error-reporting-07: (with DISCUSS)
Sent from my iPhoneOn Dec 13, 2023, at 1:32 PM, Warren Kumari wrote:On Tue, Dec 12, 2023 at 9:18 PM, Paul Wouterswrote: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 . Can this be stated explicitly ?Erm, I think that it is? Section 3. Terminology" Report query: The DNS query used to report an error is called a report query. A report query is for a DNS TXT resource record type. The content of the error report is encoded in the QNAME of a DNS request to the monitoring agent."Section 4. Overview"The resulting report query is sent as a standard DNS query for a TXT DNS resource record type by the reporting resolver."7. IANA Considerations "IANA is requested to assign the following Underscored and Globally Scoped DNS Node Name registry: RR Type _NODE NAME Reference - -- - TXT _er [this document]" 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.Yup, this is a good point — the document says:" It is RECOMMENDED that the authoritative server for the agent domain replies with a positive response (i.e. not NODATA or NXDOMAIN) containing a TXT record.". Would simply noting that this is untrusted data and should be sanitized / something before stuffing it into logs / displaying it / etc? Maybe recommend or even require that such a TXT be an empty record (length zero), or something like that?But allow for non-compliant implementations, of course. Eg ignore any content even if it doesn’t have the recommended data.Brian 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/ 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/, 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 listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-error-reporting-07: (with DISCUSS)
On Tue, Dec 12, 2023 at 9:18 PM, Paul Wouters 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://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 . Can this be stated explicitly ? > Erm, I think that it is? Section 3. Terminology " Report query: The DNS query used to report an error is called a report query. A report query is for a DNS TXT resource record type. The content of the error report is encoded in the QNAME of a DNS request to the monitoring agent." Section 4. Overview "The resulting report query is sent as a standard DNS query for a TXT DNS resource record type by the reporting resolver." 7. IANA Considerations "IANA is requested to assign the following Underscored and Globally Scoped DNS Node Name registry: RR Type _NODE NAME Reference --- - TXT _er [this document] " > 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. > Yup, this is a good point — the document says: " It is RECOMMENDED that the authoritative server for the agent domain replies with a positive response (i.e. not NODATA or NXDOMAIN) containing a TXT record.". Would simply noting that this is untrusted data and should be sanitized / something before stuffing it into logs / displaying it / etc? 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/ 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/, 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
[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-error-reporting-07: (with DISCUSS)
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 . 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/ 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/, 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