On Thu, Mar 19, 2026 at 12:13:57AM +0800, Benno Overeinder wrote: > Thank you for your WGLC feedback, and also to Petr for his DNSDIR review and > to Gianpaolo for his support of the draft (and the PoC implementation). > > I would like to ask the WG participants who have read the draft previously > to review the changes and send their support or feedback on the document to > the mailing list.
* The premise: Is a structured error necessary? To solve the problem this draft is attempting to solve, are DNS clients and web browsers unable to display freely formatted text messages from DNS responses containing RFC 8914 EDE options that hyperlink email addresses, URLs, phone numbers, etc.? Examples of free-formatted messages that can convey the same: "Your query failed because you are out of quota. Please email [email protected] to contact sales, [email protected] for tech support." "The domain name you tried to contact was blocked due to a central government directive. Please see: https://government.example.com/blocked-domains/"; Surely browsers can be made capable of displaying such a EXTRA-TEXT message on a browser error page, hyper-linking email addresses and URLs in the freely formatted text? * 3rd level of result code: There's the message RCODE, EDE INFO-CODE, and this draft introduces a third level of result code which I've commented on before, but there was no response: https://mailarchive.ietf.org/arch/msg/dnsop/6gRyV_V7I1RwdNak3Zx7pZwNkkk/ Add that because this sub-error is encoded in JSON, matching DNS messages against a sub-error from a packet capture will require a JSON parser. There is a *lot* of free space in the EDE registry in the DNS parameters registry group. If a new INFO-CODE was allocated per day, it would take 134 years to fill up the space. Flattening the currently listed sub-errors to consume a few extra codes would not be so bad if it keeps the protocol minimal. If any new INFO-CODEs are added to the EDE registry, plain RFC 8194 implementations also benefit. * Use of JSON: DNS is a binary formatted message where space is at a premium. Almost every other RDATA and EDNS option data field with structure uses binary encoding. JSON bloats (can't clients parse binary encoded fields?), introduces a dependency on a JSON parser, makes filtering on the 2nd-level result code harder. This is a case in DNS where we can do more with less. RFC 8914 is succinct, simple to implement, is already widely deployed, and can convey any message that a DNS operator wants to tell an end-user, with contact info. Browsers can display such messages to users if they want to. Mukund _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
