2 ms·
Congratulations, you've understood the main hole of dnssec. The thing is: you can verify dnssec on the client. In theory. It's just that 99,9% (rough estimate,
by hannob 10y ago
Congratulations, you've understood the main hole of dnssec.
The thing is: you can verify dnssec on the client. In theory. It's just that 99,9% (rough estimate, may be higher) of people don't.
You'd have to run your own resolver. Which might work, if your ISP isn't doing funny things with your DNS traffic. Which some ISPs do. Which means it can't be deployed widely.
This thing was built in the 90s when people assumed you have some dns that some admin you trust manages in some trusted network. Moving it to today's internet is pretty much impossible.
- ribasushi 10y ago( serious question - I might not know something ) If I run my own resolver, with a hardcoded [1] trust anchor, how could an ISP affect me regardless of what funny things it does with my DNS traffic...? [1] https://sources.debian.net/src/bind9/1:9.10.3.dfsg.P4-10.1/bind.keys/#L35-L45 https://sources.debian.net/src/bind9/1:9.10.3.dfsg.P4-10.1/b...
- lmns 10y agoIt'll just break and you won't have a working DNS.
- hannob 10y agoWell, the traffic is not encrypted or otherwise protected, so a firewall trying to be "smart" could do all kinds of things. E.g. not letting you connect to other DNS servers at all or filtering all queries with unusual record types.
- ribasushi 10y agoBut the point of DNSSEC isn't to protect your ability to contact another server, just like the point of SSL isn't to be a substitute for TOR. Are we on the same page that with DNSSEC activated on a local resolver one would either get an authentic answer, or nothing at all?
- hannob 10y ago> Are we on the same page that with DNSSEC activated on a local resolver one would either get an authentic answer, or nothing at all? Sure. But it's not very relevant, because almost nobody does that. And that's unlikely to change, because getting nothing at all isn't a very desirable state of affairs. And given that forcing local DNSSEC resolvers in an OS or a browser would likely mean that a large share of your userbase will get nothing at all this is pretty much impractial.
- ribasushi 10y ago> And that's unlikely to change, because getting nothing at all isn't a very desirable state of affairs. It worked for HTTPS - more and more browser builds refuse to show you stuff, with no workaround, even if there is nothing wrong with the certificates ( cough-sha1-cough-or-cough-chrome-cert-transparency-cough ). Yet I don't see any users revolt. Claiming that having an all-or-nothing HTTPS is a-ok, yet having all-or-nothing DNS is unacceptable is... inconsistent.
- danyork 10y agoCorrect. And if the local resolver is sufficiently close to your client that there is very low risk of an attacker getting into your local network, then you can have a higher degree of trust in those validated answers from your resolver.
- tbrownaw 10y agoWhat do you mean, "run your own resolver"? That's a fancy name for the library that the application uses to speak DNS, not a separate thing that has to be set up, run, etc, separately.
- feld 10y agoInstead of asking "what IP is Google.com?" to your configured DNS server, you traverse the whole chain. First, you refer to your list of root zones: which servers can answer about .com? Ok, ask them which DNS servers google.com should have. Next, send the request directly to those servers. Now you get a response that you can use. This chain can get really long depending on the service's DNS configuration. And this whole time every request has to come back DNSSEC signed. Note that I'm ignoring any caching....
- deleted 10y ago[deleted]