ntp.conf.html revision 275970
1<html lang="en"> 2<head> 3<title>NTP Configuration File User's Manual</title> 4<meta http-equiv="Content-Type" content="text/html"> 5<meta name="description" content="NTP Configuration File User's Manual"> 6<meta name="generator" content="makeinfo 4.7"> 7<link title="Top" rel="top" href="#Top"> 8<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> 9<meta http-equiv="Content-Style-Type" content="text/css"> 10<style type="text/css"><!-- 11 pre.display { font-family:inherit } 12 pre.format { font-family:inherit } 13 pre.smalldisplay { font-family:inherit; font-size:smaller } 14 pre.smallformat { font-family:inherit; font-size:smaller } 15 pre.smallexample { font-size:smaller } 16 pre.smalllisp { font-size:smaller } 17 span.sc { font-variant:small-caps } 18 span.roman { font-family: serif; font-weight: normal; } 19--></style> 20</head> 21<body> 22<h1 class="settitle">NTP Configuration File User's Manual</h1> 23<div class="node"> 24<p><hr> 25<a name="Top"></a>Next: <a rel="next" accesskey="n" href="#ntp_002econf-Description">ntp.conf Description</a>, 26Previous: <a rel="previous" accesskey="p" href="#dir">(dir)</a>, 27Up: <a rel="up" accesskey="u" href="#dir">(dir)</a> 28<br> 29</div> 30 31<h2 class="unnumbered">NTP's Configuration File User Manual</h2> 32 33<p>This document describes the configuration file for the NTP Project's 34<code>ntpd</code> program. 35 36 <p>This document applies to version 4.2.8 of <code>ntp.conf</code>. 37 38 <div class="shortcontents"> 39<h2>Short Contents</h2> 40<ul> 41<a href="#Top">NTP's Configuration File User Manual</a> 42</ul> 43</div> 44 45<ul class="menu"> 46<li><a accesskey="1" href="#ntp_002econf-Description">ntp.conf Description</a> 47<li><a accesskey="2" href="#ntp_002econf-Notes">ntp.conf Notes</a> 48</ul> 49 50<div class="node"> 51<p><hr> 52<a name="ntp_002econf-Description"></a>Previous: <a rel="previous" accesskey="p" href="#Top">Top</a>, 53Up: <a rel="up" accesskey="u" href="#Top">Top</a> 54<br> 55</div> 56 57<!-- node-name, next, previous, up --> 58<h3 class="section">Description</h3> 59 60<p>The behavior of <code>ntpd</code> can be changed by a configuration file, 61by default <code>ntp.conf</code>. 62 63<div class="node"> 64<p><hr> 65<a name="ntp_002econf-Notes"></a> 66<br> 67</div> 68 69<h3 class="section">Notes about ntp.conf</h3> 70 71<p><a name="index-ntp_002econf-1"></a><a name="index-Network-Time-Protocol-_0028NTP_0029-daemon-configuration-file-format-2"></a> 72 73 <p>The 74<code>ntp.conf</code> 75configuration file is read at initial startup by the 76<code>ntpd(1ntpdmdoc)</code> 77daemon in order to specify the synchronization sources, 78modes and other related information. 79Usually, it is installed in the 80<span class="file">/etc</span> 81directory, 82but could be installed elsewhere 83(see the daemon's 84<code>-c</code> 85command line option). 86 87 <p>The file format is similar to other 88<span class="sc">unix</span> 89configuration files. 90Comments begin with a 91# 92character and extend to the end of the line; 93blank lines are ignored. 94Configuration commands consist of an initial keyword 95followed by a list of arguments, 96some of which may be optional, separated by whitespace. 97Commands may not be continued over multiple lines. 98Arguments may be host names, 99host addresses written in numeric, dotted-quad form, 100integers, floating point numbers (when specifying times in seconds) 101and text strings. 102 103 <p>The rest of this page describes the configuration and control options. 104The 105"Notes on Configuring NTP and Setting up an NTP Subnet" 106page 107(available as part of the HTML documentation 108provided in 109<span class="file">/usr/share/doc/ntp</span>) 110contains an extended discussion of these options. 111In addition to the discussion of general 112<a href="#Configuration-Options">Configuration Options</a>, 113there are sections describing the following supported functionality 114and the options used to control it: 115 <ul> 116<li><a href="#Authentication-Support">Authentication Support</a> 117<li><a href="#Monitoring-Support">Monitoring Support</a> 118<li><a href="#Access-Control-Support">Access Control Support</a> 119<li><a href="#Automatic-NTP-Configuration-Options">Automatic NTP Configuration Options</a> 120<li><a href="#Reference-Clock-Support">Reference Clock Support</a> 121<li><a href="#Miscellaneous-Options">Miscellaneous Options</a> 122</ul> 123 124 <p>Following these is a section describing 125<a href="#Miscellaneous-Options">Miscellaneous Options</a>. 126While there is a rich set of options available, 127the only required option is one or more 128<code>pool</code>, 129<code>server</code>, 130<code>peer</code>, 131<code>broadcast</code> 132or 133<code>manycastclient</code> 134commands. 135<div class="node"> 136<p><hr> 137<a name="Configuration-Support"></a> 138<br> 139</div> 140 141<h4 class="subsection">Configuration Support</h4> 142 143<p>Following is a description of the configuration commands in 144NTPv4. 145These commands have the same basic functions as in NTPv3 and 146in some cases new functions and new arguments. 147There are two 148classes of commands, configuration commands that configure a 149persistent association with a remote server or peer or reference 150clock, and auxiliary commands that specify environmental variables 151that control various related operations. 152 153<h5 class="subsubsection">Configuration Commands</h5> 154 155<p>The various modes are determined by the command keyword and the 156type of the required IP address. 157Addresses are classed by type as 158(s) a remote server or peer (IPv4 class A, B and C), (b) the 159broadcast address of a local interface, (m) a multicast address (IPv4 160class D), or (r) a reference clock address (127.127.x.x). 161Note that 162only those options applicable to each command are listed below. 163Use 164of options not listed may not be caught as an error, but may result 165in some weird and even destructive behavior. 166 167 <p>If the Basic Socket Interface Extensions for IPv6 (RFC-2553) 168is detected, support for the IPv6 address family is generated 169in addition to the default support of the IPv4 address family. 170In a few cases, including the reslist billboard generated 171by ntpdc, IPv6 addresses are automatically generated. 172IPv6 addresses can be identified by the presence of colons 173: 174in the address field. 175IPv6 addresses can be used almost everywhere where 176IPv4 addresses can be used, 177with the exception of reference clock addresses, 178which are always IPv4. 179 180 <p>Note that in contexts where a host name is expected, a 181<code>-4</code> 182qualifier preceding 183the host name forces DNS resolution to the IPv4 namespace, 184while a 185<code>-6</code> 186qualifier forces DNS resolution to the IPv6 namespace. 187See IPv6 references for the 188equivalent classes for that address family. 189 <dl> 190<dt><code>pool</code> <kbd>address</kbd> <code>[burst]</code> <code>[iburst]</code> <code>[version </code><kbd>version</kbd><code>]</code> <code>[prefer]</code> <code>[minpoll </code><kbd>minpoll</kbd><code>]</code> <code>[maxpoll </code><kbd>maxpoll</kbd><code>]</code><br><dt><code>server</code> <kbd>address</kbd> <code>[key </code><kbd>key</kbd> <kbd>|</kbd><code> autokey]</code> <code>[burst]</code> <code>[iburst]</code> <code>[version </code><kbd>version</kbd><code>]</code> <code>[prefer]</code> <code>[minpoll </code><kbd>minpoll</kbd><code>]</code> <code>[maxpoll </code><kbd>maxpoll</kbd><code>]</code><br><dt><code>peer</code> <kbd>address</kbd> <code>[key </code><kbd>key</kbd> <kbd>|</kbd><code> autokey]</code> <code>[version </code><kbd>version</kbd><code>]</code> <code>[prefer]</code> <code>[minpoll </code><kbd>minpoll</kbd><code>]</code> <code>[maxpoll </code><kbd>maxpoll</kbd><code>]</code><br><dt><code>broadcast</code> <kbd>address</kbd> <code>[key </code><kbd>key</kbd> <kbd>|</kbd><code> autokey]</code> <code>[version </code><kbd>version</kbd><code>]</code> <code>[prefer]</code> <code>[minpoll </code><kbd>minpoll</kbd><code>]</code> <code>[ttl </code><kbd>ttl</kbd><code>]</code><br><dt><code>manycastclient</code> <kbd>address</kbd> <code>[key </code><kbd>key</kbd> <kbd>|</kbd><code> autokey]</code> <code>[version </code><kbd>version</kbd><code>]</code> <code>[prefer]</code> <code>[minpoll </code><kbd>minpoll</kbd><code>]</code> <code>[maxpoll </code><kbd>maxpoll</kbd><code>]</code> <code>[ttl </code><kbd>ttl</kbd><code>]</code><dd></dl> 191 192 <p>These five commands specify the time server name or address to 193be used and the mode in which to operate. 194The 195<kbd>address</kbd> 196can be 197either a DNS name or an IP address in dotted-quad notation. 198Additional information on association behavior can be found in the 199"Association Management" 200page 201(available as part of the HTML documentation 202provided in 203<span class="file">/usr/share/doc/ntp</span>). 204 <dl> 205<dt><code>pool</code><dd>For type s addresses, this command mobilizes a persistent 206client mode association with a number of remote servers. 207In this mode the local clock can synchronized to the 208remote server, but the remote server can never be synchronized to 209the local clock. 210<br><dt><code>server</code><dd>For type s and r addresses, this command mobilizes a persistent 211client mode association with the specified remote server or local 212radio clock. 213In this mode the local clock can synchronized to the 214remote server, but the remote server can never be synchronized to 215the local clock. 216This command should 217<em>not</em> 218be used for type 219b or m addresses. 220<br><dt><code>peer</code><dd>For type s addresses (only), this command mobilizes a 221persistent symmetric-active mode association with the specified 222remote peer. 223In this mode the local clock can be synchronized to 224the remote peer or the remote peer can be synchronized to the local 225clock. 226This is useful in a network of servers where, depending on 227various failure scenarios, either the local or remote peer may be 228the better source of time. 229This command should NOT be used for type 230b, m or r addresses. 231<br><dt><code>broadcast</code><dd>For type b and m addresses (only), this 232command mobilizes a persistent broadcast mode association. 233Multiple 234commands can be used to specify multiple local broadcast interfaces 235(subnets) and/or multiple multicast groups. 236Note that local 237broadcast messages go only to the interface associated with the 238subnet specified, but multicast messages go to all interfaces. 239In broadcast mode the local server sends periodic broadcast 240messages to a client population at the 241<kbd>address</kbd> 242specified, which is usually the broadcast address on (one of) the 243local network(s) or a multicast address assigned to NTP. 244The IANA 245has assigned the multicast group address IPv4 224.0.1.1 and 246IPv6 ff05::101 (site local) exclusively to 247NTP, but other nonconflicting addresses can be used to contain the 248messages within administrative boundaries. 249Ordinarily, this 250specification applies only to the local server operating as a 251sender; for operation as a broadcast client, see the 252<code>broadcastclient</code> 253or 254<code>multicastclient</code> 255commands 256below. 257<br><dt><code>manycastclient</code><dd>For type m addresses (only), this command mobilizes a 258manycast client mode association for the multicast address 259specified. 260In this case a specific address must be supplied which 261matches the address used on the 262<code>manycastserver</code> 263command for 264the designated manycast servers. 265The NTP multicast address 266224.0.1.1 assigned by the IANA should NOT be used, unless specific 267means are taken to avoid spraying large areas of the Internet with 268these messages and causing a possibly massive implosion of replies 269at the sender. 270The 271<code>manycastserver</code> 272command specifies that the local server 273is to operate in client mode with the remote servers that are 274discovered as the result of broadcast/multicast messages. 275The 276client broadcasts a request message to the group address associated 277with the specified 278<kbd>address</kbd> 279and specifically enabled 280servers respond to these messages. 281The client selects the servers 282providing the best time and continues as with the 283<code>server</code> 284command. 285The remaining servers are discarded as if never 286heard. 287</dl> 288 289 <p>Options: 290 <dl> 291<dt><code>autokey</code><dd>All packets sent to and received from the server or peer are to 292include authentication fields encrypted using the autokey scheme 293described in 294<a href="#Authentication-Options">Authentication Options</a>. 295<br><dt><code>burst</code><dd>when the server is reachable, send a burst of eight packets 296instead of the usual one. 297The packet spacing is normally 2 s; 298however, the spacing between the first and second packets 299can be changed with the calldelay command to allow 300additional time for a modem or ISDN call to complete. 301This is designed to improve timekeeping quality 302with the 303<code>server</code> 304command and s addresses. 305<br><dt><code>iburst</code><dd>When the server is unreachable, send a burst of eight packets 306instead of the usual one. 307The packet spacing is normally 2 s; 308however, the spacing between the first two packets can be 309changed with the calldelay command to allow 310additional time for a modem or ISDN call to complete. 311This is designed to speed the initial synchronization 312acquisition with the 313<code>server</code> 314command and s addresses and when 315<code>ntpd(1ntpdmdoc)</code> 316is started with the 317<code>-q</code> 318option. 319<br><dt><code>key</code> <kbd>key</kbd><dd>All packets sent to and received from the server or peer are to 320include authentication fields encrypted using the specified 321<kbd>key</kbd> 322identifier with values from 1 to 65534, inclusive. 323The 324default is to include no encryption field. 325<br><dt><code>minpoll</code> <kbd>minpoll</kbd><br><dt><code>maxpoll</code> <kbd>maxpoll</kbd><dd>These options specify the minimum and maximum poll intervals 326for NTP messages, as a power of 2 in seconds 327The maximum poll 328interval defaults to 10 (1,024 s), but can be increased by the 329<code>maxpoll</code> 330option to an upper limit of 17 (36.4 h). 331The 332minimum poll interval defaults to 6 (64 s), but can be decreased by 333the 334<code>minpoll</code> 335option to a lower limit of 4 (16 s). 336<br><dt><code>noselect</code><dd>Marks the server as unused, except for display purposes. 337The server is discarded by the selection algroithm. 338<br><dt><code>prefer</code><dd>Marks the server as preferred. 339All other things being equal, 340this host will be chosen for synchronization among a set of 341correctly operating hosts. 342See the 343"Mitigation Rules and the prefer Keyword" 344page 345(available as part of the HTML documentation 346provided in 347<span class="file">/usr/share/doc/ntp</span>) 348for further information. 349<br><dt><code>ttl</code> <kbd>ttl</kbd><dd>This option is used only with broadcast server and manycast 350client modes. 351It specifies the time-to-live 352<kbd>ttl</kbd> 353to 354use on broadcast server and multicast server and the maximum 355<kbd>ttl</kbd> 356for the expanding ring search with manycast 357client packets. 358Selection of the proper value, which defaults to 359127, is something of a black art and should be coordinated with the 360network administrator. 361<br><dt><code>version</code> <kbd>version</kbd><dd>Specifies the version number to be used for outgoing NTP 362packets. 363Versions 1-4 are the choices, with version 4 the 364default. 365</dl> 366 367<h5 class="subsubsection">Auxiliary Commands</h5> 368 369 <dl> 370<dt><code>broadcastclient</code><dd>This command enables reception of broadcast server messages to 371any local interface (type b) address. 372Upon receiving a message for 373the first time, the broadcast client measures the nominal server 374propagation delay using a brief client/server exchange with the 375server, then enters the broadcast client mode, in which it 376synchronizes to succeeding broadcast messages. 377Note that, in order 378to avoid accidental or malicious disruption in this mode, both the 379server and client should operate using symmetric-key or public-key 380authentication as described in 381<a href="#Authentication-Options">Authentication Options</a>. 382<br><dt><code>manycastserver</code> <kbd>address</kbd> <kbd>...</kbd><dd>This command enables reception of manycast client messages to 383the multicast group address(es) (type m) specified. 384At least one 385address is required, but the NTP multicast address 224.0.1.1 386assigned by the IANA should NOT be used, unless specific means are 387taken to limit the span of the reply and avoid a possibly massive 388implosion at the original sender. 389Note that, in order to avoid 390accidental or malicious disruption in this mode, both the server 391and client should operate using symmetric-key or public-key 392authentication as described in 393<a href="#Authentication-Options">Authentication Options</a>. 394<br><dt><code>multicastclient</code> <kbd>address</kbd> <kbd>...</kbd><dd>This command enables reception of multicast server messages to 395the multicast group address(es) (type m) specified. 396Upon receiving 397a message for the first time, the multicast client measures the 398nominal server propagation delay using a brief client/server 399exchange with the server, then enters the broadcast client mode, in 400which it synchronizes to succeeding multicast messages. 401Note that, 402in order to avoid accidental or malicious disruption in this mode, 403both the server and client should operate using symmetric-key or 404public-key authentication as described in 405<a href="#Authentication-Options">Authentication Options</a>. 406</dl> 407<div class="node"> 408<p><hr> 409<a name="Authentication-Support"></a> 410<br> 411</div> 412 413<h4 class="subsection">Authentication Support</h4> 414 415<p>Authentication support allows the NTP client to verify that the 416server is in fact known and trusted and not an intruder intending 417accidentally or on purpose to masquerade as that server. 418The NTPv3 419specification RFC-1305 defines a scheme which provides 420cryptographic authentication of received NTP packets. 421Originally, 422this was done using the Data Encryption Standard (DES) algorithm 423operating in Cipher Block Chaining (CBC) mode, commonly called 424DES-CBC. 425Subsequently, this was replaced by the RSA Message Digest 4265 (MD5) algorithm using a private key, commonly called keyed-MD5. 427Either algorithm computes a message digest, or one-way hash, which 428can be used to verify the server has the correct private key and 429key identifier. 430 431 <p>NTPv4 retains the NTPv3 scheme, properly described as symmetric key 432cryptography and, in addition, provides a new Autokey scheme 433based on public key cryptography. 434Public key cryptography is generally considered more secure 435than symmetric key cryptography, since the security is based 436on a private value which is generated by each server and 437never revealed. 438With Autokey all key distribution and 439management functions involve only public values, which 440considerably simplifies key distribution and storage. 441Public key management is based on X.509 certificates, 442which can be provided by commercial services or 443produced by utility programs in the OpenSSL software library 444or the NTPv4 distribution. 445 446 <p>While the algorithms for symmetric key cryptography are 447included in the NTPv4 distribution, public key cryptography 448requires the OpenSSL software library to be installed 449before building the NTP distribution. 450Directions for doing that 451are on the Building and Installing the Distribution page. 452 453 <p>Authentication is configured separately for each association 454using the 455<code>key</code> 456or 457<code>autokey</code> 458subcommand on the 459<code>peer</code>, 460<code>server</code>, 461<code>broadcast</code> 462and 463<code>manycastclient</code> 464configuration commands as described in 465<a href="#Configuration-Options">Configuration Options</a> 466page. 467The authentication 468options described below specify the locations of the key files, 469if other than default, which symmetric keys are trusted 470and the interval between various operations, if other than default. 471 472 <p>Authentication is always enabled, 473although ineffective if not configured as 474described below. 475If a NTP packet arrives 476including a message authentication 477code (MAC), it is accepted only if it 478passes all cryptographic checks. 479The 480checks require correct key ID, key value 481and message digest. 482If the packet has 483been modified in any way or replayed 484by an intruder, it will fail one or more 485of these checks and be discarded. 486Furthermore, the Autokey scheme requires a 487preliminary protocol exchange to obtain 488the server certificate, verify its 489credentials and initialize the protocol 490 491 <p>The 492<code>auth</code> 493flag controls whether new associations or 494remote configuration commands require cryptographic authentication. 495This flag can be set or reset by the 496<code>enable</code> 497and 498<code>disable</code> 499commands and also by remote 500configuration commands sent by a 501<code>ntpdc(1ntpdcmdoc)</code> 502program running in 503another machine. 504If this flag is enabled, which is the default 505case, new broadcast client and symmetric passive associations and 506remote configuration commands must be cryptographically 507authenticated using either symmetric key or public key cryptography. 508If this 509flag is disabled, these operations are effective 510even if not cryptographic 511authenticated. 512It should be understood 513that operating with the 514<code>auth</code> 515flag disabled invites a significant vulnerability 516where a rogue hacker can 517masquerade as a falseticker and seriously 518disrupt system timekeeping. 519It is 520important to note that this flag has no purpose 521other than to allow or disallow 522a new association in response to new broadcast 523and symmetric active messages 524and remote configuration commands and, in particular, 525the flag has no effect on 526the authentication process itself. 527 528 <p>An attractive alternative where multicast support is available 529is manycast mode, in which clients periodically troll 530for servers as described in the 531<a href="#Automatic-NTP-Configuration-Options">Automatic NTP Configuration Options</a> 532page. 533Either symmetric key or public key 534cryptographic authentication can be used in this mode. 535The principle advantage 536of manycast mode is that potential servers need not be 537configured in advance, 538since the client finds them during regular operation, 539and the configuration 540files for all clients can be identical. 541 542 <p>The security model and protocol schemes for 543both symmetric key and public key 544cryptography are summarized below; 545further details are in the briefings, papers 546and reports at the NTP project page linked from 547<code>http://www.ntp.org/</code>. 548 549<h5 class="subsubsection">Symmetric-Key Cryptography</h5> 550 551<p>The original RFC-1305 specification allows any one of possibly 55265,534 keys, each distinguished by a 32-bit key identifier, to 553authenticate an association. 554The servers and clients involved must 555agree on the key and key identifier to 556authenticate NTP packets. 557Keys and 558related information are specified in a key 559file, usually called 560<span class="file">ntp.keys</span>, 561which must be distributed and stored using 562secure means beyond the scope of the NTP protocol itself. 563Besides the keys used 564for ordinary NTP associations, 565additional keys can be used as passwords for the 566<code>ntpq(1ntpqmdoc)</code> 567and 568<code>ntpdc(1ntpdcmdoc)</code> 569utility programs. 570 571 <p>When 572<code>ntpd(1ntpdmdoc)</code> 573is first started, it reads the key file specified in the 574<code>keys</code> 575configuration command and installs the keys 576in the key cache. 577However, 578individual keys must be activated with the 579<code>trusted</code> 580command before use. 581This 582allows, for instance, the installation of possibly 583several batches of keys and 584then activating or deactivating each batch 585remotely using 586<code>ntpdc(1ntpdcmdoc)</code>. 587This also provides a revocation capability that can be used 588if a key becomes compromised. 589The 590<code>requestkey</code> 591command selects the key used as the password for the 592<code>ntpdc(1ntpdcmdoc)</code> 593utility, while the 594<code>controlkey</code> 595command selects the key used as the password for the 596<code>ntpq(1ntpqmdoc)</code> 597utility. 598 599<h5 class="subsubsection">Public Key Cryptography</h5> 600 601<p>NTPv4 supports the original NTPv3 symmetric key scheme 602described in RFC-1305 and in addition the Autokey protocol, 603which is based on public key cryptography. 604The Autokey Version 2 protocol described on the Autokey Protocol 605page verifies packet integrity using MD5 message digests 606and verifies the source with digital signatures and any of several 607digest/signature schemes. 608Optional identity schemes described on the Identity Schemes 609page and based on cryptographic challenge/response algorithms 610are also available. 611Using all of these schemes provides strong security against 612replay with or without modification, spoofing, masquerade 613and most forms of clogging attacks. 614 615 <p>The Autokey protocol has several modes of operation 616corresponding to the various NTP modes supported. 617Most modes use a special cookie which can be 618computed independently by the client and server, 619but encrypted in transmission. 620All modes use in addition a variant of the S-KEY scheme, 621in which a pseudo-random key list is generated and used 622in reverse order. 623These schemes are described along with an executive summary, 624current status, briefing slides and reading list on the 625<a href="#Autonomous-Authentication">Autonomous Authentication</a> 626page. 627 628 <p>The specific cryptographic environment used by Autokey servers 629and clients is determined by a set of files 630and soft links generated by the 631<code>ntp-keygen(1ntpkeygenmdoc)</code> 632program. 633This includes a required host key file, 634required certificate file and optional sign key file, 635leapsecond file and identity scheme files. 636The 637digest/signature scheme is specified in the X.509 certificate 638along with the matching sign key. 639There are several schemes 640available in the OpenSSL software library, each identified 641by a specific string such as 642<code>md5WithRSAEncryption</code>, 643which stands for the MD5 message digest with RSA 644encryption scheme. 645The current NTP distribution supports 646all the schemes in the OpenSSL library, including 647those based on RSA and DSA digital signatures. 648 649 <p>NTP secure groups can be used to define cryptographic compartments 650and security hierarchies. 651It is important that every host 652in the group be able to construct a certificate trail to one 653or more trusted hosts in the same group. 654Each group 655host runs the Autokey protocol to obtain the certificates 656for all hosts along the trail to one or more trusted hosts. 657This requires the configuration file in all hosts to be 658engineered so that, even under anticipated failure conditions, 659the NTP subnet will form such that every group host can find 660a trail to at least one trusted host. 661 662<h5 class="subsubsection">Naming and Addressing</h5> 663 664<p>It is important to note that Autokey does not use DNS to 665resolve addresses, since DNS can't be completely trusted 666until the name servers have synchronized clocks. 667The cryptographic name used by Autokey to bind the host identity 668credentials and cryptographic values must be independent 669of interface, network and any other naming convention. 670The name appears in the host certificate in either or both 671the subject and issuer fields, so protection against 672DNS compromise is essential. 673 674 <p>By convention, the name of an Autokey host is the name returned 675by the Unix 676<code>gethostname(2)</code> 677system call or equivalent in other systems. 678By the system design 679model, there are no provisions to allow alternate names or aliases. 680However, this is not to say that DNS aliases, different names 681for each interface, etc., are constrained in any way. 682 683 <p>It is also important to note that Autokey verifies authenticity 684using the host name, network address and public keys, 685all of which are bound together by the protocol specifically 686to deflect masquerade attacks. 687For this reason Autokey 688includes the source and destinatino IP addresses in message digest 689computations and so the same addresses must be available 690at both the server and client. 691For this reason operation 692with network address translation schemes is not possible. 693This reflects the intended robust security model where government 694and corporate NTP servers are operated outside firewall perimeters. 695 696<h5 class="subsubsection">Operation</h5> 697 698<p>A specific combination of authentication scheme (none, 699symmetric key, public key) and identity scheme is called 700a cryptotype, although not all combinations are compatible. 701There may be management configurations where the clients, 702servers and peers may not all support the same cryptotypes. 703A secure NTPv4 subnet can be configured in many ways while 704keeping in mind the principles explained above and 705in this section. 706Note however that some cryptotype 707combinations may successfully interoperate with each other, 708but may not represent good security practice. 709 710 <p>The cryptotype of an association is determined at the time 711of mobilization, either at configuration time or some time 712later when a message of appropriate cryptotype arrives. 713When mobilized by a 714<code>server</code> 715or 716<code>peer</code> 717configuration command and no 718<code>key</code> 719or 720<code>autokey</code> 721subcommands are present, the association is not 722authenticated; if the 723<code>key</code> 724subcommand is present, the association is authenticated 725using the symmetric key ID specified; if the 726<code>autokey</code> 727subcommand is present, the association is authenticated 728using Autokey. 729 730 <p>When multiple identity schemes are supported in the Autokey 731protocol, the first message exchange determines which one is used. 732The client request message contains bits corresponding 733to which schemes it has available. 734The server response message 735contains bits corresponding to which schemes it has available. 736Both server and client match the received bits with their own 737and select a common scheme. 738 739 <p>Following the principle that time is a public value, 740a server responds to any client packet that matches 741its cryptotype capabilities. 742Thus, a server receiving 743an unauthenticated packet will respond with an unauthenticated 744packet, while the same server receiving a packet of a cryptotype 745it supports will respond with packets of that cryptotype. 746However, unconfigured broadcast or manycast client 747associations or symmetric passive associations will not be 748mobilized unless the server supports a cryptotype compatible 749with the first packet received. 750By default, unauthenticated associations will not be mobilized 751unless overridden in a decidedly dangerous way. 752 753 <p>Some examples may help to reduce confusion. 754Client Alice has no specific cryptotype selected. 755Server Bob has both a symmetric key file and minimal Autokey files. 756Alice's unauthenticated messages arrive at Bob, who replies with 757unauthenticated messages. 758Cathy has a copy of Bob's symmetric 759key file and has selected key ID 4 in messages to Bob. 760Bob verifies the message with his key ID 4. 761If it's the 762same key and the message is verified, Bob sends Cathy a reply 763authenticated with that key. 764If verification fails, 765Bob sends Cathy a thing called a crypto-NAK, which tells her 766something broke. 767She can see the evidence using the 768<code>ntpq(1ntpqmdoc)</code> 769program. 770 771 <p>Denise has rolled her own host key and certificate. 772She also uses one of the identity schemes as Bob. 773She sends the first Autokey message to Bob and they 774both dance the protocol authentication and identity steps. 775If all comes out okay, Denise and Bob continue as described above. 776 777 <p>It should be clear from the above that Bob can support 778all the girls at the same time, as long as he has compatible 779authentication and identity credentials. 780Now, Bob can act just like the girls in his own choice of servers; 781he can run multiple configured associations with multiple different 782servers (or the same server, although that might not be useful). 783But, wise security policy might preclude some cryptotype 784combinations; for instance, running an identity scheme 785with one server and no authentication with another might not be wise. 786 787<h5 class="subsubsection">Key Management</h5> 788 789<p>The cryptographic values used by the Autokey protocol are 790incorporated as a set of files generated by the 791<code>ntp-keygen(1ntpkeygenmdoc)</code> 792utility program, including symmetric key, host key and 793public certificate files, as well as sign key, identity parameters 794and leapseconds files. 795Alternatively, host and sign keys and 796certificate files can be generated by the OpenSSL utilities 797and certificates can be imported from public certificate 798authorities. 799Note that symmetric keys are necessary for the 800<code>ntpq(1ntpqmdoc)</code> 801and 802<code>ntpdc(1ntpdcmdoc)</code> 803utility programs. 804The remaining files are necessary only for the 805Autokey protocol. 806 807 <p>Certificates imported from OpenSSL or public certificate 808authorities have certian limitations. 809The certificate should be in ASN.1 syntax, X.509 Version 3 810format and encoded in PEM, which is the same format 811used by OpenSSL. 812The overall length of the certificate encoded 813in ASN.1 must not exceed 1024 bytes. 814The subject distinguished 815name field (CN) is the fully qualified name of the host 816on which it is used; the remaining subject fields are ignored. 817The certificate extension fields must not contain either 818a subject key identifier or a issuer key identifier field; 819however, an extended key usage field for a trusted host must 820contain the value 821<code>trustRoot</code>;. 822Other extension fields are ignored. 823 824<h5 class="subsubsection">Authentication Commands</h5> 825 826 <dl> 827<dt><code>autokey</code> <code>[</code><kbd>logsec</kbd><code>]</code><dd>Specifies the interval between regenerations of the session key 828list used with the Autokey protocol. 829Note that the size of the key 830list for each association depends on this interval and the current 831poll interval. 832The default value is 12 (4096 s or about 1.1 hours). 833For poll intervals above the specified interval, a session key list 834with a single entry will be regenerated for every message 835sent. 836<br><dt><code>controlkey</code> <kbd>key</kbd><dd>Specifies the key identifier to use with the 837<code>ntpq(1ntpqmdoc)</code> 838utility, which uses the standard 839protocol defined in RFC-1305. 840The 841<kbd>key</kbd> 842argument is 843the key identifier for a trusted key, where the value can be in the 844range 1 to 65,534, inclusive. 845<br><dt><code>crypto</code> <code>[cert </code><kbd>file</kbd><code>]</code> <code>[leap </code><kbd>file</kbd><code>]</code> <code>[randfile </code><kbd>file</kbd><code>]</code> <code>[host </code><kbd>file</kbd><code>]</code> <code>[sign </code><kbd>file</kbd><code>]</code> <code>[gq </code><kbd>file</kbd><code>]</code> <code>[gqpar </code><kbd>file</kbd><code>]</code> <code>[iffpar </code><kbd>file</kbd><code>]</code> <code>[mvpar </code><kbd>file</kbd><code>]</code> <code>[pw </code><kbd>password</kbd><code>]</code><dd>This command requires the OpenSSL library. 846It activates public key 847cryptography, selects the message digest and signature 848encryption scheme and loads the required private and public 849values described above. 850If one or more files are left unspecified, 851the default names are used as described above. 852Unless the complete path and name of the file are specified, the 853location of a file is relative to the keys directory specified 854in the 855<code>keysdir</code> 856command or default 857<span class="file">/usr/local/etc</span>. 858Following are the subcommands: 859 <dl> 860<dt><code>cert</code> <kbd>file</kbd><dd>Specifies the location of the required host public certificate file. 861This overrides the link 862<span class="file">ntpkey_cert_</span><kbd>hostname</kbd> 863in the keys directory. 864<br><dt><code>gqpar</code> <kbd>file</kbd><dd>Specifies the location of the optional GQ parameters file. 865This 866overrides the link 867<span class="file">ntpkey_gq_</span><kbd>hostname</kbd> 868in the keys directory. 869<br><dt><code>host</code> <kbd>file</kbd><dd>Specifies the location of the required host key file. 870This overrides 871the link 872<span class="file">ntpkey_key_</span><kbd>hostname</kbd> 873in the keys directory. 874<br><dt><code>iffpar</code> <kbd>file</kbd><dd>Specifies the location of the optional IFF parameters file.This 875overrides the link 876<span class="file">ntpkey_iff_</span><kbd>hostname</kbd> 877in the keys directory. 878<br><dt><code>leap</code> <kbd>file</kbd><dd>Specifies the location of the optional leapsecond file. 879This overrides the link 880<span class="file">ntpkey_leap</span> 881in the keys directory. 882<br><dt><code>mvpar</code> <kbd>file</kbd><dd>Specifies the location of the optional MV parameters file. 883This 884overrides the link 885<span class="file">ntpkey_mv_</span><kbd>hostname</kbd> 886in the keys directory. 887<br><dt><code>pw</code> <kbd>password</kbd><dd>Specifies the password to decrypt files containing private keys and 888identity parameters. 889This is required only if these files have been 890encrypted. 891<br><dt><code>randfile</code> <kbd>file</kbd><dd>Specifies the location of the random seed file used by the OpenSSL 892library. 893The defaults are described in the main text above. 894<br><dt><code>sign</code> <kbd>file</kbd><dd>Specifies the location of the optional sign key file. 895This overrides 896the link 897<span class="file">ntpkey_sign_</span><kbd>hostname</kbd> 898in the keys directory. 899If this file is 900not found, the host key is also the sign key. 901</dl> 902 <br><dt><code>keys</code> <kbd>keyfile</kbd><dd>Specifies the complete path and location of the MD5 key file 903containing the keys and key identifiers used by 904<code>ntpd(1ntpdmdoc)</code>, 905<code>ntpq(1ntpqmdoc)</code> 906and 907<code>ntpdc(1ntpdcmdoc)</code> 908when operating with symmetric key cryptography. 909This is the same operation as the 910<code>-k</code> 911command line option. 912<br><dt><code>keysdir</code> <kbd>path</kbd><dd>This command specifies the default directory path for 913cryptographic keys, parameters and certificates. 914The default is 915<span class="file">/usr/local/etc/</span>. 916<br><dt><code>requestkey</code> <kbd>key</kbd><dd>Specifies the key identifier to use with the 917<code>ntpdc(1ntpdcmdoc)</code> 918utility program, which uses a 919proprietary protocol specific to this implementation of 920<code>ntpd(1ntpdmdoc)</code>. 921The 922<kbd>key</kbd> 923argument is a key identifier 924for the trusted key, where the value can be in the range 1 to 92565,534, inclusive. 926<br><dt><code>revoke</code> <kbd>logsec</kbd><dd>Specifies the interval between re-randomization of certain 927cryptographic values used by the Autokey scheme, as a power of 2 in 928seconds. 929These values need to be updated frequently in order to 930deflect brute-force attacks on the algorithms of the scheme; 931however, updating some values is a relatively expensive operation. 932The default interval is 16 (65,536 s or about 18 hours). 933For poll 934intervals above the specified interval, the values will be updated 935for every message sent. 936<br><dt><code>trustedkey</code> <kbd>key</kbd> <kbd>...</kbd><dd>Specifies the key identifiers which are trusted for the 937purposes of authenticating peers with symmetric key cryptography, 938as well as keys used by the 939<code>ntpq(1ntpqmdoc)</code> 940and 941<code>ntpdc(1ntpdcmdoc)</code> 942programs. 943The authentication procedures require that both the local 944and remote servers share the same key and key identifier for this 945purpose, although different keys can be used with different 946servers. 947The 948<kbd>key</kbd> 949arguments are 32-bit unsigned 950integers with values from 1 to 65,534. 951</dl> 952 953<h5 class="subsubsection">Error Codes</h5> 954 955<p>The following error codes are reported via the NTP control 956and monitoring protocol trap mechanism. 957 <dl> 958<dt>101<dd>(bad field format or length) 959The packet has invalid version, length or format. 960<br><dt>102<dd>(bad timestamp) 961The packet timestamp is the same or older than the most recent received. 962This could be due to a replay or a server clock time step. 963<br><dt>103<dd>(bad filestamp) 964The packet filestamp is the same or older than the most recent received. 965This could be due to a replay or a key file generation error. 966<br><dt>104<dd>(bad or missing public key) 967The public key is missing, has incorrect format or is an unsupported type. 968<br><dt>105<dd>(unsupported digest type) 969The server requires an unsupported digest/signature scheme. 970<br><dt>106<dd>(mismatched digest types) 971Not used. 972<br><dt>107<dd>(bad signature length) 973The signature length does not match the current public key. 974<br><dt>108<dd>(signature not verified) 975The message fails the signature check. 976It could be bogus or signed by a 977different private key. 978<br><dt>109<dd>(certificate not verified) 979The certificate is invalid or signed with the wrong key. 980<br><dt>110<dd>(certificate not verified) 981The certificate is not yet valid or has expired or the signature could not 982be verified. 983<br><dt>111<dd>(bad or missing cookie) 984The cookie is missing, corrupted or bogus. 985<br><dt>112<dd>(bad or missing leapseconds table) 986The leapseconds table is missing, corrupted or bogus. 987<br><dt>113<dd>(bad or missing certificate) 988The certificate is missing, corrupted or bogus. 989<br><dt>114<dd>(bad or missing identity) 990The identity key is missing, corrupt or bogus. 991</dl> 992 <div class="node"> 993<p><hr> 994<a name="Monitoring-Support"></a> 995<br> 996</div> 997 998<h4 class="subsection">Monitoring Support</h4> 999 1000<p><code>ntpd(1ntpdmdoc)</code> 1001includes a comprehensive monitoring facility suitable 1002for continuous, long term recording of server and client 1003timekeeping performance. 1004See the 1005<code>statistics</code> 1006command below 1007for a listing and example of each type of statistics currently 1008supported. 1009Statistic files are managed using file generation sets 1010and scripts in the 1011<span class="file">./scripts</span> 1012directory of this distribution. 1013Using 1014these facilities and 1015<span class="sc">unix</span> 1016<code>cron(8)</code> 1017jobs, the data can be 1018automatically summarized and archived for retrospective analysis. 1019 1020<h5 class="subsubsection">Monitoring Commands</h5> 1021 1022 <dl> 1023<dt><code>statistics</code> <kbd>name</kbd> <kbd>...</kbd><dd>Enables writing of statistics records. 1024Currently, eight kinds of 1025<kbd>name</kbd> 1026statistics are supported. 1027 <dl> 1028<dt><code>clockstats</code><dd>Enables recording of clock driver statistics information. 1029Each update 1030received from a clock driver appends a line of the following form to 1031the file generation set named 1032<code>clockstats</code>: 1033<pre class="verbatim"> 1034 49213 525.624 127.127.4.1 93 226 00:08:29.606 D 1035 </pre> 1036 1037 <p>The first two fields show the date (Modified Julian Day) and time 1038(seconds and fraction past UTC midnight). 1039The next field shows the 1040clock address in dotted-quad notation. 1041The final field shows the last 1042timecode received from the clock in decoded ASCII format, where 1043meaningful. 1044In some clock drivers a good deal of additional information 1045can be gathered and displayed as well. 1046See information specific to each 1047clock for further details. 1048<br><dt><code>cryptostats</code><dd>This option requires the OpenSSL cryptographic software library. 1049It 1050enables recording of cryptographic public key protocol information. 1051Each message received by the protocol module appends a line of the 1052following form to the file generation set named 1053<code>cryptostats</code>: 1054<pre class="verbatim"> 1055 49213 525.624 127.127.4.1 message 1056 </pre> 1057 1058 <p>The first two fields show the date (Modified Julian Day) and time 1059(seconds and fraction past UTC midnight). 1060The next field shows the peer 1061address in dotted-quad notation, The final message field includes the 1062message type and certain ancillary information. 1063See the 1064<a href="#Authentication-Options">Authentication Options</a> 1065section for further information. 1066<br><dt><code>loopstats</code><dd>Enables recording of loop filter statistics information. 1067Each 1068update of the local clock outputs a line of the following form to 1069the file generation set named 1070<code>loopstats</code>: 1071<pre class="verbatim"> 1072 50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806 1073 </pre> 1074 1075 <p>The first two fields show the date (Modified Julian Day) and 1076time (seconds and fraction past UTC midnight). 1077The next five fields 1078show time offset (seconds), frequency offset (parts per million - 1079PPM), RMS jitter (seconds), Allan deviation (PPM) and clock 1080discipline time constant. 1081<br><dt><code>peerstats</code><dd>Enables recording of peer statistics information. 1082This includes 1083statistics records of all peers of a NTP server and of special 1084signals, where present and configured. 1085Each valid update appends a 1086line of the following form to the current element of a file 1087generation set named 1088<code>peerstats</code>: 1089<pre class="verbatim"> 1090 48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674 1091 </pre> 1092 1093 <p>The first two fields show the date (Modified Julian Day) and 1094time (seconds and fraction past UTC midnight). 1095The next two fields 1096show the peer address in dotted-quad notation and status, 1097respectively. 1098The status field is encoded in hex in the format 1099described in Appendix A of the NTP specification RFC 1305. 1100The final four fields show the offset, 1101delay, dispersion and RMS jitter, all in seconds. 1102<br><dt><code>rawstats</code><dd>Enables recording of raw-timestamp statistics information. 1103This 1104includes statistics records of all peers of a NTP server and of 1105special signals, where present and configured. 1106Each NTP message 1107received from a peer or clock driver appends a line of the 1108following form to the file generation set named 1109<code>rawstats</code>: 1110<pre class="verbatim"> 1111 50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000 1112 </pre> 1113 1114 <p>The first two fields show the date (Modified Julian Day) and 1115time (seconds and fraction past UTC midnight). 1116The next two fields 1117show the remote peer or clock address followed by the local address 1118in dotted-quad notation. 1119The final four fields show the originate, 1120receive, transmit and final NTP timestamps in order. 1121The timestamp 1122values are as received and before processing by the various data 1123smoothing and mitigation algorithms. 1124<br><dt><code>sysstats</code><dd>Enables recording of ntpd statistics counters on a periodic basis. 1125Each 1126hour a line of the following form is appended to the file generation 1127set named 1128<code>sysstats</code>: 1129<pre class="verbatim"> 1130 50928 2132.543 36000 81965 0 9546 56 71793 512 540 10 147 1131 </pre> 1132 1133 <p>The first two fields show the date (Modified Julian Day) and time 1134(seconds and fraction past UTC midnight). 1135The remaining ten fields show 1136the statistics counter values accumulated since the last generated 1137line. 1138 <dl> 1139<dt>Time since restart <code>36000</code><dd>Time in hours since the system was last rebooted. 1140<br><dt>Packets received <code>81965</code><dd>Total number of packets received. 1141<br><dt>Packets processed <code>0</code><dd>Number of packets received in response to previous packets sent 1142<br><dt>Current version <code>9546</code><dd>Number of packets matching the current NTP version. 1143<br><dt>Previous version <code>56</code><dd>Number of packets matching the previous NTP version. 1144<br><dt>Bad version <code>71793</code><dd>Number of packets matching neither NTP version. 1145<br><dt>Access denied <code>512</code><dd>Number of packets denied access for any reason. 1146<br><dt>Bad length or format <code>540</code><dd>Number of packets with invalid length, format or port number. 1147<br><dt>Bad authentication <code>10</code><dd>Number of packets not verified as authentic. 1148<br><dt>Rate exceeded <code>147</code><dd>Number of packets discarded due to rate limitation. 1149</dl> 1150 <br><dt><code>statsdir</code> <kbd>directory_path</kbd><dd>Indicates the full path of a directory where statistics files 1151should be created (see below). 1152This keyword allows 1153the (otherwise constant) 1154<code>filegen</code> 1155filename prefix to be modified for file generation sets, which 1156is useful for handling statistics logs. 1157<br><dt><code>filegen</code> <kbd>name</kbd> <code>[file </code><kbd>filename</kbd><code>]</code> <code>[type </code><kbd>typename</kbd><code>]</code> <code>[link | nolink]</code> <code>[enable | disable]</code><dd>Configures setting of generation file set name. 1158Generation 1159file sets provide a means for handling files that are 1160continuously growing during the lifetime of a server. 1161Server statistics are a typical example for such files. 1162Generation file sets provide access to a set of files used 1163to store the actual data. 1164At any time at most one element 1165of the set is being written to. 1166The type given specifies 1167when and how data will be directed to a new element of the set. 1168This way, information stored in elements of a file set 1169that are currently unused are available for administrational 1170operations without the risk of disturbing the operation of ntpd. 1171(Most important: they can be removed to free space for new data 1172produced.) 1173 1174 <p>Note that this command can be sent from the 1175<code>ntpdc(1ntpdcmdoc)</code> 1176program running at a remote location. 1177 <dl> 1178<dt><code>name</code><dd>This is the type of the statistics records, as shown in the 1179<code>statistics</code> 1180command. 1181<br><dt><code>file</code> <kbd>filename</kbd><dd>This is the file name for the statistics records. 1182Filenames of set 1183members are built from three concatenated elements 1184<code>prefix</code>, 1185<code>filename</code> 1186and 1187<code>suffix</code>: 1188 <dl> 1189<dt><code>prefix</code><dd>This is a constant filename path. 1190It is not subject to 1191modifications via the 1192<kbd>filegen</kbd> 1193option. 1194It is defined by the 1195server, usually specified as a compile-time constant. 1196It may, 1197however, be configurable for individual file generation sets 1198via other commands. 1199For example, the prefix used with 1200<kbd>loopstats</kbd> 1201and 1202<kbd>peerstats</kbd> 1203generation can be configured using the 1204<kbd>statsdir</kbd> 1205option explained above. 1206<br><dt><code>filename</code><dd>This string is directly concatenated to the prefix mentioned 1207above (no intervening 1208/). 1209This can be modified using 1210the file argument to the 1211<kbd>filegen</kbd> 1212statement. 1213No 1214<span class="file">..</span> 1215elements are 1216allowed in this component to prevent filenames referring to 1217parts outside the filesystem hierarchy denoted by 1218<kbd>prefix</kbd>. 1219<br><dt><code>suffix</code><dd>This part is reflects individual elements of a file set. 1220It is 1221generated according to the type of a file set. 1222</dl> 1223 <br><dt><code>type</code> <kbd>typename</kbd><dd>A file generation set is characterized by its type. 1224The following 1225types are supported: 1226 <dl> 1227<dt><code>none</code><dd>The file set is actually a single plain file. 1228<br><dt><code>pid</code><dd>One element of file set is used per incarnation of a ntpd 1229server. 1230This type does not perform any changes to file set 1231members during runtime, however it provides an easy way of 1232separating files belonging to different 1233<code>ntpd(1ntpdmdoc)</code> 1234server incarnations. 1235The set member filename is built by appending a 1236. 1237to concatenated 1238<kbd>prefix</kbd> 1239and 1240<kbd>filename</kbd> 1241strings, and 1242appending the decimal representation of the process ID of the 1243<code>ntpd(1ntpdmdoc)</code> 1244server process. 1245<br><dt><code>day</code><dd>One file generation set element is created per day. 1246A day is 1247defined as the period between 00:00 and 24:00 UTC. 1248The file set 1249member suffix consists of a 1250. 1251and a day specification in 1252the form 1253<code>YYYYMMdd</code>. 1254<code>YYYY</code> 1255is a 4-digit year number (e.g., 1992). 1256<code>MM</code> 1257is a two digit month number. 1258<code>dd</code> 1259is a two digit day number. 1260Thus, all information written at 10 December 1992 would end up 1261in a file named 1262<kbd>prefix</kbd> 1263<kbd>filename</kbd>.19921210. 1264<br><dt><code>week</code><dd>Any file set member contains data related to a certain week of 1265a year. 1266The term week is defined by computing day-of-year 1267modulo 7. 1268Elements of such a file generation set are 1269distinguished by appending the following suffix to the file set 1270filename base: A dot, a 4-digit year number, the letter 1271<code>W</code>, 1272and a 2-digit week number. 1273For example, information from January, 127410th 1992 would end up in a file with suffix 1275.No . Ns Ar 1992W1 . 1276<br><dt><code>month</code><dd>One generation file set element is generated per month. 1277The 1278file name suffix consists of a dot, a 4-digit year number, and 1279a 2-digit month. 1280<br><dt><code>year</code><dd>One generation file element is generated per year. 1281The filename 1282suffix consists of a dot and a 4 digit year number. 1283<br><dt><code>age</code><dd>This type of file generation sets changes to a new element of 1284the file set every 24 hours of server operation. 1285The filename 1286suffix consists of a dot, the letter 1287<code>a</code>, 1288and an 8-digit number. 1289This number is taken to be the number of seconds the server is 1290running at the start of the corresponding 24-hour period. 1291Information is only written to a file generation by specifying 1292<code>enable</code>; 1293output is prevented by specifying 1294<code>disable</code>. 1295</dl> 1296 <br><dt><code>link</code> | <code>nolink</code><dd>It is convenient to be able to access the current element of a file 1297generation set by a fixed name. 1298This feature is enabled by 1299specifying 1300<code>link</code> 1301and disabled using 1302<code>nolink</code>. 1303If link is specified, a 1304hard link from the current file set element to a file without 1305suffix is created. 1306When there is already a file with this name and 1307the number of links of this file is one, it is renamed appending a 1308dot, the letter 1309<code>C</code>, 1310and the pid of the ntpd server process. 1311When the 1312number of links is greater than one, the file is unlinked. 1313This 1314allows the current file to be accessed by a constant name. 1315<br><dt><code>enable</code> <code>|</code> <code>disable</code><dd>Enables or disables the recording function. 1316</dl> 1317 </dl> 1318 </dl> 1319<div class="node"> 1320<p><hr> 1321<a name="Access-Control-Support"></a> 1322<br> 1323</div> 1324 1325<h4 class="subsection">Access Control Support</h4> 1326 1327<p>The 1328<code>ntpd(1ntpdmdoc)</code> 1329daemon implements a general purpose address/mask based restriction 1330list. 1331The list contains address/match entries sorted first 1332by increasing address values and and then by increasing mask values. 1333A match occurs when the bitwise AND of the mask and the packet 1334source address is equal to the bitwise AND of the mask and 1335address in the list. 1336The list is searched in order with the 1337last match found defining the restriction flags associated 1338with the entry. 1339Additional information and examples can be found in the 1340"Notes on Configuring NTP and Setting up a NTP Subnet" 1341page 1342(available as part of the HTML documentation 1343provided in 1344<span class="file">/usr/share/doc/ntp</span>). 1345 1346 <p>The restriction facility was implemented in conformance 1347with the access policies for the original NSFnet backbone 1348time servers. 1349Later the facility was expanded to deflect 1350cryptographic and clogging attacks. 1351While this facility may 1352be useful for keeping unwanted or broken or malicious clients 1353from congesting innocent servers, it should not be considered 1354an alternative to the NTP authentication facilities. 1355Source address based restrictions are easily circumvented 1356by a determined cracker. 1357 1358 <p>Clients can be denied service because they are explicitly 1359included in the restrict list created by the restrict command 1360or implicitly as the result of cryptographic or rate limit 1361violations. 1362Cryptographic violations include certificate 1363or identity verification failure; rate limit violations generally 1364result from defective NTP implementations that send packets 1365at abusive rates. 1366Some violations cause denied service 1367only for the offending packet, others cause denied service 1368for a timed period and others cause the denied service for 1369an indefinate period. 1370When a client or network is denied access 1371for an indefinate period, the only way at present to remove 1372the restrictions is by restarting the server. 1373 1374<h5 class="subsubsection">The Kiss-of-Death Packet</h5> 1375 1376<p>Ordinarily, packets denied service are simply dropped with no 1377further action except incrementing statistics counters. 1378Sometimes a 1379more proactive response is needed, such as a server message that 1380explicitly requests the client to stop sending and leave a message 1381for the system operator. 1382A special packet format has been created 1383for this purpose called the "kiss-of-death" (KoD) packet. 1384KoD packets have the leap bits set unsynchronized and stratum set 1385to zero and the reference identifier field set to a four-byte 1386ASCII code. 1387If the 1388<code>noserve</code> 1389or 1390<code>notrust</code> 1391flag of the matching restrict list entry is set, 1392the code is "DENY"; if the 1393<code>limited</code> 1394flag is set and the rate limit 1395is exceeded, the code is "RATE". 1396Finally, if a cryptographic violation occurs, the code is "CRYP". 1397 1398 <p>A client receiving a KoD performs a set of sanity checks to 1399minimize security exposure, then updates the stratum and 1400reference identifier peer variables, sets the access 1401denied (TEST4) bit in the peer flash variable and sends 1402a message to the log. 1403As long as the TEST4 bit is set, 1404the client will send no further packets to the server. 1405The only way at present to recover from this condition is 1406to restart the protocol at both the client and server. 1407This 1408happens automatically at the client when the association times out. 1409It will happen at the server only if the server operator cooperates. 1410 1411<h5 class="subsubsection">Access Control Commands</h5> 1412 1413 <dl> 1414<dt><code>discard</code> <code>[average </code><kbd>avg</kbd><code>]</code> <code>[minimum </code><kbd>min</kbd><code>]</code> <code>[monitor </code><kbd>prob</kbd><code>]</code><dd>Set the parameters of the 1415<code>limited</code> 1416facility which protects the server from 1417client abuse. 1418The 1419<code>average</code> 1420subcommand specifies the minimum average packet 1421spacing, while the 1422<code>minimum</code> 1423subcommand specifies the minimum packet spacing. 1424Packets that violate these minima are discarded 1425and a kiss-o'-death packet returned if enabled. 1426The default 1427minimum average and minimum are 5 and 2, respectively. 1428The monitor subcommand specifies the probability of discard 1429for packets that overflow the rate-control window. 1430<br><dt><code>restrict</code> <code>address</code> <code>[mask </code><kbd>mask</kbd><code>]</code> <code>[</code><kbd>flag</kbd> <kbd>...</kbd><code>]</code><dd>The 1431<kbd>address</kbd> 1432argument expressed in 1433dotted-quad form is the address of a host or network. 1434Alternatively, the 1435<kbd>address</kbd> 1436argument can be a valid host DNS name. 1437The 1438<kbd>mask</kbd> 1439argument expressed in dotted-quad form defaults to 1440<code>255.255.255.255</code>, 1441meaning that the 1442<kbd>address</kbd> 1443is treated as the address of an individual host. 1444A default entry (address 1445<code>0.0.0.0</code>, 1446mask 1447<code>0.0.0.0</code>) 1448is always included and is always the first entry in the list. 1449Note that text string 1450<code>default</code>, 1451with no mask option, may 1452be used to indicate the default entry. 1453In the current implementation, 1454<code>flag</code> 1455always 1456restricts access, i.e., an entry with no flags indicates that free 1457access to the server is to be given. 1458The flags are not orthogonal, 1459in that more restrictive flags will often make less restrictive 1460ones redundant. 1461The flags can generally be classed into two 1462categories, those which restrict time service and those which 1463restrict informational queries and attempts to do run-time 1464reconfiguration of the server. 1465One or more of the following flags 1466may be specified: 1467 <dl> 1468<dt><code>ignore</code><dd>Deny packets of all kinds, including 1469<code>ntpq(1ntpqmdoc)</code> 1470and 1471<code>ntpdc(1ntpdcmdoc)</code> 1472queries. 1473<br><dt><code>kod</code><dd>If this flag is set when an access violation occurs, a kiss-o'-death 1474(KoD) packet is sent. 1475KoD packets are rate limited to no more than one 1476per second. 1477If another KoD packet occurs within one second after the 1478last one, the packet is dropped. 1479<br><dt><code>limited</code><dd>Deny service if the packet spacing violates the lower limits specified 1480in the discard command. 1481A history of clients is kept using the 1482monitoring capability of 1483<code>ntpd(1ntpdmdoc)</code>. 1484Thus, monitoring is always active as 1485long as there is a restriction entry with the 1486<code>limited</code> 1487flag. 1488<br><dt><code>lowpriotrap</code><dd>Declare traps set by matching hosts to be low priority. 1489The 1490number of traps a server can maintain is limited (the current limit 1491is 3). 1492Traps are usually assigned on a first come, first served 1493basis, with later trap requestors being denied service. 1494This flag 1495modifies the assignment algorithm by allowing low priority traps to 1496be overridden by later requests for normal priority traps. 1497<br><dt><code>nomodify</code><dd>Deny 1498<code>ntpq(1ntpqmdoc)</code> 1499and 1500<code>ntpdc(1ntpdcmdoc)</code> 1501queries which attempt to modify the state of the 1502server (i.e., run time reconfiguration). 1503Queries which return 1504information are permitted. 1505<br><dt><code>noquery</code><dd>Deny 1506<code>ntpq(1ntpqmdoc)</code> 1507and 1508<code>ntpdc(1ntpdcmdoc)</code> 1509queries. 1510Time service is not affected. 1511<br><dt><code>nopeer</code><dd>Deny packets which would result in mobilizing a new association. 1512This 1513includes broadcast and symmetric active packets when a configured 1514association does not exist. 1515It also includes 1516<code>pool</code> 1517associations, so if you want to use servers from a 1518<code>pool</code> 1519directive and also want to use 1520<code>nopeer</code> 1521by default, you'll want a 1522<code>restrict source ...</code> <code>line</code> <code>as</code> <code>well</code> <code>that</code> <code>does</code> 1523<br><dt>not<dd>include the 1524<code>nopeer</code> 1525directive. 1526<br><dt><code>noserve</code><dd>Deny all packets except 1527<code>ntpq(1ntpqmdoc)</code> 1528and 1529<code>ntpdc(1ntpdcmdoc)</code> 1530queries. 1531<br><dt><code>notrap</code><dd>Decline to provide mode 6 control message trap service to matching 1532hosts. 1533The trap service is a subsystem of the ntpdq control message 1534protocol which is intended for use by remote event logging programs. 1535<br><dt><code>notrust</code><dd>Deny service unless the packet is cryptographically authenticated. 1536<br><dt><code>ntpport</code><dd>This is actually a match algorithm modifier, rather than a 1537restriction flag. 1538Its presence causes the restriction entry to be 1539matched only if the source port in the packet is the standard NTP 1540UDP port (123). 1541Both 1542<code>ntpport</code> 1543and 1544<code>non-ntpport</code> 1545may 1546be specified. 1547The 1548<code>ntpport</code> 1549is considered more specific and 1550is sorted later in the list. 1551<br><dt><code>version</code><dd>Deny packets that do not match the current NTP version. 1552</dl> 1553 1554 <p>Default restriction list entries with the flags ignore, interface, 1555ntpport, for each of the local host's interface addresses are 1556inserted into the table at startup to prevent the server 1557from attempting to synchronize to its own time. 1558A default entry is also always present, though if it is 1559otherwise unconfigured; no flags are associated 1560with the default entry (i.e., everything besides your own 1561NTP server is unrestricted). 1562</dl> 1563<div class="node"> 1564<p><hr> 1565<a name="Automatic-NTP-Configuration-Options"></a> 1566<br> 1567</div> 1568 1569<h4 class="subsection">Automatic NTP Configuration Options</h4> 1570 1571<h5 class="subsubsection">Manycasting</h5> 1572 1573<p>Manycasting is a automatic discovery and configuration paradigm 1574new to NTPv4. 1575It is intended as a means for a multicast client 1576to troll the nearby network neighborhood to find cooperating 1577manycast servers, validate them using cryptographic means 1578and evaluate their time values with respect to other servers 1579that might be lurking in the vicinity. 1580The intended result is that each manycast client mobilizes 1581client associations with some number of the "best" 1582of the nearby manycast servers, yet automatically reconfigures 1583to sustain this number of servers should one or another fail. 1584 1585 <p>Note that the manycasting paradigm does not coincide 1586with the anycast paradigm described in RFC-1546, 1587which is designed to find a single server from a clique 1588of servers providing the same service. 1589The manycast paradigm is designed to find a plurality 1590of redundant servers satisfying defined optimality criteria. 1591 1592 <p>Manycasting can be used with either symmetric key 1593or public key cryptography. 1594The public key infrastructure (PKI) 1595offers the best protection against compromised keys 1596and is generally considered stronger, at least with relatively 1597large key sizes. 1598It is implemented using the Autokey protocol and 1599the OpenSSL cryptographic library available from 1600<code>http://www.openssl.org/</code>. 1601The library can also be used with other NTPv4 modes 1602as well and is highly recommended, especially for broadcast modes. 1603 1604 <p>A persistent manycast client association is configured 1605using the manycastclient command, which is similar to the 1606server command but with a multicast (IPv4 class 1607<code>D</code> 1608or IPv6 prefix 1609<code>FF</code>) 1610group address. 1611The IANA has designated IPv4 address 224.1.1.1 1612and IPv6 address FF05::101 (site local) for NTP. 1613When more servers are needed, it broadcasts manycast 1614client messages to this address at the minimum feasible rate 1615and minimum feasible time-to-live (TTL) hops, depending 1616on how many servers have already been found. 1617There can be as many manycast client associations 1618as different group address, each one serving as a template 1619for a future ephemeral unicast client/server association. 1620 1621 <p>Manycast servers configured with the 1622<code>manycastserver</code> 1623command listen on the specified group address for manycast 1624client messages. 1625Note the distinction between manycast client, 1626which actively broadcasts messages, and manycast server, 1627which passively responds to them. 1628If a manycast server is 1629in scope of the current TTL and is itself synchronized 1630to a valid source and operating at a stratum level equal 1631to or lower than the manycast client, it replies to the 1632manycast client message with an ordinary unicast server message. 1633 1634 <p>The manycast client receiving this message mobilizes 1635an ephemeral client/server association according to the 1636matching manycast client template, but only if cryptographically 1637authenticated and the server stratum is less than or equal 1638to the client stratum. 1639Authentication is explicitly required 1640and either symmetric key or public key (Autokey) can be used. 1641Then, the client polls the server at its unicast address 1642in burst mode in order to reliably set the host clock 1643and validate the source. 1644This normally results 1645in a volley of eight client/server at 2-s intervals 1646during which both the synchronization and cryptographic 1647protocols run concurrently. 1648Following the volley, 1649the client runs the NTP intersection and clustering 1650algorithms, which act to discard all but the "best" 1651associations according to stratum and synchronization 1652distance. 1653The surviving associations then continue 1654in ordinary client/server mode. 1655 1656 <p>The manycast client polling strategy is designed to reduce 1657as much as possible the volume of manycast client messages 1658and the effects of implosion due to near-simultaneous 1659arrival of manycast server messages. 1660The strategy is determined by the 1661<code>manycastclient</code>, 1662<code>tos</code> 1663and 1664<code>ttl</code> 1665configuration commands. 1666The manycast poll interval is 1667normally eight times the system poll interval, 1668which starts out at the 1669<code>minpoll</code> 1670value specified in the 1671<code>manycastclient</code>, 1672command and, under normal circumstances, increments to the 1673<code>maxpolll</code> 1674value specified in this command. 1675Initially, the TTL is 1676set at the minimum hops specified by the ttl command. 1677At each retransmission the TTL is increased until reaching 1678the maximum hops specified by this command or a sufficient 1679number client associations have been found. 1680Further retransmissions use the same TTL. 1681 1682 <p>The quality and reliability of the suite of associations 1683discovered by the manycast client is determined by the NTP 1684mitigation algorithms and the 1685<code>minclock</code> 1686and 1687<code>minsane</code> 1688values specified in the 1689<code>tos</code> 1690configuration command. 1691At least 1692<code>minsane</code> 1693candidate servers must be available and the mitigation 1694algorithms produce at least 1695<code>minclock</code> 1696survivors in order to synchronize the clock. 1697Byzantine agreement principles require at least four 1698candidates in order to correctly discard a single falseticker. 1699For legacy purposes, 1700<code>minsane</code> 1701defaults to 1 and 1702<code>minclock</code> 1703defaults to 3. 1704For manycast service 1705<code>minsane</code> 1706should be explicitly set to 4, assuming at least that 1707number of servers are available. 1708 1709 <p>If at least 1710<code>minclock</code> 1711servers are found, the manycast poll interval is immediately 1712set to eight times 1713<code>maxpoll</code>. 1714If less than 1715<code>minclock</code> 1716servers are found when the TTL has reached the maximum hops, 1717the manycast poll interval is doubled. 1718For each transmission 1719after that, the poll interval is doubled again until 1720reaching the maximum of eight times 1721<code>maxpoll</code>. 1722Further transmissions use the same poll interval and 1723TTL values. 1724Note that while all this is going on, 1725each client/server association found is operating normally 1726it the system poll interval. 1727 1728 <p>Administratively scoped multicast boundaries are normally 1729specified by the network router configuration and, 1730in the case of IPv6, the link/site scope prefix. 1731By default, the increment for TTL hops is 32 starting 1732from 31; however, the 1733<code>ttl</code> 1734configuration command can be 1735used to modify the values to match the scope rules. 1736 1737 <p>It is often useful to narrow the range of acceptable 1738servers which can be found by manycast client associations. 1739Because manycast servers respond only when the client 1740stratum is equal to or greater than the server stratum, 1741primary (stratum 1) servers fill find only primary servers 1742in TTL range, which is probably the most common objective. 1743However, unless configured otherwise, all manycast clients 1744in TTL range will eventually find all primary servers 1745in TTL range, which is probably not the most common 1746objective in large networks. 1747The 1748<code>tos</code> 1749command can be used to modify this behavior. 1750Servers with stratum below 1751<code>floor</code> 1752or above 1753<code>ceiling</code> 1754specified in the 1755<code>tos</code> 1756command are strongly discouraged during the selection 1757process; however, these servers may be temporally 1758accepted if the number of servers within TTL range is 1759less than 1760<code>minclock</code>. 1761 1762 <p>The above actions occur for each manycast client message, 1763which repeats at the designated poll interval. 1764However, once the ephemeral client association is mobilized, 1765subsequent manycast server replies are discarded, 1766since that would result in a duplicate association. 1767If during a poll interval the number of client associations 1768falls below 1769<code>minclock</code>, 1770all manycast client prototype associations are reset 1771to the initial poll interval and TTL hops and operation 1772resumes from the beginning. 1773It is important to avoid 1774frequent manycast client messages, since each one requires 1775all manycast servers in TTL range to respond. 1776The result could well be an implosion, either minor or major, 1777depending on the number of servers in range. 1778The recommended value for 1779<code>maxpoll</code> 1780is 12 (4,096 s). 1781 1782 <p>It is possible and frequently useful to configure a host 1783as both manycast client and manycast server. 1784A number of hosts configured this way and sharing a common 1785group address will automatically organize themselves 1786in an optimum configuration based on stratum and 1787synchronization distance. 1788For example, consider an NTP 1789subnet of two primary servers and a hundred or more 1790dependent clients. 1791With two exceptions, all servers 1792and clients have identical configuration files including both 1793<code>multicastclient</code> 1794and 1795<code>multicastserver</code> 1796commands using, for instance, multicast group address 1797239.1.1.1. 1798The only exception is that each primary server 1799configuration file must include commands for the primary 1800reference source such as a GPS receiver. 1801 1802 <p>The remaining configuration files for all secondary 1803servers and clients have the same contents, except for the 1804<code>tos</code> 1805command, which is specific for each stratum level. 1806For stratum 1 and stratum 2 servers, that command is 1807not necessary. 1808For stratum 3 and above servers the 1809<code>floor</code> 1810value is set to the intended stratum number. 1811Thus, all stratum 3 configuration files are identical, 1812all stratum 4 files are identical and so forth. 1813 1814 <p>Once operations have stabilized in this scenario, 1815the primary servers will find the primary reference source 1816and each other, since they both operate at the same 1817stratum (1), but not with any secondary server or client, 1818since these operate at a higher stratum. 1819The secondary 1820servers will find the servers at the same stratum level. 1821If one of the primary servers loses its GPS receiver, 1822it will continue to operate as a client and other clients 1823will time out the corresponding association and 1824re-associate accordingly. 1825 1826 <p>Some administrators prefer to avoid running 1827<code>ntpd(1ntpdmdoc)</code> 1828continuously and run either 1829<code>ntpdate(8)</code> 1830or 1831<code>ntpd(1ntpdmdoc)</code> 1832<code>-q</code> 1833as a cron job. 1834In either case the servers must be 1835configured in advance and the program fails if none are 1836available when the cron job runs. 1837A really slick 1838application of manycast is with 1839<code>ntpd(1ntpdmdoc)</code> 1840<code>-q</code>. 1841The program wakes up, scans the local landscape looking 1842for the usual suspects, selects the best from among 1843the rascals, sets the clock and then departs. 1844Servers do not have to be configured in advance and 1845all clients throughout the network can have the same 1846configuration file. 1847 1848<h5 class="subsubsection">Manycast Interactions with Autokey</h5> 1849 1850<p>Each time a manycast client sends a client mode packet 1851to a multicast group address, all manycast servers 1852in scope generate a reply including the host name 1853and status word. 1854The manycast clients then run 1855the Autokey protocol, which collects and verifies 1856all certificates involved. 1857Following the burst interval 1858all but three survivors are cast off, 1859but the certificates remain in the local cache. 1860It often happens that several complete signing trails 1861from the client to the primary servers are collected in this way. 1862 1863 <p>About once an hour or less often if the poll interval 1864exceeds this, the client regenerates the Autokey key list. 1865This is in general transparent in client/server mode. 1866However, about once per day the server private value 1867used to generate cookies is refreshed along with all 1868manycast client associations. 1869In this case all 1870cryptographic values including certificates is refreshed. 1871If a new certificate has been generated since 1872the last refresh epoch, it will automatically revoke 1873all prior certificates that happen to be in the 1874certificate cache. 1875At the same time, the manycast 1876scheme starts all over from the beginning and 1877the expanding ring shrinks to the minimum and increments 1878from there while collecting all servers in scope. 1879 1880<h5 class="subsubsection">Manycast Options</h5> 1881 1882 <dl> 1883<dt><code>tos</code> <code>[ceiling </code><kbd>ceiling</kbd><code> | cohort { 0 | 1 } | floor </code><kbd>floor</kbd><code> | minclock </code><kbd>minclock</kbd><code> | minsane </code><kbd>minsane</kbd><code>]</code><dd>This command affects the clock selection and clustering 1884algorithms. 1885It can be used to select the quality and 1886quantity of peers used to synchronize the system clock 1887and is most useful in manycast mode. 1888The variables operate 1889as follows: 1890 <dl> 1891<dt><code>ceiling</code> <kbd>ceiling</kbd><dd>Peers with strata above 1892<code>ceiling</code> 1893will be discarded if there are at least 1894<code>minclock</code> 1895peers remaining. 1896This value defaults to 15, but can be changed 1897to any number from 1 to 15. 1898<br><dt><code>cohort</code> <code>{0 | 1}</code><dd>This is a binary flag which enables (0) or disables (1) 1899manycast server replies to manycast clients with the same 1900stratum level. 1901This is useful to reduce implosions where 1902large numbers of clients with the same stratum level 1903are present. 1904The default is to enable these replies. 1905<br><dt><code>floor</code> <kbd>floor</kbd><dd>Peers with strata below 1906<code>floor</code> 1907will be discarded if there are at least 1908<code>minclock</code> 1909peers remaining. 1910This value defaults to 1, but can be changed 1911to any number from 1 to 15. 1912<br><dt><code>minclock</code> <kbd>minclock</kbd><dd>The clustering algorithm repeatedly casts out outlyer 1913associations until no more than 1914<code>minclock</code> 1915associations remain. 1916This value defaults to 3, 1917but can be changed to any number from 1 to the number of 1918configured sources. 1919<br><dt><code>minsane</code> <kbd>minsane</kbd><dd>This is the minimum number of candidates available 1920to the clock selection algorithm in order to produce 1921one or more truechimers for the clustering algorithm. 1922If fewer than this number are available, the clock is 1923undisciplined and allowed to run free. 1924The default is 1 1925for legacy purposes. 1926However, according to principles of 1927Byzantine agreement, 1928<code>minsane</code> 1929should be at least 4 in order to detect and discard 1930a single falseticker. 1931</dl> 1932 <br><dt><code>ttl</code> <kbd>hop</kbd> <kbd>...</kbd><dd>This command specifies a list of TTL values in increasing 1933order, up to 8 values can be specified. 1934In manycast mode these values are used in turn 1935in an expanding-ring search. 1936The default is eight 1937multiples of 32 starting at 31. 1938</dl> 1939<div class="node"> 1940<p><hr> 1941<a name="Reference-Clock-Support"></a> 1942<br> 1943</div> 1944 1945<h4 class="subsection">Reference Clock Support</h4> 1946 1947<p>The NTP Version 4 daemon supports some three dozen different radio, 1948satellite and modem reference clocks plus a special pseudo-clock 1949used for backup or when no other clock source is available. 1950Detailed descriptions of individual device drivers and options can 1951be found in the 1952"Reference Clock Drivers" 1953page 1954(available as part of the HTML documentation 1955provided in 1956<span class="file">/usr/share/doc/ntp</span>). 1957Additional information can be found in the pages linked 1958there, including the 1959"Debugging Hints for Reference Clock Drivers" 1960and 1961"How To Write a Reference Clock Driver" 1962pages 1963(available as part of the HTML documentation 1964provided in 1965<span class="file">/usr/share/doc/ntp</span>). 1966In addition, support for a PPS 1967signal is available as described in the 1968"Pulse-per-second (PPS) Signal Interfacing" 1969page 1970(available as part of the HTML documentation 1971provided in 1972<span class="file">/usr/share/doc/ntp</span>). 1973Many 1974drivers support special line discipline/streams modules which can 1975significantly improve the accuracy using the driver. 1976These are 1977described in the 1978"Line Disciplines and Streams Drivers" 1979page 1980(available as part of the HTML documentation 1981provided in 1982<span class="file">/usr/share/doc/ntp</span>). 1983 1984 <p>A reference clock will generally (though not always) be a radio 1985timecode receiver which is synchronized to a source of standard 1986time such as the services offered by the NRC in Canada and NIST and 1987USNO in the US. 1988The interface between the computer and the timecode 1989receiver is device dependent, but is usually a serial port. 1990A 1991device driver specific to each reference clock must be selected and 1992compiled in the distribution; however, most common radio, satellite 1993and modem clocks are included by default. 1994Note that an attempt to 1995configure a reference clock when the driver has not been compiled 1996or the hardware port has not been appropriately configured results 1997in a scalding remark to the system log file, but is otherwise non 1998hazardous. 1999 2000 <p>For the purposes of configuration, 2001<code>ntpd(1ntpdmdoc)</code> 2002treats 2003reference clocks in a manner analogous to normal NTP peers as much 2004as possible. 2005Reference clocks are identified by a syntactically 2006correct but invalid IP address, in order to distinguish them from 2007normal NTP peers. 2008Reference clock addresses are of the form 2009<code>127.127.</code><kbd>t</kbd>.<kbd>u</kbd>, 2010where 2011<kbd>t</kbd> 2012is an integer 2013denoting the clock type and 2014<kbd>u</kbd> 2015indicates the unit 2016number in the range 0-3. 2017While it may seem overkill, it is in fact 2018sometimes useful to configure multiple reference clocks of the same 2019type, in which case the unit numbers must be unique. 2020 2021 <p>The 2022<code>server</code> 2023command is used to configure a reference 2024clock, where the 2025<kbd>address</kbd> 2026argument in that command 2027is the clock address. 2028The 2029<code>key</code>, 2030<code>version</code> 2031and 2032<code>ttl</code> 2033options are not used for reference clock support. 2034The 2035<code>mode</code> 2036option is added for reference clock support, as 2037described below. 2038The 2039<code>prefer</code> 2040option can be useful to 2041persuade the server to cherish a reference clock with somewhat more 2042enthusiasm than other reference clocks or peers. 2043Further 2044information on this option can be found in the 2045"Mitigation Rules and the prefer Keyword" 2046(available as part of the HTML documentation 2047provided in 2048<span class="file">/usr/share/doc/ntp</span>) 2049page. 2050The 2051<code>minpoll</code> 2052and 2053<code>maxpoll</code> 2054options have 2055meaning only for selected clock drivers. 2056See the individual clock 2057driver document pages for additional information. 2058 2059 <p>The 2060<code>fudge</code> 2061command is used to provide additional 2062information for individual clock drivers and normally follows 2063immediately after the 2064<code>server</code> 2065command. 2066The 2067<kbd>address</kbd> 2068argument specifies the clock address. 2069The 2070<code>refid</code> 2071and 2072<code>stratum</code> 2073options can be used to 2074override the defaults for the device. 2075There are two optional 2076device-dependent time offsets and four flags that can be included 2077in the 2078<code>fudge</code> 2079command as well. 2080 2081 <p>The stratum number of a reference clock is by default zero. 2082Since the 2083<code>ntpd(1ntpdmdoc)</code> 2084daemon adds one to the stratum of each 2085peer, a primary server ordinarily displays an external stratum of 2086one. 2087In order to provide engineered backups, it is often useful to 2088specify the reference clock stratum as greater than zero. 2089The 2090<code>stratum</code> 2091option is used for this purpose. 2092Also, in cases 2093involving both a reference clock and a pulse-per-second (PPS) 2094discipline signal, it is useful to specify the reference clock 2095identifier as other than the default, depending on the driver. 2096The 2097<code>refid</code> 2098option is used for this purpose. 2099Except where noted, 2100these options apply to all clock drivers. 2101 2102<h5 class="subsubsection">Reference Clock Commands</h5> 2103 2104 <dl> 2105<dt><code>server</code> <code>127.127.</code><kbd>t</kbd>.<kbd>u</kbd> <code>[prefer]</code> <code>[mode </code><kbd>int</kbd><code>]</code> <code>[minpoll </code><kbd>int</kbd><code>]</code> <code>[maxpoll </code><kbd>int</kbd><code>]</code><dd>This command can be used to configure reference clocks in 2106special ways. 2107The options are interpreted as follows: 2108 <dl> 2109<dt><code>prefer</code><dd>Marks the reference clock as preferred. 2110All other things being 2111equal, this host will be chosen for synchronization among a set of 2112correctly operating hosts. 2113See the 2114"Mitigation Rules and the prefer Keyword" 2115page 2116(available as part of the HTML documentation 2117provided in 2118<span class="file">/usr/share/doc/ntp</span>) 2119for further information. 2120<br><dt><code>mode</code> <kbd>int</kbd><dd>Specifies a mode number which is interpreted in a 2121device-specific fashion. 2122For instance, it selects a dialing 2123protocol in the ACTS driver and a device subtype in the 2124parse 2125drivers. 2126<br><dt><code>minpoll</code> <kbd>int</kbd><br><dt><code>maxpoll</code> <kbd>int</kbd><dd>These options specify the minimum and maximum polling interval 2127for reference clock messages, as a power of 2 in seconds 2128For 2129most directly connected reference clocks, both 2130<code>minpoll</code> 2131and 2132<code>maxpoll</code> 2133default to 6 (64 s). 2134For modem reference clocks, 2135<code>minpoll</code> 2136defaults to 10 (17.1 m) and 2137<code>maxpoll</code> 2138defaults to 14 (4.5 h). 2139The allowable range is 4 (16 s) to 17 (36.4 h) inclusive. 2140</dl> 2141 <br><dt><code>fudge</code> <code>127.127.</code><kbd>t</kbd>.<kbd>u</kbd> <code>[time1 </code><kbd>sec</kbd><code>]</code> <code>[time2 </code><kbd>sec</kbd><code>]</code> <code>[stratum </code><kbd>int</kbd><code>]</code> <code>[refid </code><kbd>string</kbd><code>]</code> <code>[mode </code><kbd>int</kbd><code>]</code> <code>[flag1 0 | 1]</code> <code>[flag2 0 | 1]</code> <code>[flag3 0 | 1]</code> <code>[flag4 0 | 1]</code><dd>This command can be used to configure reference clocks in 2142special ways. 2143It must immediately follow the 2144<code>server</code> 2145command which configures the driver. 2146Note that the same capability 2147is possible at run time using the 2148<code>ntpdc(1ntpdcmdoc)</code> 2149program. 2150The options are interpreted as 2151follows: 2152 <dl> 2153<dt><code>time1</code> <kbd>sec</kbd><dd>Specifies a constant to be added to the time offset produced by 2154the driver, a fixed-point decimal number in seconds. 2155This is used 2156as a calibration constant to adjust the nominal time offset of a 2157particular clock to agree with an external standard, such as a 2158precision PPS signal. 2159It also provides a way to correct a 2160systematic error or bias due to serial port or operating system 2161latencies, different cable lengths or receiver internal delay. 2162The 2163specified offset is in addition to the propagation delay provided 2164by other means, such as internal DIPswitches. 2165Where a calibration 2166for an individual system and driver is available, an approximate 2167correction is noted in the driver documentation pages. 2168Note: in order to facilitate calibration when more than one 2169radio clock or PPS signal is supported, a special calibration 2170feature is available. 2171It takes the form of an argument to the 2172<code>enable</code> 2173command described in 2174<a href="#Miscellaneous-Options">Miscellaneous Options</a> 2175page and operates as described in the 2176"Reference Clock Drivers" 2177page 2178(available as part of the HTML documentation 2179provided in 2180<span class="file">/usr/share/doc/ntp</span>). 2181<br><dt><code>time2</code> <kbd>secs</kbd><dd>Specifies a fixed-point decimal number in seconds, which is 2182interpreted in a driver-dependent way. 2183See the descriptions of 2184specific drivers in the 2185"Reference Clock Drivers" 2186page 2187(available as part of the HTML documentation 2188provided in 2189<span class="file">/usr/share/doc/ntp</span>). 2190<br><dt><code>stratum</code> <kbd>int</kbd><dd>Specifies the stratum number assigned to the driver, an integer 2191between 0 and 15. 2192This number overrides the default stratum number 2193ordinarily assigned by the driver itself, usually zero. 2194<br><dt><code>refid</code> <kbd>string</kbd><dd>Specifies an ASCII string of from one to four characters which 2195defines the reference identifier used by the driver. 2196This string 2197overrides the default identifier ordinarily assigned by the driver 2198itself. 2199<br><dt><code>mode</code> <kbd>int</kbd><dd>Specifies a mode number which is interpreted in a 2200device-specific fashion. 2201For instance, it selects a dialing 2202protocol in the ACTS driver and a device subtype in the 2203parse 2204drivers. 2205<br><dt><code>flag1</code> <code>0</code> <code>|</code> <code>1</code><br><dt><code>flag2</code> <code>0</code> <code>|</code> <code>1</code><br><dt><code>flag3</code> <code>0</code> <code>|</code> <code>1</code><br><dt><code>flag4</code> <code>0</code> <code>|</code> <code>1</code><dd>These four flags are used for customizing the clock driver. 2206The 2207interpretation of these values, and whether they are used at all, 2208is a function of the particular clock driver. 2209However, by 2210convention 2211<code>flag4</code> 2212is used to enable recording monitoring 2213data to the 2214<code>clockstats</code> 2215file configured with the 2216<code>filegen</code> 2217command. 2218Further information on the 2219<code>filegen</code> 2220command can be found in 2221<a href="#Monitoring-Options">Monitoring Options</a>. 2222</dl> 2223 </dl> 2224<div class="node"> 2225<p><hr> 2226<a name="Miscellaneous-Options"></a> 2227<br> 2228</div> 2229 2230<h4 class="subsection">Miscellaneous Options</h4> 2231 2232 <dl> 2233<dt><code>broadcastdelay</code> <kbd>seconds</kbd><dd>The broadcast and multicast modes require a special calibration 2234to determine the network delay between the local and remote 2235servers. 2236Ordinarily, this is done automatically by the initial 2237protocol exchanges between the client and server. 2238In some cases, 2239the calibration procedure may fail due to network or server access 2240controls, for example. 2241This command specifies the default delay to 2242be used under these circumstances. 2243Typically (for Ethernet), a 2244number between 0.003 and 0.007 seconds is appropriate. 2245The default 2246when this command is not used is 0.004 seconds. 2247<br><dt><code>calldelay</code> <kbd>delay</kbd><dd>This option controls the delay in seconds between the first and second 2248packets sent in burst or iburst mode to allow additional time for a modem 2249or ISDN call to complete. 2250<br><dt><code>driftfile</code> <kbd>driftfile</kbd><dd>This command specifies the complete path and name of the file used to 2251record the frequency of the local clock oscillator. 2252This is the same 2253operation as the 2254<code>-f</code> 2255command line option. 2256If the file exists, it is read at 2257startup in order to set the initial frequency and then updated once per 2258hour with the current frequency computed by the daemon. 2259If the file name is 2260specified, but the file itself does not exist, the starts with an initial 2261frequency of zero and creates the file when writing it for the first time. 2262If this command is not given, the daemon will always start with an initial 2263frequency of zero. 2264 2265 <p>The file format consists of a single line containing a single 2266floating point number, which records the frequency offset measured 2267in parts-per-million (PPM). 2268The file is updated by first writing 2269the current drift value into a temporary file and then renaming 2270this file to replace the old version. 2271This implies that 2272<code>ntpd(1ntpdmdoc)</code> 2273must have write permission for the directory the 2274drift file is located in, and that file system links, symbolic or 2275otherwise, should be avoided. 2276<br><dt><code>enable</code> <code>[auth | bclient | calibrate | kernel | mode7 | monitor | ntp | stats]</code><br><dt><code>disable</code> <code>[auth | bclient | calibrate | kernel | mode7 | monitor | ntp | stats]</code><dd>Provides a way to enable or disable various server options. 2277Flags not mentioned are unaffected. 2278Note that all of these flags 2279can be controlled remotely using the 2280<code>ntpdc(1ntpdcmdoc)</code> 2281utility program. 2282 <dl> 2283<dt><code>auth</code><dd>Enables the server to synchronize with unconfigured peers only if the 2284peer has been correctly authenticated using either public key or 2285private key cryptography. 2286The default for this flag is 2287<code>enable</code>. 2288<br><dt><code>bclient</code><dd>Enables the server to listen for a message from a broadcast or 2289multicast server, as in the 2290<code>multicastclient</code> 2291command with default 2292address. 2293The default for this flag is 2294<code>disable</code>. 2295<br><dt><code>calibrate</code><dd>Enables the calibrate feature for reference clocks. 2296The default for 2297this flag is 2298<code>disable</code>. 2299<br><dt><code>kernel</code><dd>Enables the kernel time discipline, if available. 2300The default for this 2301flag is 2302<code>enable</code> 2303if support is available, otherwise 2304<code>disable</code>. 2305<br><dt><code>mode7</code><dd>Enables processing of NTP mode 7 implementation-specific requests 2306which are used by the deprecated 2307<code>ntpdc(1ntpdcmdoc)</code> 2308program. 2309The default for this flag is disable. 2310This flag is excluded from runtime configuration using 2311<code>ntpq(1ntpqmdoc)</code>. 2312The 2313<code>ntpq(1ntpqmdoc)</code> 2314program provides the same capabilities as 2315<code>ntpdc(1ntpdcmdoc)</code> 2316using standard mode 6 requests. 2317<br><dt><code>monitor</code><dd>Enables the monitoring facility. 2318See the 2319<code>ntpdc(1ntpdcmdoc)</code> 2320program 2321and the 2322<code>monlist</code> 2323command or further information. 2324The 2325default for this flag is 2326<code>enable</code>. 2327<br><dt><code>ntp</code><dd>Enables time and frequency discipline. 2328In effect, this switch opens and 2329closes the feedback loop, which is useful for testing. 2330The default for 2331this flag is 2332<code>enable</code>. 2333<br><dt><code>stats</code><dd>Enables the statistics facility. 2334See the 2335<a href="#Monitoring-Options">Monitoring Options</a> 2336section for further information. 2337The default for this flag is 2338<code>disable</code>. 2339</dl> 2340 <br><dt><code>includefile</code> <kbd>includefile</kbd><dd>This command allows additional configuration commands 2341to be included from a separate file. 2342Include files may 2343be nested to a depth of five; upon reaching the end of any 2344include file, command processing resumes in the previous 2345configuration file. 2346This option is useful for sites that run 2347<code>ntpd(1ntpdmdoc)</code> 2348on multiple hosts, with (mostly) common options (e.g., a 2349restriction list). 2350<br><dt><code>logconfig</code> <kbd>configkeyword</kbd><dd>This command controls the amount and type of output written to 2351the system 2352<code>syslog(3)</code> 2353facility or the alternate 2354<code>logfile</code> 2355log file. 2356By default, all output is turned on. 2357All 2358<kbd>configkeyword</kbd> 2359keywords can be prefixed with 2360=, 2361+ 2362and 2363-, 2364where 2365= 2366sets the 2367<code>syslog(3)</code> 2368priority mask, 2369+ 2370adds and 2371- 2372removes 2373messages. 2374<code>syslog(3)</code> 2375messages can be controlled in four 2376classes 2377(<code>clock</code>, <code>peer</code>, <code>sys</code> and <code>sync</code>). 2378Within these classes four types of messages can be 2379controlled: informational messages 2380(<code>info</code>), 2381event messages 2382(<code>events</code>), 2383statistics messages 2384(<code>statistics</code>) 2385and 2386status messages 2387(<code>status</code>). 2388 2389 <p>Configuration keywords are formed by concatenating the message class with 2390the event class. 2391The 2392<code>all</code> 2393prefix can be used instead of a message class. 2394A 2395message class may also be followed by the 2396<code>all</code> 2397keyword to enable/disable all 2398messages of the respective message class.Thus, a minimal log configuration 2399could look like this: 2400<pre class="verbatim"> 2401 logconfig =syncstatus +sysevents 2402</pre> 2403 2404 <p>This would just list the synchronizations state of 2405<code>ntpd(1ntpdmdoc)</code> 2406and the major system events. 2407For a simple reference server, the 2408following minimum message configuration could be useful: 2409<pre class="verbatim"> 2410 logconfig =syncall +clockall 2411</pre> 2412 2413 <p>This configuration will list all clock information and 2414synchronization information. 2415All other events and messages about 2416peers, system events and so on is suppressed. 2417<br><dt><code>logfile</code> <kbd>logfile</kbd><dd>This command specifies the location of an alternate log file to 2418be used instead of the default system 2419<code>syslog(3)</code> 2420facility. 2421This is the same operation as the -l command line option. 2422<br><dt><code>setvar</code> <kbd>variable</kbd> <code>[default]</code><dd>This command adds an additional system variable. 2423These 2424variables can be used to distribute additional information such as 2425the access policy. 2426If the variable of the form 2427<code>name</code><code>=</code><kbd>value</kbd> 2428is followed by the 2429<code>default</code> 2430keyword, the 2431variable will be listed as part of the default system variables 2432(<code>rv</code> command)). 2433These additional variables serve 2434informational purposes only. 2435They are not related to the protocol 2436other that they can be listed. 2437The known protocol variables will 2438always override any variables defined via the 2439<code>setvar</code> 2440mechanism. 2441There are three special variables that contain the names 2442of all variable of the same group. 2443The 2444<code>sys_var_list</code> 2445holds 2446the names of all system variables. 2447The 2448<code>peer_var_list</code> 2449holds 2450the names of all peer variables and the 2451<code>clock_var_list</code> 2452holds the names of the reference clock variables. 2453<br><dt><code>tinker</code> <code>[allan </code><kbd>allan</kbd><code> | dispersion </code><kbd>dispersion</kbd><code> | freq </code><kbd>freq</kbd><code> | huffpuff </code><kbd>huffpuff</kbd><code> | panic </code><kbd>panic</kbd><code> | step </code><kbd>srep</kbd><code> | stepout </code><kbd>stepout</kbd><code>]</code><dd>This command can be used to alter several system variables in 2454very exceptional circumstances. 2455It should occur in the 2456configuration file before any other configuration options. 2457The 2458default values of these variables have been carefully optimized for 2459a wide range of network speeds and reliability expectations. 2460In 2461general, they interact in intricate ways that are hard to predict 2462and some combinations can result in some very nasty behavior. 2463Very 2464rarely is it necessary to change the default values; but, some 2465folks cannot resist twisting the knobs anyway and this command is 2466for them. 2467Emphasis added: twisters are on their own and can expect 2468no help from the support group. 2469 2470 <p>The variables operate as follows: 2471 <dl> 2472<dt><code>allan</code> <kbd>allan</kbd><dd>The argument becomes the new value for the minimum Allan 2473intercept, which is a parameter of the PLL/FLL clock discipline 2474algorithm. 2475The value in log2 seconds defaults to 7 (1024 s), which is also the lower 2476limit. 2477<br><dt><code>dispersion</code> <kbd>dispersion</kbd><dd>The argument becomes the new value for the dispersion increase rate, 2478normally .000015 s/s. 2479<br><dt><code>freq</code> <kbd>freq</kbd><dd>The argument becomes the initial value of the frequency offset in 2480parts-per-million. 2481This overrides the value in the frequency file, if 2482present, and avoids the initial training state if it is not. 2483<br><dt><code>huffpuff</code> <kbd>huffpuff</kbd><dd>The argument becomes the new value for the experimental 2484huff-n'-puff filter span, which determines the most recent interval 2485the algorithm will search for a minimum delay. 2486The lower limit is 2487900 s (15 m), but a more reasonable value is 7200 (2 hours). 2488There 2489is no default, since the filter is not enabled unless this command 2490is given. 2491<br><dt><code>panic</code> <kbd>panic</kbd><dd>The argument is the panic threshold, normally 1000 s. 2492If set to zero, 2493the panic sanity check is disabled and a clock offset of any value will 2494be accepted. 2495<br><dt><code>step</code> <kbd>step</kbd><dd>The argument is the step threshold, which by default is 0.128 s. 2496It can 2497be set to any positive number in seconds. 2498If set to zero, step 2499adjustments will never occur. 2500Note: The kernel time discipline is 2501disabled if the step threshold is set to zero or greater than the 2502default. 2503<br><dt><code>stepout</code> <kbd>stepout</kbd><dd>The argument is the stepout timeout, which by default is 900 s. 2504It can 2505be set to any positive number in seconds. 2506If set to zero, the stepout 2507pulses will not be suppressed. 2508</dl> 2509 <br><dt><code>rlimit</code> <code>[memlock </code><kbd>Nmegabytes</kbd><code> | stacksize </code><kbd>N4kPages</kbd><code> filenum </code><kbd>Nfiledescriptors</kbd><code>]</code><dd> 2510 <dl> 2511<dt><code>memlock</code> <kbd>Nmegabytes</kbd><dd>Specify the number of megabytes of memory that can be allocated. 2512Probably only available under Linux, this option is useful 2513when dropping root (the 2514<code>-i</code> 2515option). 2516The default is 32 megabytes. Setting this to zero will prevent any attemp to lock memory. 2517<br><dt><code>stacksize</code> <kbd>N4kPages</kbd><dd>Specifies the maximum size of the process stack on systems with the 2518<br><dt><code>filenum</code> <kbd>Nfiledescriptors</kbd><dd>Specifies the maximum number of file descriptors ntpd may have open at once. Defaults to the system default. 2519<code>mlockall()</code> 2520function. 2521Defaults to 50 4k pages (200 4k pages in OpenBSD). 2522</dl> 2523 <br><dt><code>trap</code> <kbd>host_address</kbd> <code>[port </code><kbd>port_number</kbd><code>]</code> <code>[interface </code><kbd>interface_address</kbd><code>]</code><dd>This command configures a trap receiver at the given host 2524address and port number for sending messages with the specified 2525local interface address. 2526If the port number is unspecified, a value 2527of 18447 is used. 2528If the interface address is not specified, the 2529message is sent with a source address of the local interface the 2530message is sent through. 2531Note that on a multihomed host the 2532interface used may vary from time to time with routing changes. 2533 2534 <p>The trap receiver will generally log event messages and other 2535information from the server in a log file. 2536While such monitor 2537programs may also request their own trap dynamically, configuring a 2538trap receiver will ensure that no messages are lost when the server 2539is started. 2540<br><dt><code>hop</code> <kbd>...</kbd><dd>This command specifies a list of TTL values in increasing order, up to 8 2541values can be specified. 2542In manycast mode these values are used in turn in 2543an expanding-ring search. 2544The default is eight multiples of 32 starting at 254531. 2546</dl> 2547 2548 <p>This section was generated by <strong>AutoGen</strong>, 2549using the <code>agtexi-cmd</code> template and the option descriptions for the <code>ntp.conf</code> program. 2550This software is released under the NTP license, <http://ntp.org/license>. 2551 2552<ul class="menu"> 2553<li><a accesskey="1" href="#ntp_002econf-Files">ntp.conf Files</a>: Files 2554<li><a accesskey="2" href="#ntp_002econf-See-Also">ntp.conf See Also</a>: See Also 2555<li><a accesskey="3" href="#ntp_002econf-Bugs">ntp.conf Bugs</a>: Bugs 2556<li><a accesskey="4" href="#ntp_002econf-Notes">ntp.conf Notes</a>: Notes 2557</ul> 2558 2559<div class="node"> 2560<p><hr> 2561<a name="ntp_002econf-Files"></a> 2562<br> 2563</div> 2564 2565<h4 class="subsection">ntp.conf Files</h4> 2566 2567 <dl> 2568<dt><span class="file">/etc/ntp.conf</span><dd>the default name of the configuration file 2569<br><dt><span class="file">ntp.keys</span><dd>private MD5 keys 2570<br><dt><span class="file">ntpkey</span><dd>RSA private key 2571<br><dt><span class="file">ntpkey_</span><kbd>host</kbd><dd>RSA public key 2572<br><dt><span class="file">ntp_dh</span><dd>Diffie-Hellman agreement parameters 2573</dl> 2574<div class="node"> 2575<p><hr> 2576<a name="ntp_002econf-See-Also"></a> 2577<br> 2578</div> 2579 2580<h4 class="subsection">ntp.conf See Also</h4> 2581 2582<p><code>ntpd(1ntpdmdoc)</code>, 2583<code>ntpdc(1ntpdcmdoc)</code>, 2584<code>ntpq(1ntpqmdoc)</code> 2585 2586 <p>In addition to the manual pages provided, 2587comprehensive documentation is available on the world wide web 2588at 2589<code>http://www.ntp.org/</code>. 2590A snapshot of this documentation is available in HTML format in 2591<span class="file">/usr/share/doc/ntp</span>. 2592<br> 2593 2594 <p><br> 2595David L. Mills, <em>Network Time Protocol (Version 4)</em>, RFC5905 2596<div class="node"> 2597<p><hr> 2598<a name="ntp_002econf-Bugs"></a> 2599<br> 2600</div> 2601 2602<h4 class="subsection">ntp.conf Bugs</h4> 2603 2604<p>The syntax checking is not picky; some combinations of 2605ridiculous and even hilarious options and modes may not be 2606detected. 2607 2608 <p>The 2609<span class="file">ntpkey_</span><kbd>host</kbd> 2610files are really digital 2611certificates. 2612These should be obtained via secure directory 2613services when they become universally available. 2614<div class="node"> 2615<p><hr> 2616<a name="ntp_002econf-Notes"></a> 2617<br> 2618</div> 2619 2620<h4 class="subsection">ntp.conf Notes</h4> 2621 2622<p>This document was derived from FreeBSD. 2623 2624</body></html> 2625 2626