On 19/11/2025 18:04, Michael Sweet wrote:
(Entering this discussion a little late, I only just became aware of this
thread...)
I've be peripherally involved with mDNS and DNS-SD for a long time, and more
specifically with how DNS-SD and TXT records are used for printing.
For printers, values are always Network Unicode (RFC 5198) which is UTF-8 NFC
without most control characters. This is consistent with IPP (STD 92) and how
we've mapped the old Printer MIB v2 and Host MIB values which use a separate
MIB property to specify the character set to IPP and other print
protocols/encodings which exclusively use Network Unicode.
From a software development perspective, I suspect you can reliably detect
when a TXT record string contains valid UTF-8 and show the contents as text or
hex data otherwise (or maybe have a toggle?) Not sure what Wireshark does for
TXT records, but that might be a place to look for inspiration...
________________________
Michael Sweet
Ah, did not know there is something like Network Unicode. Sure, that
should be enough.
Tested wireshark and that is not the best inspiration. It does neither
escaping nor proper display on my system, which has UTF-8 locale. Not
sure which encoding it tries to display, but the result is even worse
than escaping. Information is lost by it. Question mark in box appears.
latin2: zku�ebn� z�znam
zku��ebn�� z��znam
Tried also tcpdump.
pihhan.info. TXT "zkuM-EM-!ebnM-CM-- zM-CM-!znam", pihhan.info. TXT
"latin2: zkuM-9ebnM-m zM-aznam"
Event more surprising result. Not sure where those values came from. It
misinterprets the contents to be something different, but prints some
ASCII sequence instead. Seems like a bug.
It seems like a good example why some recommendation about how to
interpret TXT records would be desirable.
Cheers, Petr
--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
