Hi Viktor,
Apologies for the late reply.
While DNSSEC adoption is strong in some ccTLDs, two issues prevent it
from being a complete solution:
1.
*TLD limitations*: Some TLDs don't support DNSSEC at all (e.g., .im,
popular for XMPP services). Organizations using these domains cannot
deploy DNSSEC regardless of how motivated they are. For XMPP,
changing domains isn't feasible since they're part of user
identifiers ([email protected]).
2.
*Infrastructure breakage*: Some DNS forwarders, particularly home
routers, truncate responses and lack EDNS support (see Table 2, p.
583: https://www.usenix.org/system/files/sec20-zheng.pdf). This
breaks DNSSEC validation even for domains that properly support it.
These limitations affect a significant portion of services that need
secure delegation today. The SRV-ID certificate approach could provide a
practical alternative where DNSSEC isn't viable.
Best regards,
Michel Le Bihan
Le 01/09/2025 à 05:43, Viktor Dukhovni a écrit :
On Sun, Aug 31, 2025 at 09:18:38PM +0200, Michel Le Bihan wrote:
The Security Problem
Without DNSSEC (which has very limited deployment according to Cloudflare
and SIDN statistics),
Global average fraction of DNSSEC signed domains is ~6.5%, it is however
rather unevenly distributed. The below ccTLDs have 20% or more of their
delegations DNSSEC-signed:
https://stats.dnssec-tools.org/#/?top=tlds&tld_tab=3
TLD #Zones #Signed %Signed #DANE %DANE
TOTAL 370990810 23951119 6.46 4277775 17.86
er 53 40 75.47 0 0.00
dk 1303448 863667 66.26 367844 42.59
cz 1504173 945604 62.87 137880 14.58
nl 6109695 3817016 62.47 1054927 27.64
se 1386049 837283 60.41 338179 40.39
sk 466674 266802 57.17 22761 8.53
no 855870 488932 57.13 150899 30.86
nu 203088 114855 56.55 33337 29.03
ch 2535106 1325679 52.29 587647 44.33
li 68737 22104 32.16 7182 32.49
be 1704076 499395 29.31 143082 28.65
fo 8414 2465 29.30 233 9.45
ee 174818 43054 24.63 18794 43.65
re 39807 9705 24.38 931 9.59
yt 5453 1179 21.62 214 18.15
tf 4001 841 21.02 209 24.85
fr 4256065 887877 20.86 77439 8.72
br 5501608 1147110 20.85 2494 0.22
eu 3681490 758904 20.61 115688 15.24
where the DANE counts are for SMTP (_25._tcp TLSA RRs for the
domain's MX hosts) and %DANE is as a fraction of the *signed*
domains. [ Yes, the .er (Eritrea) outlier is not a compelling data
point, but that's also not a compelling reason to exclude it. ]
these SRV-based delegations are vulnerable to DNS spoofing attacks. An
attacker who can manipulate DNS responses can redirect users to
malicious servers, potentially intercepting credentials and
communications.
One obvious suggestion for those facing the issue is to deploy DNSSEC,
which is now a well-established technology.
I've evaluated several approaches, each with significant drawbacks:
DANE (RFC 6698): Requires DNSSEC, which remains impractical due to low
adoption
Can you explain what makes generally modest adoption rates a barrier for
those who are motivated to take advantage of DANE.
_______________________________________________
Uta mailing list -- [email protected]
To unsubscribe send an email to [email protected]
