[ntp:questions] Resolving Hostnames

throindarts at yahoo.com throindarts at yahoo.com
Wed Dec 19 22:58:21 UTC 2007


On Dec 18, 4:09 pm, da... at ex.djwhome.demon.co.uk.invalid (David
Woolley) wrote:
> In article <0549e068-1187-4b42-adcc-21d09bc68... at b1g2000pra.googlegroups.com>,
>
> throinda... at yahoo.com wrote:
> > I would like to know if there is a way to tell ntpd to periodically re-
> > resolve the hostnames provided in ntp.conf. When ntpd starts up it
>
> There is work in progress to provide for re-resolving.  It may even
> be in the latest builds.
>
> > I am considering a load-balancing approach which would use multiple
> > DNS entries (1 for each NTP server in the pool) and a TTL value
>
> Note that gratuitous re-assigning of servers is bad for the operation of
> the NTP protocol, as it forces information about a server to be thrown
> away.
>
> > allowing the load to evenly distribute among the servers in the pool.
> > In this case the client will send NTP requests to the same host but
> > get NTP responses from physically different servers. All servers in
> > the pool peer with one another.
>
> If you can make this sort of change to ntpd, adding re-resolving should
> be child's play.  I really don't see how this could possibly be more
> efficient than simply replying directly.  To make it work, the times on
> the receiving and sending machines will have to be in lock step, not
> just synchronised by NTP, as you will need to time stamp the receipt of
> the packet on the first machine with a clock that is running identical
> to the clock that is used to timestamp the packet when it is transmitted
> back.  You will also need to ensure that the IP address from which the
> response returns is the same as that to which it was sent.
>
> > The way it is working right now, each client may surely get a
> > different server in the pool but I have no way to ensure that each of
> > potentially millions of clients select the server in a way which will
> > balance the load on my servers. Also note that the server pool (at
>
> Pure statistics will get you close.  If you want better, you could
> do tricks like making the DNS hash the source address to chose between
> the servers.  It might be possible to do this in a router as well, as
> long as the router handles this completely within its routing processor and
> doesn't require control processor involvement.
>
> > least at first) will be geographically located in the same data
> > center.
>
> You probably won't need load balancing, as the bottle neck is likely to
> be the connection to the outside world, rather than the timeserver
> processor.
>
> > With the approach I would like to take, the load would balance on a
> > request basis and not on a client basis...that is the reason for my
>
> I don't understand this.  If you are involving DNS, it will balance the
> hosts.  If you balance individual requests, you will violate the assumptions
> that the protocol makes, but you could only do that at the router level.
>
> A proper NTP farm will use the same server for the client until the
> server fails or is retired, or the client is restarted.

thanks for the replies.

So to summarize, I can achieve the load--balancing via the DNS (which
will return the IPs in different order each query) because each of my
clients will query DNS at different times (i.e. they each will startup
NTP at different times). This part is fine except what happens when
the selected server fails? Well this can be solved by providing my
clients with more than 1 server host name in ntp.conf and letting the
client use one as sys.peer and the other(s) as candidate. So then if
sys.peer fails then the candidate becomes sys.peer (at least this is
my understanding of NTP).

So I should be load-balanced and redundant.




More information about the questions mailing list