On Fri, May 08, 2026 at 10:32:57AM -0700, Dan Wing wrote:
> On May 8, 2026, at 10:18 AM, Mukund Sivaraman <[email protected]> wrote:
> > On Sat, May 09, 2026 at 12:44:38AM +0800, Mukund Sivaraman wrote:
> >> On Sat, May 09, 2026 at 12:32:14AM +0800, Mukund Sivaraman wrote:
> >>> A DNS message is not the appropriate place for this kind of
> >>> localization. Space is at a premium (64kB is all there is for the whole
> >>> message). India has 22 official languages for example, and it would be
> >>> absurd to have as many translations encoded in an EDNS option.
> >>> 
> >>> The objective should be that the language used in the justification text
> >>> and organization name is indicated, which it appears the draft provides
> >>> for.
> >> 
> >> Having said this, I realise that the structured-dns-errors draft only
> >> returns the JSON for empty answers (where filtering/blocking/censoring)
> >> has occurred. So there ought to be space in the 64kB in these cases.
> >> 
> >> However, this localization still seems like it doesn't belong a DNS
> >> response.
> > 
> > Perhaps a client can indicate its locale in an EDNS option in the query,
> > and the server responds with a single localized set of fields matching
> > what the client requested, or if that is not available, whatever
> > language the server has.
> 
> This would add another fingerprinting vector (undesirable) and could be used 
> to influence filtering (probably undesirable?).

You make a good point about fingerprinting. But analogously every HTTP
request sent by a popular web browser such as Firefox (which sends the
Accept-Language header) has a similar indicator. From a DNS PoV, coming
from consideration for small message sizes, sending every translation
available in the catalog seems excessive. If a DNS client indicates what
language it wants, it can receive localized data in that language;
otherwise it can receives whatever language the server sends.

                Mukund

Attachment: signature.asc
Description: PGP signature

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to