Resolving Hostnames - NTP

This is a discussion on Resolving Hostnames - NTP ; Hi, 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 will resolve the hostnames using DNS but it appears to lock onto ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Resolving Hostnames

  1. Resolving Hostnames

    Hi,
    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
    will resolve the hostnames using DNS but it appears to lock onto the
    IP it selects and never re-checks DNS to see if the hostname resolves
    to a different IP.

    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
    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.

    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
    least at first) will be geographically located in the same data
    center.

    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
    question about ntpd resolving the hostname.

    thanks

  2. Re: Resolving Hostnames

    throindarts@yahoo.com wrote:
    > Hi,
    > 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
    > will resolve the hostnames using DNS but it appears to lock onto the
    > IP it selects and never re-checks DNS to see if the hostname resolves
    > to a different IP.
    >


    Please see http://support.ntp.org/bin/view/Dev/DNSServerFailover which
    details a project to deal with this issue. Currently this is only in
    design and is waiting on a couple of other things to get completed but I
    expect to implement this in the next 6 months.

    > 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
    > 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.
    >
    > 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
    > least at first) will be geographically located in the same data
    > center.
    >


    Have you looked at the new pool configuration option? It will use up to
    10 entries in the DNS.

    > 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
    > question about ntpd resolving the hostname.
    >


    If you are using pool.ntp.org then you should get different servers
    listed on as relatively frequent basis.

    If you are using your own servers as long as you configure enough
    servers for the FQDN it will return a different order each time.

    Danny

  3. Re: Resolving Hostnames

    In article <0549e068-1187-4b42-adcc-21d09bc68a4e@b1g2000pra.googlegroups.com>,
    throindarts@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.

  4. Re: Resolving Hostnames

    On Dec 18, 4:09 pm, da...@ex.djwhome.demon.co.uk.invalid (David
    Woolley) wrote:
    > In article <0549e068-1187-4b42-adcc-21d09bc68...@b1g2000pra.googlegroups.com>,
    >
    > throinda...@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.

  5. Re: Resolving Hostnames

    throindarts@yahoo.com wrote:
    > On Dec 18, 4:09 pm, da...@ex.djwhome.demon.co.uk.invalid (David
    > Woolley) wrote:
    >> In article <0549e068-1187-4b42-adcc-21d09bc68...@b1g2000pra.googlegroups.com>,
    >>
    >> throinda...@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).
    >


    Did you read http://support.ntp.org/bin/view/Dev/DNSServerFailover that
    I pointed you to? When complete it WILL query the DNS again after a
    period of failure.

    > So I should be load-balanced and redundant.


    No, load-balancing has no meaning in an NTP network. You can provide
    multiple addresses to the DNS label and then use the pool configuration
    option but it won't fail-over to a different address until I've done the
    DNS work.

    Danny

  6. Re: Resolving Hostnames

    On 2007-12-19, throindarts@yahoo.com wrote:

    > 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).


    ntpd automatically manages the selection of the sys.peer. All you have
    to do is provide ntpd with enough time sources.

    *** In general...

    If ntpd is using 1 remote time server it has not choice but to accept
    that server as "correct".

    If ntpd is using 2 remote time servers it now way of determining server
    is correct (unless special steps are taken).

    If ntpd is using 3 remote time servers it can determine if one of these
    servers is "wrong". However, if one of those servers is no longer
    reachable then ntpd ends up in the situation of having only 2 remote
    time servers.

    If ntpd is using more than 3 remote time servers additional levels of
    fault tolerance are gained.

    *** If you are providing your own time servers and are willing to properly
    monitor and maintain them you may be able to get away with using fewer
    than the generally accepted number of time sources.

    In the case of having only 2 time servers on a LAN, the safest
    configuration is to have each time server polling 4, or more, unique
    time sources (i.e. a combination of off-site remote time servers and/or
    on-site ref-clocks). Then designate one of your LAN time servers as the
    master and the other as the slave. Configure the slave to poll and
    prefer the master as follows: 'server master.lan.server iburst prefer'.
    This should cause the slave to always sync to the master (unless the
    master fails) and the stratum difference between the master and the
    slave will cause the clients to use the former.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  7. Re: Resolving Hostnames

    mayer@ntp.isc.org (Danny Mayer) wrote:

    > Did you read http://support.ntp.org/bin/view/Dev/DNSServerFailover that
    > I pointed you to? When complete it WILL query the DNS again after a
    > period of failure.


    An issue here (at my workplace we're rolling out IPv6 on our NTP
    servers): if a server has both IPv4 and IPv6 addresses (DNS A and
    AAAA records for the server name, as for example ntp.isc.org) and
    a client chooses the IPv6 address, will it fall back to the IPv4
    address if it fails to get a response over IPv6? I believe that the
    current behaviour of ntpd is to choose only IPv6 if the client has
    IPv6 configured. Potential problems would be lack of connectivity
    over IPv6 or incorrect "restrict"/firewall config.

    --
    Ronan Flood

  8. Re: Resolving Hostnames

    Ronan Flood wrote:
    > mayer@ntp.isc.org (Danny Mayer) wrote:
    >
    >> Did you read http://support.ntp.org/bin/view/Dev/DNSServerFailover that
    >> I pointed you to? When complete it WILL query the DNS again after a
    >> period of failure.

    >
    > An issue here (at my workplace we're rolling out IPv6 on our NTP
    > servers): if a server has both IPv4 and IPv6 addresses (DNS A and
    > AAAA records for the server name, as for example ntp.isc.org) and
    > a client chooses the IPv6 address, will it fall back to the IPv4
    > address if it fails to get a response over IPv6? I believe that the
    > current behaviour of ntpd is to choose only IPv6 if the client has
    > IPv6 configured. Potential problems would be lack of connectivity
    > over IPv6 or incorrect "restrict"/firewall config.
    >


    Currently no. That's one of the issues that need to get fixed.

    Danny

  9. Re: Resolving Hostnames

    mayer@ntp.isc.org (Danny Mayer) wrote:

    > > If [...] a client chooses the IPv6 address, will it fall back
    > > to the IPv4 address if it fails to get a response over IPv6?

    >
    > Currently no. That's one of the issues that need to get fixed.


    Righto, thanks Danny -- good to know it's on the radar.

    --
    Ronan Flood

  10. Re: Resolving Hostnames

    David Woolley wrote:
    >> 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.
    >


    This cannot work. Physically different servers will have different
    clocks and the association must be set up to work with just that one
    clock or the algorithms in the code will end up rejecting the entire set
    as the jitter and delays will be way off. Not only are the clocks
    different, their frequencies will be different, their refid's will be
    different and the round-trip delays will be different. You cannot do
    anycasting with NTP. This kind of thing works well with DNS but DNS
    doesn't care about what the server is doing, or how long it takes. NTP does.

    >> 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.
    >


    I did get a request recently which suggested picking servers at random
    from the list of addresses returned from DNS. This is probably worth
    doing. It will need code also to disable the behavior.

    Danny

+ Reply to Thread