Sent from my iPhone

On Dec 13, 2023, at 1:32 PM, Warren Kumari <war...@kumari.net> wrote:






On Tue, Dec 12, 2023 at 9:18 PM, Paul Wouters <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://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 ?


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/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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to