Every systems administrator should know at least three basic NTP configurations. These are: the Client, the Internal Server, and the Public Server. They're really quite simple, yet I see parts missing from default configurations all the time. You should not rely on your OS distribution to have customized their OS for even the most basic network environments. I'm not discussing firewall configurations here. You should be running a reasonable firewall on every computer connected to any form of networking these days. If you choose not to run a firewall, or properly configure it, may whatever deity you pray to have mercy on your soul. NTP supports a rather robust authentication scheme if you choose to implement it. The following configurations at intended for individuals and small to medium size network where authentication would provide underwhelming benefit for the complexity and maintenance needs. In a future article I will expand on authentication.

Client Configuration

Clients should have simple configurations really, there just is not much complexity in setting the clock on a client computer. The one exception to this might be in virtualized environments. In most virtualized environments you should configure the hosting server as a NTP client and the virtual machines with whatever host-guest time synchronization is available on the platform. The two "goals" of a Client NTP Configuration are to specify the server(s) to get time from, and place NTP in a "client" configuration. A simple, locked-down, configuration helps defend the client against potential attack vectors while maintaining functionality. The most common version of this is:

server ntp.pool.ntp.org iburst
restrict default ignore

The first line specifies the server to get time from. The NTP Pool Project maintains a list of publicly accessible NTP servers that should be used. The iburst options tells NTP to rapidly retry the connection if it receives no response, every 2 seconds for the first 8 requests instead of the default 64 second spacing. More complicated networks might use broadcast or multicast for their clients' time source, but more on that in a future article. Ideally a client should have multiple server to pull time from, three to four is commonly suggested. Multiple servers can be specified by simply repeating the server ... configuration line.

The second line specifies that the client will not listen to anything. It will not allow other clients to get time from it, nor management information to be pulled - absolutely all incoming requests are ignored. You can just as easily firewall the client and not allow any requests in the first place, but it's good practice to simply close this possibility at the service in addition to denying requests at the firewall. You may want to allow some management functions, mainly to monitor your time synchronization. You can add a third (or more) line to re-enable management functionality for a management server:

restrict 192.0.2.5 noserve

This third line allows the server at 192.0.2.5 unrestricted access to 'query', 'modify', and 'trap' functionalities. If you do not have a monitoring server, or it doesn't use one of these functions they can be individually disable using noquery, nomodify, and notrap (respectively) appended to noserve.

Internal Server

Similar to the previous configuration but allowing clients to connect. Additionally it's really important that any NTP Server be connecting to a reliable time source. To that end, pick a single public stratum 1 server and poll it infrequently. Something like this:

server tick.usno.navy.mil prefer minpoll 10 maxpoll 16

server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 2.us.pool.ntp.org

restrict default kod limited nomodify noquery nopeer notrap
discard average 9 minimum 5

driftfile /var/db/ntpd.drift

As in the Client configuration, we still connect to the NTP Pool Project for the bulk of our clock synchronization. Even if your localtime is different from those servers by a few milliseconds, NTP will use their time to stabilize the drift on the local clock. This will result in a more stable localtime even if all external time sources become disconnected. The first server listed here is the US Navy's public NTP Server Cluster. It should only be used by other NTP Server which provide time to clients per the Navy's request. Additionally I've included directives to poll it less often to lighten their load.

If you expect to be disconnect from other time servers regularly you may want to configure your server to use the LCL reference clock. It is essential no reference clock at all. With periotic drift corrections it can be as accurate as a second a day. But it should not be used unless you absolutely must disconnect the system from external time server and cannot connect a hardware clock for some reason.

Public Server

There's really not much difference in the following configuration from the previous, other than adding some logging. A Public NTP server should be closely monitored to ensure it's providing accurate time as well as not being abused (the UDP nature of NTP means it's easily abused in reflection and amplification attacks).

server tick.usno.navy.mil prefer minpoll 10 maxpoll 16
server ntp-oar.usno.navy.mil iburst
server ntp-gatech.usno.navy.mil iburst

restrict default kod limited nomodify noquery nopeer notrap
discard average 9 minimum 5

driftfile /var/db/ntpd.drift

logfile /var/log/ntp.log
logconfig +sysall +syncall
statistics loopstats
statsdir /var/log/ntp
filegen loopstats file loops type day link enable

If you plan on listing with the NTP Pool Project they request that your server does not synchronize against other pool servers as this may lead to pool drift. Ideally servers in the pool get their time from a Stratum 1 server or a hardware clock. The big difference in running a Public Server is the commitment you are making. Public NTP server need to be accurate and available over great lengths of time. You should have a static IP address and a reasonable expectation of being able to provide NTP service for at least a year into the future. If this change you need to immediately advise any services listing your server. This most and many others I have written are in direct response to Questions I have seen or answered on Server Fault. Server fault is a Question and Answer site exclusively for Professional System Administrators (et al). It's part of the Stack Exchange network of Q&A sites - expert answers to your questions.