Unlike a webpage served over HTTPS which has transport security and server authentication, a DNS response carrying arbitrary free-form text does not have the same guarantees, making structured and validated content essential. For instance, a free-form EXTRA-TEXT string containing URLs or contact information can be manipulated by an on-path attacker to redirect end-users to malicious sites, which is precisely the attack the draft addresses.
Another example could be, RFC8914 EXTRA-TEXT has no language tag, determining the language of a short string is challenging, making translation or locale-appropriate handling unreliable; this draft solves this by tagging the error response with the language, enabling clients to handle it appropriately. WGLC is intended to identify technical issues with the current specification, not re-open the question of whether the work should exist, the WG already reached consensus on that at adoption. This draft has a history of several years where the need for it was discussed and agreed upon at adoption, and it has continuously evolved to address various issues including, threats and deployability. If you are still not convinced of the need for this draft, I suggest reviewing the history of this draft and the extensive discussions on the mailing list. -Tiru On Thu, 19 Mar 2026 at 10:02, Mukund Sivaraman <[email protected]> wrote: > Hi Lars > > On Thu, Mar 19, 2026 at 01:00:03PM +0900, Lars Eggert wrote: > > Hi, > > > > On Mar 19, 2026, at 12:45, Mukund Sivaraman <[email protected]> wrote: > > > I don't follow. Without considering transport security, what risk is > > > present from processing and displaying a freely formatted text message > > > generated by an NS for its clients (with additional hyperlinks added) > > > that cannot exist in every other webpage on the internet that is > > > displayed to users? A browser can escape or reject junk in EXTRA-TEXT. > > > > this is not "every other web page". This content will be shown in a > > highly security-related context, and it is critical that the user > > agent has full control over what is shown to the user. (Never mind > > other issues such as localization.) > > Why does this have to be shown in a highly security related context, and > not as a webpage? > > For example, if a webserver blocks me from accessing a resource, it may > generate a webpage that says "You've been blocked from accessing this > resource because we don't like you accessing this over a VPN, and here's > a picture of a furry animal to take away some of the pain. If you want > to, you may try contacting us at [email protected] but you'll have > better luck squeezing oil out of stone than getting a reply." > > Websites don't return JSON objects with contact information to be > displayed in highly security-related context when there are errors. Why > is a DNS extended error special that a browser error page cannot be > displayed with the EXTRA-TEXT? > > > Let me turn this around and ask you what you think is lost by > > eliminating arbitrary content? > > Eliminating arbitrary content is not the concern. It's the requirement > of implementing yet another DNS RFC in a nameserver. If there are good > reasons that are well-explained in the draft, there's no problem. > > The premise of having to display contact information in a high > security-related context is not even described in the abstract or > introduction of this draft. The stated goal is to convey which what > filtered something, how to report mistakes, or ask why something was > filtered; and to eliminate spoofed websites/pages for blocked HTTPS > websites. This can be implemented with RFC 8914. > > Structured data is usually desired in automation, but it's not clear how > this will be used in automation. > > Mukund > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
