Thanks, Petr, for the detailed review. https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/86 has been raised to address the issues you identified.
Cheers, -Tiru On Mon, 23 Mar 2026 at 17:07, Petr Špaček <[email protected]> wrote: > On 19. 03. 26 5:59, tirumal reddy wrote: > > addresses comments received during WGLC, > > particularly those raised by Petr Špaček. > > First, I apologize for the mangled review text! Apparently Datatracker > ate some of the newlines and it made it really hard to read even for me, > which I unfortunately noticed only today. > > I went through -18 and my -17 review and I think this mess contributed > to skipping over several points I raised. The first one is crucial as > the format under-specification was not addressed: > > -18 says: > > 4. I-JSON in EXTRA-TEXT Field > > > > ... data in the EXTRA-TEXT field [RFC8914] encoded using the Internet > JSON (I-JSON) message format [RFC7493]. > > It is still missing a specification the data must be a JSON Object > (emphasis on the capital O). I-JSON message could be an array, even > null/false/true. I suggest replacing the sentence above with something > like: > > "... data in the EXTRA-TEXT field [RFC8914] as JSON Object encoded using > the Internet JSON (I-JSON) message format [RFC 8259 section 4]." > > > > 5.2. Server Generating Response > > If the SDE option was not present in the DNS request, the DNS server > MUST NOT include structured JSON data. > > What if an implementation does not produce humand-readable version? Does > that mean it MUST NOT give back any information at all? Returning > unsolicited SDE does not result in any interoperability problem, it just > might be less convenient for a person to read it. But having something > is certainly better than not returning anything at all. > > I suggest change to something like this: > "If the SDE option was not present in the DNS request, the DNS server > SHOULD include human-readable EXTRA-TEXT accordance with [RFC8914]." > > > > 5.3. Client Processing Response > > 8. If the DNS client has enabled the opportunistic privacy profile for > DoT (Section 5 of [RFC8310]) and the identity of the DNS server cannot be > verified, ... > > This paragraph has leftover over-specification for DoT which was > corrected in other places. Simply shortening it would address this > issue. E.g."If the identity of the DNS server cannot be verified, ..." > > If you really want to single out DoT, then perhaps something like: > > "If the identity of the DNS server cannot be verified (e.g. with > opportunistic privacy like Section 5 of [RFC8310]), ..." > > > > 5.3. Client Processing Response > > In opportunistic discovery [RFC9462], where only the IP address of the > DNS server is validated and the server identity is not authenticated, the > DNS client MUST ignore ... > > Same here. There might be a different mechanism in use which is similar > but different than RFC 9462. > > I suggest: > "If only the IP address of the DNS server is validated and the server > identity is not authenticated (e.g. with opportunistic discovery > [RFC9462]), ..." > > > 5.3. Client Processing Response > > 10. If a DNS client has enabled strict privacy profile (Section 5 of > [RFC8310]) for DoT, the DNS client requires an encrypted connection and > successful authentication of the DNS server. In doing so, this mitigates > both passive eavesdropping and client redirection (at the expense of > providing no DNS service if an encrypted, authenticated connection is > not available). If the DNS client has enabled strict privacy profile for > DoT, the DNS client MAY process the EXTRA-TEXT field of the DNS response. > > This seems to over-specify things again. E.g. an ordinary Firefox > browser today, doing DoH to a selected DoH resolver, will not fulfill > this specification! > > I suggest simplifying it to: > > "If the connection to a DNS server is authenticated and integrity > protected, the DNS client MAY process the EXTRA-TEXT field of the DNS > response." > > That's technology neutral and focuses on the important properties the > SDE protocol relies on - authentication and integrity protection. (For > the fun of it, TLS with NULL cypher-suite would suffice as it provides > integrity protection without encryption :grin:) > > > > 10.1. Authentication and Confidentiality > > This specification assumes the use of encrypted DNS transports and > recommends authenticated connections to the DNS server. > > After the changes above, this would read better as e.g. > > "This specification assumes the use of integrity-protected DNS > transports and recommends authenticated connections to the DNS server." > > > Nit: > I suggest adding "SDE" acronym definition into section 2. Conventions > and Definitions . > > Thank you for patience with me. > > -- > Petr Špaček >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
