4 ms·
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
by phicoh 10y ago
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.
- lmns 10y ago> 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?
- okket 10y agoAlso, at the moment you do not get much by checking their broken DNSSEC entries: http://dnsviz.net/d/pool.ntp.org/dnssec/ http://dnsviz.net/d/pool.ntp.org/dnssec/
- phicoh 10y agoIf 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.