Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote on 10/30/2012
15:09:31:
>
> On Tue, 30 Oct 2012, John.Florian@xxxxxxxx wrote:
>
> > What strategy does chronyd use to resolve the hostnames to IP
addresses
> > for its upstream time servers? I'm guessing it does so
once at startup
> > and then caches the result for all future use. Is that
correct?
> >
> > I had a number of systems I had to twiddle with today because
chronyd
> > didn't seem to follow an IP address change we made in DNS. I
had
> > specifically used a name via DNS to cope with such a situation
so was
> > surprised by this behavior. To me it's the first reason
to use names ...
> > an abstraction layer allowing redirections.
>
> The alternative is to have chrony do a dns lookup everytime it wants
to send
> out a packet. That makes a much larger load on the host system to
running
> chrony. "Send out one ntp packet and receive one ntp packet"
vs " Send out a
> dns query (which typically first goes to /etc/hosts, and then out
the net to
> the dns server, get the answer and interpret the answer, then send
out and
> receive the dns packet. At the same time, try to make sure that if
the ip
> address changes of a server, that the records for that server remain
attached
> to each other even if the dns address changes.
Umm... that's exactly the job of the
resolver. It should cache all such lookups until such time that the
DNS time-to-live has expired. In other words, chronyd should *always*
ask the resolver, but the resolver only sends the DNS query if it has no
record or if the TTL of the record it does have has expired.
> Remember that chrony keeps the
> up to the past 64 queries to a server, and must make sure that all
queries to
> the same server remain associated with the same server. Far easier
to use IP
> to make that association. Chrony also keeps info for a server across
various
> runnings of chrony if I recall correctly.
This makes a better argument. Maybe
chronyd should note the IP that provided the history and if it changes,
invalidate the history and effectively restart.
--
John Florian