On Fri Feb 4 2011 Dave Hart wrote in [Pool]:
> Vincent Zweije wrote:
>> Dave Hart wrote:
>>> 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.
>>
>> Wouldn't it be better to re-resolve when the DNS record
>> TTL expires? Provided the resolver library gives access
>> to the TTL, of course.
>
> It doesn't, in our case. ntpd name resolution is built on
> getaddrinfo() which provides an answer but not a time remaining.
> Moreover, it's risky to re-resolve before using all addresses,
> or you might end up stuck using only the first (few) of
> the addresses.
>
> Anyway, this is a detail of an imaginary capability.
> We can hash out a solution once ntpd actually re-resolves
> non-pool hostnames.
Why not just use the pool directive instead of the server directive?
(or have NTP internally do so.)
{Even if / when they only resolve to one IP each.}
Is there any significant down side to doing:
# ntpd 4.2.7
restrict source nomodify
pool ntp.example.com # [192.0.32.10]
pool cronos.example.net # [198.51.100.11]
pool tempus.example.org # [203.0.113.18]
pool time.example.edu # [169.254.132.33]
pool clock.example.test # [192.0.2.123]
pool tick.example.localhost # [127.254.123.60]
pool tock.example.invalid # []
pool 0.zone.pool.ntp.org # [###.###.###.#], [###.##.###.##],
[###.#.###.###]
instead of:
# ntpd 4.2.7
restrict source nomodify
server ntp.example.com # [192.0.32.10]
server cronos.example.net # [198.51.100.11]
server tempus.example.org # [203.0.113.18]
server time.example.edu # [169.254.132.33]
server clock.example.test # [192.0.2.123]
server tick.example.localhost # [127.254.123.60]
server tock.example.invalid # []
pool 0.zone.pool.ntp.org # [###.###.###.#], [###.##.###.##],
[###.#.###.###]
--
E-Mail Sent to this address <[email protected]>
will be added to the BlackLists.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
