On 12 Aug 2025, at 16:32, Vadim Goncharov <[email protected]> wrote: > Well, do you have survey data showing such usage in TXT records on mass scale? > If not (and it seems not), then what explanations do you have to such fact? > We all know that standard allows full binary, that was told in the very > beginning of thread and that is not the question.
TXT records with arbitrary values are used for DNS-SD. This is described in section 6.1 of RFC6763. If you have any Apple TV or HomePods or other Thread border routers, they implement this with the DNS protocol. DNS-SD over mDNS is ubiquitous, but not technically DNS, which is why I mention Apple TVs and HomePods. But e.g. if you ever go to an IETF and try to use a printer there, you discover the printer using DNS, not mDNS, and the printer's capabilities are described in a TXT record formatted as described in RFC6763. You should also be aware that the whole point of using a length encoding for substrings of the TXT record as described in this section is so that the value in any key=value pair can in fact be unicode or binary. >> The fact that some DNS web UI doesn't support this is an indictment of web >> UIs, not a DNS issue. If you want DNS to work, don't use web UIs to set up >> your zone files. > > What about e.g. people who have no choice? I don't actually know of a totalitarian regime that forbids individuals from running their own DNS servers, but perhaps I am missing some? In any case, the IETF can't design protocols with such regimes in mind. This is a normative policy—see RFC 3365. If you mean that some legitimate users of DNS aren't able to understand how set up their own DNS server and hence must rely on some DNS provider with a broken web UI, again, the IETF doesn't design protocols to support broken web UIs. I do understand that you want to advance your proposed encoding for CBOR, and for that to happen you would need the answer to be that such records will never exist in practice. But this simply isn't true. You did the right thing coming here to ask about this, and I'm sorry the answer is disappointing, but it's really not negotiable. If you were to get such a document past a working group last call, I hope the mistake would be caught in IETF last call or by the IESG. That would be a really unfortunate waste of working group time. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
