گزینه‌های سرور (Server Options)

گزینه‌های سراسری (در صورتی که از طریق خط فرمان NSD لغو نشده باشند) از بخش server: گرفته می‌شوند. تنها یک بخش server: می‌تواند وجود داشته باشد.

ip-address: <ip4 or ip6 or interface-name>[@port] [servers] [bindtodevice] [setfib]

سرور NSD به ip-address مشخص‌شده متصل (bind) می‌شود. می‌تواند چندین بار برای اتصال به چند نشانی IP تکرار شود. به صورت اختیاری می‌توان شماره درگاه (port) را نیز مشخص کرد. اگر مقداری داده نشود، NSD به رابط عام (wildcard) گوش می‌دهد. معادل گزینه خط فرمان -a.

برای محدود کردن اینکه کدام سرور(های) NSD به رابط داده‌شده گوش دهند، یک یا چند سرور را با فاصله بعد از <ip>[@port] مشخص کنید. سرور NSD فرآیندهایی با شماره‌های 1 تا server-count برای پاسخ‌دهی به پرس‌وجوها دارد. این مورد پردازه‌های سرور را با شماره مشخص می‌کند تا نشانی IP را مدیریت کنند. از محدوده‌ها (ranges) می‌توان به عنوان روشی خلاصه برای تعیین چندین سرور متوالی استفاده کرد. به طور پیش‌فرض، همه سرورها گوش داده و ترافیک آن را مدیریت می‌کنند.

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

برای سرورهایی با چندین نشانی IP که می‌توانند برای ارسال ترافیک به اینترنت استفاده شوند، آن‌ها را یکی یکی فهرست کنید، در غیر این صورت ممکن است نشانی مبدا در پاسخ‌ها نادرست باشد. این امر به این دلیل است که اگر سوکت udp نشانی مبدا 0.0.0.0 را متصل کند، هسته یک نشانی IP را برای ارسال به اینترنت انتخاب می‌کند و ممکن است نشانی اشتباه را انتخاب کند. این مورد معمولاً برای نمونه‌های anycast مورد نیاز است. از ip-transparent استفاده کنید تا بتوانید نشانی‌هایی را که بعداً فعال می‌شوند فهرست نمایید (مناسب برای برخی حالت‌های متعادل‌سازی بار).

گزینه bindtodevice دستگاه مرتبط با نشانی را جستجو کرده و سپس از SO_BINDTODEVICE برای اتصال سوکت به دستگاه استفاده می‌کند. این ویژگی به عنوان یک بهینه‌سازی عملکردی استفاده می‌شود و به سوکت شبکه اجازه می‌دهد مستقیماً به دستگاه شبکه متصل شود که باعث افزایش سرعت پردازش پشته شبکه می‌شود. سوکت تنها بسته‌های دریافت‌شده از همان رابط را پردازش می‌کند.

گزینه setfib از گزینه سوکت SO_SETFIB استفاده می‌کند تا fib حاصل از getaddrinfo برای آن نشانی روی سوکت تنظیم شود. این کار FIB (جدول مسیریابی) رابط را به سوکت متصل می‌کند که باعث دور زدن فرآیند انتخاب مسیر برای ترافیک می‌شود. این مورد برای بهینه‌سازی کارایی کاربرد دارد.

interface: <ip4 or ip6 or interface-name>[@port] [servers] [bindtodevice] [setfib]

مشابه ip-address (برای سازگاری آسان‌تر با unbound.conf).

ip-transparent: <yes or no>

به NSD اجازه می‌دهد تا به نشانی‌های غیرمحلی متصل شود. این گزینه برای این مفید است که NSD به نشانی‌های IP که هنوز به رابط شبکه اضافه نشده‌اند گوش دهد تا بتواند بلافاصله پس از اضافه شدن نشانی پاسخ دهد. پیش‌فرض no است.

ip-freebind: <yes or no>

گزینه IP_FREEBIND را برای اتصال به نشانی‌های غیرمحلی و رابط‌هایی که غیرفعال (down) هستند تنظیم می‌کند. شبیه به ip-transparent است. مقدار پیش‌فرض no است.

reuseport: <yes or no>

از گزینه سوکت SO_REUSEPORT استفاده می‌کند و برای هر سرور مشخص‌شده در server-count توصیف‌کننده‌های فایل (file descriptors) ایجاد می‌کند. این کار عملکرد پشته شبکه را بهبود می‌بخشد. این ویژگی تنها زمانی واقعاً مفید است که server-count را بالاتر از 1 (مثلاً برابر با تعداد پردازنده‌ها) تنظیم کرده باشید. مقدار پیش‌فرض no است. این قابلیت روی لینوکس کار می‌کند اما روی FreeBSD کار نمی‌کند و احتمالاً روی سایر سیستم‌ها نیز کار نخواهد کرد.

send-buffer-size: <number>

اندازه بافر ارسال را برای سوکت‌های سرویس‌دهنده به پرس‌وجوها تعیین می‌کند. برای استفاده از تنظیمات پیش‌فرض مقدار را 0 قرار دهید. این بخش به مقداری فضا برای رسیدگی به بسته‌هایی نیاز دارد که قبل از ارسال منتظر تحلیل نشانی محلی (مانند کشف ARP و NDP) هستند، از این رو به طور پیش‌فرض از پیش‌فرض سیستم بالاتر است. مقدار پیش‌فرض 4194304 بایت (4 مگابایت) است.

receive-buffer-size: <number>

اندازه بافر دریافت را برای سوکت‌های سرویس‌دهنده به پرس‌وجوها تعیین می‌کند. برای استفاده از تنظیمات پیش‌فرض مقدار را 0 قرار دهید. مقدار پیش‌فرض 1048576 بایت (1 مگابایت) است.

debug-mode: <yes or no>

حالت اشکال‌زدایی را برای nsd فعال می‌کند و فرآیند دیمن فورک نمی‌شود. پیش‌فرض no است. معادل گزینه خط فرمان -d. اگر روی yes تنظیم شود، فورک نشده و در پس‌زمینه اجرا نمی‌شود (در پیش‌زمینه باقی می‌ماند)، که می‌تواند برای اشکال‌زدایی خط فرمان مفید باشد، و همچنین توسط برخی فرآیندهای نظارت بر سرور (supervisor) برای اطمینان از در حال اجرا بودن سرور استفاده می‌شود.

do-ip4: <yes or no>

در صورت تنظیم روی yes، سرور NSD به اتصالات IPv4 گوش می‌دهد. پیش‌فرض yes است.

do-ip6: <yes or no>

در صورت تنظیم روی yes، سرور NSD به اتصالات IPv6 گوش می‌دهد. پیش‌فرض yes است.

database: <filename>

این گزینه توسط نسخه‌های 4.8.0 و جدیدتر NSD نادیده گرفته می‌شود، زیرا قابلیت پایگاه داده حذف شده است.

zonelistfile: <filename>

به طور پیش‌فرض از //var/db/nsd/zone.list استفاده می‌شود. فایل مشخص‌شده برای ذخیره فهرست ناحیه‌های اضافه‌شده به صورت پویا استفاده می‌شود. NSD برای افزودن و حذف نواحی در این لیست می‌نویسد. این یک فایل متنی با یک zone-name و pattern-name در هر خط است. این فایل برای دستورات addzone و delzone در nsd-control استفاده می‌شود.

identity: <string>

در پاسخ به پرس‌وجوی CH TXT ID.SERVER هویت مشخص‌شده را بازمی‌گرداند. پیش‌فرض نامی است که توسط gethostname(3) برگردانده می‌شود. معادل گزینه خط فرمان -i. برای تنظیم سرور به عدم پاسخگویی به چنین پرس‌وجوهایی، به hide-identity مراجعه کنید.

version: <string>

رشته نگارش مشخص‌شده را در پاسخ به پرس‌وجوهای CH TXT version.server و version.bind بازمی‌گرداند. پیش‌فرض نگارش بسته کامپایل‌شده است. برای تنظیم سرور به عدم پاسخگویی به چنین پرس‌وجوهایی، به hide-version مراجعه کنید.

nsid: <string>

در هنگام پاسخ به بسته‌ای که گزینه NSID EDNS در آن فعال است، nsid مشخص‌شده را به بخش EDNS پاسخ اضافه می‌کند. می‌تواند به صورت دنباله‌ای از کاراکترهای هگزادسیمال یا با پیشوند _ascii و سپس یک رشته ascii باشد. معادل گزینه خط فرمان -I.

logfile: <filename>

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

log-only-syslog: <yes or no>

پیام‌ها را فقط در syslog ثبت می‌کند. این گزینه با systemd مفید است تا چاپ در stderr باعث ایجاد رشته‌های گزارش تکراری در journald نشود. قبل از باز شدن syslog، سرور از stderr استفاده می‌کند. همچنین در صورتی که syslog در دسترس نباشد، از stderr استفاده می‌شود. پیش‌فرض no است.

server-count: <number>

این تعداد سرور NSD را راه‌اندازی می‌کند. پیش‌فرض 1 است. معادل گزینه خط فرمان -N.

cpu-affinity: <number> <number> ...

وابستگی کلی پردازنده (CPU affinity) برای سرور(های) NSD. پیش‌فرض بدون وابستگی است.

server-N-cpu-affinity: <number>

سرور NSD مشخص‌شده با N را به یک هسته خاص مقید می‌کند. حالت پیش‌فرض این است که وابستگی به تمام هسته‌های مشخص‌شده در cpu-affinity تنظیم شود. این تنظیم فقط زمانی اثر می‌کند که cpu-affinity فعال باشد.

xfrd-cpu-affinity: <number>

دیمن xfrd را به یک هسته خاص مقید می‌کند. پیش‌فرض داشتن وابستگی به تمامی هسته‌های مشخص‌شده در cpu-affinity است. این تنظیم تنها در صورتی اثرگذار است که cpu-affinity فعال باشد.

tcp-count: <number>

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

tcp-reject-overflow: <yes or no>

در صورت تنظیم روی yes، اتصالات TCP که فراتر از حداکثر تعیین‌شده توسط tcp-count برقرار شوند، فوراً رد (پذیرفته و بسته) خواهند شد. پیش‌فرض no است.

tcp-query-count: <number>

حداکثر تعداد پرس‌وجوهای پاسخ‌داده‌شده در یک اتصال TCP واحد. پیش‌فرض 0 است، به این معنی که محدودیتی وجود ندارد.

tcp-timeout: <number>

زمان انتظار پیش‌فرض TCP را بازنویسی می‌کند. این مورد بر انتقال ناحیه (zone transfer) از طریق TCP نیز تأثیر می‌گذارد. مقدار پیش‌فرض 120 ثانیه است.

tcp-mss: <number>

حداکثر اندازه سگمنت (MSS) سوکت TCP که سرور بر روی آن به پرس‌وجوها پاسخ می‌دهد. مقداری کمتر از MSS معمول در اترنت (برای مثال 1220) مشکل Path MTU را برطرف می‌کند. توجه داشته باشید که همه سیستم‌ها از گزینه سوکت برای تنظیم MSS (یعنی TCP_MAXSEG) پشتیبانی نمی‌کنند. مقدار پیش‌فرض، MSS پیش‌فرض سیستم است که توسط MTU رابط و مذاکره بین سرور و کلاینت تعیین می‌شود.

outgoing-tcp-mss: <number>

حداکثر اندازه سگمنت (MSS) سوکت TCP برای درخواست‌های خروجی XFR به سایر سرورهای نام. مقداری کمتر از MSS معمول اترنت (برای مثال 1220) مشکل Path MTU را برطرف می‌کند. توجه داشته باشید که همه سیستم‌ها از گزینه سوکت برای تنظیم MSS (یعنی TCP_MAXSEG) پشتیبانی نمی‌کنند. مقدار پیش‌فرض، MSS پیش‌فرض سیستم است که توسط MTU رابط و مذاکره بین NSD و سایر سرورها تعیین می‌شود.

tcp-listen-queue: <number>

صف پس‌افتاده (backlog) اتصال TCP را برای سوکت‌های شنونده تنظیم می‌کند. این کار به اتصالات در انتظار بیشتری که اتصال آن‌ها برقرار شده و منتظر سرویس‌دهی TCP هستند اجازه ورود می‌دهد. مقادیر بالاتر برای دریافت همزمان اتصالات بیشتر بهتر است. مقادیر بالا همچنین در برابر حملات سیل‌آسا (flooding) و برخی مشکلات کانال جانبی محافظت بیشتری ایجاد می‌کنند. پیش‌فرض در BSDها و لینوکس -1 و در سایر سیستم‌ها 256 است. مقدار -1 بیشترین مقدار مجاز را انتخاب می‌کند.

xfrd-tcp-max: <number>

تعداد سوکت‌هایی که xfrd برای انتقال‌های ناحیه خروجی استفاده می‌کند. پیش‌فرض 128 است. برای مجاز کردن سوکت‌های بیشتر برای انتقال ناحیه، مثلاً تا 256، آن را افزایش دهید. این گزینه برای انتقال‌های ناحیه‌ای است که این سرور از سرورهای دیگر درخواست می‌کند. برای صرفه‌جویی در حافظه، می‌توان این مقدار را کاهش داد؛ آن را همراه با چند تنظیم دیگر کاهش دهید تا ردپای حافظه NSD کاهش یابد: xfrd-tcp-max: 32 و xfrd-tcp-pipeline: 128 و rrl-size: 1000.

این کار ردپای حافظه را کاهش می‌دهد. سایر مصارف حافظه عمدتاً ناشی از تنظیم server-count، تعداد فرآیندهای سرور، تنظیم tcp-count (که بافرها را به ازای هر فرآیند سرور نگه می‌دارد) و حجم داده‌های ناحیه است.

xfrd-tcp-pipeline: <number>

تعداد انتقال‌های ناحیه خروجی همزمان که روی سوکت‌های tcp دیمن xfrd امکان‌پذیر است. حداکثر 65536 و پیش‌فرض 128 است. این گزینه برای انتقال‌های ناحیه‌ای است که توسط این سرور از سرورهای دیگر درخواست می‌شود.

ipv4-edns-size: <number>

اندازه بافر EDNS ترجیحی برای IPv4. پیش‌فرض 1232 است.

ipv6-edns-size: <number>

اندازه بافر EDNS ترجیحی برای IPv6. پیش‌فرض 1232 است.

pidfile: <filename>

استفاده از فایل pid به جای پیش‌فرض سیستم‌عامل، که معمولاً "/run/nsd/nsd.pid" است. معادل گزینه خط فرمان -P. با مقدار "" هیچ فایلی برای pid ایجاد نمی‌شود که برای برخی تنظیمات مدیریت راه‌اندازی که نیازی به pidfile ندارند مناسب است. پیش‌فرض می‌تواند در زمان کامپایل تنظیم شود، گاهی اوقات روی "". سپس می‌توان از گزینه پیکربندی و گزینه خط فرمان برای تعیین استفاده از فایل pid متفاوت از مقدار پیش‌فرض زمان کامپایل استفاده کرد. به دلایل ایمنی دسترسی‌ها، مالکیت فایل به کاربر مشخص‌شده در گزینه username: تغییر داده نمی‌شود (chown نمی‌شود) و تحت مالکیت کاربری که سرور با آن اجرا شده باقی می‌ماند. ممکن است فایل پس از پایان کار و خروج سرور حذف نشود، زیرا دسترسی‌های نام کاربری ممکن است این اجازه را ندهد.

port: <number>

پاسخ‌دهی به پرس‌وجوها روی درگاه مشخص‌شده. پیش‌فرض 53 است. معادل گزینه خط فرمان -p.

statistics: <number>

در صورت عدم وجود، هیچ آماری ثبت نمی‌شود. آمارها هر چند ثانیه یک‌بار (طبق عدد مشخص‌شده) تولید می‌شوند. معادل گزینه خط فرمان -s.

chroot: <directory>

سرور NSD در هنگام راه‌اندازی به دایرکتوری مشخص‌شده chroot می‌کند. توجه داشته باشید اگر در جای دیگری از پیکربندی، مسیر فایلی مطلق درون chroot مشخص کرده‌اید، باید مسیر chroot را به ابتدای آن اضافه کنید. به این ترتیب می‌توانید بدون نیاز به تغییر سایر بخش‌های پیکربندی، گزینه chroot را فعال یا غیرفعال کنید. مقدار را روی "" (رشته خالی) قرار دهید تا chroot غیرفعال شود. به طور پیش‌فرض از "" استفاده می‌شود. معادل گزینه خط فرمان -t.

username: <username>

پس از اتصال سوکت، امتیازات دسترسی کاربر را کنار گذاشته و هویت این نام کاربری را می‌گیرد. می‌تواند نام کاربری، id یا id.gid باشد. معادل گزینه خط فرمان -u.

zonesdir: <directory>

دایرکتوری کاری را قبل از دسترسی به فایل‌های ناحیه به دایرکتوری مشخص‌شده تغییر می‌دهد. همچنین NSD به zonelistfile، logfile، pidfile، xfrdfile، xfrdir، server-key-file، server-cert-file، control-key-file و control-cert-file به صورت نسبی نسبت به این دایرکتوری دسترسی پیدا می‌کند. برای غیرفعال کردن تغییر دایرکتوری کاری، مقدار را برابر "" (رشته خالی) قرار دهید. به طور پیش‌فرض "//etc/nsd" استفاده می‌شود.

difffile: <filename>

نادیده گرفته می‌شود؛ فقط برای سازگاری با فایل‌های پیکربندی NSD3 وجود دارد.

xfrdfile: <filename>

دیمن مهلت زمانی soa و انتقال ناحیه در NSD، وضعیت خود را در این فایل ذخیره می‌کند. وضعیت پس از راه‌اندازی مجدد بازخوانی می‌شود. فایل وضعیت را می‌توان بدون آسیب جدی حذف کرد، اما برچسب‌های زمانی نواحی از بین خواهند رفت. اگر روی "" پیکربندی شود، فایل وضعیت استفاده نمی‌شود و همه نواحی ثانویه هنگام راه‌اندازی برای به‌روزرسانی بررسی می‌شوند. برای جزئیات بیشتر به بخش رفتار انقضای ناحیه در NSD مراجعه کنید. پیش‌فرض //var/db/nsd/xfrd.state است.

xfrdir: <directory>

انتقال‌های ناحیه قبل از پردازش در اینجا ذخیره می‌شوند. دایرکتوری‌ای در اینجا ایجاد می‌شود که هنگام خروج NSD حذف می‌گردد. پیش‌فرض /tmp است.

xfrd-reload-timeout: <number>

اگر این مقدار -1 باشد، xfrd پس از انتقال ناحیه بارگذاری مجدد (reload) را آغاز نمی‌کند. اگر مثبت باشد، xfrd پس از انتقال ناحیه بارگذاری مجدد را آغاز کرده و سپس به مدت این تعداد ثانیه منتظر می‌ماند تا بارگذاری مجدد جدیدی را آغاز کند. تنظیم این مقدار، بارگذاری‌های مجدد را به یک بار در هر تعداد ثانیه مشخص محدود می‌کند. پیش‌فرض 1 ثانیه است.

verbosity: <level>

این مقدار سطح پرگویی (verbosity) را برای گزارش‌گیری غیر اشکال‌زدایی مشخص می‌کند. پیش‌فرض 0 است. مقدار 1 اطلاعات بیشتری در مورد اعلان‌ها (notifies) و انتقال‌های ناحیه ورودی ارائه می‌دهد. مقدار 2 هشدارهای خفیف را فهرست می‌کند. مقدار 3 اطلاعات بیشتری چاپ می‌کند. معادل گزینه خط فرمان -V.

سطح پرگویی 0 هشدارها، خطاها و سایر رویدادهای مهم برای روشن ماندن NSD را چاپ می‌کند.

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

سطح پرگویی 2 خطاهای جزئی مانند ریست شدن اتصال روی TCP، رد اعلان‌ها و رد درخواست‌های axfr را نیز چاپ می‌کند.

hide-version: <yes or no>

جلوگیری از پاسخگویی NSD با رشته نگارش در پرس‌وجوهای کلاس CHAOS. پیش‌فرض no است.

hide-identity: <yes or no>

جلوگیری از پاسخگویی NSD با رشته هویت در پرس‌وجوهای کلاس CHAOS. پیش‌فرض no است.

drop-updates: <yes or no>

در صورت تنظیم روی yes، بسته‌های دریافتی با کد عملیاتی UPDATE نادیده گرفته شده و دور انداخته می‌شوند. پیش‌فرض no است.

use-systemd: <yes or no>

این گزینه منسوخ شده و نادیده گرفته می‌شود. اگر با libsystemd کامپایل شده باشد، NSD آماده بودن را به systemd اعلام می‌کند و استفاده از این گزینه ضروری نیست.

log-time-ascii: <yes or no>

ثبت زمان به صورت ascii؛ اگر روی "no" باشد به صورت ثانیه‌های epoch ثبت می‌شود. پیش‌فرض yes است. این گزینه قالب زمان را هنگام گزارش‌گیری در فایل انتخاب می‌کند. خروجی چاپ‌شده از طریق syslog قالبی دارد که توسط syslog مشخص می‌شود.

log-time-iso: <yes or no>

در صورتی که log-time-ascii: نیز روی yes باشد، زمان را در قالب ISO8601 ثبت می‌کند. پیش‌فرض no است.

round-robin: <yes or no>

فعال‌سازی چرخش نوبتی (round robin) رکوردها در پاسخ. این کار ترتیب رکوردها را در پاسخ تغییر می‌دهد و ممکن است بار را بین آن‌ها متعادل کند. پیش‌فرض no است.

minimal-responses: <yes or no>

فعال‌سازی پاسخ‌های حداقلی برای دریافت پاسخ‌های کوچک‌تر. این کار بسته‌ها را کوچک‌تر می‌کند. داده‌های اضافی تنها در صورت ارجاع‌ها (referrals) و هنگامی که واقعاً لازم باشد اضافه می‌شوند. این مورد با گزینه زمان کامپایل --enable-minimal-responses متفاوت است؛ آن گزینه بسته‌ها را دقیقاً به اندازه طول تکه‌تکه‌شدن کاهش می‌دهد، اما این گزینه پیکربندی بسته‌ها را تا حد امکان کوچک می‌کند. پیش‌فرض no است.

confine-to-zone: <yes or no>

در صورت تنظیم روی yes، اگر ناحیه رأس (apex) اطلاعات اضافی با ناحیه رأس پرس‌وجوی اولیه مطابقت نداشته باشد (مانند تفکیک CNAME)، اطلاعات اضافی به پاسخ اضافه نخواهد شد. پیش‌فرض no است.

refuse-any: <yes or no>

رد کردن پرس‌وجوهای نوع ANY. این گزینه برای توقف سیل پرس‌وجوهایی که تلاش می‌کنند پاسخ‌های بزرگ دریافت کنند مفید است. توجه داشته باشید که محدودسازی نرخ (rrl) نیز نوع ANY را به عنوان یک نوع محدودکننده در نظر می‌گیرد؛ در پاسخ به پرس‌وجوهای UDP نوع ANY پاسخ کوتاه‌شده (truncation) ارسال می‌کند و پرس‌وجوهای TCP نوع ANY را به صورت عادی مجاز می‌داند. پیش‌فرض no است. با غیرفعال بودن این گزینه، NSD طبق RFC 8482 بخش 4.1 رفتار می‌کند و پاسخ را با یک مجموعه رکورد (RRset) به حداقل می‌رساند. انواع پرکاربرد و کم‌حجم مانند A، AAAA و MX ترجیح داده می‌شوند و انواع حجیم مانند DNSKEY و RRSIG با اولویت کمتری نسبت به سایر انواع انتخاب می‌شوند تا پاسخ کوچک‌تر شود.

reload-config: <yes or no>

بارگذاری مجدد فایل پیکربندی و به‌روزرسانی کلیدهای TSIG و نواحی با دریافت سیگنال SIGHUP. پیش‌فرض no است.

zonefiles-check: <yes or no>

بررسی mtime فایل‌های ناحیه توسط NSD در زمان شروع و دریافت sighup. اگر آن را غیرفعال کنید، سرور سریع‌تر شروع به کار می‌کند (فعالیت دیسک کمتر در صورت وجود تعداد زیادی ناحیه). پیش‌فرض yes است. دستور reload در nsd-control بدون در نظر گرفتن این گزینه، فایل‌های ناحیه را بازخوانی می‌کند.

zonefiles-write: <seconds>

نوشتن نواحی ثانویه به‌روزرسانی‌شده در فایل ناحیه مربوطه‌شان در هر N ثانیه. اگر گزینه "zonefile" در ناحیه یا الگو روی "" (رشته خالی) تنظیم شده باشد، هیچ فایل ناحیه‌ای نوشته نمی‌شود. پیش‌فرض 3600 (1 ساعت) است.

rrl-size: <numbuckets>

اندازه جدول هش را تعیین می‌کند. پیش‌فرض 1000000 است. سطل‌های (buckets) بیشتر حافظه بیشتری مصرف می‌کنند و احتمال برخورد هش را کاهش می‌دهند.

rrl-ratelimit: <qps>

حداکثر qps مجاز (از یک مبدا پرس‌وجو). پیش‌فرض خاموش است (با مقدار پیشنهادی 200 qps). اگر روی 0 تنظیم شود غیرفعال می‌شود (نرخ نامحدود)؛ همچنین whitelist-ratelimit را برای غیرفعال کردن پردازش محدودیت نرخ روی 0 تنظیم کنید. اگر verbosity را روی 2 تنظیم کنید، زیرشبکه‌های مسدودشده و رفع مسدودیت‌شده گزارش می‌شوند. پرس‌وجوهای مسدودشده متوقف می‌شوند و برخی پاسخ عقب‌نشینی به TCP دریافت می‌کنند. پس از رسیدن به محدودیت نرخ، NSD شروع به انداختن (drop) پاسخ‌ها می‌کند. با این حال، به ازای هر تعداد پاسخ مشخص در "rrl-slip"، یک پاسخ با بیت TC تنظیم‌شده مجاز می‌شود. اگر slip روی 2 تنظیم شود، نرخ پاسخ‌های برگشتی نصف خواهد شد. اگر روی 3 تنظیم شود، یک‌سوم خواهد شد و الی آخر. اگر rrl-slip را روی 10 تنظیم کنید، ترافیک به یک‌دهم کاهش می‌یابد. گزینه‌های محدودیت نرخ rrl-ratelimit، rrl-size و rrl-whitelist-ratelimit هنگام اجرای reconfig در nsd-control به‌روزرسانی می‌شوند (همچنین گزینه‌های محدودیت نرخ اختصاصی ناحیه به‌روز می‌شوند). اگر در زمان کامپایل گنجانده نشده باشد، این گزینه نادیده گرفته می‌شود؛ محدودیت نرخ می‌تواند بر اساس پیکربندی زمان کامپایل به طور پیش‌فرض روشن یا خاموش باشد.

rrl-slip: <numpackets>

این گزینه تعداد بسته‌های دور ریخته شده را قبل از ارسال پاسخ SLIP (پاسخی با بیت "truncated" برابر 1) کنترل می‌کند. مقدار 0 ارسال بسته‌های SLIP را غیرفعال می‌کند و 1 به این معنی است که هر پرس‌وجو یک پاسخ SLIP دریافت خواهد کرد. پیش‌فرض 2 است که ترافیک را به نصف کاهش می‌دهد و به کاربران قانونی شانس عادلانه‌ای برای دریافت پاسخ +TC می‌دهد.

rrl-ipv4-prefix-length: <subnet>

طول پیشوند IPv4. نشانی‌ها بر اساس بلوک شبکه گروه‌بندی می‌شوند. پیش‌فرض 24 است.

rrl-ipv6-prefix-length: <subnet>

طول پیشوند IPv6. نشانی‌ها بر اساس بلوک شبکه گروه‌بندی می‌شوند. پیش‌فرض 64 است.

rrl-whitelist-ratelimit: <qps>

حداکثر qps برای انواع پرس‌وجو از یک مبدا که در لیست سفید قرار گرفته‌اند. پیش‌فرض خاموش است (با مقدار پیشنهادی 2000 qps). با استفاده از گزینه rrl-whitelist می‌توانید پرس‌وجوهای خاصی را تنظیم کنید تا به جای محدودیت عادی، این محدودیت qps را دریافت کنند. با مقدار 0 نرخ نامحدود خواهد بود.

answer-cookie: <yes or no>

پاسخ‌دهی به درخواست‌های حاوی کوکی‌های DNS را طبق RFC7873 فعال می‌کند. پیش‌فرض no است.

کوکی‌های DNS امنیت تراکنش‌ها را افزایش داده و محافظت محدودی در برابر حملات تقویت‌شده منع سرویس (DoS) فراهم می‌کنند. کوکی‌های سرور ایجاد شده و در پاسخ‌ها گنجانده می‌شوند. کوکی‌های سرور بر اساس کوکی کلاینت موجود در درخواست، زمان فعلی، نشانی IP کلاینت و یک کلید محرمانه ایجاد می‌شوند. هنگامی که یک کلاینت کوکی معتبر سرور را در درخواست‌های بعدی خود قرار دهد، مشمول محدودیت نرخ درخواست (به rrl-ratelimit مراجعه کنید) نخواهد شد.

سرورها در یک استقرار anycast باید بتوانند کوکی‌های سرور یکدیگر را تأیید کنند. برای این کار آن‌ها باید در کلید محرمانه‌ای که برای ساخت و تأیید کوکی‌ها استفاده می‌شود مشترک باشند. این کلیدهای محرمانه کوکی را می‌توان در فایل‌های پیکربندی با گزینه‌های cookie-secret و cookie-staging-secret مشخص کرد.

اگر هیچ کلید محرمانه کوکی از طریق فایل پیکربندی ارائه نشود، می‌توان کلیدهای محرمانه کوکی سرور را با استفاده از ابزار nsd-control(8) اضافه، حذف یا فعال کرد. این کلیدها به صورت دائمی در فایل اسرار کوکی ذخیره می‌شوند که مکان آن را می‌توان با گزینه cookie-secret-file مشخص کرد.

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

cookie-secret: <128 bit hex string>

کلید محرمانه کوکی که با آن کوکی‌های سرور ایجاد شده و قابل تأیید هستند. اگر یک cookie-secret از طریق فایل پیکربندی مشخص شود، کلیدهای موجود در فایل اسرار کوکی نادیده گرفته خواهند شد.

cookie-staging-secret: <128 bit hex string>

یک کلید محرمانه کوکی که با آن کوکی‌های سرور قابل تأیید هستند، اما ایجاد نمی‌شوند. این گزینه در چرخش کلیدهای محرمانه کوکی در تنظیمات anycast مفید است.

یک cookie-staging-secret تنها زمانی قابل پیکربندی است که یک cookie-secret نیز پیکربندی شده باشد.

cookie-secret-file: <filename>

فایلی که اسرار مورد استفاده در محاسبات کوکی DNS از آن خوانده می‌شوند. این فایل تنها در صورتی خوانده می‌شود که هیچ کلید محرمانه کوکی در فایل پیکربندی از طریق گزینه‌های cookie-secret و cookie-staging-secret داده نشده باشد. پیش‌فرض "//var/db/nsd/cookiesecrets.txt" است.

در نسخه 4.10.1 و نسخه‌های قبلی NSD، مکان پیش‌فرض فایل اسرار کوکی "//etc/nsd/nsd_cookiesecrets.txt" بود. به منظور مهاجرت، اگر مقداری برای گزینه cookie-secret-file داده نشود و مکان پیش‌فرض فعلی وجود نداشته باشد، اسرار کوکی از آن مکان خوانده خواهند شد.

محتوای فایل اسرار کوکی باید با دستورات add_cookie_secret، drop_cookie_secret و activate_cookie_secret در ابزار nsd-control(8) مدیریت شود. لطفاً برای چگونگی انجام چرخش ایمن کلید محرمانه کوکی به صفحه راهنمای آن ابزار مراجعه کنید.

tls-service-key: <filename>

در صورت فعال بودن، سرور سرویس TLS را روی سوکت‌های TCP با شماره درگاه سرویس TLS ارائه می‌دهد. شماره درگاه (853) با tls-port پیکربندی می‌شود. برای روشن کردن آن، یک خط گزینه :interface در پیکربندی با port@ متصل به نشانی IP ایجاد کنید. این کار سوکت اضافی را ایجاد می‌کند که سرویس DNS over TLS روی آن ارائه می‌شود.

این فایل کلید خصوصی برای نشست TLS است. گواهی عمومی در فایل tls-service-pem قرار دارد. پیش‌فرض "" (خاموش) است. در صورت تغییر نیاز به راه‌اندازی مجدد (restart) دارد (reload کافی نیست)، زیرا کلید خصوصی در حالی خوانده می‌شود که دسترسی ریشه وجود دارد و قبل از chroot (در صورت وجود) است.

tls-service-pem: <filename>

فایل pem گواهی کلید عمومی برای سرویس tls. پیش‌فرض "" (خاموش) است.

tls-service-ocsp: <filename>

فایل pem مربوط به ocsp برای سرویس tls، جهت استفاده در OCSP stapling. پیش‌فرض "" (خاموش) است. یک فرآیند خارجی داده‌های OCSP stapling را آماده و به‌روزرسانی می‌کند؛ به این شکل:

openssl ocsp -no_nonce \
	-respout /path/to/ocsp.pem \
	-CAfile /path/to/ca_and_any_intermediate.pem \
	-issuer /path/to/direct_issuer.pem \
	-cert /path/to/cert.pem \
	-url "$( openssl x509 -noout -ocsp_uri -in /path/to/cert.pem )"

tls-port: <number>

شماره درگاهی که سرویس TCP TLS روی آن ارائه می‌شود. پیش‌فرض 853 است. تنها رابط‌هایی که با آن شماره درگاه به عنوان number@ پیکربندی شده‌اند، سرویس DNS over TLS را دریافت می‌کنند.

tls-auth-port: <number>

شماره درگاه برای ارائه سرویس TCP TLS تنها به کلاینت‌های احراز هویت‌شده. اگر می‌خواهید از احراز هویت دوطرفه TLS در اتصالات Transfer over TLS (XoT) استفاده کنید، سرور اصلی یک درگاه اختصاصی برای این منظور در اینجا فعال می‌کند. گواهی‌های موجود در tls-cert-bundle برای تأیید اصالت کلاینت یا سرور ثانویه استفاده می‌شوند.

کلاینت (ثانویه) باید tls-auth را فعال کرده، client-cert و client-key را پیکربندی کرده و tls-auth را در پیکربندی ناحیه فعال کند تا بتواند نزد سرور راه دور (اصلی) احراز هویت شود.

tls-auth-xfr-only: <yes or no>

اجازه انتقال ناحیه تنها روی درگاه tls-auth-port و فقط برای کلاینت‌های احراز هویت‌شده. این گزینه به صورت سراسری برای همه نواحی اعمال می‌شود. یک لیست کنترل دسترسی provide-xfr همراه با tls-auth نیز برای اجازه و تأیید اتصال لازم است. درخواست‌های انتقال ناحیه روی سایر درگاه‌ها رد می‌شوند.

tls-cert-bundle: <filename>

اگر null یا "" باشد، از مکان‌های پیش‌فرض اعتبارسنجی استفاده می‌شود. آن را روی فایل دسته گواهی تنظیم کنید، برای مثال "/etc/pki/tls/certs/ca-bundle.crt". این گواهی‌ها برای احراز هویت اتصالات Transfer over TLS (XoT) استفاده می‌شوند.

proxy-protocol-port: <number>

شماره درگاه برای سرویس proxy protocol. اگر این دستور چندین بار تکرار شود، شماره‌های درگاه اضافی می‌توانند برای این سرویس استفاده شوند. تعاریف رابطی که از این شماره درگاه استفاده می‌کنند انتظار ترافیک پروتکل پراکسی PROXYv2 را برای UDP، TCP و سرویس TLS دارند.

xdp-interface: <string>

رابطی که XDP باید با آن استفاده شود. این گزینه استفاده از سوکت‌های AF_XDP را برای پرس‌وجوهای UDP فعال می‌کند. پیش‌فرض "" (غیرفعال) است. (آزمایشی)

نکات قابل توجه:
• اگر cpu-affinity پیکربندی شده است، لطفاً به وابستگی پردازنده صف‌های دستگاه شبکه توجه داشته باشید.
• تعداد سرورهای ایجاد‌شده به تعداد کانال‌ها/صف‌های ترکیبی rx/tx رابط انتخابی بستگی دارد. به همان تعداد فرآیندی که کانال ترکیبی روی رابط مشخص‌شده وجود دارد، ترافیک را از طریق XDP دریافت خواهند کرد. در صورت لزوم مقدار server-count افزایش خواهد یافت. اگر server-count بالاتر باشد، فرآیندهای اضافی از XDP استفاده نخواهند کرد.
• پروتکل PROXYv2، DNSTAP و محدودیت نرخ (ratelimiting) در حال حاضر از طریق XDP پشتیبانی نمی‌شوند.

xdp-program-path: <string>

برنامه eBPF XDP برای استخراج XSKMAP از آن. اگر می‌خواهید از یک برنامه سفارشی XDP استفاده کنید، برنامه خود را در اینجا مشخص نمایید. برنامه پیش‌فرض همراه با NSD فقط ترافیک UDP (روی Ethernet[+VLAN]+IPv4/6) را به درگاه 53 هدایت می‌کند. هنگام استفاده از برنامه XDP اختصاصی، باید یک BPF_MAP_TYPE_XSKMAP به نام "xsks_map" تعریف شده باشد.

این گزینه حتی زمانی که NSD پیکربندی شده باشد تا برنامه XDP مشخص‌شده را بارگذاری نکند (به xdp-program-load مراجعه کنید) نیز باید تنظیم شود تا بتواند ساختار XSKMAP را تعیین کند. در این حالت برنامه XDP شما باید نگاشت فوق‌الذکر را در یک bpffs سنجاق (pin) کند (به xdp-bpffs-path مراجعه نمایید).

پیش‌فرض "/usr/share/nsd/xdp-dns-redirect_kern.o" است.

xdp-program-load: <yes or no>

مشخص می‌کند که آیا NSD باید برنامه XDP را بارگذاری کند یا خیر. اگر روی no تنظیم شود، باید برنامه XDP را خودتان بارگذاری کنید. در صورت تنظیم بودن xdp-interface، پیش‌فرض yes است.

xdp-bpffs-path: <string>

مسیر bpffs برای ذخیره/خواندن پین xsks_map. برنامه پیش‌فرض XDP بارگذاری‌شده توسط NSD نیازی به این گزینه ندارد؛ این گزینه فقط در صورتی لازم است که برنامه‌ای را بارگذاری کنید که نگاشت BPF خود را پین می‌کند.

اگر NSD برای بارگذاری یک برنامه XDP که نگاشت خود را پین می‌کند پیکربندی شده باشد، NSD برای ایجاد و سپس حذف پین نگاشت نیاز به دسترسی خواندن/نوشتن/اجرا در bpffs مشخص‌شده دارد. اگر برنامه XDP را خودتان بارگذاری کنید، NSD فقط به دسترسی خواندن و نوشتن روی خود فایل پین نیاز دارد (اما حداقل دسترسی اجرا به دایرکتوری‌های والد لازم است). bpffs پیش‌فرض (/sys/fs/bpf) معمولاً مجوزهای لازم را برای کاربران غیر ریشه تنظیم نکرده است. می‌توانید مجوزهای لازم را تنظیم کنید یا bpffs خود را سوار (mount) نمایید.

پیش‌فرض "/sys/fs/bpf" است.

xdp-force-copy: <yes or no>

اجبار به استفاده از حالت XDP_COPY به جای zero copy برای سوکت‌های AF_XDP. این گزینه می‌تواند برای درایورهایی که پشتیبانی AF_XDP در آن‌ها معیوب است مفید باشد. پیش‌فرض no است.

metrics-enable: <yes or no>

فعال‌سازی نقطه پایانی HTTP معیارهای prometheus. این بخش همان آمارهای دستور nsd-control stats_noreset را اما با نام‌های معیار مطابق با مشخصات prometheus نمایش می‌دهد. (به libevent2 نیاز دارد)

برای تولید معیارها به ازای هر ناحیه (یا دقیق‌تر، به ازای هر گروه zonestats)، گزینه zonestats را روی نواحی مورد نظر مشخص کنید. این کار معیارهای zonestats را با نام zonestats به عنوان برچسبی به نام "zone" نشان می‌دهد؛ به عنوان مثال با zonestats: examplezone:

nsd_zonestats_queries_total{zone="examplezone"}

توجه داشته باشید هنگام استفاده از nsd-control stats (به جای nsd-control stats_noreset)، آمارها برای نقطه پایانی معیارهای HTTP نیز بازنشانی (reset) خواهند شد.

metrics-interface: <ip4 or ip6 | interface name>

سرور NSD به نشانی‌ها یا رابط‌های فهرست‌شده برای ارائه معیارهای prometheus متصل می‌شود. می‌تواند چندین بار برای اتصال به چند نشانی IP تکرار شود. از 0.0.0.0 و 0:: برای اتصال به رابط عام استفاده کنید.

اگر به جای ip4 یا ip6 از نام رابط استفاده شود، لیست نشانی‌های IP مرتبط با آن رابط در زمان راه‌اندازی سرور دریافت و استفاده می‌شود.

پیش‌فرض 127.0.0.1 و 1:: است.

metrics-port: <number>

شماره درگاه برای سرویس HTTP. پیش‌فرض 9100 است.

metrics-path: <string>

مسیر HTTP برای ارائه معیارها. پیش‌فرض "/metrics" است.

کنترل از راه دور (Remote Control)

بخش remote-control: برای تنظیم گزینه‌های مربوط به استفاده از ابزار nsd-control(8) جهت ارسال دستورات به سرور NSD در حال اجرا استفاده می‌شود. این قابلیت به طور پیش‌فرض غیرفعال است و به طور پیش‌فرض به localhost گوش می‌دهد. از TLS روی TCP استفاده می‌کند که در آن سرور و کلاینت با گواهی‌های خودامضاشده (self-signed) نسبت به یکدیگر احراز هویت می‌شوند. گواهی‌های خودامضاشده را می‌توان با ابزار nsd-control-setup ایجاد کرد. فایل‌های کلید قبل از chroot و قبل از سلب امتیازات کاربر توسط NSD خوانده می‌شوند، بنابراین می‌توانند خارج از chroot بوده و فقط توسط کاربر ارشد (superuser) قابل خواندن باشند.

control-enable: <yes or no>

فعال‌سازی کنترل از راه دور. پیش‌فرض no است.

control-interface: <ip4 or ip6 | interface name | absolute path>

سرور NSD به نشانی‌های فهرست‌شده برای سرویس‌دهی به درخواست‌های کنترل (روی TCP) متصل می‌شود. می‌تواند چندین بار برای چند نشانی تکرار شود. برای سرویس‌دهی روی رابط عام از 0.0.0.0 و 0:: استفاده کنید. در صورت فعال بودن با control-enable، اگر هیچ مقداری داده نشود، NSD به رابط‌های localhost یعنی 127.0.0.1 و 1:: گوش می‌دهد.

اگر به جای ip4 یا ip6 از نام رابط استفاده شود، فهرست نشانی‌های IP مرتبط با آن رابط در زمان شروع به کار سرور دریافت و استفاده می‌شود.

با یک مسیر مطلق، یک لوله نام‌گذاری‌شده یونیکس (named pipe) برای کنترل استفاده می‌شود. فایل با کاربر و گروه پیکربندی‌شده ایجاد می‌شود و بیت‌های دسترسی طوری تنظیم می‌شوند که به اعضای گروه اجازه دسترسی بدهند. دسترسی بیشتر را می‌توان با تنظیم مجوزها روی دایرکتوری حاوی فایل سوکت کنترل مدیریت کرد. هنگامی که کنترل از طریق لوله نام‌گذاری‌شده باشد، از فایل‌های کلید و گواهی استفاده نمی‌شود، زیرا کنترل دسترسی از طریق مجوزهای فایل و دایرکتوری انجام می‌گیرد.

control-port: <number>

شماره درگاه برای سرویس کنترل از راه دور. به طور پیش‌فرض 8952 است.

server-key-file: <filename>

مسیر کلید خصوصی سرور؛ به طور پیش‌فرض //etc/nsd/nsd_server.key. این فایل توسط ابزار nsd-control-setup ایجاد می‌شود. این فایل توسط سرور nsd استفاده می‌شود اما توسط nsd-control استفاده نمی‌شود.

server-cert-file: <filename>

مسیر گواهی خودامضاشده سرور؛ به طور پیش‌فرض //etc/nsd/nsd_server.pem. این فایل توسط ابزار nsd-control-setup تولید می‌شود. این فایل توسط سرور nsd و همچنین توسط nsd-control استفاده می‌شود.

control-key-file: <filename>

مسیر کلید خصوصی کلاینت کنترل؛ به طور پیش‌فرض //etc/nsd/nsd_control.key. این فایل توسط ابزار nsd-control-setup تولید می‌شود. این فایل توسط nsd-control استفاده می‌شود.

control-cert-file: <filename>

مسیر گواهی کلاینت کنترل؛ به طور پیش‌فرض //etc/nsd/nsd_control.pem. این گواهی باید با گواهی سرور امضا شود. این فایل توسط ابزار nsd-control-setup تولید می‌شود. این فایل توسط nsd-control استفاده می‌شود.

گزینه‌های اعتبارسنج (Verifier options)

بخش verify: برای فعال یا غیرفعال کردن اعتبارسنجی ناحیه، پیکربندی رابط‌های شنونده و کنترل پیش‌فرض‌های سراسری به کار می‌رود.

enable: <yes or no>

فعال‌سازی اعتبارسنجی ناحیه. پیش‌فرض no است.

port: <number>

درگاهی که باید به پرس‌وجوهای اعتبارسنج روی آن پاسخ داده شود. پیش‌فرض 5347 است.

ip-address:

رابط‌هایی برای اتصال جهت اعتبارسنجی ناحیه (پیش‌فرض رابط‌های localhost، معمولاً 127.0.0.1 و 1:: هستند). برای اتصال به چندین نشانی IP، آن‌ها را یکی یکی فهرست کنید. گزینه‌های سوکت را نمی‌توان برای ip-address در verify مشخص کرد.

verify-zones: <yes or no>

اعتبارسنجی نواحی به صورت پیش‌فرض.

verifier: <command>

هنگامی که یک به‌روزرسانی برای ناحیه دریافت می‌شود (توسط IXFR یا AXFR)، این برنامه برای ارزیابی ناحیه به همراه به‌روزرسانی اجرا می‌شود. اگر برنامه با کد وضعیت 0 خارج شود، ناحیه سالم در نظر گرفته شده و سرویس‌دهی می‌شود. هر کد وضعیت دیگری ناحیه را نامعتبر تشخیص داده و به‌روزرسانی دریافتی کنار گذاشته می‌شود. سرویس‌دهی به ناحیه ادامه خواهد یافت اما بدون به‌روزرسانی جدید.

متغیرهای محیطی زیر در دسترس برنامه‌های اعتبارسنج هستند:

VERIFY_ZONE
نام دامنه ناحیه‌ای که باید اعتبارسنجی شود.

VERIFY_ZONE_ON_STDIN
هنگامی که ناحیه بتواند از ورودی استاندارد (stdin) خوانده شود، این متغیر روی "yes" تنظیم می‌شود، در غیر این صورت روی "no" تنظیم خواهد بود.

VERIFY_IP_ADDRESSES
اولین نشانی‌ای که نواحی مورد ارزیابی روی آن سرویس‌دهی خواهند شد. اگر IPv6 در دسترس باشد، یک نشانی IPv6 نسبت به IPv4 ترجیح داده می‌شود.

VERIFY_PORT
شماره درگاه برای VERIFY_IP_ADDRESS.

VERIFY_IPV6_ADDRESS
اولین نشانی IPv6 که نواحی مورد ارزیابی روی آن سرویس‌دهی خواهند شد.

VERIFY_IPV6_PORT
شماره درگاه برای VERIFY_IPV6_ADDRESS.

VERIFY_IPV4_ADDRESS
اولین نشانی IPv4 که نواحی مورد ارزیابی روی آن سرویس‌دهی خواهند شد.

VERIFY_IPV4_PORT
شماره درگاه برای VERIFY_IPV4_ADDRESS.

verifier-count: <number>

حداکثر تعداد اعتبارسنج‌ها برای اجرای همزمان. پیش‌فرض 1 است.

verifier-feed-zone: <yes or no>

ارسال ناحیه به‌روزرسانی‌شده به اعتبارسنج از طریق ورودی استاندارد (stdin).

verifier-timeout: <seconds>

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

گزینه‌های الگو (Pattern Options)

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

name: <string>

نام الگو. این یک رشته متنی (حساس به بزرگ و کوچکی حروف) است. نام‌های الگویی که با "_implicit_" شروع می‌شوند، به صورت داخلی برای نواحی فاقد الگو (که مستقیماً در nsd.conf تعریف شده‌اند) استفاده می‌شوند.

include-pattern: <pattern-name>

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

<zone option>: <value>

گزینه‌های ناحیه مانند zonefile، allow-query، allow-notify، request-xfr، allow-axfr-fallback، notify، notify-retry، provide-xfr، store-ixfr، ixfr-number، ixfr-size، create-ixfr، zonestats، outgoing-interface، verify-zone، verifier، verifier-feed-zone، verifier-timeout، catalog و catalog-member-pattern می‌توانند مشخص شوند. آن‌ها به الگوها و نواحی شامل این الگو اعمال می‌شوند.

گزینه‌های ناحیه (Zone Options)

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

برای نواحی که در فایل پیکربندی nsd.conf پیکربندی شده‌اند، تنظیمات آن‌ها به صورت ثابت (در یک الگوی ضمنی فقط برای خودشان) تعریف می‌شود و نمی‌توان آن‌ها را از طریق delzone حذف کرد، بلکه باید آن‌ها را از فایل پیکربندی حذف کرده و عمل repattern را انجام داد.

name: <string>

نام ناحیه. این نام دامنه رأس (apex) ناحیه است. ممکن است با '.' (در قالب FQDN) خاتمه یابد؛ به عنوان مثال "example.com"، "sub.example.net.". این مشخصه باید در هر ناحیه وجود داشته باشد.

zonefile: <filename>

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

این رشته به گونه‌ای پردازش می‌شود که بتوان از یک رشته (در یک الگو) برای تعداد زیادی از نواحی مختلف استفاده کرد. اگر برچسب یا کاراکتر وجود نداشته باشد، کاراکتر درصد با یک نقطه در خروجی جایگزین می‌شود (مثلاً برای کاراکتر سوم در یک نام دامنه دو حرفی). کاراکتر اسلش '/' هنگامی که درون رشته '%s' قرار گیرد به صورت "\047" فراردهی (escape) می‌شود. دایرکتوری‌ها در صورت لزوم، هنگامی که دایرکتوری به عنوان بخشی از رشته zonefile مشخص شده باشد، ایجاد می‌شوند؛ مانند "%1/%2/%s.zone".

%s با نام ناحیه جایگزین می‌شود.

%1 با اولین کاراکتر نام ناحیه جایگزین می‌شود.

%2 با دومین کاراکتر نام ناحیه جایگزین می‌شود.

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

%z با نام دامنه سطح بالا (TLD) ناحیه جایگزین می‌شود.

%y با برچسب بعدی زیر دامنه سطح بالا جایگزین می‌شود.

%x با برچسب بعدی پس از آن جایگزین می‌شود.

allow-query: <ip-spec> <key-name | NOKEY | BLOCKED>

فهرست کنترل دسترسی. هنگامی که حداقل یک گزینه allow-query مشخص شده باشد، نشانی‌های تعیین‌شده در این گزینه‌ها مجاز به ارسال پرس‌وجو به سرور برای این ناحیه هستند. پرس‌وجوها از نشانی‌های فهرست‌نشده یا صراحتاً BLOCKED دور انداخته می‌شوند. اگر NOKEY داده شود نیازی به امضای TSIG نیست. BLOCKED بر سایر ورودی‌ها تقدم دارد و سایر ورودی‌ها به ترتیب عبارت‌ها بررسی می‌شوند. بدون گزینه‌های allow-query، پرس‌وجوها از هر نشانی IP بدون کلید TSIG مجاز هستند (که حالت پیش‌فرض است).

مقدار ip-spec یا یک نشانی IP ساده (IPv4 یا IPv6) است، یا می‌تواند زیرشبکه‌ای به شکل 1.2.3.4/24 باشد، یا دارای ماسک مانند 1.2.3.4&255.255.255.0 یا محدوده‌ای به شکل 1.2.3.4-1.2.3.25 باشد. توجه داشته باشید که در محدوده‌های ip-spec نباید در اطراف نمادهای /، &، @ و - از فاصله استفاده شود.

allow-notify: <ip-spec> <key-name | NOKEY | BLOCKED>

فهرست کنترل دسترسی. نشانی (اصلی) فهرست‌شده مجاز است اعلان‌ها (notifies) را از طریق UDP یا TCP به این سرور (ثانویه) ارسال کند. اعلان‌های دریافتی از نشانی‌های فهرست‌نشده یا مسدودشده (BLOCKED) نادیده گرفته می‌شوند. اگر NOKEY داده شود نیازی به امضای TSIG نیست. عبارت BLOCKED بر سایر ورودی‌ها تقدم دارد و سایر ورودی‌ها به ترتیبی که نوشته شده‌اند بررسی می‌شوند.

مقدار ip-spec یک نشانی IP ساده (IPv4 یا IPv6)، یک زیرشبکه مانند 1.2.3.4/24، با ماسک مانند 1.2.3.4&255.255.255.0 یا یک محدوده مانند 1.2.3.4-1.2.3.25 است. شماره درگاه را می‌توان با پسوند number@ اضافه کرد؛ به عنوان مثال 1.2.3.4@5300 یا 1.2.3.4/24@5300 برای درگاه 5300. توجه داشته باشید که در فواصل محدوده‌های ip-spec نباید در اطراف نمادهای /، &، @ و - از فاصله استفاده شود.

request-xfr: [AXFR|UDP] <ip-address> <key-name | NOKEY> [tls-auth-name]

فهرست کنترل دسترسی. در هنگام به‌روزرسانی، از نشانی فهرست‌شده (سرور اصلی) برای AXFR/IXFR پرس‌وجو می‌شود. شماره درگاه را می‌توان با پسوند number@ اضافه کرد؛ مانند 1.2.3.4@5300. کلید مشخص‌شده در طول فرآیند AXFR/IXFR استفاده می‌شود. اگر tls-auth-name درج شود، از بخش tls-auth مشخص‌شده برای انجام XFR-over-TLS با احراز هویت استفاده خواهد شد.

اگر گزینه AXFR داده شود، با سرور از طریق پرس‌وجوهای IXFR ارتباط برقرار نخواهد شد و فقط درخواست‌های AXFR ارسال می‌شوند. این ویژگی به سرور ثانویه NSD اجازه می‌دهد تا سرور اصلی داشته باشد که روی آن NSD اجرا می‌شود. اگر گزینه AXFR حذف شود، هر دو درخواست IXFR و AXFR به سرور اصلی ارسال می‌شوند.

اگر گزینه UDP داده شود، سرور ثانویه از UDP برای انتقال درخواست‌های IXFR استفاده خواهد کرد. در صورت مجاز کردن انتقال UDP، برای احراز هویت اعلان‌ها و انتقال‌های ناحیه باید از TSIG استفاده کنید؛ در غیر این صورت NSD در برابر حملات نوع کامینسکی (Kaminsky) آسیب‌پذیرتر خواهد بود. اگر گزینه UDP حذف شود، IXFR با استفاده از TCP انتقال می‌یابد.

اگر tls-auth-name داده شود، از TLS (به طور پیش‌فرض روی درگاه 853) برای تمامی انتقال‌های این ناحیه استفاده خواهد شد. اگر احراز هویت سرور اصلی بر اساس اطلاعات tls-auth مشخص‌شده ناموفق باشد، درخواست XFR ارسال نخواهد شد. پشتیبانی از TLS 1.3 برای XFR-over-TLS الزامی است.

allow-axfr-fallback: <yes or no>

این گزینه باید همراه با request-xfr باشد. این گزینه به NSD (به عنوان ثانویه) اجازه می‌دهد (یا مانع می‌شود) که در صورت عدم پشتیبانی سرور نام اصلی از IXFR، به AXFR عقب‌نشینی کند. پیش‌فرض yes است.

size-limit-xfr: <number>

این گزینه باید همراه با request-xfr باشد. این گزینه محدودیت اندازه فایل موقت XFR را تعیین می‌کند. می‌توان از آن برای متوقف کردن دریافت نواحی بسیار بزرگ که می‌توانند حافظه و فضای دیسک زیادی را اشغال کنند، استفاده کرد. اگر این گزینه 0 باشد، نامحدود است. مقدار پیش‌فرض 0 است.

notify: <ip-address> <key-name | NOKEY>

فهرست کنترل دسترسی. به نشانی فهرست‌شده (سرور ثانویه) از به‌روزرسانی‌های این ناحیه از طریق UDP اطلاع داده می‌شود. شماره درگاه را می‌توان با پسوند number@ اضافه کرد؛ مانند 1.2.3.4@5300. کلید مشخص‌شده برای امضای اعلان استفاده می‌شود. سرور NSD تنها در پیکربندی‌های ثانویه قادر به تشخیص به‌روزرسانی‌های ناحیه خواهد بود (زیرا خودش اعلان را دریافت می‌کند یا پس از مدتی تازه‌سازی انجام می‌دهد).

notify-retry: <number>

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

provide-xfr: <ip-spec> <key-name | NOKEY | BLOCKED> [tls-auth-name]

فهرست کنترل دسترسی. نشانی فهرست‌شده (یک ثانویه) مجاز به درخواست XFR از این سرور است. داده‌های ناحیه در اختیار آن نشانی قرار می‌گیرد. کلید مشخص‌شده در طول XFR استفاده می‌شود. برای نشانی‌های فهرست‌نشده یا BLOCKED داده‌ای ارائه نمی‌شود و درخواست‌ها نادیده گرفته می‌شوند. عبارت BLOCKED بر سایر ورودی‌ها تقدم دارد و سایر ورودی‌ها به ترتیب عبارت‌ها بررسی می‌شوند.

مقدار ip-spec یک نشانی IP ساده (IPv4 یا IPv6)، یک زیرشبکه مانند 1.2.3.4/24، با ماسک مانند 1.2.3.4&255.255.255.0 یا یک محدوده مانند 1.2.3.4-1.2.3.25 است. شماره درگاه را می‌توان با پسوند number@ اضافه کرد؛ مانند 1.2.3.4@5300 یا 1.2.3.4/24@5300 برای درگاه 5300. توجه داشته باشید که در فواصل محدوده‌های ip-spec نباید در اطراف نمادهای /، &، @ و - فاصله قرار گیرد.

اگر tls-auth-name داده شود، احراز هویت TLS برای سرور ثانویه در درخواست‌های انتقال این ناحیه انجام خواهد شد. طرف راه دور باید به tls-auth-port متصل شود و باید گواهی‌ای با ورودی SAN (Subject Alternative Name) DNS یا CN (Common Name) برابر با auth-domain-name تعریف‌شده در tls-auth ارائه دهد. اعتبار گواهی نیز با tls-cert-bundle بررسی می‌شود. اگر احراز هویت ثانویه بر اساس اطلاعات tls-auth ناموفق باشد، انتقال ناحیه XFR رد خواهد شد. اگر اتصال روی tls-port انجام شود، احراز هویتی انجام نمی‌شود و انتقال رد نخواهد شد. برای اجبار به انتقال‌های ناحیه فقط به صورت احراز هویت‌شده، گزینه tls-auth-xfr-only نیز باید فعال شود. پشتیبانی از TLS 1.3 برای XFR-over-TLS الزامی است.

outgoing-interface: <ip-address>

فهرست کنترل دسترسی. نشانی فهرست‌شده برای درخواست AXFR|IXFR (در حالت سرور ثانویه) یا برای ارسال اعلان‌ها (در حالت سرور اصلی) استفاده می‌شود.

مقدار ip-address یک نشانی IP ساده (IPv4 یا IPv6) است. شماره درگاه را می‌توان با پسوند number@ اضافه کرد؛ مانند 1.2.3.4@5300.

store-ixfr: <yes or no>

در صورت فعال بودن، محتویات IXFR ذخیره شده و به مجموعه کلاینت‌های مشخص‌شده در عبارت provide-xfr ارائه می‌شود. پیش‌فرض no است. محتوای IXFR شامل مجموعه کوچک‌تری از تغییرات متفاوت بین نگارش‌های ناحیه است، در حالی که AXFR شامل کل محتوای ناحیه است.

ixfr-number: <number>

حداکثر تعداد نگارش‌های IXFR برای ذخیره‌سازی در این ناحیه. پیش‌فرض 5 است.

ixfr-size: <number>

حداکثر فضای ذخیره‌سازی مورد استفاده برای نگارش‌های IXFR در این ناحیه به بایت. پیش‌فرض 1048576 است. مقدار 0 به معنای نامحدود است. اگر می‌خواهید ذخیره‌سازی IXFR را غیرفعال کنید، گزینه store-ixfr را روی no قرار دهید. سرور NSD محتویات IXFR را از نگارش‌هایی که داده‌های یکسانی را اضافه و حذف می‌کنند حذف نمی‌کند. این نرم‌افزار IXFRها را همان‌طور که توسط سرور بالادستی منتقل شده‌اند، ذخیره و ارسال می‌کند.

create-ixfr: <yes or no>

در صورت فعال بودن، هنگام خواندن یک فایل ناحیه توسط سرور، داده‌های IXFR ایجاد می‌شوند. این مورد مستلزم تنظیم store-ixfr روی yes است تا محتویات IXFR روی دیسک ذخیره شوند. پیش‌فرض off است. اگر سرور در حال اجرا نیست، می‌توان از گزینه nsd-checkzone -i برای ایجاد فایل IXFR استفاده کرد. هنگامی که یک IXFR ایجاد می‌شود، سرور یک نسخه از ناحیه را در یک فایل موقت در مکانی که فایل‌های ixfr ذخیره می‌شوند، ذخیره (spool) می‌کند. این گزینه هنگام خواندن ناحیه از فایل داده‌های IXFR تولید می‌کند، اما هنگامی که ناحیه از طریق انتقال AXFR از یک سرور خوانده می‌شود چنین نمی‌کند؛ زیرا در آن حالت بالاترین سروری که منشا داده‌هاست تنها جایی است که تفاوت‌های IXFR در آن محاسبه می‌شود و آن تفاوت‌ها سپس عیناً به سایر سرورها منتقل می‌گردند.

max-refresh-time: <seconds>

محدود کردن زمان تازه‌سازی (refresh) برای نواحی ثانویه. این زمان‌سنج بررسی می‌کند که آیا ناحیه پس از انقضا باید مجدداً دریافت شود یا خیر. به طور معمول از مقدار موجود در رکورد SOA استفاده می‌شود، اما این گزینه آن مقدار را محدود می‌کند.

min-refresh-time: <seconds>

حداقل زمان تازه‌سازی برای نواحی ثانویه.

max-retry-time: <seconds>

محدود کردن زمان تلاش مجدد (retry) برای نواحی ثانویه. این زمان‌سنجی است که پس از تلاش ناموفق برای دریافت ناحیه، دوباره تلاش می‌کند. به طور معمول از مقدار موجود در رکورد SOA همراه با عقب‌نشینی نمایی استفاده می‌شود، اما این گزینه آن مقدار را محدود می‌کند.

min-retry-time: <seconds>

حداقل زمان تلاش مجدد برای نواحی ثانویه.

min-expire-time: <seconds or refresh+retry+1>

محدود کردن زمان انقضا برای نواحی ثانویه. مقدار را می‌توان با تعداد ثانیه‌ها یا رشته "refresh+retry+1" مشخص کرد. در حالت دوم، زمان انقضا دارای حد پایینی برابر با مجموع مقادیر refresh و retry از رکورد SOA به علاوه 1 خواهد بود. مقادیر refresh و retry در صورت تعیین شدن، تابع محدودیت‌های پیکربندی‌شده با max-refresh-time، min-refresh-time، max-retry-time و min-retry-time خواهند بود.

zonestats: <name>

در صورتی که بدون zone-stats کامپایل نشده باشد، NSD می‌تواند آمارها را به ازای هر ناحیه جمع‌آوری کند. این نام گروهی را مشخص می‌کند که آمارها به آن اضافه می‌شوند. این گروه‌ها در خروجی دستورات stats و stats_noreset در nsd-control ظاهر می‌شوند. پیش‌فرض "" است. می‌توانید از "%s" برای استفاده از نام ناحیه جهت ردیابی آمار آن استفاده کنید. اگر در زمان کامپایل گنجانده نشده باشد، این گزینه می‌تواند مشخص شود اما نادیده گرفته خواهد شد.

include-pattern: <pattern-name>

گزینه‌های مربوط به الگوی داده‌شده در این نقطه اضافه می‌شوند. الگوی ارجاع داده‌شده باید بالاتر از این ناحیه تعریف شده باشد.

rrl-whitelist: <rrltype>

این گزینه باعث می‌شود که پرس‌وجوهای مربوط به این rrltype برای این ناحیه در فهرست سفید قرار گیرند. آن‌ها محدودیت whitelist-ratelimit را دریافت می‌کنند. می‌توانید چندین خط بنویسید که هر کدام یک rrltype جدید را برای ناحیه مجاز می‌کند. پیش‌فرض فاقد هرگونه فهرست سفید است. مقدار rrltype طبقه‌بندی پرس‌وجویی است که RRL در NSD برای جلوگیری از تداخل انواع مختلف به کار می‌برد. این انواع در خطوط گزارش هنگام مسدود شدن یک زیرشبکه ثبت می‌شوند (در سطح پرگویی 2). انواع طبقه‌بندی RRL عبارتند از: nxdomain، error، referral، any، rrsig، wildcard، nodata، dnskey، positive، all.

multi-primary-check: <yes or no>

پیش‌فرض no است. در صورت فعال بودن، تمام سرورهای اصلی را برای آخرین نگارش بررسی می‌کند. از بالاترین نگارش در میان تمام سرورهای اصلی پیکربندی‌شده استفاده می‌کند. اگر چندین سرور اصلی دارید که شماره نگارش‌های متفاوتی را ارائه می‌دهند، بسیار مفید است.

verify-zone: <yes or no>

فعال یا غیرفعال کردن اعتبارسنجی برای این ناحیه. پیش‌فرض مقادیر verify-zones پیکربندی‌شده در verify: است.

verifier: <command>

دستوری که برای ارزیابی این ناحیه اجرا می‌شود. پیش‌فرض verifier پیکربندی‌شده در verify: است.

verifier-feed-zone: <yes or no>

ارسال ناحیه به‌روزرسانی‌شده به اعتبارسنج از طریق ورودی استاندارد. پیش‌فرض verifier-feed-zone پیکربندی‌شده در verify: است.

verifier-timeout: <seconds>

تعداد ثانیه‌ها قبل از اینکه اعتبارسنج به اجبار متوقف شود. عدد 0 (صفر) را مشخص کنید تا از مهلت زمانی مشخصی استفاده نشود. پیش‌فرض verifier-timeout از verify: است.

catalog: <consumer or producer>

اگر روی consumer تنظیم شود، پردازش ناحیه کاتالوگ برای این ناحیه فعال می‌شود. تنها یک ناحیه منفرد می‌تواند به عنوان ناحیه مصرف‌کننده کاتالوگ (consumer) پیکربندی شود. اگر بیش از یک ناحیه مصرف‌کننده کاتالوگ پیکربندی شود، هیچ‌کدام پردازش نخواهند شد. نواحی عضو کاتالوگ از الگوی مشخص‌شده توسط ویژگی group استفاده می‌کنند؛ یا اگر ویژگی group وجود نداشته یا نامعتبر باشد، الگوی مشخص‌شده توسط گزینه catalog-member-pattern استفاده می‌شود. ویژگی‌های group تنها در صورتی معتبر هستند که یک مقدار منطبق بر نام یک الگوی معتبر برای نواحی عضو داشته باشند.

ناحیه‌ای با این گزینه تنظیم‌شده روی producer، می‌تواند برای تولید یک ناحیه کاتالوگ استفاده شود. نواحی عضو برای نواحی تولیدکننده کاتالوگ را می‌توان با "nsd-control addzone <zone> <pattern>" اضافه کرد، که در آن <pattern> دارای یک گزینه catalog-producer-zone اشاره‌کننده به یک ناحیه تولیدکننده کاتالوگ است. اعضا یک ویژگی group با نام الگو به عنوان مقدار دریافت خواهند کرد. نواحی تولیدکننده کاتالوگ باید نواحی اصلی باشند و نباید گزینه request-xfr داشته باشند. نواحی تولیدکننده کاتالوگ محتوا را از فایل‌های ناحیه نمی‌خوانند، بلکه ناحیه را هنگام راه‌اندازی از ورودی‌های ناحیه عضو در //var/db/nsd/zone.list که با گزینه zonelistfile مشخص شده است، بازسازی می‌کنند.

وضعیت هر دو نوع ناحیه مصرف‌کننده و تولیدکننده کاتالوگ را می‌توان با nsd-control zonestatus بررسی کرد. این دستور تعداد نواحی عضو و در صورت نامعتبر بودن ناحیه کاتالوگ، دلیل نامعتبر بودن را نشان می‌دهد. nsd-control zonestatus همچنین ورودی یک ناحیه عضو کاتالوگ را در ناحیه کاتالوگ به صورت catalog-member-id: نشان خواهد داد.

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

نواحی کاتالوگ حاوی فهرستی از نواحی سرویس‌دهی‌شده هستند. از allow-query: 0.0.0.0/0 BLOCKED و allow-query: ::0/0 BLOCKED در بخش ناحیه کاتالوگ یا الگو استفاده کنید تا از افشای کاتالوگ جلوگیری شود. همچنین استفاده از انتقال‌ها روی TLS را برای محافظت بیشتر از کاتالوگ در برابر شنود در نظر بگیرید.

catalog-member-pattern: <pattern-name>

اگر این گزینه برای یک ناحیه مصرف‌کننده کاتالوگ ارائه شود، اعضای آن کاتالوگ که ویژگی group گم‌شده یا نامعتبر دارند با استفاده از الگوی <pattern-name> اضافه خواهند شد.

catalog-producer-zone: <zone-name>

این گزینه فقط در یک الگو قابل استفاده است. افزودن یک ناحیه با استفاده از "nsd-control addzone <zone> <pattern>" با یک <pattern> حاوی این گزینه، باعث ایجاد یک ورودی عضو کاتالوگ در ناحیه تولیدکننده کاتالوگ <zone-name> می‌شود. <zone-name> باید وجود داشته باشد و یک ناحیه تولیدکننده کاتالوگ معتبر باشد.

تعریف کلیدها (Key Declarations)

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

name: <string>

نام کلید. برای ارجاع به این کلید در فهرست کنترل دسترسی استفاده می‌شود. برای اینکه tsig کار کند، نام کلید باید دقیق باشد؛ زیرا نام کلید روی شبکه ارسال می‌شود.

algorithm: <string>

الگوریتم احراز هویت برای این کلید؛ مانند hmac-md5، hmac-sha1، hmac-sha224، hmac-sha256، hmac-sha384 و hmac-sha512. همچنین می‌تواند به صورت 'sha1' یا 'sha256' خلاصه شود. پیش‌فرض sha256 است. الگوریتم‌ها تنها در صورتی در دسترس هستند که در زمان ساخت در کتابخانه رمزنگاری کامپایل شده باشند.

secret: <base64 blob>

رمز محرمانه مشترک کدگذاری‌شده با base64. این امکان وجود دارد که اعلان secret: (و داده base64) را در یک فایل جداگانه قرار داده و سپس آن فایل را با include: فراخوانی کرد. به این ترتیب می‌توان کلید محرمانه را از بقیه فایل پیکربندی که ممکن است سیاست‌های امنیتی متفاوتی داشته باشد، جدا کرد. محتوای secret همان محتوای توافق‌شده محرمانه در قالب base64 است. برای ایجاد آن، یک گذرواژه وارد کنید (طول آن باید مضربی از 4 کاراکتر، A-Za-z0-9 باشد)، یا از خروجی dev-random که با یک فیلتر base64 کدگذاری شده استفاده نمایید.

تعاریف احراز هویت TLS (TLS Auth Declarations)

بخش tls-auth: مشخصه‌هایی را برای احراز هویت طرف مقابل در یک اتصال TLS و همچنین تعریف اعتبارنامه‌ها جهت احراز هویت در یک سرور راه دور تعیین می‌کند. این بخش در فهرست‌های کنترل دسترسی برای XFR-over-TLS استفاده می‌شود و دارای مشخصه‌های زیر است:

name: <string>

نام tls-auth. برای ارجاع به این اطلاعات احراز هویت TLS در فهرست کنترل دسترسی استفاده می‌شود.

auth-domain-name: <string>

نام دامنه احراز هویت همان‌طور که در RFC8310 تعریف شده است. برای تأیید گواهی سرور متصل‌شونده راه دور استفاده می‌شود. هنگامی که توسط یک سرور اصلی در provide-xfr استفاده شود، سرور ثانویه را تأیید می‌کند. هنگامی که توسط یک سرور ثانویه در request-xfr استفاده شود، سرور اصلی را تأیید می‌کند.

client-cert: <file name of clientcert.pem>

اگر می‌خواهید از احراز هویت متقابل TLS استفاده کنید، در اینجا گواهی‌های کلاینتی که NSD برای اتصال به سرور بالادستی جهت بارگیری ناحیه استفاده می‌کند، قابل پیکربندی است. فایل گواهی pem کلید عمومی کلاینت می‌تواند در اینجا پیکربندی شود. همچنین یک کلید خصوصی را با client-key پیکربندی کنید.

client-key: <file name of clientkey.key>

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

client-key-pw: <string>

اگر فایل client-key از یک گذرواژه برای رمزگشایی کلید قبل از استفاده استفاده می‌کند، گذرواژه را می‌توان در اینجا به عنوان یک رشته متنی مشخص کرد. امکان افزودن فایل‌های پیکربندی دیگر با گزینه include: وجود دارد و در صورت تمایل می‌توان از این قابلیت برای انتقال این داده‌های حساس به فایلی دیگر استفاده کرد.

گزینه‌های ثبت وقایع DNSTAP (DNSTAP Logging Options)

پشتیبانی از DNSTAP، در صورت کامپایل شدن، در بخش dnstap: فعال می‌شود. این کار یک فرآیند جمع‌آوری‌کننده را راه‌اندازی می‌کند که اطلاعات گزارش را به مقصد می‌نویسد.

dnstap-enable: <yes or no>

آیا dnstap فعال است یا خیر. پیش‌فرض no است. در صورت تنظیم روی yes، به سرور dnstap متصل می‌شود و در صورت فعال بودن هر یک از گزینه‌های dnstap-log-..-messages، گزارش‌های آن پیام‌ها را به سرور ارسال می‌کند.

dnstap-socket-path: <file name>

نام فایل سوکت یونیکس را برای اتصال به سروری که به آن سوکت گوش می‌دهد تنظیم می‌کند. پیش‌فرض "//var/run/nsd-dnstap.sock" است.

dnstap-ip: <"" or addr[@port]>

در صورت غیرفعال بودن با ""، از مسیر سوکت استفاده می‌شود. با یک مقدار مانند address یا address@port (مثلاً "127.0.0.1@3333") از TCP یا TLS استفاده می‌شود. پیش‌فرض "" است.

dnstap-tls: <yes or no>

در صورت فعال بودن، از TLS به نشانی مشخص‌شده در dnstap-ip استفاده می‌شود. در غیر این صورت از TCP استفاده خواهد شد. پیش‌فرض yes است.

dnstap-tls-server-name: <string>

نام برای احراز هویت سرور بالادستی. با مقدار "" غیرفعال می‌شود.

dnstap-tls-client-key-file: <file name>

فایل کلید برای احراز هویت کلاینت، یا "" برای غیرفعال کردن.

dnstap-tls-client-cert-file: <file name>

فایل گواهی برای احراز هویت کلاینت، یا "" برای غیرفعال کردن.

dnstap-send-identity: <yes or no>

در صورت فعال بودن، هویت سرور در پیام‌های گزارش گنجانده می‌شود. پیش‌فرض no است.

dnstap-send-version: <yes or no>

در صورت فعال بودن، نگارش سرور در پیام‌های گزارش گنجانده می‌شود. پیش‌فرض no است.

dnstap-identity: <string>

هویتی که همراه با پیام‌ها ارسال می‌شود؛ اگر "" باشد از نام میزبان (hostname) استفاده می‌شود. پیش‌فرض "" است.

dnstap-version: <string>

نگارشی که با پیام‌ها ارسال می‌شود؛ اگر "" باشد از نگارش بسته استفاده می‌شود. پیش‌فرض "" است.

dnstap-log-auth-query-messages: <yes or no>

فعال‌سازی ثبت پیام‌های پرس‌وجوی معتبر (auth query). پیش‌فرض no است. این‌ها پرس‌وجوهای کلاینت به NSD هستند.

dnstap-log-auth-response-messages: <yes or no>

فعال‌سازی ثبت پیام‌های پاسخ معتبر (auth response). پیش‌فرض no است. این‌ها پاسخ‌های ارسالی از NSD به کلاینت‌ها هستند.

نواحی ثانویه (Secondary zones)

برای یک ناحیه ثانویه، سرورهای اصلی فهرست می‌شوند. سرورهای اصلی برای دریافت داده‌های ناحیه مورد پرس‌وجو قرار می‌گیرند و برای اعلان‌های به‌روزرسانی به آن‌ها گوش داده می‌شود. در NSD این دو ویژگی باید به طور جداگانه، با فهرست کردن نشانی اصلی در دستورات allow-notify و request-xfr پیکربندی شوند.

در BIND9 فقط باید عناصر allow-notify را برای منابع اضافی اعلان‌ها (مانند اپراتورها) ارائه دهید، اما NSD باید برای هر دو یعنی سرورهای اصلی و اپراتورها دارای allow-notify باشد. BIND9 به منابع انتقال اضافی اجازه می‌دهد، در حالی که در NSD آن‌ها را به عنوان request-xfr فهرست می‌کنید.

در اینجا یک مثال از یک ناحیه ثانویه با ساختار BIND9 آمده است:

# Config file for example.org
options {
	dnssec-enable yes;
};

key tsig.example.org. {
	algorithm hmac-md5;
	secret "aaaaaabbbbbbccccccdddddd";
};

server 162.0.4.49 {
	keys { tsig.example.org. ; };
};

zone "example.org" {
	type secondary;
	file "secondary/example.org.signed";
	primaries { 162.0.4.49; };
};

# Config file for example.org
key:
	name: tsig.example.org.
	algorithm: hmac-md5
	secret: "aaaaaabbbbbbccccccdddddd"

zone:
	name: "example.org"
	zonefile: "secondary/example.org.signed"
	# the primary is allowed to notify and will provide zone data.
	allow-notify: 162.0.4.49 NOKEY
	request-xfr: 162.0.4.49 tsig.example.org.

توجه داشته باشید که سرور اصلی دو بار فهرست شده است؛ یک بار برای اینکه اجازه داشته باشد اعلان‌ها را به این سرور ثانویه ارسال کند و یک بار برای اینکه به سرور ثانویه بگوید برای به‌روزرسانی داده‌های ناحیه به کجا نگاه کند. می‌توان خطوط allow-notify و request-xfr بیشتری را برای تعیین سرورهای اصلی بیشتر اضافه کرد.

می‌توان خطوط allow-notify اضافی را برای نشانی‌هایی که مجاز به ارسال اعلان به این سرور ثانویه هستند مشخص کرد.

نواحی اصلی (Primary zones)

برای یک ناحیه اصلی در BIND9، سرورهای ثانویه فهرست می‌شوند. برای این سرورهای ثانویه اعلان‌های به‌روزرسانی ارسال می‌شود و به آن‌ها اجازه داده می‌شود انتقال داده‌های ناحیه را درخواست کنند. در NSD این دو ویژگی باید جداگانه پیکربندی شوند.

در اینجا نمونه‌ای از یک ناحیه اصلی با ساختار BIND9 آمده است:

zone "example.nl" {
	type primary;
	file "example.nl";
};

در ساختار NSD این مورد به شکل زیر تبدیل می‌شود:

zone:
	name: "example.nl"
	zonefile: "example.nl"
	# allow anybody to request xfr.
	provide-xfr: 0.0.0.0/0 NOKEY
	provide-xfr: ::0/0 NOKEY

# to list a secondary server you would in general give
# provide-xfr: 1.2.3.4 tsig-key.name.
# notify: 1.2.3.4 NOKEY

سایر موارد (Other)

سرور NSD یک سرور DNS منحصراً معتبر (Authoritative-only) است. این بدان معناست که این نرم‌افزار به عنوان سرور اصلی یا ثانویه برای نواحی عمل کرده و داده‌های DNS را در اختیار تحلیل‌کننده‌ها (resolvers) و حافظه‌های موقت (caches) دی‌ان‌اس قرار می‌دهد. BIND9 می‌تواند به عنوان یک سرور معتبر DNS عمل کند که گزینه‌های پیکربندی آن در این بخش با NSD مقایسه شدند. با این حال BIND9 می‌تواند به عنوان resolver یا cache نیز عمل کند. گزینه‌های پیکربندی مربوط به resolver یا caching در BIND9، هیچ معادلی در NSD ندارند.