Just because you've securely looked up an IP address, do your packets really arrive there?

That's why DNSSEC without DANE seems pointless (and with DANE/TLS seems redundant).

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?

Also, at the moment you do not get much by checking their broken DNSSEC entries:

http://dnsviz.net/d/pool.ntp.org/dnssec/

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 can't tell if you're saying TLS is pointless with DANE, or DNSSEC is pointless with some combination of DANE+TLS.

DANE isn't severable from DNSSEC; it relies on the DNSSEC PKI to function. Unfortunately, that PKI is absolutely the worst part of DNSSEC.