-- when DNSSEC validation fails, the domain is unreachable: www.dnssec-failed.org. The browser doesn't have to warn the user, the resolver will fail to return the DNS answer altogether.
-- when DNSSEC validation fails, the domain is unreachable: www.dnssec-failed.org. The browser doesn't have to warn the user, the resolver will fail to return the DNS answer altogether.
From a user's perspective, DNSSEC is merely the potential to be more secure; until they personally verify it is working for them, they have no idea if they are actually more secure or not. And you have to do this per device, per OS.
I just pulled up http://www.dnssec-failed.org/ on both my laptop and my Android phone, it loaded just fine. So DNSSEC failed to prevent either of these devices from loading an invalid domain. But I had no notification that DNSSEC failed; the page just worked!
If the browser actually informed me that DNSSEC isn't being enforced at all, I would at least know i'm not as secure as I could be.
Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not.
Assuming both the client and network were correct, you still have no idea if it worked or not! If you are a really smart user who thinks a site should be using DNSSEC and you try to go to that site, and your dns resolver supports DNSSEC properly, all you get back from trying a bad site is the domain wasn't resolved.
Is DNSSEC broken? Was the domain name wrong? Do I not have an IP on the network? Did something else happen? Who the fuck knows? Not the user, who gets back a generic error message if DNSSEC is working, and gets no error message if DNSSEC is not working.
So it only works reliably when it's broken. What a fantastic security system.
None of that happens with HTTPS, of course. With HTTPS the only thing that determines the security of the connection is whether the client validates its certs (and all browsers do). If it fails, you get an error and a big scary warning page.
Good point! I didn't know that. Perhaps that's what you're running into, since Android 5.0 seems to be working fine for me? For a long time we all just used whatever DNS server we got from DHCP, but I think the time for that has passed. At this point we should choose our own recursive DNS provider, and reconsider using networks that don't allow that.
Assuming you control your device (non-corporate non-government users) and know how to configure your DNS server (elite users only) and wanted to do this extra step (privacy-conscious people?), this will break for hotels, airports, cafes/restaurants, corporate/government networks, anyone with an ISP that intercepts public DNS requests, and various home routers. Not to mention making surfing the web much slower and less reliable, since we distribute name servers specifically to rely on caching to lower latency and increase availability in case of various network failures.
But otherwise, sure, that works.
If this isn't the case, then I know that the device operates not in my interest, but in that of whoever controls it. So, I probably won't be entering any sensitive information into it.