NTPD.CONF(5)

✨ NTPD.CONF(5) ✨

okay so this is the ntpd.conf page from the File Formats Manual — it's literally the glow-up guide for your NTP daemon's config file, and i'm gonna walk you through every single line of it 🫶

---

💖 NAME 💖

ntpd.conf — the NTP daemon configuration file, aka the lil text file that tells ntpd(8) how to live its life 💅

---

🌸 DESCRIPTION 🌸

This manual page describes the format of the ntpd(8) configuration file. that's it, that's the vibe.

ntpd.conf has the following format:

• Empty lines? ignored. 💀
• Lines beginning with the # character? also ignored. those are your lil comments bestie, use them liberally ✨

Keywords may be specified multiple times within the configuration file — like, go off, repeat yourself, it's fine 👑

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, it can act as an NTP server itself, redistributing the local clock. like, main character energy — it's not just receiving, it's serving now 💁‍♀️

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 — nope, not a single one, it's shy like that 🙈 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 *

or

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

• query from sourceaddr — Specify a local IP address the ntpd(8) daemon should use for outgoing queries to subsequently specified servers, which is useful on machines with multiple interfaces. lowkey crucial if your box is out here with a whole wardrobe of network interfaces 👗 For example:

query from 192.0.2.1
query from 2001:db8::1

• sensor device [correction microseconds] [refid ID-string] [stratum stratum-value] [trusted] [weight weight-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 — ghosted, respectfully 🫥 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

A 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

A refid ID-string of 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

The stratum keyword can be used to change the stratum value from the default of 1.

The trusted keyword indicates the time learned is secure, trustworthy, and not vulnerable to man-in-the-middle attacks, so constraints validation is skipped. This is useful for boot-time correction in environments where constraints cannot be used. it's giving "i trust you with my whole clock" 🕐💜

The 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. it's giving popularity contest but make it physics 🔥

• server address [trusted] [weight weight-value] — 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. 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 — bestie is persistent, she does not give up on a server 💀 For example:

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

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. so like, pick the close ones, bestie, latency is the enemy 🏃‍♀️💨

• servers address [trusted] [weight weight-value] — 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 — the plural version ate, no crumbs left ✨ For example:

servers pool.ntp.org
servers pool.ntp.org weight 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. it's the bouncer at the club checking IDs, and some servers are not getting in 🚫🎟️

🚨 Support for constraints is only available if ntpd(8) has been linked with libtls from LibreSSL. Configuring a constraint without libtls causes ntpd(8) to log a warning message on startup. so like, check your build before you get obsessed, bestie 😭

• constraint from url [ip...] — Specify the URL, IP address or the hostname of an HTTPS server to provide a constraint. If the url is followed by one or more addresses, the url and addresses will be tried until a working one is found. The url path and expected certificate name is always taken from the url specified. If constraint from is used more than once, ntpd(8) will calculate a median constraint from all the servers specified. median constraint is such a slay statistical move 📊✨

server ntp.example.org
constraint from www.example.com
constraint from "https://9.9.9.9" "2620:fe::9"

• 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. Again: the plural version understood the assignment 🎀 For example:

servers pool.ntp.org
constraints from "https://www.google.com/"

---

🎀 FILES 🎀

• /etc/ntpd.conf — Default ntpd(8) configuration file. that's the one, that's home 🏡

---

🌈 SEE ALSO 🌈

ntpctl(8), ntpd(8), sysctl(8) — go read your friends' pages too, they're all linked, iykyk 💖

---

⭐ HISTORY ⭐

The ntpd.conf file format first appeared in OpenBSD 3.6. an icon, a legend, a pioneer 👑

---

and that's the whole page, bestie — no notes, no skips, every single flag accounted for 💅

this queen came to you courtesy of the Debian build of the File Formats Manual, dated March 2, 2023 — mwah, go sync your clock now 🕐💜✨