Configuration recommendations for servers joining the pool
If you just want to use the pool, see the pool usage page.
The comp.protocols.time.ntp newsgroup is the best place to get help with the ntpd software.
Below are some things of particular importance if you are going to join the NTP Pool with your server.
The Internet Engineering Task Force have published a draft on Network Time Protocol Best Current Practices that we recommend.
Make the default configuration be to not allow "management queries". For ntpd this will be adding the "noquery" option to the default "restrict" lines, for example:
restrict default kod limited nomodify notrap nopeer noquery restrict -6 default kod limited nomodify notrap nopeer noquery
To allow commands like "ntpq -c pe" to work from localhost you can add:
restrict 127.0.0.1 restrict -6 ::1
Setup about 5 servers
To work properly ntpd needs to talk to at least 3 servers ("A man with a watch knows what time it is. A man with two watches is never sure").
For servers in the pool we recommend configuring no less than 4 and no more than 7 servers.
Don't use *.pool.ntp.org servers
Ironically to make sure the pool service is the best it can be you shouldn't use the *.pool.ntp.org aliases in your configuration when you are going to add your server to the pool.
For the robustness of the pool it's healthier if all pool operators "hand pick" good local (network wise) time servers. The NTP.org wiki has a list of public servers.
Use the standard ntpd
We are all for software diversity, but a significant percentage of the "it's not working" questions that come in are for software other than ntpd.
You can use the pool with any program speaking NTP, but if you are going to join the pool we recommend you use ntpd.
Don't use the LOCAL clock driver
Servers in the NTP Pool should not have the LOCAL clock driver configured.
Beware of PTR DNS queries
Some server operators have reported that some of the NTP users (or their firewall software) does a "reverse DNS" (PTR) query for the IP address of the NTP server. Beware that this might cause the number of queries to go up. Increasing the "time to live" on those records is recommended if the number of DNS queries is a concern, and will generally make the number of queries negligible.