Hacker News new | ask | show | jobs
by smashed 801 days ago
> I figured they must be running DNSSEC on that zone (or some part of it), and it must have a "not-before" constraint

Since clients will attempt to resolve ntp.org in order to actually sync their clock, there is a good probability that some clients will be way off.

Enabling dnssec on that zone was probably not without important drawbacks? I wonder if the operators thought about that potential pitfall. Seems like they might be doing a disservice to their core mission of allowing devices to sync their clock.
2 comments
growse 801 days ago
It feels like enabling DNSSEC on any zone is inviting a bunch of fun service risks and unexpected failures.

Is my clock more likely to be accurate after NTP.org got signed? It looks like it's less likely, on average.

link
cbhl 801 days ago
If you _don't_ enable dnssec on ntp.org, then a mitm can intercept the dns request to redirect to an attacker-owned timeserver with a time in the past. Then the host can have old and expired (without loss of generality) keys/certificates replayed against it.

If memory serves though, Raspbian used to not even have `fake-hwclock` by default and even more Pis would end up with this "wildly wrong time near the epoch and can't bootstrap DNS/NTP" failure mode. You'd sometimes also see it with VMs too (esp if they were doing a pure-software clock that ran slower than realtime, instead of patching clock calls to the real hardware clock on the host).

link
Dylan16807 801 days ago
> If you _don't_ enable dnssec on ntp.org, then a mitm can intercept the dns request to redirect to an attacker-owned timeserver with a time in the past. Then the host can have old and expired (without loss of generality) keys/certificates replayed against it.

Preventing DNS mitm only matters if you prevent NTP mitm too.

What percent of NTP clients talking to these servers are doing it in a secure way? And is that share growing?

link