On Mon, Jun 23, 2025 at 12:28:56AM -0400, Patrick Domack via dane-users wrote:
How many entries approx can fit without requiring the fallback? I believe I have calculated this years ago, but. I normally have my systems manage 3, future, current, and past
The arithmetic depends on what else your server chooses to return in response to a TLSA query, and what DNSSEC signature algorithm you're using. Each additional "3 1 1" RR after the first adds
- 2 byte "pointer" to the owner (in first RR or qname) - 2 byte type - 2 byte class - 4 byte TTL - 2 byte payload length - 35 byte value (usage, select, mtype, data)
So thats 47 bytes. The DNSSEC signature size is unaffected, it signs the RRset, not individual records.
Unless 94 bytes for two more records pushes the overall response size past ~1400 bytes (sometimes as low as just over ~1200 bytes depending on client EDNS size option and server config) this should not lead to TCP fallback, or dramatically larger response packets.
The chances of TCP fallback go up if you're using unreasonably large RSA keys (say a 4096-bit RSA ZSK), instead of the more secure and more compact ECDSA P256 (algoriutm 13), or if your authoritative nameserver returns also a signed NS RRset in the authority section of every response and perhaps also (optionally) signed glue in the additional section, maybe signed additional addresses for the MX host, ...
Much depends on the nameserver code and especially configuration settings. For my BIND authoritative server and MX host with two TLSA records, with two in-bailiwick nameservers, each having A and AAAA records the response size with default BIND settings is 1226 bytes, because of this returns a signed NS RRset in the authority section and 4 additional glue RRsets (but just 3 signatures, b/c optional).
Setting "minimal-responses yes":
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-mi...
returns just the signed TLSA RRset, using 344 bytes, with plenty of room for more. Even if I included all 10 "2 1 1" records for the LE intermediate issuers (RSA and EC), the two ISRG Roots, and two "3 1 1" records each (current + next) for two algorithms (I have RSA and ML-DSA-65 SMTP server keys), I'd then have 14 more TLSA RRs adding 658 bytes, which would still fit in a "minimal" UDP response.