DNS security is important but DNSSEC may be a failed experiment Last week I turned on DNSSEC (Domain Name System Security Extensions) for the systemsapproach.org domain. No need to applaud; I was just trying to get an understanding of what the barriers to adoption might be while teaching myself about the technology. It turns out that, if you have your domain hosted by a big provider (we …
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
> 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.
"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.
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.
"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".
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.
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".
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]
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.
You might well think that. But you'd be wrong. Resolvers get a SERVFAIL error when DNSSEC validation fails. They don't even get an error code to say it was a validation failure. A resolver would need to go through all the other possibilities for a SERVFAIL response before telling the end user/application a signature or key was wrong (how?) and hoping they could make sense of that before deciding what to do about that. Good luck.
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.
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.
> most sites don't need HTTPS, most sites are just static crap with nothing to protect...
Many sites which don't need to add privacy since, as you say it's just static crap or some such, use HTTPS because it stops unscrupulous ISPs stealing their revenue stream by replacing the adverts of common webpages with other adverts which the ISP is being paid for.
Every site does have something to protect, and that's the information it itself serves.
A miscreant can easily change the content on a site that uses HTTP.
The worst for a user is probably that downloading a PDF serves malware from elsewhere instead of the PDF from the site.
The most common is probably inserting and replacing adverts. Even supposedly reputable ISPs have done that.
"I don't understand why it's not turned on by default."
That's because you'd be relying on everyone who DNSSEC-signs their zones to never fuck up. Good luck with that.
Suppose CNN/Amazon/Apple/Microsoft/Netflix.com were signed. [They aren't but let that pass.] If their signing procedures broke, your DNSSEC validations would fail and these somewhat popular websites would be unreachable to your customers. An angry mob with pitchforks and flaming torches would storm your building(s). Meanwhile, these websites would still be reachable just fine for your competitor's customers who have DNSSEC validation turned off.
"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."
More likely, it's because nothing important's ever been signed and DNSSEC validation failures have only affected stuff nobody cares about. Signing the DNS and some TLDs is all very well but it hasn't made the slightest difference to the adoption of DNSSEC by any significant content providers. The last time I looked only 2 or 3 of the world's busiest 1000 web sites had names that were DNSSEC-signed.
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.
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.
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 soonTM), 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....
Might work, but they could be hard to remember (especially when we transition to IPv6 soonTM)
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!
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.
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.
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.
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.
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.
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.
Part of the reason for the lack of uptake is the lack of support in browsers.
Catch 22.
Why enable it in your site when no browser will warn the user of a problem ?
Why add it to the browser when so few sites use it ?
For the full protection the user must also be using a DNS that is configured with DNSSec. It isn't just a consideration for the site hosts.
