On Tue, 13 Feb 2024, Roy Arends wrote:
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:
Yes that was my bad.
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?
I was thinking along the lines of:
Any RDATA content MUST be ignored. If the RDATA content is logged,
it MUST assume the content can be malicious and take appropriate
meassures
to avoid exploitation. One such method could be to log in hexadecimal.
This
would avoid remote code execution through logging string attacks such as
[CVE-2021-44228].
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.
How about:
Care should be taken when more DNS resolving is needed to
resolve the error reporting QNAME. This resolving itself
could trigger another error reporting to be created. A
maximum expense or depth limit MUST be used to prevent
cascading errors.
This would nudge the implementors to think about the solution that
works for them, without dictating certain behaviour that might not be
convenient for an implementation. They might still opt to do exactly
what you stated in your version.
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?
I want to avoid people creating malicious error reporting zones that
include "www.nohats.ca", where the DNS resolver will drop DNSSEC because
it is now a "error reporting FQDN" and now my DNSSEC domain has been the
victim of a downgrade attack. Similar to above, rather point out the
resource/failure mode and suggest possible counter measures. But please
do not say "for some queries, disable DNSSEC" unless it is very well
constrained - eg with wording like "set the CD flag for any error
reporting queries to disabled DNSSEC without causing a downgrade
attack". Based on the assumption that CD queries are already quaranteed
in resolver code.
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"
Thanks.
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.
It might be good to just take a step back now, so that perhaps in the
future we do not need re-coding, waiting on updates, deployments, etc?
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
