ntp.conf(5) File Formats ntp.conf(5)

ntp.conf - فایل پیکربندی دیمن پروتکل زمان شبکه (NTP)

ntp.conf [--option-name] [--option-name value]

تمامی آرگومان‌ها باید گزینه باشند.

فایل پیکربندی ntp.conf در زمان راه‌اندازی اولیه توسط دیمن ntpd(1) خوانده می‌شود تا منابع همگام‌سازی، حالت‌ها و سایر اطلاعات مرتبط را مشخص کند. معمولاً در پوشه /etc نصب می‌شود، اما می‌تواند در مکان دیگری نیز نصب شود (گزینه خط فرمان -c دیمن را ببینید).

فرمت فایل مشابه سایر فایل‌های پیکربندی UNIX است. توضیحات با نویسه ‘#’ شروع شده و تا انتهای خط ادامه می‌یابند؛ خطوط خالی نادیده گرفته می‌شوند. دستورات پیکربندی شامل یک کلمه کلیدی اولیه هستند که به دنبال آن فهرستی از آرگومان‌ها قرار می‌گیرد، که برخی از آن‌ها ممکن است اختیاری باشند و با فاصله‌های خالی (whitespace) از یکدیگر جدا می‌شوند. دستورات نباید در چندین خط ادامه یابند. آرگومان‌ها می‌توانند نام میزبان، نشانی‌های میزبان نوشته‌شده در قالب عددی چهاربخشی با نقطه (dotted-quad)، اعداد صحیح، اعداد اعشاری (هنگام مشخص کردن زمان بر حسب ثانیه) و رشته‌های متنی باشند.

ادامه این صفحه به بررسی گزینه‌های پیکربندی و کنترل می‌پردازد. صفحه "Notes on Configuring NTP and Setting up an NTP Subnet" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) شامل بررسی گسترده‌تری درباره این گزینه‌ها است. علاوه بر بررسی کلی گزینه‌های پیکربندی (Configuration Options)، بخش‌هایی وجود دارند که قابلیت‌های پشتیبانی‌شده زیر و گزینه‌های مورد استفاده برای کنترل آن‌ها را شرح می‌دهند:

•
پشتیبانی از احراز هویت (Authentication Support)
•
پشتیبانی از پایش (Monitoring Support)
•
پشتیبانی از کنترل دسترسی (Access Control Support)
•
گزینه‌های پیکربندی خودکار NTP (Automatic NTP Configuration Options)
•
پشتیبانی از ساعت مرجع (Reference Clock Support)
•
گزینه‌های متفرقه (Miscellaneous Options)

پس از این‌ها بخشی قرار دارد که گزینه‌های متفرقه (Miscellaneous Options) را توصیف می‌کند. اگرچه مجموعه متنوعی از گزینه‌ها در دسترس است، تنها گزینه الزامی استفاده از یک یا چند دستور pool, server, peer, broadcast یا manycastclient است.

در ادامه، شرحی از دستورات پیکربندی در NTPv4 ارائه شده است. این دستورات همان کارکردهای اساسی در NTPv3 را دارند و در برخی موارد دارای کارکردها و آرگومان‌های جدیدی هستند. دو دسته دستور وجود دارد: دستورات پیکربندی که یک ارتباط پایدار (persistent association) با یک سرور یا همتای دوردست یا ساعت مرجع را پیکربندی می‌کنند، و دستورات کمکی که متغیرهای محیطی کنترل‌کننده عملیات مختلف مرتبط را تعیین می‌نمایند.

حالت‌های مختلف بر اساس کلمه کلیدی دستور و نوع نشانی IP مورد نیاز تعیین می‌شوند. نشانی‌ها بر اساس نوع دسته‌بندی می‌شوند: (s) یک سرور یا همتای دوردست (IPv4 کلاس A، B و C)، (b) نشانی برودکست (پخش همگانی) یک رابط محلی، (m) یک نشانی چندپخشی یا مالتی‌کست (IPv4 کلاس D)، یا (r) نشانی یک ساعت مرجع (127.127.x.x). توجه داشته باشید که تنها گزینه‌های قابل اعمال بر هر دستور در زیر فهرست شده‌اند. استفاده از گزینه‌هایی که فهرست نشده‌اند ممکن است به عنوان خطا شناسایی نشود، اما می‌تواند منجر به رفتارهای عجیب و حتی مخرب گردد.

اگر افزونه‌های رابط سوکت پایه برای IPv6 (سند RFC-2553) تشخیص داده شود، علاوه بر پشتیبانی پیش‌فرض از خانواده نشانی‌های IPv4، پشتیبانی از خانواده نشانی‌های IPv6 نیز ایجاد می‌شود. در موارد معدودی، از جمله تابلوی اطلاعات (billboard) reslist تولیدشده توسط ntpq(1) یا ntpdc(1)، نشانی‌های IPv6 به طور خودکار تولید می‌شوند. نشانی‌های IPv6 را می‌توان از وجود دونقطه “:” در فیلد نشانی تشخیص داد. نشانی‌های IPv6 تقریباً در هر جایی که نشانی‌های IPv4 قابل استفاده هستند به کار می‌روند، به استثنای نشانی‌های ساعت مرجع که همیشه IPv4 هستند.

توجه داشته باشید در شرایطی که انتظار نام میزبان می‌رود، پیشوند تعیین‌کننده -4 قبل از نام میزبان، وضوح DNS را به فضای نام IPv4 اجبار می‌کند، در حالی که پیشوند تعیین‌کننده -6 وضوح DNS را به فضای نام IPv6 مجبور می‌سازد. برای کلاس‌های معادل در آن خانواده نشانی، به مراجع IPv6 مراجعه کنید.






این پنج دستور، نام یا نشانی کارساز زمان مورد استفاده و حالت عملکرد آن را مشخص می‌کنند. address می‌تواند یک نام DNS یا یک نشانی IP در قالب نشانه‌گذاری چهاربخشی با نقطه (dotted-quad) باشد. اطلاعات بیشتر درباره رفتار ارتباط (association) را می‌توان در صفحه "مدیریت ارتباط (Association Management)" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) یافت.


برای نشانی‌های نوع s، این دستور یک ارتباط پایدار در حالت کلاینت با تعدادی از سرورهای دوردست ایجاد می‌کند. در این حالت، ساعت محلی می‌تواند با سرور دوردست همگام‌سازی شود، اما سرور دوردست هرگز نمی‌تواند با ساعت محلی همگام شود.

برای نشانی‌های نوع s و r، این دستور یک ارتباط پایدار در حالت کلاینت با سرور دوردست یا ساعت رادیویی محلی مشخص‌شده ایجاد می‌کند. در این حالت، ساعت محلی می‌تواند با سرور دوردست همگام‌سازی شود، اما سرور دوردست هرگز نمی‌تواند با ساعت محلی همگام شود. این دستور نباید برای نشانی‌های نوع b یا m استفاده شود.

تنها برای نشانی‌های نوع s، این دستور یک ارتباط پایدار در حالت متقارن-فعال (symmetric-active) با همتای دوردست مشخص‌شده ایجاد می‌کند. در این حالت، ساعت محلی می‌تواند با همتای دوردست همگام‌سازی شود یا همتای دوردست می‌تواند با ساعت محلی همگام گردد. این ویژگی در شبکه‌ای از سرورها مفید است که در آن، بسته به سناریوهای مختلف خرابی، ممکن است همتای محلی یا دوردست منبع بهتری برای زمان باشند. این دستور نباید برای نشانی‌های نوع b، m یا r استفاده شود.

تنها برای نشانی‌های نوع b و m، این دستور یک ارتباط پایدار در حالت برودکست (پخش همگانی) برقرار می‌کند. می‌توان از چندین دستور برای مشخص کردن چندین رابط برودکست محلی (زیرشبکه‌ها) و/یا چندین گروه چندپخشی (مالتی‌کست) استفاده کرد. توجه داشته باشید که پیام‌های برودکست محلی تنها به رابط مرتبط با زیرشبکه مشخص‌شده ارسال می‌شوند، اما پیام‌های مالتی‌کست به تمامی رابط‌ها فرستاده می‌شوند. در حالت برودکست، سرور محلی پیام‌های برودکست دوره‌ای را به جمع کلاینت‌ها در address مشخص‌شده ارسال می‌کند، که معمولاً نشانی برودکست در (یکی از) شبکه(های) محلی یا یک نشانی مالتی‌کست تخصیص‌یافته به NTP است. سازمان IANA نشانی گروه مالتی‌کست IPv4 224.0.1.1 و IPv6 ff05::101 (محلی سایت) را منحصراً به NTP اختصاص داده است، اما سایر نشانی‌های غیرمتداخل می‌توانند برای محدود کردن پیام‌ها در مرزهای مدیریتی استفاده شوند. به طور معمول، این مشخصات تنها برای سرور محلی که به عنوان فرستنده عمل می‌کند اعمال می‌شود؛ برای عملکرد به عنوان کلاینت برودکست، دستورات broadcastclient یا multicastclient را در زیر ببینید.

تنها برای نشانی‌های نوع m، این دستور یک ارتباط در حالت کلاینت منی‌کست را برای نشانی مالتی‌کست مشخص‌شده برقرار می‌کند. در این حالت باید یک نشانی مشخص ارائه شود که با نشانی مورد استفاده در دستور manycastserver برای سرورهای منی‌کست تعیین‌شده مطابقت داشته باشد. نشانی مالتی‌کست NTP 224.0.1.1 تخصیص‌یافته توسط IANA نباید استفاده شود، مگر اینکه تمهیدات ویژه‌ای برای جلوگیری از انتشار وسیع این پیام‌ها در بخش‌های بزرگی از اینترنت و ایجاد هجوم سهمگین بالقوه پاسخ‌ها به سمت فرستنده اتخاذ شده باشد. دستور manycastserver مشخص می‌کند که سرور محلی باید در حالت کلاینت با سرورهای دوردستی که در نتیجه پیام‌های برودکست/مالتی‌کست کشف می‌شوند، کار کند. کلاینت، یک پیام درخواست به نشانی گروه مرتبط با address مشخص‌شده پخش می‌کند و سرورهایی که به طور خاص فعال شده‌اند به این پیام‌ها پاسخ می‌دهند. کلاینت سرورهایی را که بهترین زمان را ارائه می‌دهند انتخاب می‌کند و مانند دستور server ادامه می‌دهد. سایر سرورها به گونه‌ای نادیده گرفته می‌شوند که گویی هرگز شنیده نشده‌اند.

گزینه‌ها:


تمام بسته‌های ارسالی به و دریافتی از سرور یا همتا باید شامل فیلدهای احراز هویت رمزگذاری‌شده با استفاده از طرحواره autokey باشند که در پشتیبانی از احراز هویت (Authentication Support) شرح داده شده است.

هنگامی که سرور در دسترس است، به جای یک بسته معمول، یک رگبار (burst) از شش بسته ارسال شود. فاصله بین بسته‌ها ۲ ثانیه است. این گزینه برای بهبود کیفیت زمان‌سنجی با دستور server و نشانی‌های s طراحی شده است.

هنگامی که سرور در دسترس نیست، یک رگبار از هشت بسته به جای یک بسته معمول ارسال شود. فاصله بین بسته‌ها ۲ ثانیه است. این گزینه برای سرعت بخشیدن به برقراری همگام‌سازی اولیه با دستور server و نشانی‌های s و زمانی که ntpd(1) با گزینه -q راه‌اندازی می‌شود، طراحی شده است.

تمام بسته‌های ارسالی به و دریافتی از سرور یا همتا باید شامل فیلدهای احراز هویت رمزگذاری‌شده با استفاده از شناسه key مشخص‌شده با مقادیر ۱ تا ۶۵۵۳۵ (شامل هر دو) باشند. حالت پیش‌فرض این است که هیچ فیلد رمزنگاری گنجانده نشود.


این گزینه‌ها حداقل و حداکثر فواصل نظرسنجی (poll intervals) را برای پیام‌های NTP به صورت توانی از ۲ بر حسب ثانیه مشخص می‌کنند. حداکثر فاصله نظرسنجی به طور پیش‌فرض ۱۰ (۱۰۲۴ ثانیه) است، اما می‌تواند توسط گزینه maxpoll تا حد بالای ۱۷ (۳۶.۴ ساعت) افزایش یابد. حداقل فاصله نظرسنجی به طور پیش‌فرض ۶ (۶۴ ثانیه) است، اما می‌تواند توسط گزینه minpoll تا حد پایین ۴ (۱۶ ثانیه) کاهش یابد.

سرور را به جز برای اهداف نمایشی، به عنوان غیرقابل استفاده علامت‌گذاری می‌کند. سرور توسط الگوریتم انتخاب نادیده گرفته می‌شود.

مشخص می‌کند که ارتباط می‌تواند پیش‌دستانه جایگزین شود (preempted).

سرور را به عنوان ترجیح‌داده‌شده علامت‌گذاری می‌کند. در شرایط برابر، این میزبان برای همگام‌سازی در میان مجموعه‌ای از میزبان‌های با عملکرد صحیح انتخاب خواهد شد. صفحه "Mitigation Rules and the prefer Keyword" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) را برای اطلاعات بیشتر ببینید.

سرور را به عنوان یک منبع زمان واقعی و معتبر (truechimer) علامت‌گذاری می‌کند، و ارتباط را مجبور می‌سازد تا همیشه در الگوریتم‌های انتخاب و خوشه‌بندی باقی بماند. این گزینه تقریباً با اطمینان فقط باید هنگام آزمایش یک ارتباط استفاده شود.

این گزینه تنها در حالت‌های سرور برودکست و کلاینت منی‌کست استفاده می‌شود. این گزینه مقدار طول عمر (time-to-live) ttl را برای استفاده در سرور برودکست و سرور مالتی‌کست و حداکثر ttl را برای جستجوی حلقه گسترش‌یابنده (expanding ring search) با بسته‌های کلاینت منی‌کست مشخص می‌کند. انتخاب مقدار مناسب که به طور پیش‌فرض ۱۲۷ است، امری تخصصی و پیچیده بوده و باید با مدیر شبکه هماهنگ شود.

شماره نسخه مورد استفاده برای بسته‌های خروجی NTP را مشخص می‌کند. گزینه‌ها نسخه‌های ۱ تا ۴ هستند که نسخه ۴ پیش‌فرض است.

تنها در حالت‌های peer و broadcast معتبر است؛ این فلگ حالت درهم‌تنیده (interleave mode) را فعال می‌کند.

تنها برای حالت‌های server و pool معتبر است؛ این فلگ یک عدد تصادفی در برچسب زمانی ارسال (transmit timestamp) بسته قرار می‌دهد.


این دستور دریافت پیام‌های سرور برودکست را برای هر نشانی رابط محلی (نوع b) فعال می‌کند. پس از دریافت یک پیام برای نخستین بار، کلاینت برودکست تأخیر اسمی انتشار سرور را با استفاده از یک تبادل کوتاه کلاینت/سرور با سرور اندازه می‌گیرد، سپس وارد حالت کلاینت برودکست می‌شود که در آن با پیام‌های برودکست بعدی همگام می‌گردد. توجه داشته باشید که برای جلوگیری از اختلال تصادفی یا بدخواهانه در این حالت، هر دو سرور و کلاینت باید با استفاده از احراز هویت کلید متقارن یا کلید عمومی همان‌طور که در پشتیبانی از احراز هویت (Authentication Support) توضیح داده شده است، کار کنند.

این دستور دریافت پیام‌های کلاینت منی‌کست را برای نشانی(های) گروه مالتی‌کست مشخص‌شده (نوع m) فعال می‌کند. حداقل یک نشانی الزامی است، اما نشانی مالتی‌کست NTP 224.0.1.1 تخصیص‌یافته توسط IANA نباید استفاده شود، مگر اینکه تمهیدات خاصی برای محدود کردن دامنه پاسخ و جلوگیری از هجوم بالقوه عظیم پاسخ‌ها به سمت فرستنده اصلی اتخاذ شده باشد. توجه داشته باشید که برای جلوگیری از اختلال تصادفی یا بدخواهانه در این حالت، هر دو سرور و کلاینت باید با استفاده از احراز هویت کلید متقارن یا کلید عمومی همان‌طور که در پشتیبانی از احراز هویت (Authentication Support) شرح داده شده است، عمل کنند.

این دستور دریافت پیام‌های سرور مالتی‌کست را برای نشانی(های) گروه مالتی‌کست مشخص‌شده (نوع m) فعال می‌کند. پس از دریافت یک پیام برای نخستین بار، کلاینت مالتی‌کست تأخیر اسمی انتشار سرور را با استفاده از یک تبادل کوتاه کلاینت/سرور با سرور اندازه می‌گیرد، سپس وارد حالت کلاینت برودکست می‌شود که در آن با پیام‌های مالتی‌کست بعدی همگام می‌گردد. توجه داشته باشید که برای جلوگیری از اختلال تصادفی یا بدخواهانه در این حالت، هر دو سرور و کلاینت باید با استفاده از احراز هویت کلید متقارن یا کلید عمومی همان‌طور که در پشتیبانی از احراز هویت (Authentication Support) توصیف شده است، کار کنند.

اگر در mDNS مشارکت داشته باشیم، پس از اینکه برای نخستین بار همگام شدیم، تلاش می‌کنیم در سیستم mDNS ثبت شویم. اگر آن تلاش برای ثبت ناموفق باشد، در فواصل زمانی یک‌دقیقه‌ای تا حداکثر mdnstries بار دیگر تلاش می‌کنیم. به هر حال، ممکن است ntpd پیش از mDNS شروع به کار کرده باشد. مقدار پیش‌فرض برای mdnstries برابر ۵ است.

پشتیبانی از احراز هویت به کلاینت NTP این امکان را می‌دهد تا تأیید کند سرور در واقع شناخته‌شده و مورد اعتماد است و یک نفوذگر نیست که تصادفی یا عامدانه قصد جعل هویت آن سرور (masquerade) را داشته باشد. مشخصات NTPv3 در RFC-1305 طرحی را تعریف می‌کند که احراز هویت رمزنگاری‌شده بسته‌های دریافتی NTP را فراهم می‌سازد. در ابتدا، این کار با استفاده از الگوریتم استاندارد رمزنگاری داده‌ها (DES) که در حالت زنجیره‌سازی بلوک‌های رمزشده (CBC) کار می‌کرد و معمولاً DES-CBC نامیده می‌شد، انجام می‌گرفت. سپس، این روش با الگوریتم خلاصه‌پیام RSA شماره ۵ (MD5) با استفاده از یک کلید خصوصی (private key) که معمولاً keyed-MD5 نامیده می‌شود، جایگزین شد. هر یک از این الگوریتم‌ها یک خلاصه‌پیام (message digest) یا درهم‌ساز یک‌طرفه (one-way hash) محاسبه می‌کنند که می‌تواند برای تأیید اینکه سرور دارای کلید خصوصی و شناسه کلید (key identifier) صحیح است استفاده شود.

NTPv4 طرح NTPv3 را حفظ کرده است که به درستی به عنوان رمزنگاری کلید متقارن (symmetric key cryptography) توصیف می‌شود و علاوه بر آن، طرح جدید Autokey را بر پایه رمزنگاری کلید عمومی (public key cryptography) ارائه می‌دهد. رمزنگاری کلید عمومی به طور کلی امن‌تر از رمزنگاری کلید متقارن در نظر گرفته می‌شود، زیرا امنیت بر پایه یک مقدار خصوصی است که توسط هر سرور تولید شده و هرگز فاش نمی‌شود. با Autokey تمام توابع توزیع و مدیریت کلید تنها شامل مقادیر عمومی هستند که توزیع و ذخیره‌سازی کلید را به طور چشمگیری ساده می‌کند. مدیریت کلید عمومی بر پایه گواهی‌های X.509 (certificates) است که می‌توانند توسط سرویس‌های تجاری ارائه شوند یا توسط برنامه‌های کاربردی در کتابخانه نرم‌افزاری OpenSSL یا توزیع NTPv4 تولید گردند.

در حالی که الگوریتم‌های رمزنگاری کلید متقارن در توزیع NTPv4 گنجانده شده‌اند، رمزنگاری کلید عمومی مستلزم این است که کتابخانه نرم‌افزاری OpenSSL قبل از کامپایل و ساخت توزیع NTP نصب شده باشد. دستورالعمل‌های انجام این کار در صفحه Building and Installing the Distribution قرار دارد.

احراز هویت برای هر ارتباط (association) به طور جداگانه با استفاده از زیردستور key یا autokey در دستورات پیکربندی peer, server, broadcast و manycastclient همان‌طور که در صفحه Configuration Options توضیح داده شده است، پیکربندی می‌شود. گزینه‌های احراز هویت توصیف‌شده در زیر، مکان فایل‌های کلید (در صورتی که غیر از پیش‌فرض باشند)، اینکه کدام کلیدهای متقارن مورد اعتماد هستند و فواصل زمانی بین عملیات مختلف (در صورتی که غیر از پیش‌فرض باشند) را مشخص می‌کنند.

احراز هویت همیشه فعال است، هرچند اگر همان‌طور که در ادامه توصیف شده است پیکربندی نشود، بی‌اثر خواهد بود. اگر یک بسته NTP شامل یک کد احراز هویت پیام (MAC) برسد، تنها در صورتی پذیرفته می‌شود که تمام بررسی‌های رمزنگاری را پشت سر بگذارد. این بررسی‌ها نیازمند شناسه کلید، مقدار کلید و خلاصه‌پیام (message digest) صحیح هستند. اگر بسته به هر نحوی دستکاری شده باشد یا توسط یک نفوذگر بازپخش (replayed) شده باشد، در یک یا چند مورد از این بررسی‌ها رد شده و دور انداخته می‌شود. علاوه بر این، طرح Autokey نیازمند یک تبادل مقدماتی پروتکل برای دریافت گواهی سرور، اعتبارسنجی اعتبارنامه‌های آن و راه‌اندازی اولیه پروتکل است.

فلگ auth کنترل می‌کند که آیا ارتباطات جدید یا دستورات پیکربندی از راه دور نیازمند احراز هویت رمزنگاری هستند یا خیر. این فلگ می‌تواند توسط دستورات enable و disable و همچنین توسط دستورات پیکربندی از راه دور ارسال‌شده توسط یک برنامه ntpdc(1) که روی ماشین دیگری اجرا می‌شود، تنظیم یا بازنشانی شود. اگر این فلگ فعال باشد (که حالت پیش‌فرض است)، ارتباطات جدید کلاینت broadcast و passive متقارن و دستورات پیکربندی از راه دور باید با استفاده از رمزنگاری کلید متقارن یا کلید عمومی به صورت رمزنگاری احراز هویت شوند. اگر این فلگ غیرفعال باشد، این عملیات حتی اگر از نظر رمزنگاری احراز هویت نشده باشند نیز مؤثر واقع می‌شوند. باید درک کرد که اجرا در شرایطی که فلگ auth غیرفعال است یک آسیب‌پذیری بزرگ ایجاد می‌کند که در آن یک هکر مخرب می‌تواند خود را به جای یک falseticker جا زده و زمان‌سنجی سیستم را به طور جدی مختل کند. مهم است توجه شود که این فلگ هیچ هدفی جز مجاز کردن یا رد کردن یک ارتباط جدید در پاسخ به پیام‌های جدید broadcast و active متقارن و دستورات پیکربندی از راه دور ندارد و به ویژه، این فلگ هیچ تأثیری بر خود فرآیند احراز هویت ندارد.

یک جایگزین جذاب در جایی که پشتیبانی از چندپخشی (multicast) در دسترس است، حالت manycast است که در آن کلاینت‌ها به صورت دوره‌ای برای یافتن سرورها جستجو می‌کنند (troll)، همان‌طور که در صفحه Automatic NTP Configuration Options توضیح داده شده است. در این حالت می‌توان از احراز هویت رمزنگاری کلید متقارن یا کلید عمومی استفاده کرد. مزیت اصلی حالت manycast این است که نیازی به پیکربندی سرورهای بالقوه از قبل نیست، زیرا کلاینت آن‌ها را در طول عملکرد عادی پیدا می‌کند، و فایل‌های پیکربندی تمام کلاینت‌ها می‌توانند یکسان باشند.

مدل امنیتی و طرح‌های پروتکل برای هر دو نوع رمزنگاری کلید متقارن و کلید عمومی در زیر خلاصه شده است؛ جزئیات بیشتر در توجیهات، مقالات و گزارش‌های صفحه پروژه NTP که از http://www.ntp.org پیوند داده شده، موجود است.

مشخصات اصلی RFC-1305 اجازه می‌دهد هر یک از حداکثر ۶۵,۵۳۵ کلید ممکن، که هر کدام با یک شناسه کلید ۳۲ بیتی متمایز می‌شوند، برای احراز هویت یک ارتباط استفاده شود. سرورها و کلاینت‌های درگیر باید بر سر کلید و شناسه کلید به منظور احراز هویت بسته‌های NTP توافق داشته باشند. کلیدها و اطلاعات مربوطه در یک فایل کلید، که معمولاً ntp.keys نامیده می‌شود، مشخص می‌گردند که باید با استفاده از روش‌های امن فراتر از محدوده خود پروتکل NTP توزیع و ذخیره شوند. علاوه بر کلیدهای مورد استفاده برای ارتباطات عادی NTP، کلیدهای اضافی می‌توانند به عنوان گذرواژه برای برنامه‌های کاربردی ntpq(1) و ntpdc(1) به کار روند.

هنگامی که ntpd(1) برای نخستین بار آغاز به کار می‌کند، فایل کلید مشخص‌شده در دستور پیکربندی keys را خوانده و کلیدها را در حافظه پنهان کلید (key cache) نصب می‌کند. با این حال، هر یک از کلیدها باید قبل از استفاده با دستور trusted فعال شوند. این امر برای نمونه امکان نصب چند دسته کلید و سپس فعال یا غیرفعال کردن هر دسته از راه دور با استفاده از ntpdc(1) را فراهم می‌سازد. همچنین این ویژگی قابلیت ابطال (revocation) را فراهم می‌کند که در صورت به خطر افتادن یک کلید قابل استفاده است. دستور requestkey کلید مورد استفاده به عنوان گذرواژه برای ابزار کاربردی ntpdc(1) را انتخاب می‌کند، در حالی که دستور controlkey کلید مورد استفاده به عنوان گذرواژه برای ابزار کاربردی ntpq(1) را برمی‌گزیند.

نسخه NTPv4 از طرح اصلی کلید متقارن NTPv3 شرح داده شده در RFC-1305 و علاوه بر آن از پروتکل Autokey که بر پایه رمزنگاری کلید عمومی است پشتیبانی می‌کند. پروتکل Autokey Version 2 شرح داده شده در صفحه Autokey Protocol یکپارچگی بسته را با استفاده از خلاصه‌پیام‌های MD5 تأیید می‌کند و مبدأ را با امضاهای دیجیتال و هر یک از طرح‌های چندگانه خلاصه‌سازی/امضا (digest/signature) مورد اعتبارسنجی قرار می‌دهد. طرح‌های اختیاری هویت توصیف‌شده در صفحه Identity Schemes که بر اساس الگوریتم‌های چالش/پاسخ (challenge/response) رمزنگاری هستند نیز در دسترس قرار دارند. استفاده از تمام این طرح‌ها امنیت بالایی را در برابر بازپخش با یا بدون تغییر، جعل (spoofing)، جا زدن هویت (masquerade) و بیشتر انواع حملات مسدودسازی (clogging attacks) فراهم می‌کند.

پروتکل Autokey دارای چندین حالت عملیاتی متناظر با حالت‌های مختلف پشتیبانی‌شده در NTP است. بیشتر حالت‌ها از یک کوکی (cookie) ویژه استفاده می‌کنند که می‌تواند به طور مستقل توسط کلاینت و سرور محاسبه شود، اما در طول انتقال رمزگذاری می‌گردد. همچنین همه حالت‌ها از گونه‌ای از طرح S-KEY استفاده می‌کنند که در آن یک فهرست کلید شبه‌تصادفی تولید شده و به ترتیب معکوس مورد استفاده قرار می‌گیرد. این طرح‌ها همراه با یک خلاصه مدیریتی، وضعیت کنونی، اسلایدهای توجیهی و فهرست مطالعه در صفحه Autonomous Authentication شرح داده شده‌اند.

محیط رمزنگاری خاص مورد استفاده توسط سرورها و کلاینت‌های Autokey توسط مجموعه‌ای از فایل‌ها و پیوندهای نمادین تولیدشده توسط برنامه ntp-keygen(1ntpkeygenmdoc) تعیین می‌شود. این موارد شامل فایل الزامی کلید میزبان (host key)، فایل الزامی گواهی (certificate) و فایل‌های اختیاری کلید امضا (sign key)، فایل ثانیه کبیسه (leapsecond) و فایل‌های طرح هویت است. طرح خلاصه‌سازی/امضا (digest/signature) در گواهی X.509 همراه با کلید امضای منطبق مشخص می‌شود. چندین طرح در کتابخانه نرم‌افزاری OpenSSL در دسترس است که هر یک با رشته خاصی مانند md5WithRSAEncryption مشخص می‌شوند که نشان‌دهنده طرح خلاصه‌پیام MD5 با رمزنگاری RSA است. توزیع فعلی NTP از تمام طرح‌های موجود در کتابخانه OpenSSL، از جمله طرح‌های مبتنی بر امضاهای دیجیتال RSA و DSA پشتیبانی می‌کند.

گروه‌های امن NTP می‌توانند برای تعریف بخش‌های رمزنگاری و سلسله‌مراتب‌های امنیتی مورد استفاده قرار گیرند. بسیار مهم است که هر میزبان در گروه بتواند یک رد گواهی (certificate trail) به یک یا چند میزبان مورد اعتماد در همان گروه ایجاد کند. هر میزبان گروه، پروتکل Autokey را برای به دست آوردن گواهی‌های تمام میزبان‌های موجود در مسیر منتهی به یک یا چند میزبان مورد اعتماد اجرا می‌کند. این امر مستلزم آن است که فایل پیکربندی در تمام میزبان‌ها به گونه‌ای طراحی شود که حتی در شرایط خرابی پیش‌بینی‌شده، زیرشبکه NTP طوری شکل گیرد که هر میزبان گروه بتواند مسیری به حداقل یک میزبان مورد اعتماد بیابد.

مهم است توجه شود که Autokey از DNS برای حل نام آدرس‌ها استفاده نمی‌کند، چرا که تا زمانی که سرورهای نام (name servers) ساعت‌های همگام نداشته باشند، نمی‌توان به طور کامل به DNS اعتماد کرد. نام رمزنگاری مورداستفاده توسط Autokey برای پیوند دادن مدارک هویتی میزبان و مقادیر رمزنگاری، باید مستقل از رابط، شبکه و هرگونه قرارداد نام‌گذاری دیگر باشد. این نام در گواهی میزبان در یکی یا هر دو فیلد subject و issuer ظاهر می‌شود؛ بنابراین حفاظت در برابر نفوذ یا به خطر افتادن DNS ضروری است.

طبق قرارداد، نام یک میزبان Autokey همان نامی است که توسط فراخوانی سیستمی یونیکس gethostname(2) یا معادل آن در سایر سیستم‌ها برگردانده می‌شود. بر اساس مدل طراحی سیستم، هیچ تمهیدی برای اجازه دادن به نام‌های جایگزین یا نام‌های مستعار (aliases) وجود ندارد. با این وجود، این به آن معنا نیست که نام‌های مستعار DNS، نام‌های متفاوت برای هر رابط و غیره به هیچ نحوی محدود شده باشند.

همچنین باید توجه داشت که Autokey اصالت را با استفاده از نام میزبان، آدرس شبکه و کلیدهای عمومی تأیید می‌کند که همگی توسط این پروتکل به طور ویژه به یکدیگر پیوند خورده‌اند تا از حملات جعل هویت (masquerade) جلوگیری کنند. به همین دلیل، Autokey آدرس‌های IP مبدأ و مقصد را در محاسبات خلاصه‌پیام (message digest) لحاظ می‌کند و بنابراین آدرس‌های یکسانی باید در هر دو طرف سرور و کلاینت در دسترس باشند. به همین دلیل، کارکرد با طرح‌های ترجمه آدرس شبکه (NAT) امکان‌پذیر نیست. این موضوع بازتاب‌دهنده مدل امنیتی قدرتمند در نظر گرفته شده است که در آن سرورهای دولتی و شرکتی NTP در خارج از محدوده فایروال‌ها راه‌اندازی و اجرا می‌شوند.

یک ترکیب مشخص از طرح احراز هویت (هیچ، کلید متقارن، کلید عمومی) و طرح هویت، یک نوع رمزنگاری یا cryptotype نامیده می‌شود، اگرچه همه ترکیب‌ها با یکدیگر سازگار نیستند. ممکن است پیکربندی‌های مدیریتی وجود داشته باشد که در آن‌ها کلاینت‌ها، سرورها و همتایان (peers) همگی از cryptotypeهای یکسانی پشتیبانی نکنند. یک زیرشبکه امن NTPv4 را می‌توان با در نظر داشتن اصول توضیح‌داده‌شده در بالا و در این بخش، به روش‌های متعددی پیکربندی کرد. با این حال توجه داشته باشید که برخی از ترکیب‌های cryptotype ممکن است با موفقیت با یکدیگر تعامل داشته باشند، اما بازتاب‌دهنده یک رویکرد امنیتی خوب نباشند.

نوع رمزنگاری (cryptotype) یک ارتباط در زمان فعال‌سازی (mobilization) تعیین می‌شود؛ چه در زمان پیکربندی و چه مدتی بعد هنگامی که پیامی با cryptotype مناسب دریافت شود. هنگامی که با دستور پیکربندی server یا peer فعال‌سازی انجام شود و هیچ زیردستور key یا autokey حضور نداشته باشد، ارتباط احراز هویت نمی‌شود؛ اگر زیردستور key وجود داشته باشد، ارتباط با استفاده از شناسه کلید متقارن مشخص‌شده احراز هویت می‌گردد؛ اگر زیردستور autokey وجود داشته باشد، ارتباط با استفاده از Autokey احراز هویت می‌شود.

هنگامی که چندین طرح هویت در پروتکل Autokey پشتیبانی می‌شود، اولین تبادل پیام مشخص می‌کند که کدام یک استفاده شود. پیام درخواست کلاینت حاوی بیت‌هایی متناظر با طرح‌های در دسترس آن است. پیام پاسخ سرور نیز شامل بیت‌هایی متناظر با طرح‌های در دسترس سرور است. هر دو طرف سرور و کلاینت بیت‌های دریافتی را با بیت‌های خود مطابقت داده و یک طرح مشترک را انتخاب می‌کنند.

پیرو این اصل که زمان یک مقدار عمومی است، یک سرور به هر بسته کلاینت که با قابلیت‌های cryptotype آن همخوانی داشته باشد پاسخ می‌دهد. بنابراین، سروری که یک بسته احراز هویت‌نشده دریافت می‌کند، با یک بسته احراز هویت‌نشده پاسخ خواهد داد، در حالی که همان سرور در صورت دریافت بسته‌ای با cryptotype مورد پشتیبانی خود، با بسته‌هایی از همان cryptotype پاسخ می‌دهد. با این حال، ارتباطات کلاینت broadcast یا manycast پیکربندی‌نشده، یا ارتباطات passive متقارن فعال‌سازی (mobilize) نخواهند شد مگر اینکه سرور از یک cryptotype سازگار با نخستین بسته دریافتی پشتیبانی کند. به طور پیش‌فرض، ارتباطات احراز هویت‌نشده فعال‌سازی نمی‌شوند مگر اینکه به شکلی کاملاً خطرناک بازنویسی (override) شوند.

چند مثال ممکن است به رفع ابهام کمک کند. کلاینت Alice هیچ cryptotype خاصی را انتخاب نکرده است. سرور Bob هم یک فایل کلید متقارن و هم حداقل فایل‌های Autokey را دارد. پیام‌های احراز هویت‌نشده Alice به Bob می‌رسد و او با پیام‌های احراز هویت‌نشده پاسخ می‌دهد. کلاینت Cathy نسخه‌ای از فایل کلید متقارن Bob را دارد و شناسه کلید ۴ را در پیام‌ها به Bob انتخاب کرده است. سرور Bob پیام را با شناسه کلید ۴ خود اعتبارسنجی می‌کند. اگر کلید یکسان باشد و پیام تأیید شود، Bob پاسخی احراز هویت‌شده با همان کلید برای Cathy ارسال می‌کند. اگر اعتبارسنجی با شکست مواجه شود، Bob چیزی به نام crypto-NAK برای Cathy ارسال می‌کند که به او اطلاع می‌دهد اشکالی رخ داده است. او می‌تواند شواهد را با استفاده از برنامه ntpq(1) مشاهده کند.

کلاینت Denise کلید میزبان و گواهی مخصوص به خود را تولید کرده است. او همچنین از یکی از طرح‌های هویتی مشابه با Bob استفاده می‌کند. او نخستین پیام Autokey را برای Bob می‌فرستد و هر دو مراحل احراز هویت و هویت‌سنجی پروتکل را طی می‌کنند. اگر همه چیز به درستی پیش رود، Denise و Bob همان‌طور که در بالا توضیح داده شد به کار خود ادامه می‌دهند.

از موارد فوق باید روشن باشد که Bob می‌تواند تا زمانی که مدارک احراز هویت و هویت‌سنجی سازگار داشته باشد، همزمان از همه کلاینت‌ها پشتیبانی کند. اکنون، Bob می‌تواند در انتخاب سرورهای خود نیز دقیقاً همانند کلاینت‌ها عمل کند؛ او می‌تواند چندین ارتباط پیکربندی‌شده با چندین سرور مختلف (یا همان سرور، هرچند ممکن است مفید نباشد) را اجرا نماید. اما یک سیاست امنیتی هوشمندانه ممکن است برخی از ترکیب‌های cryptotype را منع کند؛ به عنوان مثال، اجرای یک طرح هویت با یک سرور و عدم استفاده از احراز هویت با سرور دیگر ممکن است عاقلانه نباشد.

مقادیر رمزنگاری مورداستفاده در پروتکل Autokey به عنوان مجموعه‌ای از فایل‌های تولیدشده توسط ابزار کاربردی ntp-keygen(1ntpkeygenmdoc) ادغام می‌شوند، از جمله فایل‌های کلید متقارن، کلید میزبان و گواهی عمومی، و همچنین فایل‌های کلید امضا، پارامترهای هویتی و ثانیه‌های کبیسه. همچنین، کلیدهای میزبان و امضا و فایل‌های گواهی می‌توانند توسط ابزارهای OpenSSL تولید شوند و گواهی‌ها را می‌توان از مراجع صدور گواهی عمومی (certificate authorities) وارد کرد. توجه داشته باشید که کلیدهای متقارن برای ابزارهای کاربردی ntpq(1) و ntpdc(1) ضروری هستند. سایر فایل‌ها فقط برای پروتکل Autokey مورد نیاز هستند.

گواهی‌های واردشده از OpenSSL یا مراجع صدور گواهی عمومی دارای محدودیت‌های خاصی هستند. گواهی باید در نحو ASN.1، قالب X.509 Version 3 و با کدگذاری PEM باشد، که همان قالبی است که توسط OpenSSL استفاده می‌شود. طول کلی گواهی کدگذاری‌شده در ASN.1 نباید از ۱۰۲۴ بایت فراتر رود. فیلد نام متمایز موضوع (CN) نام کامل میزبان (FQDN) است که گواهی روی آن استفاده می‌شود؛ باقی فیلدهای subject نادیده گرفته می‌شوند. فیلدهای پسوند گواهی (extension fields) نباید شامل هیچ‌یک از فیلدهای subject key identifier یا issuer key identifier باشند؛ با این حال، یک فیلد extended key usage برای یک میزبان مورد اعتماد باید حاوی مقدار trustRoot;. باشد. سایر فیلدهای پسوند نادیده گرفته می‌شوند.


فاصله زمانی بین تولید مجدد فهرست کلیدهای نشست (session key list) استفاده‌شده با پروتکل Autokey را مشخص می‌کند. توجه داشته باشید که اندازه فهرست کلید برای هر ارتباط (association) به این فاصله زمانی و فاصله نظرسنجی (poll interval) فعلی بستگی دارد. مقدار پیش‌فرض ۱۲ (۴۰۹۶ ثانیه یا حدود ۱٫۱ ساعت) است. برای فواصل نظرسنجی فراتر از فاصله مشخص‌شده، یک فهرست کلید نشست با تنها یک ورودی برای هر پیام ارسال‌شده مجدداً تولید خواهد شد.

شناسه کلید مورد استفاده با ابزار ntpq(1) را مشخص می‌کند، که از پروتکل استاندارد تعریف‌شده در RFC-1305 استفاده می‌نماید. آرگومان key شناسه کلید برای یک کلید معتمد (trusted key) است که مقدار آن می‌تواند در بازه ۱ تا ۶۵٬۵۳۵ (شامل هر دو) باشد.

این دستور نیازمند کتابخانه OpenSSL است. این دستور رمزنگاری کلید عمومی را فعال می‌کند، طرح رمزنگاری خلاصه پیام و امضا را انتخاب کرده و مقادیر خصوصی و عمومی مورد نیاز شرح داده شده در بالا را بارگذاری می‌کند. اگر یک یا چند فایل مشخص نشده باقی بمانند، نام‌های پیش‌فرض مطابق آنچه در بالا شرح داده شد استفاده می‌شوند. مگر اینکه مسیر و نام کامل فایل مشخص شده باشد، مکان فایل نسبت به دایرکتوری کلیدهای مشخص‌شده در دستور keysdir یا پیش‌فرض /usr/local/etc در نظر گرفته می‌شود. در ادامه زیردستورات آمده است:

مکان فایل گواهی عمومی مورد نیاز میزبان را مشخص می‌کند. این گزینه پیوند ntpkey_cert_hostname در دایرکتوری کلیدها را بازنویسی می‌کند.

مکان فایل اختیاری پارامترهای GQ را مشخص می‌کند. این گزینه پیوند ntpkey_gq_hostname در دایرکتوری کلیدها را بازنویسی می‌کند.

مکان فایل کلید میزبان مورد نیاز را مشخص می‌کند. این گزینه پیوند ntpkey_key_hostname در دایرکتوری کلیدها را بازنویسی می‌کند.

مکان فایل اختیاری پارامترهای IFF را مشخص می‌کند. این گزینه پیوند ntpkey_iff_hostname در دایرکتوری کلیدها را بازنویسی می‌کند.

مکان فایل اختیاری ثانیه کبیسه را مشخص می‌کند. این گزینه پیوند ntpkey_leap در دایرکتوری کلیدها را بازنویسی می‌کند.

مکان فایل اختیاری پارامترهای MV را مشخص می‌کند. این گزینه پیوند ntpkey_mv_hostname در دایرکتوری کلیدها را بازنویسی می‌کند.

گذرواژه را برای رمزگشایی فایل‌های حاوی کلیدهای خصوصی و پارامترهای هویت مشخص می‌کند. این مورد تنها در صورتی لازم است که این فایل‌ها رمزگذاری شده باشند.

مکان فایل بذر تصادفی (random seed) مورد استفاده توسط کتابخانه OpenSSL را مشخص می‌کند. مقادیر پیش‌فرض در متن اصلی بالا شرح داده شده‌اند.

مسیر و مکان کامل فایل کلید MD5 حاوی کلیدها و شناسه‌های کلید مورد استفاده توسط ntpd(1), ntpq(1) و ntpdc(1) را هنگام کار با رمزنگاری کلید متقارن مشخص می‌کند. این عملکرد همانند گزینه خط فرمان -k است.

این دستور مسیر دایرکتوری پیش‌فرض را برای کلیدهای رمزنگاری، پارامترها و گواهی‌ها مشخص می‌کند. مقدار پیش‌فرض /usr/local/etc/ است.

شناسه کلید مورد استفاده با برنامه کمکی ntpdc(1) را مشخص می‌کند، که از یک پروتکل اختصاصی ویژه این پیاده‌سازی از ntpd(1) استفاده می‌کند. آرگومان key یک شناسه کلید برای کلید معتمد است، که در آن مقدار می‌تواند در بازه ۱ تا ۶۵٬۵۳۵ (شامل هر دو) باشد.

فاصله زمانی بین تصادفی‌سازی مجدد برخی از مقادیر رمزنگاری استفاده‌شده توسط طرح Autokey را به‌صورت توانی از ۲ بر حسب ثانیه مشخص می‌کند. این مقادیر باید به‌طور مکرر به‌روزرسانی شوند تا حملات جستجوی فراگیر (brute-force) روی الگوریتم‌های این طرح دفع شوند؛ با این حال، به‌روزرسانی برخی مقادیر عملیاتی نسبتاً سنگین و هزینه‌بر است. فاصله زمانی پیش‌فرض ۱۶ (۶۵٬۵۳۶ ثانیه یا حدود ۱۸ ساعت) است. برای فواصل نظرسنجی فراتر از فاصله زمانی تعیین‌شده، این مقادیر برای هر پیام ارسال‌شده به‌روزرسانی خواهند شد.

شناسه‌های کلیدی را مشخص می‌کند که برای اهداف احراز هویت همتایان با رمزنگاری کلید متقارن، و همچنین کلیدهای مورد استفاده توسط برنامه‌های ntpq(1) و ntpdc(1) معتمد (trusted) هستند. فرآیندهای احراز هویت مستلزم آن است که هر دو سرور محلی و راه دور کلید و شناسه کلید یکسانی را برای این منظور به اشتراک بگذارند، اگرچه می‌توان از کلیدهای متفاوتی با سرورهای مختلف استفاده کرد. آرگومان‌های key اعداد صحیح ۳۲ بیتی بدون علامت با مقادیر ۱ تا ۶۵٬۵۳۵ هستند.

کدهای خطای زیر از طریق سازوکار تله (trap) پروتکل کنترل و نظارت NTP گزارش می‌شوند.

101

(bad field format or length) بسته دارای نسخه، طول یا فرمت نامعتبر است.
102

(bad timestamp) برچسب زمانی بسته با آخرین برچسب دریافتی یکسان یا قدیمی‌تر از آن است. این موضوع می‌تواند به دلیل بازپخش یا پرش زمانی ساعت سرور باشد.
103

(bad filestamp) برچسب زمانی فایل بسته با آخرین برچسب دریافتی یکسان یا قدیمی‌تر از آن است. این موضوع می‌تواند به دلیل بازپخش یا خطای تولید فایل کلید باشد.
104

(bad or missing public key) کلید عمومی مفقود شده است، فرمت نادرستی دارد یا از نوع پشتیبانی‌نشده است.
105

(unsupported digest type) سرور نیازمند یک طرح خلاصه پیام/امضای پشتیبانی‌نشده است.
106

(mismatched digest types) استفاده نمی‌شود.
107

(bad signature length) طول امضا با کلید عمومی فعلی مطابقت ندارد.
108

(signature not verified) پیام در بررسی امضا مردود می‌شود. ممکن است جعلی باشد یا با کلید خصوصی متفاوتی امضا شده باشد.
109

(certificate not verified) گواهی نامعتبر است یا با کلید نادرستی امضا شده است.
110

(certificate not verified) گواهی هنوز معتبر نیست یا منقضی شده است یا امکان تایید امضا وجود نداشت.
111

(bad or missing cookie) کوکی مفقود، خراب یا جعلی است.
112

(bad or missing leapseconds table) جدول ثانیه‌های کبیسه مفقود، خراب یا جعلی است.
113

(bad or missing certificate) گواهی مفقود، خراب یا جعلی است.
114

(bad or missing identity) کلید هویت مفقود، خراب یا جعلی است.

ntpd(1) شامل یک امکان نظارتی جامع است که برای ثبت مداوم و بلندمدت عملکرد زمان‌سنجی سرور و کلاینت مناسب است. برای مشاهده فهرست و مثالی از هر نوع از آمارهای پشتیبانی‌شده فعلی، دستور statistics در زیر را ببینید. فایل‌های آماری با استفاده از مجموعه‌های تولید فایل و اسکریپت‌های موجود در دایرکتوری ./scripts توزیع کد منبع مدیریت می‌شوند. با استفاده از این امکانات و وظایف زمان‌بندی‌شده cron(8) یونیکس، داده‌ها را می‌توان به‌طور خودکار خلاصه و برای تحلیل‌های گذشته‌نگر آرشیو کرد.


نوشتن رکوردهای آماری را فعال می‌کند. در حال حاضر، هشت نوع آمار name پشتیبانی می‌شود.

ثبت اطلاعات آماری راه‌انداز ساعت (clock driver) را فعال می‌کند. هر به‌روزرسانی دریافت شده از یک راه‌انداز ساعت، خطی به فرم زیر را به مجموعه تولید فایل با نام clockstats اضافه می‌کند: 

49213 525.624 127.127.4.1 93 226 00:08:29.606 D

دو فیلد اول تاریخ (Modified Julian Day) و زمان (ثانیه و کسر ثانیه گذشته از نیمه‌شب UTC) را نشان می‌دهند. فیلد بعدی نشانی ساعت را در قالب چهاردهدهی نقطه‌دار (dotted-quad) نشان می‌دهد. فیلد پایانی آخرین کد زمانی دریافت شده از ساعت را در قالب اسکی رمزگشایی‌شده (در صورت معنی‌دار بودن) نشان می‌دهد. در برخی راه‌اندازهای ساعت، اطلاعات اضافی قابل توجهی نیز می‌تواند جمع‌آوری و نمایش داده شود. برای جزئیات بیشتر اطلاعات ویژه هر ساعت را ببینید.


این گزینه نیازمند کتابخانه نرم‌افزاری رمزنگاری OpenSSL است. این گزینه ثبت اطلاعات پروتکل رمزنگاری کلید عمومی را فعال می‌کند. هر پیام دریافت شده توسط ماژول پروتکل، خطی به فرم زیر را به مجموعه تولید فایل با نام cryptostats اضافه می‌کند: 

49213 525.624 127.127.4.1 message

دو فیلد اول تاریخ (Modified Julian Day) و زمان (ثانیه و کسر ثانیه گذشته از نیمه‌شب UTC) را نشان می‌دهند. فیلد بعدی نشانی همتا را در قالب چهاردهدهی نقطه‌دار نشان می‌دهد. فیلد نهایی message شامل نوع پیام و برخی اطلاعات فرعی است. برای اطلاعات بیشتر بخش Authentication Options را ببینید.


ثبت اطلاعات آماری فیلتر حلقه (loop filter) را فعال می‌کند. هر به‌روزرسانی ساعت محلی، خطی به فرم زیر را به مجموعه تولید فایل با نام loopstats خروجی می‌دهد: 

50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806

دو فیلد اول تاریخ (Modified Julian Day) و زمان (ثانیه و کسر ثانیه گذشته از نیمه‌شب UTC) را نشان می‌دهند. پنج فیلد بعدی انحراف زمان (ثانیه)، انحراف فرکانس (قسمت در میلیون - PPM)، جیتر RMS (ثانیه)، انحراف آلن (PPM) و ثابت زمانی تنظیم ساعت را نشان می‌دهند.


ثبت اطلاعات آماری همتایان را فعال می‌کند. این شامل رکوردهای آماری تمامی همتایان یک سرور NTP و سیگنال‌های ویژه در صورت وجود و پیکربندی است. هر به‌روزرسانی معتبر، خطی به فرم زیر را به عنصر فعلی مجموعه تولید فایل با نام peerstats اضافه می‌کند: 

48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674

دو فیلد اول تاریخ (Modified Julian Day) و زمان (ثانیه و کسر ثانیه گذشته از نیمه‌شب UTC) را نشان می‌دهند. دو فیلد بعدی به ترتیب نشانی همتا را در قالب چهاردهدهی نقطه‌دار و وضعیت نشان می‌دهند. فیلد وضعیت به‌صورت هگزادسیمال در قالبی که در پیوست A مشخصات NTP در RFC 1305 شرح داده شده، کدگذاری می‌شود. چهار فیلد نهایی انحراف (offset)، تاخیر، پراکندگی و جیتر RMS را همگی بر حسب ثانیه نشان می‌دهند.


ثبت اطلاعات آماری برچسب زمانی خام (raw-timestamp) را فعال می‌کند. این شامل رکوردهای آماری تمامی همتایان یک سرور NTP و سیگنال‌های ویژه در صورت وجود و پیکربندی است. هر پیام NTP دریافت شده از یک همتا یا راه‌انداز ساعت، خطی به فرم زیر را به مجموعه تولید فایل با نام rawstats اضافه می‌کند: 

50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000

دو فیلد اول تاریخ (Modified Julian Day) و زمان (ثانیه و کسر ثانیه گذشته از نیمه‌شب UTC) را نشان می‌دهند. دو فیلد بعدی نشانی همتا یا ساعت راه دور و به دنبال آن نشانی محلی را در قالب چهاردهدهی نقطه‌دار نشان می‌دهند. چهار فیلد نهایی به ترتیب برچسب‌های زمانی مبدأ (originate)، دریافت (receive)، انتقال (transmit) و نهایی NTP را نشان می‌دهند. مقادیر برچسب زمانی همان مقادیر دریافتی هستند و قبل از پردازش توسط الگوریتم‌های مختلف هموارسازی داده‌ها و کاهش نوسان قرار دارند.


ثبت دوره‌ای شمارنده‌های آماری ntpd را فعال می‌کند. هر ساعت خطی به فرم زیر به مجموعه تولید فایل با نام sysstats اضافه می‌شود: 

50928 2132.543 36000 81965 0 9546 56 71793 512 540 10 147

دو فیلد اول تاریخ (Modified Julian Day) و زمان (ثانیه و کسر ثانیه گذشته از نیمه‌شب UTC) را نشان می‌دهند. ده فیلد باقی‌مانده مقادیر شمارنده‌های آماری انباشته‌شده از زمان آخرین خط تولیدشده را نشان می‌دهند.


زمان بر حسب ساعت از آخرین راه‌اندازی مجدد سیستم.

تعداد کل بسته‌های دریافتی.

تعداد بسته‌های دریافت‌شده در پاسخ به بسته‌های ارسال‌شده قبلی.

تعداد بسته‌های منطبق با نسخه فعلی NTP.

تعداد بسته‌های منطبق با نسخه قبلی NTP.

تعداد بسته‌هایی که با هیچ‌کدام از نسخه‌های NTP مطابقت ندارند.

تعداد بسته‌هایی که دسترسی آن‌ها به هر دلیلی رد شده است.

تعداد بسته‌های دارای طول، فرمت یا شماره پورت نامعتبر.

تعداد بسته‌هایی که اصالت آن‌ها تایید نشده است.

تعداد بسته‌های دور ریخته‌شده به دلیل محدودیت نرخ.

مسیر کامل دایرکتوری‌ای را مشخص می‌کند که فایل‌های آماری باید در آن ایجاد شوند (به زیر مراجعه کنید). این کلمه کلیدی اجازه می‌دهد پیشوند نام فایل filegen (که در غیر این صورت ثابت است) برای مجموعه‌های تولید فایل تغییر داده شود، که برای مدیریت گزارش‌های آماری مفید است.

تنظیمات نام مجموعه فایل‌های تولیدی را پیکربندی می‌کند. مجموعه‌های فایل تولیدی ابزاری برای مدیریت فایل‌هایی فراهم می‌کنند که در طول مدت فعالیت سرور پیوسته در حال رشد هستند. آمار سرور نمونه‌ای معمول از این دست فایل‌ها هستند. مجموعه‌های فایل تولیدی دسترسی به مجموعه‌ای از فایل‌ها را فراهم می‌کنند که برای ذخیره داده‌های واقعی استفاده می‌شوند. در هر زمان حداکثر در یک عنصر از این مجموعه نوشته می‌شود. نوع ارائه‌شده مشخص می‌کند چه زمانی و چگونه داده‌ها به عنصر جدیدی از مجموعه هدایت شوند. از این طریق، اطلاعات ذخیره‌شده در عناصری از مجموعه فایل که در حال حاضر بلااستفاده هستند، برای عملیات مدیریتی بدون خطر ایجاد اختلال در عملکرد ntpd در دسترس هستند. (مهم‌تر از همه: می‌توان آن‌ها را برای آزادسازی فضا برای داده‌های جدید تولیدشده حذف کرد.)

توجه داشته باشید که این دستور می‌تواند از برنامه ntpdc(1) که در یک مکان راه دور در حال اجراست ارسال شود.


این نوع رکوردهای آماری است، همان‌گونه که در دستور statistics نشان داده شده است.

این نام فایل برای رکوردهای آماری است. نام فایل‌های اعضای مجموعه از سه عنصر الحاق‌شده prefix, filename و suffix ساخته می‌شوند:

این یک مسیر نام فایل ثابت است. این مقدار از طریق گزینه filegen قابل تغییر نیست. این مقدار توسط سرور تعریف می‌شود و معمولاً به‌صورت یک مقدار ثابت در زمان کامپایل مشخص می‌گردد. با این حال، ممکن است برای هر مجموعه تولید فایل مجزا از طریق دستورات دیگر قابل پیکربندی باشد. برای مثال، پیشوند مورد استفاده در تولید loopstats و peerstats را می‌توان با استفاده از گزینه statsdir که در بالا توضیح داده شد پیکربندی کرد.

این رشته مستقیماً به پیشوند ذکر شده در بالا الحاق می‌شود (بدون وجود ‘/’ در میان آن‌ها). این مقدار را می‌توان با استفاده از آرگومان file در دستور filegen تغییر داد. هیچ عنصری مانند .. در این جزء مجاز نیست تا از ارجاع نام فایل‌ها به بخش‌های خارج از سلسله‌مراتب سیستم‌فایل تعیین‌شده توسط prefix جلوگیری شود.

این بخش نمایانگر عناصر مجزای یک مجموعه فایل است. این بخش با توجه به نوع مجموعه فایل تولید می‌شود.

یک مجموعه تولید فایل با نوع آن مشخص می‌شود. انواع زیر پشتیبانی می‌شوند:

مجموعه فایل در واقع یک فایل منفرد ساده است.

به ازای هر نمونه از اجرای سرور ntpd، یک عنصر از مجموعه فایل استفاده می‌شود. این نوع در زمان اجرا تغییری روی اعضای مجموعه فایل ایجاد نمی‌کند، با این حال روش ساده‌ای را برای جداسازی فایل‌های متعلق به نمونه‌های مختلف اجرای سرور ntpd(1) فراهم می‌آورد. نام فایل عضو مجموعه با افزودن یک ‘.’ به رشته‌های الحاق‌شده prefix و filename و افزودن نمایش دهدهی شناسه پردازش (PID) مربوط به پردازش سرور ntpd(1) ساخته می‌شود.

به ازای هر روز یک عنصر مجموعه تولید فایل ایجاد می‌شود. یک روز به‌صورت بازه زمانی بین 00:00 تا 24:00 ساعت UTC تعریف می‌شود. پسوند عضو مجموعه فایل شامل یک ‘.’ و مشخصه روز به فرم YYYYMMdd است. YYYY یک شماره سال ۴ رقمی است (مثلاً 1992). MM یک شماره ماه دو رقمی است. dd یک شماره روز دو رقمی است. بنابراین، تمام اطلاعات نوشته‌شده در ۱۰ دسامبر ۱۹۹۲ در فایلی با نام prefix filename.19921210 قرار خواهد گرفت.

هر عضو مجموعه فایل حاوی داده‌های مربوط به یک هفته مشخص از سال است. اصطلاح هفته با محاسبه روز سال به پیمانه ۷ (modulo 7) تعریف می‌شود. عناصر چنین مجموعه فایل تولیدی با افزودن پسوند زیر به پایه نام فایل مجموعه فایل متمایز می‌شوند: یک نقطه، یک شماره سال ۴ رقمی، حرف W و یک شماره هفته ۲ رقمی. برای مثال، اطلاعات ۱۰ ژانویه ۱۹۹۲ در فایلی با پسوند قرار خواهد گرفت.

به ازای هر ماه یک عنصر مجموعه فایل تولیدی ایجاد می‌شود. پسوند نام فایل شامل یک نقطه، یک شماره سال ۴ رقمی و یک ماه ۲ رقمی است.

به ازای هر سال یک عنصر فایل تولیدی ایجاد می‌شود. پسوند نام فایل شامل یک نقطه و یک شماره سال ۴ رقمی است.

این نوع از مجموعه‌های تولید فایل، پس از هر ۲۴ ساعت کارکرد سرور، به یک عنصر جدید از مجموعه فایل تغییر می‌یابند. پسوند نام فایل شامل یک نقطه، حرف a و یک عدد ۸ رقمی است. این عدد نشان‌دهنده تعداد ثانیه‌هایی است که سرور در ابتدای دوره ۲۴ ساعته مربوطه در حال اجرا بوده است. اطلاعات تنها با تعیین enable در یک فایل تولیدی نوشته می‌شوند؛ با مشخص کردن disable از ایجاد خروجی جلوگیری می‌شود.

اینکه بتوان به عنصر فعلی یک مجموعه تولید فایل با نامی ثابت دسترسی داشت، بسیار سودمند است. این ویژگی با تعیین link فعال و با استفاده از nolink غیرفعال می‌شود. در صورت تعیین link، یک پیوند سخت (hard link) از عنصر فعلی مجموعه فایل به فایلی بدون پسوند ایجاد می‌شود. هنگامی که از قبل فایلی با این نام وجود داشته باشد و تعداد پیوندهای این فایل یک باشد، با افزودن یک نقطه، حرف C و شناسه پردازش (PID) فرآیند سرور ntpd(1) تغییر نام می‌یابد. هنگامی که تعداد پیوندها بیش از یک باشد، پیوند فایل حذف می‌شود. این ویژگی اجازه می‌دهد به فایل فعلی با یک نام ثابت دسترسی داشت.

قابلیت ثبت را فعال یا غیرفعال می‌کند.

دیمن ntpd(1) یک فهرست محدودیت همه‌منظوره بر پایه نشانی/ماسک را پیاده‌سازی می‌کند. این فهرست شامل مدخل‌های نشانی/تطابق است که ابتدا بر اساس افزایش مقادیر نشانی و سپس بر اساس افزایش مقادیر ماسک مرتب شده‌اند. یک تطابق زمانی رخ می‌دهد که AND بیتیِ ماسک و نشانی مبدأ بسته با AND بیتیِ ماسک و نشانی در فهرست برابر باشد. فهرست به ترتیب بررسی می‌شود و آخرین تطابقِ یافت‌شده، فلگ‌های محدودیت مرتبط با آن مدخل را تعیین می‌کند. اطلاعات تکمیلی و مثال‌ها را می‌توان در صفحه "Notes on Configuring NTP and Setting up a NTP Subnet" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) یافت.

سازوکار محدودیت در انطباق با خط‌مشی‌های دسترسی سرورهای زمان ستون فقرات اولیه NSFnet پیاده‌سازی شده بود. بعدها این سازوکار برای دفع حملات رمزنگاری و انسدادی (clogging) گسترش یافت. اگرچه این قابلیت ممکن است برای جلوگیری از ایجاد ترافیک سنگین و ازدحام توسط کلاینت‌های ناخواسته، معیوب یا مخرب بر روی سرورهای بی‌گناه مفید باشد، اما نباید به عنوان جایگزینی برای امکانات احراز هویت NTP در نظر گرفته شود. محدودیت‌های مبتنی بر نشانی مبدأ به سادگی توسط یک نفوذگر مصمم دور زده می‌شوند.

سرویس‌دهی به کلاینت‌ها می‌تواند رد شود چرا که آن‌ها صراحتاً در فهرست محدودیت ایجادشده توسط دستور restrict قرار گرفته‌اند، یا به صورت ضمنی در نتیجه نقض موارد رمزنگاری یا محدودیت نرخ. نقض‌های رمزنگاری شامل شکست در اعتبارسنجی گواهی یا هویت هستند؛ نقض‌های محدودیت نرخ معمولاً ناشی از پیاده‌سازی‌های معیوب NTP است که بسته‌ها را با نرخ‌های بیش از حد و سوءاستفاده‌گرانه ارسال می‌کنند. برخی تخلفات تنها برای بسته متخلف موجب رد سرویس می‌شوند، برخی دیگر باعث رد سرویس برای یک بازه زمانی مشخص می‌گردند و برخی دیگر باعث رد سرویس برای مدتی نامحدود می‌شوند. هنگامی که دسترسی یک کلاینت یا شبکه برای مدتی نامحدود رد می‌شود، در حال حاضر تنها راه برای لغو محدودیت‌ها راه‌اندازی مجدد سرور است.

به طور معمول، بسته‌هایی که از دریافت سرویس محروم می‌شوند صرفاً دور ریخته شده و اقدام دیگری به جز افزایش شمارنده‌های آماری انجام نمی‌گیرد. گاهی به پاسخی فعالانه‌تر نیاز است؛ مانند پیامی از سوی سرور که صراحتاً از کلاینت می‌خواهد ارسال را متوقف کرده و پیامی برای اپراتور سیستم باقی بگذارد. یک قالب بسته ویژه برای این منظور به نام بسته «بوسه مرگ» یا "kiss-of-death" (KoD) ایجاد شده است. بسته‌های KoD دارای بیت‌های جهش (leap bits) تنظیم‌شده بر روی حالت همگام‌نشده (unsynchronized)، لایه (stratum) تنظیم‌شده روی صفر، و فیلد شناسه مرجع (reference identifier) تنظیم‌شده روی یک کد اسکی چهار بایتی هستند. اگر فلگ noserve یا notrust در مدخل منطبق در فهرست محدودیت تنظیم شده باشد، کد برابر با "DENY" است؛ اگر فلگ limited تنظیم شده باشد و از حد مجاز نرخ فراتر رفته باشد، کد "RATE" است. در نهایت، اگر یک نقض رمزنگاری رخ دهد، کد برابر با "CRYP" خواهد بود.

کلاینتی که یک KoD دریافت می‌کند، مجموعه‌ای از بررسی‌های سلامت را برای به حداقل رساندن مخاطرات امنیتی انجام می‌دهد، سپس متغیرهای همتای stratum و شناسه مرجع را به‌روزرسانی کرده، بیت دسترسی رد شده (TEST4) را در متغیر فلشِ همتا تنظیم می‌کند و پیامی را به گزارش (log) ارسال می‌نماید. تا زمانی که بیت TEST4 تنظیم باشد، کلاینت هیچ بسته دیگری به سرور ارسال نخواهد کرد. در حال حاضر تنها راه برای بازیابی از این وضعیت، راه‌اندازی مجدد پروتکل در هر دو سمت کلاینت و سرور است. این امر در کلاینت زمانی که مهلت ارتباط (association) به پایان می‌رسد به طور خودکار رخ می‌دهد. در سرور تنها در صورتی رخ خواهد داد که اپراتور سرور همکاری کند.


تنظیم پارامترهای سازوکار limited که از سرور در برابر سوءاستفاده کلاینت محافظت می‌کند. زیردستور average حداقل فاصله زمانی میانگین بسته‌ها را بر حسب log2 ثانیه مشخص می‌کند که مقدار پیش‌فرض آن ۳ (۸ ثانیه) است، در حالی که زیردستور minimum حداقل فاصله بسته‌ها را بر حسب ثانیه مشخص می‌کند که پیش‌فرض آن ۲ است. بسته‌هایی که این مقادیر حداقل را نقض کنند دور ریخته شده و در صورت فعال بودن، یک بسته kiss-o'-death بازگردانده می‌شود. زیردستور monitor به طور غیرمستقیم احتمال جایگزینی قدیمی‌ترین مدخل از فهرست پایش (MRU) درخواست‌های اخیر را که برای اعمال کنترل‌های نرخ استفاده می‌شود، هنگامی که این فهرست در حداکثر اندازه خود است مشخص می‌کند. احتمال جایگزینی قدیمی‌ترین مدخل، سن آن مدخل بر حسب ثانیه تقسیم بر مقدار monitor است، با مقدار پیش‌فرض ۳۰۰۰. برای مثال، اگر قدیمی‌ترین مدخل در فهرست MRU نمایانگر درخواستی از ۳۰۰ ثانیه پیش باشد، به طور پیش‌فرض احتمال جایگزینی آن با مدخلی که نمایانگر درخواست کلاینت در حال پردازش کنونی است ۱۰٪ خواهد بود. برعکس، اگر سن قدیمی‌ترین مدخل بیش از ۳۰۰۰ ثانیه باشد، این احتمال ۱۰۰٪ است.

آرگومان address که به صورت عددی بیان می‌شود، نشانی یک میزبان یا شبکه است. همچنین، آرگومان address می‌تواند یک نام میزبان معتبر باشد. هنگامی که یک نام میزبان ارائه می‌شود، برای هر نشانی که نام میزبان به آن ترجمه می‌شود یک مدخل محدودیت ایجاد می‌گردد، و هر mask ارائه‌شده نادیده گرفته شده و یک ماسک میزبان مجزا برای هر مدخل به کار می‌رود. آرگومان mask که به صورت عددی بیان می‌شود، به طور پیش‌فرض دارای تمام بیت‌های فعال (یک) است، به این معنی که address به عنوان نشانی یک میزبان مجزا تلقی می‌شود. یک مدخل پیش‌فرض با نشانی و ماسک تماماً صفر همواره گنجانده شده و همیشه اولین مدخل در فهرست است. توجه داشته باشید که رشته متنی default، بدون گزینه mask، ممکن است برای مشخص کردن مدخل پیش‌فرض استفاده شود. دستورالعمل ippeerlimit تعداد درخواست‌های همتا (peer) را برای هر IP به int محدود می‌کند، که در آن مقدار -1 به معنای "unlimited" (نامحدود)، یعنی پیش‌فرض فعلی است. مقدار 0 به معنای "none" (هیچ) است. معمولاً حداکثر ۱ درخواست ارتباط همتا به ازای هر IP وجود دارد، اما اگر درخواست‌های ریموتِ همتا پشت یک پروکسی باشند، ممکن است به ازای هر IP بیش از ۱ مورد وجود داشته باشد. در پیاده‌سازی کنونی، flag همیشه دسترسی را محدود می‌کند، یعنی یک مدخل بدون هیچ فلگی نشان می‌دهد که دسترسی آزاد به سرور داده می‌شود. فلگ‌ها متعامد (مستقل) نیستند، بدین معنا که فلگ‌های محدودکننده‌تر اغلب فلگ‌های کمتر محدودکننده را زائد می‌سازند. فلگ‌ها را می‌توان به طور کلی به دو دسته طبقه‌بندی کرد: آن‌هایی که سرویس زمان را محدود می‌کنند و آن‌هایی که پرس‌وجوهای اطلاعاتی و تلاش‌ها برای پیکربندی مجدد سرور در زمان اجرا را محدود می‌سازند. یک یا چند مورد از فلگ‌های زیر را می‌توان مشخص کرد:

رد کردن بسته‌ها از هر نوعی، از جمله پرس‌وجوهای ntpq(1) و ntpdc(1).

اگر این فلگ هنگام رخ دادن تخلف نرخ تنظیم شده باشد، گاهی یک بسته kiss-o'-death (KoD) ارسال می‌شود. بسته‌های KoD دارای محدودیت نرخ به حداکثر یک بسته در هر حداقل فاصله میانگین بین بسته‌ها هستند که توسط discard average تعیین شده و پیش‌فرض آن 8s است. در غیر این صورت، هیچ پاسخی ارسال نمی‌شود.

رد سرویس‌دهی در صورتی که فاصله زمانی بسته‌ها، محدودیت‌های پایینی مشخص‌شده در دستور discard را نقض کند. تاریخچه‌ای از کلاینت‌ها با استفاده از قابلیت پایش ntpd(1) نگهداری می‌شود. بنابراین، تا زمانی که یک مدخل محدودیت با فلگ limited وجود داشته باشد، پایش همواره فعال است.

اعلام تله‌های تنظیم‌شده توسط میزبان‌های منطبق به عنوان اولویت پایین. تعداد تله‌هایی که یک سرور می‌تواند نگه دارد محدود است (محدودیت فعلی ۳ است). تله‌ها معمولاً بر اساس حق تقدم ورود (نوبت اول) تخصیص داده می‌شوند و به درخواست‌کنندگان بعدی تله سرویس داده نمی‌شود. این فلگ با مجاز کردن جایگزینی درخواست‌های بعدی برای تله‌های با اولویت عادی به جای تله‌های با اولویت پایین، الگوریتم تخصیص را تغییر می‌دهد.

رد درخواست‌های همتای موقت (ephemeral peer)، حتی اگر از یک منبع احراز هویت‌شده بیایند. توجه داشته باشید که امکان استفاده از یک کلید متقارن برای احراز هویت ممکن است از طریق فیلد سوم فایل ntp.keys به یک یا چند IP یا زیرشبکه محدود شده باشد. این محدودیت به صورت پیش‌فرض فعال نیست تا سازگاری رو به عقب حفظ شود. انتظار می‌رود noepeer در نسخه ntp-4.4 به حالت پیش‌فرض تبدیل شود.

رد پرس‌وجوهای ntpq(1) و ntpdc(1) که قصد تغییر وضعیت سرور را دارند (یعنی پیکربندی مجدد در زمان اجرا). پرس‌وجوهایی که اطلاعات بازمی‌گردانند مجاز هستند.

رد پرس‌وجوهای ntpq(1) و ntpdc(1). سرویس زمان تحت تأثیر قرار نمی‌گیرد.

رد بسته‌های احراز هویت‌نشده که منجر به تشکیل یک ارتباط (association) جدید می‌شوند. این شامل بسته‌های پخشی (broadcast) و متقارن فعال در زمانی که یک ارتباط پیکربندی‌شده وجود ندارد می‌شود. همچنین شامل ارتباط‌های pool نیز می‌شود، بنابراین اگر می‌خواهید از سرورهای یک دستورالعمل pool استفاده کنید و همچنین مایلید به طور پیش‌فرض از nopeer استفاده کنید، به یک خط restrict source ... نیز نیاز دارید که شامل دستورالعمل nopeer not نباشد.

رد تمام بسته‌ها به جز پرس‌وجوهای ntpq(1) و ntpdc(1).

خودداری از ارائه سرویس تله پیام کنترلی mode 6 به میزبان‌های منطبق. سرویس تله زیرسیستمی از پروتکل پیام کنترلی ntpq(1) است که برای استفاده برنامه‌های ثبت وقایع از راه دور طراحی شده است.

رد سرویس‌دهی مگر اینکه بسته از نظر رمزنگاری احراز هویت شده باشد.

این در واقع یک اصلاح‌کننده الگوریتم تطابق است تا یک فلگ محدودیت. حضور آن باعث می‌شود مدخل محدودیت تنها در صورتی منطبق شود که پورت مبدأ در بسته، پورت استاندارد UDP مربوط به NTP (پورت ۱۲۳) باشد. اگر یکی از آن‌ها ntpport را مشخص کند و دیگری نکند، می‌توان دو مدخل محدودیت با نشانی IP یکسان داشت. مدخل ntpport خاص‌تر در نظر گرفته می‌شود و در فهرست دیرتر مرتب می‌شود.

هنگام پاسخ دادن به درخواست‌های سرور، بیت‌های مرتبه پایینِ reftime را مبهم‌سازی (fuzz) می‌کند.

رد بسته‌هایی که با نسخه فعلی NTP مطابقت ندارند.

مدخل‌های پیش‌فرض فهرست محدودیت با فلگ‌های ignore، interface و ntpport برای هر یک از نشانی‌های رابط میزبان محلی در هنگام راه‌اندازی در جدول درج می‌شوند تا از تلاش ntpd برای همگام‌سازی با خودش جلوگیری کنند، مانند زمانی با manycastclient وقتی که manycast نیز با همان نشانی چندپخشی (multicast) مشخص شده است. یک مدخل پیش‌فرض نیز همواره وجود دارد، اگرچه در صورتی که طور دیگری پیکربندی نشده باشد، هیچ فلگی با مدخل پیش‌فرض مرتبط نیست (یعنی همه چیز به جز سرور NTP خودتان بدون محدودیت است).


حذف یک محدودیت از پیش تنظیم‌شده. این قابلیت برای پیکربندی در زمان اجرا از طریق ntpq(1) مفید است. اگر source مشخص شده باشد، یک محدودیت پویا که از الگوی restrict source در زمان اضافه شدن یک ارتباط ایجاد شده بود حذف می‌شود. بدون source یک محدودیت ایستا حذف خواهد شد.

چندپخشی (Manycasting) یک الگوی کشف و پیکربندی خودکار است که به‌تازگی در NTPv4 معرفی شده است. این قابلیت به‌منظور روشی برای یک کلاینت چندپخشی (multicast) طراحی شده است تا در محدوده شبکه اطراف به جستجو پرداخته و سرورهای manycast همکار را بیابد، آن‌ها را با استفاده از روش‌های رمزنگاری اعتبارسنجی کند و مقادیر زمانی آن‌ها را نسبت به سایر سرورهایی که ممکن است در مجاورت حضور داشته باشند ارزیابی نماید. نتیجه مورد انتظار این است که هر کلاینت manycast ارتباطات کلاینتی را با تعدادی از «بهترین» سرورهای manycast مجاور برقرار سازد، با این حال در صورت خرابی هر یک از سرورها، به‌طور خودکار پیکربندی مجدد انجام دهد تا این تعداد سرور حفظ شود.

توجه داشته باشید که الگوی manycasting با الگوی anycast توصیف‌شده در RFC-1546، که برای یافتن یک سرور منفرد از میان گروهی از سرورهای ارائه‌دهنده یک سرویس یکسان طراحی شده است، همخوانی ندارد. الگوی manycast برای یافتن چندین سرور افزونه (redundant) طراحی شده است که معیارهای بهینگیِ تعریف‌شده را برآورده می‌کنند.

قابلیت Manycasting می‌تواند با رمزنگاری کلید متقارن یا رمزنگاری کلید عمومی مورد استفاده قرار گیرد. زیرساخت کلید عمومی (PKI) بهترین حفاظت را در برابر کلیدهای افشاشده ارائه می‌دهد و عموماً قوی‌تر در نظر گرفته می‌شود، دست‌کم با اندازه کلیدهای نسبتاً بزرگ. این قابلیت با استفاده از پروتکل Autokey و کتابخانه رمزنگاری OpenSSL موجود در http://www.openssl.org پیاده‌سازی شده است. این کتابخانه می‌تواند با سایر حالت‌های NTPv4 نیز استفاده شود و استفاده از آن، به‌ویژه برای حالت‌های پخش همگانی (broadcast)، اکیداً توصیه می‌شود.

یک ارتباط پایدار کلاینت manycast با استفاده از دستور manycastclient پیکربندی می‌شود، که مشابه دستور server است اما با یک آدرس گروه چندپخشی (کلاس D در IPv4 یا پیشوند FF در IPv6). سازمان IANA آدرس IPv4 با مقدار 224.1.1.1 و آدرس IPv6 با مقدار FF05::101 (محلی سایت) را برای NTP تعیین کرده است. هنگامی که به سرورهای بیشتری نیاز باشد، پیام‌های کلاینت manycast به این آدرس با حداقل نرخ ممکن و حداقل هاپ‌های طول عمر (TTL) امکان‌پذیر، بسته به این که تاکنون چه تعداد سرور پیدا شده است، ارسال می‌شوند. به تعداد آدرس‌های گروه مختلف می‌تواند ارتباط کلاینت manycast وجود داشته باشد، که هر یک به عنوان الگویی برای یک ارتباط موقت تک‌پخشی (unicast) کلاینت/سرور در آینده عمل می‌کند.

سرورهای Manycast که با دستور manycastserver پیکربندی شده‌اند، روی آدرس گروه مشخص‌شده به پیام‌های کلاینت manycast گوش می‌دهند. به تمایز میان کلاینت manycast که فعالانه پیام‌ها را ارسال می‌کند، و سرور manycast که به‌صورت غیرفعال به آن‌ها پاسخ می‌دهد، توجه داشته باشید. اگر یک سرور manycast در محدوده TTL جاری باشد و خودش با یک منبع معتبر همگام شده باشد و در سطح لایه‌ای (stratum) برابر یا پایین‌تر از کلاینت manycast کار کند، به پیام کلاینت manycast با یک پیام معمولی سرور تک‌پخشی (unicast) پاسخ می‌دهد.

کلاینت manycast پس از دریافت این پیام، یک ارتباط کلاینت/سرور موقت (ephemeral) را مطابق با الگوی کلاینت manycast منطبق برقرار می‌سازد، اما فقط در صورتی که از نظر رمزنگاری احراز هویت شده باشد و لایه (stratum) سرور کمتر یا مساوی با لایه کلاینت باشد. احراز هویت صراحتاً الزامی است و می‌توان از کلید متقارن یا کلید عمومی (Autokey) استفاده کرد. سپس، کلاینت از سرور در آدرس تک‌پخشی آن در حالت burst پرس‌وجو می‌کند تا ساعت میزبان را با اطمینان تنظیم کرده و منبع را اعتبارسنجی نماید. این کار معمولاً منجر به یک رگبار هشت‌تایی کلاینت/سرور در فواصل ۲ ثانیه‌ای می‌شود که در طی آن هر دو پروتکل همگام‌سازی و رمزنگاری به‌طور همزمان اجرا می‌شوند. پس از این رگبار، کلاینت الگوریتم‌های تقاطع (intersection) و خوشه‌بندی (clustering) مربوط به NTP را اجرا می‌کند، که برای کنار گذاشتن تمام ارتباطات به جز «بهترین‌ها» بر اساس لایه و فاصله همگام‌سازی عمل می‌نمایند. ارتباطات باقی‌مانده سپس در حالت عادی کلاینت/سرور ادامه می‌یابند.

راهبرد پرس‌وجوی کلاینت manycast به‌گونه‌ای طراحی شده است که تا حد امکان حجم پیام‌های کلاینت manycast و اثرات انفجار درونی (implosion) ناشی از دریافت تقریباً همزمان پیام‌های سرور manycast را کاهش دهد. این راهبرد توسط دستورات پیکربندی manycastclient، tos و ttl تعیین می‌شود. فاصله زمانی پرس‌وجوی manycast معمولاً هشت برابر فاصله زمانی پرس‌وجوی سیستم است، که از مقدار minpoll مشخص‌شده در دستور manycastclient شروع شده و در شرایط عادی، تا مقدار maxpolll تعیین‌شده در این دستور افزایش می‌یابد. در ابتدا، مقدار TTL روی حداقل هاپ‌های مشخص‌شده توسط دستور ttl تنظیم می‌شود. در هر ارسال مجدد، مقدار TTL افزایش می‌یابد تا زمانی که به حداکثر هاپ‌های مشخص‌شده توسط این دستور برسد یا تعداد کافی از ارتباطات کلاینت پیدا شود. ارسال‌های مجدد بعدی از همان TTL استفاده می‌کنند.

کیفیت و قابلیت اطمینان مجموعه ارتباطات کشف‌شده توسط کلاینت manycast، با الگوریتم‌های تعدیل NTP و مقادیر minclock و minsane مشخص‌شده در دستور پیکربندی tos تعیین می‌شود. حداقل باید minsane سرور کاندید در دسترس باشد و الگوریتم‌های تعدیل حداقل minclock بازمانده تولید کنند تا ساعت همگام‌سازی شود. اصول توافق بیزانسی حداقل به چهار کاندید نیاز دارد تا یک ساعت خطاکار (falseticker) منفرد را به‌درستی کنار بگذارد. برای سازگاری با سیستم‌های قدیمی (legacy)، مقدار پیش‌فرض minsane برابر ۱ و مقدار پیش‌فرض minclock برابر ۳ است. برای سرویس manycast، به فرض اینکه حداقل این تعداد سرور در دسترس باشد، minsane باید صراحتاً روی ۴ تنظیم شود.

اگر حداقل minclock سرور پیدا شود، فاصله پرس‌وجوی manycast بلافاصله روی هشت برابر maxpoll تنظیم می‌شود. اگر در زمانی که TTL به حداکثر هاپ‌ها رسید، کمتر از minclock سرور پیدا شود، فاصله پرس‌وجوی manycast دو برابر می‌شود. برای هر ارسال پس از آن، فاصله پرس‌وجو دوباره دو برابر می‌شود تا زمانی که به حداکثرِ هشت برابر maxpoll برسد. ارسال‌های بعدی از همان مقادیر فاصله پرس‌وجو و TTL استفاده می‌کنند. توجه داشته باشید در حالی که تمام این مراحل در جریان است، هر ارتباط کلاینت/سرورِ یافت‌شده با فاصله زمانی پرس‌وجوی سیستم به‌طور عادی کار می‌کند.

مرزهای چندپخشی با محدوده مدیریتی معمولاً توسط پیکربندی مسیریاب شبکه و در مورد IPv6، با پیشوند محدوده پیوند/سایت مشخص می‌شوند. به‌طور پیش‌فرض، گام افزایش برای هاپ‌های TTL مقدار ۳۲ با شروع از ۳۱ است؛ با این حال، دستور پیکربندی ttl می‌تواند برای تغییر مقادیر جهت تطابق با قوانین محدوده (scope) استفاده شود.

اغلب مفید است که دامنه سرورهای قابل قبول را که می‌توانند توسط ارتباطات کلاینت manycast پیدا شوند، محدود نمود. از آنجا که سرورهای manycast تنها زمانی پاسخ می‌دهند که لایه (stratum) کلاینت مساوی یا بزرگ‌تر از لایه سرور باشد، سرورهای اولیه (لایه ۱) تنها سرورهای اولیه را در محدوده TTL پیدا خواهند کرد، که احتمالاً رایج‌ترین هدف است. با این حال، مگر آنکه به‌گونه دیگری پیکربندی شده باشد، تمام کلاینت‌های manycast در محدوده TTL در نهایت تمام سرورهای اولیه در محدوده TTL را خواهند یافت، که احتمالاً در شبکه‌های بزرگ متداول‌ترین هدف نیست. دستور tos می‌تواند برای تغییر این رفتار استفاده شود. انتخاب سرورهایی با لایه پایین‌تر از floor یا بالاتر از ceiling مشخص‌شده در دستور tos در طول فرایند گزینش به شدت منع می‌شود؛ با این حال، در صورتی که تعداد سرورهای درون محدوده TTL کمتر از minclock باشد، این سرورها ممکن است موقتاً پذیرفته شوند.

اقدامات فوق برای هر پیام کلاینت manycast، که در فاصله زمانی پرس‌وجوی تعیین‌شده تکرار می‌شود، رخ می‌دهد. با این حال، هنگامی که ارتباط کلاینت موقت برقرار شد، پاسخ‌های بعدی سرور manycast نادیده گرفته می‌شوند، چرا که منجر به ایجاد ارتباط تکراری خواهد شد. اگر در طول یک بازه پرس‌وجو تعداد ارتباطات کلاینت به زیر minclock کاهش یابد، تمام ارتباطات نمونه اولیه کلاینت manycast به بازه پرس‌وجو و هاپ‌های TTL اولیه بازنشانی می‌شوند و عملیات از ابتدا از سر گرفته می‌شود. اجتناب از ارسال مکرر پیام‌های کلاینت manycast مهم است، زیرا هر پیام مستلزم پاسخگویی تمام سرورهای manycast در محدوده TTL است. نتیجه این امر می‌تواند یک انفجار درونی (implosion)، چه کوچک یا بزرگ، بسته به تعداد سرورهای موجود در محدوده باشد. مقدار توصیه‌شده برای maxpoll برابر 12 (4,096 ثانیه) است.

پیکربندی یک میزبان هم به‌عنوان کلاینت manycast و هم به‌عنوان سرور manycast امکان‌پذیر و غالباً سودمند است. تعدادی میزبان که به این روش پیکربندی شده و یک آدرس گروهی مشترک داشته باشند، به‌طور خودکار خود را بر اساس لایه و فاصله همگام‌سازی در یک پیکربندی بهینه سازماندهی خواهند کرد. به‌عنوان مثال، یک زیرشبکه NTP متشکل از دو سرور اصلی و صد یا تعداد بیشتری کلاینت وابسته را در نظر بگیرید. به‌جز دو استثنا، تمام سرورها و کلاینت‌ها فایل‌های پیکربندی یکسانی دارند که شامل هر دو دستور multicastclient و multicastserver با استفاده از، برای نمونه، آدرس گروه چندپخشی 239.1.1.1 است. تنها استثنا این است که فایل پیکربندی هر سرور اولیه باید شامل دستوراتی برای منبع مرجع اولیه مانند یک گیرنده GPS باشد.

فایل‌های پیکربندی باقی‌مانده برای تمام سرورها و کلاینت‌های ثانویه محتوای یکسانی دارند، به‌جز دستور tos که برای هر سطح لایه مختص همان سطح است. برای سرورهای لایه ۱ و لایه ۲، این دستور ضروری نیست. برای سرورهای لایه ۳ و بالاتر، مقدار floor روی شماره لایه مورد نظر تنظیم می‌شود. بنابراین، تمام فایل‌های پیکربندی لایه ۳ یکسان هستند، تمام فایل‌های لایه ۴ یکسان هستند و به همین ترتیب.

هنگامی که عملیات در این سناریو تثبیت شد، سرورهای اولیه منبع مرجع اولیه و یکدیگر را پیدا خواهند کرد، زیرا هر دوی آن‌ها در یک لایه (1) کار می‌کنند، اما به هیچ سرور یا کلاینت ثانویه‌ای متصل نمی‌شوند، زیرا آن‌ها در لایه بالاتری کار می‌کنند. سرورهای ثانویه سرورهای موجود در همان سطح لایه را خواهند یافت. اگر یکی از سرورهای اصلی گیرنده GPS خود را از دست بدهد، به کار خود به‌عنوان یک کلاینت ادامه خواهد داد و سایر کلاینت‌ها ارتباط مربوطه را به اتمام رسانده (time out) و بر این اساس مجدداً ارتباط برقرار می‌کنند.

برخی از مدیران ترجیح می‌دهند از اجرای مداوم ntpd(1) خودداری کرده و sntp(1) یا ntpd(1) -q را به‌عنوان یک کار زمان‌بندی‌شده (cron job) اجرا نمایند. در هر دو صورت سرورها باید از قبل پیکربندی شوند و اگر در زمان اجرای cron job هیچ سروری در دسترس نباشد، برنامه با شکست مواجه می‌شود. یک کاربرد واقعاً جذاب از manycast با ntpd(1) -q است. برنامه بیدار می‌شود، محیط محلی را برای یافتن سرورهای مورد انتظار اسکن می‌کند، بهترین مورد را از میان آن‌ها انتخاب می‌نماید، ساعت را تنظیم می‌کند و سپس خارج می‌شود. نیازی نیست سرورها از قبل پیکربندی شوند و تمام کلاینت‌ها در سراسر شبکه می‌توانند فایل پیکربندی یکسانی داشته باشند.

هر بار که یک کلاینت manycast یک بسته در حالت کلاینت را به یک آدرس گروه چندپخشی ارسال می‌کند، تمام سرورهای manycast در محدوده، پاسخی شامل نام میزبان و واژه وضعیت (status word) تولید می‌کنند. سپس کلاینت‌های manycast پروتکل Autokey را اجرا می‌نمایند، که تمام گواهی‌های دخیل را جمع‌آوری و اعتبارسنجی می‌کند. به دنبال بازه زمانی burst، تمام موارد به‌جز سه بازمانده کنار گذاشته می‌شوند، اما گواهی‌ها در حافظه موقت (cache) محلی باقی می‌مانند. اغلب اتفاق می‌افتد که چندین ردپای امضای کامل از کلاینت به سرورهای اولیه به این شیوه جمع‌آوری شوند.

تقریباً هر یک ساعت یک بار یا کمتر در صورتی که فاصله زمانی پرس‌وجو از این فراتر رود، کلاینت فهرست کلید Autokey را بازتولید می‌کند. این امر به‌طور کلی در حالت کلاینت/سرور شفاف (غیرمحسوس) است. با این حال، تقریباً روزی یک بار مقدار خصوصی سرور که برای تولید کوکی‌ها استفاده می‌شود، همراه با تمام ارتباطات کلاینت manycast تازه‌سازی می‌شود. در این حالت تمام مقادیر رمزنگاری از جمله گواهی‌ها تازه‌سازی می‌شوند. اگر گواهی جدیدی از زمان آخرین مبدأ زمانی (epoch) تازه‌سازی تولید شده باشد، به‌طور خودکار تمام گواهی‌های قبلی را که احیاناً در حافظه کش گواهی قرار دارند، باطل می‌کند. همزمان، طرح manycast همه‌چیز را از ابتدا شروع می‌کند و حلقه گسترش‌یابنده به حداقل کاهش یافته و از آنجا ضمن جمع‌آوری تمام سرورهای موجود در محدوده افزایش می‌یابد.


این دستور روشی را برای به تاخیر انداختنِ پذیرش پرش‌های زمانی به عقب از سوی یک سرور برودکست، به تعداد مشخصی از فواصل زمانی پرس‌وجوی برودکست، فراهم می‌کند. انتظار می‌رود شبکه‌های زمانی پخش همگانی مورد اعتماد باشند. در صورتی که زمان یک سرور برودکست به عقب پرش کند، اینکه کلاینت‌ها این تغییر را در سریع‌ترین زمان ممکن متوجه شوند منفعتی آشکار دارد. با این حال، حملاتی نظیر حملات بازپخش (replay attacks) می‌توانند رخ دهند، و با اینکه تدابیر حفاظتی متعددی در حالت پخش همگانی تعبیه شده است، تلاش برای انجام حمله بازپخش امکان‌پذیر است. مقدار پیش‌فرض این متغیر 0 است، اما می‌تواند به هر تعداد فاصله زمانی پرس‌وجو بین 0 تا 4 تغییر یابد.


این دستور بر الگوریتم‌های انتخاب ساعت و خوشه‌بندی اثر می‌گذارد. می‌توان از آن برای تعیین کیفیت و تعداد همتایان مورد استفاده جهت همگام‌سازی ساعت سیستم استفاده کرد و بیشترین کاربرد را در حالت manycast دارد. متغیرها به شرح زیر عمل می‌کنند:

همتایانی با لایه‌های (strata) بالاتر از ceiling در صورتی که حداقل minclock همتا باقی مانده باشد، کنار گذاشته خواهند شد. مقدار پیش‌فرض این متغیر 15 است، اما می‌تواند به هر عددی از 1 تا 15 تغییر یابد.

این یک فلگ باینری است که پاسخ‌های سرور manycast به کلاینت‌های manycast با همان سطح لایه را فعال (0) یا غیرفعال (1) می‌کند. این گزینه برای کاهش اثرات انفجار درونی (implosion) در مواردی که تعداد زیادی کلاینت با سطح لایه یکسان حضور دارند، مفید است. حالت پیش‌فرض فعال بودن این پاسخ‌ها است.

همتایانی با لایه‌های پایین‌تر از floor در صورتی که حداقل minclock همتا باقی مانده باشد، کنار گذاشته خواهند شد. مقدار پیش‌فرض این متغیر 1 است، اما می‌تواند به هر عددی از 1 تا 15 تغییر یابد.

الگوریتم خوشه‌بندی مکرراً ارتباطات پرت (outlier) را دور می‌اندازد تا زمانی که حداکثر minclock ارتباط باقی بماند. مقدار پیش‌فرض این متغیر 3 است، اما می‌تواند به هر عددی از 1 تا تعداد منابع پیکربندی‌شده تغییر یابد.

این حداقل تعداد کاندیدهای در دسترس الگوریتم انتخاب ساعت است تا یک یا چند ساعت معتبر (truechimer) را برای الگوریتم خوشه‌بندی تولید کند. اگر تعداد کمتری از این مقدار در دسترس باشد، ساعت انضباط‌نیافته (undisciplined) خواهد بود و اجازه دارد آزادانه کار کند. مقدار پیش‌فرض برای سازگاری با سیستم‌های قدیمی (legacy) برابر 1 است. با این حال، طبق اصول توافق بیزانسی (Byzantine agreement)، minsane باید حداقل 4 باشد تا یک ساعت خطاکار (falseticker) منفرد را شناسایی و کنار بگذارد.

این دستور فهرستی از مقادیر TTL را به ترتیب صعودی مشخص می‌کند؛ حداکثر تا 8 مقدار را می‌توان تعیین کرد. در حالت manycast این مقادیر به نوبت در یک جستجوی حلقه گسترش‌یابنده (expanding-ring) استفاده می‌شوند. مقدار پیش‌فرض، هشت مضرب از 32 با شروع از 31 است.

دیمن نگارش ۴ NTP از حدود سه دوجین ساعت مرجع رادیویی، ماهواره‌ای و مودمی مختلف به همراه یک شبه‌ساعت ویژه که برای پشتیبان یا در مواقع عدم دسترسی به منبع ساعت دیگر استفاده می‌شود، پشتیبانی می‌کند. توضیحات دقیق راه‌اندازهای تک‌تک دستگاه‌ها و گزینه‌ها را می‌توان در صفحهٔ "Reference Clock Drivers" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) یافت. اطلاعات تکمیلی را می‌توان در صفحاتی که پیوند آن‌ها در آنجا قرار دارد، از جمله صفحات "Debugging Hints for Reference Clock Drivers" و "How To Write a Reference Clock Driver" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) پیدا کرد. علاوه بر این، پشتیبانی از سیگنال PPS همان‌طور که در صفحهٔ "Pulse-per-second (PPS) Signal Interfacing" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) شرح داده شده، در دسترس است. بسیاری از راه‌اندازها از ماژول‌های ویژهٔ line discipline/streams پشتیبانی می‌کنند که می‌توانند دقت کار با راه‌انداز را به طور چشمگیری بهبود بخشند. این موارد در صفحهٔ "Line Disciplines and Streams Drivers" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) شرح داده شده‌اند.

یک ساعت مرجع عموماً (هرچند نه همیشه) یک گیرندهٔ کد زمانی رادیویی است که با یک منبع زمان استاندارد مانند سرویس‌های ارائه‌شده توسط NRC در کانادا و NIST و USNO در ایالات متحده همگام شده است. رابط میان رایانه و گیرندهٔ کد زمانی به دستگاه وابسته است، اما معمولاً یک درگاه سریال است. یک راه‌انداز دستگاه مخصوص به هر ساعت مرجع باید انتخاب شده و در توزیع کامپایل شود؛ با این حال، اکثر ساعت‌های متداول رادیویی، ماهواره‌ای و مودمی به طور پیش‌فرض گنجانده شده‌اند. توجه داشته باشید که تلاش برای پیکربندی یک ساعت مرجع زمانی که راه‌انداز آن کامپایل نشده یا درگاه سخت‌فزاری به درستی پیکربندی نشده است، منجر به ثبت اخطاری تند در فایل ثبت وقایع سیستم (system log) می‌شود، اما در غیر این صورت خطری در پی ندارد.

برای اهداف پیکربندی، ntpd(1) تا جای ممکن با ساعت‌های مرجع به روشی مشابه با همتایان (peers) عادی NTP رفتار می‌کند. ساعت‌های مرجع با یک نشانی IP که از نظر نحوی صحیح اما از نظر مسیریابی نامعتبر است شناسایی می‌شوند تا از همتایان عادی NTP متمایز گردند. نشانی‌های ساعت مرجع به شکل 127.127.t.u, هستند، که در آن t یک عدد صحیح نشان‌دهندهٔ نوع ساعت و u بیانگر شمارهٔ واحد در محدوده 0-3 است. اگرچه ممکن است زیاده‌روی به نظر برسد، اما در واقع گاهی اوقات پیکربندی چندین ساعت مرجع از همان نوع مفید است، که در این صورت شماره‌های واحد باید یکتا باشند.

دستور server برای پیکربندی یک ساعت مرجع استفاده می‌شود، که در آن شناسهٔ address در آن دستور همان نشانی ساعت است. گزینه‌های key, version و ttl برای پشتیبانی از ساعت مرجع استفاده نمی‌شوند. گزینهٔ mode همان‌طور که در زیر شرح داده شده، برای پشتیبانی از ساعت مرجع اضافه شده است. گزینهٔ prefer می‌تواند برای ترغیب کارساز به اولویت دادن به یک ساعت مرجع با اشتیاقی بیشتر از سایر ساعت‌های مرجع یا همتایان مفید باشد. اطلاعات بیشتر دربارهٔ این گزینه را می‌توان در صفحهٔ "Mitigation Rules and the prefer Keyword" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) یافت. گزینه‌های minpoll و maxpoll تنها برای راه‌اندازهای ساعت منتخبی معنا دارند. برای اطلاعات تکمیلی به صفحات مستندات راه‌انداز تک‌تک ساعت‌ها مراجعه کنید.

دستور fudge برای ارائه اطلاعات تکمیلی برای راه‌اندازهای ساعت اختصاصی استفاده می‌شود و معمولاً بلافاصله پس از دستور server می‌آید. شناسهٔ address نشانی ساعت را مشخص می‌کند. گزینه‌های refid و stratum می‌توانند برای بازنویسی مقادیر پیش‌فرض دستگاه استفاده شوند. دو آفست زمانی اختیاری وابسته به دستگاه و چهار فلگ نیز وجود دارند که می‌توانند در دستور fudge گنجانده شوند.

شمارهٔ لایهٔ (stratum) یک ساعت مرجع به طور پیش‌فرض صفر است. از آنجا که دیمن ntpd(1) یک واحد به لایهٔ هر همتا اضافه می‌کند، یک کارساز اولیه معمولاً لایهٔ خارجی یک را نمایش می‌دهد. به منظور فراهم کردن پشتیبان‌های مهندسی‌شده، اغلب مفید است که لایهٔ ساعت مرجع بزرگتر از صفر مشخص شود. گزینهٔ stratum برای این منظور استفاده می‌شود. همچنین، در مواردی که هم یک ساعت مرجع و هم یک سیگنال انضباطی پالس بر ثانیه (PPS) دخیل هستند، مشخص کردن شناسه‌ای غیر از پیش‌فرض برای ساعت مرجع، بسته به راه‌انداز، مفید است. گزینهٔ refid برای این منظور استفاده می‌شود. به جز در مواردی که ذکر شده، این گزینه‌ها برای همه راه‌اندازهای ساعت اعمال می‌شوند.


این دستور می‌تواند برای پیکربندی ساعت‌های مرجع به روش‌های ویژه استفاده شود. گزینه‌ها به صورت زیر تفسیر می‌شوند:

ساعت مرجع را به عنوان ترجیح‌داده‌شده (preferred) نشانه‌گذاری می‌کند. در شرایط برابر، این میزبان برای همگام‌سازی از میان مجموعه‌ای از میزبان‌های به درستی فعال انتخاب خواهد شد. برای اطلاعات بیشتر به صفحهٔ "Mitigation Rules and the prefer Keyword" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) مراجعه کنید.

یک شماره حالت (mode) را مشخص می‌کند که به شیوه‌ای وابسته به دستگاه تفسیر می‌شود. به عنوان مثال، یک پروتکل شماره‌گیری را در راه‌انداز ACTS و یک زیرنوع دستگاه را در راه‌اندازهای parse انتخاب می‌کند.


این گزینه‌ها حداقل و حداکثر بازهٔ نظرسنجی (polling) را برای پیام‌های ساعت مرجع، به صورت توانی از ۲ بر حسب ثانیه مشخص می‌کنند برای بیشتر ساعت‌های مرجع با اتصال مستقیم، هر دو گزینهٔ minpoll و maxpoll به طور پیش‌فرض روی 6 (64 ثانیه) تنظیم شده‌اند. برای ساعت‌های مرجع مودمی، minpoll به طور پیش‌فرض روی 10 (17.1 دقیقه) و maxpoll به طور پیش‌فرض روی 14 (4.5 ساعت) تنظیم شده است. محدودهٔ مجاز بین 4 (16 ثانیه) تا 17 (36.4 ساعت) شامل هر دو است.

این دستور می‌تواند برای پیکربندی ساعت‌های مرجع به روش‌های ویژه استفاده شود. این دستور باید بلافاصله پس از دستور server که راه‌انداز را پیکربندی می‌کند، بیاید. توجه داشته باشید که همین قابلیت در زمان اجرا با استفاده از برنامهٔ ntpdc(1) امکان‌پذیر است. گزینه‌ها به صورت زیر تفسیر می‌شوند:

یک مقدار ثابت برای اضافه شدن به آفست زمانی تولیدشده توسط راه‌انداز را به صورت یک عدد اعشاری با ممیز ثابت بر حسب ثانیه مشخص می‌کند. این مقدار به عنوان یک ثابت کالیبراسیون برای تنظیم آفست زمانی اسمی یک ساعت خاص جهت مطابقت با یک استاندارد خارجی، مانند یک سیگنال دقیق PPS استفاده می‌شود. همچنین راهکاری برای تصحیح یک خطای سیستماتیک یا انحراف ناشی از تاخیرهای درگاه سریال یا سیستم‌عامل، طول‌های متفاوت کابل یا تاخیر داخلی گیرنده فراهم می‌کند. آفست مشخص‌شده علاوه بر تاخیر انتشار است که از راه‌های دیگر، مانند کلیدهای DIP داخلی فراهم شده است. در مواردی که کالیبراسیون برای یک سیستم و راه‌انداز خاص در دسترس است، یک تصحیح تقریبی در صفحات مستندات راه‌انداز ذکر شده است. نکته: به منظور تسهیل کالیبراسیون زمانی که بیش از یک ساعت رادیویی یا سیگنال PPS پشتیبانی می‌شود، یک ویژگی کالیبراسیون ویژه در دسترس است. این ویژگی به شکل یک شناسه برای دستور enable که در صفحهٔ Miscellaneous Options شرح داده شده است، وجود دارد و طبق آنچه در صفحهٔ "Reference Clock Drivers" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp) آمده است کار می‌کند.

یک عدد اعشاری با ممیز ثابت بر حسب ثانیه را مشخص می‌کند که به شیوه‌ای وابسته به راه‌انداز تفسیر می‌شود. به توضیحات مربوط به راه‌اندازهای خاص در صفحهٔ "Reference Clock Drivers" (موجود به عنوان بخشی از مستندات HTML ارائه‌شده در /usr/share/doc/ntp ). مراجعه کنید.

شمارهٔ لایهٔ (stratum) اختصاص‌یافته به راه‌انداز را مشخص می‌کند که یک عدد صحیح بین 0 و 15 است. این عدد، شماره لایهٔ پیش‌فرضی را که معمولاً توسط خود راه‌انداز اختصاص می‌یابد (معمولاً صفر)، بازنویسی می‌کند.

یک رشتهٔ اسکی از یک تا چهار نویسه را مشخص می‌کند که شناسهٔ مرجع استفاده‌شده توسط راه‌انداز را تعیین می‌نماید. این رشته، شناسهٔ پیش‌فرضی را که معمولاً توسط خود راه‌انداز اختصاص داده می‌شود بازنویسی می‌کند.

یک شماره حالت (mode) را مشخص می‌کند که به شیوه‌ای وابسته به دستگاه تفسیر می‌شود. به عنوان مثال، یک پروتکل شماره‌گیری را در راه‌انداز ACTS و یک زیرنوع دستگاه را در راه‌اندازهای parse انتخاب می‌کند.




این چهار فلگ برای سفارشی‌سازی راه‌انداز ساعت به کار می‌روند. تفسیر این مقادیر، و اینکه آیا اصلاً استفاده می‌شوند یا خیر، به راه‌انداز ساعت مورد نظر بستگی دارد. با این حال، طبق قرارداد، flag4 برای فعال‌سازی ثبت داده‌های پایش در فایل clockstats که با دستور filegen پیکربندی شده است، استفاده می‌شود. اطلاعات بیشتر دربارهٔ دستور filegen را می‌توان در Monitoring Options یافت.


حالت‌های برودکست (پخش همگانی) و چندپخشی (multicast) به یک کالیبراسیون ویژه برای تعیین تاخیر شبکه میان کارسازهای محلی و دوردست نیاز دارند. به‌طور معمول، این کار به صورت خودکار از طریق تبادلات اولیه پروتکل میان کلاینت و کارساز انجام می‌شود. در برخی موارد، ممکن است روند کالیبراسیون برای مثال به دلیل کنترل‌های دسترسی شبکه یا کارساز با شکست مواجه شود. این دستور تاخیر پیش‌فرضی را که باید تحت این شرایط استفاده شود مشخص می‌کند. معمولاً (برای اترنت)، عددی بین 0.003 و 0.007 ثانیه مناسب است. مقدار پیش‌فرض در صورت عدم استفاده از این دستور، 0.004 ثانیه است.

این دستور مسیر کامل و نام فایلی را مشخص می‌کند که برای ثبت بسامد نوسان‌ساز ساعت محلی به کار می‌رود. این عملیات مشابه گزینه خط فرمان -f است. اگر فایل موجود باشد، در هنگام راه‌اندازی به منظور تنظیم بسامد اولیه خوانده شده و سپس ساعتی یک بار با بسامد فعلی محاسبه‌شده توسط دیمن به‌روزرسانی می‌شود. اگر نام فایل مشخص شده باشد، اما خود فایل وجود نداشته باشد، دیمن با بسامد اولیه صفر شروع به کار کرده و هنگام اولین بار نوشتن، فایل را ایجاد می‌کند. اگر این دستور داده نشود، دیمن همواره با بسامد اولیه صفر شروع خواهد شد.

قالب این فایل شامل یک خط منفرد حاوی یک عدد اعشاری ممیز شناور است که انحراف بسامد را بر حسب بخش در میلیون (PPM) ثبت می‌کند. این فایل ابتدا با نوشتن مقدار رانش جاری در یک فایل موقت و سپس تغییر نام این فایل برای جایگزینی نسخه قدیمی به‌روزرسانی می‌شود. این بدان معناست که ntpd(1) باید مجوز نوشتن در پوشه‌ای که فایل رانش در آن قرار دارد را داشته باشد، و این‌که باید از پیوندهای سیستم فایل، چه نمادین یا غیر آن، خودداری شود.


این گزینه مقدار Differentiated Services Control Point (DSCP) را مشخص می‌کند که یک کد ۶ بیتی است. مقدار پیش‌فرض 46 است که نشان‌دهنده Expedited Forwarding می‌باشد.


روشی برای فعال یا غیرفعال کردن گزینه‌های مختلف کارساز فراهم می‌کند. فلگ‌هایی که ذکر نشده‌اند تحت تاثیر قرار نمی‌گیرند. توجه داشته باشید که تمامی این فلگ‌ها را می‌توان از راه دور با استفاده از برنامه کمکی ntpdc(1) کنترل کرد.

به کارساز امکان می‌دهد تنها در صورتی با همتایان پیکربندی‌نشده همگام شود که همتا با استفاده از رمزنگاری کلید عمومی یا کلید خصوصی به درستی احراز هویت شده باشد. مقدار پیش‌فرض برای این فلگ enable است.

به کارساز امکان می‌دهد تا برای دریافت پیامی از یک کارساز برودکست یا چندپخشی، همانند دستور multicastclient با نشانی پیش‌فرض، به گوش بایستد. مقدار پیش‌فرض برای این فلگ disable است.

ویژگی calibrate (کالیبراسیون) را برای ساعت‌های مرجع فعال می‌کند. مقدار پیش‌فرض برای این فلگ disable است.

در صورت در دسترس بودن، انضباط زمانی هسته (kernel time discipline) را فعال می‌کند. مقدار پیش‌فرض برای این فلگ در صورت وجود پشتیبانی enable و در غیر این صورت disable است.

پردازش درخواست‌های وابسته به پیاده‌سازی NTP mode 7 را که توسط برنامه منسوخ‌شده ntpdc(1) استفاده می‌شوند فعال می‌کند. مقدار پیش‌فرض برای این فلگ disable است. این فلگ از پیکربندی زمان اجرا با استفاده از ntpq(1) مستثنی شده است. برنامه ntpq(1) همان قابلیت‌های ntpdc(1) را با استفاده از درخواست‌های استاندارد mode 6 فراهم می‌کند.

امکانات پایش (monitoring) را فعال می‌کند. برای اطلاعات بیشتر به برنامه ntpdc(1) و دستور monlist مراجعه کنید. مقدار پیش‌فرض برای این فلگ enable است.

انضباط زمان و بسامد را فعال می‌کند. در واقع، این سوییچ حلقه بازخورد را باز و بسته می‌کند که برای آزمایش مفید است. مقدار پیش‌فرض برای این فلگ enable است.

به‌طور پیش‌فرض، اگر ntpd(1) از autokey استفاده کند و یک بسته crypto-NAK دریافت کند که بررسی‌های بسته تکراری و برچسب زمانی مبدا را با موفقیت پشت سر بگذارد، متغیرهای همتا بلافاصله پاک می‌شوند. اگرچه این ویژگی عموماً یک مزیت است زیرا امکان بازیابی سریع را در صورت تغییر کلید کارساز فراهم می‌کند، اما یک بسته crypto-NAK که به درستی جعل شده و در زمان مناسب تحویل داده شود می‌تواند در یک حمله DoS به کار رود. اگر با این نوع حمله DoS مشکلات فعال و محسوسی دارید، باید غیرفعال کردن این گزینه را در نظر بگیرید. می‌توانید فایل peerstats خود را برای یافتن شواهدی از هر یک از این حملات بررسی کنید. مقدار پیش‌فرض برای این فلگ enable است.

امکانات آمارگیری را فعال می‌کند. برای اطلاعات بیشتر بخش Monitoring Options را ببینید. مقدار پیش‌فرض برای این فلگ disable است.

به‌طور پیش‌فرض، اگر ntpd(1) بسته autokey دریافت کند که در TEST9 (شکست رمزنگاری) رد شود، اتصال بلافاصله پاک می‌شود. این ویژگی تقریباً به طور قطع یک مزیت است، اما اگر با وجود توصیه فعلی مبنی بر عدم استفاده از autokey، شما همچنان از autokey استفاده می‌کنید و شاهد این نوع حمله DoS هستید، غیرفعال کردن این فلگ قطع ارتباط را تا زمانی که شمارنده دسترسی‌پذیری به صفر برسد به تاخیر می‌اندازد. می‌توانید فایل peerstats خود را برای یافتن شواهدی از هر یک از این حملات بررسی کنید. مقدار پیش‌فرض برای این فلگ enable است.

به‌طور پیش‌فرض، اگر ntpd(1) یک بسته crypto-NAK دریافت کند که بررسی‌های بسته تکراری و برچسب زمانی مبدا را با موفقیت پشت سر بگذارد، اتصال بلافاصله پاک می‌شود. اگرچه این ویژگی عموماً یک مزیت است زیرا امکان بازیابی سریع را در صورت تغییر کلید کارساز فراهم می‌کند، اما یک بسته crypto-NAK که به درستی جعل شده و در زمان مناسب تحویل داده شود می‌تواند در یک حمله DoS به کار رود. اگر با این نوع حمله DoS مشکلات فعال و محسوسی دارید، باید غیرفعال کردن این گزینه را در نظر بگیرید. می‌توانید فایل peerstats خود را برای یافتن شواهدی از هر یک از این حملات بررسی کنید. مقدار پیش‌فرض برای این فلگ enable است.

به‌طور پیش‌فرض، اگر ntpd(1) بسته‌ای را دریافت کند که باید احراز هویت شده باشد و سایر بررسی‌های سلامت بسته را با موفقیت پشت سر بگذارد اما حاوی یک خلاصه (digest) نامعتبر باشد، اتصال بلافاصله پاک می‌شود. اگرچه این ویژگی عموماً یک مزیت است زیرا امکان بازیابی سریع را فراهم می‌کند، اما اگر این نوع بسته به دقت جعل شده و در بازه زمانی مناسبی ارسال شود، می‌تواند برای یک حمله DoS استفاده شود. اگر با این نوع حمله DoS مشکلات فعال و محسوسی دارید، باید غیرفعال کردن این گزینه را در نظر بگیرید. می‌توانید فایل peerstats خود را برای یافتن شواهدی از هر یک از این حملات بررسی کنید. مقدار پیش‌فرض برای این فلگ enable است.

این دستور اجازه می‌دهد دستورات پیکربندی اضافی از یک فایل جداگانه گنجانده (include) شوند. فایل‌های گنجانده‌شده می‌توانند تا عمق پنج سطح تو در تو باشند؛ پس از رسیدن به انتهای هر فایل گنجانده‌شده، پردازش دستورات در فایل پیکربندی قبلی از سر گرفته می‌شود. این گزینه برای مراکزی مفید است که ntpd(1) را روی چندین میزبان با گزینه‌های (عمدتاً) مشترک (مانند یک فهرست محدودیت) اجرا می‌کنند.

دستورالعمل interface کنترل می‌کند که ntpd(1) کدام نشانی‌های شبکه را باز کند، و این‌که آیا ورودی بدون پردازش دور ریخته شود یا خیر. پارامتر اول، اقدام مربوط به نشانی‌هایی را که با پارامتر دوم مطابقت دارند تعیین می‌کند. پارامتر دوم دسته‌ای از نشانی‌ها، یا یک نام واسط خاص، یا یک نشانی را مشخص می‌کند. در حالت نشانی، prefixlen تعیین می‌کند چه تعداد بیت باید برای اعمال این قاعده مطابقت داشته باشند. ignore از باز شدن نشانی‌های منطبق جلوگیری می‌کند؛ drop باعث می‌شود ntpd(1) نشانی را باز کند و تمامی بسته‌های دریافتی را بدون بررسی دور بیندازد. می‌توان از چندین دستورالعمل interface استفاده کرد. آخرین قاعده‌ای که با یک نشانی مشخص مطابقت داشته باشد، اقدام مربوط به آن را تعیین می‌کند. دستورالعمل‌های interface در صورتی که هر یک از گزینه‌های خط فرمان -I, --interface, -L, یا --novirtualips مشخص شده باشند غیرفعال می‌شوند؛ در صورتی که در فایل پیکربندی مشخص نشوند، تمامی نشانی‌های شبکه در دسترس باز می‌شوند. دستورالعمل nic یک نام مستعار برای interface است.

این دستور فایل ثانیه‌های کبیسه IERS را بارگذاری کرده و مقادیر ثانیه کبیسه را برای رویداد ثانیه کبیسه بعدی، زمان انقضای فایل leapfile و انحراف TAI مقداردهی اولیه می‌کند. این فایل را می‌توان مستقیماً از IERS به نشانی https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list یا ftp://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list به دست آورد. فایل leapfile هنگامی پویش می‌شود که ntpd(1) دستورالعمل leapfile را پردازش کند یا زمانی که ntpd تشخیص دهد که leapfile تغییر کرده است. ntpd روزی یک بار بررسی می‌کند تا ببیند آیا leapfile تغییر کرده است یا خیر. اسکریپت update-leap(1update_leapmdoc) می‌تواند اجرا شود تا بررسی کند آیا leapfile باید به‌روزرسانی شود یا خیر.

این گزینه آزمایشی (EXPERIMENTAL) تنها زمانی در دسترس است که ntpd(1) با گزینه --enable-leap-smear در اسکریپت configure ساخته شده باشد. این گزینه بازه‌ای را مشخص می‌کند که طی آن تصحیح ثانیه کبیسه اعمال خواهد شد. مقادیر پیشنهادی برای این گزینه بین 7200 (۲ ساعت) و 86400 (۲۴ ساعت) است. برای اطلاعات بیشتر به http://bugs.ntp.org/2855 مراجعه کنید.

این دستور میزان و نوع خروجی نوشته‌شده در سرویس syslog(3) سیستم یا فایل ثبت وقایع جایگزین logfile را کنترل می‌کند. به‌طور پیش‌فرض، تمام خروجی‌ها فعال هستند. تمامی کلمات کلیدی configkeyword می‌توانند با پیشوندهای ‘=’، ‘+’ و ‘-’ همراه شوند، که در آن ‘=’ ماسک اولویت syslog(3) را تنظیم می‌کند، ‘+’ پیام‌ها را اضافه و ‘-’ پیام‌ها را حذف می‌نماید. پیام‌های syslog(3) را می‌توان در چهار دسته کنترل کرد (clock، peer، sys و sync). درون این دسته‌ها، چهار نوع پیام را می‌توان کنترل کرد: پیام‌های اطلاعاتی (info)، پیام‌های رویداد (events)، پیام‌های آماری (statistics) و پیام‌های وضعیت (status).

کلمات کلیدی پیکربندی از پیوند دادن دسته پیام با دسته رویداد تشکیل می‌شوند. می‌توان از پیشوند all به جای دسته پیام استفاده کرد. همچنین می‌تواند پس از یک دسته پیام، کلمه کلیدی all قرار گیرد تا تمامی پیام‌های دسته پیام مربوطه فعال یا غیرفعال شوند. بنابراین، یک پیکربندی حداقلی ثبت وقایع می‌تواند به این صورت باشد: 

logconfig =syncstatus +sysevents

این کار فقط وضعیت همگام‌سازی ntpd(1) و رویدادهای اصلی سیستم را فهرست می‌کند. برای یک کارساز مرجع ساده، پیکربندی حداقلی پیام زیر می‌تواند مفید باشد: 

logconfig =syncall +clockall

این پیکربندی تمامی اطلاعات ساعت و اطلاعات همگام‌سازی را فهرست خواهد کرد. تمامی رویدادها و پیام‌های دیگر درباره همتایان، رویدادهای سیستم و غیره متوقف می‌شوند.


این دستور مکان یک فایل لاگ جایگزین را برای استفاده به‌جای امکانات پیش‌فرض syslog(3) سیستم مشخص می‌کند. این عملکرد مشابه گزینه خط فرمان -l است.

محدودیت‌های اندازه فهرست «اخیراً استفاده‌شده» (MRU) نشانی‌های کلاینت در بخش پایش را کنترل می‌کند که توسط بخش کنترل نرخ (rate control) نیز استفاده می‌شود.


حدود بالای معادل برای اندازه فهرست MRU، بر حسب تعداد مدخل‌ها یا کیلوبایت. حد واقعی می‌تواند تا incalloc مدخل یا incmem کیلوبایت بزرگ‌تر باشد. همانند تمام گزینه‌های mru ارائه‌شده در واحدهای تعداد مدخل یا کیلوبایت، اگر هر دو گزینه maxdepth و maxmem استفاده شوند، آخرین گزینه مشخص‌شده اولویت خواهد داشت. مقدار پیش‌فرض 1024 کیلوبایت است.

حد پایین اندازه فهرست MRU. هنگامی که فهرست MRU کمتر از mindepth مدخل داشته باشد، مدخل‌های موجود هرگز برای باز کردن فضا برای مدخل‌های جدیدتر حذف نمی‌شوند، صرف‌نظر از اینکه چقدر قدیمی باشند. مقدار پیش‌فرض 600 مدخل است.

زمانی که فهرست MRU به تعداد mindepth مدخل داشته باشد و قرار باشد یک کلاینت اضافی به فهرست افزوده شود، اگر قدیمی‌ترین مدخل بیش از maxage ثانیه پیش به‌روزرسانی شده باشد، آن مدخل حذف شده و فضای ذخیره‌سازی آن دوباره استفاده می‌شود. اگر قدیمی‌ترین مدخل اخیراً به‌روزرسانی شده باشد، فهرست MRU با رعایت محدودیت maxdepth / maxmem گسترش می‌یابد. مقدار پیش‌فرض 64 ثانیه است.


تخصیص حافظه اولیه در زمان نخستین فعال‌سازی امکانات پایش، بر حسب تعداد مدخل‌ها یا کیلوبایت. مقدار پیش‌فرض 4 کیلوبایت است.


اندازه تخصیص حافظه اضافی هنگام گسترش فهرست MRU، بر حسب مدخل‌ها یا کیلوبایت. مقدار پیش‌فرض 4 کیلوبایت است.

مقدار دلتای threshold (آستانه) را بر حسب ثانیه مشخص می‌کند که پیش از نوشتن تغییر ساعتی در driftfile (فایل فرکانس) باید برآورده شود؛ با مقدار پیش‌فرض 1e-7 (برابر با 0.1 PPM). فایل فرکانس هر ساعت بررسی می‌شود. اگر اختلاف بین فرکانس فعلی و آخرین مقدار نوشته‌شده از آستانه فراتر رود، فایل نوشته شده و مقدار threshold به مقدار آستانه جدید تبدیل می‌شود. اگر از آستانه فراتر نرود، آستانه به نصف کاهش می‌یابد. هدف از این کار کاهش تعداد دفعات نوشتن فایل برای سیستم‌های تعبیه‌شده با حافظه غیرفرار (nonvolatile) است.

این دستور در ارتباط با درایور مودم ACTS (نوع 18) یا درایور JJY (نوع 40، حالت‌های 100 - 180) استفاده می‌شود. برای درایور مودم ACTS (نوع 18)، آرگومان‌ها شامل حداکثر 10 شماره تلفن است که برای شماره‌گیری سرویس زمان USNO، NIST یا اروپایی استفاده می‌شوند. برای درایور JJY (نوع 40 حالت 100 - 180)، آرگومان شامل یک شماره تلفن است که برای شماره‌گیری سرویس تلفنی JJY استفاده می‌شود. دستور Hayes به نام ATDT معمولاً در ابتدای شماره قرار می‌گیرد. شماره می‌تواند شامل سایر کدهای کنترلی مودم نیز باشد.

اریب‌سازی (skewing) درخواست‌های نظرسنجی ما به سرورهایمان را فعال می‌کند. poll عددی بین 3 تا 17 (شامل خود آن‌ها) است که یک بازه نظرسنجی خاص را مشخص می‌کند. مدت‌زمان بازه نظرسنجی برابر با 2^n ثانیه است، بنابراین مقدار نظرسنجی 3 معادل 8 ثانیه و بازه نظرسنجی 17 معادل 131,072 ثانیه یا حدود یک روز و نیم است. دو عدد بعدی باید بین 0 و نصف بازه نظرسنجی (شامل خود آن‌ها) باشند. آرگومان early مشخص می‌کند که نظرسنجی چقدر زودتر می‌تواند آغاز شود، در حالی که آرگومان late مشخص می‌کند که نظرسنجی تا چه اندازه می‌تواند به تأخیر بیفتد. بدون آرگومان، مقادیر پیش‌فرض تعیین‌شده داخلی انتخاب می‌شوند.

یک یا چند گروه از شمارنده‌های نگه‌داری‌شده توسط ntpd را که توسط ntpq و ntpdc نمایش داده می‌شوند، بازنشانی می‌کند.


تعداد مگابایت حافظه‌ای را که باید تخصیص داده شده و قفل شود مشخص می‌کند. این گزینه که احتمالاً فقط در لینوکس در دسترس است، ممکن است هنگام رها کردن دسترسی ریشه (گزینه -i) مفید باشد. مقدار پیش‌فرض در دستگاه‌های غیر لینوکسی 32 مگابایت و در لینوکس -1 است. مقدار -1 به معنی «فرایند را در حافظه قفل نکن» است. مقدار 0 به معنی «هر مقداری از حافظه که فرایند می‌خواهد را در حافظه قفل کن» است.

حداکثر اندازه پشته (stack) فرایند را در سیستم‌های دارای تابع mlockall() مشخص می‌کند. پیش‌فرض 50 صفحه 4 کیلوبایتی است (200 صفحه 4 کیلوبایتی در OpenBSD).

حداکثر تعداد توصیف‌کننده‌های فایلی که ntpd می‌تواند همزمان باز نگه دارد را مشخص می‌کند. پیش‌فرض برابر با مقدار پیش‌فرض سیستم است.

پوشه‌ای را مشخص می‌کند که تصویرهای لحظه‌ای (snapshots) پیکربندی درخواست‌شده با دستور saveconfig برنامه در آن نوشته شوند. اگر saveconfigdir در فایل پیکربندی وجود نداشته باشد، درخواست‌های saveconfig توسط ntpd رد می‌شوند.

پیکربندی فعلی، شامل هرگونه تغییرات زمان اجرا که با :config یا config-from-file داده شده است را در filename میزبان ntpd در saveconfigdir می‌نویسد. این دستور رد خواهد شد مگر اینکه دستورالعمل saveconfigdir در فایل پیکربندی آمده باشد. filename می‌تواند از دستورالعمل‌های قالب‌بندی strftime(3) برای جایگزینی تاریخ و زمان فعلی استفاده کند، برای نمونه: saveconfig ntp-%Y%m%d-%H%M%S.conf. نام فایل استفاده‌شده در متغیر سیستمی savedconfig ذخیره می‌شود. احراز هویت الزامی است.

این دستور یک متغیر سیستمی اضافی می‌افزاید. این متغیرها می‌توانند برای انتشار اطلاعات تکمیلی مانند خط‌مشی دسترسی استفاده شوند. اگر متغیر به شکل name=value با کلیدواژه default دنبال شود، متغیر به عنوان بخشی از متغیرهای پیش‌فرض سیستم فهرست خواهد شد (دستور rv در ntpq(1)). این متغیرهای اضافی تنها اهداف اطلاع‌رسانی دارند. آن‌ها به پروتکل مرتبط نیستند، جز اینکه می‌توان آن‌ها را فهرست کرد. متغیرهای شناخته‌شده پروتکل همیشه بر هر متغیر تعریف‌شده از طریق سازوکار setvar اولویت خواهند داشت. سه متغیر ویژه وجود دارد که شامل نام‌های تمام متغیرهای همان گروه هستند. متغیر sys_var_list شامل نام‌های تمام متغیرهای سیستم است. متغیر peer_var_list شامل نام‌های تمام متغیرهای همتا و متغیر clock_var_list شامل نام‌های متغیرهای ساعت مرجع است.

نمایش خلاصه عملیاتی سیستم.

نمایش شمارنده‌های آماری نگه‌داری‌شده در ماژول پروتکل.

از این دستور می‌توان برای تغییر چندین متغیر سیستمی در شرایط بسیار استثنایی استفاده کرد. این دستور باید در فایل پیکربندی پیش از هر گزینه پیکربندی دیگری قرار گیرد. مقادیر پیش‌فرض این متغیرها با دقت فراوان برای طیف وسیعی از سرعت‌های شبکه و انتظارات قابلیت اطمینان بهینه‌سازی شده‌اند. به طور کلی، آن‌ها به شیوه‌های پیچیده‌ای با یکدیگر تعامل دارند که پیش‌بینی آن دشوار است و برخی ترکیبات ممکن است به رفتارهای بسیار نامطلوبی منجر شوند. بسیار به ندرت پیش می‌آید که نیاز به تغییر مقادیر پیش‌فرض باشد؛ با این حال، برخی افراد نمی‌توانند در برابر دستکاری و چرخاندن پیچ‌های تنظیم مقاومت کنند و این دستور برای آن‌هاست. با تأکید یادآوری می‌شود: دستکاری‌کنندگان با مسئولیت خودشان اقدام می‌کنند و نباید هیچ انتظار کمکی از سوی گروه پشتیبانی داشته باشند.

این متغیرها به شرح زیر عمل می‌کنند:


آرگومان، مقدار جدید برای حداقل تقاطع آلن (Allan intercept) می‌شود، که پارامتری از الگوریتم انضباط ساعت PLL/FLL است. مقدار بر حسب log2 ثانیه به طور پیش‌فرض 7 (۱۰۲۴ ثانیه) است که حد پایین نیز محسوب می‌شود.

آرگومان، مقدار جدید برای نرخ افزایش پراکندگی (dispersion increase rate) می‌شود که به طور معمول ‎.000015 s/s است.

آرگومان، مقدار اولیه آفست فرکانس بر حسب بخش در میلیون (parts-per-million یا PPM) می‌شود. این مقدار، مقدار موجود در فایل فرکانس را در صورت وجود باطل می‌کند و در صورت عدم وجود، از وضعیت آموزش اولیه جلوگیری می‌نماید.

آرگومان، مقدار جدید برای بازه فیلتر آزمایشی huff-n'-puff می‌شود، که تازه‌ترین بازه‌ای را مشخص می‌کند که الگوریتم برای کمترین تأخیر در آن جستجو خواهد کرد. حد پایین 900 ثانیه (15 دقیقه) است، اما مقدار معقول‌تر 7200 (2 ساعت) است. هیچ مقدار پیش‌فرضی وجود ندارد، زیرا فیلتر تا زمانی که این دستور داده نشود فعال نمی‌گردد.

آرگومان، آستانه سراسیمگی (panic threshold) است، به طور معمول 1000 ثانیه. اگر روی صفر تنظیم شود، بررسی سلامت سراسیمگی غیرفعال شده و هر مقداری برای آفست ساعت پذیرفته خواهد شد.

آرگومان، آستانه جهش (step threshold) است که به طور پیش‌فرض 0.128 ثانیه است. می‌تواند روی هر عدد مثبت بر حسب ثانیه تنظیم شود. اگر روی صفر تنظیم شود، تنظیمات جهشی (step) هرگز رخ نخواهد داد. نکته: انضباط زمان هسته (kernel time discipline) در صورتی که آستانه جهش روی صفر یا مقداری بزرگ‌تر از مقدار پیش‌فرض تنظیم شود، غیرفعال می‌گردد.

آرگومان، آستانه جهش برای جهت رو به عقب است که به طور پیش‌فرض 0.128 ثانیه است. می‌تواند روی هر عدد مثبت بر حسب ثانیه تنظیم شود. اگر هر دو آستانه جهش رو به جلو و رو به عقب روی صفر تنظیم شوند، تنظیمات جهشی هرگز رخ نخواهد داد. نکته: انضباط زمان هسته در صورتی غیرفعال می‌شود که آستانه جهش در هر جهت، یا روی صفر تنظیم شده یا بیشتر از ‎.5 ثانیه باشد.

همانند stepback، اما برای جهت رو به جلو.

آرگومان، مهلت زمانی stepout است که به طور پیش‌فرض 900 ثانیه است. می‌تواند روی هر عدد مثبت بر حسب ثانیه تنظیم شود. اگر روی صفر تنظیم شود، پالس‌های stepout سرکوب نخواهند شد.

نوشتن (ایجاد یا به‌روزرسانی) متغیرهای مشخص‌شده. اگر assocID صفر باشد، متغیرها متعلق به فضای نام متغیرهای سیستم (system variables) هستند، در غیر این صورت از فضای نام متغیرهای همتا (peer variables) می‌باشند. مقدار assocID الزامی است، زیرا نام یکسان می‌تواند در هر دو فضای نام رخ دهد.

این دستور یک گیرنده تله (trap receiver) را در نشانی میزبان و شماره درگاه داده‌شده برای ارسال پیام‌ها با نشانی رابط محلی مشخص‌شده پیکربندی می‌کند. اگر شماره درگاه مشخص نشود، از مقدار 18447 استفاده می‌شود. اگر نشانی رابط مشخص نشود، پیام با نشانی مبدأ همان رابط محلی ارسال می‌شود که پیام از طریق آن فرستاده شده است. توجه داشته باشید که در یک میزبان چنداتصالی (multihomed)، رابط استفاده‌شده ممکن است هر از گاه با تغییرات مسیریابی دگرگون شود.

این دستور فهرستی از مقادیر TTL را به ترتیب صعودی مشخص می‌کند. حداکثر تا 8 مقدار را می‌توان مشخص کرد. در حالت manycast، این مقادیر به نوبت در یک جستجوی حلقه رو به گسترش (expanding-ring search) استفاده می‌شوند. پیش‌فرض هشت مضرب از 32 است که از 31 شروع می‌شود.

گیرنده تله عموماً پیام‌های رخداد و سایر اطلاعات سرور را در یک فایل لاگ ثبت می‌کند. در حالی که چنین برنامه‌های پایشگری ممکن است تله خود را به صورت پویا نیز درخواست کنند، پیکربندی یک گیرنده تله اطمینان می‌دهد که هیچ پیامی هنگام راه‌اندازی سرور از دست نمی‌رود.


این دستور فهرستی از مقادیر TTL را به ترتیب صعودی مشخص می‌کند؛ حداکثر 8 مقدار را می‌توان مشخص کرد. در حالت manycast این مقادیر به نوبت در یک جستجوی حلقه رو به گسترش استفاده می‌شوند. پیش‌فرض هشت مضرب از 32 است که از 31 شروع می‌شود.


نمایش اطلاعات نحوه استفاده و خروج.

ارسال اطلاعات تفصیلی نحوه استفاده از طریق یک صفحه‌بند (pager).

خروجی نسخه برنامه و خروج. حالت پیش‌فرض `v' (نسخه ساده) است. حالت `c' اطلاعات حق نشر و `n' متن کامل حق نشر را چاپ می‌کند.

هر گزینه‌ای که به عنوان not presettable (غیرقابل پیش‌تنظیم) علامت نخورده باشد، می‌تواند با بارگذاری مقادیر از متغیرهای محیطی زیر پیش‌تنظیم شود:

NTP_CONF_<option-name> یا NTP_CONF

برای متغیرهای محیطی پیکربندی، بخش پیش‌تنظیم‌های گزینه‌ها (OPTION PRESETS) را ببینید.

/etc/ntp.conf

نام پیش‌فرض فایل پیکربندی

کلیدهای خصوصی MD5

کلید خصوصی RSA

کلید عمومی RSA

پارامترهای توافق دیفی-هلمن (Diffie-Hellman)

یکی از مقادیر خروج زیر بازگردانده خواهد شد:

0 (EXIT_SUCCESS)

اجرای موفقیت‌آمیز برنامه.
1 (EXIT_FAILURE)

عملیات شکست خورد یا ساختار دستور نامعتبر بود.
70 (EX_SOFTWARE)

کتابخانه libopts با یک خطای عملیاتی داخلی روبرو شد. لطفاً آن را به autogen-users@lists.sourceforge.net گزارش دهید. با تشکر.

ntpd(1), ntpdc(1), ntpq(1)

علاوه بر صفحات راهنمای ارائه‌شده، مستندات جامعی در تارنمای وب در http://www.ntp.org در دسترس است. تصویر لحظه‌ای از این مستندات با قالب HTML در /usr/share/doc/ntp موجود است. دیوید ال. میلز (David L. Mills)، Network Time Protocol (Version 4), RFC5905

دانشگاه دلاور (The University of Delaware) و بنیاد زمان شبکه (Network Time Foundation)

حق نشر (C) ۱۹۹۲-۲۰۲۴ متعلق به دانشگاه دلاور و بنیاد زمان شبکه است، کلیه حقوق محفوظ است. این برنامه تحت شرایط مجوز NTP منتشر شده است، http://ntp.org/license.

بررسی ساختار نحوی خیلی سخت‌گیرانه نیست؛ ممکن است برخی ترکیبات مضحک و حتی خنده‌دار از گزینه‌ها و حالت‌ها تشخیص داده نشوند.

فایل‌های ntpkey_host در واقع گواهی‌های دیجیتال هستند. این‌ها زمانی که سرویس‌های دایرکتوری امن به طور عمومی در دسترس قرار گیرند، باید از طریق آن‌ها دریافت شوند.

لطفاً گزارش اشکالات را ارسال کنید به: https://bugs.ntp.org, bugs@ntp.org

این سند از FreeBSD اقتباس شده است.

این صفحه راهنما توسط AutoGen از تعاریف گزینه‌های ntp.conf تولید شده است.

25 May 2024 4.2.8p18