DNS Security is Important But DNSSEC May Be a Failed Experiment (theregister.com) 71
Domain Name System Security Extensions has achieved only 34% deployment after 28 years since publication of the first DNSSEC RFC, according to Internet Society data that labels it "arguably the worst performing technology" among internet enabling technologies. HTTPS reaches 96% adoption among the top 1,000 websites globally despite roughly the same development timeline as DNSSEC.
The security protocol faces fundamental barriers including lack of user visibility compared to HTTPS padlock icons and mandatory implementation throughout the entire DNS hierarchy. Approximately 30% of country-level domains have not implemented DNSSEC, creating deployment gaps that prevent domains beneath them from securing their DNS records.
The security protocol faces fundamental barriers including lack of user visibility compared to HTTPS padlock icons and mandatory implementation throughout the entire DNS hierarchy. Approximately 30% of country-level domains have not implemented DNSSEC, creating deployment gaps that prevent domains beneath them from securing their DNS records.
First! (Score:4, Funny)
For those who remember when slashdot was good.
Re: First! (Score:3, Funny)
Re: (Score:2)
If your uid was 5 digits or less I'd probably mod you insightful. But since it's not, I'm pretty sure you weren't around here back in the late 90s.
Re: First! (Score:2)
Re: (Score:2)
So did I!
And I used to have a 5 digit id.
Re: (Score:2)
Re: (Score:2)
Correct!
Re: (Score:2)
Re: (Score:2)
Not quite as big a loss as someone who had 10,000 BTC stored on an old hard drive somewhere that got thrown out years ago in a move, but still some sort of loss.
That's better than to have it stolen by a sketchy or poorly secured crypto exchange.
Re: (Score:2)
So did I! :-)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Your UID is post-2001, so you might not have been here in the late '90s, either.
Re: First! (Score:2)
What do Taco and Cowboy Neal have to say about Soviet Russia? Has netcraft confirmed it is still dying?
Re: (Score:2)
Re: (Score:2)
I'd mod funny if I had points.
Re: (Score:2)
First post! :) :)
You misspelled "frist".
Easy Answer (Score:1)
The easy answer is that DNSSec is a solution to a problem that very few have or care about.
Most people are not worried about their DNS traffic being examined. And the problems with DNS traffic being altered or redirected has yet to be a widespread enough problem for the masses to care about.
DNSSec is a solution to a problem that virtually no one has. So, why should they care?
Re:Easy Answer (Score:5, Informative)
Most people are not worried about their DNS traffic being examined.
DNSSEC does not protect against your traffic being examined in any way wahtsoever.
DNSSEC provides digitally signing of DNS zone data so that the DNS resolver can verify the record in the response has not been altered.
the problems with DNS traffic being altered or redirected has yet to be a widespread
In fact it is a widespread problem. One of the major ways malware would be spread was by malicious actors pointing users' routers at malicious DNS servers.
Unfortunately DNSSEC would not help with this issue either; because Microsoft does not ship Windows with a built-in DNSSEC-validating recursive DNS resolver. Probably because it would conflict with the idea of having "fake" internal domain names which Active Directory is dependent on, since a recursive DNS resolver component has to start straight at the official source of truth (The internet's root nameservers).
Re: (Score:3)
Also for most everyday users, DNS-over-HTTPS band-aids a lot of the problems DNSSEC could fix.
Re: Easy Answer (Score:2)
Re: (Score:3)
The end-to-end integrity of the DNS query is still not guaranteed unless DNSSEC is used
The number of parties who could tamper with the response is reduced from potentially any passive observer who happens to be able to tap into the link anywhere along the whole path - reduced to that one server operator.
the Host header for SNI is still plaintext.
With HTTP/3 and TLS 1.3 with the ESNI option this is no longer the case.
And roughly 50% of HTTP traffic on the internet is HTTP/3 now which uses QUIC over U
Re: (Score:2)
In short: That particular issue will become less and less over time. Especially once websites and web browsers start turning off support for HTTP/1.1 and older TLS versions without the encrypted SNI.
There is no such thing as encrypted SNI. There is only ECH which is a farse practically only available to huge providers.
Re: (Score:2)
There is no such thing as encrypted SNI.
Sure there absolutely is such a thing as SNI encryption [ietf.org]
Re: (Score:2)
Sure there absolutely is such a thing as SNI encryption
You are citing an experimental draft that expired April 25, 2019 nobody has bothered to so much as renew for 6 years. When you find proof of life for ESNI please do mention it here.
Re: (Score:2)
nobody has bothered to so much as renew for 6 years.
Apparently you are a bit clueless. Because you see there is an IESG action already on draft-ietf-tls-esni which approves it to proposed standard, effective July 9, 2025. In other words the standards process has already finalized on the TLS-ESNI draft (TLS1.3 Encrypted Helo) and it is simply waiting in the RFC editor's queue [rfc-editor.org] for final publication.
Not that it has to have the status before the feature is available.
Re: (Score:2)
Apparently you are a bit clueless. Because you see there is an IESG action already on draft-ietf-tls-esni which approves it to proposed standard, effective July 9, 2025. In other words the standards process has already finalized on the TLS-ESNI draft (TLS1.3 Encrypted Helo) and it is simply waiting in the RFC editor's queue for final publication.
The draft in the editor queue is entitled "TLS Encrypted Client Hello" this is ECH which I already addressed and is a radically thing than ESNI.
ESNI was deployable by everyone, ECH is for large providers.
Re: (Score:2)
It is the same draft. Revision 25. Encrypted Client Hello and Encrypted SNI is one and the same and this is and was always deployable by everyone; this is not "for large providers" - it is for All providers. They simply had to revise the spec to protect more than the SNI.
See https://datatracker.ietf.org/d... [ietf.org]
Re: (Score:2)
It is the same draft. Revision 25. Encrypted Client Hello and Encrypted SNI is one and the same and this is and was always deployable by everyone; this is not "for large providers" - it is for All providers. They simply had to revise the spec to protect more than the SNI.
I have one web server, one domain and there is one URL to access my website. How would I deploy this technology? If a useful answer can't be provided to this question then the technology clearly isn't deployable by everyone.
This scheme works for those in a position to be able to hide multiple identities behind a single platform like hosting providers and cloudflares of the world. It does nothing useful for a single self-hosted site.
Re: (Score:2)
I have one web server, one domain and there is one URL to access my website. How would I deploy this technology?
Start by deploying a reverse proxy or load balancer between your website and the internet shared with at least a dozen unrelated website/domain names per HTTPS endpoint IP address. Otherwise; you do not even need to have SNI support on the server, and having clients encrypt it is nonsenical for your scenario -- you could deploy this: but it does not provide any privacy.
Your scenario is not
Re: Easy wrong Answer (Score:2)
it just move the power to inspect your traffic from your local ISP to google/cloudflare. (if you're fool enough to use 1.1.1.1)
Re: (Score:2)
it also ensures black-box IoT devices can't have their ad-queries blocked by pesky customer's pi-hole DNS devices.
You can always serve DNS server IP addresses to your LAN for DNS servers that support only legacy Port 53 DNS over TCP/UDP. Then firewall off "public DNS server IP addresses" as an extra precaution.
In short the only way your Pi-Hole can't be made to block the DNS queries is the case where a blackbox overrides your network configurations and tunnels its DNS traffic through the vendor's s
Re: (Score:2)
Re: (Score:3)
I almost always enable DNSSEC on my DCs
Windows' DNS server program supports DNSSEC.
The problem is the Windows OS such as Windows 10 or Windows 11 itself does not come with a full DNSSEC-validating recursive resolver. It only comes with a dumb stub resolver which requires other DNS servers to function.
If Windows 11 came with a built-in recursive resolver It would implement DNSSEC AND it would be able to resolve domain names with no need to configure any kind of DNS server -- In fact, no local
Re: (Score:2)
If you have a trusted authority locally why can't you rely on that one? I.e. Administrator runs the DNS server for their company, company equipment trusts that server implicitly on the internal network which is somewhat under control, and that DNS server checks DNSSEC for all external queries? We don't need to have a verification chain from end to end, just on either side of an untrusted network, i.e. the external internet. See also: adding custom root certificates allowing admins to MITM https connections.
Re: (Score:2)
since a recursive DNS resolver component has to start straight at the official source of truth (The internet's root nameservers).
A recursive resolver isn't necessary on the client; you can use a stub resolver to fetch records via an upstream recursive server and then validate them locally. Supporting a domain outside of the normal DNS hierarchy would require pinning a key as a signing root, but that's doable in the same way that adding custom CAs to TLS clients is.
Re: (Score:2)
One of the major ways malware would be spread was by malicious actors reconfiguring users' insecure routers to use malicious DNS servers.
Emphasis mine, and to say nothing of using questionable networks / "free wifi", seems like the problem wasn't DNS to begin with. So DNSSEC wasn't going to fix anything on that front.
because Microsoft does not ship Windows with a built-in DNSSEC-validating recursive DNS resolver
conflict with the idea of having "fake" internal domain names which Active Directory is dependent on
So a product is supposed to break with a widespread standardized practice all because some luser can't be bothered to secure their own device that they put their entire lives on and the authoritarian "solution" to said luser's laziness is incompatible without massive recurring financial expenditures imposed on others (annual D
Re: (Score:2)
seems like the problem wasn't DNS to begin with. So DNSSEC wasn't going to fix anything on that front.
Oh. DNS and the lack of security thereof: that is the fact that the client would trust whatever some random DNS server claims to be true is a huge part of the problem.
So a product is supposed to break with a widespread standardized practice all because some luser can't be bothered to secure their own device
The product is supposed to be break a non-Standardized practice. Snagging a domain you have not reg
Re: (Score:2)
Most people are not worried about their DNS traffic being examined.
That is not why DNSSEC exists. The reason DNSSEC exists is so that DNS queries cannot be altered so when when you ask for the IP address for [yourbank.com], a malicious attacker has not populated queries with IP addresses of [fakebanksite.com]
And the problems with DNS traffic being altered or redirected has yet to be a widespread enough problem for the masses to care about.
So we should wait until a fundamental part of how the Internet works is exploited for people to do something about it? DNS cache poisoning [1kosmos.com] was found to be exploitable in 2008. DNS was patched to plug the exploit. It was not actually fixed.
Re: (Score:3)
DNS cache poisoning was around long before 2008. The non random source port reported in 2008 has exploit code available many years earlier, for instance this web archive shows it was available as early as 2001:
https://web.archive.org/web/20... [archive.org]
This version takes advantage of the non random source port, and brute forces the query id.
There were also other bugs in earlier versions of bind - such as non random query ids, and caching of additional records outside of the current domain etc.
After the publicity in 2
Re: (Score:2)
DNSSec is a solution to a problem that virtually no one has. So, why should they care?
Agreed. If you need to rely on DNS being secure, you typically have already failed. The security of modern IT infrastructure is overall abysmally bad enough for DNS to be a tiny piece of the puzzle.
I wouldn't call it failed (Score:5, Interesting)
To be honest, I didn't think adoption was as high as 34%. To me, that's a success, around the same order of magnitude as IPv6 adoption.
I enabled DNSSEC on my domains a while back. And I host my own DNS; I don't use Google or Cloudflare or whatever. The setup process was mildly annoying, but there were plenty of online resources, and I only had to do it once. Modern versions of BIND make it much easier than the ancient version I started with.
Re: (Score:2)
So long as the DNS server has enough memory, I don't see any reason not to enable DNSSEC.
Re: (Score:2)
I don't use IoT devices for that very reason. Since DoH simply uses HTTPS, it's hard to effectively block DoH without blocking HTTPS too (though I guess you could block based on the destination IP address.)
I understand the need for DoH and the desire not to have your ISP monkey with your DNS traffic, but sometimes it's the client devices that are not completely trustworthy and it's I who wants to monkey with the DNS traffic.
Re: (Score:2)
To be honest, I didn't think adoption was as high as 34%. To me, that's a success, around the same order of magnitude as IPv6 adoption.
Global IPv6 adoption is at 50% already. The "same order of magnitude" includes most possible ranges 10%-99% which is a big difference ;-)
Re: (Score:2)
Haha, OK... then: "Within a factor of 1.4"
Re: (Score:2)
The problem with partial adoption this low is it makes DNSSEC almost useless as a signal. You can't, for example, just drop or block emails based on a DNSSEC failure because there are simply too many domains for which it is not rolled out.
Re: (Score:2)
There's a big difference between lack of DNSSEC and an actual DNSSEC failure. The former is not a spam indicator; the latter is a red flag and most resolvers can (and should) be configured to refuse to resolve a domain with a DNSSEC failure.
Re: (Score:2)
You use BIND? Well. That is maybe not the best idea.
Re: (Score:3)
Having my DNS queries encrypted is very low value. It just seems like one more tactic by large companies to squeeze out small companies, much like DKIM. It's got marginal value and "solves" a problem that spam filtering already took care of decades ago only to make it harder for small server operators so they'll hopefully throw up their hands and give the business to Google or M$, instead. That's what they want, not "security".
And what method do you propose that your DNS queries have not been tampered with? DNS runs quietly in background every time you use a web address. If someone were to redirect DNS queries of [yourbank.com] to their [fakebanksite.com] and got your banking credentials, I would guess you would not think that was of "marginal value".
Re: Because not everything needs fucking encryptio (Score:1)
The unfortunate part though is that your browser is now trying to "help" you by automatically routing your DNS queries over whatever other network, which I'm going to assume means that *they* will be creaming off your delicious data.
Bottom line is you can't trust anyone or anything
Re: (Score:2)
Run an encrypted proxy locally. You may not "win", but you may lose less.
Re: (Score:2)
What modern email server/service doesn't have builtin support for DKIM? What DNS server/service doesn't support DNSSEC?
Re: (Score:2)
DNSSEC doesn't encrypt queries or responses. It just proves that responses haven't been tampered with (to the extent that a valid digital signature "proves" anything.)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
DNSSec does not do encryption. It adds signatures. Other than that, I tend to agree with you here.
DANE (Score:2)
A subset of people are really against DANE which lets you self-attest your TLS cert without a parallel PKI. DNSSEC was the PKI in that model.
There are pros and cons but a big con was people not paying for certs.
Now with LetsEncrypt we have DV certs almost everywhere, few people pay for certs, and two PKI's with little protection for anything else that uses DNS.
Oh, and LetsEncrypt would be marginally better off with DNSSEC. Their new observation standard at least helps mitigate BGP shenanigans.
Re: (Score:2)
Now with LetsEncrypt we have DV certs almost everywhere, few people pay for certs, and two PKI's with little protection for anything else that uses DNS.
Oh, and LetsEncrypt would be marginally better off with DNSSEC. Their new observation standard at least helps mitigate BGP shenanigans.
It boggles my mind how anyone in a position to intercept a sites traffic can now obtain a valid parallel certificate easily and for free in a manner enabling silent total ownage of all of the sites users without needing to compromise any of the sites systems.
Yet it seems everyone is just like yea this all sounds totally fine and reasonable to us. Fucking insanity.
It's a North American thing... (Score:2)
Do you really want to talk about DNSSEC penetration and turn a blind eye to IPv6 adoption? We've been working on IPv6 since 1996 as well and ... well ... here we are, last country on the planet to take it seriously, because carrier-grade NAT, NAT, and similar crutches get us through. How many people here have asked their residential internet provider if they support IPv6? I have, many times, and each one looks at me like I'm an idiot. They don't WANT to. You can't MAKE THEM. "You're not the boss of me
Clock should start after 2016 (Score:2)
DNSSEC was impossible to responsibly deploy until 2016 with introduction of RFC 7873. It then took a few years for the fix to diffuse through the worlds systems.
Besides our practical choices are limited to sticking with the increasingly insane DV CA industry or adopting DANE.
Actually actually (Score:3)
DNSSec is a smashing success because a ton of providers and unscrupulous governments do everything in their power to prevent customers from using it.
Russia, Iran, China, etc. all happily force use to use ISP's DNS servers that provide you with IP addresses that are approved by your government.
Oh wait, some EU countries and even US states have joined the ranks of those meddling with your DNS queries.
What US states meddle w/ DNS? Re:Actually actually (Score:1)
Oh wait, some ... US states have joined the ranks of those meddling with your DNS queries.
Which ones?
DJB, comment? (Score:2)
DJB, of DJBDNS fame, do you have a comment? We know you always wear black.