Hi Tirumal On Fri, Mar 20, 2026 at 09:29:46AM +0530, tirumal reddy wrote: > The layered approach provides richer and more precise error information. > For example, "Blocked" means the server is unable to respond to the request > because the domain is on a blocklist due to an internal security policy > imposed by the operator of the server resolving or forwarding the query. > Adding a sub-error code on top of this tells the client exactly why the > domain was blocked, enabling better user-facing messages.
Flattened INFO-CODEs would convey the same error information. They would just take up more code points. User facing messages would be mapped from the code to a string. It was not about what is conveyed, but how. > So far we have not heard any arguments in favour of flat INFO-CODE > allocation other than yours that outweigh the design rationale already > documented in Section 4 of the draft. I too am surprised to be the only dissenting developer here. Is there no other DNS developer bothered that a 3rd level of result code is introduced, that has to be tracked separately? Is there no other DNS operator bothered that this needs JSON parsing of the EXTRA-TEXT to filtering DNS messages on the sub-error? I'm fine to be the only one. > > BTW I'm not entirely against this. From a different perspective of a > > commercial DNS implementation, a draft like this with bells and whistles > > is favourable because it increases the barrier to entry. Having this > > extra protocol implemented makes a deeper moat and it's a few hundred > > lines of code over the extensive EDE implementation we already have. The > > camel is fine with this draft in that regard. I sent the review with my > > opinion after reading Benno's email. > > > > For what it's worth, two DNS resolvers have already implemented this draft > and browser vendors have shown interest; otherwise this draft would not > have reached this stage. This is a strong signal that the industry sees > value beyond what RFC 8914 provides. Yes I see the value too. > > > It is already discussed in the draft, see > > > > > https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-18.html#section-10 > > > > Tirumal, the purpose of your draft is this. It shouldn't be a footnote. > > > > What is the premise? "This draft communicates contact and DNS filtering > > information over secure transport to web browsers to show in > > dialogs/pages in a secure UI context, which RFC 8914 is incapable of > > conveying." State this in the introduction so that it's clear why this > > draft is necessary over what's already there. Would you like me to > > write some sentences that you can edit and add to the introduction? > > > > I will add text clarifying what this draft enables over RFC 8914. Thank you. Mukund _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
