verbosity: <number>

سطح پرگویی.

پرگویی را همچنین می‌توان از خط فرمان و در زمان اجرا از طریق کنترل از راه دور افزایش داد. به ترتیب unbound(8) و unbound-control(8) را ببینید.

پیش‌فرض: 1

statistics-interval: <seconds>

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

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

statistics-cumulative: <yes or no>

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

پیش‌فرض: no

extended-statistics: <yes or no>

در صورت فعال بودن، آمارهای گسترده از unbound-control(8) چاپ می‌شوند. شمارنده‌ها در unbound-control(8) فهرست شده‌اند. ردیابی آمارهای بیشتر زمان‌بر است.

پیش‌فرض: no

statistics-inhibit-zero: <yes or no>

در صورت فعال بودن، از چاپ آمارهای گسترده انتخابی با مقدار 0 در unbound-control(8) جلوگیری می‌شود. این‌ها شامل انواع پرس‌وجو، کلاس‌های پرس‌وجو، کدهای عملیات پرس‌وجو، ردهای پاسخ (به جز NOERROR، FORMERR، SERVFAIL، NXDOMAIN، NOTIMPL، REFUSED) و اقدامات RPZ هستند.

پیش‌فرض: yes

num-threads: <number>

تعداد نخ‌ها برای ایجاد جهت خدمت‌رسانی به کلاینت‌ها. برای عدم استفاده از چندنخی از 1 استفاده کنید.

پیش‌فرض: 1

port: <port number>

شماره درگاهی که سرور روی آن به پرس‌وجوها پاسخ می‌دهد.

پیش‌فرض: 53

interface: <IP address or interface name[@port]>

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

اگر به جای آدرس IP از نام یک رابط استفاده شود، فهرست آدرس‌های IP روی آن رابط استفاده می‌شود. رابط‌ها با بارگذاری مجدد (kill -HUP) تغییر نمی‌کنند، بلکه تنها با راه‌اندازی مجدد تغییر می‌یابند.

شماره درگاه می‌تواند با @port (بدون فاصله میان رابط و شماره درگاه) مشخص شود، اگر مشخص نشود از درگاه پیش‌فرض (از port) استفاده می‌شود.

ip-address: <IP address or interface name[@port]>

مشابه interface (برای سازگاری آسان با nsd.conf(5)).

interface-automatic: <yes or no>

روی تمام آدرس‌ها در تمام رابط‌ها (فعلی و آینده) شنود می‌کند، رابط مبدا را در پرس‌وجوهای UDP شناسایی کرده و آن‌ها را در پاسخ‌ها کپی می‌کند. این گزینه بسیار شبیه به ip-transparent است، اما این گزینه به تمام رابط‌ها خدمت‌رسانی می‌کند در حالی که با ip-transparent می‌توانید انتخاب کنید Unbound روی کدام رابط‌ها (آینده) خدمات ارائه دهد. این قابلیت آزمایشی است و نیازمند پشتیبانی سیستم‌عامل شما از گزینه‌های سوکت خاص است.

پیش‌فرض: no

interface-automatic-ports: "<string>"

فهرست شماره درگاه‌هایی که interface-automatic روی آن‌ها شنود می‌کند. در صورت خالی بودن، روی درگاه پیش‌فرض شنود می‌شود. شماره‌های درگاه با فاصله در رشته جدا می‌شوند.

از این گزینه می‌توان استفاده کرد تا رابط خودکار با رابط کار کند و با گنجاندن درگاه معمولی در فهرست، روی آن شنود کند، و همچنین با قرار دادن شماره درگاه‌های HTTPS یا DNS-over-TLS در فهرست، روی آن‌ها نیز شنود نماید.

پیش‌فرض: ""

outgoing-interface: <IPv4/IPv6 address or IPv6 netblock>

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

اگر به جای یک آدرس IPv6 منفرد، یک بلوک شبکه IPv6 مشخص شود، پرس‌وجوهای خروجی UDP از یک آدرس مبدا تصادفی برگرفته از بلوک شبکه برای مقابله با جعل استفاده خواهند کرد. نیاز دارد که بلوک شبکه IPv6 به سمت میزبان اجراکننده Unbound مسیریابی شده باشد و نیازمند پشتیبانی سیستم‌عامل از اتصال‌های محلی غیرمجاز (non-local binds) بدون امتیاز است (در حال حاضر فقط در لینوکس پشتیبانی می‌شود). چندین بلوک شبکه را می‌توان با چندین گزینه outgoing-interface مشخص کرد، اما همزمان یک آدرس IPv6 منفرد و یک بلوک شبکه IPv6 را مشخص نکنید، در غیر این صورت تصادفی‌سازی به خطر می‌افتد. برای افزایش احتمال انتخاب سرورهای نام IPv6 برای پرس‌وجوها، ترکیب آن با prefer-ip6: yes را در نظر بگیرید. در لینوکس برای اینکه بتوانید از گزینه سوکت freebind برای دریافت ترافیک بلوک شبکه ip6 استفاده کنید، به این دو دستور نیاز دارید:

ip -6 addr add mynetblock/64 dev lo && \
ip -6 route add local mynetblock/64 dev lo

outgoing-range: <number>

تعداد درگاه‌ها برای باز کردن. این تعداد توصیف‌کننده فایل می‌تواند به ازای هر نخ باز شود. باید حداقل 1 باشد. پیش‌فرض به گزینه‌های کامپایل بستگی دارد. اعداد بزرگ‌تر نیازمند منابع اضافی از سیستم‌عامل هستند. برای کارایی یک مقدار بسیار بزرگ بهترین است، از libevent برای امکان‌پذیر ساختن این امر استفاده کنید. باید بالاتر (ترجیحاً دو برابر) مقدار num-queries-per-thread باشد تا مواردی را که فهرست درخواست‌ها پر است پوشش دهد و از قحطی توصیف‌کننده فایل جلوگیری کند.

پیش‌فرض: 4096 (libevent) / 960 (minievent) / 48 (windows)

outgoing-port-permit: <port number or range>

به Unbound اجازه می‌دهد این درگاه یا محدوده درگاه‌ها را برای ارسال پرس‌وجوها باز کند. تعداد بیشتر درگاه‌های خروجی مجاز، انعطاف‌پذیری در برابر تلاش‌های جعل را افزایش می‌دهد. اطمینان حاصل کنید که این درگاه‌ها توسط دیمون‌های دیگر مورد نیاز نباشند. به‌طور پیش‌فرض تنها درگاه‌های بالای 1024 که توسط IANA تخصیص نیافته‌اند استفاده می‌شوند. یک شماره درگاه یا محدوده‌ای به شکل "low-high" بدون فاصله وارد کنید.

عبارت‌های outgoing-port-permit و outgoing-port-avoid به ترتیب خطوط پرونده پیکربندی پردازش می‌شوند؛ درگاه‌های مجاز را اضافه و درگاه‌های اجتناب‌شده را از مجموعه درگاه‌های مجاز کم می‌کنند. پردازش با درگاه‌های تخصیص‌نیافته توسط IANA بالای 1024 در مجموعه درگاه‌های مجاز آغاز می‌شود.

outgoing-port-avoid: <port number or range>

به Unbound اجازه باز کردن این درگاه یا محدوده درگاه‌ها را برای ارسال پرس‌وجوها نمی‌دهد. از این گزینه استفاده کنید تا مطمئن شوید Unbound درگاهی را که دیمون دیگری نیاز دارد تصاحب نمی‌کند. از درگاه در تمام رابط‌های خروجی، هم IPv4 و هم IPv6، اجتناب می‌شود. به‌طور پیش‌فرض تنها درگاه‌های بالای 1024 که توسط IANA تخصیص نیافته‌اند استفاده می‌شوند. یک شماره درگاه یا محدوده‌ای به شکل "low-high" بدون فاصله وارد کنید.

outgoing-num-tcp: <number>

تعداد بافرهای خروجی TCP برای تخصیص به ازای هر نخ. اگر روی 0 تنظیم شود، یا اگر do-tcp: no تنظیم شده باشد، هیچ پرس‌وجوی TCP به سرورهای مجاز انجام نمی‌شود. برای سامانه‌های بزرگ‌تر افزایش این مقدار ایده خوبی است.

پیش‌فرض: 10

incoming-num-tcp: <number>

تعداد بافرهای ورودی TCP برای تخصیص به ازای هر نخ. اگر روی 0 تنظیم شود، یا اگر do-tcp: no تنظیم شده باشد، هیچ پرس‌وجوی TCP از کلاینت‌ها پذیرفته نمی‌شود. برای سامانه‌های بزرگ‌تر افزایش این مقدار ایده خوبی است.

پیش‌فرض: 10

edns-buffer-size: <number>

تعداد بایت‌های اندازه برای اعلام به عنوان اندازه بافر بازسرهم‌بندی EDNS. این مقداری است که در دیتاگرام‌های روی UDP به سمت همتایان قرار می‌گیرد. اندازه واقعی بافر توسط msg-buffer-size (هم برای TCP و هم UDP) تعیین می‌شود. بزرگ‌تر از آن مقدار تنظیم نکنید. تنظیم روی 512 حتی سخت‌گیرانه‌ترین مشکلات مسیر MTU را دور می‌زند، اما افراطی تلقی می‌شود، زیرا حجم بازگشت به TCP ایجاد شده بیش از حد است (احتمالاً برای این تحلیل‌کننده نیز تنظیم outgoing-num-tcp را در نظر بگیرید).

پیش‌فرض: 1232 (توصیه DNS Flag Day 2020)

max-udp-size: <number>

حداکثر اندازه پاسخ UDP (روی پاسخ TCP اعمال نمی‌شود). مقدار 65536 حداکثر اندازه پاسخ UDP را غیرفعال کرده و همیشه از انتخاب کلاینت استفاده می‌کند. مقادیر پیشنهادی 512 تا 4096 هستند.

پیش‌فرض: 1232 (مشابه edns-buffer-size)

stream-wait-size: <number>

حداکثر تعداد بایت‌های اندازه برای استفاده جهت بافرهای جریان در انتظار. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت). از آنجا که جریان‌های TCP و TLS چندین نتیجه را صف‌بندی می‌کنند، مقدار حافظه استفاده‌شده برای این بافرها از این عدد فراتر نمی‌رود، در غیر این صورت پاسخ‌ها دور ریخته می‌شوند. این امر کل مصرف حافظه سرور را (تحت بار سنگین) مدیریت می‌کند؛ تعداد درخواست‌هایی که می‌توانند به ازای هر اتصال در صف قرار گیرند نیز محدود است و درخواست‌های بیشتر در بافرهای TCP منتظر می‌مانند.

پیش‌فرض: 4m

msg-buffer-size: <number>

تعداد بایت‌های اندازه بافرهای پیام. پیش‌فرض 65552 بایت است، کافی برای بسته‌های 64 کیلوبایتی که حداکثر اندازه پیام DNS است. هیچ پیامی بزرگ‌تر از این نمی‌تواند ارسال یا دریافت شود. می‌تواند برای استفاده از حافظه کمتر کاهش یابد، اما برخی درخواست‌ها برای داده‌های DNS، مانند رکوردهای منبع حجیم، منجر به پاسخ SERVFAIL به کلاینت خواهد شد.

پیش‌فرض: 65552

msg-cache-size: <number>

تعداد بایت‌های اندازه کش پیام. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت).

پیش‌فرض: 4m

msg-cache-slabs: <number>

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

پیش‌فرض: (پیکربندی‌نشده)

num-queries-per-thread: <number>

تعداد پرس‌وجوهایی که هر نخ به طور همزمان به آن‌ها خدمت‌رسانی می‌کند. اگر پرس‌وجوهای بیشتری برسند که نیازمند خدمت‌رسانی باشند و نتوان هیچ پرس‌وجویی را بیرون راند (jostle-timeout را ببینید)، پرس‌وجوها دور ریخته می‌شوند. این امر کلاینت را وادار می‌کند پس از اتمام مهلت دوباره ارسال کند؛ و به سرور زمان می‌دهد تا روی پرس‌وجوهای موجود کار کند. پیش‌فرض به گزینه‌های کامپایل بستگی دارد.

پیش‌فرض: 2048 (libevent) / 512 (minievent) / 24 (windows)

jostle-timeout: <msec>

مهلت زمانی مورد استفاده هنگامی که سرور بسیار شلوغ است. روی مقداری تنظیم کنید که معمولاً منجر به یک رفت و برگشت به سرورهای مجاز شود.

اگر پرس‌وجوهای بیش از حد زیادی برسند، 50% از پرس‌وجوها اجازه دارند تا پایان اجرا شوند، و 50% دیگر در صورتی که زمان مجاز خود را سپری کرده باشند با پرس‌وجوی ورودی جدید جایگزین می‌شوند. این کار در برابر محروم‌سازی از سرویس (DoS) توسط پرس‌وجوهای کند یا نرخ‌های بالای پرس‌وجو محافظت می‌کند.

تاثیر آن این است که qps برای پرس‌وجوهای طولانی‌مدت تقریباً عبارت است از:

(num-queries-per-thread / 2) / (average time for such long queries) qps

مقدار qps برای پرس‌وجوهای کوتاه می‌تواند تقریباً به این صورت باشد:

(num-queries-per-thread / 2) / (jostle-timeout in whole seconds) qps per thread

به طور پیش‌فرض حدود (2048/2)*5 = 5120 qps.

پیش‌فرض: 200

delay-close: <msec>

تاخیر اضافی برای درگاه‌های UDP منقضی‌شده پیش از بسته شدن آن‌ها، بر حسب میلی‌ثانیه. این امر از برخورد بسته‌های پاسخ بسیار تاخیردار از سرورهای بالادست (بازگشتی) به درگاه‌های بسته و فعال شدن انواع شمارنده‌های درگاه بسته جلوگیری می‌کند، برای نمونه با 1500 میلی‌ثانیه. هنگام وقوع انقضاها شما به سوکت‌های اضافی نیاز دارید؛ شناسه و IP راه دور بسته‌ها را بررسی می‌کند و بسته‌های ناخواسته به شمارنده بسته‌های ناخواسته اضافه می‌شوند.

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

udp-connect: <yes or no>

اجرای connect(2) برای سوکت‌های UDP که نشت کانال جانبی ICMP را کاهش می‌دهد.

پیش‌فرض: yes

unknown-server-time-limit: <msec>

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

پیش‌فرض: 376

discard-timeout: <msec>

زمان انتظار بر حسب میلی‌ثانیه که در آن درخواست‌های بازگشتی دور ریخته می‌شوند. این امر برای جلوگیری از تجمع تعداد زیادی پاسخ است. آن‌ها هیچ پاسخی دریافت نمی‌کنند و مورد کاری به بازگشت ادامه می‌دهد. برای UDP پاسخ‌ها دور ریخته می‌شوند، برای اتصالات جریانی اگر اتصال جریانی همچنان باز و آماده دریافت پاسخ‌ها باشد پاسخ دور ریخته نمی‌شود. خوب است که کمی بزرگ‌تر از serve-expired-client-timeout باشد در صورتی که آن گزینه فعال باشد. مقدار 1900 میلی‌ثانیه پیشنهاد می‌شود. مقدار 0 آن را غیرفعال می‌کند.

پیش‌فرض: 1900

wait-limit: <number>

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

پیش‌فرض: 1000

wait-limit-cookie: <number>

تعداد پاسخ‌هایی که می‌توانند برای یک آدرس IP که پرس‌وجو را همراه با یک کوکی DNS معتبر ارسال کرده است، در انتظار بازگشت بمانند. از آنجا که کوکی پیشاپیش آدرس کلاینت را اعتبارسنجی می‌کند، این گزینه اجازه می‌دهد مقدار پیکربندی‌شده wait-limit معمولاً با مقداری بالاتر برای پرس‌وجوهای اعتبارسنجی‌شده با کوکی بازنویسی شود. مقدار 0 محدودیت‌های انتظار را برای پرس‌وجوهای اعتبارسنجی‌شده با کوکی غیرفعال می‌کند.

پیش‌فرض: 10000

wait-limit-netblock: <netblock> <number>

محدودیت انتظار برای بلوک شبکه. اگر داده نشود از مقدار wait-limit استفاده می‌شود. خاص‌ترین بلوک شبکه برای تعیین محدودیت استفاده می‌شود. برای بازنویسی مقدار پیش‌فرض برای یک سرور خاص، گروهی یا انفرادی، مفید است. مقدار -1 محدودیت‌های انتظار را برای بلوک شبکه غیرفعال می‌کند. به‌طور پیش‌فرض رابط loopback دارای محدودیت انتظار بلوک شبکه -1 است، محدود نمی‌شود، زیرا برای بسته‌های جعلی از بقیه شبکه جدا شده است. آدرس‌های loopback شامل 127.0.0.0/8 و ::1/128 به‌طور پیش‌فرض روی -1 هستند.

پیش‌فرض: (هیچ‌کدام)

wait-limit-cookie-netblock: <netblock> <number>

محدودیت انتظار برای بلوک شبکه، هنگامی که پرس‌وجو حاوی کوکی DNS است. اگر داده نشود، از مقدار wait-limit-cookie استفاده می‌شود. مقدار -1 محدودیت‌های انتظار را برای بلوک شبکه غیرفعال می‌کند. آدرس‌های loopback شامل 127.0.0.0/8 و ::1/128 به‌طور پیش‌فرض روی -1 هستند.

پیش‌فرض: (هیچ‌کدام)

so-rcvbuf: <number>

اگر 0 نباشد، گزینه سوکت SO_RCVBUF را تنظیم می‌کند تا فضای بافر بیشتری روی درگاه 53 UDP برای پرس‌وجوهای ورودی دریافت شود. به طوری که جهش‌های ناگهانی و کوتاه‌مدت در سرورهای شلوغ بسته‌ها را دور نریزند (شمارنده را در netstat -su ببینید). در غیر این صورت، تعداد بایت‌هایی است که باید درخواست شود، روی یک سرور شلوغ مقدار "4m" را امتحان کنید.

سیستم‌عامل آن را روی یک حداکثر محدود می‌کند؛ در لینوکس Unbound برای دور زدن محدودیت به دسترسی ریشه (root) نیاز دارد، یا مدیر می‌تواند از sysctl net.core.rmem_max استفاده کند.

در BSD مقدار kern.ipc.maxsockbuf را در /etc/sysctl.conf تغییر دهید.

در OpenBSD هدر را تغییر داده و هسته را دوباره کامپایل کنید.

در Solaris دستور ndd -set /dev/udp udp_max_buf 8388608.

پیش‌فرض: 0 (استفاده از مقدار سیستم)

so-sndbuf: <number>

اگر 0 نباشد، گزینه سوکت SO_SNDBUF را تنظیم می‌کند تا فضای بافر بیشتری روی درگاه 53 UDP برای پاسخ‌های خروجی دریافت شود. این گزینه برای سرورهای بسیار شلوغ جهش‌های ناگهانی در ترافیک پاسخ را مدیریت می‌کند، در غیر این صورت:

send: resource temporarily unavailable

می‌تواند در لاگ ثبت شود، سرریز بافر همچنین از طریق netstat -su قابل مشاهده است. اگر روی 0 تنظیم شود از مقدار سیستم استفاده می‌کند. تعداد بایت‌های درخواستی را مشخص کنید، روی یک سرور بسیار شلوغ مقدار "8m" را امتحان کنید.

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

سیستم‌عامل آن را روی یک حداکثر محدود می‌کند؛ در لینوکس Unbound برای دور زدن محدودیت به دسترسی ریشه نیاز دارد، یا مدیر می‌تواند از sysctl net.core.wmem_max استفاده کند.

در BSD و Solaris تغییرات مشابه با so-rcvbuf است.

پیش‌فرض: 4m

so-reuseport: <yes or no>

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

در لینوکس در هسته‌های >= 3.9 پشتیبانی می‌شود.

در سایر سیستم‌ها، FreeBSD و OSX نیز ممکن است کار کند.

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

در بارهای بسیار شدید ممکن است خاموش کردن آن برای توزیع یکنواخت پرس‌وجوها بهتر باشد، همان‌طور که برای سیستم‌های لینوکس (4.4.x) گزارش شده است.

پیش‌فرض: yes

ip-transparent: <yes or no>

اگر yes باشد، از گزینه سوکت IP_TRANSPARENT روی سوکت‌هایی که Unbound روی آن‌ها به ترافیک ورودی گوش می‌دهد استفاده می‌کند. به شما اجازه می‌دهد به رابط‌های غیرمحلی متصل شوید (bind). برای نمونه برای آدرس‌های IP ناموجودی که قرار است بعداً وجود داشته باشند، در پیکربندی failover میزبان.

این گزینه بسیار شبیه به interface-automatic است، اما آن گزینه به تمام رابط‌ها خدمت‌رسانی می‌کند در حالی که با این گزینه می‌توانید انتخاب کنید Unbound روی کدام رابط‌ها (آینده) خدمات ارائه دهد.

این گزینه در برخی سیستم‌ها نیازمند راه‌اندازی Unbound با مجوزهای ریشه (root) است. این گزینه در سیستم‌های FreeBSD از IP_BINDANY و در سیستم‌های OpenBSD از SO_BINDANY استفاده می‌کند.

پیش‌فرض: no

ip-freebind: <yes or no>

اگر yes باشد، از گزینه سوکت IP_FREEBIND روی سوکت‌هایی که Unbound روی آن‌ها به ترافیک ورودی گوش می‌دهد استفاده می‌کند. به شما اجازه می‌دهد به آدرس‌های IP غیرمحلی یا ناموجود متصل شوید، مانند زمانی که رابط شبکه یا آدرس IP قطع است.

تنها در لینوکس وجود دارد، جایی که گزینه مشابه ip-transparent نیز در دسترس است.

پیش‌فرض: no

ip-dscp: <number>

مقدار کدپوینت خدمات تفکیک‌شده (DSCP) در فیلد خدمات تفکیک‌شده (DS) در هدر بسته‌های خروجی IP. این فیلد جایگزین فیلد منسوخ‌شده Type-Of-Service در IPv4 و فیلد رده ترافیک IPv6 می‌شود.

rrset-cache-size: <number>

تعداد بایت‌های اندازه کش RRset. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت).

پیش‌فرض: 4m

rrset-cache-slabs: <number>

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

پیش‌فرض: (پیکربندی‌نشده)

cache-max-ttl: <seconds>

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

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

cache-min-ttl: <seconds>

حداقل زمان بقا (TTL) برای RRsetها و پیام‌ها در کش. اگر حداقل اعمال شود، داده‌ها برای مدتی طولانی‌تر از آنچه مالک دامنه در نظر داشته کش می‌شوند، و بنابراین پرس‌وجوهای کمتری برای جستجوی داده‌ها انجام می‌شود. مقدار صفر اطمینان می‌دهد که داده‌های موجود در کش همانند نظر مالک دامنه است؛ مقادیر بالاتر، به‌ویژه بیش از حدود یک ساعت، می‌توانند دردسرساز شوند زیرا داده‌های موجود در کش دیگر با داده‌های واقعی مطابقت ندارند.

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

cache-max-negative-ttl: <seconds>

حداکثر زمان بقا برای پاسخ‌های منفی، این پاسخ‌ها دارای یک SOA در بخش مرجع هستند که از نظر زمانی محدود است. این گزینه روی پاسخ‌های NXDOMAIN و NODATA اعمال می‌شود.

پیش‌فرض: 3600

cache-min-negative-ttl: <seconds>

حداقل زمان بقا برای پاسخ‌های منفی، این پاسخ‌ها دارای یک SOA در بخش مرجع هستند که از نظر زمانی محدود است. اگر این گزینه غیرفعال باشد و cache-min-ttl پیکربندی شده باشد، به جای آن اثر خواهد گذاشت. در این صورت می‌توانید این مقدار را برای رعایت TTL بالادست روی 1 تنظیم کنید. این گزینه روی پاسخ‌های NXDOMAIN و NODATA اعمال می‌شود.

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

infra-host-ttl: <seconds>

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

پیش‌فرض: 900

infra-cache-slabs: <number>

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

پیش‌فرض: (پیکربندی‌نشده)

infra-cache-numhosts: <number>

تعداد میزبان‌هایی که اطلاعات آن‌ها کش می‌شود.

پیش‌فرض: 10000

infra-cache-min-rtt: <msec>

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

پیش‌فرض: 50

infra-cache-max-rtt: <msec>

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

پیش‌فرض: 120000 (2 دقیقه)

infra-keep-probing: <yes or no>

در صورت فعال بودن، سرور به بررسی میزبان‌هایی که قطع هستند در سازوکار یک پروب در هر زمان ادامه می‌دهد. میزبان‌هایی که قطع هستند، مثلاً در طول دوره یک پروب در هر زمان پاسخ نداده‌اند، به عنوان قطع علامت‌گذاری می‌شوند و ممکن است به اندازه زمان infra-host-ttl طول بکشد تا دوباره بررسی شوند.

پیش‌فرض: no

define-tag: "<list of tags>"

تعریف برچسب‌هایی که می‌توانند با local-zone و access-control استفاده شوند. فهرست را میان علامت‌های نقل‌قول ("") قرار دهید و میان برچسب‌ها فاصله بگذارید.

do-ip4: <yes or no>

پاسخ‌دهی یا ارسال پرس‌وجوهای IPv4 را فعال یا غیرفعال می‌کند.

پیش‌فرض: yes

do-ip6: <yes or no>

پاسخ‌دهی یا ارسال پرس‌وجوهای IPv6 را فعال یا غیرفعال می‌کند. در صورت غیرفعال بودن، به پرس‌وجوها روی IPv6 پاسخ داده نمی‌شود و پرس‌وجویی روی IPv6 به سرورهای نام اینترنت ارسال نمی‌گردد. با این گزینه می‌توانید انتقال IPv6 را برای ارسال ترافیک DNS غیرفعال کنید؛ این گزینه تأثیری بر محتوای ترافیک DNS که ممکن است حاوی آدرس‌های IPv4 (A) و IPv6 (AAAA) باشد ندارد.

پیش‌فرض: yes

prefer-ip4: <yes or no>

در صورت فعال بودن، پروتکل انتقال IPv4 را برای ارسال پرس‌وجوهای DNS به سرورهای نام اینترنت ترجیح می‌دهد. اگر بلوک شبکه IPv6 که سرور دارد، کل /64 آن متعلق به یک اپراتور نباشد و اعتبار بلوک شبکه /64 یک مسئله باشد مفید است، با استفاده از IPv4 فیلترهای IPv4 سرورهای بالادست اعمال می‌شوند.

پیش‌فرض: no

prefer-ip6: <yes or no>

در صورت فعال بودن، پروتکل انتقال IPv6 را برای ارسال پرس‌وجوهای DNS به سرورهای نام اینترنت ترجیح می‌دهد.

پیش‌فرض: no

do-udp: <yes or no>

پاسخ‌دهی یا ارسال پرس‌وجوهای UDP را فعال یا غیرفعال می‌کند.

پیش‌فرض: yes

do-tcp: <yes or no>

پاسخ‌دهی یا ارسال پرس‌وجوهای TCP را فعال یا غیرفعال می‌کند.

پیش‌فرض: yes

tcp-mss: <number>

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

outgoing-tcp-mss: <number>

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

tcp-idle-timeout: <msec>

مدت زمانی که Unbound روی یک اتصال TCP منتظر یک پرس‌وجو می‌ماند. اگر این مهلت منقضی شود، Unbound اتصال را می‌بندد. هنگامی که تعداد بافرهای آزاد ورودی TCP به زیر 50% کل تعداد پیکربندی‌شده سقوط کند، مقدار گزینه استفاده‌شده به صورت پلکانی کاهش می‌یابد؛ ابتدا به 1% مقدار پیکربندی‌شده، سپس در صورتی که بافرهای آزاد به زیر 35% کل تعداد سقوط کند به 0.2% مقدار پیکربندی‌شده، و در نهایت اگر بافرهای آزاد به زیر 20% سقوط کند به 0 کاهش می‌یابد. حداقل مهلت زمانی 200 میلی‌ثانیه صرف‌نظر از مقدار گزینه استفاده‌شده رعایت می‌شود. در صورت فعال بودن edns-tcp-keepalive، این مقدار توسط edns-tcp-keepalive-timeout بازنویسی می‌شود.

پیش‌فرض: 30000 (30 ثانیه)

tcp-reuse-timeout: <msec>

مدت زمانی که Unbound اتصالات پایدار TCP به سرورهای مرجع را باز نگه می‌دارد.

پیش‌فرض: 60000 (60 ثانیه)

max-reuse-tcp-queries: <number>

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

پیش‌فرض: 200

tcp-auth-query-timeout: <number>

مهلت زمانی بر حسب میلی‌ثانیه برای پرس‌وجوهای TCP به سرورهای مجاز (auth).

پیش‌فرض: 3000 (3 ثانیه)

edns-tcp-keepalive: <yes or no>

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

پیش‌فرض: no

edns-tcp-keepalive-timeout: <msec>

هنگامی که edns-tcp-keepalive فعال باشد، tcp-idle-timeout را بازنویسی می‌کند. اگر کلاینت از گزینه EDNS TCP Keepalive پشتیبانی کند، Unbound مقدار مهلت زمانی را به کلاینت می‌فرستد تا آن را ترغیب کند پیش از انقضای مهلت سرور، اتصال را ببندد.

پیش‌فرض: 120000 (2 دقیقه)

sock-queue-timeout: <sec>

پرس‌وجوهای UDP که برای مدت طولانی در بافر سوکت منتظر مانده‌اند می‌توانند دور ریخته شوند. زمان بر حسب ثانیه تنظیم می‌شود؛ مقدار 3 می‌تواند مقدار مناسبی برای نادیده گرفتن پرس‌وجوهای قدیمی باشد که احتمالاً کلاینت دیگر نیازی به پاسخ آن‌ها ندارد. این امر ممکن است زمانی رخ دهد که میزبان برای مدتی قادر به پاسخگویی به پرس‌وجوها نبوده باشد (یعنی Unbound در حال اجرا نبوده و سپس دوباره فعال شده است). از گزینه‌های سوکت برچسب زمانی استفاده می‌کند. گزینه سوکت روی پلتفرم‌های لینوکس و FreeBSD در دسترس است.

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

tcp-upstream: <yes or no>

استفاده صرف از TCP برای انتقال در پرس‌وجوهای بالادست را فعال یا غیرفعال می‌کند. در سناریوهای تونل‌زنی مفید است. اگر روی no تنظیم شود، می‌توانید انتقال TCP را تنها برای ناحیه‌های فوروارد یا خرد (stub) انتخابی به ترتیب با استفاده از forward-tcp-upstream یا stub-tcp-upstream مشخص کنید.

پیش‌فرض: no

udp-upstream-without-downstream: <yes or no>

پرس‌وجوی بالادست UDP را حتی اگر do-udp: no تنظیم شده باشد فعال می‌کند. برای ارائه‌دهندگان خدمات TLS که مایل به عدم دریافت UDP در پایین‌دست هستند اما از UDP برای واکشی داده‌ها در بالادست استفاده می‌کنند، مفید است.

پیش‌فرض: no (بدون تغییر)

tls-upstream: <yes or no>

استفاده صرف از TLS برای انتقال در پرس‌وجوهای بالادست را فعال یا غیرفعال می‌کند. در سناریوهای تونل‌زنی مفید است. ارتباط TLS حاوی DNS ساده در قالب سیمی TCP است. سرور دیگر باید از این مورد پشتیبانی کند (به tls-service-key مراجعه کنید).

اگر این گزینه را فعال کردید، همچنین یک tls-cert-bundle را پیکربندی کنید یا از tls-win-cert یا tls-system-cert برای بارگذاری گواهی‌های CA استفاده کنید، در غیر این صورت اتصالات نمی‌توانند احراز هویت شوند.

این گزینه TLS را برای همه آن‌ها فعال می‌کند، اما اگر این را تنظیم نکنید می‌توانید TLS را به‌طور خاص برای برخی از ناحیه‌های فوروارد با forward-tls-upstream پیکربندی کنید. و همچنین با stub-tls-upstream. اگر گزینه tls-upstream فعال باشد، برای تمام فورواردها و استاب‌ها اعمال می‌شود و گزینه‌های forward-tls-upstream و stub-tls-upstream نادیده گرفته می‌شوند، گویی که روی yes تنظیم شده بودند.

پیش‌فرض: no

ssl-upstream: <yes or no>

نحو جایگزین برای tls-upstream. اگر هر دو در پرونده پیکربندی وجود داشته باشند، آخرین مورد استفاده می‌شود.

tls-service-key: <file>

در صورت فعال بودن، سرور خدمات DNS-over-TLS یا DNS-over-HTTPS را روی درگاه‌های TCP که به طور ضمنی یا صریح با tls-port یا https-port برای این خدمات نشانه‌گذاری شده‌اند، ارائه می‌دهد. پرونده باید حاوی کلید خصوصی برای نشست TLS باشد، گواهی عمومی در پرونده tls-service-pem قرار دارد و در صورت مشخص شدن tls-service-key باید آن نیز مشخص شود. اگر کلید با مجوزهای ریشه یا خارج از chroot ذخیره شده باشد، تغییر، فعال‌سازی یا غیرفعال‌سازی نیازمند راه‌اندازی مجدد است (یک بارگذاری مجدد کافی نیست). اما اگر پرونده کلید (و پرونده tls-service-pem) در دسترس باشند، هنگام بارگذاری مجدد (reload) و بارگذاری سریع (fast_reload) خوانده می‌شوند. سرور زمان ویرایش پرونده (و نام پرونده) را بررسی می‌کند تا ببیند آیا پرونده برای بارگذاری مجدد تغییر کرده است یا خیر. درگاه‌هایی که به طور ضمنی یا صریح از طریق tls-port و https-port فعال شده‌اند، سرویس معمولی DNS TCP را ارائه نمی‌دهند.

NOTE:

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

ssl-service-key: <file>

نحو جایگزین برای tls-service-key.

tls-service-pem: <file>

پرونده pem گواهی کلید عمومی برای خدمات TLS.

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

ssl-service-pem: <file>

نحو جایگزین برای tls-service-pem.

tls-port: <number>

شماره درگاهی که روی آن خدمات TCP TLS ارائه می‌شود. تنها رابط‌هایی که با آن شماره درگاه به صورت @number پیکربندی شده‌اند خدمات TLS را دریافت می‌کنند.

پیش‌فرض: 853

ssl-port: <number>

نحو جایگزین برای tls-port.

tls-cert-bundle: <file>

اگر null یا "" باشد، هیچ پرونده‌ای استفاده نمی‌شود. آن را روی پرونده بسته گواهی تنظیم کنید، برای نمونه /etc/pki/tls/certs/ca-bundle.crt. این گواهی‌ها برای احراز هویت اتصالات برقرارشده با همتایان بیرونی استفاده می‌شوند. برای نمونه آدرس‌های auth-zone urls و همچنین اتصالات DNS-over-TLS. در زمان راه‌اندازی پیش از سلب مجوز و chroot خوانده می‌شود.

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

ssl-cert-bundle: <file>

نحو جایگزین برای tls-cert-bundle.

tls-win-cert: <yes or no>

گواهی‌های سیستم را برای احراز هویت به گواهی‌های بسته گواهی اضافه می‌کند. اگر بسته گواهی وجود نداشته باشد، تنها از این گواهی‌ها استفاده می‌کند. در ویندوز این گزینه از گواهی‌های موجود در مخزن گواهی استفاده می‌کند. در سایر سیستم‌ها از گزینه tls-cert-bundle استفاده کنید. در سایر سیستم‌ها، این گزینه گواهی‌های سیستم را فعال می‌کند.

پیش‌فرض: no

tls-system-cert: <yes or no>

این گزینه مشابه گزینه tls-win-cert با نامی متفاوت است. زیرا به ویندوز محدود نمی‌شود.

tls-additional-port: <portnr>

شماره‌های درگاه را به صورت tls-additional-port فهرست کنید؛ هنگامی که رابط‌ها مثلاً با پسوند @port به این شماره درگاه تعریف شوند، خدمات DNS-over-TLS را ارائه می‌دهند. می‌توان چندین مورد را، هر کدام در یک عبارت جداگانه، فهرست کرد.

tls-session-ticket-keys: <file>

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

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

dd if=/dev/random bs=1 count=80 of=ticket.dat

اگر کلید دوم ایجاد می‌کنید، 16 بایت نخست باید با کلید قدیمی متفاوت باشد؛ این نامی است که برای شناسایی کلید استفاده می‌شود. سپس 32 بایت داده تصادفی برای کلید AES و سپس 32 بایت داده تصادفی برای کلید HMAC قرار دارد.

پیش‌فرض: ""

tls-ciphers: <string with cipher list>

مجموعه رمزهای مجاز (ciphers) هنگام ارائه خدمات TLS را تنظیم می‌کند. برای رمزهای پیش‌فرض از "" استفاده کنید.

پیش‌فرض: ""

tls-ciphersuites: <string with ciphersuites list>

مجموعه سوییت‌های رمز مجاز (ciphersuites) هنگام ارائه خدمات TLS را تنظیم می‌کند. این گزینه برای اتصالات جدیدتر TLS 1.3 است. برای سوییت‌های رمز پیش‌فرض از "" استفاده کنید.

پیش‌فرض: ""

tls-use-sni: <yes or no>

ارسال پسوند SNI در اتصالات TLS را فعال یا غیرفعال می‌کند.

NOTE:

پیش‌فرض: yes

tls-protocols: "<list of protocols>"

نسخه‌های پروتکل مجاز TLS را بدون ترتیب خاصی مشخص می‌کند. مقادیر ممکن عبارتند از TLSv1.2 و TLSv1.3. فهرست پروتکل‌ها را میان علامت‌های نقل‌قول ("") قرار دهید و بین آن‌ها فاصله بگذارید.

NOTE:

پیش‌فرض: "TLSv1.2 TLSv1.3"

pad-responses: <yes or no>

در صورت فعال بودن، پرس‌وجوهای ارائه‌شده از طریق TLS که حاوی گزینه پدینگ EDNS بوده‌اند، باعث می‌شوند پاسخ‌ها تا نزدیک‌ترین مضرب اندازه مشخص‌شده در pad-responses-block-size پدگذاری شوند.

پیش‌فرض: yes

pad-responses-block-size: <number>

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

پیش‌فرض: 468

pad-queries: <yes or no>

در صورت فعال بودن، تمام پرس‌وجوهای ارسالی روی بالادست‌های TLS تا نزدیک‌ترین مضرب اندازه مشخص‌شده در pad-queries-block-size پدگذاری می‌شوند.

پیش‌فرض: yes

pad-queries-block-size: <number>

اندازه بلوکی که با آن پرس‌وجوهای ارسالی روی بالادست‌های TLS پدگذاری می‌شوند.

پیش‌فرض: 128

https-port: <number>

شماره درگاهی که روی آن خدمات DNS-over-HTTPS ارائه می‌شود. تنها رابط‌هایی که با آن شماره درگاه به عنوان @number پیکربندی شده‌اند خدمات HTTPS را دریافت می‌کنند.

پیش‌فرض: 443

http-endpoint: <endpoint string>

نقطه پایانی (endpoint) HTTP برای ارائه خدمات DNS-over-HTTPS روی آن.

پیش‌فرض: /dns-query

http-max-streams: <number of streams>

عددی که در پارامتر SETTINGS_MAX_CONCURRENT_STREAMS در فریم SETTINGS پروتکل HTTP/2 برای اتصالات DNS-over-HTTPS استفاده می‌شود.

پیش‌فرض: 100

http-query-buffer-size: <size in bytes>

حداکثر تعداد بایت‌های استفاده‌شده برای تمام بافرهای پرس‌وجوی HTTP/2 در مجموع. این بافرها حاوی پرس‌وجوهای DNS (جزئی) در انتظار تکمیل جریان درخواست هستند. یک فریم RST_STREAM به جریان‌هایی که از این حد فراتر روند ارسال خواهد شد. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت).

پیش‌فرض: 4m

http-response-buffer-size: <size in bytes>

حداکثر تعداد بایت‌های استفاده‌شده برای تمام بافرهای پاسخ HTTP/2 در مجموع. این بافرها حاوی پاسخ‌های DNS در انتظار بازنویسی به کلاینت‌ها هستند. یک فریم RST_STREAM به جریان‌هایی که از این حد فراتر روند ارسال خواهد شد. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت).

پیش‌فرض: 4m

http-nodelay: <yes or no>

گزینه سوکت TCP_NODELAY را روی سوکت‌های استفاده‌شده برای ارائه خدمات DNS-over-HTTPS تنظیم می‌کند. در صورت عدم دسترسی به این گزینه نادیده گرفته می‌شود.

پیش‌فرض: yes

http-notls-downstream: <yes or no>

استفاده از TLS را برای اتصالات DNS-over-HTTP در پایین‌دست غیرفعال می‌کند. برای سرورهای پشتیبان محلی (back end) مفید است.

پیش‌فرض: no

proxy-protocol-port: <portnr>

شماره‌های درگاه را به صورت proxy-protocol-port فهرست کنید؛ هنگامی که رابط‌ها مثلاً با پسوند @port به این شماره درگاه تعریف شوند، از PROXYv2 پشتیبانی کرده و انتظار آن را دارند.

در این حالت، آدرس پراکسی تنها برای ارتباط شبکه و ACL اولیه استفاده می‌شود (بررسی اینکه آیا خود پراکسی توسط پیکربندی رد/محروم شده است یا خیر).

سپس آدرس پراکسی‌شده (در صورت وجود) به عنوان آدرس واقعی کلاینت در نظر گرفته شده و در صورت لزوم برای ثبت لاگ، ACL، DNSTAP، RPZ و محدودیت نرخ IP استفاده خواهد شد.

پروتکل PROXYv2 برای رابط‌های شنود UDP و TCP/TLS پشتیبانی می‌شود.

روی رابط شنود DoH، DoQ یا DNSCrypt هیچ پشتیبانی از PROXYv2 وجود ندارد.

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

quic-port: <number>

شماره درگاهی که روی آن خدمات DNS-over-QUIC ارائه می‌شود. تنها رابط‌هایی که با آن شماره درگاه به عنوان @number پیکربندی شده‌اند خدمات QUIC را دریافت می‌کنند. رابط از QUIC برای ترافیک UDP روی آن شماره درگاه استفاده می‌کند. اگر روی 0 تنظیم شود، سرور کد QUIC را راه‌اندازی اولیه نمی‌کند و QUIC غیرفعال می‌شود. این مشابه وضعیتی است که QUIC در حال استفاده نباشد، اما به صورت صریح.

پیش‌فرض: 853

quic-size: <size in bytes>

حداکثر تعداد بایت‌ها برای تمام بافرها و داده‌های QUIC در مجموع. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت). هنگامی که از این حد فراتر رود، اتصالات جدید خطای اتصال رد شد (connection refused) دریافت می‌کنند. هنگامی که از این حد فراتر رود، جریان‌های جدید ریست می‌شوند.

پیش‌فرض: 8m

use-systemd: <yes or no>

فعال‌سازی سوکت systemd را فعال یا غیرفعال می‌کند.

پیش‌فرض: no

do-daemonize: <yes or no>

فورک شدن سرور Unbound به پس‌زمینه به عنوان یک دیمون را فعال یا غیرفعال می‌کند. هنگامی که Unbound به عنوان یک سرویس systemd اجرا می‌شود مقدار را روی no قرار دهید.

پیش‌فرض: yes

tcp-connection-limit: <IP netblock> <limit>

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

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

access-control: <IP netblock> <action>

نحوه برخورد با پرس‌وجوهای ورودی را بر اساس آدرس IP مبدأ آن‌ها مشخص می‌کند. پرس‌وجوها می‌توانند اجازه دسترسی به این سرور که پاسخ‌های DNS می‌دهد را داشته باشند، یا رد شوند، همراه با سایر اقدامات ممکن. محدوده آدرس IP می‌تواند به عنوان یک بلوک شبکه مشخص شود؛ امکان ارائه عبارت چندین بار برای تعیین نحوه برخورد با بلوک‌های شبکه مختلف وجود دارد. بلوک شبکه به صورت یک آدرس IPv4 یا IPv6 با size/ اضافه شده برای یک بلوک شبکه بدون کلاس داده می‌شود. خاص‌ترین تطابق بلوک شبکه استفاده می‌شود؛ اگر هیچ‌کدام مطابقت نداشته باشد از refuse استفاده می‌شود. بنابراین ترتیب عبارت‌های access-control اهمیتی ندارد. اقدام می‌تواند deny، refuse، allow، allow_setrd، allow_snoop، allow_cookie، deny_non_local یا refuse_non_local باشد.

به‌طور پیش‌فرض تنها localhost (بلوک شبکه IP 127.0.0.0/8، نه رابط loopback) به طور ضمنی مجاز است، بقیه رد می‌شوند. پیش‌فرض refused است، زیرا با پروتکل سازگارتر است. پروتکل DNS برای مدیریت بسته‌های دور ریخته‌شده به دلیل سیاست طراحی نشده است و دور انداختن ممکن است منجر به تلاش‌های مکرر (احتمالاً بیش از حد) برای پرس‌وجو شود.

access-control-tag: <IP netblock> "<list of tags>"

تخصیص برچسب‌ها به عناصر access-control. کلاینت‌هایی که از این عنصر کنترل دسترسی استفاده می‌کنند، از ناحیه‌های محلی برچسب‌گذاری‌شده با یکی از این برچسب‌ها استفاده خواهند کرد.

برچسب‌ها باید در define-tag تعریف شده باشند. فهرست برچسب‌ها را میان علامت‌های نقل‌قول ("") قرار دهید و میان برچسب‌ها فاصله بگذارید.

اگر access-control-tag برای یک بلوک شبکه که فاقد access-control است پیکربندی شود، یک عنصر کنترل دسترسی با اقدام allow برای این بلوک شبکه پیکربندی می‌گردد.

access-control-tag-action: <IP netblock> <tag> <action>

تنظیم اقدام برای برچسب خاص جهت عنصر کنترل دسترسی داده‌شده. اگر چندین مقدار برچسب داشته باشید، برچسب مورد استفاده برای جستجوی اقدام، اولین برچسب منطبق میان access-control-tag و local-zone-tag است که در آن «اولین» برگرفته از ترتیب مقادیر define-tag است.

access-control-tag-data: <IP netblock> <tag> "<resource record string>"

تنظیم داده‌های هدایت مجدد برای برچسب خاص جهت عنصر کنترل دسترسی داده‌شده.

access-control-view: <IP netblock> <view name>

تنظیم نما برای عنصر کنترل دسترسی داده‌شده.

interface-action: <ip address or interface name [@port]> <action>

مشابه access-control اما برای رابط‌ها.

اقدام همان مواردی است که ذیل access-control تعریف شده‌اند.

اقدام پیش‌فرض برای رابط‌ها refuse است. به طور پیش‌فرض تنها localhost (بلوک شبکه IP 127.0.0.0/8، نه رابط loopback) به صورت ضمنی از طریق رفتار پیش‌فرض access-control مجاز است. این همچنین بدان معنی است که هرگونه تلاش برای استفاده از گزینه‌های interface-*: برای رابط loopback کار نخواهد کرد زیرا توسط گزینه پیش‌فرض ضمنی "access-control: 127.0.0.0/8 allow" بازنویسی می‌شوند.

NOTE:

interface-tag: <ip address or interface name [@port]> <"list of tags">

مشابه access-control-tag اما برای رابط‌ها.

NOTE:

interface-tag-action: <ip address or interface name [@port]> <tag> <action>

مشابه access-control-tag-action اما برای رابط‌ها.

NOTE:

interface-tag-data: <ip address or interface name [@port]> <tag> <"resource record string">

مشابه access-control-tag-data اما برای رابط‌ها.

NOTE:

interface-view: <ip address or interface name [@port]> <view name>

مشابه access-control-view اما برای رابط‌ها.

NOTE:

chroot: <directory>

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

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

پرونده pidfile می‌تواند یک مسیر نسبی نسبت به دایرکتوری کاری باشد یا یک مسیر مطلق نسبت به ریشه اصلی. درست پیش از chroot و سلب مجوزها نوشته می‌شود. این به pidfile اجازه می‌دهد به عنوان مثال /var/run/unbound.pid باشد و chroot به عنوان مثال /var/unbound باشد. توجه داشته باشید که Unbound پس از خاتمه، قادر به حذف pidfile زمانی که خارج از دایرکتوری chroot قرار دارد نیست.

علاوه بر این، Unbound ممکن است نیاز به دسترسی به /dev/urandom (برای آنتروپی) از داخل chroot داشته باشد.

در صورت ارائه، یک chroot(2) به دایرکتوری داده‌شده انجام می‌شود. اگر "" بدهید، هیچ chroot(2) انجام نمی‌شود.

پیش‌فرض: /etc/unbound

username: <name>

در صورت ارائه، پس از مقیدسازی (bind) درگاه، امتیازات کاربر سلب می‌شود. اگر username: "" بدهید، هیچ تغییری در کاربر انجام نمی‌شود.

اگر این کاربر قادر به اتصال به درگاه نباشد، بارگذاری‌های مجدد (توسط سیگنال HUP) همچنان درگاه‌های بازشده را حفظ خواهند کرد. اگر شماره درگاه را در پرونده پیکربندی تغییر دهید و آن شماره درگاه جدید نیازمند امتیازات باشد، بارگذاری مجدد شکست خواهد خورد؛ یک راه‌اندازی مجدد لازم است.

پیش‌فرض: unbound

directory: <directory>

دایرکتوری کاری را برای برنامه تنظیم می‌کند. در ویندوز رشته "%EXECUTABLE%" تلاش می‌کند به دایرکتوری‌ای که unbound.exe در آن قرار دارد تغییر مسیر دهد. اگر یک server: directory: <directory> پیش از عبارت‌های پرونده include ارائه دهید، آن شمول‌ها می‌توانند نسبت به دایرکتوری کاری نسبی باشند.

پیش‌فرض: /etc/unbound

logfile: <filename>

اگر "" داده شود، ثبت لاگ به stderr یا پس از دیمون شدن به ناکجا می‌رود. به انتهای پرونده لاگ به قالب زیر افزوده می‌شود:

[seconds since 1970] unbound[pid:tid]: type: message.

اگر این گزینه داده شود، گزینه use-syslog در داخل به no تنظیم می‌شود.

پرونده لاگ هنگام بازخوانی پرونده پیکربندی با SIGHUP مجدداً (برای الحاق) باز می‌شود.

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

use-syslog: <yes or no>

تنظیم می‌کند که Unbound پیام‌های لاگ را با استفاده از syslog(3) به syslogd بفرستد. امکان لاگ LOG_DAEMON با هویت "unbound" استفاده می‌شود. هنگامی که use-syslog: yes تنظیم شود، تنظیم logfile بازنویسی می‌شود.

پیش‌فرض: yes

log-identity: <string>

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

پیش‌فرض: ""

log-time-ascii: <yes or no>

خطوط پرونده لاگ را تنظیم می‌کند تا از برچسب زمانی به صورت UTC ASCII استفاده کنند. در صورت استفاده از syslog تاثیری ندارد؛ در آن صورت syslog قالبی را که برچسب زمانی در پرونده‌های لاگ چاپ می‌شود تعیین می‌کند.

پیش‌فرض: no (ثانیه‌ها از سال 1970 را در قلاب چاپ می‌کند)

log-time-iso: <yes or no>

زمان لاگ در قالب ISO8601، در صورتی که log-time-ascii: yes نیز تنظیم شده باشد.

پیش‌فرض: no

log-queries: <yes or no>

یک خط به ازای هر پرس‌وجو به همراه برچسب زمانی لاگ و آدرس IP، نام، نوع و کلاس در لاگ چاپ می‌کند. توجه داشته باشید که چاپ این خطوط زمان‌بر است که باعث می‌شود سرور (به طور قابل توجهی) کندتر شود. کاراکترهای غیرمعمول (غیرقابل چاپ) در نام‌ها به صورت '?' چاپ می‌شوند.

پیش‌فرض: no

log-replies: <yes or no>

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

پیش‌فرض: no

log-tag-queryreply: <yes or no>

کلمات 'query' و 'reply' را همراه با log-queries و log-replies چاپ می‌کند. این کار پالایش لاگ‌ها را آسان‌تر می‌کند.

پیش‌فرض: no (سازگار با نسخه‌های پیشین)

log-destaddr: <yes or no>

آدرس مقصد، درگاه و نوع را در خروجی log-replies چاپ می‌کند. این کار ابهام‌زدایی می‌کند که چه نوع ترافیکی، برای نمونه UDP یا TCP، و به چه درگاه محلی ترافیک ارسال شده است.

پیش‌فرض: no

log-local-actions: <yes or no>

خطوط لاگ را برای اطلاع‌رسانی درباره اقدامات ناحیه محلی چاپ می‌کند. این خطوط شبیه به خروجی‌های local-zone type inform هستند، اما برای انواع دیگر ناحیه‌های محلی نیز چاپ می‌شوند.

پیش‌فرض: no

log-servfail: <yes or no>

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

پیش‌فرض: no

log-thread-id: <yes or no>

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

پیش‌فرض: no

pidfile: <filename>

شناسه فرایند در این پرونده نوشته می‌شود. پیش‌فرض "/run/unbound.pid" است. بنابراین:

kill -HUP `cat /run/unbound.pid`

باعث بارگذاری مجدد، و

kill -TERM `cat /run/unbound.pid`

به آرامی خاتمه می‌دهد.

پیش‌فرض: /run/unbound.pid

root-hints: <filename>

هینت‌های ریشه (root hints) را از این پرونده می‌خواند. پیش‌فرض هیچ‌چیز است، با استفاده از هینت‌های داخلی برای کلاس IN. پرونده دارای قالب پرونده‌های ناحیه است، تنها با نام‌ها و آدرس‌های سرور نام ریشه. هنگامی که سرورها تغییر کنند، ممکن است پیش‌فرض قدیمی شود و در آن صورت می‌توان از یک پرونده هینت‌های ریشه با سرورهای مشخص استفاده کرد.

پیش‌فرض: ""

hide-identity: <yes or no>

در صورت فعال بودن، پرس‌وجوهای 'id.server' و 'hostname.bind' رد می‌شوند (REFUSED).

پیش‌فرض: no

identity: <string>

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

پیش‌فرض: ""

hide-version: <yes or no>

در صورت فعال بودن، پرس‌وجوهای 'version.server' و 'version.bind' رد می‌شوند (REFUSED).

پیش‌فرض: no

version: <string>

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

پیش‌فرض: ""

hide-http-user-agent: <yes or no>

در صورت فعال بودن، هدر HTTP با عنوان User-Agent تنظیم نمی‌شود. با احتیاط استفاده کنید زیرا برخی پیکربندی‌های وب‌سرور ممکن است درخواست‌های HTTP فاقد این هدر را رد کنند. در صورت نیاز، بهتر است گزینه http-user-agent زیر را به طور صریح تنظیم کنید.

پیش‌فرض: no

http-user-agent: <string>

هدر HTTP User-Agent را برای درخواست‌های خروجی HTTP تنظیم می‌کند. اگر روی "" تنظیم شود، نام و نسخه بسته استفاده می‌شود.

پیش‌فرض: ""

nsid: <string>

هنگامی که پرس‌وجو با بسته‌ای فعال با NSID EDNS انجام شود، nsid مشخص‌شده را به بخش EDNS پاسخ اضافه می‌کند. به صورت دنباله‌ای از کاراکترهای هگزادسیمال یا با پیشوند 'ascii_' و سپس یک رشته ASCII.

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

hide-trustanchor: <yes or no>

در صورت فعال بودن، پرس‌وجوهای 'trustanchor.unbound' رد می‌شوند (REFUSED).

پیش‌فرض: no

target-fetch-policy: <"list of numbers">

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

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

فهرست را میان علامت‌های نقل‌قول ("") قرار دهید و میان اعداد فاصله بگذارید. تنظیم همه روی صفر، "0 0 0 0 0" رفتاری نزدیک‌تر به BIND 9 ایجاد می‌کند، در حالی که تنظیم "-1 -1 -1 -1 -1" رفتاری نزدیک‌تر به BIND 8 فراهم می‌آورد.

پیش‌فرض: "3 2 1 0 0"

harden-short-bufsize: <yes or no>

اندازه‌های بسیار کوچک بافر EDNS از پرس‌وجوها نادیده گرفته می‌شوند.

پیش‌فرض: yes (بر اساس RFC 6891)

harden-large-queries: <yes or no>

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

پیش‌فرض: no

harden-glue: <yes or no>

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

پیش‌فرض: yes

harden-unverified-glue: <yes or no>

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

پیش‌فرض: no

harden-dnssec-stripped: <yes or no>

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

پیش‌فرض: yes

harden-below-nxdomain: <yes or no>

برگرفته از RFC 8020 (با عنوان "NXDOMAIN: There Really Is Nothing Underneath")، به پرس‌وجوهای مربوط به نامی زیر نام دیگری که از قبل مشخص شده NXDOMAIN است، پاسخ NXDOMAIN می‌دهد. استاندارد DNSSEC برای نام‌های غیرپایانی تهی پاسخ NOERROR را الزامی می‌کند، از این رو این کار امکان‌پذیر است. نرم‌افزارهای بسیار قدیمی ممکن است برای نام‌های غیرپایانی تهی (که معمولاً در جستجوهای معکوس آدرس IP رخ می‌دهند) NXDOMAIN برگردانند و بنابراین ممکن است با این گزینه ناسازگار باشند. برای تلاش جهت اجتناب از این مشکل، تنها از NXDOMAINهای امن با DNSSEC استفاده می‌شود، زیرا نرم‌افزارهای قدیمی فاقد DNSSEC هستند.

NOTE:

پیش‌فرض: yes

harden-referral-path: <yes or no>

مسیر ارجاع را با انجام پرس‌وجوهای اضافی برای داده‌های زیرساختی مقاوم‌سازی می‌کند. در صورت پیکربندی لنگرهای اعتماد و امضاشده بودن ناحیه‌ها، پاسخ‌ها را اعتبارسنجی می‌کند. این کار اعتبارسنجی DNSSEC را روی مجموعه‌های NS سرور نام و آدرس‌های سرور نام که در مسیر ارجاع به پاسخ با آن‌ها مواجه می‌شویم تحمیل می‌کند. پیش‌فرض off است، زیرا بر سرورهای مرجع بار وارد می‌کند، استاندارد RFC نیست، و به دلیل بار پرس‌وجوی اضافی ایجاد شده می‌تواند به مشکلات عملکرد منجر شود. گزینه‌ای آزمایشی است. اگر آن را فعال می‌کنید، افزودن اعداد بیشتر پس از target-fetch-policy را برای افزایش حداکثر عمق بررسی در نظر بگیرید.

پیش‌فرض: no

harden-algo-downgrade: <yes or no>

هنگامی که چندین الگوریتم در رکورد DS اعلام شده‌اند، در برابر تنزل رتبه الگوریتم مقاوم‌سازی می‌کند. این کار ابتدا با انتخاب قوی‌ترین نوع دایجست DS بر اساس RFC 4509 (Unbound بالاترین الگوریتم را قوی‌ترین می‌داند) و سپس انتظار حضور امضاها از تمام الگوریتم‌های امضای اعلام‌شده از DS(های) انتخاب‌شده کار می‌کند. اگر no باشد، به هر الگوریتم پشتیبانی‌شده واحدی اجازه می‌دهد ناحیه را اعتبارسنجی کند، حتی اگر سایر الگوریتم‌های اعلام‌شده شکسته باشند. استاندارد RFC 6840 حکم می‌کند که امضاکنندگان ناحیه باید ناحیه‌هایی امضاشده با تمام الگوریتم‌های اعلام‌شده تولید کنند، اما گاهی اوقات این کار را نمی‌کنند. همچنین RFC 6840 روشن می‌کند که این الزام برای اعتبارسنج‌ها نیست و اعتبارسنج‌ها باید هر مسیر معتبر واحدی را بپذیرند. بنابراین باید به صراحت ذکر شود که این گزینه RFC 6840 را برای اعتبارسنجی DNSSEC نقض می‌کند و فقط باید برای انجام آزمون کامل بودن امضا جهت کمک به عیب‌یابی استفاده شود.

WARNING:

پیش‌فرض: no

harden-unknown-additional: <yes or no>

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

پیش‌فرض: no

use-caps-for-id: <yes or no>

از بیت‌های تصادفی کدگذاری‌شده با 0x20 در پرس‌وجو برای ناکام گذاشتن تلاش‌های جعل استفاده می‌کند. این گزینه حروف کوچک و بزرگ نام‌های پرس‌وجوی ارسال‌شده به سرورهای مرجع را دستکاری کرده و بررسی می‌کند که آیا پاسخ هنوز حالت حروف درست را دارد یا خیر. این قابلیت یک پیاده‌سازی آزمایشی از پیش‌نویس dns-0x20 است.

پیش‌فرض: no

caps-exempt: <domain>

دامنه را معاف می‌کند تا پرس‌وجوهای دستکاری‌شده با caps-for-id را دریافت نکند. برای دامنه‌هایی که از 0x20 پشتیبانی نمی‌کنند و همچنین با عقب‌نشینی با شکست مواجه می‌شوند زیرا به ارسال پاسخ‌های متفاوت ادامه می‌دهند، مانند برخی از متعادل‌کننده‌های بار. می‌تواند چندین بار برای دامنه‌های مختلف داده شود.

caps-whitelist: <domain>

نحو جایگزین برای caps-exempt.

qname-minimisation: <yes or no>

حداقل مقدار اطلاعات را به سرورهای بالادست ارسال می‌کند تا حریم خصوصی را افزایش دهد. فقط حداقل برچسب‌های مورد نیاز از QNAME را ارسال کرده و در صورت امکان QTYPE را روی A تنظیم می‌کند. رویکرد با بهترین تلاش؛ هنگامی که بالادست با کد خطایی غیر از NOERROR پاسخ دهد، QNAME کامل و QTYPE اصلی ارسال خواهد شد، مگر در زمان دریافت NXDOMAIN از یک ناحیه امضاشده با DNSSEC.

پیش‌فرض: yes

qname-minimisation-strict: <yes or no>

کمینه‌سازی QNAME در حالت سخت‌گیرانه. به ارسال QNAME کامل به سرورهای نام بالقوه خراب عقب‌نشینی نمی‌کند. بسیاری از دامنه‌ها در صورت فعال بودن این گزینه قابل تفکیک نخواهند بود. تنها در صورتی استفاده کنید که می‌دانید چه می‌کنید. این گزینه تنها زمانی اثر دارد که qname-minimisation فعال باشد.

پیش‌فرض: no

aggressive-nsec: <yes or no>

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

پیش‌فرض: yes

private-address: <IP address or subnet>

آدرس‌های IPv4 یا IPv6 یا زیرشبکه‌های بدون کلاس را مشخص کنید. این‌ها آدرس‌هایی روی شبکه خصوصی شما هستند و اجازه ندارند برای نام‌های اینترنت عمومی بازگردانده شوند. هرگونه وقوع چنین آدرس‌هایی از پاسخ‌های DNS حذف می‌شود. علاوه بر این، اعتبارسنج DNSSEC ممکن است پاسخ‌ها را جعلی علامت‌گذاری کند. این کار در برابر آنچه بازپیوند DNS نامیده می‌شود محافظت می‌کند، جایی که مرورگر کاربر به یک پراکسی شبکه تبدیل می‌شود که امکان دسترسی از راه دور از طریق مرورگر به سایر بخش‌های شبکه خصوصی شما را فراهم می‌کند.

این گزینه رکوردهای منبع از انواع A، AAAA، SVCB و HTTPS را که با فیلتر مطابقت دارند حذف می‌کند. درون رکوردهای SVCB و HTTPS، پارامترهای svcparams از نوع ipv4hint و ipv6hint برای یافتن مطابقت بررسی می‌شوند.

به برخی نام‌ها می‌توان اجازه داد حاوی آدرس‌های خصوصی شما باشند؛ به‌طور پیش‌فرض تمام local-data که پیکربندی کرده‌اید مجاز است، و می‌توانید نام‌های اضافی را با استفاده از private-domain مشخص کنید. به طور پیش‌فرض هیچ آدرس خصوصی فعال نیست.

ما فعال‌سازی این مورد را برای فضای آدرس IP خصوصی RFC 1918 به صورت پیش‌فرض در نسخه‌های بعدی مد نظر داریم. این امر آدرس‌های خصوصی را برای 10.0.0.0/8، 172.16.0.0/12، 192.168.0.0/16، 169.254.0.0/16، fd00::/8 و fe80::/10 فعال می‌کند، زیرا استانداردهای RFC می‌گویند این آدرس‌ها نباید در اینترنت عمومی قابل مشاهده باشند.

فعال کردن 127.0.0.0/8 مانع بسیاری از لیست‌های مسدودسازی اسپم می‌شود زیرا آن‌ها از آن استفاده می‌کنند. افزودن ::ffff:0:0/96 از دور زدن فیلتر توسط آدرس‌های IPv6 نگاشت‌شده به IPv4 جلوگیری می‌کند.

private-domain: <domain name>

به این دامنه و تمام زیردامنه‌های آن اجازه می‌دهد حاوی آدرس‌های خصوصی باشند. چندین بار وارد کنید تا چندین نام دامنه مجاز به داشتن آدرس‌های خصوصی باشند.

پیش‌فرض: (هیچ‌کدام)

unwanted-reply-threshold: <number>

در صورت تنظیم، تعداد کل پاسخ‌های ناخواسته در هر نخ ردیابی می‌شود. هنگامی که به آستانه برسد، اقدامی دفاعی انجام شده و هشداری در لاگ چاپ می‌شود. اقدام دفاعی پاک کردن کش‌های rrset و پیام است، به امید اینکه هرگونه مسمومیت از بین برود. مقدار 10 میلیون پیشنهاد می‌شود.

مفید است که 0.0.0.0/8 و '::' را به فهرست do-not-query-address اضافه کنید. در غیر این صورت ممکن است از localhost پاسخ داده شوند، و مبدأ متفاوت پاسخی ناخواسته ایجاد کند که به طور غیرضروری شمارنده را بالا ببرد. گزینه do-not-query-localhost آن‌ها (زیرشبکه‌های صفر) را در صورت فعال بودن شامل می‌شود.

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

do-not-query-address: <IP address>

از آدرس IP داده‌شده پرس‌وجو نمی‌کند. می‌تواند IPv4 یا IPv6 باشد. برای نشان دادن یک بلوک شبکه تفویض‌شده بدون کلاس، num/ را اضافه کنید، برای مثال مانند 10.2.3.4/24 یا 2001::11/64.

پیش‌فرض: (هیچ‌کدام)

do-not-query-localhost: <yes or no>

اگر yes باشد، localhost به ورودی‌های do-not-query-address اضافه می‌شود، هم IPv6 ::1 و هم IPv4 127.0.0.1/8. اگر no باشد، می‌توان از localhost برای ارسال پرس‌وجوها استفاده کرد.

پیش‌فرض: yes

prefetch: <yes or no>

اگر yes باشد، اصابت‌های کش روی عناصر کش پیام که در 10 درصد پایانی مقدار TTL خود قرار دارند، یک پیش‌واکشی را برای به‌روز نگه داشتن کش آغاز می‌کنند. روشن کردن آن حدود 10 درصد ترافیک و بار بیشتری روی دستگاه ایجاد می‌کند، اما موارد محبوب از کش منقضی نمی‌شوند.

پیش‌فرض: no

prefetch-key: <yes or no>

اگر yes باشد، کلیدهای DNSKEY را زودتر در فرآیند اعتبارسنجی، هنگامی که با رکورد DS مواجه می‌شود، واکشی می‌کند. این کار تأخیر درخواست‌ها را کاهش می‌دهد. کمی از پردازنده بیشتری استفاده می‌کند. همچنین اگر کش روی 0 تنظیم شده باشد، فایده‌ای ندارد.

پیش‌فرض: no

deny-any: <yes or no>

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

پیش‌فرض: no

rrset-roundrobin: <yes or no>

اگر yes باشد، Unbound ترتیب RRSet را در پاسخ می‌چرخاند (عدد تصادفی برای سرعت و ایمنی نخ از شناسه پرس‌وجو گرفته می‌شود).

پیش‌فرض: yes

minimal-responses: <yes or no>

اگر yes باشد، Unbound بخش‌های مرجع/اضافی را هنگامی که آن بخش‌ها مورد نیاز نیستند در پیام‌های پاسخ درج نمی‌کند. این کار اندازه پاسخ را به طور چشمگیری کاهش می‌دهد و ممکن است از عقب‌نشینی به TCP برای برخی پاسخ‌ها جلوگیری کند که می‌تواند باعث افزایش اندک سرعت شود. پیش‌فرض yes است، اگرچه RFCهای پروتکل DNS این بخش‌ها را الزامی می‌دانند، و محتوای اضافی می‌تواند رفت‌وبرگشت‌ها را برای کلاینت‌هایی که از محتوای اضافی استفاده می‌کنند ذخیره کند. با این حال این بخش‌ها به ندرت توسط کلاینت‌ها استفاده می‌شوند. فعال کردن prefetch می‌تواند با تلاش برای تازه نگه داشتن آن محتوا در کش به نفع کلاینت‌هایی باشد که به محتوای اضافی نیاز دارند.

پیش‌فرض: yes

disable-dnssec-lame-check: <yes or no>

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

پیش‌فرض: no

module-config: "<module names>"

پیکربندی ماژول، فهرستی از نام‌های ماژول جداشده با فاصله، رشته را در علامت‌های نقل‌قول ("") قرار دهید. ماژول‌ها می‌توانند respip، validator یا iterator باشند (و احتمالاً موارد بیشتر، زیر را ببینید).

NOTE:

تنظیم این گزینه تنها روی "iterator" منجر به یک سرور بدون اعتبارسنجی می‌شود. تنظیم این گزینه روی "validator iterator" اعتبارسنجی DNSSEC را روشن می‌کند.

NOTE:

افزودن respip به ابتدا باعث می‌شود پردازش RPZ روی تمام پرس‌وجوها انجام شود.

بیشتر ماژول‌هایی که باید در اینجا فهرست شوند باید در ابتدای خط فهرست شوند.

ماژول subnetcache باید دقیقاً پیش از iterator فهرست شود.

ماژول python می‌تواند در جاهای مختلفی فهرست شود، در این صورت خروجی ماژولی را که دقیقاً پیش از آن قرار دارد پردازش می‌کند.

ماژول dynlib را می‌توان تقریباً در هر جایی فهرست کرد، این ماژول تنها یک پوشش بسیار نازک است که اجازه می‌دهد کتابخانه‌های پویا به جای آن اجرا شوند.

پیش‌فرض: "validator iterator"

trust-anchor-file: <filename>

پرونده حاوی کلیدهای مورد اعتماد برای اعتبارسنجی. هم ورودی‌های DS و هم ورودی‌های DNSKEY می‌توانند در پرونده ظاهر شوند. قالب پرونده همان قالب استاندارد پرونده ناحیه DNS است.

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

auto-trust-anchor-file: <filename>

پرونده حاوی لنگر اعتماد برای یک ناحیه، که با پروب‌های RFC 5011 ردیابی می‌شود. پروب‌ها چندین بار در ماه اجرا می‌شوند، بنابراین دستگاه باید به طور مکرر آنلاین باشد. پرونده اولیه می‌تواند پرونده‌ای با محتوای شرح داده شده در trust-anchor-file باشد. هنگام به‌روزرسانی لنگر اعتماد در پرونده نوشته می‌شود، بنابراین کاربر Unbound باید مجوز نوشتن داشته باشد. مجوز نوشتن روی پرونده، و همچنین روی دایرکتوری‌ای که پرونده در آن قرار دارد (برای ایجاد یک پرونده موقت، که برای مدیریت رویدادهای پر شدن سیستم‌فایل ضروری است)، همچنین باید در داخل chroot باشد (اگر استفاده شود).

پیش‌فرض: "" (بدون پرونده لنگر اعتماد خودکار)

trust-anchor: "<Resource Record>"

یک رکورد منبع DS یا DNSKEY برای کلیدی که باید برای اعتبارسنجی استفاده شود. می‌توان چندین ورودی را برای تعیین چندین کلید مورد اعتماد، علاوه بر trust-anchor-file مشخص کرد. رکورد منبع به همان قالبی که dig(1) یا drill(1) آن‌ها را چاپ می‌کنند، همان قالب پرونده ناحیه، وارد می‌شود. باید در یک خط واحد، با "" در اطراف آن باشد. یک TTL می‌تواند برای سهولت برش و چسباندن مشخص شود، اما نادیده گرفته می‌شود. یک کلاس می‌تواند مشخص شود، اما کلاس IN پیش‌فرض است.

پیش‌فرض: (هیچ‌کدام)

trusted-keys-file: <filename>

پرونده حاوی کلیدهای مورد اعتماد برای اعتبارسنجی. بیش از یک پرونده را با چندین ورودی، یک پرونده به ازای هر ورودی، مشخص کنید. مشابه trust-anchor-file است اما قالب پرونده متفاوتی دارد. قالب آن قالب سبک BIND-9 است، بندهای trusted-keys { name flag proto algo "key"; }; خوانده می‌شوند. امکان استفاده از کاراکترهای عمومی با این عبارت وجود دارد، کاراکتر عمومی در زمان شروع و هنگام بارگذاری مجدد بسط می‌یابد.

پیش‌فرض: "" (بدون پرونده کلیدهای مورد اعتماد)

trust-anchor-signaling: <yes or no>

ارسال پرس‌وجوی برچسب کلید RFC 8145 پس از آماده‌سازی لنگر اعتماد.

پیش‌فرض: yes

root-key-sentinel: <yes or no>

دیده‌بان لنگر اعتماد کلید ریشه.

پیش‌فرض: yes

domain-insecure: <domain name>

مقدار <domain name> را روی ناامن تنظیم می‌کند، زنجیره اعتماد DNSSEC به سمت <domain name> نادیده گرفته می‌شود. بنابراین یک لنگر اعتماد بالای نام دامنه نمی‌تواند با یک رکورد DS دامنه را امن کند؛ چنین رکورد DS نادیده گرفته می‌شود. می‌توان چندین بار برای تعیین چندین دامنه که طوری با آن‌ها برخورد می‌شود که گویی امضا نشده‌اند مشخص کرد. اگر لنگرهای اعتماد برای دامنه تنظیم کنید، آن‌ها این تنظیم را بازنویسی می‌کنند (و دامنه امن می‌شود).

این می‌تواند مفید باشد اگر می‌خواهید مطمئن شوید یک لنگر اعتماد برای جستجوهای بیرونی بر یک دامنه داخلی (امضانشده) تأثیر نمی‌گذارد. یک رکورد DS در خارج می‌تواند خطاهای اعتبارسنجی برای آن دامنه داخلی ایجاد کند.

پیش‌فرض: (هیچ‌کدام)

val-override-date: <rrsig-style date spec>

WARNING:

در صورت فعال بودن با ارائه تاریخی به سبک RRSIG، از آن تاریخ برای تأیید تاریخ‌های آغاز و انقضای RRSIG به جای تاریخ فعلی استفاده می‌شود. این را تنظیم نکنید مگر اینکه در حال اشکال‌زدایی آغاز و انقضای امضا باشید. مقدار 1- تاریخ را به کلی نادیده می‌گیرد، که برای برخی برنامه‌های خاص مفید است.

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

val-sig-skew-min: <seconds>

حداقل تعداد ثانیه‌های انحراف ساعت برای اعمال بر امضاهای اعتبارسنجی‌شده. مقداری برابر با 10% طول عمر امضا (انقضا - آغاز) استفاده می‌شود که توسط این تنظیم محدود می‌شود. پیش‌فرض 3600 (1 ساعت) است که تفاوت‌های ساعت تابستانی را پوشش می‌دهد. این مقدار را برای بررسی سخت‌گیرانه‌تر امضاهای کوتاه‌مدت کاهش دهید.

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

val-sig-skew-max: <seconds>

حداکثر تعداد ثانیه‌های انحراف ساعت برای اعمال بر امضاهای اعتبارسنجی‌شده. مقداری برابر با 10% طول عمر امضا (انقضا - آغاز) استفاده می‌شود که توسط این تنظیم محدود می‌شود. پیش‌فرض 86400 (24 ساعت) است که مشکلات تنظیم منطقه زمانی را در دامنه‌های پایدار پوشش می‌دهد. تنظیم بسیار پایین هر دو مقدار حداقل و حداکثر، مجاز بودن انحراف ساعت را غیرفعال می‌کند. تنظیم بسیار بالای هر دو مقدار حداقل و حداکثر باعث می‌شود اعتبارسنج برچسب‌های زمانی امضا را با سخت‌گیری کمتری بررسی کند.

پیش‌فرض: 86400 (24 ساعت)

val-max-restart: <number>

حداکثر دفعاتی که اعتبارسنج باید در صورت شکست اعتبارسنجی، اعتبارسنجی را با مرجع دیگری دوباره آغاز کند.

پیش‌فرض: 5

val-bogus-ttl: <seconds>

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

پیش‌فرض: 60

val-clean-additional: <yes or no>

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

پیش‌فرض: yes

val-log-level: <number>

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

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

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

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

val-permissive-mode: <yes or no>

به اعتبارسنج دستور می‌دهد پیام‌های جعلی را به عنوان نامشخص علامت‌گذاری کند. بررسی‌های امنیتی انجام می‌شوند، اما اگر نتیجه جعلی (شکست امنیتی) باشد، پاسخ مانند حالت معمول با SERVFAIL از کلاینت دریغ نمی‌شود. کلاینت داده‌های جعلی را دریافت می‌کند. برای پیام‌هایی که امن تشخیص داده می‌شوند، بیت AD در پاسخ‌ها تنظیم می‌شود. همچنین ثبت لاگ مانند اعتبارسنجی کامل انجام می‌شود.

پیش‌فرض: no

ignore-cd-flag: <yes or no>

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

پیش‌فرض: no

disable-edns-do: <yes or no>

فلگ EDNS DO را در درخواست‌های بالادست غیرفعال می‌کند. این کار اعتبارسنجی DNSSEC را برای کلاینت‌های Unbound مختل می‌کند. این امر منجر به این می‌شود که سرورهای نام بالادست رکوردهای DNSSEC را در پاسخ‌های خود نگنجانند و می‌تواند برای دستگاه‌هایی که قادر به مدیریت اطلاعات DNSSEC نیستند مفید باشد. هنگامی که این گزینه فعال باشد، کلاینت‌هایی که فلگ DO را تنظیم می‌کنند هیچ رکورد EDNS در پاسخ دریافت نمی‌کنند تا عدم پشتیبانی به آن‌ها نشان داده شود. اگر این گزینه فعال باشد اما Unbound از قبل برای اعتبارسنجی DNSSEC پیکربندی شده باشد (یعنی ماژول validator فعال باشد؛ پیش‌فرض)، این گزینه به طور ضمنی همراه با هشداری خاموش می‌شود تا اعتبارسنجی DNSSEC در Unbound مختل نگردد.

پیش‌فرض: no

serve-expired: <yes or no>

در صورت فعال بودن، Unbound تلاش می‌کند پاسخ‌های قدیمی را از کش با TTL برابر با serve-expired-reply-ttl در پاسخ ارائه دهد. به‌طور پیش‌فرض، پاسخ منقضی‌شده پس از آنکه تلاش برای تفکیک با خطا مواجه شد یا تفکیک بیش از serve-expired-client-timeout طول کشید استفاده خواهد شد.

پیش‌فرض: no

serve-expired-ttl: <seconds>

ارائه پاسخ‌های منقضی‌شده را به ثانیه‌های پیکربندی‌شده پس از انقضا محدود می‌کند. 0 محدودیت را غیرفعال می‌کند. این گزینه تنها زمانی اعمال می‌شود که serve-expired فعال باشد. مقدار پیشنهادی بر اساس RFC 8767 بین 86400 (1 روز) و 259200 (3 روز) است. پیش‌فرض 86400 است.

پیش‌فرض: 86400

serve-expired-ttl-reset: <yes or no>

تنظیم TTL رکوردهای منقضی‌شده روی مقدار serve-expired-ttl پس از یک تلاش ناموفق برای بازیابی رکورد از بالادست. این اطمینان می‌دهد که رکوردهای منقضی‌شده تا زمانی که پرس‌وجوهایی برای آن وجود داشته باشد ارائه خواهند شد.

پیش‌فرض: no

serve-expired-reply-ttl: <seconds>

مقدار TTL مورد استفاده هنگام پاسخ دادن با داده‌های منقضی‌شده. اگر serve-expired-client-timeout نیز استفاده شود، استفاده از مقدار 30 توصیه می‌شود (بر اساس RFC 8767).

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

پیش‌فرض: 30

serve-expired-client-timeout: <msec>

زمان بر حسب میلی‌ثانیه پیش از پاسخ دادن به کلاینت با داده‌های منقضی‌شده. این در واقع رفتار serve-stale را بر اساس آنچه در RFC 8767 مشخص شده فعال می‌کند که ابتدا سعی می‌کند پیش از پاسخ فوری با داده‌های منقضی‌شده، تفکیک را انجام دهد. تنظیم این مقدار روی 0 این رفتار را غیرفعال می‌کند و در عوض رکورد منقضی‌شده را بلافاصله پیش از تلاش برای نوسازی آن از طریق تفکیک، از کش ارائه می‌دهد.

پیش‌فرض: 1800

serve-original-ttl: <yes or no>

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

فعال کردن این قابلیت بر انقضای کش تأثیری ندارد، تنها TTL را که Unbound در پاسخ‌ها به پرس‌وجوها جاسازی می‌کند تغییر می‌دهد.

NOTE:

NOTE:

پیش‌فرض: no

val-nsec3-keysize-iterations: <"list of values">

فهرستی از مقادیر اندازه کلید و تعداد تکرار، جداشده با فاصله، احاطه‌شده با علامت‌های نقل‌قول. این حداکثر تعداد تکرار مجاز NSEC3 را پیش از اینکه یک پیام به جای انجام تکرارهای متعدد درهم‌سازی صرفاً ناامن علامت‌گذاری شود تعیین می‌کند. فهرست باید به ترتیب صعودی باشد و حداقل یک ورودی داشته باشد. اگر آن را روی "1024 65535" تنظیم کنید، هیچ محدودیتی برای مقادیر تکرار NSEC3 وجود نخواهد داشت.

NOTE:

پیش‌فرض: "1024 150 2048 150 4096 150"

zonemd-permissive-mode: <yes or no>

در صورت فعال بودن، شکست‌های تأیید ZONEMD تنها ثبت لاگ می‌شوند و باعث مسدود شدن ناحیه و بازگرداندن تنها servfail نمی‌شوند. برای آزمودن اینکه آیا کار می‌کند، یا اگر اپراتور فقط می‌خواهد بدون اختلال در سرویس از یک مشکل مطلع شود مفید است.

پیش‌فرض: no

add-holddown: <seconds>

به سازوکار پروب auto-trust-anchor-file برای به‌روزرسانی‌های اعتماد خودکار RFC 5011 دستور می‌دهد لنگرهای اعتماد جدید را تنها پس از اینکه برای این مدت قابل مشاهده بودند اضافه کند.

پیش‌فرض: 2592000 (30 روز بر اساس RFC)

del-holddown: <seconds>

به سازوکار پروب auto-trust-anchor-file برای به‌روزرسانی‌های اعتماد خودکار RFC 5011 دستور می‌دهد لنگرهای اعتماد باطل‌شده را پس از نگهداری در فهرست باطل‌شده برای این مدت حذف کند.

پیش‌فرض: 2592000 (30 روز بر اساس RFC)

keep-missing: <seconds>

به سازوکار پروب auto-trust-anchor-file برای به‌روزرسانی‌های اعتماد خودکار RFC 5011 دستور می‌دهد لنگرهای اعتماد مفقود را پس از دیده نشدن برای این مدت حذف کند. اگر ناحیه هدف اقدام به ابطال لنگر اعتماد نکند، این پرونده وضعیت را پاکسازی می‌کند، بنابراین باعث می‌شود سازوکار پروب خودکار با ناحیه‌هایی که تعویض‌های منظم (غیر 5011) انجام می‌دهند کار کند. مقدار 0 لنگرهای مفقود را بر اساس RFC حذف نمی‌کند.

پیش‌فرض: 31622400 (366 روز)

permit-small-holddown: <yes or no>

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

پیش‌فرض: no

key-cache-size: <number>

تعداد بایت‌های اندازه کش کلید. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت).

پیش‌فرض: 4m

key-cache-slabs: <number>

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

پیش‌فرض: (پیکربندی‌نشده)

neg-cache-size: <number>

تعداد بایت‌های اندازه کش منفی تهاجمی. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت).

پیش‌فرض: 1m

unblock-lan-zones: <yes or no>

در صورت فعال بودن، جستجوهای معکوس برای فضای آدرس خصوصی دیگر فیلتر نمی‌شوند. این به Unbound اجازه می‌دهد زمانی که به عنوان سرویس dns روی میزبانی اجرا می‌شود که برای آن خدمات ارائه می‌دهد، تمام پرس‌وجوها را برای بالادست 'lan' ارسال کند. هنگام فعال بودن، تنها ناحیه‌های معکوس localhost، 127.0.0.1 و معکوس ::1 با ناحیه‌های محلی پیش‌فرض پیکربندی می‌شوند. زمانی که Unbound به عنوان یک تحلیل‌کننده شبکه DNS (همراه با DHCP) برای گروهی از دستگاه‌ها اجرا می‌شود این گزینه را غیرفعال کنید، جایی که چنین جستجوهایی باید فیلتر شوند (سازگاری با RFC)؛ این کار همچنین از نشت احتمالی داده‌های مربوط به شبکه محلی به سرورهای DNS بالادست جلوگیری می‌کند.

پیش‌فرض: no

insecure-lan-zones: <yes or no>

در صورت فعال بودن، جستجوهای معکوس در فضای آدرس خصوصی اعتبارسنجی نمی‌شوند. این مورد معمولاً هر زمان که unblock-lan-zones استفاده می‌شود مورد نیاز است.

پیش‌فرض: no

local-zone: <zone> <type>

پیکربندی یک ناحیه محلی. نوع، پاسخی را که در صورت عدم تطابق از local-data باید داده شود تعیین می‌کند. انواع عبارتند از deny، refuse، static، transparent، redirect، nodefault، typetransparent، inform، inform_deny، inform_redirect، always_transparent، block_a، block_aaaa، block_a_wdata، block_aaaa_wdata، always_refuse، always_nxdomain، always_null، noview، و در زیر توضیح داده شده‌اند. پس از آن تنظیمات پیش‌فرض فهرست شده‌اند. از local-data برای وارد کردن داده‌ها به ناحیه محلی استفاده کنید. پاسخ‌ها برای ناحیه‌های محلی، پاسخ‌های معتبر DNS هستند. به‌طور پیش‌فرض ناحیه‌ها در کلاس IN هستند.

اگر به داده‌های مرجع پیچیده‌تر، همراه با ارجاعات، کاراکترهای عمومی، پشتیبانی CNAME/DNAME، یا سرویس مرجع DNSSEC نیاز دارید، یک stub-zone برای آن طبق جزئیات بخش ناحیه خرد در زیر راه‌اندازی کنید. از یک stub-zone می‌توان استفاده کرد تا unbound پرس‌وجوها را به سرور دیگری، یک سرور مرجع، برای واکشی اطلاعات بفرستد. با یک forward-zone، unbound پرس‌وجوها را به سروری که یک سرور بازگشتی است می‌فرستد تا اطلاعات را واکشی کند. با یک auth-zone می‌توان یک ناحیه را از پرونده بارگذاری کرد و استفاده نمود؛ می‌توان از آن مانند یک ناحیه محلی برای کاربران پایین‌دست استفاده کرد، یا می‌توان از اطلاعات auth-zone برای واکشی اطلاعات هنگام تفکیک استفاده نمود، گویی که یک سرور بالادست است. گزینه‌های forward-zone و auth-zone در بخش‌های مربوط به خود در زیر شرح داده شده‌اند. اگر می‌خواهید پالایش اطلاعاتی را که کاربران می‌توانند واکشی کنند انجام دهید، عبارت‌های local-zone و local-data این امکان را فراهم می‌کنند، اما همچنین قابلیت rpz را نیز می‌توان استفاده کرد که در بخش RPZ شرح داده شده است.

local-zone: "example.com." redirect
local-data: "example.com. A 127.0.0.1"

local-zone: "example.com." redirect
local-data: "example.com. CNAME www.example.org."

timestamp, unbound-pid, info: zonename inform IP@port queryname type class.

ناحیه‌های پیش‌فرض عبارتند از localhost، معکوس 127.0.0.1 و ::1، ناحیه‌های home.arpa، resolver.arpa، service.arpa، onion، test، invalid و ناحیه‌های AS112. ناحیه‌های AS112 ناحیه‌های معکوس DNS برای استفاده خصوصی و آدرس‌های IP رزروشده هستند که سرورهای روی اینترنت نمی‌توانند پاسخ‌های صحیحی برای آن‌ها ارائه دهند. آن‌ها به طور پیش‌فرض پیکربندی شده‌اند تا پاسخ‌های NXDOMAIN (بدون اطلاعات معکوس) ارائه دهند.

پیش‌فرض‌ها را می‌توان با تعیین local-zone خودتان با آن نام، یا استفاده از نوع nodefault خاموش کرد. در زیر فهرستی از محتویات ناحیه پیش‌فرض آورده شده است.

local-zone: "localhost." redirect
local-data: "localhost. 10800 IN NS localhost."
local-data: "localhost. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"
local-data: "localhost. 10800 IN A 127.0.0.1"
local-data: "localhost. 10800 IN AAAA ::1"

local-zone: "127.in-addr.arpa." static
local-data: "127.in-addr.arpa. 10800 IN NS localhost."
local-data: "127.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"
local-data: "1.0.0.127.in-addr.arpa. 10800 IN PTR localhost."

local-zone: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." static
local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN NS localhost."
local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"
local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN PTR localhost."

local-zone: "home.arpa." static
local-data: "home.arpa. 10800 IN NS localhost."
local-data: "home.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"

local-zone: "resolver.arpa." static
local-data: "resolver.arpa. 10800 IN NS localhost."
local-data: "resolver.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"

local-zone: "service.arpa." static
local-data: "service.arpa. 10800 IN NS localhost."
local-data: "service.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"

local-zone: "onion." static
local-data: "onion. 10800 IN NS localhost."
local-data: "onion. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"

local-zone: "test." static
local-data: "test. 10800 IN NS localhost."
local-data: "test. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"

local-zone: "invalid." static
local-data: "invalid. 10800 IN NS localhost."
local-data: "invalid. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"

local-zone: 8.B.D.0.1.0.0.2.ip6.arpa. nodefault

همچنین می‌توانید به طور انتخابی بخشی از ناحیه را با شفاف کردن آن بخش با استفاده از یک عبارت local-zone رفع انسداد کنید. این برای سایر ناحیه‌های پیش‌فرض نیز کار می‌کند.

local-data: "<resource record string>"

پیکربندی داده‌های محلی، که در پاسخ به پرس‌وجوهای مربوط به آن ارائه می‌شود. پرس‌وجو باید دقیقاً مطابقت داشته باشد مگر اینکه local-zone را به صورت redirect پیکربندی کنید. در صورت عدم تطابق دقیق، نوع local-zone پردازش بیشتر را تعیین می‌کند. اگر local-data پیکربندی شود که زیردامنه یک local-zone نباشد، یک transparent local-zone پیکربندی می‌شود. برای انواع رکورد مانند TXT، از نقل‌قول تکی استفاده کنید:

local-data: 'example. TXT "text"'

NOTE:

local-data-ptr: "IPaddr name"

پیکربندی کوته‌نوشت داده محلی برای یک رکورد PTR با آدرس معکوس‌شده IPv4 یا IPv6 و نام میزبان. برای مثال "192.0.2.4 www.example.com". مقدار TTL را می‌توان این‌گونه درج کرد: "2001:db8::4 7200 www.example.com"

local-zone-tag: <zone> <"list of tags">

تخصیص برچسب‌ها به ناحیه‌های محلی. ناحیه‌های محلی برچسب‌گذاری‌شده تنها زمانی اعمال خواهند شد که عنصر access-control استفاده‌شده دارای برچسب منطبق باشد. برچسب‌ها باید در define-tag تعریف شده باشند. فهرست برچسب‌ها را در علامت‌های نقل‌قول ("") قرار دهید و میان برچسب‌ها فاصله بگذارید. هنگامی که چندین برچسب وجود دارد، بررسی می‌کند که آیا اشتراک فهرست برچسب‌ها برای پرس‌وجو و local-zone-tag غیرخالی است یا خیر.

local-zone-override: <zone> <IP netblock> <type>

بازنویسی نوع ناحیه محلی برای پرس‌وجوها از آدرس‌های منطبق بر بلوک شبکه. صرف‌نظر از نوع پیکربندی‌شده برای ناحیه محلی (هم برچسب‌دار و هم بدون برچسب) و صرف‌نظر از نوع پیکربندی‌شده با استفاده از access-control-tag-action، از این نوع ناحیه محلی استفاده می‌کند.

response-ip: <IP-netblock> <action>

این گزینه نیازمند استفاده از ماژول respip است.

اگر آدرس IP در یک رکورد منبع AAAA یا A در بخش پاسخ یک جواب با بلوک شبکه IP مشخص‌شده مطابقت داشته باشد، اقدام مشخص‌شده اعمال خواهد شد. مقدار <action> عموماً دارای همان معنایی است که برای access-control-tag-action وجود دارد، اما برخی استثناها وجود دارد.

اقدامات برای response-ip با اقدامات برای local-zone متفاوت هستند زیرا در مورد اول شرایطی مانند «پرس‌وجو با آن مطابقت دارد اما داده محلی وجود ندارد» بی‌معنی است. به دلیل این تفاوت، معنای اقدامات response-ip به شرح زیر اصلاح یا ساده‌سازی شده است: اقدامات static، refuse، transparent، typetransparent و nodefault برای response-ip نامعتبر هستند. استفاده از هر یک از این‌ها باعث رد پیکربندی به عنوان معیوب خواهد شد. اقدام deny غیرمشروط است، یعنی همیشه منجر به دور انداختن پرس‌وجوی مربوطه می‌شود. نتیجه تفکیک پیش از اعمال اقدام deny همچنان کش می‌شود و می‌تواند برای پرس‌وجوهای دیگر استفاده شود.

response-ip-data: <IP-netblock> <"resource record string">

این گزینه نیازمند استفاده از ماژول respip است.

این گزینه داده‌های اقدام را برای response-ip مشخص می‌کند که اقدام آن هدایت مجدد بر اساس <"resource record string"> است. مقدار <"Resource record string"> مشابه مقدار access-control-tag-data است، اما باید از یکی از انواع AAAA، A یا CNAME باشد. اگر <IP-netblock> یک پیشوند IPv6/IPv4 باشد، رکورد باید به ترتیب AAAA/A باشد، مگر اینکه CNAME باشد (که می‌تواند برای هر دو نسخه بلوک شبکه IP استفاده شود). اگر CNAME باشد نباید بیش از یک response-ip-data برای همان <IP-netblock> وجود داشته باشد. همچنین بر اساس قوانین معمول رکوردهای CNAME، رکورد CNAME و سایر انواع رکورد نباید برای همان <IP-netblock> همزیستی داشته باشند. نام متنی دامنه برای CNAME لازم نیست به طور صریح با یک نقطه (".") پایان یابد؛ نام ریشه مبدأ آن نام فرض می‌شود.

response-ip-tag: <IP-netblock> <"list of tags">

این گزینه نیازمند استفاده از ماژول respip است.

تخصیص برچسب‌ها به <IP-netblock> پاسخ. اگر آدرس IP در یک رکورد منبع AAAA یا A در بخش پاسخ یک جواب با <IP-netblock> مشخص‌شده مطابقت داشته باشد، برچسب‌های مشخص‌شده به آدرس IP تخصیص می‌یابند. سپس، اگر یک access-control-tag برای کلاینت تعریف شده باشد و شامل یکی از برچسب‌های IP پاسخ باشد، access-control-tag-action مربوطه اعمال خواهد شد. قاعده تطابق برچسب همان قاعده‌ای است که برای access-control-tag و local-zone وجود دارد. برخلاف local-zone-tag، response-ip-tag می‌تواند برای یک <IP-netblock> تعریف شود حتی اگر هیچ response-ip برای آن بلوک شبکه تعریف نشده باشد. اگر چندین گزینه response-ip-tag برای یک <IP-netblock> در عبارات مختلف مشخص شوند، همه به جز اولی نادیده گرفته خواهند شد. با این حال، این به عنوان یک خطای پیکربندی پرچم‌گذاری نمی‌شود، اما نتیجه احتمالاً آن چیزی نیست که مد نظر بوده است.

اقدامات مشخص‌شده در یک access-control-tag-action که دارای برچسب منطبق با response-ip-tag است می‌توانند مواردی باشند که برای response-ip فهرست‌شده در بالا «نامعتبر» بودند، زیرا access-control-tag-action می‌تواند با ناحیه‌های محلی به اشتراک گذاشته شود. برای این اقدامات، اگر در مورد ناحیه‌های محلی بسته به وجود یا عدم وجود داده‌های محلی رفتار متفاوتی داشته باشند، رفتار برای response-ip-data عموماً منجر به NOERROR/NODATA به جای NXDOMAIN خواهد شد، زیرا داده‌های response-ip ذاتاً به نوع وابسته هستند و عدم وجود داده هیچ چیزی درباره وجود یا عدم وجود خود qname نشان نمی‌دهد. برای مثال اگر اقدام برچسب منطبق static باشد اما داده‌ای برای پیکربندی response-ip متناظر وجود نداشته باشد، نتیجه NOERROR/NODATA خواهد بود. تنها حالتی که NXDOMAIN بازگردانده می‌شود زمانی است که اقدام always_nxdomain اعمال شود.

ratelimit: <number or 0>

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

محدودیت نرخ بر حسب تعداد پرس‌وجوهای مجاز در ثانیه است. پرس‌وجوهای بیشتر با یک خطا (SERVFAIL) بازگردانده می‌شوند. پاسخ‌های کش‌شده توسط این تنظیم محدود نمی‌شوند.

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

هدف شمارش تعداد پرس‌وجوها به سمت سرورهای نام برای ناحیه و محدود نگه داشتن آن پرس‌وجوها است. هنگامی که تفویضی وجود دارد که نیازمند جستجوهای زیادی است، آن‌ها در شمارنده‌های مقصد، نام هدف، رکوردهای NS ثبت می‌شوند. زیرا آنجاست که پرس‌وجوهای جستجوی سرور نام ارسال می‌شوند. این کار از داشتن پرس‌وجوهای بسیار برای هدف، دامنه قربانی، جلوگیری می‌کند. با ratelimit-factor، برخی پرس‌وجوهای واقعی که به ناحیه هدف نیز ارسال می‌شوند می‌توانند فیلتر شده و عبور کنند، و سپس به کش وارد شوند، جایی که پاسخ‌های واقعی فرصت جمع‌آوری پیدا کرده و سرویس تا حدودی حفظ می‌شود.

NOTE:

پیش‌فرض: 0

ratelimit-size: <memory size>

اندازه ساختار داده‌ای را که در آن نرخ‌های جاری ردیابی می‌شوند مشخص کنید. بر حسب بایت یا از m (مگا)، k (کیلو)، g (گیگا) استفاده کنید. ساختار ratelimit کوچک است، بنابراین احتمالاً این ساختار داده نیازی به بزرگ بودن ندارد.

پیش‌فرض: 4m

ratelimit-slabs: <number>

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

پیش‌فرض: (پیکربندی‌نشده)

ratelimit-factor: <number>

مقدار پرس‌وجوهایی را که در صورت فراتر رفتن از حد باید محدود شوند تنظیم می‌کند. اگر روی 0 تنظیم شود، تمام پرس‌وجوها برای دامنه‌هایی که از حد فراتر رفته‌اند دور ریخته می‌شوند. اگر روی مقدار دیگری تنظیم شود، 1 در آن تعداد اجازه عبور و تکمیل را دارد. پیش‌فرض 10 است که به 1/10 ترافیک اجازه جریان عادی می‌دهد. این می‌تواند باعث شود پرس‌وجوهای عادی تکمیل شده (در صورت پرس‌وجوی مکرر) و وارد کش شوند، در حالی که جریان ترافیک را نیز با ضریب ارائه‌شده کاهش می‌دهد.

پیش‌فرض: 10

ratelimit-backoff: <yes or no>

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

پیش‌فرض: no

ratelimit-for-domain: <domain> <number qps or 0>

بازنویسی ratelimit سراسری برای یک نام دامنه با تطابق دقیق با عدد فهرست‌شده. می‌توانید این را برای هر تعداد نام مشخص کنید. برای مثال، برای یک دامنه سطح بالا ممکن است بخواهید محدودیت بالاتری نسبت به سایر نام‌ها داشته باشید. مقدار 0 محدودیت نرخ را برای آن دامنه غیرفعال می‌کند.

ratelimit-below-domain: <domain> <number qps or 0>

بازنویسی ratelimit سراسری برای یک نام دامنه که به این نام ختم می‌شود. می‌توانید این را چندین بار وارد کنید؛ در این صورت تنظیمات مختلف در بخش‌های مختلف فضای نام را شرح می‌دهد. نزدیک‌ترین پسوند منطبق برای تعیین حد qps استفاده می‌شود. نرخ برای نام دامنه با تطابق دقیق تغییر نمی‌کند، از ratelimit-for-domain برای تنظیم آن استفاده کنید؛ ممکن است بخواهید از تنظیمات متفاوتی برای یک دامنه سطح بالا و زیردامنه‌ها استفاده نمایید. مقدار 0 محدودیت نرخ را برای نام‌های دامنه‌ای که به این نام ختم می‌شوند غیرفعال می‌کند.

ip-ratelimit: <number or 0>

محدودسازی نرخ سراسری پرس‌وجوهای پذیرفته‌شده به ازای هر آدرس IP را فعال می‌کند. این گزینه در حال حاضر آزمایشی است. محدودیت نرخ بر حسب تعداد پرس‌وجوهای مجاز در ثانیه است. پرس‌وجوهای بیشتر به طور کامل دور ریخته می‌شوند و پاسخی (SERVFAIL یا غیره) دریافت نخواهند کرد. محدودسازی نرخ IP پیش از جستجو در کش رخ می‌دهد. این ممکن است برای کاهش حملات تقویت مفید باشد. کلاینت‌های دارای یک کوکی معتبر DNS از این محدودیت نرخ عبور خواهند کرد. اگر همچنان برای چنین کلاینت‌هایی به محدودیت نرخ نیاز باشد، می‌توان از ip-ratelimit-cookie در عوض استفاده کرد.

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

ip-ratelimit-cookie: <number or 0>

محدودسازی نرخ سراسری پرس‌وجوهای پذیرفته‌شده به ازای هر آدرس IP با یک کوکی معتبر DNS را فعال می‌کند. این گزینه در حال حاضر آزمایشی است. محدودیت نرخ بر حسب تعداد پرس‌وجوهای مجاز در ثانیه است. پرس‌وجوهای بیشتر به طور کامل دور ریخته می‌شوند و پاسخی (SERVFAIL یا غیره) دریافت نخواهند کرد. محدودسازی نرخ IP پیش از جستجو در کش رخ می‌دهد. این گزینه می‌تواند در ترکیب با allow_cookie مفید باشد، در تلاشی برای کاهش سایر حملات تقویت غیر از بازتاب‌های UDP (مانند حملاتی که خود Unbound را هدف قرار می‌دهند) که پیشاپیش با کوکی‌های DNS مدیریت می‌شوند. در صورت استفاده، پیشنهاد می‌شود مقدار بالاتر از ip-ratelimit باشد، برای نمونه ده‌برابر.

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

ip-ratelimit-size: <memory size>

اندازه ساختار داده‌ای را که در آن نرخ‌های جاری ردیابی می‌شوند مشخص کنید. بر حسب بایت یا از m (مگا)، k (کیلو)، g (گیگا) استفاده کنید. ساختار IP ratelimit کوچک است، بنابراین احتمالاً این ساختار داده نیازی به بزرگ بودن ندارد.

پیش‌فرض: 4m

ip-ratelimit-slabs: <number>

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

پیش‌فرض: (پیکربندی‌نشده)

ip-ratelimit-factor: <number>

مقدار پرس‌وجوهایی را که در صورت فراتر رفتن از حد باید محدود شوند تنظیم می‌کند. اگر روی 0 تنظیم شود، تمام پرس‌وجوها برای آدرس‌هایی که از حد فراتر رفته‌اند دور ریخته می‌شوند. اگر روی مقدار دیگری تنظیم شود، 1 در آن تعداد اجازه عبور و تکمیل را دارد. پیش‌فرض 10 است که به 1/10 ترافیک اجازه جریان عادی می‌دهد. این می‌تواند باعث شود پرس‌وجوهای عادی تکمیل شده (در صورت پرس‌وجوی مکرر) و وارد کش شوند، در حالی که جریان ترافیک را نیز با ضریب ارائه‌شده کاهش می‌دهد.

پیش‌فرض: 10

ip-ratelimit-backoff: <yes or no>

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

پیش‌فرض: no

outbound-msg-retry: <number>

تعداد تلاش‌های مجدد، به ازای هر سرور نام بالادست در یک تفویض، که Unbound در صورت دریافت پاسخ دورریختنی انجام خواهد داد. عدم دریافت پاسخ (انقضای مهلت) به شمارنده تلاش مجدد اضافه می‌شود. اگر از یک ناحیه forward/stub استفاده شود، این تعداد تلاش‌های مجدد به ازای هر سرور نام در ناحیه است.

پیش‌فرض: 5

max-sent-count: <number>

حد قطعی برای تعداد پرس‌وجوهای خروجی که Unbound هنگام تفکیک یک نام انجام خواهد داد، تا اطمینان حاصل شود مجموعه‌های بزرگ NS وارد حلقه نمی‌شوند. در صورت رسیدن به این حد منجر به SERVFAIL می‌شود. با راه‌اندازی مجدد پرس‌وجو (مانند CNAME) و ارجاعات ریست می‌شود.

پیش‌فرض: 32

max-query-restarts: <number>

حد قطعی برای تعداد دفعاتی که Unbound مجاز است پس از مواجهه با یک رکورد CNAME یک پرس‌وجو را دوباره آغاز کند. در صورت رسیدن به این حد منجر به SERVFAIL می‌شود. این روی رکوردهای زنجیره‌ای CNAME اعمال می‌شود اما نه رکوردهای پراکنده CNAME که ممکن است در طول تلاش تفکیک پرس‌وجو با آن‌ها مواجه شد. هنگامی که یک زنجیره CNAME به پایان می‌رسد، شمارنده‌ای که این حد را پیگیری می‌کند ریست می‌شود. تغییر این مقدار نیاز به احتیاط دارد زیرا می‌تواند اجازه دهد زنجیره‌های طولانی CNAME پذیرفته شوند، جایی که Unbound باید هر پیوند را به صورت جداگانه تأیید (تفکیک) کند.

پیش‌فرض: 11

iter-scrub-ns: <number>

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

پیش‌فرض: 20

iter-scrub-cname: <number>

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

پیش‌فرض: 11

iter-scrub-rrsig: <number>

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

پیش‌فرض: 8

max-global-quota: <number>

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

پیش‌فرض: 200

iter-scrub-promiscuous: <yes or no>

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

پیش‌فرض: yes

fast-server-permil: <number>

مشخص کنید از هر 1000 بار چند بار از مجموعه سریع‌ترین سرورها انتخاب شود. 0 قابلیت را خاموش می‌کند. مقدار 900 در 90 درصد مواقع از سریع‌ترین سرورها انتخاب می‌کند و برای زمان باقی‌مانده کاوش عادی سرورهای تصادفی را انجام می‌دهد. هنگامی که prefetch (یا serve-expired) فعال باشد، چنین پیش‌واکشی‌هایی سرعت داده نمی‌شوند، زیرا هیچ‌کس منتظر آن نیست و زمان مناسبی برای انجام کاوش سرورها فراهم می‌آورد. از گزینه fast-server-num می‌توان برای تعیین اندازه مجموعه سریع‌ترین سرورها استفاده کرد.

پیش‌فرض: 0

fast-server-num: <number>

تعداد سرورهایی را که باید برای انتخاب سریع سرور استفاده شوند تنظیم می‌کند. تنها از سریع‌ترین تعداد سرورهای مشخص‌شده با گزینه fast-server-permil استفاده کنید که این گزینه را روشن یا خاموش می‌کند.

پیش‌فرض: 3

answer-cookie: <yes or no>

در صورت فعال بودن، Unbound به درخواست‌های حاوی کوکی‌های DNS همان‌طور که در RFC 7873 و RFC 9018 مشخص شده پاسخ خواهد داد.

پیش‌فرض: no

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

راز سرور برای تولید کوکی DNS. برای تنظیم صریح برای سرورها در یک استقرار anycast که نیاز به اشتراک‌گذاری راز دارند تا کوکی‌های سرور یکدیگر را تأیید کنند مفید است. یک رشته هگزادسیمال نمونه عبارت است از "000102030405060708090a0b0c0d0e0f".

NOTE:

پیش‌فرض: راز تصادفی 128 بیتی تولیدشده در زمان راه‌اندازی

cookie-secret-file: <filename>

پرونده‌ای که رازهای استفاده‌شده در محاسبات کوکی DNS از آن خوانده می‌شوند. هنگامی که این پرونده وجود دارد، از رازهای درون آن استفاده می‌شود و راز مشخص‌شده توسط گزینه cookie-secret نادیده گرفته می‌شود. آن را با تعیین نام پرونده، مانند "/usr/local/etc/unbound_cookiesecrets.txt"، فعال کنید. محتوای این پرونده باید با دستورات add_cookie_secret، drop_cookie_secret و activate_cookie_secret در ابزار unbound-control(8) مدیریت شود. لطفاً آن صفحه راهنما را برای نحوه انجام تعویض امن راز کوکی ببینید.

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

edns-client-string: <IP netblock> <string>

یک گزینه EDNS0 حاوی رشته ASCII پیکربندی‌شده را در پرس‌وجوهایی با آدرس مقصد منطبق بر <IP netblock> پیکربندی‌شده می‌گنجاند. این گزینه پیکربندی می‌تواند چندین بار استفاده شود. خاص‌ترین تطابق استفاده خواهد شد.

edns-client-string-opcode: <opcode>

کد گزینه EDNS0 برای گزینه edns-client-string، از 0 تا 65535. مقداری از محدوده «رزرو شده برای محلی/آزمایشی» (65001-65534) باید استفاده شود.

پیش‌فرض: 65001

ede: <yes or no>

در صورت فعال بودن، Unbound با کدهای خطای گسترده DNS (RFC 8914) پاسخ خواهد داد. این EDEها اطلاعات اضافی را همراه با پاسخ، عمدتاً اما نه محدود به خطاهای DNS و DNSSEC، ارائه می‌دهند.

هنگامی که گزینه val-log-level نیز روی 2 تنظیم شده باشد، پاسخ‌های حاوی خطاهای گسترده DNS مربوط به شکست‌های DNSSEC همچنین شامل یک پیام متنی توصیفی درباره علت شکست خواهند بود.

پیش‌فرض: no

ede-serve-expired: <yes or no>

در صورت فعال بودن، Unbound یک خطای گسترده DNS (RFC 8914) با کد 3 - پاسخ کهنه را به عنوان گزینه EDNS0 به پاسخ منقضی‌شده پیوست می‌کند.

NOTE:

پیش‌فرض: no

dns-error-reporting: <yes or no>

در صورت فعال بودن، Unbound گزارش‌های خطای DNS (RFC 9567) را ارسال خواهد کرد. سرورهای نام باید پشتیبانی خود را با پیوست کردن گزینه EDNS0 با عنوان Report-Channel در پاسخ‌های خود با تعیین عامل گزارش‌دهی برای ناحیه اعلام کنند. هرگونه خطایی که در حین تفکیک با آن مواجه شود که منجر به تولید یک خطای گسترده DNS (RFC 8914) توسط Unbound شود، به عامل گزارش‌دهی ناحیه گزارش خواهد شد.

برای کارکرد این قابلیت نیازی به فعال بودن گزینه ede نیست.

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

پیش‌فرض: no

control-enable: <yes or no>

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

پیش‌فرض: no

control-interface: <IP address or interface name[@port] or path>

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

به‌طور پیش‌فرض روی localhost (127.0.0.1 و ::1) شنود می‌شود. از 0.0.0.0 و ::0 برای شنود روی تمام رابط‌ها استفاده کنید. اگر این را تغییر دهید و مجوزها سلب شده باشند، برای اعمال تغییر باید سرور را دوباره راه‌اندازی کنید.

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

control-port: <port number>

شماره درگاه برای شنود روی رابط‌های کنترلی IPv4 یا IPv6.

NOTE:

پیش‌فرض: 8953

control-use-cert: <yes or no>

برای control-interface در localhost می‌توانید استفاده از TLS را با تنظیم این گزینه روی "no" غیرفعال کنید. برای سوکت‌های محلی، TLS غیرفعال است و مقدار این گزینه نادیده گرفته می‌شود.

پیش‌فرض: yes

server-key-file: <private key file>

مسیر کلید خصوصی سرور. این پرونده توسط ابزار unbound-control-setup(8) تولید می‌شود. این پرونده توسط سرور Unbound استفاده می‌شود، اما توسط unbound-control(8) خیر.

پیش‌فرض: unbound_server.key

server-cert-file: <certificate file.pem>

مسیر گواهی خودامضاشده سرور. این پرونده توسط ابزار unbound-control-setup(8) تولید می‌شود. این پرونده توسط سرور Unbound و همچنین توسط unbound-control(8) استفاده می‌شود.

پیش‌فرض: unbound_server.pem

control-key-file: <private key file>

مسیر کلید خصوصی کلاینت کنترل. این پرونده توسط ابزار unbound-control-setup(8) تولید می‌شود. این پرونده توسط unbound-control(8) استفاده می‌شود.

پیش‌فرض: unbound_control.key

control-cert-file: <certificate file.pem>

مسیر گواهی کلاینت کنترل. این گواهی باید با گواهی سرور امضا شده باشد. این پرونده توسط ابزار unbound-control-setup(8) تولید می‌شود. این پرونده توسط unbound-control(8) استفاده می‌شود.

پیش‌فرض: unbound_control.pem

name: <domain name>

نام ناحیه خرد. این نام کامل دامنه ناحیه است.

stub-host: <domain name>

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

CAUTION:

برای استفاده از یک درگاه غیرپیش‌فرض برای ارتباط DNS، علامت '@' را همراه با شماره درگاه الحاق کنید.

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

اگر '@' و '#' را ترکیب کنید، '@' اول می‌آید. اگر تنها '#' استفاده شود درگاه پیش‌فرض همان tls-port پیکربندی‌شده است.

stub-addr: <IP address>

آدرس IP سرور نام ناحیه خرد. می‌تواند IPv4 یا IPv6 باشد.

برای استفاده از یک درگاه غیرپیش‌فرض برای ارتباط DNS، علامت '@' را همراه با شماره درگاه الحاق کنید.

اگر TLS فعال باشد، می‌توانید یک '#' و یک نام الحاق کنید، سپس گواهی‌های احراز هویت tls را با آن نام بررسی خواهد کرد.

اگر '@' و '#' را ترکیب کنید، '@' اول می‌آید. اگر تنها '#' استفاده شود درگاه پیش‌فرض همان tls-port پیکربندی‌شده است.

stub-prime: <yes or no>

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

پیش‌فرض: no

stub-first: <yes or no>

در صورت فعال بودن، در صورت شکست، یک پرس‌وجو بدون این بخش stub امتحان می‌شود. داده‌ها قابل بازیابی نبودند و باعث SERVFAIL می‌شدند زیرا سرورها غیرقابل دسترس هستند، در عوض بدون این بخش stub تلاش می‌شود. این می‌تواند منجر به استفاده از ناحیه‌های forward/stub/auth پیکربندی‌شده با عمومیت بیشتر در صورت وجود شود، یا در غیر این صورت به تفکیک بازگشتی عادی برای آن پرس‌وجوی خاص ختم شود.

پیش‌فرض: no

stub-tls-upstream: <yes or no>

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

پیش‌فرض: no

stub-ssl-upstream: <yes or no>

نحو جایگزین برای stub-tls-upstream.

stub-tcp-upstream: <yes or no>

اگر روی "yes" تنظیم شود، پرس‌وجوهای بالادست بدون در نظر گرفتن فلگ سراسری tcp-upstream تنها از TCP برای انتقال استفاده می‌کنند.

پیش‌فرض: no

stub-no-cache: <yes or no>

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

پیش‌فرض: no

name: <domain name>

نام ناحیه فوروارد. این نام کامل دامنه ناحیه است.

forward-host: <domain name>

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

CAUTION:

برای استفاده از یک درگاه غیرپیش‌فرض برای ارتباط DNS، علامت '@' را همراه با شماره درگاه الحاق کنید.

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

اگر '@' و '#' را ترکیب کنید، '@' اول می‌آید. اگر تنها '#' استفاده شود درگاه پیش‌فرض همان tls-port پیکربندی‌شده است.

forward-addr: <IP address>

آدرس IP سرور برای فوروارد به آن. می‌تواند IPv4 یا IPv6 باشد.

برای استفاده از یک درگاه غیرپیش‌فرض برای ارتباط DNS، علامت '@' را همراه با شماره درگاه الحاق کنید.

اگر TLS فعال باشد، می‌توانید یک '#' و یک نام الحاق کنید، سپس گواهی‌های احراز هویت tls را با آن نام بررسی خواهد کرد.

اگر '@' و '#' را ترکیب کنید، '@' اول می‌آید. اگر تنها '#' استفاده شود درگاه پیش‌فرض همان tls-port پیکربندی‌شده است.

در سطح پرگویی بالا، گواهی TLS را با TLS فعال در لاگ ثبت می‌کند. اگر '#' و نام احراز هویت را از forward-addr حذف کنید، هر نامی پذیرفته می‌شود. گواهی همچنین باید با یک CA از tls-cert-bundle مطابقت داشته باشد.

forward-first: <yes or no>

اگر یک پرس‌وجوی فورواردشده با خطای SERVFAIL مواجه شود و این گزینه فعال باشد، Unbound به تفکیک با عمومیت بیشتر عقب‌نشینی می‌کند. این می‌تواند منجر به استفاده از ناحیه‌های forward/stub/auth پیکربندی‌شده با عمومیت بیشتر در صورت وجود شود، یا در غیر این صورت به تفکیک بازگشتی عادی برای آن پرس‌وجوی خاص ختم گردد.

پیش‌فرض: no

forward-tls-upstream: <yes or no>

استفاده از TLS را برای انتقال در پرس‌وجوها به این فورواردر فعال یا غیرفعال می‌کند. اگر این را فعال کردید، همچنین یک tls-cert-bundle را پیکربندی کنید یا از tls-win-cert برای بارگذاری گواهی‌های CA استفاده کنید، در غیر این صورت اتصالات نمی‌توانند احراز هویت شوند.

پیش‌فرض: no

forward-ssl-upstream: <yes or no>

نحو جایگزین برای forward-tls-upstream.

forward-tcp-upstream: <yes or no>

اگر روی "yes" تنظیم شود، پرس‌وجوهای بالادست بدون در نظر گرفتن فلگ سراسری tcp-upstream تنها از TCP برای انتقال استفاده می‌کنند.

پیش‌فرض: no

forward-no-cache: <yes or no>

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

پیش‌فرض: no

name: <zone name>

نام ناحیه مرجع.

primary: <IP address or host name>

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

برای استفاده از یک درگاه غیرپیش‌فرض برای ارتباط DNS، علامت '@' را همراه با شماره درگاه الحاق کنید.

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

اگر '@' و '#' را ترکیب کنید، '@' اول می‌آید. اگر آن را به یک نمونه دیگر Unbound نشانه روید، کار نخواهد کرد زیرا از AXFR/IXFR برای ناحیه پشتیبانی نمی‌کند، اما اگر از url برای دانلود zonefile به عنوان یک پرونده متنی از یک وب‌سرور استفاده کنید کار خواهد کرد.

CAUTION:

master: <IP address or host name>

نحو جایگزین برای primary.

url: <URL to zone file>

محل دانلود یک پرونده ناحیه برای ناحیه. با HTTP یا HTTPS. یک نمونه برای url:

می‌توان چندین عبارت url داد، آن‌ها به نوبت امتحان می‌شوند.

اگر فقط urlها داده شوند از تایمر تازه‌سازی SOA برای انتظار جهت انجام دانلودهای جدید استفاده می‌شود. اگر سرورهای اصلی نیز فهرست شده باشند، سرورهای اصلی ابتدا با پرس‌وجوهای UDP SOA بررسی می‌شوند تا مشخص شود آیا شماره سریال SOA تغییر کرده است یا خیر، که تعداد دانلودها را کاهش می‌دهد. اگر هیچ‌یک از urlها کار نکنند، سرورهای اصلی با IXFR و AXFR امتحان می‌شوند.

برای HTTPS، از tls-cert-bundle و نام میزبان برگرفته از url برای احراز هویت اتصال استفاده می‌شود.

اگر یک نام میزبان در URL مشخص کنید، نمی‌توانید از دامنه موجود در zonefile استفاده کنید، زیرا ممکن است هنگام بازیابی آن داده‌ها آن را نداشته باشد؛ در عوض از یک آدرس IP ساده برای اجتناب از وابستگی دوری در بازیابی آن آدرس IP استفاده کنید.

با استفاده از نگارشی مانند "http://192.0.2.1/unbound-primaries/example.com.zone" با یک آدرس IP صریح، از وابستگی به جستجوهای نام خودداری کنید.

allow-notify: <IP address or host name or netblockIP/prefix>

با allow-notify می‌توانید منابع اضافی اعلام‌ها را مشخص کنید. هنگام دریافت اعلام، سرور ابتدا تلاش می‌کند پروب انجام دهد و سپس انتقال ناحیه را اجرا کند. اگر اعلام از یک سرور اصلی باشد، ابتدا آن سرور اصلی را امتحان می‌کند. در غیر این صورت سرورهای اصلی دیگر امتحان می‌شوند. اگر هیچ سرور اصلی وجود نداشته باشد، اما فقط urlها باشند، پرونده هنگام دریافت اعلام دانلود می‌شود.

NOTE:

fallback-enabled: <yes or no>

در صورت فعال بودن، Unbound در زمان شکست جستجوها به پرس‌وجو از اینترنت به عنوان یک تحلیل‌کننده برای این ناحیه عقب‌نشینی می‌کند. برای مثال برای شکست‌های اعتبارسنجی DNSSEC.

پیش‌فرض: no

for-downstream: <yes or no>

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

اگر می‌خواهید Unbound بازگشت را برای ناحیه فراهم کند اما رونوشت محلی از داده‌های ناحیه داشته باشد، آن را خاموش کنید.

اگر for-downstream: no و for-upstream: yes تنظیم شوند، Unbound محتویات ناحیه را پیش از ارائه محتویات ناحیه به کلاینت‌ها با DNSSEC اعتبارسنجی کرده و نتایج اعتبارسنجی را در کش ذخیره می‌کند.

پیش‌فرض: yes

for-upstream: <yes or no>

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

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

پیش‌فرض: yes

zonemd-check: <yes or no>

این گزینه را برای بررسی رکوردهای ZONEMD در ناحیه فعال کنید. رکورد ZONEMD یک چکسام روی داده‌های ناحیه است. این شامل داده‌های glue در ناحیه و داده‌های پرونده ناحیه می‌شود و توضیحات پرونده ناحیه را شامل نمی‌شود. هنگامی که زنجیره اعتماد DNSSEC وجود دارد، امضاهای DNSSEC نیز بررسی می‌شوند.

پیش‌فرض: no

zonemd-reject-absence: <yes or no>

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

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

اقدام پس از شکست توسط گزینه zonemd-permissive-mode کنترل می‌شود، فقط برای ثبت لاگ یا مسدود کردن ناحیه نیز.

بدون این گزینه، عدم وجود یک ZONEMD تنها زمانی یک شکست تلقی می‌شود که ناحیه با DNSSEC امضا شده باشد، و ما یک لنگر اعتماد داشته باشیم، و تأیید DNSSEC مبنی بر عدم وجود ZONEMD با شکست مواجه شود. با فعال بودن این گزینه، عدم وجود ZONEMD همیشه یک شکست است، همچنین برای ناحیه‌های امضانشده با DNSSEC.

پیش‌فرض: no

zonefile: <filename>

نام پرونده‌ای که ناحیه در آن ذخیره می‌شود. اگر داده نشود هیچ پرونده ناحیه‌ای استفاده نمی‌شود. اگر پرونده وجود نداشته باشد یا خالی باشد، Unbound تلاش خواهد کرد داده‌های ناحیه را واکشی کند (مثلاً از سرورهای اصلی).

max-transfer-size: <number>

تعداد بایت‌های اندازه حداکثر انتقال ناحیه. انتقال‌های بزرگ‌تر، روی AXFR، IXFR و HTTP مجاز نیستند. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت). مقدار 0 این قابلیت را غیرفعال می‌کند.

تنها برای سرورهای اصلی غیرقابل اعتماد/بدرفتار که می‌توانند منابع را غصب کرده و تحلیل‌کننده را از کار بیندازند مد نظر قرار دهید.

پیش‌فرض: 0

max-transfer-time: <msec>

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

تنها برای سرورهای اصلی غیرقابل اعتماد/بدرفتار که می‌توانند منابع را غصب کرده و تحلیل‌کننده را از کار بیندازند مد نظر قرار دهید.

پیش‌فرض: 0

name: <view name>

نام نما. باید یکتا باشد. این نام در گزینه access-control-view استفاده می‌شود.

local-zone: <zone> <type>

عناصر ناحیه محلی ویژه نما. دارای همان انواع و رفتارهای عناصر local-zone سراسری است. هنگامی که حداقل یک local-zone: مشخص شده باشد و view-first: no تنظیم شده باشد، ناحیه‌های محلی پیش‌فرض به این نما اضافه خواهند شد. پیش‌فرض‌ها را می‌توان با استفاده از نوع nodefault غیرفعال کرد. هنگامی که view-first: yes تنظیم شده باشد یا زمانی که یک نما فاقد local-zone باشد، از local-zone سراسری شامل ناحیه‌های پیش‌فرض آن استفاده خواهد شد.

local-data: "<resource record string>"

عناصر داده محلی ویژه نما. دارای همان رفتار عناصر local-data سراسری است.

local-data-ptr: "IPaddr name"

عناصر local-data-ptr ویژه نما. دارای همان رفتار عناصر local-data-ptr سراسری است.

response-ip: <IP-netblock> <action>

این گزینه نیازمند استفاده از ماژول respip است.

مشابه response-ip اما تنها روی این نما اعمال می‌شود.

response-ip-data: <IP-netblock> <"resource record string">

این گزینه نیازمند استفاده از ماژول respip است.

مشابه response-ip-data اما تنها روی این نما اعمال می‌شود.

view-first: <yes or no>

در صورت فعال بودن، در صورتی که تطابقی در گزینه‌های ویژه نما وجود نداشته باشد، تلاش می‌کند از local-zone و local-data سراسری استفاده کند.

پیش‌فرض: no

python-script: <python file>

پرونده اسکریپت برای بارگذاری. این گزینه را برای هر نمونه ماژول پایتون اضافه‌شده به گزینه module-config تکرار کنید.

dynlib-file: <dynlib file>

پرونده کتابخانه پویا برای بارگذاری. این گزینه را برای هر نمونه ماژول dynlib اضافه‌شده به گزینه module-config تکرار کنید.

dns64-prefix: <IPv6 prefix>

پیشوند DNS64 مورد استفاده برای سنتز رکوردهای AAAA را تنظیم می‌کند. باید 96/ یا کوتاه‌تر باشد.

پیش‌فرض: 64:ff9b::/96

dns64-synthall: <yes or no>

WARNING:

در صورت فعال بودن، تمام رکوردهای AAAA را با وجود حضور رکوردهای واقعی AAAA سنتز می‌کند.

پیش‌فرض: no

dns64-ignore-aaaa: <domain name>

دامنه‌ای را فهرست می‌کند که رکوردهای AAAA آن نادیده گرفته شده و رکورد A توسط پردازش DNS64 در عوض استفاده می‌شود. می‌تواند چندین بار وارد شود، یک دامنه جدید که روی آن اعمال می‌شود، یک دامنه در هر خط. همچنین روی نام‌های زیر نام داده‌شده اعمال می‌شود.

do-nat64: <yes or no>

از NAT64 برای دسترسی به سرورهای فقط IPv4 استفاده می‌کند. همچنین فعال کردن prefer-ip6 را برای ترجیح اتصالات بومی IPv6 به سرورهای نام در نظر بگیرید.

پیش‌فرض: no

nat64-prefix: <IPv6 prefix>

استفاده از یک پیشوند مشخص NAT64 برای دسترسی به سرورهای فقط IPv4. طول پیشوند باید یکی از مقادیر 32/، 40/، 48/، 56/، 64/ یا 96/ باشد.

پیشوند NAT64 توسط گزینه do-not-query-address مجاز دانسته می‌شود، به طوری که نتیجه مشخصی از آدرس‌ها در هر دو وجود داشته باشد؛ پیشوند NAT64 مجاز است. آدرس IPv4 در صورت نیاز می‌تواند توسط گزینه do-not-query-address فیلتر شود. مجاز شمردن پیشوند NAT64 هنگام استفاده از do-not-query-address برای خوشه‌ای از ماشین‌ها که فقط IPv6 هستند و از NAT64 استفاده می‌کنند اما دسترسی به اینترنت ندارند مفید است.

پیش‌فرض: 64:ff9b::/96 (مشابه dns64-prefix)

dnscrypt-enable: <yes or no>

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

پیش‌فرض: no

dnscrypt-port: <port number>

dnscrypt روی کدام درگاه باید فعال شود.

NOTE:

dnscrypt-provider: <provider name>

نام ارائه‌دهنده مورد استفاده برای توزیع گواهی‌ها. به این صورت است:

2.dnscrypt-cert.example.com.

IMPORTANT:

dnscrypt-secret-key: <path to secret key file>

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

dnscrypt-provider-cert: <path to cert file>

مسیر گواهی مربوط به dnscrypt-secret-key. این گزینه می‌تواند چندین بار مشخص شود.

dnscrypt-provider-cert-rotated: <path to cert file>

مسیر گواهی‌ای که باید بتوانیم اتصال موجود را از آن ارائه دهیم اما نمی‌خواهیم از طریق توزیع گواهی‌های رکورد TXT ارائه‌دهنده dnscrypt-provider اعلام کنیم.

یک مورد کاربرد متداول هنگام چرخش گواهی‌ها است، کلاینت‌های موجود ممکن است همچنان از client magic گواهی قدیمی در پرس‌وجوهای خود استفاده کنند تا زمانی که گواهی جدید را واکشی و به‌روزرسانی نمایند. به همین ترتیب، به فرد اجازه می‌دهد گواهی/کلید جدید را بدون توزیع گواهی جدید آماده کند؛ این می‌تواند هنگام استفاده از شبکه‌ای از سرورها با anycast که در آن‌ها پیکربندی ممکن است در یک زمان دقیقاً یکسان به‌روزرسانی نشود، مفید باشد.

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

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

dnscrypt-shared-secret-cache-size: <memory size>

اندازه ساختار داده‌ای که کلیدهای مخفی مشترک در آن نگهداری می‌شوند را مشخص می‌کند. بر حسب بایت یا استفاده از m (مگا)، k (کیلو)، g (گیگا). کش کلید مخفی مشترک زمانی استفاده می‌شود که یک کلاینت یکسان چندین پرس‌وجو را با استفاده از یک کلید عمومی یکسان انجام می‌دهد. مقدار قابل توجهی از پردازنده را ذخیره می‌کند.

پیش‌فرض: 4m

dnscrypt-shared-secret-cache-slabs: <number>

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

پیش‌فرض: (پیکربندی‌نشده)

dnscrypt-nonce-cache-size: <memory size>

اندازه ساختار داده‌ای که نانس‌های کلاینت در آن نگهداری می‌شوند را مشخص می‌کند. بر حسب بایت یا استفاده از m (مگا)، k (کیلو)، g (گیگا). کش نانس برای جلوگیری از بازپخش پیام‌های dnscrypt استفاده می‌شود. نانس کلاینت برای هر جفت کلید عمومی کلاینت/کلید خصوصی سرور باید منحصر‌به‌فرد باشد.

پیش‌فرض: 4m

dnscrypt-nonce-cache-slabs: <number>

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

پیش‌فرض: (پیکربندی‌نشده)

send-client-subnet: <IP address>

ارسال آدرس مبدأ کلاینت به این مرجع. برای نشان دادن یک بلوک شبکه واگذاری بدون کلاس، num/ را الحاق کنید، به عنوان مثال مانند 10.2.3.4/24 یا 2001::11/64. می‌تواند چندین بار مشخص شود. مراجع فهرست‌نشده اطلاعات edns-subnet را دریافت نخواهند کرد، مگر اینکه دامنه موجود در پرس‌وجو در client-subnet-zone مشخص شده باشد.

client-subnet-zone: <domain>

ارسال آدرس مبدأ کلاینت در پرس‌وجوها برای این دامنه و زیردامنه‌های آن. می‌تواند چندین بار مشخص شود. ناحیه‌های فهرست‌نشده اطلاعات edns-subnet را دریافت نخواهند کرد، مگر اینکه توسط مرجع مشخص‌شده در send-client-subnet میزبانی شوند.

client-subnet-always-forward: <yes or no>

مشخص می‌کند که آیا بررسی آدرس ECS (پیکربندی‌شده با استفاده از send-client-subnet) برای تمام پرس‌وجوها اعمال شود، حتی اگر پرس‌وجوی محرک حاوی یک رکورد ECS باشد، یا تنها برای پرس‌وجوهایی که رکورد ECS برای آن‌ها با استفاده از آدرس پرسشگر تولید شده است (و بنابراین حاوی داده‌های ECS در پرس‌وجوی کلاینت نبوده است). در صورت فعال بودن، زمانی که پرس‌وجوی کلاینت حاوی یک رکورد ECS باشد از بررسی آدرس صرف‌نظر می‌شود. و جستجو در کش معمولی نادیده گرفته می‌شود.

پیش‌فرض: no

max-client-subnet-ipv6: <number>

حداکثر طول پیشوند آدرس مبدأ کلاینت که مایل به افشای آن برای اشخاص ثالث در IPv6 هستیم را مشخص می‌کند.

پیش‌فرض: 56

max-client-subnet-ipv4: <number>

حداکثر طول پیشوند آدرس مبدأ کلاینت که مایل به افشای آن برای اشخاص ثالث در IPv4 هستیم را مشخص می‌کند.

پیش‌فرض: 24

min-client-subnet-ipv6: <number>

حداقل طول پیشوند ماسک مبدأ IPv6 که مایل به پذیرش آن در پرس‌وجوها هستیم را مشخص می‌کند. ماسک‌های مبدأ کوتاه‌تر منجر به پاسخ‌های REFUSED می‌شوند. ماسک مبدأ 0 همیشه پذیرفته می‌شود.

پیش‌فرض: 0

min-client-subnet-ipv4: <number>

حداقل طول پیشوند ماسک مبدأ IPv4 که مایل به پذیرش آن در پرس‌وجوها هستیم را مشخص می‌کند. ماسک‌های مبدأ کوتاه‌تر منجر به پاسخ‌های REFUSED می‌شوند. ماسک مبدأ 0 همیشه پذیرفته می‌شود.

پیش‌فرض: 0

max-ecs-tree-size-ipv4: <number>

حداکثر تعداد پاسخ‌های ECS زیرشبکه‌ها که در درخت رادیکس ECS نگهداری می‌شوند را مشخص می‌کند. این عدد برای هر چندتایی qname/qclass/qtype اعمال می‌شود.

پیش‌فرض: 100

max-ecs-tree-size-ipv6: <number>

حداکثر تعداد پاسخ‌های ECS زیرشبکه‌ها که در درخت رادیکس ECS نگهداری می‌شوند را مشخص می‌کند. این عدد برای هر چندتایی qname/qclass/qtype اعمال می‌شود.

پیش‌فرض: 100

QNAME

نام دامنه پرس‌وجوی A/AAAA و IPSECKEY. در قالب رشته.

IPSECKEY TTL

مقدار TTL مجموعه رکورد IPSECKEY.

A/AAAA

رشته‌ای از آدرس‌های IP جداشده با فاصله موجود در مجموعه رکورد A/AAAA. آدرس‌های IP در قالب رشته هستند.

IPSECKEY

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

ipsecmod-enabled: <yes or no>

مشخص می‌کند که آیا ماژول IPsec فعال است یا خیر. ماژول IPsec همچنان باید در دستورالعمل module-config تعریف شود. این گزینه روشن/خاموش کردن ماژول را بدون راه‌اندازی مجدد/بارگذاری مجدد Unbound تسهیل می‌کند.

پیش‌فرض: yes

ipsecmod-hook: <filename>

قلاب خارجی را مشخص می‌کند که Unbound با system(3) فراخوانی خواهد کرد. پرونده می‌تواند به عنوان یک مسیر مطلق/نسبی مشخص شود. پرونده برای اینکه بتواند توسط همان کاربری که Unbound را اجرا می‌کند اجرا شود به مجوزهای مناسب نیاز دارد. زمانی که ماژول IPsec در دستورالعمل module-config تعریف شده باشد باید وجود داشته باشد.

ipsecmod-strict: <yes or no>

در صورت فعال بودن، Unbound نیازمند آن است که قلاب خارجی مقدار موفقیت 0 را برگرداند. در صورت عدم موفقیت، Unbound با SERVFAIL پاسخ خواهد داد. پاسخ A/AAAA نیز کش نخواهد شد.

پیش‌فرض: no

ipsecmod-max-ttl: <seconds>

حداکثر زمان بقا برای رکوردهای کش‌شده A/AAAA پس از فراخوانی قلاب خارجی.

پیش‌فرض: 3600

ipsecmod-ignore-bogus: <yes or no>

رفتار Unbound را هنگامی که پاسخ IPSECKEY جعلی است مشخص می‌کند. اگر روی yes تنظیم شود، قلاب فراخوانی می‌شود و پاسخ A/AAAA به کلاینت بازگردانده خواهد شد. اگر روی no تنظیم شود، قلاب فراخوانی نمی‌شود و پاسخ به پرس‌وجوی A/AAAA خطای SERVFAIL خواهد بود. عمدتاً برای آزمایش استفاده می‌شود.

پیش‌فرض: no

ipsecmod-allow: <domain>

قابلیت ماژول IPsec را برای دامنه مجاز می‌کند تا منطق ماژول اجرا شود. می‌تواند چندین بار، برای دامنه‌های مختلف مشخص شود. اگر گزینه مشخص نشود، با تمام دامنه‌ها به عنوان مجاز برخورد می‌شود (پیش‌فرض).

ipsecmod-whitelist: <domain>

نحو جایگزین برای ipsecmod-allow.

backend: <backend name>

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

پیش‌فرض: testframe

secret-seed: "<secret string>"

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

پیش‌فرض: "default"

cachedb-no-store: <yes or no>

اگر باید از بک‌اند خوانده شود، اما در آن نوشته نشود. این باعث می‌شود این نمونه پیام‌های dns را در بک‌اند ذخیره نکند. اما اگر داده در دسترس باشد بازیابی می‌شود.

پیش‌فرض: no

cachedb-check-when-serve-expired: <yes or no>

در صورت فعال بودن، پایگاه‌داده cachedb پیش از بازگرداندن پاسخ منقضی‌شده بررسی می‌شود. هنگامی که serve-expired بدون serve-expired-client-timeout فعال باشد، بلافاصله با یک پاسخ منقضی‌شده از کش پاسخ نمی‌دهد، بلکه ابتدا cachedb را برای محتویات معتبر بررسی می‌کند و در این صورت آن را برمی‌گرداند. اگر cachedb نیز محتوای معتبری نداشته باشد، پاسخ منقضی‌شده ارسال می‌شود. اگر serve-expired-client-timeout نیز فعال باشد، پاسخ منقضی‌شده تا زمان به پایان رسیدن مهلت زمانی به تأخیر می‌افتد. مگر اینکه جستجو در طول مهلت زمانی به نتیجه برسد.

پیش‌فرض: yes

redis-server-host: <server address or name>

آدرس IP (چه v6 یا v4) یا نام دامنه سرور Redis. به طور کلی یک آدرس IP باید مشخص شود زیرا در غیر این صورت Unbound باید هر بار که اتصالی به سرور برقرار می‌کند نام سرور را تفکیک نماید.

پیش‌فرض: 127.0.0.1

redis-server-port: <port number>

شماره درگاه TCP سرور Redis.

پیش‌فرض: 6379

redis-server-path: <unix socket path>

مسیر سوکت یونیکس برای اتصال به سرور Redis. سوکت‌های یونیکس ممکن است بازدهی بهتری نسبت به گزینه آدرس IP داشته باشند.

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

redis-server-password: "<password>"

گذرواژه AUTH ردیس برای استفاده در سرور Redis. تنها در صورتی مرتبط است که Redis برای مجوز گذرواژه کلاینت پیکربندی شده باشد.

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

redis-timeout: <msec>

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

پیش‌فرض: 100

redis-command-timeout: <msec>

مهلت زمانی برای دستورات Redis، بر حسب میلی‌ثانیه. اگر 0 باشد، از مقدار redis-timeout استفاده می‌کند.

پیش‌فرض: 0

redis-connect-timeout: <msec>

مهلت زمانی برای راه‌اندازی اتصال Redis، بر حسب میلی‌ثانیه. اگر 0 باشد، از مقدار redis-timeout استفاده می‌کند.

پیش‌فرض: 0

redis-expire-records: <yes or no>

آیا انقضای رکوردهای Redis فعال است یا خیر. در صورت انتخاب yes، سرور Unbound مهلت زمانی را برای رکوردهای Redis تنظیم می‌کند تا Redis بتواند کلیدهایی را که منقضی شده‌اند به طور خودکار تخلیه کند. اگر Unbound با serve-expired و serve-expired-ttl: 0 پیکربندی شده باشد، این گزینه در داخل به "no" بازگردانده می‌شود.

NOTE:

پیش‌فرض: no

redis-logical-db: <logical database index>

پایگاه‌داده منطقی در Redis برای استفاده. این‌ها پایگاه‌های داده در همان نمونه Redis هستند که پیکربندی یکسانی را به اشتراک گذاشته و در همان پرونده RDB/AOF ماندگار می‌شوند. در صورت تردید در استفاده از این گزینه، مستندات Redis پیشنهاد می‌کند از یک نمونه واحد Redis برای چندین برنامه نامرتبط استفاده نکنید (https://redis.io/commands/select). پایگاه‌داده پیش‌فرض در Redis برابر با 0 است در حالی که سایر پایگاه‌های داده منطقی پس از اتصال باید صراحتاً با دستور SELECT انتخاب شوند.

پیش‌فرض: 0

redis-replica-server-host: <server address or name>

آدرس IP (چه v6 یا v4) یا نام دامنه سرور Redis. به طور کلی یک آدرس IP باید مشخص شود زیرا در غیر این صورت Unbound باید هر بار که اتصالی به سرور برقرار می‌کند نام سرور را تفکیک نماید.

با این سرور به عنوان یک سرور رونوشت فقط‌خواندنی برخورد می‌شود (https://redis.io/docs/management/replication/#read-only-replica). در صورت مشخص شدن، تمام دستورات خواندن Redis به این سرور رونوشت ارسال می‌شوند، در حالی که دستورات نوشتن به redis-server-host ارسال خواهند شد.

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

redis-replica-server-port: <port number>

شماره درگاه TCP سرور رونوشت Redis.

پیش‌فرض: 6379

redis-replica-server-path: <unix socket path>

مسیر سوکت یونیکس برای اتصال به سرور رونوشت Redis. سوکت‌های یونیکس ممکن است بازدهی بهتری نسبت به گزینه آدرس IP داشته باشند.

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

redis-replica-server-password: "<password>"

گذرواژه AUTH ردیس برای استفاده در سرور Redis. تنها در صورتی مرتبط است که Redis برای مجوز گذرواژه کلاینت پیکربندی شده باشد.

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

redis-replica-timeout: <msec>

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

پیش‌فرض: 100

redis-replica-command-timeout: <msec>

مهلت زمانی برای دستورات رونوشت Redis، بر حسب میلی‌ثانیه. اگر 0 باشد، از مقدار redis-replica-timeout استفاده می‌کند.

پیش‌فرض: 0

redis-replica-connect-timeout: <msec>

مهلت زمانی برای راه‌اندازی اتصال رونوشت Redis، بر حسب میلی‌ثانیه. اگر 0 باشد، از مقدار redis-replica-timeout استفاده می‌کند.

پیش‌فرض: 0

redis-replica-logical-db: <logical database index>

مشابه redis-logical-db اما برای سرور رونوشت Redis.

پیش‌فرض: 0

dnstap-enable: <yes or no>

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

پیش‌فرض: no

dnstap-bidirectional: <yes or no>

استفاده از جریان‌های فریم در حالت دوطرفه برای انتقال پیام‌های DNSTAP.

پیش‌فرض: yes

dnstap-socket-path: <file name>

نام پرونده سوکت یونیکس را برای اتصال به سروری که به آن سوکت گوش می‌دهد تنظیم می‌کند.

پیش‌فرض: /etc/unbound/dnstap.sock

dnstap-ip: <IPaddress[@port]>

اگر "" باشد، از سوکت یونیکس استفاده می‌شود؛ اگر با یک آدرس IP (چه IPv4 یا IPv6) تنظیم شود، از آن آدرس برای اتصال به سرور استفاده می‌گردد.

پیش‌فرض: ""

dnstap-tls: <yes or no>

این گزینه را برای استفاده از TLS جهت اتصال به سرور مشخص‌شده در dnstap-ip تنظیم کنید. اگر روی no تنظیم شود، از TCP برای اتصال به سرور استفاده خواهد شد.

پیش‌فرض: yes

dnstap-tls-server-name: <name of TLS authentication>

نام سرور TLS برای احراز هویت سرور. هنگامی که dnstap-tls: yes تنظیم شده باشد استفاده می‌شود. اگر "" باشد نادیده گرفته می‌شود.

پیش‌فرض: ""

dnstap-tls-cert-bundle: <file name of cert bundle>

پرونده pem حاوی گواهی‌ها برای تأیید گواهی سرور TLS. اگر "" باشد از بسته گواهی پیش‌فرض سرور یا بسته گواهی ویندوز در ویندوز استفاده می‌شود.

پیش‌فرض: ""

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

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

پیش‌فرض: ""

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

پرونده گواهی کلاینت برای احراز هویت کلاینت TLS.

پیش‌فرض: ""

dnstap-send-identity: <yes or no>

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

پیش‌فرض: no

dnstap-send-version: <yes or no>

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

پیش‌فرض: no

dnstap-identity: <string>

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

پیش‌فرض: ""

dnstap-version: <string>

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

پیش‌فرض: ""

dnstap-sample-rate: <number>

نرخ نمونه‌برداری برای لاگ پیام‌ها؛ تنها 1/N پیام‌ها را لاگ می‌کند. با مقدار 0 غیرفعال می‌شود. این مورد در محیط‌های با حجم ترافیک بالا مفید است، جایی که قابلیت ثبت لاگ در غیر این صورت قابل اعتماد نخواهد بود. برای مثال، مقدار 10 تنها 1/10 زمان را صرف ثبت لاگ می‌کند، و مقدار 100 تنها یک صدم زمان را صرف ثبت لاگ خواهد کرد.

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

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

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

پیش‌فرض: no

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

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

پیش‌فرض: no

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

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

پیش‌فرض: no

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

فعال‌سازی برای ثبت لاگ پیام‌های پاسخ کلاینت. این‌ها پاسخ‌هایی از Unbound به کلاینت‌ها هستند.

پیش‌فرض: no

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

فعال‌سازی برای ثبت لاگ پیام‌های پرس‌وجوی فورواردر.

پیش‌فرض: no

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

فعال‌سازی برای ثبت لاگ پیام‌های پاسخ فورواردر.

پیش‌فرض: no

name: <zone name>

نام ناحیه مرجع.

primary: <IP address or host name>

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

برای استفاده از یک درگاه غیرپیش‌فرض برای ارتباط DNS، علامت '@' را همراه با شماره درگاه الحاق کنید.

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

اگر '@' و '#' را ترکیب کنید، '@' اول می‌آید. اگر آن را به یک نمونه دیگر Unbound نشانه روید، کار نخواهد کرد زیرا از AXFR/IXFR برای ناحیه پشتیبانی نمی‌کند، اما اگر از url برای دانلود zonefile به عنوان یک پرونده متنی از یک وب‌سرور استفاده کنید کار خواهد کرد.

اگر نام میزبان را مشخص کنید، نمی‌توانید از دامنه موجود در zonefile استفاده کنید، زیرا ممکن است هنگام بازیابی آن داده‌ها آن را نداشته باشد؛ در عوض از یک آدرس IP ساده برای اجتناب از وابستگی دوری در بازیابی آن آدرس IP استفاده کنید.

پس از هر چند انتقال IXFR، یک AXFR کامل انجام می‌شود. این کار برای تجمیع حافظه rpz است که در غیر این صورت افزایش می‌یابد. مقدار ثابت پس از 5 انتقال IXFR است.

master: <IP address or host name>

نحو جایگزین برای primary.

url: <url to zonefile>

محل دانلود یک پرونده ناحیه برای ناحیه. با HTTP یا HTTPS. یک نمونه برای url:

می‌توان چندین عبارت url داد، آن‌ها به نوبت امتحان می‌شوند.

اگر فقط urlها داده شوند از تایمر تازه‌سازی SOA برای انتظار جهت انجام دانلودهای جدید استفاده می‌شود. اگر سرورهای اصلی نیز فهرست شده باشند، سرورهای اصلی ابتدا با پرس‌وجوهای UDP SOA بررسی می‌شوند تا مشخص شود آیا شماره سریال SOA تغییر کرده است یا خیر، که تعداد دانلودها را کاهش می‌دهد. اگر هیچ‌یک از URLها کار نکنند، سرورهای اصلی با IXFR و AXFR امتحان می‌شوند.

برای HTTPS، از tls-cert-bundle و نام میزبان برگرفته از url برای احراز هویت اتصال استفاده می‌شود.

allow-notify: <IP address or host name or netblockIP/prefix>

با allow-notify می‌توانید منابع اضافی اعلام‌ها را مشخص کنید. هنگام دریافت اعلام، سرور ابتدا تلاش می‌کند پروب انجام دهد و سپس انتقال ناحیه را اجرا کند. اگر اعلام از یک سرور اصلی باشد، ابتدا آن سرور اصلی را امتحان می‌کند. در غیر این صورت سرورهای اصلی دیگر امتحان می‌شوند. اگر هیچ سرور اصلی وجود نداشته باشد، اما فقط urlها باشند، پرونده هنگام دریافت اعلام دانلود می‌شود.

NOTE:

zonefile: <filename>

نام پرونده‌ای که ناحیه در آن ذخیره می‌شود. اگر داده نشود هیچ پرونده ناحیه‌ای استفاده نمی‌شود. اگر پرونده وجود نداشته باشد یا خالی باشد، Unbound تلاش خواهد کرد داده‌های ناحیه را واکشی کند (مثلاً از سرورهای اصلی).

rpz-action-override: <action>

همیشه از این اقدام RPZ برای تطابق با محرک‌های این ناحیه استفاده شود. اقدامات ممکن عبارتند از: nxdomain، nodata، passthru، drop، disabled و cname.

rpz-cname-override: <domain>

دامنه مقصد CNAME برای استفاده در صورتی که اقدام cname برای rpz-action-override پیکربندی شده باشد.

rpz-log: <yes or no>

ثبت لاگ تمام اقدامات اعمال‌شده RPZ برای این ناحیه RPZ.

پیش‌فرض: no

rpz-log-name: <name>

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

rpz-signal-nxdomain-ra: <yes or no>

علامت‌گذاری هنگام مسدود شدن یک پرس‌وجو توسط RPZ با NXDOMAIN و فلگ تنظیم‌نشده RA. این به کلاینت‌های خاصی مانند dnsmasq اجازه می‌دهد استنباط کنند که دامنه از خارج مسدود شده است.

پیش‌فرض: no

for-downstream: <yes or no>

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

پیش‌فرض: no

tags: "<list of tags>"

محدود کردن خط‌مشی‌های این بخش RPZ به کلاینت‌هایی با یک برچسب منطبق.

برچسب‌ها باید در define-tag تعریف شوند و می‌توانند با استفاده از access-control-tag یا interface-tag به آدرس‌های کلاینت اختصاص یابند. فهرست برچسب‌ها را در علامت‌های نقل‌قول ("") قرار دهید و فاصله‌ها را میان برچسب‌ها بگذارید.

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

max-transfer-size: <number>

تعداد بایت‌های اندازه حداکثر انتقال ناحیه. انتقال‌های بزرگ‌تر، روی AXFR، IXFR و HTTP مجاز نیستند. یک عدد ساده بر حسب بایت است؛ 'k'، 'm' یا 'g' را برای کیلوبایت، مگابایت یا گیگابایت اضافه کنید (1024*1024 بایت در یک مگابایت). مقدار 0 این قابلیت را غیرفعال می‌کند.

تنها برای سرورهای اصلی غیرقابل اعتماد/بدرفتار که می‌توانند منابع را غصب کرده و تحلیل‌کننده را از کار بیندازند مد نظر قرار دهید.

پیش‌فرض: 0

max-transfer-time: <msec>

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

تنها برای سرورهای اصلی غیرقابل اعتماد/بدرفتار که می‌توانند منابع را غصب کرده و تحلیل‌کننده را از کار بیندازند مد نظر قرار دهید.

پیش‌فرض: 0

/etc/unbound

دایرکتوری کاری پیش‌فرض Unbound.

/etc/unbound

موقعیت پیش‌فرض chroot(2).

/etc/unbound/unbound.conf

پرونده پیکربندی Unbound.

/run/unbound.pid

پرونده pid پیش‌فرض Unbound حاوی شناسه فرآیند دیمون در حال اجرا.

unbound.log

پرونده لاگ Unbound. پیش‌فرض ثبت لاگ در syslog(3) است.