On Thu, Feb 3, 2011 at 3:51 PM, David J Taylor <[email protected]> wrote: > I thought that recent NTP versions revisited the DNS lookup once in a while?
Yes, but not for "server" lines in ntp.conf. 4.2.7 (ntp-dev) introduced a revamped "pool" directive implemented very similarly to manycastclient, substituting DNS lookups for manycastclient's multicast server solicitation. If you're using pool in ntp.conf and you're using 4.2.7, pool servers which become unreachable are demobilized and replaced as needed, using leftover addresses from the last pool DNS lookup or initiating another if needed. >From the time I did that work, I wanted to do the same for all association directives that accept hostnames, like server and peer. The challenge is how to minimize operator astonishment with the change. Even in the latest 4.2.7 snapshots, non-pool hostnames are resolved once at startup to a single IP address, and that IP address is the unique identifier of the association. In my view, it would be good for ntpd to keep track of the hostname originally used to configure the association and (at least by default) use leftover alternate addresses or re-resolve the name after the association becomes unreachable. That would involve rejecting duplicate associations with the same hostname in addition to the current duplicate remote address rejection. It would also mean less predictable behavior, as ntpd would begin using more than the first address returned by DNS for unicast associations by name. Setups involving "restrict" by numeric address which work today could develop problems not previously seen. Name-based restrictions in recent ntpd are applied to all addresses returned (in 4.2.6 as well, I believe, but not 4.2.4). I doubt this will be tackled before the next ntp-stable, whether it's called 4.2.8 or 4.3.0. Cheers, Dave Hart _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
