The question for many residential internet users is: Just because I set my DNS to Google's, do my request really arrive there? Or does my ISP use transparent DNS proxies?
I know that for many ISPs around here (Telekom especially), setting your DNS doesn't have any effect unless you run a local resolver (or DNScrypt).
It's a different threat model. Classical DNS (i.e. without port randomization and a whole host of other tricks) is very easy to spoof from all over the internet.
Inserting yourself between a client and a server is way more difficult.
Note that from the point of traffic analysis, you still don't want your TLS traffic to go through a third party.
So if your thread model mostly includes nation-state attackers then DNSSEC is only useful for DANE. If you also want to secure a lookup of, for example, pool.ntp.org then DNSSEC for A and AAAA records also makes sense.
> If you also want to secure a lookup of, for example, pool.ntp.org then DNSSEC for A and AAAA records also makes sense.
The fun part begins when you realize you can't validate DNSSEC because your time drifts too much. So how do you get your initial sync from pool.ntp.org with DNSSEC validation enabled?
If the DNSSEC validating resolver is a server then it is usually not an issue. Most server hardware has battery backed real time clocks. In the odd case that you are bootstrapping a server you would have to set the time manually or make setting the time part of bootstrap process.
For embedded systems that don't have a battery backed real time clock and want to do local DNSSEC validation this is indeed an issue.
There are plenty of hacks to make it work, but no real standard.
I know that for many ISPs around here (Telekom especially), setting your DNS doesn't have any effect unless you run a local resolver (or DNScrypt).
More info and how to test if you are affected by this: https://hackernews.hn/item?id=13037858