Some MTA operators neglect to prune outdated TLSA records with "usage" DANE-EE(3). As keys or certificates are replaced, they add new matching TLSA records, never dropping the records matching the outdated keys.
This largely defeats the purpose of key or certificate rollover, since it blesses (at least in the context of DANE) ongoing misuse of any past compromise of the old key. And it results in ever growing TLSA records DNS payload sizes, resulting initially in needlessly large UDP payloads, and ultimately failover to TCP for every lookup.
It is best to avoid this pattern and prune outdated TLSA records once the corresponding key (3 1 X) or certificate (3 0 X) is no longer in use.
Example (current DANE-EE(3) count record holder):
_25._tcp.mail.evocat.net TLSA 3 1 1 83037f6a136945f50dbc4e4cb65d0c154b726992eafb55ba5b3b4e4bcbde9715 ; 2022-05-27 - present _25._tcp.mail.evocat.net TLSA 3 1 1 379f309bff870568b06756c3ccb321692fdde8e970950ca0cbae3b4595e5b538 ; 2022-07-27 - present _25._tcp.mail.evocat.net TLSA 3 1 1 a31fdc67764edc9e7bc734b907bd8b514f4616d2e8e2dfbcb01c8dc557acea34 ; 2022-09-25 - present _25._tcp.mail.evocat.net TLSA 3 1 1 21e1d9438b6528948794244cf1caf5802c6edb5a3415d33d7299c7daadee3834 ; 2022-11-24 - present _25._tcp.mail.evocat.net TLSA 3 1 1 c7be1ef02c2556cf4f421cb724b0327676d2d144790042a3aa603dfc96fb4a5a ; 2023-01-23 - present _25._tcp.mail.evocat.net TLSA 3 1 1 8115a64ccf2aa3b7e06c2e0cab0b972ca98eb83c707b68fc725c02195ce8d47f ; 2023-03-25 - present _25._tcp.mail.evocat.net TLSA 3 1 1 37c12ea11d4cd88c756768308a13587ebdd4fe626f7dc2512e37c85d1fe20d14 ; 2023-05-24 - present _25._tcp.mail.evocat.net TLSA 3 1 1 196d17a19f5dc1c0ad4a58eb8afff5e07b92ba72cd6d776b941e4233856c0636 ; 2023-07-24 - present _25._tcp.mail.evocat.net TLSA 3 1 1 3b3ee102ccb95a75ca73b337b4ba88d33b3cff3b1a2309227d71ccd808144482 ; 2023-09-22 - present _25._tcp.mail.evocat.net TLSA 3 1 1 e896a20362f25d49a869f12ff99878b86e37dc86af38c04c29ab8992a6502f30 ; 2023-11-21 - present _25._tcp.mail.evocat.net TLSA 3 1 1 7475c707cdf5137eea74ea02f23b81ede7a1b4d2edb65af08c8cc1749a3f5c99 ; 2024-01-21 - present _25._tcp.mail.evocat.net TLSA 3 1 1 e5949d3fb74344210439161d7bf2fb53e0bc68fe74a1e21a870c8881fbcd5901 ; 2024-03-21 - present _25._tcp.mail.evocat.net TLSA 3 1 1 31ea43c1733770793b157aa8963a2fc3dfc969ad3c6849c31d33e14ff643615e ; 2024-05-20 - present _25._tcp.mail.evocat.net TLSA 3 1 1 87e19f49bf9fae3273509940f27931dcf2edd3fc132eb1f2ddbe56e2bc2e0410 ; 2024-07-19 - present _25._tcp.mail.evocat.net TLSA 3 1 1 a0c849a30b9cf92c206a28723324ed40318a7e2a82e56104959588a795db3669 ; 2024-09-19 - present _25._tcp.mail.evocat.net TLSA 3 1 1 468e0e2e119ea97bc8ab3c34792fa479dd8ea2d47e62a868020e06dc3d25c304 ; 2024-11-17 - present _25._tcp.mail.evocat.net TLSA 3 1 1 d6fffb71e83fcec0dde93edbbc1c50b0fdff21dffc78390c309c1cf3dd350370 ; 2025-01-16 - present _25._tcp.mail.evocat.net TLSA 3 1 1 a2cb82878da95d9bae063340e6312ab7fe85100671899bf13793dc8893e42ac9 ; 2025-03-17 - present _25._tcp.mail.evocat.net TLSA 3 1 1 e4ccf3f074a06cd30722fc42df127ef8e682136b40116e6bb77adf9679140f2f ; 2025-05-16 - present
The authoritative DNS server returns a truncated (TC=1) response, leading to TCP fallback and high, from my vantage point, latency:
$ dig @ns1.evocat.net +norecur +dnssec +noall +stats -t tlsa _25._tcp.mail.evocat.net ;; Query time: 1014 msec ;; SERVER: 185.157.233.76#53(ns1.evocat.net) (TCP) ;; WHEN: Mon Jun 23 04:03:04 UTC 2025 ;; MSG SIZE rcvd: 2886
By way of comparison, the "A" RRset response fits in UDP and the latency I see is 5x lower:
$ dig @ns1.evocat.net +norecur +dnssec +noall +stats -t a mail.evocat.net ;; Query time: 201 msec ;; SERVER: 185.157.233.76#53(ns1.evocat.net) (UDP) ;; WHEN: Mon Jun 23 04:04:55 UTC 2025 ;; MSG SIZE rcvd: 1106
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
Quoting Viktor Dukhovni ietf-dane@dukhovni.org:
Some MTA operators neglect to prune outdated TLSA records with "usage" DANE-EE(3). As keys or certificates are replaced, they add new matching TLSA records, never dropping the records matching the outdated keys.
This largely defeats the purpose of key or certificate rollover, since it blesses (at least in the context of DANE) ongoing misuse of any past compromise of the old key. And it results in ever growing TLSA records DNS payload sizes, resulting initially in needlessly large UDP payloads, and ultimately failover to TCP for every lookup.
It is best to avoid this pattern and prune outdated TLSA records once the corresponding key (3 1 X) or certificate (3 0 X) is no longer in use.
The authoritative DNS server returns a truncated (TC=1) response, leading to TCP fallback and high, from my vantage point, latency:
$ dig @ns1.evocat.net +norecur +dnssec +noall +stats -t tlsa_25._tcp.mail.evocat.net ;; Query time: 1014 msec ;; SERVER: 185.157.233.76#53(ns1.evocat.net) (TCP) ;; WHEN: Mon Jun 23 04:03:04 UTC 2025 ;; MSG SIZE rcvd: 2886
By way of comparison, the "A" RRset response fits in UDP and the latency I see is 5x lower:
$ dig @ns1.evocat.net +norecur +dnssec +noall +stats -t a mail.evocat.net ;; Query time: 201 msec ;; SERVER: 185.157.233.76#53(ns1.evocat.net) (UDP) ;; WHEN: Mon Jun 23 04:04:55 UTC 2025 ;; MSG SIZE rcvd: 1106-- Viktor.
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.
On Mon, Jun 23, 2025 at 03:05:19PM +1000, Viktor Dukhovni wrote:
Setting "minimal-responses yes":
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-minimal-responsesreturns just the signed TLSA RRset, using 344 bytes, with plenty of room for more.
Your MX host's zone is signed with ECDSA, and the ns[12] nameservers return minimal responses:
$ dig +noall +stats +norecur +dnssec -t tlsa @ns1.patrickdk.com _25._tcp.kishi.patrickdk.com ;; Query time: 12 msec ;; SERVER: 205.233.73.235#53(ns1.patrickdk.com) (UDP) ;; WHEN: Mon Jun 23 05:08:44 UTC 2025 ;; MSG SIZE rcvd: 260
But the third nameserver is less parsimonious:
$ dig +noall +stats +norecur +dnssec -t tlsa @ns-global.kjsl.com. _25._tcp.kishi.patrickdk.com ;; Query time: 61 msec ;; SERVER: 23.128.97.53#53(ns-global.kjsl.com.) (UDP) ;; WHEN: Mon Jun 23 05:11:34 UTC 2025 ;; MSG SIZE rcvd: 989
Yet still has space for ~10 more TLSA records before nearing ~1400 bytes or ~4-5 more to get over ~1200 bytes. And it may choose to prune the additional section rather than set TC=1 should the response size grow larger.
participants (2)
-
Patrick Domack -
Viktor Dukhovni