[dns-operations] creeping poorness of judgement
paul at redbarn.org
Sat Mar 14 21:09:29 UTC 2020
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)."
More information about the dns-operations