On Saturday, 14 March 2020 20:38:23 UTC Mark Delany wrote: > On 14Mar20, Paul Vixie allegedly wrote: > > yes. this code had to run on a PDP-11. > > Bummer. Based on this, is it reasonable to assume a TXT only holds > 7-bit ASCII then? Not until the Experimental RFC1464 do we finally > find explicit mention of a code set for the contents of a TXT in a > very specific use-case. > > Asking for a friend who wants to create a zone full of TXTs which > provide character-set conversions. ASCII -> Fieldata, etc. and as best > I can tell this is legit according to 1035.
nothing in the dns protocol specification prohibits 8-bit values in a <character-string> as used in HINFO (two of them) or TXT (N of them). some older servers and older client libraries will trip over a 0x00 value. i don't know of any implementation that ever stripped the high (ch & 0x80) bit. <character-string> is unlike <label> in that there is no case folding. so for servers who ignore or reject duplicate Rdata within an RRset, TXT Rdatum differing only in case (TXT abc123, TXT ABC123) will not be seen as duplicates, as would be true for <labels> differing only in case. if you are using modern unbound, nsd, knot, bind, powerdns, and a modern library like getdnsapi, the sky is the limit. you should be good to go with (for example) utf8 in <character-string> as long as you're OK with this not being well represented by zone file parsers or dumpers, or by "dig". RFC 1035, page 13, section 3.3: "<character-string> is a single length octet followed by that number of characters. <character-string> is treated as binary information, and can be up to 256 characters in length (including the length octet)." -- Paul _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
