KNOT.CONF(5) Knot DNS KNOT.CONF(5)

knot.conf - پرونده پیکربندی سرور Knot DNS

پرونده‌های پیکربندی Knot DNS از قالب ساده‌شدهٔ YAML استفاده می‌کنند. ساده‌شده به این معنی است که همهٔ ویژگی‌ها پشتیبانی نمی‌شوند.

برای توصیف موارد پیکربندی، نمادهای زیر تعریف می‌شوند:

  • INT – عدد صحیح
  • STR – رشتهٔ متنی
  • HEXSTR – رشتهٔ هگزادسیمال (با پیشوند 0x)
  • BOOL – مقدار بولی (on/off یا true/false)
  • TIME – تعداد ثانیه‌ها؛ عدد صحیح با امکان پسوند ضریب زمانی (s ~ 1، m ~ 60، h ~ 3600، d ~ 24 * 3600، w ~ 7 * 24 * 3600، M ~ 30 * 24 * 3600، y ~ 365 * 24 * 3600)
  • SIZE – تعداد بایت‌ها؛ عدد صحیح با امکان پسوند ضریب اندازه (B ~ 1، K ~ 1024، M ~ 1024^2 یا G ~ 1024^3)
  • BASE64 – رشتهٔ کدگذاری‌شده با Base64
  • ADDR – نشانی IPv4 یا IPv6
  • DNAME – نام دامنه
  • ... – مورد چندمقداری، ترتیب مقادیر حفظ می‌شود
  • [ ] – مقدار اختیاری
  • | – انتخاب

پیکربندی شامل چندین بخش ثابت و بخش‌های ماژول اختیاری است. ۱۸ بخش ثابت وجود دارد (module، server، xdp، control، log، statistics، database، keystore، key، remote، remotes، acl، submission، dnskey-sync، policy، external`، template، zone). بخش‌های ماژول با پیشوند mod- مشخص می‌شوند (مانند mod-stats).

بیشتر بخش‌ها (مانند zone) دنباله‌ای از بلوک‌های تنظیمات هستند. هر بلوک تنظیمات با یک شناسهٔ یکتا آغاز می‌شود که می‌تواند به‌عنوان ارجاع از بخش‌های دیگر استفاده شود (چنین شناسه‌ای باید از پیش تعریف شده باشد).

یک مورد چندمقداری می‌تواند به‌صورت دنبالهٔ YAML مشخص شود:

address: [10.0.0.1, 10.0.0.2]

یا به‌صورت چند مورد تک‌مقداری، هر کدام در یک خط جداگانه:

address: 10.0.0.1
address: 10.0.0.2

اگر مقدار یک مورد شامل فاصله یا نویسه‌های خاص دیگر باشد، قرار دادن آن مقدار داخل گیومهٔ دوتایی " " الزامی است.

در صورت عدم تعیین، موردی که نشان‌دهندهٔ یک پرونده یا مسیر دایرکتوری است می‌تواند به‌صورت یک مسیر مطلق (شروع با /)، یا یک مسیر نسبی نسبت به همان دایرکتوریِ مقدار پیش‌فرض آن مورد تعریف شود.

یک نظر با نویسهٔ # آغاز می‌شود و هنگام پردازش نادیده گرفته خواهد شد. همچنین هر بخش پیکربندی یا بلوک دنباله، امکان ثبت یک نظر دائمی را با استفاده از مورد comment فراهم می‌کند که در سرور در کنار پیکربندی ذخیره می‌شود.

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

include: STR

یک مسیر یا الگوی منطبق‌کننده برای تعیین یک یا چند پرونده که در موقعیت گزینهٔ include در پیکربندی فراخوانی می‌شوند. اگر مسیر مطلق نباشد، نسبت به پروندهٔ فعلی در نظر گرفته می‌شود. الگو می‌تواند هر رشته‌ای مطابق با نیازمندی‌های glob در POSIX باشد، مانند dir/*.conf. پرونده‌های منطبق به‌ترتیب مرتب‌شده پردازش می‌شوند.

پیش‌فرض: تنظیم نشده

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

clear: STR

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

نکته:

برای تطبیق الگو از تابع fnmatch() در POSIX https://pubs.opengroup.org/onlinepubs/9699919799/functions/fnmatch.html استفاده می‌شود. در لینوکس، افزونهٔ گنو FNM_EXTMATCH https://www.gnu.org/software/libc/manual/html_node/Wildcard-Matching.html#index-FNM_005fEXTMATCH فعال است که تطبیق الگوی گسترده را امکان‌پذیر می‌کند. نمونه‌ها:
  • clear: zone – بخش zone را پاک می‌کند.
  • clear: mod-* – همهٔ بخش‌های ماژول را پاک می‌کند.
  • clear: "[!z]*" – تمام بخش‌هایی را که با حرف z شروع نمی‌شوند پاک می‌کند.
  • clear: !(zone) – (تنها گنو) همهٔ بخش‌ها را به‌جز بخش zone پاک می‌کند.
  • clear: @(zone|template) – (تنها گنو) بخش‌های zone و template را پاک می‌کند.

پیش‌فرض: تنظیم نشده

پیکربندی بارگذاری پویای ماژول‌ها.

نکته:

اگر با پارامتر غیرخالی --with-moduledir=path پیکربندی شده باشد، تمام ماژول‌های اشتراکی در این دایرکتوری به‌طور خودکار بارگذاری می‌شوند.
module:
  - id: STR
    file: STR

یک شناسه‌ی ماژول در قالب پیشوند mod- و پسوند نام ماژول.

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

هشدار:

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

پیش‌فرض: ${libdir}/knot/modules-${version}/module_name.so (یا ${path}/module_name.so اگر با --with-moduledir=path پیکربندی شده باشد)

گزینه‌های عمومی مربوط به سرور.

server:
    identity: [STR]
    version: [STR]
    nsid: [STR|HEXSTR]
    rundir: STR
    user: STR[:STR]
    pidfile: STR
    udp-workers: INT
    tcp-workers: INT
    background-workers: INT
    async-start: BOOL
    tcp-idle-timeout: TIME
    tcp-io-timeout: INT
    tcp-remote-io-timeout: INT
    tcp-max-clients: INT
    tcp-reuseport: BOOL
    tcp-fastopen: BOOL
    quic-max-clients: INT
    quic-outbuf-max-size: SIZE
    quic-idle-close-timeout: TIME
    remote-pool-limit: INT
    remote-pool-timeout: TIME
    remote-retry-delay: INT
    socket-affinity: BOOL
    udp-max-payload: SIZE
    udp-max-payload-ipv4: SIZE
    udp-max-payload-ipv6: SIZE
    key-file: STR
    cert-file: STR
    ca-file: STR ...
    edns-client-subnet: BOOL
    answer-rotation: BOOL
    automatic-acl: BOOL
    proxy-allowlist: ADDR[/INT] | ADDR-ADDR ...
    dbus-event: none | running | zone-updated | external-verify | ksk-submission | dnssec-invalid ...
    dbus-init-delay: TIME
    listen: ADDR[%STR][@INT] | STR ...
    listen-quic: ADDR[%STR][@INT] ...
    listen-tls: ADDR[%STR][@INT] ...

توجه:

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

شناسه‌ی سرور که در پاسخ به پرسش برای رکورد TXT نام‌های id.server. یا hostname.bind. در کلاس CHAOS بازگردانده می‌شود (RFC 4892 https://datatracker.ietf.org/doc/html/rfc4892.html). برای غیرفعال‌سازی مقدار خالی تنظیم کنید.

پیش‌فرض: نام میزبان FQDN

نسخه‌ی نرم‌افزار سرور که در پاسخ به پرسش برای رکورد TXT نام‌های version.server. یا version.bind. در کلاس CHAOS بازگردانده می‌شود (RFC 4892 https://datatracker.ietf.org/doc/html/rfc4892.html). برای غیرفعال‌سازی مقدار خالی تنظیم کنید.

پیش‌فرض: نسخه‌ی سرور

یک شناسه‌ی سرور نام DNS (RFC 5001 https://datatracker.ietf.org/doc/html/rfc5001.html). برای غیرفعال‌سازی مقدار خالی تنظیم کنید.

پیش‌فرض: نام میزبان FQDN در لحظه‌ی شروع دیمن

مسیری برای ذخیره‌ی داده‌های زمان اجرا (پرونده‌ی PID، سوکت‌های یونیکس و غیره). یک مسیر غیرمطلق نسبت به دایرکتوری راه‌اندازی knotd <> سنجیده می‌شود.

بسته به نحوه‌ی استفاده از این پارامتر، اعمال تغییر آن ممکن است نیاز به راه‌اندازی مجدد سرور Knot داشته باشد.

پیش‌فرض: ${localstatedir}/run/knot (پیکربندی‌شده با --with-rundir=path)

کاربر سیستمی با گروه سیستمی اختیاری (user:group) که کارساز پس از شروع و اتصال به رابط‌ها، تحت آن اجرا می‌شود. قابلیت‌های لینوکس (Linux capabilities) در صورت پشتیبانی به کار گرفته می‌شوند.

اعمال تغییر در این پارامتر نیازمند راه‌اندازی مجدد کارساز Knot است.

پیش‌فرض: root:root

مکان پرونده PID.

اعمال تغییر در این پارامتر نیازمند راه‌اندازی مجدد کارساز Knot است.

پیش‌فرض: rundir/knot.pid

تعداد کارگران (نخ‌های) UDP برای پردازش پرس‌وجوهای ورودی روی UDP.

اعمال تغییر در این پارامتر نیازمند راه‌اندازی مجدد کارساز Knot است.

پیش‌فرض: برابر با تعداد پردازنده‌های آنلاین

تعداد کارگران (نخ‌های) TCP برای پردازش پرس‌وجوهای ورودی روی TCP.

اعمال تغییر در این پارامتر نیازمند راه‌اندازی مجدد کارساز Knot است.

پیش‌فرض: برابر با تعداد پردازنده‌های آنلاین، مقدار پیش‌فرض حداقل ۱۰ است

تعداد کارگران (نخ‌ها) برای اجرای عملیات‌های پس‌زمینه (بارگذاری زون، به‌روزرسانی‌های زون، و غیره).

اعمال تغییر در این پارامتر نیازمند راه‌اندازی مجدد کارساز Knot است.

پیش‌فرض: برابر با تعداد پردازنده‌های آنلاین، مقدار پیش‌فرض حداکثر ۱۰ است

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

پیش‌فرض: off

حداکثر زمان بیکاری (به ثانیه) میان درخواست‌ها در یک اتصال TCP ورودی. بدین معنا که در صورت عدم فعالیت در اتصال TCP ورودی در این مدت زمان، اتصال توسط کارساز بسته می‌شود.

حداقل: 1

پیش‌فرض: 10

حداکثر زمان (به میلی‌ثانیه) برای دریافت یا ارسال یک پیام DNS روی اتصال ورودی TCP. بدین معنا که این محدودیت بر پرس‌وجوها و پاسخ‌های عادی DNS، درخواست‌های DDNS ورودی، و انتقال‌های زون خروجی اعمال می‌شود. این مهلت زمانی از هنگامی که داده برای پردازش در دسترس است اندازه‌گیری می‌شود. برای بی‌نهایت، مقدار 0 قرار داده شود.

پیش‌فرض: 500 (میلی‌ثانیه)

توجه:

به منظور کاهش خطر حملات Slow Loris، توصیه می‌شود روی کارسازهای عمومی، این محدودیت تا حد امکان کم تنظیم شود.

حداکثر زمان (به میلی‌ثانیه) برای دریافت یا ارسال یک پیام DNS روی اتصال خروجی TCP/QUIC/TLS که قبلاً به یک کارساز دوردست پیکربندی‌شده برقرار شده است. بدین معنا که این محدودیت بر انتقال‌های زون ورودی، ارسال NOTIFY، هدایت DDNS، و بررسی یا ارسال DS اعمال می‌شود. این مهلت زمانی شامل زمان لازم برای رفت‌وبرگشت شبکه و پردازش پرس‌وجو توسط طرف دوردست است. برای بی‌نهایت، مقدار 0 قرار داده شود.

پیش‌فرض: 5000 (میلی‌ثانیه)

در صورت فعال بودن، هر کارگر TCP روی سوکت مجزای خود شنود می‌کند و توازن بار سوکت هسته سیستم‌عامل با استفاده از SO_REUSEPORT (یا SO_REUSEPORT_LB در FreeBSD) استفاده می‌شود. به دلیل عدم وجود یک سوکت مشترک، کارساز می‌تواند نرخ پردازش پاسخ بالاتری را روی TCP ارائه دهد. با این حال، در صورت وجود درخواست‌های زمان‌بر (مانند انتقال زون‌های یک دامنه سطح‌بالا - TLD)، فعال بودن reuseport ممکن است منجر به تاخیر یا عدم پاسخ‌دهی به درخواست‌های کلاینت شود. بنابراین استفاده از این گزینه روی کارسازهای ثانویه توصیه می‌شود.

نکته:

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

اعمال تغییر در این پارامتر نیازمند راه‌اندازی مجدد کارساز Knot است.

پیش‌فرض: off

در صورت فعال بودن، از TCP Fast Open برای ارتباطات خروجی TCP (سمت کلاینت) استفاده می‌کند: انتقال‌های زون ورودی، ارسال NOTIFY، و هدایت DDNS. این حالت دست‌تکانی TCP را ساده‌تر کرده و می‌تواند کارایی شبکه بهتری ایجاد کند. TCP Fast Open برای ارتباطات ورودی TCP (سمت کارساز) تحت تأثیر این تنظیم قرار نمی‌گیرد، چرا که در صورت پشتیبانی سیستم‌عامل، به‌طور خودکار فعال می‌شود.

نکته:

پشتیبانی TCP Fast Open باید در سطح سیستم‌عامل نیز فعال باشد:
  • لینوکس/macOS: مطمئن شوید پارامتر هسته net.ipv4.tcp_fastopen برای سمت کارساز برابر 2 یا 3، و برای سمت کلاینت برابر 1 یا 3 باشد.
  • در FreeBSD: مطمئن شوید پارامتر هسته net.inet.tcp.fastopen.server_enable برای سمت کارساز برابر 1، و net.inet.tcp.fastopen.client_enable برای سمت کلاینت برابر 1 باشد.

پیش‌فرض: off

حداکثر تعداد کلاینت‌های QUIC متصل به صورت هم‌گام.

همچنین ببینید quic.

اعمال تغییرات نیازمند راه‌اندازی مجدد سرور Knot.

حداقل: 128

پیش‌فرض: 10000 (ده هزار)

حداکثر حجم تجمعی حافظه مورد استفاده برای بافرهای پیام‌های ارسالی بدون تایید دریافت (unACKed). محدودیت به ازای هر UDP worker.

نکته:

امکان اشغال موقت حافظه بیشتر توسط بافرها تا زمان پاکسازی اتصالات جهت آزادسازی حافظه و اعمال محدودیت وجود دارد.

در صورت کمبود حافظه مقدار پایین تنظیم شود (همراه با quic-max-clients به دلیل مصرف بالای حافظه در اتصالات QUIC). در صورت پیش‌بینی انتقال زون‌های بزرگ به صورت خروجی روی QUIC مقدار بالا تنظیم شود.

اعمال تغییرات نیازمند راه‌اندازی مجدد سرور Knot.

حداقل: 1M (۱ مبی‌بایت)

پیش‌فرض: 100M (۱۰۰ مبی‌بایت)

مدت زمان به ثانیه؛ پس از آن هر اتصال بی‌کار QUIC به صورت استاندارد بسته می‌شود.

اعمال تغییرات نیازمند راه‌اندازی مجدد سرور Knot.

حداقل: 1

پیش‌فرض: 4

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

اعمال تغییرات نیازمند راه‌اندازی مجدد سرور Knot.

پیش‌فرض: 0

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

پیش‌فرض: 5

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

پیش‌فرض: 0

در صورت فعال بودن و در دسترس بودن SO_REUSEPORT در لینوکس، تمام سوکت‌های شبکه پیکربندی‌شده به UDP workerها و TCP workerها متصل می‌شوند تا کارایی شبکه افزایش یابد. این حالت برای سیستم‌هایی که تعداد صف‌های کارت شبکه در آن‌ها کمتر از تعداد workerهای UDP یا TCP است توصیه نمی‌شود.

اعمال تغییرات نیازمند راه‌اندازی مجدد سرور Knot.

پیش‌فرض: off

حداکثر تعداد کلاینت‌های TCP متصل به صورت هم‌گام. مقدار پایین‌تر از محدودیت توصیف‌گر فایل تنظیم شود تا از اتمام منابع جلوگیری گردد.

نکته:

تنظیم حداکثر تعداد پرونده‌های باز به ازای هر پردازش در پیکربندی سیستم‌عامل توصیه می‌شود.

پیش‌فرض: نیمی از محدودیت توصیف‌گر فایل برای پردازش سرور

حداکثر حجم پیش‌فرض payload پروتکل UDP در EDNS0 برای هر دو IPv4 و IPv6.

پیش‌فرض: 1232

حداکثر حجم payload پروتکل UDP در EDNS0 برای IPv4.

پیش‌فرض: 1232

حداکثر حجم payload پروتکل UDP در EDNS0 برای IPv6.

پیش‌فرض: 1232

مسیر پرونده PEM کلید سرور مورد استفاده در ارتباطات DNS بر بستر QUIC/TLS. مسیر غیرمطلق مشخص‌شده توسط کاربر نسبت به دایرکتوری /etc/knot سنجیده می‌شود.

پیش‌فرض: کلید تولیدشده خودکار

مسیر پرونده PEM گواهی سرور مورد استفاده در ارتباطات DNS بر بستر QUIC/TLS. مسیر غیرمطلق نسبت به دایرکتوری /etc/knot سنجیده می‌شود.

پیش‌فرض: گواهی یک‌باره در حافظه

یک یا چند مسیر را برای بارگذاری مرجع‌های گواهی (CA) معتبر مشخص می‌کند. رشته خالی ("") به معنی CAهای معتبر پیش‌فرض سیستم است. CAهای بارگذاری‌شده برای اعتبارسنجی گواهی ریموت (cert-hostname، cert-hostname و zone-db-cert-hostname) استفاده می‌شوند.

پیش‌فرض: تنظیم نشده

فعال یا غیرفعال کردن پشتیبانی از EDNS Client Subnet. در صورت فعال بودن، پاسخ‌ها به پرسش‌های حاوی گزینه EDNS Client Subnet، طبق RFC 7871 https://datatracker.ietf.org/doc/html/rfc7871.html همواره شامل یک گزینه معتبر EDNS Client Subnet خواهند بود.

پیش‌فرض: off

فعال یا غیرفعال کردن چرخش sorted-rrset در بخش پاسخ (answer) جواب‌های عادی. جابجایی چرخش صرفاً بر اساس شناسه پرسش (query ID) تعیین می‌شود.

پیش‌فرض: off

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

پیش‌فرض: off

فهرستی مرتب از نشانی‌های IP، زیرشبکه‌ها یا دامنه‌های شبکه که به عنوان نشانی مبدا برای ترافیک پراکسی‌شده DNS روی UDP مجاز هستند. پروتکل پراکسی پشتیبانی‌شده haproxy PROXY v2 https://www.haproxy.org/download/2.5/doc/proxy-protocol.txt است.

نکته:

پروتکل TCP پشتیبانی نمی‌شود.

پیش‌فرض: تنظیم نشده

مشخص کردن وضعیت‌های سرور یا زون که یک سیگنال D-Bus بر روی گذرگاه سیستم ارسال می‌کنند. نام گذرگاه cz.nic.knotd، مسیر شیء /cz/nic/knotd، و نام رابط cz.nic.knotd.events است.

مقادیر ممکن:

  • none – هیچ سیگنالی ارسال نمی‌شود.
  • running – ممکن است دو سیگنال ارسال شود:
  • started – هنگام شروع سرور و بارگذاری یا راه‌اندازی اولیه موفق همه زون‌های پیکربندی‌شده (شامل زون‌های کاتالوگ و اعضای آن‌ها) ارسال می‌شود.
  • stopped – هنگام آغاز فرآیند خاموش شدن سرور ارسال می‌شود.
•
zone-updated – ممکن است دو سیگنال ارسال شود:
  • zone_updated – هنگام به‌روزرسانی موفق یک زون ارسال می‌شود. پارامترها: نام zone و serial مربوط به SOA زون.
  • zone_not_updated – هنگامی که یک زون با موفقیت به‌روزرسانی نشده باشد ارسال می‌شود. پارامترها: نام zone.
  • external-verify – سیگنال external_verify هنگامی ارسال می‌شود که یک زون قبل از اعمال تغییرات در انتظار اعتبارسنجی خارجی باشد. پارامترها: نام zone و serial جدید SOA زون.
  • keys-updated – سیگنال keys_updated هنگام به‌روزرسانی مجموعه کلید DNSSEC ارسال می‌شود. پارامترها: نام zone.
  • ksk-submission – سیگنال zone_ksk_submission در صورتی ارسال می‌شود که هنگام امضای زون، یک KSK آماده وجود داشته باشد. پارامترها: نام zone، مقدار keytag کلید KSK، و id مربوط به KASP کلید KSK.
  • dnssec-invalid – سیگنال zone_dnssec_invalid هنگامی ارسال می‌شود که اعتبارسنجی DNSSEC با شکست مواجه شود یا راستی‌آزمایی ZONEMD ناموفق باشد. پارامترها: نام zone و seconds باقی‌مانده تا انقضای یک RRSIG.

نکته:

این قابلیت نیازمند systemd نسخه حداقل 221 یا libdbus است.

نکته کاربردی:

چندین نمونه الگوی اسکریپت در مخزن پروژه https://gitlab.nic.cz/knot/knot-dns/-/tree/master/samples موجود است.

اعمال تغییر در این پارامتر نیازمند راه‌اندازی مجدد سرور Knot است.

پیش‌فرض: none

مدت زمان به ثانیه که سرور پس از مقداردهی اولیه D-Bus منتظر می‌ماند تا اطمینان حاصل کند که کلاینت D-Bus برای دریافت سیگنال‌ها آماده است.

اعمال تغییر در این پارامتر نیازمند راه‌اندازی مجدد سرور Knot است.

حداقل: 0

پیش‌فرض: 1

یک یا چند نشانی IP که سرور برای پرسش‌های دریافتی روی آن‌ها گوش می‌دهد. می‌توان با استفاده از جداکننده @ یک درگاه اختیاری (پیش‌فرض 53 است) به هر نشانی اضافه کرد. از نشانی عام (wildcard) 0.0.0.0 برای همه نشانی‌های IPv4 پیکربندی‌شده یا :: برای همه نشانی‌های IPv6 پیکربندی‌شده استفاده کنید. در لینوکس، می‌توان پس از نشانی عام از % و یک نام رابط استفاده کرد تا اتصال نشانی عام به یک رابط خاص محدود شود. می‌توان یک مسیر در سیستم‌فایل را برای گوش دادن روی یک سوکت محلی UNIX SOCK_STREAM مشخص کرد. مسیر غیر مطلق (یعنی مسیری که با / شروع نمی‌شود) به صورت نسبی نسبت به rundir تفسیر می‌شود. اتصال به نشانی‌های غیر محلی در صورت پشتیبانی سیستم‌عامل به‌طور خودکار فعال می‌شود.

اعمال تغییر در این پارامتر نیازمند راه‌اندازی مجدد سرور Knot است.

نکته:

اتصال به نشانی‌های غیر محلی یا اتصال نشانی عام به یک رابط خاص ممکن است نیازمند تنظیم sysctl -w net.ipv4.ip_nonlocal_bind=1 و sysctl -w net.ipv6.ip_nonlocal_bind=1 باشد.

پیش‌فرض: تنظیم نشده

یک یا چند نشانی IP و اختیاری درگاه‌ها (پیش‌فرض 853) که کارساز روی آن‌ها به پرس‌وجوهای ورودی پروتکل QUIC گوش می‌دهد.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره کارساز Knot است.

پیش‌فرض: تنظیم نشده

یک یا چند نشانی IP و اختیاری درگاه‌ها (پیش‌فرض 853) که کارساز روی آن‌ها به پرس‌وجوهای ورودی پروتکل TLS (DoT) گوش می‌دهد.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره کارساز Knot است.

پیش‌فرض: تنظیم نشده

گزینه‌های گوناگون مربوط به شنود XDP، به‌ویژه TCP.

xdp:
    listen: STR[@INT] | ADDR[@INT] ...
    udp: BOOL
    tcp: BOOL
    quic: BOOL
    quic-port: INT
    tcp-max-clients: INT
    tcp-inbuf-max-size: SIZE
    tcp-outbuf-max-size: SIZE
    tcp-idle-close-timeout: TIME
    tcp-idle-reset-timeout: TIME
    tcp-resend-timeout: TIME
    route-check: BOOL
    zero-copy: BOOL
    ring-size: INT
    busypoll-budget: INT
    busypoll-timeout: INT

توجه:

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

یک یا چند نام دستگاه شبکه (مانند ens786f0) که حالت XDP روی آن‌ها فعال است <#mode-xdp>. می‌توان به جای نام دستگاه از نشانی IP نیز استفاده کرد، اما کارساز همچنان روی همه نشانی‌های متعلق به همان رابط گوش خواهد داد! مشخص کردن درگاه اختیاری (پیش‌فرض 53) با استفاده از جداکننده @ در انتهای هر نام دستگاه یا نشانی امکان‌پذیر است.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره کارساز Knot است.

توجه:

اگر کارگران XDP تنها ترافیک عادی DNS روی UDP را پردازش می‌کنند، اکیداً توصیه می‌شود روی نشانی‌هایی که برای ارائه سرویس DNS در نظر گرفته شده‌اند نیز گوش داده شود، دست‌کم برای برآورده ساختن الزامات DNS در جهت کارکرد TCP.

نکته:

ترافیک ورودی DDNS <#dynamic-updates> روی XDP پشتیبانی نمی‌شود. کارساز همواره با SERVFAIL پاسخ می‌دهد.

پیش‌فرض: تنظیم نشده

در صورت فعال بودن، DNS روی UDP توسط کارگران XDP پردازش می‌شود.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره کارساز Knot است.

پیش‌فرض: on

در صورت فعال بودن، ترافیک DNS روی TCP توسط کارگران XDP پردازش می‌شود.

محدودیت‌های پشته TCP:

  • کنترل ازدحام پیاده‌سازی نشده است.
  • بسته‌های گم‌شده‌ای که حاوی بار داده TCP نیستند ممکن است دوباره ارسال نشوند.
  • برای انتقال زون‌های غیرساده بهینه‌سازی نشده است.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره کارساز Knot است.

پیش‌فرض: off

در صورت فعال بودن، DNS روی QUIC توسط کارگران XDP پردازش می‌شود.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره کارساز Knot است.

پیش‌فرض: off

سرویس DNS روی QUIC روی رابط‌های پیکربندی‌شده توسط listen، اما روی درگاهی متفاوت که با این گزینه تعیین می‌شود، گوش خواهد داد.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره کارساز Knot است.

پیش‌فرض: 853

حداکثر تعداد کلاینت‌های TCP متصل به‌طور موازی.

حداقل: 1024

پیش‌فرض: 1000000 (یک میلیون)

حداکثر اندازه تجمعی حافظه برای بافرهای پیام‌های ناقص دریافت شده.

حداقل: 1M (۱ مبی‌بایت)

پیش‌فرض: 100M (۱۰۰ مبی‌بایت)

حداکثر اندازه تجمعی حافظه برای بافرهای پیام‌های ارسالی تایید‌نشده (unACKed).

حداقل: 1M (۱ مبی‌بایت)

پیش‌فرض: 100M (۱۰۰ مبی‌بایت)

زمان به ثانیه، که پس از آن هر اتصال بیکار به‌صورت ملایم بسته می‌شود.

حداقل: 1

پیش‌فرض: 10

زمان به ثانیه، که پس از آن هر اتصال بیکار به‌صورت اجباری بسته می‌شود.

حداقل: 1

پیش‌فرض: 20

ارسال مجدد بسته‌های داده خروجی (با بار پاسخ DNS) در صورت عدم تایید (ACK) قبل از این مهلت زمانی (به ثانیه).

حداقل: 1

پیش‌فرض: 5

در صورت فعال بودن، اطلاعات مسیریابی سیستم‌عامل هنگام پردازش هر بسته DNS ورودی دریافتی روی رابط XDP در نظر گرفته می‌شود:

  • اگر رابط خروجی پاسخ DNS مربوطه با رابط ورودی متفاوت باشد، بسته به طور عادی توسط ورکر‌های UDP/TCP پردازش می‌شود (از XDP استفاده نمی‌شود).
  • اگر نشانی مقصد سیاه‌چاله (blackhole)، غیرقابل دسترس یا ممنوع باشد، بسته DNS بدون پاسخ دور ریخته می‌شود.
  • آدرس MAC مقصد و تگ احتمالی VLAN برای پاسخ از سیستم مسیریابی گرفته می‌شود.

در صورت غیرفعال بودن، مسیریابی متقارن اعمال می‌شود. به این معنی که آدرس MAC منبع پرس‌وجو به عنوان آدرس MAC مقصد پاسخ استفاده می‌شود. تگ احتمالی VLAN حفظ می‌شود.

تغییر این پارامتر برای اعمال نیاز به راه‌اندازی مجدد سرور Knot دارد.

نکته:

این حالت نیازمند فعال بودن فورواردینگ روی رابط loopback است (sysctl -w net.ipv4.conf.lo.forwarding=1 و sysctl -w net.ipv6.conf.lo.forwarding=1). اگر فورواردینگ غیرفعال باشد، تمام بسته‌های DNS ورودی دور ریخته می‌شوند!

فقط VLAN 802.1Q پشتیبانی می‌شود.

پیش‌فرض: off

در صورت فعال بودن و پشتیبانی دستگاه شبکه پیکربندی‌شده، حالت zero-copy قابل استفاده است. برای مقاصد آزمایشی یا در صورت بروز مشکل در هسته یا درایور دستگاه، غیرفعال کردن zero-copy ممکن است به بهای کارایی پایین‌تر کمک کند.

تغییر این پارامتر برای اعمال نیاز به راه‌اندازی مجدد سرور Knot دارد.

پیش‌فرض: on

اندازه حلقه‌های RX، FQ، TX و CQ.

تغییر این پارامتر برای اعمال نیاز به راه‌اندازی مجدد سرور Knot دارد.

نکته:

این مقدار باید حداقل به اندازه RX پیکربندی‌شده دستگاه شبکه در حالت XDP باشد.

پیش‌فرض: 2048

در صورت تنظیم روی مقدار مثبت، preferred busy polling با بودجه مشخص‌شده فعال می‌شود.

تغییر این پارامتر برای اعمال نیاز به راه‌اندازی مجدد سرور Knot دارد.

نکته:

قابلیت Preferred busy polling همچنین به تنظیم napi_defer_hard_irqs و gro_flush_timeout برای رابط شبکه مربوطه نیاز دارد. به عنوان مثال: 
echo 2 | sudo tee /sys/class/net/<interface>/napi_defer_hard_irqs
echo 200000 | sudo tee /sys/class/net/<interface>/gro_flush_timeout

نکته:

مقدار توصیه‌شده بین ۸ تا ۶۴ است.

پیش‌فرض: 0 (غیرفعال)

زمان انتظار بر حسب میکروثانیه برای busy polling در صورت فعال بودن با busypoll-budget.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره سرور Knot است.

پیش‌فرض: 20 (۲۰ میکروثانیه)

پیکربندی رابط کنترلی سرور.

control:
    listen: STR ...
    backlog: INT
    timeout: TIME

مسیر سوکت UNIX که سرور برای دستورهای کنترلی روی آن شنود می‌کند.

امکان پیکربندی چندین سوکت برای استفاده مستقل و موازی وجود دارد، اما تعداد آنها محدود است (در حال حاضر ۴ عدد)، و برخی عملیات ممکن است به دلیل mutexها با تاخیر مواجه شوند.

هشدار:

عملیات شبه‌تراکنشی، مانند conf-begin/set/commit/abort یا zone-begin/set/commit/abort، باید از طریق همان سوکت انجام شوند.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره سرور Knot است.

پیش‌فرض: rundir/knot.sock

اندازه backlog شنود سوکت کنترلی UNIX.

اعمال تغییر این پارامتر نیازمند راه‌اندازی دوباره سرور Knot است.

پیش‌فرض: 5

حداکثر زمان (بر حسب ثانیه) مجاز برای انجام عملیات سوکت کنترل. مقدار 0 به معنای نامحدود است.

پیش‌فرض: 5

سرور را می‌توان برای ثبت وقایع در خروجی استاندارد، خروجی خطای استاندارد، syslog (یا systemd journal در صورت فعال بودن systemd) یا در یک فایل دلخواه پیکربندی کرد.

شش سطح اهمیت وقایع وجود دارد:

  • critical – خطای غیرقابل‌برگشت که منجر به خاموش شدن سرور می‌شود.
  • error – خطای قابل‌برگشت، اقدام لازم است.
  • warning – هشداری که ممکن است نیازمند اقدام کاربر باشد.
  • notice – اعلان یا راهنمایی از سوی سرور.
  • info – پیام اطلاعاتی.
  • debug – پیام خطایابی یا تفصیلی.

در صورت نبود بخش log، پیام‌های warning یا خطاهای جدی‌تر در هر دو خروجی خطای استاندارد و syslog ثبت می‌شوند. پیام‌های info و notice در خروجی استاندارد ثبت خواهند شد.

log:
  - target: stdout | stderr | syslog | STR
    server: critical | error | warning | notice | info | debug
    control: critical | error | warning | notice | info | debug
    zone: critical | error | warning | notice | info | debug
    quic: critical | error | warning | notice | info | debug
    any: critical | error | warning | notice | info | debug

خروجی ثبت وقایع.

مقدارهای ممکن:

  • stdout – خروجی استاندارد.
  • stderr – خروجی خطای استاندارد.
  • syslog – گزارش‌گیر Syslog یا systemd journal.
  • file_name – یک پرونده مشخص.

با مقصد syslog، از سرویس syslog استفاده می‌شود. هرچند اگر Knot DNS با پشتیبانی systemd کامپایل شده و سیستم‌عامل با systemd راه‌اندازی شده باشد، به جای syslog از systemd journal استفاده خواهد شد.

یک file_name می‌تواند به صورت مسیر مطلق یا مسیری نسبت به دایرکتوری شروع knotd <> مشخص شود.

حداقل سطح اهمیت برای ثبت پیام‌های مربوط به عملکرد کلی سرور.

پیش‌فرض: تنظیم نشده (not set)

حداقل سطح اهمیت برای ثبت گزارش پیام‌های مرتبط با کنترل سرور.

پیش‌فرض: تنظیم‌نشده

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

پیش‌فرض: تنظیم‌نشده

حداقل سطح اهمیت برای ثبت گزارش پیام‌های مرتبط با QUIC.

پیش‌فرض: تنظیم‌نشده

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

پیش‌فرض: تنظیم‌نشده

تخلیه دوره‌ای آمار سرور.

statistics:
    timer: TIME
    file: STR
    append: BOOL

دوره‌ای زمانی (به ثانیه) که پس از آن تمام معیارهای آماری موجود در پرونده نوشته می‌شوند.

پیش‌فرض: تنظیم‌نشده

مسیر پرونده خروجی آمار در قالب YAML.

پیش‌فرض: rundir/stats.yaml

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

پیش‌فرض: off

پیکربندی پایگاه‌های داده برای محتوای زون، متاداده‌های DNSSEC یا زمان‌سنج رویدادها.

database:
    storage: STR
    journal-db: STR
    journal-db-mode: robust | asynchronous
    journal-db-max-size: SIZE
    kasp-db: STR
    kasp-db-max-size: SIZE
    timer-db: STR
    timer-db-max-size: SIZE
    timer-db-sync: never | shutdown | immediate | TIME
    catalog-db: str
    catalog-db-max-size: SIZE
    zone-db-listen: ADDR[@INT] | STR[@INT] ...
    zone-db-tls: BOOL
    zone-db-cert-key: BASE64 ...
    zone-db-cert-hostname: STR ...

پوشه داده برای ذخیره‌سازی پایگاه‌های داده ژورنال، KASP و زمان‌سنج. مسیر غیرمطلق نسبت به پوشه راه‌اندازی knotd <> در نظر گرفته می‌شود.

پیش‌فرض: ${localstatedir}/lib/knot (پیکربندی‌شده با --with-storage=path)

تعیین صریح پوشه پایگاه داده ژورنال ماندگار.

پیش‌فرض: storage/journal

پیکربندی بک‌اند LMDB ژورنال را مشخص می‌کند که بر کارایی و ماندگاری تأثیر می‌گذارد.

مقادیر ممکن:

  • robust – همگام‌سازی دیسک پایگاه داده ژورنال ماندگاری داده را تضمین می‌کند، اما عموماً کندتر است.
  • asynchronous – همگام‌سازی دیسک پایگاه داده ژورنال برای کارایی بهتر بهینه شده است، به قیمت ماندگاری کمتر پایگاه داده در صورت بروز کرش. این حالت برای سرورهای ثانویه با تعداد زون بالا توصیه می‌شود.

پیش‌فرض: robust

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

توصیه می‌شود در بیشتر موارد به‌جای journal-db-max-size، مقدار journal-max-usage به ازای هر زون محدود شود. لطفاً این مقدار را بزرگتر از مجموع محدودیت‌های مصرف ژورنال تمام زون‌ها نگه دارید. جزئیات بیشتر درباره رفتار ژورنال را در <#journal-behaviour> ببینید.

نکته:

این مقدار بر مصرف حافظه مجازی سرور نیز تأثیر می‌گذارد.

پیش‌فرض: 20G (20 گیبی‌بایت)، یا 512M (512 مبی‌بایت) برای سیستم‌های ۳۲ بیتی

مشخص‌سازی صریح دایرکتوری پایگاه دادهٔ KASP.

پیش‌فرض: storage/keys

حد سخت‌گیرانه (Hard limit) برای حداکثر حجم پایگاه دادهٔ KASP.

نکته:

این مقدار همچنین بر میزان استفادهٔ سرور از حافظهٔ مجازی تأثیر می‌گذارد.

پیش‌فرض: 10G (۱۰ گیبی‌بایت)، یا 512M (۵۱۲ میبی‌بایت) برای سیستم‌های ۳۲ بیتی

مشخص‌سازی صریح دایرکتوری پایگاه دادهٔ ماندگار تایمرها (persistent timer).

پیش‌فرض: storage/timers

حد سخت‌گیرانه برای حداکثر حجم پایگاه دادهٔ تایمرها.

نکته:

این مقدار همچنین بر میزان استفادهٔ سرور از حافظهٔ مجازی تأثیر می‌گذارد.

پیش‌فرض: 5G (۵ گیبی‌بایت)، یا 512M (۵۱۲ میبی‌بایت) برای سیستم‌های ۳۲ بیتی

مشخص می‌کند که تایمرهای زون چه زمانی باید در پایگاه دادهٔ ماندگار تایمرها نوشته شوند.

مقادیر ممکن:

  • never – هرگز نوشته نمی‌شوند.
  • shutdown – تنها یک‌بار هنگام خاموش شدن سرور نوشته می‌شوند.
  • immediate – هر زون تایمرهای خود را بلافاصله پس از تغییر می‌نویسد. در صورت پیکربندی زون‌های متعدد، این حالت ممکن است رویدادهای زون‌ها را کند کند.
  • INT – یک رشتهٔ اختصاصی به‌طور پیوسته بین زون‌های پیکربندی‌شده پیمایش می‌کند و تایمرهای آن‌ها را در بازهٔ زمانی غیرصفر مشخص‌شده (به ثانیه) می‌نویسد.

پیش‌فرض: shutdown

مشخص‌سازی صریح دایرکتوری پایگاه دادهٔ کاتالوگ زون. فقط در صورت فعال بودن Catalog zones <#catalog-zones> مفید است.

پیش‌فرض: storage/catalog

حد سخت‌گیرانه برای حداکثر حجم پایگاه دادهٔ کاتالوگ.

نکته:

این مقدار همچنین بر میزان استفادهٔ سرور از حافظهٔ مجازی تأثیر می‌گذارد.

پیش‌فرض: 20G (۲۰ گیبی‌بایت)، یا 512M (۵۱۲ میبی‌بایت) برای سیستم‌های ۳۲ بیتی

فهرستی مرتب‌شده از آدرس‌های IP یا نام‌های میزبان (و اختیاری درگاه‌ها، پیش‌فرض 6379)، یا مسیرهای مطلق سوکت‌های یونیکس (که با / شروع می‌شوند) برای نمونه‌های در حال اجرای Redis (یا سازگار با آن) که جهت خواندن و/یا نوشتن محتوای زون استفاده می‌شوند. به zone-db-input و zone-db-output رجوع کنید.

پارامترهای شنود به ترتیب آزمایش می‌شوند تا یک اتصال قابل استفاده برقرار شود. پایگاه دادهٔ متصل می‌تواند master،‏ replica یا sentinel باشد. در صورت sentinel بودن، برای به‌دست آوردن پارامترهای اتصالِ پایگاه دادهٔ master استفاده می‌شود.

پیش‌فرض: تنظیم نشده

در صورت فعال بودن، از TLS 1.3 برای ارتباط با پایگاه دادهٔ زون استفاده خواهد شد.

پیش‌فرض: off

فهرستی مرتب‌شده از حداکثر ۴ پین (PIN) کلید عمومی گواهیِ پایگاه دادهٔ زون. اگر این فهرست خالی نباشد، ارتباط با پایگاه دادهٔ زون فقط از طریق TLS امکان‌پذیر است و به گواهی طرف مقابل (peer) نیاز خواهد بود. کلید عمومی گواهی طرف مقابل باید با یکی از پین‌های مشخص‌شده مطابقت داشته باشد.

پیش‌فرض: تنظیم نشده

فهرستی مرتب‌شده از حداکثر ۴ نام میزبان برای تطبیق با گواهیِ پایگاه دادهٔ زون. حداقل یک نام میزبان باید مطابقت داشته باشد تا گواهی معتبر شناخته شود (به ca-file مراجعه کنید). اگر فهرست خالی نباشد، ارتباط با پایگاه دادهٔ زون فقط از طریق TLS امکان‌پذیر خواهد بود و گواهی طرف مقابل الزامی است.

پیش‌فرض: تنظیم نشده

پیکربندی ذخیره‌گاه کلید DNSSEC.

keystore:
  - id: STR
    backend: pem | pkcs11
    config: STR
    ksk-only: BOOL
    key-label: BOOL

شناسهٔ keystore.

نوع بک‌اند ذخیره‌سازی کلید.

مقادیر ممکن:

  • pem – پرونده‌های PEM.
  • pkcs11 – ذخیره‌گاه PKCS #11.

پیش‌فرض: pem

پیکربندی مخصوص بک‌اند. پوشه‌ای شامل پرونده‌های PEM (مسیر می‌تواند به صورت نسبی نسبت به kasp-db مشخص شود) یا یک رشتهٔ پیکربندی برای ذخیره‌گاه PKCS #11 (<pkcs11-uri> <module-path>). طرح PKCS #11 URI در RFC 7512 https://datatracker.ietf.org/doc/html/rfc7512.html تعریف شده است.

نکته:

نمونه رشتهٔ پیکربندی برای PKCS #11: 
"pkcs11:token=knot;pin-value=1234 /usr/lib64/pkcs11/libsofthsm2.so"

پیش‌فرض: kasp-db/keys

کلیدهای جدید تولیدشده تنها در صورتی در این keystore ذخیره می‌شوند که KSK یا CSK باشند. کلیدهای امضای زون در keystore بعدی که این گزینه در آن فعال نیست ذخیره خواهند شد.

پیش‌فرض: off

اگر در ترکیب با بک‌اند PKCS #11 فعال باشد، کلیدهای تولیدشده به شکل <zone_name> KSK|ZSK برچسب‌گذاری می‌شوند.

پیش‌فرض: off

کلیدهای اشتراکی TSIG برای احراز هویت ارتباط با سرور.

key:
  - id: DNAME
    algorithm: hmac-md5 | hmac-sha1 | hmac-sha224 | hmac-sha256 | hmac-sha384 | hmac-sha512
    secret: BASE64

شناسهٔ نام کلید.

نکته:

این مقدار باید دقیقاً یکسان با نام کلید TSIG در سرور(های) طرف مقابل primary/secondary باشد.

الگوریتم کلید TSIG. بخش TSIG Algorithm Numbers https://www.iana.org/assignments/tsig-algorithm-names/tsig-algorithm-names.xhtml را ببینید.

مقادیر ممکن:

  • hmac-md5
  • hmac-sha1
  • hmac-sha224
  • hmac-sha256
  • hmac-sha384
  • hmac-sha512

پیش‌فرض: hmac-sha256

رمز اشتراکی کلید.

پیش‌فرض: تنظیم‌نشده

تعاریف سرورهای راه دور برای اتصال‌های خروجی (مبدأ انتقال زون، مقصد اعلان و غیره).

remote:
  - id: STR
    address: ADDR[@INT] | STR ...
    via: ADDR[@INT] ...
    quic: BOOL
    tls: BOOL
    key: key_id
    cert-key: BASE64 ...
    cert-hostname: STR ...
    block-notify-after-transfer: BOOL
    no-edns: BOOL
    automatic-acl: BOOL

یک شناسه ریموت.

فهرست مرتب‌شده‌ای از نشانی‌های IP مقصد یا مسیرهای سوکت UNIX که برای ارتباط با سرور ریموت استفاده می‌شوند. مسیر غیرمطلق (یعنی مسیری که با / آغاز نمی‌شود) نسبت به rundir سنجیده می‌شود. درگاه مقصد اختیاری (پیش‌فرض ۵۳ برای UDP/TCP و ۸۵۳ برای QUIC) می‌تواند با استفاده از جداکننده @ به نشانی افزوده شود. نشانی‌ها به ترتیب آزمایش می‌شوند تا ارتباط با ریموت برقرار شود.

پیش‌فرض: تنظیم نشده

نکته:

اگر با ریموت تماس برقرار شود و از انجام عمل درخواستی خودداری کند، هیچ نشانی دیگری برای این ریموت آزمایش نخواهد شد.

فهرست مرتب‌شده‌ای از نشانی‌های IP مبدأ که به عنوان نشانی‌های مبدأ برای ارتباط با ریموت استفاده می‌شوند. برای N-امین نشانی ریموت، آخرین نشانی، اما حداکثر N-امین نشانی مشخص‌شده via از همان خانواده استفاده می‌شود. این گزینه در صورتی که سرور روی چندین نشانی گوش دهد مفید است. درگاه مبدأ اختیاری (پیش‌فرض تصادفی است) می‌تواند با استفاده از جداکننده @ به نشانی افزوده شود.

پیش‌فرض: تنظیم نشده

نکته:

برای پیکربندی زیر: 
remote:
  - id: example
    address: [198.51.100.10, 2001:db8::10, 198.51.100.20, 2001:db8::20]
    via: [198.51.100.1, 198.51.100.2, 2001:db8::1]

نگاشت (via -> address) به این صورت است:

  • 198.51.100.1 -> 198.51.100.10
  • 2001:db8::1 -> 2001:db8::10
  • 198.51.100.2 -> 198.51.100.20
  • 2001:db8::1 -> 2001:db8::20

اگر این گزینه تنظیم شود، از پروتکل QUIC برای ارتباطات خروجی با این ریموت استفاده خواهد شد.

نکته:

برای هر ریموت یک اتصال باز می‌شود؛ remote-pool-limit برای QUIC اعمال نمی‌شود. با این حال، دست‌تکانی‌های سریع QUIC با بهره‌گیری از بلیت‌های نشست به‌دست‌آمده برای برقراری مجدد اتصالات به ریموت‌هایی که اخیراً (تا ۱ روز قبل) استعلام شده‌اند استفاده می‌شوند.

پیش‌فرض: off

اگر این گزینه تنظیم شود، از پروتکل TLS (DoT) برای ارتباطات خروجی با این ریموت استفاده خواهد شد.

پیش‌فرض: off

ارجاع به کلید TSIG که برای احراز هویت ارتباط با سرور ریموت استفاده می‌شود.

پیش‌فرض: تنظیم نشده

فهرست مرتب‌شده‌ای از حداکثر ۴ پین کلید عمومی گواهی ریموت. اگر فهرست خالی نباشد، ارتباط با ریموت تنها از طریق پروتکل‌های QUIC یا TLS امکان‌پذیر است و گواهی همتا الزامی خواهد بود. کلید گواهی همتا باید با یکی از پین‌های مشخص‌شده مطابقت داشته باشد.

یک پین شناسه یکتایی است که نمایانگر کلید عمومی گواهی همتا است. این شناسه یک درهم‌سازی SHA-256 با کدگذاری base64 از کلید عمومی است. این شناسه معمولاً هنگام تمدید گواهی یکسان باقی می‌ماند.

پیش‌فرض: تنظیم نشده

فهرست مرتب‌شده‌ای از حداکثر ۴ نام میزبان جهت مطابقت با گواهی همتا. برای اعتبارسنجی موفق گواهی، حداقل یکی باید مطابقت داشته باشد (به ca-file مراجعه کنید). اگر فهرست خالی نباشد، ارتباط با ریموت تنها از طریق پروتکل‌های QUIC یا TLS امکان‌پذیر است و گواهی همتا الزامی خواهد بود.

پیش‌فرض: تنظیم نشده

هنگام دریافت AXFR/IXFR ورودی از این ریموت (به عنوان یک سرور اصلی)، از ارسال پیام‌های NOTIFY به تمام سرورهای ثانویه پیکربندی‌شده جلوگیری می‌کند.

پیش‌فرض: off

اگر فعال باشد، هیچ رکورد OPT (EDNS) به درخواست‌های خروجی به این سرور ریموت اضافه نمی‌شود. این حالت برای ارتباط با برخی پیاده‌سازی‌های معیوب DNS (مانند Windows Server 2016) ضروری است.

علاوه بر این، اگر از TCP برای نوسازی زون استفاده شود، استعلام SOA و استعلام AXFR/IXFR متعاقب آن از اتصال TCP مشترک استفاده نمی‌کنند. این حالت امکان انتقال از برخی پیاده‌سازی‌های معیوب DNS (مانند ixfrdist) را فراهم می‌کند.

نکته:

این گزینه عملاً به‌روزرسانی‌های تایمر انقضای زون <#zone-expiration> را از طریق گزینه EDNS EXPIRE مشخص‌شده در RFC 7314 https://datatracker.ietf.org/doc/html/rfc7314.html غیرفعال می‌کند.

پیش‌فرض: off

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

  • درخواست NOTIFY ورودی از ریموت مجاز است اگر سرور اصلی زون باشد.
  • انتقال زون خروجی به ریموت مجاز است اگر مقصد NOTIFY برای زون باشد.

قوانین automatic ACL قبل از پیکربندی صریح ACL زون ارزیابی می‌شوند.

نکته:

نیازمند فعال‌سازی سراسری از طریق automatic-acl در بخش سرور است.

پیش‌فرض: on

تعریف گروه‌های سرورهای ریموت. گروه‌بندی ریموت‌ها پیکربندی را ساده می‌کند.

remotes:
  - id: STR
    remote: remote_id ...

شناسه گروه ریموت.

فهرست مرتب از ارجاعات به تعاریف سرورهای ریموت.

پیش‌فرض: تنظیم نشده

تعریف قوانین فهرست کنترل دسترسی (ACL). قانون ACL شرح یک یا چند اقدام مجاز (درخواست انتقال زون، اعلان تغییر زون، و به‌روزرسانی پویای DNS) است که پردازش یا رد می‌شوند. پرس‌وجوهای بدون نیاز به احراز هویت همیشه مجازند.

acl:
  - id: STR
    address: ADDR[/INT] | ADDR-ADDR | STR ...
    key: key_id ...
    cert-key: BASE64 ...
    cert-hostname: STR ...
    remote: remote_id | remotes_id ...
    action: query | notify | transfer | update ...
    protocol: udp | tcp | tls | quic ...
    deny: BOOL
    update-type: STR ...
    update-owner: key | zone | name
    update-owner-match: sub-or-equal | equal | sub | pattern
    update-owner-name: STR ...

شناسه قانون ACL.

فهرست مرتب از آدرس‌های IP، مسیرهای مطلق سوکت UNIX، زیرشبکه‌ها، یا محدوده‌های شبکه. آدرس مبدأ پرس‌وجو باید با یکی از آن‌ها مطابقت داشته باشد. اگر تنظیم نشود، تطابق آدرس الزامی نیست.

پیش‌فرض: تنظیم نشده

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

پیش‌فرض: تنظیم نشده

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

شناسه PIN نماینده کلید عمومی گواهی همتا است. هش SHA-256 با کدگذاری Base64 از کلید عمومی است. هنگام تمدید گواهی معمولاً ثابت می‌ماند.

پیش‌فرض: تنظیم نشده

فهرست مرتب از نام‌های میزبان جهت تطابق با گواهی همتا. حداقل یک مورد برای اعتبارسنجی موفق گواهی باید مطابقت داشته باشد (رجوع به ca-file). اگر فهرست خالی نباشد، ارتباط با ریموت فقط از طریق پروتکل‌های QUIC یا TLS ممکن است و ارائه گواهی همتا الزامی است.

پیش‌فرض: تنظیم نشده

فهرست مرتب از ارجاعات به remote و remotes. پرس‌وجو باید با یکی از ریموت‌ها مطابقت داشته باشد؛ مشخصاً، یکی از آدرس‌های ریموت و در صورت وجود، کلید TSIG آن.

نکته:

این گزینه همزمان با گزینه‌های address، key، یا protocol در یک آیتم ACL قابل تعیین نیست.

پیش‌فرض: تنظیم نشده

فهرستی مرتب از عملیات‌های مجاز یا غیرمجاز (انواع درخواست).

مقدارهای ممکن:

  • query – مجاز دانستن پرس‌وجوی معمولی DNS. چون پرس‌وجوهای عادی همیشه مجاز هستند، این اقدام تنها در ترکیب با کلید TSIG کاربرد دارد.
  • notify – مجاز دانستن اعلان ورودی (NOTIFY).
  • transfer – مجاز دانستن انتقال زون (AXFR، IXFR).
  • update – مجاز دانستن به‌روزرسانی‌های زون (DDNS).

پیش‌فرض: query

فهرست پروتکل‌های مجاز.

مقدارهای ممکن:

  • udp – پروتکل UDP.
  • tcp – پروتکل TCP.
  • tls – پروتکل TLS.
  • quic – پروتکل QUIC.

پیش‌فرض: تنظیم‌نشده (هرکدام)

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

پیش‌فرض: off

فهرستی از انواع مجاز رکوردهای منبع (RR) در به‌روزرسانی زون. هر رکورد در به‌روزرسانی باید با یکی از انواع مشخص‌شده مطابقت داشته باشد.

پیش‌فرض: تنظیم‌نشده

این گزینه مالکان مجاز رکوردهای منبع را در به‌روزرسانی زون، از طریق مقایسه آن‌ها با شناسه کلید TSIG، نام زون فعلی، یا فهرستی از نام‌های دامنه ارائه‌شده توسط گزینه update-owner-name محدود می‌کند. روش مقایسه توسط گزینه update-owner-match تعیین می‌شود.

مقدارهای ممکن:

  • key — مالک هر RR به‌روزرسانی‌شده باید با شناسه کلید TSIG (در صورت استفاده) مطابقت داشته باشد.
  • name — مالک هر RR به‌روزرسانی‌شده باید با حداقل یک نام در فهرست update-owner-name مطابقت داشته باشد.
  • zone — مالک هر RR به‌روزرسانی‌شده باید با نام زون فعلی مطابقت داشته باشد.

پیش‌فرض: تنظیم‌نشده

این گزینه نحوه تطبیق مالکان رکوردهای منبع در به‌روزرسانی را با نام یا نام‌های دامنه تنظیم‌شده توسط گزینه update-owner مشخص می‌کند.

مقدارهای ممکن:

  • sub-or-equal — مالک هر RR در به‌روزرسانی باید برابر با حداقل یک نام دامنه تعیین‌شده توسط update-owner یا زیردامنه‌ای از آن باشد.
  • equal — مالک هر RR به‌روزرسانی‌شده باید برابر با حداقل یک نام دامنه تعیین‌شده توسط update-owner باشد.
  • sub — مالک هر RR به‌روزرسانی‌شده باید زیردامنه‌ای از حداقل یک نام دامنه تعیین‌شده توسط update-owner باشد، اما نباید با آن برابر باشد.
  • pattern — مالک هر RR به‌روزرسانی‌شده باید با الگوی مشخص‌شده توسط update-owner مطابقت داشته باشد. الگو می‌تواند یک نام دامنه FQDN یا غیر FQDN دلخواه باشد. اگر یک برچسب (label) شامل نویسه * (ستاره) باشد، با هر برچسبی مطابقت پیدا می‌کند. امکان تعیین چندین برچسب ستاره وجود دارد.

پیش‌فرض: sub-or-equal

فهرستی از مالکان مجاز RRها در به‌روزرسانی زون، هنگام استفاده از update-owner با مقدار name. هر نام مالک در فهرست که FQDN نباشد (یعنی به نقطه ختم نشود)، به‌گونه‌ای در نظر گرفته می‌شود که نام زون مقصد به انتهای آن اضافه شده است. این شیوه تعیین نام مالک نسبی، امکان استفاده مجدد بهتر از قوانین ACL را در چندین زون فراهم می‌کند.

پیش‌فرض: تنظیم‌نشده

پارامترهای بررسی‌های ارائه‌ی KSK.

submission:
  - id: STR
    parent: remote_id | remotes_id ...
    check-interval: TIME
    timeout: TIME
    parent-delay: TIME

یک شناسه ارائه‌دهنده (submission).

فهرستی از ارجاعات remote و remotes به کارگزارهای DNS والد جهت بررسی وجود رکوردهای DS متناظر، هنگام ارائه KSK. همه آن‌ها باید DS متناظر را داشته باشند تا جابه‌جایی کلید (rollover) ادامه یابد. اگر مقداری مشخص نشود، جابه‌جایی باید به صورت دستی پیش برده شود.

پیش‌فرض: تنظیم‌نشده

نکته:

یک resolver دارای اعتبارسنجی DNSSEC می‌تواند به عنوان parent تعیین شود.

بازه زمانی (به ثانیه) جهت بررسی دوره‌ای وجود رکورد DS روی کارسازهای DNS بالادست (parent)، هنگام ارسال KSK.

پیش‌فرض: 1h (یک ساعت)

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

پیش‌فرض: 0

پس از بررسی موفق رکورد DS بالادست، پیش از آغاز مرحله بعدی تعویض کلید (roll-over)، به این میزان (به ثانیه) درنگ می‌شود. این تاخیر باید زمان انتشار به‌روزرسانی در زون بالادست را پوشش دهد.

نکته:

این تاخیر فقط بر ارسال خودکار KSK همراه با پرس‌وجوهای بالادست اثر می‌گذارد. برای ارسال KSK که منتهی به timeout شده یا با دستور knotc zone-ksk-submitted دستی تایید شده باشد اعمال نمی‌گردد.

پیش‌فرض: 0

پارامترهای همگام‌سازی DNSKEY از طریق dynamic-update.

dnskey-sync:
  - id: STR
    remote: remote_id | remotes_id ...
    check-interval: TIME

شناسه dnskey-sync.

فهرستی از ارجاعات remote و remotes به سایر امضاکنندگان یا سرور master مشترک، که به‌روزرسانی‌های DDNS شامل رکوردهای DNSKEY/CDNSKEY/CDS باید به آن‌ها ارسال شوند.

پیش‌فرض: تنظیم نشده

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

پیش‌فرض: 60 (یک دقیقه)

پیکربندی خط‌مشی DNSSEC.

policy:
  - id: STR
    keystore: keystore_id ...
    manual: BOOL
    single-type-signing: BOOL
    algorithm: rsasha1 | rsasha1-nsec3-sha1 | rsasha256 | rsasha512 | ecdsap256sha256 | ecdsap384sha384 | ed25519 | ed448
    ksk-size: SIZE
    zsk-size: SIZE
    ksk-shared: BOOL
    dnskey-ttl: TIME
    zone-max-ttl: TIME
    keytag-modulo: INT/INT
    ksk-lifetime: TIME
    zsk-lifetime: TIME
    delete-delay: TIME
    propagation-delay: TIME
    rrsig-lifetime: TIME
    rrsig-refresh: TIME
    rrsig-pre-refresh: TIME
    reproducible-signing: BOOL
    nsec3: BOOL
    nsec3-iterations: INT
    nsec3-opt-out: BOOL
    nsec3-salt-length: INT
    nsec3-salt-lifetime: TIME
    signing-threads: INT
    ksk-submission: submission_id
    ds-push: remote_id | remotes_id ...
    cds-cdnskey-publish: none | delete-dnssec | rollover | always | double-ds
    cds-digest-type: sha256 | sha384
    dnskey-management: full | incremental
    offline-ksk: BOOL
    unsafe-operation: none | no-check-keyset | no-update-dnskey | no-update-nsec | no-update-expired ...

شناسه خط‌مشی.

ارجاع به یک keystore حاوی داده‌های کلید خصوصی زون‌ها.

در صورت تعیین چند keystore، کلیدهای خصوصی جهت امضا در همه آن‌ها جستجو می‌شوند. کلیدهای تازه‌تولیدشده در نخستین مورد (یا نخستین مورد فاقد گزینه فعال ksk-only در صورت تولید ZSK جدید) به ترتیب مشخص‌شده ذخیره می‌گردند.

نکته:

اگر چند keystore پیکربندی شده باشد و زون با استفاده از ویژگی پشتیبان‌گیری <#data-and-metadata-backup> بازیابی شود، کلیه کلیدهای خصوصی بازیابی‌شده در نخستین keystore ارجاع‌داده‌شده ذخیره می‌شوند.

نکته:

یک keystore پیکربندی‌شده با نام "default" تا زمانی که صریحاً ارجاع داده نشود استفاده نخواهد شد.

پیش‌فرض: یک keystore فرضی با مقادیر کاملاً پیش‌فرض

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

پیش‌فرض: off

در صورت فعال بودن، از طرح امضای تک‌نوعی (Single-Type Signing Scheme) در حالت مدیریت خودکار کلید استفاده می‌شود.

پیش‌فرض: off (پیش‌فرض ماژول onlinesign <#mod-onlinesign> برابر با on است)

الگوریتم کلیدهای امضا و امضاهای صادرشده. به DNSSEC Algorithm Numbers در https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 مراجعه کنید.

مقادیر ممکن:

  • rsasha1
  • rsasha1-nsec3-sha1
  • rsasha256
  • rsasha512
  • ecdsap256sha256
  • ecdsap384sha384
  • ed25519
  • ed448

نکته:

الگوریتم Ed448 تنها در صورتی در دسترس است که برنامه با GnuTLS 3.6.12+ و Nettle 3.6+ کامپایل شده باشد.

پیش‌فرض: ecdsap256sha256

طول کلیدهای KSK یا CSK تازه‌تولیدشده.

پیش‌فرض: 2048 (rsa*)، 256 (ecdsap256)، 384 (ecdsap384)، 256 (ed25519)، 456 (ed448)

طول کلیدهای ZSK تازه‌تولیدشده.

پیش‌فرض: مقدار پیش‌فرض ksk-size را ببینید

در صورت فعال بودن، تمام زون‌هایی که این خط‌مشی به آن‌ها اختصاص یافته از یک یا چند KSK مشترک استفاده خواهند کرد. در حین چرخش (rollover) کلید KSK می‌توان چندین KSK را به اشتراک گذاشت.

هشدار:

از آنجا که مجموعه KSK مشترک به شناسه خط‌مشی (policy id) وابسته است، تغییر نام خط‌مشی این ارتباط را شکسته و هنگام نیاز به KSK جدید، مجموعه KSK مشترک جدیدی آغاز می‌شود.

پیش‌فرض: off

مقدار TTL برای رکوردهای DNSKEY افزوده‌شده به رأس زون (apex).

نکته:

روی طول عمر کلید ZSK تأثیر دارد.

هشدار:

اطمینان حاصل کنید که تمام رکوردهای DNSKEY با TTL به‌روزشده پیش از آغاز چرخش بعدی DNSKEY، در سرتاسر شبکه منتشر شده باشند.

پیش‌فرض: مقدار SOA TTL زون

تعیین (بازنویسی) حداکثر مقدار TTL در میان تمام رکوردهای زون.

نکته:

عموماً توصیه می‌شود تا حد امکان محاسبه بیشینه TTL را با تنظیم صریح این گزینه بازنویسی کنید. این گزینه برای DNSSEC Offline KSK <#dnssec-offline-ksk> الزامی است و زمانی که رکوردها به‌طور پویا تولید می‌شوند (مثلاً توسط ماژول <#mod-synthrecord>) کاملاً منطقی خواهد بود.

پیش‌فرض: پس از بارگذاری زون محاسبه می‌شود

مشخص می‌کند که برچسب‌های کلید (keytags) هر کلید تولیدشده باید به پیمانه (modulo) مشخص‌شده هم‌نهشت باشند. مقدار گزینه باید رشته‌ای با قالب R/M باشد که در آن R < M <= 256 اعداد صحیح مثبت هستند. هر زمان که یک کلید DNSSEC تولید می‌شود، اطمینان حاصل می‌شود که keytag % M == R باشد. این امر از تداخل برچسب کلید در پیکربندی‌های DNSSEC Offline KSK <#dnssec-offline-ksk> یا DNSSEC multi-signer <#dnssec-multi-signer> (و احتمالاً سایر موارد) جلوگیری می‌کند.

نکته:

این تنظیم تنها برای کلیدهای تازه‌تولیدشده در زمان ایجاد آن‌ها اعمال می‌شود. کلیدهای مربوط به پیش از تنظیم این گزینه و کلیدهای واردشده از جاهای دیگر ممکن است با این خط‌مشی مطابقت نداشته باشند.

پیش‌فرض: 0/1

دوره زمانی (به ثانیه) میان تولید KSK و شروع رول‌اور بعدی.

نکته:

طول عمر کلید KSK تحت تأثیر propagation-delay، dnskey-ttl و تاخیر در ثبت KSK نیز قرار دارد.

مقدار صفر (نامحدود) باعث عدم رول‌اور KSK می‌شود.

در صورت فعال بودن single-type-signing، این مورد برای طول عمر CSK اعمال می‌شود.

پیش‌فرض: 0 (نامحدود)

دوره زمانی (به ثانیه) میان فعال‌سازی ZSK و شروع رول‌اور بعدی.

نکته:

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

در نتیجه، در عملکرد عادی، دوره تولید ZSK برابر با zsk-lifetime + propagation-delay + dnskey_ttl خواهد بود.

مقدار صفر (نامحدود) باعث عدم رول‌اور ZSK می‌شود.

پیش‌فرض: 30d (۳۰ روز)

پس از رول‌اور یک کلید (KSK یا ZSK) و حذف آن از زون، نگهداری آن در پایگاه داده KASP برای حداقل این مدت زمان (به ثانیه) پیش از حذف کامل. این ویژگی برای عیب‌یابی در مواردی که نیاز به بازیابی کلید باشد مفید است.

پیش‌فرض: 0

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

نکته:

بر طول عمر کلید ZSK تأثیر دارد.

پیش‌فرض: 1h (۱ ساعت)

دوره اعتبار (به ثانیه) برای امضاهای تازه صادر شده.

نکته:

زمان شروع اعتبار امضای RRSIG روی ۹۰ دقیقه قبل تنظیم می‌شود. این دوره زمانی جزء طول عمر امضا محاسبه نمی‌شود.

پیش‌فرض: 14d (۱۴ روز)

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

پیش‌فرض: 0.1 * rrsig-lifetime + propagation-delay + zone-max-ttl

در صورت فعال بودن dnssec-validation:

پیش‌فرض: 1d (۱ روز)

حداکثر مدت زمان (به ثانیه) پیش از زمان بازآوری امضا که طی آن ممکن است امضا بازآوری شود، تا در زون‌هایی با به‌روزرسانی مکرر، امضاهای RRSIG در دسته‌های بزرگ‌تر بازآوری شوند (جلوگیری از امضای مجدد بیش از حد مکرر).

پیش‌فرض: 1h (۱ ساعت)

تولید قطعی امضاهای RRSIG برای الگوریتم‌های ECDSA (RFC 6979 https://datatracker.ietf.org/doc/html/rfc6979.html). این حالت علاوه بر امنیت رمزنگاری نظری بهتر، سرعت بارگذاری زون‌های امضا شده (با روش مشابه) را به طور چشمگیری افزایش می‌دهد. با این حال، امضای زون کمی کندتر انجام می‌شود.

پیش‌فرض: off

تعیین می‌کند که آیا NSEC3 به جای NSEC استفاده شود یا خیر.

پیش‌فرض: off

تعداد دفعات اضافی اجرای هشینگ.

پیش‌فرض: 0

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

هشدار:

رکورد NSEC3 با بیت Opt-Out فعال، دیگر به عنوان اثبات عدم وجود رکورد در این زون عمل نمی‌کند.

پیش‌فرض: off

طول فیلد salt بر حسب بایت (octet)، که پیش از هش کردن به نام مالک اصلی افزوده می‌شود.

پیش‌فرض: 0

مدت‌زمان اعتبار (به ثانیه) فیلد salt به‌تازگی صادر شده.

مقدار صفر به معنی نامحدود است.

مقدار خاص -1 هربار با تغییر ZSK فعال، ایجاد salt جدید (re-salt) را آغاز می‌کند. این امر تعداد تغییرات بزرگ روی زون را بهینه می‌سازد.

پیش‌فرض: 30d (۳۰ روز)

هنگام امضای زون یا به‌روزرسانی، از این تعداد ریسه (thread) برای امضای موازی استفاده می‌شود.

این ریسه‌ها افزون بر ریسه‌های مستقل Background workers هستند.

نکته:

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

پیش‌فرض: 1 (بدون ریسه اضافه)

ارجاع به بخش submission شامل پارامترهای بررسی ثبت KSK.

پیش‌فرض: تنظیم نشده

ارجاع‌های اختیاری remote و remotes به کارساز DNS معتبر زون والد. کارساز ریموت باید طوری پیکربندی شده باشد که به‌روزرسانی‌های رکورد DS را از طریق DDNS بپذیرد. هرگاه یک رکورد CDS در زون محلی تغییر کند، رکورد DS متناظر به‌صورت یک به‌روزرسانی پویا (DDNS) به کارساز DNS والد ارسال می‌شود. همه رکوردهای قبلی DS درون پیام DDNS حذف می‌شوند. مدیریت هم‌زمان هر دو زون فرزند و والد توسط یک کارساز Knot DNS یکسان امکان‌پذیر است.

نکته:

این ویژگی نیازمند این است که cds-cdnskey-publish روی none تنظیم نشده باشد.

نکته:

تغییر یادشده در رکورد CDS معمولاً به این معنی است که یک تعویض KSK (roll-over) در حال اجراست و کلید جدید در حال ورود، از پیش برای مدت‌زمان propagation-delay در وضعیت «آماده» (ready) بوده است.

نکته:

ماژول Onlinesign <#mod-onlinesign> از قابلیت ارسال DS (DS push) پشتیبانی نمی‌کند.

نکته:

اگر این ویژگی زمانی فعال شود که تعویض KSK از قبل در حال اجرا بوده است، ممکن است برای تعویض کلید در حال اجرا اعمال نشود.

پیش‌فرض: تنظیم نشده

ارجاع به بخش dnskey-sync شامل پارامترهای همگام‌سازی DNSKEY.

پیش‌فرض: تنظیم نشده

چگونگی و وضعیت انتشار رکوردهای CDS و CDNSKEY را در زون کنترل می‌کند.

مقادیر ممکن:

  • none – هرگز هیچ رکورد CDS یا CDNSKEY در زون منتشر نشود.
  • delete-dnssec – انتشار رکوردهای ویژه CDS و CDNSKEY که نشان‌دهنده غیرفعال‌سازی DNSSEC هستند.
  • rollover – انتشار رکوردهای CDS و CDNSKEY برای KSK آماده ولی هنوز غیرفعال (مرحله submission در تعویض KSK).
  • always – همیشه یک رکورد CDS و یک رکورد CDNSKEY برای KSK فعلی منتشر شود.
  • double-ds – همیشه حداکثر تا دو رکورد CDS و دو رکورد CDNSKEY برای KSKهای آماده و/یا فعال منتشر شود.

نکته:

اگر کلیدهای زون به‌صورت دستی مدیریت شوند، بسته به کلیدهای موجود، مجموعه‌رکوردهای (rrsets) مربوط به CDS و CDNSKEY ممکن است شامل رکوردهای بیشتری باشند.

هشدار:

مقدار double-ds روش تعویض double-DS را آغاز نمی‌کند. این روش تنها زمانی پشتیبانی می‌شود که به‌صورت دستی و بدون تنظیم ksk-submission انجام شود.

پیش‌فرض: rollover

نوع دایجست را برای رکوردهای منتشرشده CDS مشخص می‌کند.

مقادیر ممکن:

  • sha256
  • sha384

پیش‌فرض: sha256

نحوه مدیریت مجموعه‌رکوردهای DNSKEY، CDNSKEY و CDS در نقطه راس زون (apex) را هنگام امضای (مجدد) زون مشخص می‌کند.

مقادیر ممکن:

  • full – هنگام هر بار امضای (مجدد) زون، تمام رکوردهای ناشناخته DNSKEY، CDNSKEY و CDS را حذف کرده و فقط مواردی که با کلیدهای زون در پایگاه داده KASP مرتبط هستند حفظ می‌شوند.
  • incremental – رکوردهای ناشناخته DNSKEY، CDNSKEY و CDS در زون نگه داشته شده و رکوردهای تحت مدیریت سرور، به صورت تدریجی بر اساس تغییرات پایگاه داده KASP اصلاح می‌شوند.

نکته:

پیش‌نیازها برای incremental:
  • قابلیت Offline KSK <#dnssec-offline-ksk> پشتیبانی نمی‌شود.
  • مقدار delete-delay برای پوشش‌دادن خاموشی احتمالی دیمن (مثلاً برای نگهداری سرور) به اندازه کافی بزرگ باشد.
  • اجتناب از حذف دستی کلیدها با استفاده از keymgr <>.

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

پیش‌فرض: full

فعال بودن یا نبودن ویژگی Offline KSK <#dnssec-offline-ksk> را مشخص می‌کند.

پیش‌فرض: off

غیرفعال‌سازی برخی ویژگی‌های ایمنی DNSSEC.

مقادیر ممکن:

  • none – هیچ موردی غیرفعال نشود.
  • no-check-keyset – کلیدهای فعال در الگوریتم‌های موجود بررسی نشوند. این مورد ممکن است منجر به نقض RFC 4035 بخش 2.2 https://datatracker.ietf.org/doc/html/rfc4035.html#section-2.2 شود.
  • no-update-dnskey – رکوردهای DNSKEY، CDNSKEY و CDS در نقطه راس زون طبق پایگاه داده KASP نگهداری/بروزرسانی نشوند. دقیقاً همان‌طور که در زون هستند رها شوند.
  • no-update-nsec – زنجیره NSEC/NSEC3 نگهداری/بروزرسانی نشود. تمام رکوردها همان‌طور که در زون هستند رها شوند.
  • no-update-expired – رکوردهای منقضی‌شده RRSIG بروزرسانی نشوند.

چندین مقدار را می‌توان تعیین کرد.

هشدار:

این حالت مخصوص متخصصان DNSSEC است که عواقب آن را درک می‌کنند.

پیش‌فرض: none

پیکربندی اعتبارسنجی خارجی زون.

external:
  - id: STR
    timeout: TIME
    dump-new-zone: STR
    dump-removals: STR
    dump-additions: STR

شناسه بخش external.

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

پیش‌فرض: 300

مسیر پرونده‌ای که محتویات زون جدید پیش از انتظار برای اعتبارسنجی خارجی، در آن نوشته می‌شود.

پیش‌فرض: none

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

پیش‌فرض: none

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

پیش‌فرض: none

یک الگو، تنظیمات زون قابل اشتراک‌گذاری است که با کاهش موارد تکراری، پیکربندی را ساده می‌کند. الگوی پیش‌فرض خاص (با شناسه default) می‌تواند برای پیکربندی سراسری زون یا به عنوان پیکربندی ضمنی در صورت عدم تعیین الگوی دیگر برای زون، استفاده شود.

template:
  - id: STR
    global-module: STR/STR ...
    # All zone options (excluding 'template' item)

نکته:

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

شناسه الگو.

فهرست مرتب‌شده ارجاعات به ماژول‌های پرس‌وجو در قالب module_name یا module_name/module_id. این ماژول‌ها بر تمام پرس‌وجوها اعمال می‌شوند.

نکته:

این گزینه تنها در الگوی default در دسترس است.

پیش‌فرض: تنظیم‌نشده

تعریف زون‌های ارائه‌شده توسط سرور.

zone:
  - domain: DNAME
    template: template_id
    storage: STR
    file: STR
    zone-db-input: INT
    zone-db-output: INT
    master: remote_id | remotes_id ...
    ddns-master: remote_id
    notify: remote_id | remotes_id ...
    notify-delay: TIME
    update-delay: TIME
    acl: acl_id ...
    master-pin-tolerance: TIME
    provide-ixfr: BOOL
    semantic-checks: BOOL | soft
    default-ttl: TIME
    zonefile-sync: TIME
    zonefile-load: none | difference | difference-no-serial | whole
    zonefile-skip: STR ...
    journal-content: none | changes | all
    journal-max-usage: SIZE
    journal-max-depth: INT
    ixfr-benevolent: BOOL
    ixfr-by-one: BOOL
    ixfr-from-axfr: BOOL
    zone-max-size : SIZE
    adjust-threads: INT
    external-validation: external_id
    dnssec-signing: BOOL
    dnssec-validation: BOOL
    dnssec-policy: policy_id
    ds-push: remote_id | remotes_id ...
    zonemd-verify: BOOL
    zonemd-generate: none | zonemd-sha384 | zonemd-sha512 | remove
    serial-policy: increment | unixtime | dateserial
    serial-modulo: INT/INT | +INT | -INT | INT/INT+INT | INT/INT-INT
    reverse-generate: DNAME ...
    include-from: DNAME ...
    refresh-min-interval: TIME
    refresh-max-interval: TIME
    retry-min-interval: TIME
    retry-max-interval: TIME
    expire-min-interval: TIME
    expire-max-interval: TIME
    catalog-role: none | interpret | generate | member
    catalog-template: template_id ...
    catalog-zone: DNAME
    catalog-group: STR
    module: STR/STR ...

شناسه نام زون.

ارجاع به الگوی پیکربندی.

پیش‌فرض: تنظیم‌نشده یا default (اگر الگو وجود داشته باشد)

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

پیش‌فرض: ${localstatedir}/lib/knot (پیکربندی‌شده با --with-storage=path)

مسیر پرونده زون. امکان استفاده از قالب‌سازهای زیر نیز وجود دارد:

  • %c[N] یا %c[N-M] – یعنی کاراکتر Nام یا دنباله‌ای از کاراکترها که از کاراکتر Nام آغاز شده و با کاراکتر Mام نام متنی زون پایان می‌یابد (نگاه کنید به %s). شمارش اندیس‌ها از چپ و از 0 آغاز می‌شود. تمام نقطه‌ها (شامل نقطه پایانی) محاسبه می‌شوند. اگر کاراکتر موجود نباشد، قالب‌ساز بی‌اثر است.
  • %l[N] – یعنی برچسب Nام نام متنی زون (نگاه کنید به %s). شمارش اندیس از راست و از 0 آغاز می‌شود (0 ~ TLD). اگر برچسب موجود نباشد، قالب‌ساز بی‌اثر است.
  • %s – یعنی نام زون فعلی در نمایش متنی آن. نام زون شامل نقطه پایانی نیست (نتیجه برای زون ریشه، یک رشته خالی است!).
  • %% – یعنی نویسه %.

هشدار:

مراقب نویسه‌های ویژه‌ای که گریز داده شده‌اند یا به فرم \DDD کدگذاری شده‌اند (که در آن DDD کد اسکی ده‌دهی متناظر است) باشید.

پیش‌فرض: storage/%s.zone

در صورت تنظیم، زون از پایگاه داده زون پیکربندی‌شده در zone-db-listen بارگیری می‌شود. مقدار این گزینه، شماره نمونه زون (از 1 تا 8 شامل خودشان) درون پایگاه داده را جهت خواندن مشخص می‌کند.

نکته:

با فعال بودن این گزینه، پرونده متنی زون هرگز بارگیری نمی‌شود. تنظیمات zonefile-load همچنان برای مدیریت محتوای زون بارگیری‌شده از پایگاه داده اعمال می‌شود؛ با این حال، مقادیر zonefile-load: whole و journal-content: changes توصیه می‌شوند (که هر دو حالت پیش‌فرض هستند).

پیش‌فرض: -1 (غیرفعال)

در صورت تنظیم، زون در پایگاه داده زون پیکربندی‌شده در zone-db-listen ذخیره شده و با هر تغییر در محتوای زون در آنجا به‌روزرسانی می‌شود. مقدار این گزینه شماره نمونه زون (از 1 تا 8 شامل خودشان) درون پایگاه داده را جهت نوشتن تعیین می‌کند.

پیش‌فرض: -1 (غیرفعال)

فهرستی مرتب از ارجاعات remote و remotes به سرورهای اصلی زون (که پیش‌تر با عنوان سرورهای master شناخته می‌شدند). مقدار خالی برای بازنویسی مقدار الگو مجاز است.

پیش‌فرض: تنظیم نشده

ارجاعی به سرور اصلی زون که پیام‌های DDNS باید به آن فوروارد شوند. در صورت عدم تعیین، اولین سرور master استفاده می‌شود.

اگر روی مقدار خالی ("") تنظیم شود، پیام‌های دریافتی DDNS فوروارد نمی‌شوند بلکه روی زون محلی اعمال می‌گردند، فارغ از اینکه سرور ثانویه باشد یا نه. این مورد فقط در ترکیب با فعال بودن dnssec-signing مجاز است.

پیش‌فرض: تنظیم نشده

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

پیش‌فرض: تنظیم نشده

تأخیر زمانی بر حسب ثانیه پیش از ارسال پیام خروجی NOTIFY. این تأخیر همچنین دقت زمانی ارسال پیام‌های NOTIFY را به ازای هر زون مشخص می‌کند.

پیش‌فرض: 0

تأخیر زمانی بر حسب ثانیه پیش از اعمال تغییرات در محتوای زون پس از یک محرک خارجی مانند NOTIFY یا DDNS دریافتی، یا یک محرک داخلی از زونی دیگر مانند تغییر در زونی که باید معکوس شود، شامل شده از آن باشد یا عضوی از کاتالوگ زون تولیدشده باشد.

استثنا: رویدادهای تغییر زون ناشی از سوکت کنترل (دستورهای knotc zone-*) یا کاتالوگ تفسیرشده بلافاصله و بدون تأخیر پیکربندی‌شده انجام می‌شوند.

پیش‌فرض: 0

فهرستی مرتب از ارجاعات به قواعد ACL که می‌توانند انتقال‌های زون، به‌روزرسانی‌ها یا پیام‌های NOTIFY دریافتی را مجاز یا رد کنند.

پیش‌فرض: تنظیم نشده

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

این گزینه زمانی مفید است که چند سرور اصلی ممکن است تاریخچه‌های متفاوتی از زون در ژورنال‌های خود داشته باشند، که ترکیب متناوب IXFR از سرورهای اصلی مختلف را ناامن می‌سازد.

پیش‌فرض: 0 (غیرفعال)

اگر غیرفعال باشد، سرور مجبور است به پرس‌وجوهای IXFR با AXFR پاسخ دهد. اگر فعال باشد، به درخواست‌های IXFR به‌صورت عادی پاسخ داده می‌شود.

پیش‌فرض: on

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

چندین بررسی اجباری وجود دارد که همیشه فعال‌اند و قابل غیرفعال‌سازی نیستند. خطا در بررسی اجباری مانع از بارگذاری زون می‌شود. اکثر بررسی‌های اجباری را می‌توان با تنظیم soft تضعیف کرد، که امکان بارگذاری زون را حتی در صورت رد شدن در بررسی فراهم می‌کند.

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

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

بررسی‌های اجباری:

(*) بررسی نشانه‌دار را نمی‌توان با حالت soft تضعیف کرد. سایر بررسی‌های اجباری مشمول حالت اختیاری soft می‌شوند.

بررسی‌های اضافی:

  • نبود رکورد NS در رأس زون
  • نبود رکورد glue از نوع A یا AAAA
  • رکورد نامعتبر DS یا NSEC3PARAM
  • ناهمخوانی CDS یا CDNSKEY
  • سایر بررسی‌های DNSSEC که حین dnssec-validation اجرا می‌شوند

نکته:

حالت soft به رویداد تازه‌سازی اجازه می‌دهد از پاسخ CNAME به پرس‌وجوی SOA (پیام با ساختار نادرست) چشم‌پوشی کند و در عوض راه‌اندازی اولیه زون (bootstrap) را اجرا نماید.

پیش‌فرض: off

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

هشدار:

از آنجا که تغییر این مقدار می‌تواند منجر به تجزیه متفاوت پرونده(های) زون شود، شماره سریال SOA مربوطه زون باید قبل از بارگذاری مجدد یا ثبت پیکربندی افزایش یابد. از طرف دیگر، تنظیم zonefile-load روی difference-no-serial تضمین می‌کند که به‌روزرسانی زون(های) حاصل صحیح باشد.

پیش‌فرض: 3600

مدت زمان به ثانیه که پس از آن زون فعلی در حافظه با پرونده زون روی دیسک همگام‌سازی می‌شود (به file مراجعه کنید). سرور حتی پس از راه‌اندازی مجدد با استفاده از ژورنال زون، آخرین نسخه زون را ارائه می‌دهد، اما پرونده زون روی دیسک تنها پس از پایان زمان zonefile-sync (یا پس از تخلیه دستی زون) همگام‌سازی خواهد شد. این قابلیت زمانی کاربرد دارد که زون از طریق IXFR ،DDNS یا امضای خودکار DNSSEC به‌روزرسانی شود. برای غیرفعال کردن کامل همگام‌سازی خودکار پرونده زون، مقدار را روی -1 تنظیم کنید. در این حالت، همچنان امکان اجبار تخلیه دستی زون با گزینه -f وجود دارد.

نکته:

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

پیش‌فرض: 0 (فوری)

نحوه اعمال محتوای پرونده زون هنگام بارگذاری زون را انتخاب می‌کند.

مقادیر ممکن:

  • none – پرونده زون اصلاً استفاده نمی‌شود.
  • difference – اگر محتوای زون هنگام شروع یا بارگذاری مجدد سرور از قبل در دسترس باشد، تفاوت بین آن‌ها و محتوای پرونده زون محاسبه می‌شود. این تفاوت سپس از نظر خطاهای معنایی بررسی شده و بر محتوای فعلی زون اعمال می‌شود.
  • difference-no-serial – مشابه difference است، اما از سریال SOA در پرونده زون چشم‌پوشی می‌شود و سرور به‌طور خودکار سریال را افزایش می‌دهد.
  • whole – محتوای زون از پرونده زون بارگذاری می‌شود.

هنگامی که difference پیکربندی شده باشد و هنوز محتوایی برای زون وجود نداشته باشد (راه‌اندازی اولیه بدون محتوای پیشین و بدون محتوای زون در ژورنال)، رفتاری مشابه با whole خواهد داشت.

پیش‌فرض: whole

نکته:

برای راهنمایی در مورد پیکربندی این گزینه و گزینه‌های مرتبط جهت تضمین عملکرد قابل اطمینان، به Handling zone file, journal, changes, serials <#handling-zone-file-journal-changes-serials> مراجعه کنید.

هشدار:

اگر zone-db-input پیکربندی شده باشد، پرونده متنی زون هرگز بارگذاری نمی‌شود. با این وجود، این گزینه همچنان بر نحوه اعمال و مدیریت محتوای زون بارگذاری‌شده از پایگاه داده تأثیر می‌گذارد.

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

انواع رکوردهای منبع به صورت رشته نشان داده می‌شوند (مانند "DS") و چندین نوع قابل تعیین است. رشته خاص dnssec نشان‌دهنده تمام انواعی است که معمولاً توسط روال‌های امضای DNSSEC ایجاد می‌شوند (DNSKEY، RRSIG، NSEC، NSEC3، NSEC3PARAM، CDNSKEY، CDS — ولی نه DS).

نکته:

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

پیش‌فرض: تنظیم‌نشده

نحوه استفاده از ژورنال برای ذخیره زون و تغییرات آن را تعیین می‌کند.

مقادیر ممکن:

  • none – ژورنال اصلاً استفاده نمی‌شود.
  • changes – تاریخچه تغییرات زون در ژورنال ذخیره می‌شود.
  • all – محتوا و تاریخچه زون در ژورنال ذخیره می‌شود.

پیش‌فرض: changes

هشدار:

هنگام تغییر این گزینه، ژورنال داده‌های مربوط به تنظیم قبلی را نگه می‌دارد. برای نمونه، تغییر آن به none ژورنال را پاکسازی نمی‌کند. همچنین، تغییر آن از all به changes باعث حذف zone-in-journal نمی‌شود و رفتار بارگذاری زون ممکن است متفاوت از حد انتظار باشد. توصیه می‌شود هنگام تغییر این گزینه، پاکسازی ژورنال لحاظ شود.

سیاست میزان فضای اشغالی در DB ژورنال توسط ژورنال هر زون.

نکته:

به دلیل تکه‌تکه‌شدن (fragmentation) فضای خالی DB، ممکن است حجم پایگاه‌داده ژورنال بسیار بیشتر از مجموع journal-max-usage همه زون‌ها رشد کند.

پیش‌فرض: 100M (100 مگابایت)

حداکثر طول تاریخچه ژورنال.

نکته:

مجموعه تغییرات zone-in-journal جزو این حد شمرده نمی‌شود.

حداقل: 2

پیش‌فرض: 20

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

پیش‌فرض: off

در IXFR دریافتی، پردازش فقط یک مجموعه تغییر در لحظه، نه چند مورد با هم. این کار تاریخچه کامل را در ژورنال حفظ می‌کند و مانع از ادغام مجموعه‌های تغییر هنگام دریافت همزمان چندتایی IXFR می‌شود. با این حال، همانطور که در رفتار ژورنال <#journal-behaviour> شرح داده شده، مانع از ادغام (یا حذف) مجموعه تغییرات قدیمی در ژورنال جهت ذخیره فضا نمی‌شود.

این گزینه باعث افزایش بار سرور هنگام پردازش IXFR، شامل ترافیک شبکه می‌شود.

پیش‌فرض: off

اگر کارگزار اولیه در پاسخ به درخواست IXFR، قالبی به سبک AXFR (AXFR-style-IXFR) بفرستد، تفاوت محاسبه شده و به صورت یک به‌روزرسانی تدریجی زون پردازش می‌شود (مثلاً با ذخیره مجموعه تغییرات در ژورنال).

پیش‌فرض: off

حداکثر اندازه زون. اندازه بر اساس حجم رکوردهای زون در قالب شبکه (wire format) بدون فشرده‌سازی سنجیده می‌شود. این حد برای انتقال‌های زون ورودی و به‌روزرسانی‌های پویا اعمال می‌شود.

برای انتقال‌های تدریجی (IXFR)، حد مؤثر برای اندازه کل رکوردهای موجود در انتقال، دو برابر مقدار پیکربندی‌شده است. با این حال، اندازه نهایی زون باید با مقدار پیکربندی‌شده مطابقت داشته باشد.

پیش‌فرض: نامحدود

موازی‌سازی روال‌های داخلی تنظیم زون با استفاده از تعداد معینی ریسه (thread). این مورد برای زون‌های بسیار بزرگ با NSEC3 مفید است. افزایش سرعت هنگام راه‌اندازی سرور و پردازش re-salt در NSEC3 قابل مشاهده است.

پیش‌فرض: 1 (بدون ریسه اضافی)

ارجاع به بخش اعتبارسنجی خارجی (external validation).

در صورت پیکربندی، هرگونه تغییر در زون (به‌روزرسانی پرونده زون، IXFR/AXFR ورودی، به‌روزرسانی پویا، و امضای مجدد DNSSEC، ولی نه تغییرات روی سوکت کنترلی – knotc zone-begin) درست پیش از اعمال زون جدید متوقف می‌شود. در آن نقطه، اعتبارسنجی و تأیید کاربر (یا اسکریپت تعریف‌شده توسط کاربر) انتظار کشیده می‌شود.

نکته:

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

در بخش ارجاع‌شده external، امکان تعریف مسیر پرونده‌هایی وجود دارد که محتوا یا تفاوت‌های زون جدید درست پیش از هر اعتبارسنجی در آن‌ها (در قالب پرونده زون) نوشته می‌شود.

نکته کوتاه:

اگر dbus-event روی external-verify تنظیم شده باشد، هنگامی که سرور منتظر اعتبارسنجی خارجی است، سیگنال مربوطه ارسال می‌شود.

پیش‌فرض: none

اگر فعال باشد، امضای خودکار DNSSEC برای زون روشن می‌شود.

پیش‌فرض: off

اگر فعال باشد، محتوای زون برای امضای صحیح با امضاهای DNSSEC (شامل زنجیرهٔ NSEC/NSEC3) هر بار که زون بارگذاری یا تغییر کند (شامل AXFR/IXFR)، یا هر زمان که انقضای یک RRSIG قبلاً دیده‌شده سپری شود، اعتبارسنجی می‌شود.

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

هنگامی که یک RRSIG روی سرور ثانویه منقضی شود، کل زون منقضی می‌شود (SERVFAIL دائمی تا زمان حل مشکل).

اعتبارسنجی DNSSEC تا حد امکان به‌صورت افزایشی انجام می‌شود (زمان کمی برای به‌روزرسانی‌های کوچک روی زون بزرگ صرف می‌کند)، اما گاهی اعتبارسنجی کامل زون صورت می‌گیرد.

فهرست بررسی‌های DNSSEC:

  • هر RRSet زون به‌طور صحیح توسط حداقل یک DNSKEY موجود امضا شده باشد.
  • برای هر RRSIG حداکثر ۳ DNSKEY غیرمنطبق با keytag یکسان وجود دارد.
  • مجموعهٔ RRSet مربوط به DNSKEY توسط KSK امضا شده باشد.
  • رکورد NSEC(3) برای هر نام وجود داشته باشد (مگر در حالت opt-out) با بیت‌مپ صحیح.
  • هر رکورد NSEC(3) به رکورد بعدی از نظر ترتیب واژگانی متصل باشد.

اعتبارسنجی تحت تأثیر پیکربندی dnssec-policy قرار نمی‌گیرد، به‌جز گزینهٔ signing-threads که تعداد رشته‌ها را برای اعتبارسنجی موازی مشخص می‌کند، و rrsig-refresh که حداقل اعتبار باقی‌ماندهٔ مجاز RRSIG را تعریف می‌کند (در غیر این صورت یک هشدار ثبت می‌شود).

نکته:

رکوردهای NSEC3 زائد یا خراب نادیده گرفته می‌شوند.

این حالت با dnssec-signing سازگار نیست.

نکته:

اگر dbus-event روی dnssec-invalid تنظیم شده باشد، سیگنال مربوطه در هنگام شکست اعتبارسنجی منتشر می‌شود؛ چه در مورد به‌روزرسانی نامعتبر زون و چه در مورد RRSIG منقضی‌شده که بازآوری نشده است.

پیش‌فرض: تنظیم‌نشده

ارجاع به خط‌مشی امضای DNSSEC.

نکته:

خط‌مشی پیکربندی‌شده به نام "default" استفاده نخواهد شد مگر اینکه صریحاً ارجاع داده شود.

پیش‌فرض: یک خط‌مشی فرضی با تمام مقادیر پیش‌فرض

پیکربندی ds-push برای هر زون. این گزینه خط‌مشی‌های احتمالی مربوط به هر پالیسی را بازنویسی می‌کند. مقدار خالی برای بازنویسی مقدار الگو مجاز است.

پیش‌فرض: تنظیم‌نشده

در هر بارگذاری/به‌روزرسانی زون، بررسی شود که ZONEMD در زون موجود و معتبر است.

نکته:

محاسبهٔ خلاصهٔ زون (Zone digest) ممکن است روی زون‌های بزرگ زمان و CPU زیادی مصرف کند.

نکته:

اگر dbus-event روی dnssec-invalid تنظیم شده باشد، سیگنال مربوطه در هنگام شکست تأیید اعتبار منتشر می‌شود.

پیش‌فرض: off

در هر به‌روزرسانی زون، ZONEMD محاسبه شده و درون زون قرار داده شود.

مقادیر ممکن:

  • none – هیچ اقدامی دربارهٔ ZONEMD انجام نشود.
  • zonemd-sha384 – تولید ZONEMD با استفاده از الگوریتم SHA384.
  • zonemd-sha512 – تولید ZONEMD با استفاده از الگوریتم SHA512.
  • remove – حذف هرگونه ZONEMD از رأس (apex) زون.

پیش‌فرض: none

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

مقادیر ممکن:

  • increment – سریال طبق محاسبات ریاضی شماره سریال افزایش می‌یابد.
  • unixtime – سریال روی زمان یونیکس فعلی تنظیم می‌شود.
  • dateserial – سریال ۱۰ رقمی (YYYYMMDDnn) افزایش می‌یابد، ۸ رقم نخست با تاریخ iso فعلی مطابقت دارد.

نکته:

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

برای جلوگیری از سردرگمی کاربر، از dateserial فقط در صورتی استفاده کنید که حداکثر انتظار ۱۰۰ به‌روزرسانی در روز برای هر زون را دارید و از unixtime فقط در صورتی که حداکثر انتظار یک به‌روزرسانی در ثانیه برای هر زون را دارید.

زون‌های کاتالوگ تولیدشده تنها از unixtime استفاده می‌کنند.

پیش‌فرض: increment (برای زون‌های کاتالوگ تولیدشده: unixtime)

مقدار گزینه رشته‌ای شامل دو بخش (بدون جداکننده) است؛ هر بخش اختیاری است.

بخش نخست مشخص می‌کند شماره سریال زون باید بر مبنای همنهشتی به پیمانه مقدار مشخص‌شده باشد. قالب آن R/M است که در آن R < M <= 256 اعداد صحیح مثبت هستند. هرگاه شماره سریال زون افزایش یابد، تضمین می‌شود که serial % M == R باشد. این ویژگی هنگام وجود چندین سرور primary ناسازگار مفید است؛ جایی که دنباله‌های متمایز سریال زون مانع از cross-master-IXFR توسط هر secondary می‌شود.

نکته:

به این دلیل که سریال زون عملاً به جای 1 همواره به میزان M افزایش می‌یابد، استفاده از خط‌مشی سریال dateserial یا حتی unixtime در زون‌های با به‌روزرسانی سریع پیشنهاد نمی‌شود.

بخش دوم یک جابجایی عددی را برای سریال زون ایجادشده تعیین می‌کند. این جابجایی به‌صورت یک عدد صحیح دارای علامت، شامل علامت (+ یا -) قالب‌بندی می‌شود. بیشترین کاربرد آن همراه با خط‌مشی سریال unixtime است، جایی که سریال تولیدشده برای زون نسبت به زمان یونیکس جابجا می‌شود.

نکته:

جهت تضمین سیاست همنهشتی، این گزینه تنها با فعال بودن امضای DNSSEC و تنظیم zonefile-load روی difference-no-serial یا none مجاز است.

پیش‌فرض: 0/1+0

فهرستی از نام‌های زون که تولید خودکار رکوردهای معکوس PTR بر اساس رکوردهای A/AAAA برای آن‌ها فعال است. کل زون تولیدشده به‌طور خودکار در ژورنال ذخیره می‌شود.

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

محدودیت‌های فعلی:

  • برای زون‌های بزرگ کند است (حتی هنگام تغییرات اندک).
  • با هر تغییر در هر یک از زون‌های معکوس، تمامی رکوردهای معکوس را دوباره محاسبه می‌کند.

در مورد زون ثانویه (یعنی سرور master مشخص شده باشد)، این گزینه به معنی ixfr-from-axfr: on و journal-content: all است؛ در غیر این صورت معادل zonefile-load: difference-no-serial و journal-content: all خواهد بود.

پیش‌فرض: none

فهرستی از زیرزون‌ها که باید در این زون ادغام و مسطح (flatten) شوند. این عمل مسطح‌سازی تمام رکوردهای مربوط به تفویض اختیار (شامل NS، SOA و ...) را از هر دو زون حذف کرده و دیگر رکوردها را از زیرزون به این زون رونوشت می‌کند.

در مورد زون ثانویه (یعنی سرور master مشخص شده باشد)، این گزینه به معنی ixfr-from-axfr: on و journal-content: all است؛ در غیر این صورت معادل zonefile-load: difference-no-serial و journal-content: all خواهد بود.

پیش‌فرض: none

حداقل بازه زمانی اجباری برای تازه‌سازی زون (به ثانیه) جهت جلوگیری از ارسال ترافیک بیش‌ازحد به سرور primary.

حداقل: 2

پیش‌فرض: 2

حداکثر بازه زمانی اجباری برای تازه‌سازی زون (به ثانیه).

پیش‌فرض: تنظیم‌نشده

حداقل بازه زمانی اجباری برای تلاش دوباره زون (به ثانیه) جهت جلوگیری از ارسال ترافیک بیش‌ازحد به سرور primary.

حداقل: 1

پیش‌فرض: 1

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

پیش‌فرض: تنظیم‌نشده

حداقل بازه زمانی اجباری انقضای زون (به ثانیه) جهت جلوگیری از ارسال ترافیک بیش‌ازحد به سرور primary.

حداقل: 3

پیش‌فرض: 3

حداکثر بازه زمانی اجباری انقضای زون (به ثانیه).

پیش‌فرض: تنظیم‌نشده

فعال‌سازی قابلیت catalog zone. مقادیر ممکن:

  • none – زون کاتالوگ نیست.
  • interpret – زون کاتالوگی که از یک پرونده زون یا XFR بارگذاری می‌شود، و زون‌های عضو باید بر اساس محتوای آن پیکربندی شوند.
  • generate – زون کاتالوگی که محتوای آن بر اساس زون‌های عضو تخصیص‌یافته تولید می‌شود.
  • member – زون عضوی که به یک زون کاتالوگ تولیدشده تخصیص یافته است.

نکته:

در صورت تنظیم روی generate، گزینه zonefile-load هیچ اثری ندارد زیرا پرونده زون هرگز بارگذاری نمی‌شود.

پیش‌فرض: none

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

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

نکته:

این گزینه باید تنها و تنها در صورتی تنظیم شود که catalog-role روی interpret باشد.

زون‌های کاتالوگ تودرتو پشتیبانی نمی‌شوند. بنابراین الگوهای کاتالوگ نمی‌توانند شامل catalog-role تنظیم‌شده روی interpret یا generate باشند.

پیش‌فرض: تنظیم نشده

تخصیص این زون عضو به زون کاتالوگ تولیدشدهٔ مشخص‌شده.

نکته:

این گزینه باید در صورتی تنظیم شود که catalog-role روی member باشد.

زون کاتالوگ ارجاع‌شده باید وجود داشته باشد و catalog-role آن روی generate تنظیم شده باشد.

هشدار:

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

ترتیب صحیح پردازش زون کاتالوگ روی کارگزارهای ثانویه را می‌توان با متوقف‌سازی موقت (انجماد) انتقال‌های خروجی <#knotc-zone-xfr-freeze> زون کاتالوگ مقصد و رفع انجماد آن <#knotc-zone-xfr-thaw> پس از پردازش زون کاتالوگ مبدا (یعنی حذف شدن عضو)، و سپس ارسال دستی اعلان <#knotc-zone-notify> به ثانویه‌ها تضمین کرد.

اگر کاتالوگ‌های زون تولیدشده پیش‌تر با ترتیب نادرست به یک ثانویه رسیده باشند، آغاز انتقال مجدد زون <#knotc-zone-retransfer> برای کاتالوگ مقصد در ثانویه مشکل را برطرف می‌کند.

پیش‌فرض: تنظیم نشده

تخصیص این زون عضو به گروه کاتالوگ مشخص‌شده (الگوی پیکربندی).

نکته:

این گزینه تنها و تنها در صورتی موثر است که catalog-role روی member باشد.

پیش‌فرض: تنظیم نشده

فهرستی مرتب از ارجاعات به ماژول‌های پرس‌وجو در قالب module_name یا module_name/module_id. این ماژول‌ها صرفاً بر پرس‌وجوهای زون جاری اعمال می‌شوند.

پیش‌فرض: تنظیم نشده

CZ.NIC, z.s.p.o. و مشارکت‌کنندگان https://www.knot-dns.cz

Copyright (C) CZ.NIC, z.s.p.o. and contributors

2026-06-12 3.5.5