On 4/14/25 17:18, The IESG wrote:
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Structured Error Data for
Filtered DNS'
<draft-ietf-dnsop-structured-dns-error-12.txt> as Proposed Standard
I've reviewed only the DNS bits but not the data format transferred
using this protocol. From DNS responder and receiver perspective I have
technical objections.
Issue #1
5.1. Client Generating Request
When generating a DNS query the client includes the EDE option (Section 2 of [RFC8914])
in the OPT pseudo-RR [RFC6891] to elicit the EDE option in the DNS response. It MUST use
an OPTION-LENGTH of 2, the INFO-CODE field set to "0" (Other Error), and an
empty EXTRA-TEXT field. This signal indicates that the client desires that the server
responds in accordance with the present specification.
RFC 8914 did not envision use of the EDE Option in requests, only in
responses. I think it is bad design to overload EDE for use in requests.
It would be cleaner and more robust from compatibility perspective to
use a specialized EDNS Option as a signal from requestor to responder to
signal interest in structured data.
A specialized option was present in
draft-wing-dnsop-structured-dns-error-page-01 but was replaced with EDE.
I guess it is okay to do that on responder side, but it is a really bad
idea to reuse EDE on the client/requestor side.
E.g. something along those lines:
-------------------
This document defines a new EDNS(0) [RFC6891] option code to request RFC
8914 data in responses to be formatted in JSON. The value of this
EDNS(0) OPTION-CODE is TBA-BY-IANA. This option MUST have OPTION-LENGTH
equal to zero.
-------------------
Issue #2
5.3. Client Processing Response
On receipt of a DNS response with an EDE option from a DNS responder, the
following ordered actions are performed on the EXTRA-TEXT field:
Servers which don't support this specification might use plain text in the
EXTRA-TEXT field. Requestors SHOULD properly handle both plaintext and JSON
text in the EXTRA-TEXT field. The requestor verifies that the field contains
valid JSON.
There is no indication in the response if an answer contains structured
EDE or not. The client has to guess!
I suggest to use a new specialized zero-length option to signal the
request was indeed fulfilled.
If people feel this is frivolous waste of EDNS(0) OPTION-CODE values we
could reuse the same value proposed for use in section 5.1 (see above)
... OTOH in the last 25+ years we have managed to allocate only 20
points out of 65000 available, so I cannot see why we should require
more code to be written to determine meaning of an option based on QR
bit value.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
