> but it can be tricky to configure properly on a name server.
I wouldn't say it is tricky with a good name server: for instance with bind just split the value into multiple quoted strings and it'll do the rest¹.
Though while it is well known, it doesn't seem to be well documented away from many forum posts discussing the matter: after a little searching I can't find reference to the issue in bind documentation or relevant RFCs. The RR format allows RDATA to be longer than 255 octets (RDLENGTH is an unsigned 16-bit value, not 8-bit) so presumably the limit is imposed by the zonefile format. The only reference to 255 octet limits in RFCs 1034 & 1035 is the length of a full name (with individual labels making up a name being limited to 63 octets).
Of course many UIs for editing zone files or other stored RR information, or other DNS management interfaces, might implement longer RDATA support in a worse way or not support longer RDATA values at all.
----
[1] I'm not sure what “the rest” is (I might look deeper later)
.... <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).
So the 255-byte limit for each string within the TXT record is a core part of DNS. But so is having more than one such string in the record data (which I thought was a later extension). I have no idea why this strange format was chosen when, as you noted already, the RDATA is already sized by the RDLENGTH, which is 16 bits. However, it is not a mere artifact of the zonefile format; indeed the format follows from the spec.
I'm not sure that all clients and servers out there handle more than one string in the record properly, though in my experience, most do. Still, having to split the values, and being able to split them before exactly 255 bytes, makes it trickier than it needed to be to administer and validate such configurations manually.
yeah my point is that most dns servers used outside the major markets do not support any of this double key stuff.
if you want TLD not available at your us registrar, you're stuck with low dkim keys. period. doesn't matter what specs says.
dunno if that's just a consequence of the monopoly design of the dns business, or more nefarious reasons, but that's the situation on most TLD not easily registered such as .br
Ok, using your registrar to serve your DNS records for you is a choice on your part, and if so, then yes you would be subject to their limitations. But the vast majority of registrars, and this includes registro.br as far as I can tell according to a machine translation from Portuguese to English [1], allow you to delegate a domain to your own nameservers, and this is the standard way to use a registrar. You pay a registrar to lease a domain, not to host it. Once they have delegated to your nameservers via NS records, you can serve whatever other records you want (subject to the registrar's legal policies). Now, maybe a lot of client software commonly used in Brazil does not support multi-string TXT records, and that would still be an issue, but it's not on the server side.
[1]: In the 5th bullet under section 1.2 of https://registro.br/ajuda/tutoriais-administrativos/ it says (roughly) "In DNS (OPTIONAL), you can inform the DNS servers previously configured for your domain. If you do not have this information, ignore this field. Our system will automatically use the DNS servers made available free of charge by Registro.br."
I wouldn't say it is tricky with a good name server: for instance with bind just split the value into multiple quoted strings and it'll do the rest¹.
Though while it is well known, it doesn't seem to be well documented away from many forum posts discussing the matter: after a little searching I can't find reference to the issue in bind documentation or relevant RFCs. The RR format allows RDATA to be longer than 255 octets (RDLENGTH is an unsigned 16-bit value, not 8-bit) so presumably the limit is imposed by the zonefile format. The only reference to 255 octet limits in RFCs 1034 & 1035 is the length of a full name (with individual labels making up a name being limited to 63 octets).
Of course many UIs for editing zone files or other stored RR information, or other DNS management interfaces, might implement longer RDATA support in a worse way or not support longer RDATA values at all.
----
[1] I'm not sure what “the rest” is (I might look deeper later)