#dns question about multi-string TXT records: #rfc7208 section 3.3 says they shall be concatenated w/o space.
Is this applicable only to #spf records?
Looking at #rfc9432 (catalog zones) section 4.3.2.1 the group example "operator-y" "bar" seem to suggest this shall be interpreted as some sort of key/value (e.g. “operator-y=bar” or “operator-y bar”) where “operator-ybar” would not make any sense.
Neither #rcf1035 nor #rfc1464 mention multi-string TXT records.

@gjherbiet My guess would be: yes. (More precisely: my guess is that: authors of RFC 7208 mentionned it as it is not a standard practice)

RFC 1035 is very precise (of course not): TXT records contain one or more strings. And that the semantics depends on the domain where it is found. And deal with it 😬

@shaft OK. So I believe it is legitimate to consider TXT multi-strings concatenation makes sense for SPF records in #rfc7208 and “tokenization” is more appropriate for catalog zones in #rfc9432.
@gjherbiet Well, have not read RFC 9432 yet (no usage for it yet), so yes I guess 😅

@gjherbiet To be more precise: Strings in a TXT record are usually rendered as is: if you have

example.org IN TXT "str1" "str2"

It is usually rendered as 2 strings. (Try, the TXT at "page751.necronomicon.shaftinc.fr" for an rather extreme example)

So the author of spf RFC is vicious. How are we supposed to know that a TXT record is a SPF. Need to parse it :(

@shaft et on est d'accord que 2030 n'est pas la limite dure de TXT, mais juste la limite de la page 751
@Albirew La limite de données (RDATA) d'un enregistrement DNS est de 65535 octets. Donc en théorie, on pourrait caser quelques autres pages du grimoire maudit :)