Okay, one more time from me.I will not use any terminology to prevent being picked I do not understand them properly.
I have prepared archive with a text: https://pemensik.fedorapeople.org/utf8.tar.gz
You can access them from a browser too: https://pemensik.fedorapeople.org/utf8/
The result is tiny and I attached it here.However that server specifies UTF-8 encoding for them, giving additional extra data. Therefore rendering it in a browser has extra additional information.
There are files from https://www.iana.org/domains/reserved, plus one czech extra. Then two random binary content to make the difference obvious.
They are plain text only, no metadata. No header and no encoding specification. Just like TXT content.
Yet, when I use less tool, it escapes only binary content. The rest is rendered somehow. Not always great way with arabic, but never escaped. Linux file tool detects them as UTF-8 text.
file text-cs.txt text-cs.txt: UTF-8 Unicode text $ file bin16.txt bin16.txt: data $ file bin8.txt bin8.txt: Non-ISO extended-ASCII text, with no line terminatorsNow if you could find a simple words and explain me, why this is possible in terminal with less, even with common plain text editor like vim. But not possible with TXT records in DNS.
There seems some possible algorithm to handle it a bit better. Because I am only simple minded and still do not see the problem others do.
Perhaps better to respond privately. On 26/11/2025 09:44, Marco Davids (IETF IMAP) wrote:
Mark wrote:Dig uses ‘.’ when printing out unknown EDNS options when the value is not printable ASCII.I played e little with dig and Extended DNS Errors (RFC8914) and it turned out to be perfectly possible to add UTF-8 encoded strings in there:;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232; EDE: 4 (Forged Answer): (キルロイはここにいた DNS4ALL frontend fiddled around with this reply -Is that because it it not an 'unknown' EDNS option ?Perhaps also because RFC8914 says: EXTRA-TEXT: a variable-length, UTF-8-encoded [RFC5198] text field.Infourls in RESINFO RRtype records (RFC9606) on the other hand, look like this:;; ANSWER SECTION:resinfo.testdns.nl. 0 IN RESINFO "qnamemin" "temp-dnssecval" "infourl=https://\228\190\139\229\173\144.\207\128\206\177\207\129\206\172\206\180\206\181\206\185\206\179\206\188\206\177/\227\130\173\227\131\171\227\131\173\227\130\164\227\129\175\227\129\147\227\129\147\227\129\171\227\129\132\227\129\159";Probably because section 4 says: "The resolver information record uses the same format as DNS TXT records."Both RFCs have a disclaimer that the information is intended for human consumption, not automated parsing.Interesting stuff. ;-)
-- Petr Menšík Senior Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
utf8.tar.gz
Description: application/gzip
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
