3 ms·

> 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

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

growse 2y 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.
cbhl 2y 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).
- Dylan16807 2y 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?

growse 2y 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.

cbhl 2y 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).

Dylan16807 2y 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?