On 02. 03. 26 10:25, Stephane Bortzmeyer wrote:
On Fri, Feb 27, 2026 at 09:50:57AM -0800,
Petr Špaček via Datatracker <[email protected]> wrote
a message of 200 lines which said:
Document: draft-ietf-dnsop-structured-dns-error
Title: Structured Error Data for Filtered DNS
Reviewer: Petr Špaček
Review result: On the Right Track
4. I-JSON in EXTRA-TEXT Field
DNS servers that are compliant with this specification and have received an
indication that the client also supports this specification as per Section 5.1
send data in the EXTRA-TEXT field [RFC8914] encoded using the Internet JSON
(I-JSON) message format [RFC7493].
Note that [RFC7493] was based on [RFC7159], but [RFC7159] was
replaced by [RFC8259]. I don't know how to interpret this note. What
are the implications for an implementer?
RFC 8259 changes nothing to the definition of I-JSON. RFC 7493 is a
restricted profile of JSON and it is not modified by the update of the
JSON specification. Basically, the implementer must return I-JSON and
not the more lax JSON. IMHO, the note could be removed.
If I first use "curl" from console, the NXDOMAIN for a blocked domain might get
cached in stub's local cache. A subsequent web visit to the same domain from
the same machine will get NXDOMAIN without the EDE, but it is still the same
NXDOMAIN. If there is upstream cache, the same happens e.g. for a whole home
(e.g. if I put my home router between client end devices and ISP's resolver).
Speaking of this, I wonder what will happen if a NXDOMAIN for a
subdomain is synthetized from a forged NXDOMAIN of the parent domain
(for instance because of RFC 8020). Should the server include an SDE
(a very corner-case, I admit)?
Even worse, 'encryption' itself might not be sufficient because encryption
generally does not guarantee non-malleability.
I agree with the idea that mentioning the goal (authentication and
integrity) is better than mentioniong the mean (encryption) but, since
DNS encryption always use TLS, and TLS 1.3 always force integrity (RFC
8446, section 5.2), may be there is no real issue here.
First, I can't see justification to deviate from RFC 8914 section 6
which already handles this question.
Secondly, why do you think "DNS encryption always use TLS"? Or rather,
why it should stay the same into indefinite future? Why over prescribe
and prevent new [or old, see TSIG, SIG(0)] technology from reusing
existing specifications?
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
