DNS security is important but DNSSEC may be a failed experiment
- Reference: 1753424774
- News link: https://www.theregister.co.uk/2025/07/25/systems_approach_column_dns_security/
- Source link:
It turns out that, if you have your domain hosted by a big provider (we happen to use GoDaddy), it's easy to turn on DNSSEC. But I think it says a lot that it took us this long (and the stimulus of working on a new security book) to get us to turn on DNSSEC. By contrast, we would never think of running a website in 2025 without HTTPS.
For the last couple of months, my focus for the new book has been on infrastructure security. Because these technologies are not directly end-user focused, it has been a challenge to gather information about what is really going on in terms of deployment. As [2]I reported a few weeks back , there are some bright spots in the [3]long and slow process of securing internet routing, notably the adopting of route origin validation (ROV, now over 50 percent) and the introduction of AS Provider Authorization ( [4]ASPA [PDF]). But the domain name system is also a critical piece of infrastructure with [5]well-known vulnerabilities to attack – how are we doing at securing it?
The heart of the problem with DNSSEC is lack of user visibility
The Internet Society has a [6]helpful dashboard of deployment stats for a number of "enabling technologies" supporting the internet, and DNSSEC is arguably the worst performing technology at 34 percent. HTTP version 3 has reached only 25 percent, but it has done so in four years as compared to the 28 years since publication of the first DNSSEC RFC. Meanwhile HTTPS, which is roughly the same age as DNSSEC, is enabled at 96 percent of the top 1,000 websites globally.
In addition to the dashboard, I found two blogs that shed light on the failures of DNSSEC: Geoff Huston from APNIC has written " [7]Calling Time on DNSSEC? ” and Edward Lewis of the Internet Society followed up with " [8]Where did DNSSEC go wrong? " The cumulative list of drawbacks and suboptimal design decisions enumerated in those two blogs left me pretty convinced that we're not going to see a big uptick in DNSSEC deployment anytime soon, even as I added one more domain to the deployment list myself.
[9]
Huston notes the similar timing of DNSSEC development relative to SSL/TLS and HTTPS, and the different trust models that they deliver. Both appeared on the scene in the mid 1990s as the Web was bringing the Internet to a much larger audience. Attacks on DNS have been known since 1990. What DNSSEC tries to do is assure a client that the name-to-address translation function of DNS has been done correctly without interference from an attacker. In other words, DNSSEC assures me that I really am talking to the IP address corresponding to the domain name that I entered.
[10]
[11]
By contrast, TLS assures me that I am talking to a server controlled by the entity named in the certificate. Of course, most people don't look at either IP addresses or certificates; the standard TLS implementations show a padlock icon in the browser when all is well (and raise warnings when the certificate is invalid). This is usually enough for the user to feel reassured that the security of the site is OK.
I think this gets to the heart of the problem with DNSSEC: a lack of user visibility. DNSSEC does not directly make a user aware that they are connected to the site they wanted to connect to. I was able to turn on DNSSEC for [12]systemsapproach.org because it was free and easy, but the experience of visitors to our site didn't change. How much would I have been willing to pay for that service if my DNS provider wanted to charge for it?
We're not going to see a big uptick in DNSSEC deployment anytime soon,
By contrast, I actually did pay for a TLS certificate a few years ago for another domain I control (for a local running club) because I believed it delivered real value: making the site more discoverable in search engines, and making it look more "trustworthy" to users. I'm not sure I'm getting enough value from DNSSEC to pay extra for it – thankfully I didn't have to.
DNSSEC validation
In the absence of a little padlock icon to tell me whether DNSSEC was working properly, I looked around for some tools to validate our DNSSEC operation, and I found a couple of good ones: the [13]DNSSEC Debugger from Verisign and the open source [14]DNSviz tool. Both of them show that we have successfully established a [15]chain of trust from the root zone via the .org zone and on to the [16]systemsappproach.org zone.
The website DNSviz very nicely produces a very detailed graphical representation of the chain of trust for any website. Here's what it produced for systemsappproach.org.
[17]
A diagram of the DNSSEC authentication chain for systemsapproach.org created at dnsviz.net - click to enlarge
If you're familiar with how chains of trust are established by [18]certification authorities for Transport Layer Security (TLS) then this should look pretty familiar.
One interesting detail that distinguishes this chain of trust from TLS, however, is that there are no choices of CA when it comes to getting your key signed: since our domain sits within .org, we depend on the .org domain to sign our key. If we happened to be sitting under a parent domain that did not implement DNSSEC (as is the case for about 30 percent of country-level domains, for example), we'd be out of luck. That dependence on implementation all the way from root to leaf is another reason why DNSSEC hasn't progressed the way HTTPS has done.
[19]
While our prior comparison between TLS and DNSSEC might suggest that we can just relax and let our security be handled between browser and website using TLS, there are plenty of reasons to remain concerned about the security of the DNS. Modification of DNS traffic is routinely used as a tool for censorship, as was well reported in " [20]The Collateral Damage of DNS Censorship ." One of the surprises in that paper is the extent to which DNS censorship within China has an impact on queries that originate and terminate outside China but have the misfortune to pass through a Chinese ISP.
[21]To progress as an engineer career-wise, become a great communicator
[22]What does it mean to build in security from the ground up?
[23]Contrary to some, traceroute is very real – I should know, I helped make it work
[24]Will passkeys ever replace passwords? Can they?
And this isn't limited to China. (Will the US need its own great firewall to [25]prevent access to the Chinese version of TikTok , for example?) A more recent report on how DNS is used for censorship is [26]The Lock Net . Working around censorship is a big enough topic to need its own post (if not a book). I raise this issue to suggest that we should not simply give up on securing DNS.
With today's widespread adoption of TLS it should come as no surprise that there are now standard ways to send DNS queries and responses over TLS-secured channels. There have been a few similar proposals to achieve this outcome, with the IETF having standardized both [27]DNS over TLS (DoT) and [28]DNS over HTTPS (DoH) in RFC 8484. There is some debate about the merits of each but for the purposes of this post the differences are not too significant. You can configure DoH in most web browsers.
While these approaches ensure that we have a secure channel to the intended DNS resolver, they lack assurance that the DNS information being provided by the resolver is correct. We can be sure of the identity of the resolver we are connected to, since that is provided by its TLS certificate, and the fact that the query sent and response issued by the resolver have not been modified or observed by an intermediary, since they are both encrypted and authenticated. But if the resolver itself is giving bad information, perhaps because the information provided to it from upstream in the DNS hierarchy has been corrupted, the client will be none the wiser.
So while the need to deploy DNSSEC all the way up the hierarchy is something of an impediment to deployment, it does provide a level of security that isn't provided by simply securing the client-to-resolver channel. Indeed we can think of DNSSEC and DoH/DoT as complementary: DNSSEC ensures the validity of information in the resolver, and DoH/DoT gets you a secure channel from client to resolver.
[29]
For completeness, I want to mention [30]Oblivious DNS , which extends DoH to make surveillance of DNS traffic more difficult. It's actually one of several technologies used in [31]Apple's Private Relay and there is a [32]blog about it from Cloudflare.
So where does this leave us? Well, the poor rate of deployment of DNSSEC seems like an outage to me, but most of the internet's users don't care about DNS resolution as much as they care about application-level security that is provided by HTTPS. But since DNS remains fundamental to the operation of the internet, and since attacks continue, I hope that there will be continued efforts to improve its security, even if DNSSEC itself turns out to be a bit of a failed experiment. ®
Larry Peterson and Bruce Davie are the authors behind [33]Computer Networks: A Systems Approach and the related [34]Systems Approach series of books. All their content is open source and available for free on [35]GitHub . You can find them on [36]Mastodon , their newsletter [37]right here , and past The Register columns [38]here .
Get our [39]Tech Resources
[1] http://systemsapproach.org
[2] https://systemsapproach.org/2025/05/19/securing-internet-infrastructure/
[3] https://dl.acm.org/doi/pdf/10.1145/2668152.2668966/
[4] https://storage.googleapis.com/site-media-prod/meetings/NANOG89/4809/20231017_Sriram_Aspa-Based_Bgp_As_Path_v1.pdf
[5] https://www.cloudflare.com/learning/dns/dns-cache-poisoning/
[6] https://pulse.internetsociety.org/en/technologies/
[7] https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/
[8] https://blog.apnic.net/2024/07/05/where-did-dnssec-go-wrong/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aIZNL9JAbqbT_UXxyh40ywAAAJI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aIZNL9JAbqbT_UXxyh40ywAAAJI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aIZNL9JAbqbT_UXxyh40ywAAAJI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[12] http://systemsapproach.org
[13] https://dnssec-debugger.verisignlabs.com/
[14] https://github.com/dnsviz/dnsviz
[15] https://en.wikipedia.org/wiki/Chain_of_trust
[16] http://systemsappproach.org
[17] https://regmedia.co.uk/2025/07/24/supplied_dns_validation.png
[18] https://book.systemsapproach.org/security/key-distro.html#certification-authorities
[19] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aIZNL9JAbqbT_UXxyh40ywAAAJI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[20] https://dl.acm.org/doi/10.1145/2317307.2317311
[21] https://www.theregister.com/2025/05/18/communications_for_engineers/
[22] https://www.theregister.com/2025/02/02/security_design_choices/
[23] https://www.theregister.com/2024/12/14/mpls_traceroute_history/
[24] https://www.theregister.com/2024/11/17/passkeys_passwords/
[25] https://www.reuters.com/world/china/tiktok-building-new-version-app-ahead-expected-us-sale-information-reports-2025-07-06/
[26] https://locknet.chinafile.com/the-locknet/part-3/
[27] https://www.rfc-editor.org/info/rfc7858
[28] https://www.rfc-editor.org/info/rfc8484
[29] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aIZNL9JAbqbT_UXxyh40ywAAAJI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[30] https://www.rfc-editor.org/info/rfc9230
[31] https://support.apple.com/guide/iphone/protect-web-browsing-icloud-private-relay-iph499d287c2/ios
[32] https://blog.cloudflare.com/oblivious-dns/
[33] https://book.systemsapproach.org/
[34] https://www.systemsapproach.org/
[35] https://github.com/SystemsApproach
[36] https://discuss.systems/@SystemsAppr
[37] https://systemsapproach.org/newsletter/
[38] https://www.theregister.com/Tag/Systems%20Approach
[39] https://whitepapers.theregister.com/
The 40 even seems to be a low number for me, must excluding some which are required to run unencrypted (.crl check as the "funniest" example here, since it is used for HTTPS together with a few other HTTP URLs stored in the certificate for validation).
DNSSEC is good DANE is better
this feels like well researched click bait
basically the certificate authority PKI based system is broken
99% use it
Those that do not have advantages of caching and they like that...
Those that do use TLS backed by a CA are susceptible (can be hacked) by a nation state without any trouble at all simply ask your local CA company (there are american and chinese CA's in your browser)
so really its a farce currently the only way out is DNS
if a chinese dissident contacts the americans the chinese have the power and can compel a CA to sign a cert that allows them to intercept all traffic and it appears to be signed by USA equally American dissident contacts the china the americans have the power and can compel a CA to sign a cert that allows them to intercept all traffic
IF we had DNSSEC and DANE then the local gov for that domain is in charge nothing to do with centralised power...
so yeah sign your domain its not hard
Re: DNSSEC is good DANE is better
> basically the certificate authority PKI based system is broken
You are citing that one "root of trust" weakness I skipped to mention to make my post small :D. Opening that can of worms dictates that everyone runs his own CA in a safe way and use your own certificates everywhere whenever possible.
Re: DNSSEC is good DANE is better
Sure, but sane presets would make this trivial, and while have been available from day one.
Certificates? IP address?
"By contrast, TLS assures me that I am talking to a server controlled by the entity named in the certificate. Of course, most people don't look at either IP addresses or certificates;"
Most people don't look at the URL, or where the picture that are embedded in the mail they received from "thisisyourbank-honestly.yeahright.fuck.up" are sourced by a server in korea. HTTPS is used because all the "modern" browser automatically add 'https' in front of the url unless you specify http by hand.
Seriously, https, dnssec and html version wathever add NOTHING about security.
Re: Certificates? IP address?
"HTTPS add nothing about security"? Classical AC bull. You from Pre-Snowden era? Yep, over 10 years in the past.
Re: Certificates? IP address?
"Most people don't look at the URL"
Indeed, and on Apple devices the default settings for Safari and Mail are not to show the full URL so it might not matter if you did look at it.
Re: Certificates? IP address?
IMHO that's what the default should be. Because defaults should be set for the TYPICAL USER, not for the type of people who visit sites like this and post in threads about DNSSEC! You can click in the URL bar and it'll expand the URL.
You don't want people looking at the "full URL", because that's what scams rely on! Make visible ONLY the part that matters for distinguishing normal use from a scam and there's a better chance the average person sees it. Do you think it would be easier for a typical internet user to tell something is amiss if the URL shown is:
yourbank.com.scam.xyz/secure/?ref=DLFUJKD342jlafdsj09FJKLDFJasdfl+flffj93ladf&auth=alsdfladsfho3hfioa908FL39asdfaadodsldkflalkdfj
Or if what is shown is:
scam.xyz
If all browsers did like Safari scammers would be forced to adjust their tactics to compensate. Maybe they're able to register "yourbank.xyz" which is not as obviously a scam but most casual internet users have come expect domains to end with ".com" to the point where some are suspicious of even ".net" or ".org". Probably the only scam domain that could trick Safari users is ".co" - IMHO it was a mistake that they allowed Columbia to choose it. Your chances of noticing that single missing "m" are a lot better if all you see is "yourbank.co" without all the irrelevant (to people who don't post in topics about DNSSEC on internet forums) detail that comes after.
Re: Certificates? IP address?
> Seriously, https, dnssec and html version wathever add NOTHING about security.
Then you won't mind me installing gov.crt on this machine sir, will you? Step aside please, this won't take a moment.
Re: Certificates? IP address?
Do you mean like what your company does so their firewall can examine all your traffic that is running over https? Pushing out and updated trusted CA list through Microsoft active directory and then resigning certificates on the Fly so they can examine the internal traffic something that's been done for over a decade. So you don't really have any firm trust model.
Re: Certificates? IP address?
If you want to attach to my VPN, you have to abide by my rules. Don't download porn on the company network please. Likewise, don't expose your personal info down my network, I don't want to become a GDPR data processor for you and your extended family.
There is a perfectly good trust model here. It's just that it's about the network not trusting you . Ye who click on All The Links and Open All The invoice.zip.exe .
Re: Certificates? IP address?
"HTTPS is used because all the "modern" browser automatically add 'https' in front of the url unless you specify http by hand."
Incorrect. Google Chrome browser gives the option to not only use "only HTTPS" to connect to a website, but also puts up a warning page of the URL you enter points to a website that does NOT use HTTPS, and asks if you want to go "Back to Safety" when that option is turned on. The Enhanced Security options enforce an even higher level of security by sending the URL to Google to ensure it's legit and not a phishing attempt or a malware website. This Enhanced Security is turned on by default (and locked into the On position) for Pixel users who turn on the Advanced Protection Program setting. I suggest you not comment anymore, "Coward".
Another barrier to adoption
Implementing DNSSEC on your domain is nice and all, but the biggest barrier in my opinion is client validation of DNSSEC.
Every resolver i've come across has DNSSEC validation turned off by default (although most of them do support it), and no one cares enough to turn it on.
I don't understand why it's not turned on by default. For most resolvers the only reason it will drop queries is when DNSSEC is available for the upstream resolver and domain, and the reply is bogus (no pass). I've personally only had a DNS issue caused by false bogus replies once over the last couple of years, and it was a transient error.
I feel like at the very least the resolvers that market themselves as "secure" should validate this.
Re: Another barrier to adoption
When the TLS certificate doesn't validate because it's expired or none of the Subject Alternate Names match, the Browser throws a (somewhat) decipherable error.
When DNSSEC validation fails, the name doesn't resolve at all.
It sometimes creates issues when people make errors renewing their keys or moving DNS-servers, fix them - but resolvers around the world still have the old, wrong information cached.
Users then complain that "Google can resolve it, Cloudflare can resolve it".
Re: Another barrier to adoption
The resolver needs some way of telling the client "site has DNSSEC enabled but it didn't validate" so the client can choose what to do.
The question, if a browser is the client, what should it do? Give people a warning to click through like they get if SSL validation fails? Or put some icon that no one knows what it means in the URL bar next to the SSL padlock? [I will note that I looked at my Firefox URL bar and thought "hey they got rid of the padlock" because the padlock looks very much like the "person" icon sites use - like the one to the left of "my account" on this site - so it didn't register as a "padlock" to me]
Re: Another barrier to adoption
Is there any client validation for DNSSEC? All this time everything I've read about it is DNSSEC has nothing to do with the end clients it's only for server to server communication (which I understand as being from the authoritative server hosting the zone to the recursive resolver that is caching the data, for which the clients then connect to using regular clear text DNS protocol).
https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
"DNSSEC strengthens DNS authentication using digital signatures based on public key cryptography. With DNSSEC, it's not DNS queries and responses themselves that are cryptographically signed, but rather the DNS data itself is signed by the owner of the data."
As for websites with TLS in 2025, there would be a lot more without HTTPS because most sites don't need HTTPS, most sites are just static crap with nothing to protect(most don't even have any way to input data into them they are simply for showing content), but of course browsers are super anal about that stuff now and thinks everything needs a cert.
Been running my own DNS(and web and email) since 1996, though no need for DNSSEC for my stuff, no org I've ever worked for has expressed interest in deploying it either, it's never come up in a conversation ever that I can recall over the past 25 years.
Re: Another barrier to adoption
Most large DNS resolver providers have DNSSEC validation enabled.
Ie. Google and Comcast DNS resolvers will block resolution of any domain not passing DNSSEC validation.
So, yes, "clients" do typically have it enabled already without their knowledge.
Of course, you can still run your own resolver, and omit turning on DNSSEC validation. But the people that depend on running their own DNS resolver are miniscle compared to the rest of the Net.
But if the resolver itself is giving bad information...
Having good user feedback when something is off is important, but you cannot implement that until everyone's endpoints are signing their responses upstream.
This was very much fixed with https with a double pronged attack- Chrome and Firefox explicitly started upgrading http requests, and made visiting http as big red and scary as an invalid certificate.
Without Let's Encrypt, it would have just kicked 95% of the internet into the wilderness. So there needs to be a body willing to step up and fund managing a CA.
The whole DNS is basically outdated tech
DNS is pure convenience. Just because a name or term is easier to keep in mind than an IP-address is the whole reason for the existence of the DNS.
It is overdue for a technology change, but rather than going for a new, better tech we try to make the old do more with some duct tape.
Re: The whole DNS is basically outdated tech
Right... so what do you propose? We all change from domain names to IP addresses and market them like phone numbers?
Might work, but they could be hard to remember (especially when we transition to IPv6 soon TM ), and they are also a bit more dynamic and subject to change than phone numbers.
I guess it would be convenient to have some sort of "phone book for the internet" to easily look up an IP address based on a name, and being able to update it regularly.
...Wait a second....
Re: The whole DNS is basically outdated tech
Might work, but they could be hard to remember (especially when we transition to IPv6 soon TM )
Only using IP addresses would force a hard transition to IPv6 - there aren't enough IPs to go around all the cPanel/Plesk/Virtualmin servers hosting hundreds or even thousands of domains from a single IP(v4).
This works if you can peer into the HTTP request for the desired domain (and ESNI has extended that to serve the correct certificate ahead of negotiating your TCP session).
If all you're giving them is an IP address, then it'll have to be one-ip-per-site, which would probably be realised as a server having a single /64 prefix and then each site having it's own 128.
I suppose large businesses would be able to shell out £££ for "desirable" and easily remembered IPv4s like 2.2.2.2 or 1.2.1.2. The rest of us would be on v6. The routing tables would be... fun. Aggregation? We've heard of it!
As you say, we'd need a big old yellow pages to look up the addresses for individual sites. Eventually, someone would probably digitise it so you can just type in a memorable identifier for your desired site and it'll take you there!
Re: The whole DNS is basically outdated tech
You can't just say "we need a technology change" without even providing one shortcoming of DNS that its replacement must have, or considering how a transition to this "better world" would take place.
Anyway we have effectively replaced DNS as far as almost everyone's usage - we rely on Google and/or autocomplete to find sites we frequently visit so we pretty much never type out "theregister.com". Or maybe in some cases always maintain an active browser tab on a particular site. DNS is as invisible to the average person as the pipes under the street that insure they get water when they turn on a tap.
Ask Google to make it a page rank criterium
If the Google ranking of your web site depended on DNSSEC (as is HTTPS) then it would reach 95% in a few years.
I know that Google is evil & all that but it might actually do this if someone asked the right person nicely.
Re: Ask Google to make it a page rank criterium
There you go, that's the answer! But we better have them make that change quick because if AI catches on like those investing countless billions in building all those datacenters hope it does, Google's page ranking will be irrelevant in a few years and will no longer act as an incentive to get people to add DNSSEC.
Re: Ask Google to make it a page rank criterium
I'm pretty sure that page ranking is already overtaken by events. Evidence? The discrepancies between Google's AI summaries and the URLs that Google actually list are getting greater (and weirder) every day.
Honest questions here:
- why should my site, hosted on a Pi3 at my home, where you input your ham radio callsign and get your QLS card (if we've had a QSO) must be https?
- why should my personal blog where no comments are allowed, hosted on the same Pi3, must be https?
- why should all of the above must use DNSSEC?
What's the benefit for me personally? I don't store personal information (except mine, which Google & all already have), I don't use cookies, I don't keep logs of who used those sites, I don't do adverts or use any kind of analytics, so don't start with OMG! securitys.
For https:
Users will not be met with a scary warning from their browser. I see some browsers make it hard to get around.
I see browsers auto upgrade to https, and then going 'page not found', when 443 is not open.
Search engines will not crawl your site, so it will not be found.
Free WiFi fex in a hotel, would inject its own ads in the pages you visited. Have not seen this in a long time, but I have not seen http in a long time either.
For http:
AI crawlers will not crawl your site.
So if a site is used by more than a few friends, that know how to trick their browsers, it needs https, even if there is nothing to protect.
The only real benefits in terms of security would be against MITM attacks when visitors are using a compromised device or network. In that case they're cooked either way, it's not your problem.
Warnings for http sites are pretty mild these days for most browsers (especially compared to invalid SSL certs), so that doesn't really matter for the end user.
For situations like yours it's more a case of "why not?". On most DNS providers i've come across you can turn on DNSSEC with a simple toggle, and if you are able to open up port 80 for Let's Encrypt (or if your DNS provider has an API they likely have a DNS01 challenge extension too), there's little reason not to use HTTPS.
The answer is you shouldn't be forced to use or care about SSL or DNSSEC. Unfortunately browsers make it more difficult than it should to add exceptions for sites to connect without SSL, especially since they will try to add "https" by default to a raw domain name so you have to explicitly type "http://site" to get around it which is annoying.
TFA says:
"By contrast, TLS assures me that I am talking to a server controlled by the entity named in the certificate"
If by entity, you mean "the organization you would think as a lay person based on looking at the Organization attribute of the Subject Name section of the certificate" - I don't think that has been meaningfully true in decades, if it ever was. Today with LE, all TLS assures me is
- traffic between my browser and the website (or at least some proxy between me and the website, depending on my network and installed certs on my device) is encrypted, and
- the web server has a certificate that some issuer thought was reasonable to issue to them, based perhaps on nothing more than that they could get DNS resolution to point to their site for at least a little while
TLS still has value for the first item, but it only means something about "you are talking to the site you think you are" for sophisticated users who know how to look under various covers.
Even more .. obviously most sites are composed of data from more than one url/domain/site. Just because I'm on theregister.com doesn't mean all of the requests(almost guarantees for most sites) is coming from that site. Ads, trackers, pixels, embedded media content, may go to any one of a million other hosts(of which owner of the site almost certainly cannot completely vouch for), and of course all the user sees is theregister.com in their address bar.
so TLS doesn't really assure much of anything in that regard. Even google has been caught serving malware from their "trusted" sites with SSL certs and fancy TLS encryption.
Key rotation is a PITA
I control about a dozen domains. I implemented DNSSEC a few years back and then turned it off a few months later. The key rotation was the barrier as my domain registrar doesn't allow me to update the keys in an automated way. I have to manually log in to their website and copy and paste keys into various fields on a web page. I forgot to do this one month and the keys expired. The result is not an error message to the site visitor, but the website suddenly ceases to exist.
And because of the way DNS is cached, key rotation requires having both old and new keys present simultaneously. I just found the whole experience to be a nightmare for such little overall gain.
Re: Key rotation is a PITA
You were doing it wrong. You only need to rotate the ZSK, and any sane DNS software handles that automatically.
I have had 20+ dnssec domains running for years, and once they have been set up, they run themselves. The only additional work setting them up is pasting the DS key into the registrars UI (and that's only if they don't have an API you can use, and just about all do these days), but that only needs to be done once.
[1]RFC 4641 - DNSSEC Operational Practices, Version 2 :
.... a reasonable effectivity period for KSKs that have corresponding DS records in the parent zone is of the order of 2 decades or longer . That is, if one does not plan to test the rollover procedure, the key should be effective essentially forever, and only rolled over in case of emergency.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc4641bis-10#section-3.3
The main reason that HTTPS took off is that Google stopped putting sites with HTTP addresses in its search results.
If Google stopped putting sites which weren't protected by DNSSEC in its search results, what do you think would happen?
First google waits until 18 days certificates are the norm, denies any older in search, and THEN enforces DNSSEC with the same certificate timeout requirement.
A lot of crap sites will disapper from the net. I'd call that a bonus.
It seems easy enough to turn on
I run my own dns servers and I tell bind to sign the domain. About a day later, the name reseller has picked up the signed data, I click a box and DNSSEC is on. Seems easy enough.
Re: It seems easy enough to turn on
I do too, and yes, It is entirely that simple.
40 of the top 1,000 web sites do not use HTTPS? Is this including darknet markets or something?