[DNSOP] Re: AD review of draft-ietf-dnsop-structured-dns-error-19

[Mark Nottingham <[e-mail]>]

There's been pretty consistent feedback from browsers that they're reluctant to directly display textual strings from DNS responses to users. 


> On 10 May 2026, at 12:39 pm, Mukund Sivaraman <[e-mail]> wrote:
> 
> On Sun, May 10, 2026 at 10:19:07AM +1000, Mark Nottingham wrote:
>> I'd be concerned if we started rebuilding HTTP semantics inside
>> DNS. The merit of putting links instead of strings inside the response
>> is that you can then use language negotiation (etc.) for a richer
>> experience when called for without burdening DNS.
> 
> Indeed a URL that provides localized information seems better than
> localizing in DNS.
> 
> I think Eric is pushing for localizing the justification string which is
> meant to be displayed to a human in a browser.
> 
>> Emitting another bit of fingerprinting data on all DNS requests is
>> likely to be controversial, and also will require significant
>> implementation effort.
> 
> For example, if the new structured-dns-error EDNS option in a query,
> instead of being empty, includes the requested language, a nameserver
> could ignore it and deliver text for whatever locale it wants to as is
> currently specified in the draft.  The extra implementation effort would
> be for nameservers that want to deliver localized strings, and that need
> not be much work. For example, for one kind of implementation, it would
> involve wrapping justification messages in _(), providing po
> translations, specification of organization translations in
> configuration with a map.  Just responding to the point that this isn't
> necessarily a lot of development work.
> 
> I prefer the URL approach you've mentioned above and to leave
> localization out. The language field would be just an indicator of what
> language the justification and organization name are delivered in.
> 
> Mukund

--
Mark Nottingham   https://www.mnot.net/