On Oct 9, 2013, at 1:59 PM, Joe Abley <jab...@hopcount.ca> wrote: > DNSSEC validation imposes a requirement for clock sync (to the accuracy > reasonably required to consider signature inception and expiry times). There > is a possible future in which such validation takes place on end hosts, > rather than intermediate resolvers. (We may wind up somewhere else, but there > are certainly people who think that is the Right Way).
Sure. Including me. > In that sense any device that needs to look up names in the DNS has a > potential requirement for time sync. Yes, definitely. > Of course even the wall clock you imagine might have a vendor who is capable > of running their own array of time servers as (e.g.) Apple does, but it seems > reasonable to imagine that there will be people who are not in that position, > and since I agree with you when you say: > >> Of course, if a CPE vendor were to hard-code the FQDN of an NTP server >> belonging to someone else into their devices, that would be disastrous. > > it seems to me that there's a plausible use case for a DHCP client to receive > direction on what servers to chime against. Yup. There's an equally plausible use case for distributing DNSSEC root keys using DHCP, so that the DHCP client has a current copy of the keys. This totally solves the key rollover problem! :) Of course, the situations are not precisely analogous, but the point is that just because DHCP could be conveniently used to suit some purpose, does not mean that it _should_ be used to suit that purpose. I think reasonable people can differ about configuring NTP over DHCP, but it really does depend on how you are using NTP. I think the main justification for using DHCP to configure NTP is in fact that it is expedient, even though it's not secure.
