Bill Unruh <un...@physics.ubc.ca> wrote on 10/30/2012 15:09:31: > > On Tue, 30 Oct 2012, john.flor...@dart.biz 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
