Ubuntu Manpage: ntpd.conf — Network Time Protocol daemon configuration file

NAME

       ntpd.conf — Network Time Protocol daemon configuration file

DESCRIPTION

This manual page describes the format of the ntpd(8) configuration file.

ntpd.conf has the following format:

Empty lines and lines beginning with the ‘#’ character are ignored.

Keywords may be specified multiple times within the configuration file. The basic configuration options
are as follows:

listen on address [rtable table-id]
ntpd(8) has the ability to sync the local clock to remote NTP servers and, if this directive is
specified, can act as NTP server itself, redistributing the local clock.

Specify a local IP address or a hostname the ntpd(8) daemon should listen on to enable remote
clients synchronization. If it appears multiple times, ntpd(8) will listen on each given
address. If ‘*’ is given as an address, ntpd(8) will listen on all local addresses using the
specified routing table. ntpd(8) does not listen on any address by default. The optional rtable
keyword will specify which routing table to listen on, if the operating system supports rdomains.
By default ntpd(8) will listen using the current routing table. For example:

listen on *

listen on 127.0.0.1
listen on ::1
listen on 127.0.0.1 rtable 4

sensor device [correction microseconds] [weight weight-value] [refid string] [stratum stratum-value]
Specify a timedelta sensor device ntpd(8) should use, if the operating system supports sensors.
The sensor can be specified multiple times: ntpd(8) will use each given sensor that actually
exists. Non-existent sensors are ignored. If ‘*’ is given as device name, ntpd(8) will use all
timedelta sensors it finds. ntpd(8) does not use any timedelta sensor by default. For example:

sensor *
sensor nmea0

An optional correction in microseconds can be given to compensate for the sensor's offset. The
maximum correction is 127 seconds. For example, if a DCF77 receiver is lagging 70ms behind
actual time:

sensor udcf0 correction 70000

The optional weight keyword permits finer control over the relative importance of time sources
(servers or sensor devices). Weights are specified in the range 1 to 10; if no weight is given,
the default is 1. A server with a weight of 5, for example, will have five times more influence
on time offset calculation than a server with a weight of 1.

An optional reference ID string - up to 4 ASCII characters - can be given to publish the sensor
type to clients. RFC 2030 suggests some common reference identifiers, but new identifiers "can
be contrived as appropriate." If an ID string is not given, ntpd(8) will use a generic reference
ID. For example:

sensor nmea0 refid GPS

A stratum value other than the default of 1 can be assigned using the stratum keyword.

server address [weight weight-value] [rtable table-id]
Specify the IP address or the hostname of an NTP server to synchronize to. If it appears
multiple times, ntpd(8) will try to synchronize to all of the servers specified. The rtable
option specifies which routing table should be used for connection attempts. Hostname resolution
will still happen using the default routing table. If a hostname resolves to multiple IPv4
and/or IPv6 addresses, ntpd(8) uses the first address. If it does not get a reply, ntpd(8)
retries with the next address and continues to do so until a working address is found. For
example:

server 10.0.0.2 weight 5
server ntp.example.org weight 1 rtable 4

To provide redundancy, it is good practice to configure multiple servers. In general, best
accuracy is obtained by using servers that have a low network latency.

servers address [weight weight-value] [rtable table-id]
As with server, specify the IP address or hostname of an NTP server to synchronize to. If it
appears multiple times, ntpd(8) will try to synchronize to all of the servers specified. Should
the hostname resolve to multiple IP addresses, ntpd(8) will try to synchronize to all of them.
For example:

servers pool.ntp.org
servers pool.ntp.org rtable 5

CONSTRAINTS

       ntpd(8)  can be configured to query the ‘Date’ from trusted HTTPS servers via TLS.  This time information
       is not used for precision but acts as  an  authenticated  constraint,  thereby  reducing  the  impact  of
       unauthenticated  NTP  ‘Man-In-The-Middle’  attacks.   Received  NTP packets with time information falling
       outside of a range near the constraint will be discarded and such NTP servers will be marked as invalid.

       constraint from url
               Specify the URL, IP address or the hostname of an HTTPS  server  to  provide  a  constraint.   If
               constraint  from  is used more than once, ntpd(8) will calculate a median constraint from all the
               servers specified.

                     server ntp.example.org
                     constraint from www.example.com

       constraints from url
               As with constraint from, specify the URL, IP address or  the  hostname  of  an  HTTPS  server  to
               provide  a  constraint.   Should  the  hostname  resolve  to  multiple IP addresses, ntpd(8) will
               calculate a median constraint from all of them.  For example:

                     servers pool.ntp.org
                     constraints from "https://www.google.com/search?q=openntpd"

FILES

       /etc/ntpd.conf     default ntpd(8) configuration file

HISTORY

       The ntpd.conf file format first appeared in OpenBSD 3.6.

CAVEATS