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.

What 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.

Instead 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....

( 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/b...

Well, 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.

But 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?

> 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.

> 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.

Correct. 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.

It'll just break and you won't have a working DNS.

You also could run your own DNS resolver on your local device and do the DNSSEC validation there.

One example of this bundled up in a way that is easy to install is DNSSEC-Trigger: https://nlnetlabs.nl/projects/dnssec-trigger/

More info in this blog post from Red Hat: http://developerblog.redhat.com/2015/04/14/writing-an-applic...

Only if your ISP doesn't molest DNS packets. More importantly: this only works for a small set of nerds; it doesn't scale to every user on the Internet --- this is the worst kind of "insecurity for thee not me". For refusing to make compromises like this, and instead insisting that sound cryptography be made available to all users, Moxie and Trevor just won the Levchin Prize at RWC.

Notice also that Signal provides a massive amount of cryptographic security to billions of people without needing a PKI controlled at its roots by world governments.

It can be verified by the client [1] (wikipedia link also has RFC source), but typically the verification is done by the resolver, which introduces the problem that a client has to trust the resolver and the network from resolver to the client (last mile problem)

1: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...

Sure, the client application can validate DNSSEC if it is using a DNS library that supports DNSSEC. Examples include:

- getDNS - https://getdnsapi.net/

- ldns - https://nlnetlabs.nl/projects/ldns/

The application simply has to perform the actual validation itself (versus using another resolver).