NTP Pool Servers

NTP, the Network Time Protocol, is a very useful and easy way of keeping the clock of many systems synchronized. ISC, the Internet Systems Consortium maintains a list of NTP servers that form a public pool of servers that you can use for your own systems too.

More information about the “NTP pool servers” can be found at:


The sample ntp.conf file of that page is not 100% right for use with FreeBSD though, since our rc.d scripts specify the location of the driftfile in /etc/defaults/rc.conf:

# grep drift /etc/defaults/rc.conf
ntpd_flags="-p /var/run/ntpd.pid -f /var/db/ntpd.drift"

The rest of the sample ntp.conf file is ok though, so you can start with:

# cat /etc/ntp.conf
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server pool.ntp.org

Then, enable the ntpd service in your /etc/rc.conf file:


Before you fire up ntpd for the first time, it’s a good idea to manually synchronize the system clock at least once, so that ntpd will not start with a huge time-difference to recover from (which may inhibit ntpd from starting at all, in some cases). The ntpdate utility can do that, but please make sure you understand all the ramifications of running it with the -b and -v options (which will step the system clock instead of gradually slewing it):

# ntpdate -v -b pool.ntp.org

You should see something like:

# ntpdate -v -b pool.ntp.org
17 Apr 08:07:50 ntpdate[85166]: ntpdate 4.2.0-a Tue Apr 11 03:40:32 EEST 2006 (1)
17 Apr 08:07:54 ntpdate[85166]: step time server offset 0.211012 sec

Now, you can safely start the ntpd daemon, to keep the clock sychronized at all times:

# /etc/rc.d/ntpd start
Starting ntpd.

All set. Now you can use ntpq to query & monitor your NTP synchronization daemon :-)

After you let ntpd run for a while, you can query its status with ntpq (NTP “query” utility) and see how well your new ntp.conf setup works:

# ntpq
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
+allanon.amazing      2 u   58   64  377  102.379  242.506 113.880
+server1.medigli    2 u   55   64  377  135.605  225.324 106.716
+topaz.conuropsi        3 u   62   64  377   81.529  220.863 163.234
*ns2.national-ne  2 u   65   64  372  195.683   76.388 179.670

NOTE: The delay, offset, and jitter, column are displayed in milliseconds, so values like 76.388 above are quite fine for most desktop users. The meaning of the first column characters ('+' and '*' above are explained in the ntpq manpage:

  • ‘+’ = (candidate) The peer is a survivor and a candidate for the combining algorithm.
  • ‘*’ = (peer) The peer has been declared the system peer and lends its variables to the system variables.

If all this sounds strange, you can always find more information about the way ntpd and ntpq work in their manual pages:

$ man ntpd
$ man ntpq

6 thoughts on “NTP Pool Servers

  1. atma


    This guide is UNIX Generic from what I can say. It applies equally on *BSD and GNU/Linux flavours. Lately I’m messing with iptables and due to hardened policy I had to write a rule in order to accept the remote ntpd packets. The NTP protocol uses the udp protocol and apparently it runs by default on port 123:

    host ~ # uname
    host ~ # grep ntp /etc/services
    nntp 119/tcp readnews untp # Network News Transfer Protocol
    nntp 119/udp readnews untp
    ntp 123/tcp # Network Time Protocol
    ntp 123/udp
    nntps 563/tcp snntp # NNTP over SSL
    nntps 563/udp snntp
    trnsprntproxy 3346/tcp # Transparent Proxy
    trnsprntproxy 3346/udp

    At this stage of paranoia, maybe using the SSLv3/TLSv1 makes more sense..
    Anyway, what I wanted to say in first place, after finding out the pool server we can add this string in our iptables rules to allow the connection:

    iptables -A INPUT -p udp –sport 123 –dport 123 -s -d -j ACCEPT

    In my case works. I have a static ip connection and I struggled a bit in order to write this line :-P that’s why I wanted to share it!!!

  2. atma

    It seems that I made a mess above, i enclosed the ip’s in two < > fscking html :(

    ps. please give people a preview plugin!

  3. keramida Post author

    I usually run my firewalls in “semi-paranoid” mode:

    – allow all outgoing connections (keeping state)
    – selectively pass *some* incoming connections through
    – block all incoming connections

    This way, I don’t need a special rule for allowing port udp/123 traffic to go through, as it’s always the NTP client that initiates the connection and the stateful rule lets the replies through. In OpenBSD pf(4) syntax, this looks something like this:

    # The default firewall policy is to block everything.
    block in log all
    block out log all

    # Allow all ICMP packets.
    # They are mostly useful and rate-limited by the kernel anyway.
    pass in proto icmp all
    pass out proto icmp all

    # Allow all outgoing connections.
    pass out proto { tcp, udp } all keep state (no-sync)

    # Allow some incoming connections.
    pass in proto tcp from any to any port = 22 keep state (no-sync)
    pass in proto tcp from any to any port = 113 keep state (no-sync)

    Thanks for the cool iptables rule though :)

  4. atma

    To make it clear for others here is the iptables string again:

    iptables -A INPUT -p udp –sport 123 –dport 123 -s source-ip -d destination-ip -j ACCEPT

    I’d like to play with OpenBSD’s packet filter in the future, but I have no BSD machine right now and I don’t have any (physical) space here. The situation will (hopefully) change soon :-)
    Until then I’m stuck with iptables. I’d like to read something about pf vs iptables. Not a flame just a good comparison paper.

  5. douglas calvert

    Opening up a hole for “the pool server” makes no sense. Its just a round robin dns pool of servers…

    $ host 2.us.pool.ntp.org
    2.us.pool.ntp.org has address
    2.us.pool.ntp.org has address
    2.us.pool.ntp.org has address

    You want to do time synchronization over TLS/SSL? There is a reason why UDP is used and not TCP. Moreover NTPv4 has support for authentication but the spec is based on the assumption that you dont need to keep the contents of the time packets secret…

Comments are closed.