[DNSOP] Re: draft-ietf-dnsop-structured-dns-error-17 early Dnsdir review

[Stephane Bortzmeyer <[e-mail]>]

On Fri, Feb 27, 2026 at 09:50:57AM -0800,
 Petr Špaček via Datatracker <[e-mail]> 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.