Early Review of draft-ietf-dnsop-structured-dns-error-03
review-ietf-dnsop-structured-dns-error-03-dnsdir-early-brown-2023-06-29-00

I believe this draft has ambiguities that will present issues for implementing
clients that require further discussion and clarification before proceeding.

**Issue 1**
RFC8914 is clear (section 2) regarding EXTRA-TEXT that “This information is
intended for human consumption (not automated parsing).“.

Section 4 of this draft implicitly updates that requirement by stating that
I-JSON can be sent in the field, but focuses on the technical aspects of the
JSON structure, not on the implications of reversing that statement.

Changing a field stated as for human consumption to a field intended to be
machine-readable is a major change and the implications of this change should
be discussed in the draft, including an explicit statement updating the intent
of the EXTRA-TEXT field.

In particular I would expect to see discussion and consideration of how
backwards compatibility with RFC8914 compliant, but structured-dns-error
ignorant clients would be achieved. One obvious scenario that presents
difficulties is a client expecting EXTRA-TEXT to contain human readable
contents which it displays to an end-user, which would now (upon encountering a
resolver implementing this draft) instead display JSON blobs intended for
machine consumption to the user. This seems undesirable to me, but the draft is
silent on whether this is an accepted consequence of the updates, simply
overlooked or can be avoided in some way.

At the very least, this situation should be discussed and acknowledged as OK in
the draft, or ideally consideration of how to handle it - e.g. was a separate
EDNS option code for structured-error considered?

**Issue 2**
The above ambiguity also appears to lead into conflicting instructions for
clients in section 5.3 - specifically the first and third bullet points are
conflicting - clients SHOULD handle either plaintext or JSON in EXTRA-TEXT
(point 3), but MUST discard invalid JSON (point 1).

How is a client meant to determine if the EXTRA-TEXT field contains invalid
JSON or simply plain text? Is it envisaged that the client performs some sort
of content detection to determine whether the field is plain-text or JSON
before trying to parse it as JSON - if so how? Or if the field cannot be parsed
as JSON then why can’t the client simply treat it as plain text?

Again this seems to call for a discussion of why the existing EDNS option code
is being reused. Attempting to deal with either human or machine readable data
in a single field is generally a fraught and dangerous choice in protocol
design, and the presence of these two conflicting requirements is a clear
example of why.

The use of a separate EDNS option code for human-readable vs machine-readable
extended error information would provide a clean solution, but is not discussed.

**Issue 3**
Section 6 appears to alter DNS processing behaviour for RPZ servers (to avoid
the use of NXDOMAIN, RA=0 in favour of the logic in section 5.2), there are 3
points here:

1) (issue) “can” is not a BCP 14 term, making it unclear the strength of this
instruction for compatible servers - I recommend using an explicit MAY, SHOULD
or MUST term here instead of the ambiguous can. 2) (issue) regardless of the
term used, the implication that the presence of an EDE option can indeed alter
DNS processing behaviour on the server is in conflict with the MUST NOT
directive in section 6 of RFC8194, which section 10 of this draft says still
apply to this document. If this section 6 does indeed intend to override the
MUST NOT security considerations of section 6 in RFC8194 and allow a situation
where EDE can alter DNS processing behaviour for RPZ servers that should be
explicitly stated (both in this section) and also in the later security
considerations section. 3) (nit) the link/reference to #server-response in the
text is not working

**Nit 1**
Section 3 contains an incorrect assertion that EDE (RFC8914) is a DNS filtering
methods stating that: “DNS responses can be filtered by sending a bogus (also
called "forged") A or AAAA response, NXDOMAIN error or empty answer, or an
Extended DNS Error code defined in [RFC8914].” - EDE is being presented as a
third alternative for filtering. It is not. RFC8914 clearly states that EDE
MUST NOT alter DNS processing, so an EDE cannot be used to filter a DNS
response - EDE can only add explanatory information about filtering that is
occuring due to another method.

This sentence needs re-wording to clarify this, and I would suggest refactoring
the entire paragraph into two parts, one which explains the issues with the
actual filtering methods, and then a second part which separately covers why
the existing EDE responses are insufficient for the use-cases this draft
intends to support. Separating this explanation into two parts avoids the
confusion the text currently introduces around whether or not RFC8914 is a
filtering method or an information method.