[dns-operations] creeping poorness of judgement

[Paul Vixie]

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