Hi Ben On Tue, May 26, 2026 at 11:54:39AM -0400, Ben Schwartz wrote: > +1 > > Text that is shown to end users is "content". DNS is a platform for > distributing technical metadata, not content for users.
The JSON "j" field in the draft appears to model on the EDE.EXTRA-TEXT
field (as it overwrites it), and it may not be best to call it "content"
- i.e., it is human readable textual technical metadata.
RFC 8914 specifies an EXTRA-TEXT field with UTF-8 encoding which is
intended for users. From the RFC:
> This information is intended for human consumption (not automated
> parsing).
It can contain descriptive information on the processing of a DNS query,
and why it resulted in the response that was delivered, more than just
the RCODE and the EDE.INFO-CODEs.
The EDE.EXTRA-TEXT field is a crucial textual field that can deliver
more information to users. For example, both the following conditions
may cause a nameserver implementation to return EDE.INFO-CODE =
Prohibited (18):
* A DNS query was denied to a query ACL
* A DNS response to a UDP query was truncated by a response policy zone
(which isn't covered by EDE.INFO-CODEs for blocked, censored, or
filtered)
(... and it's not limited to just these conditions.)
In such cases, the nameserver may use the EDE.EXTRA-TEXT field to return
cruicial information about what happened to users, more than a code may
convey. It can contain query-specific variable information in the text
including DNS names, IP address, DNS zone, keytag, etc. It may not be
useful for the latter example as clients upon receiving TC=1 will retry
over TCP, but the message for the former would convey to the user what
exactly happened.
RFC 8194 is relatively young and it's not yet rigorously implemented for
most conditions in many DNS implementations as much as implementors
would like. The EXTRA-TEXT field can be almost like a syslog for DNS
support engineering staff and regular users performing DNS queries using
DNS clients to find out what happened for a query without having to
match against syslogs (or having access).
It is a textual message for users to consume and for clients to display
to users. Web browsers may have strict policies on what they display in
some contexts, but that doesn't mean that DNS should not distribute this
textual information.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
