RESOLVED.CONF(5) resolved.conf RESOLVED.CONF(5)

resolved.conf - فایل‌های پیکربندی سرویس حل نام شبکه (systemd-resolved)

/etc/systemd/resolved.conf
/run/systemd/resolved.conf
/usr/local/lib/systemd/resolved.conf
/usr/lib/systemd/resolved.conf
/etc/systemd/resolved.conf.d/*.conf
/run/systemd/resolved.conf.d/*.conf
/usr/local/lib/systemd/resolved.conf.d/*.conf
/usr/lib/systemd/resolved.conf.d/*.conf

این فایل‌های پیکربندی حل نام محلی DNS و LLMNR را کنترل می‌کنند.

پیکربندی پیش‌فرض در زمان کامپایل تعیین می‌شود، بنابراین پیکربندی تنها زمانی مورد نیاز است که انحراف از آن مقادیر پیش‌فرض لازم باشد. فایل پیکربندی اصلی از یکی از دایرکتوری‌های فهرست‌شده به ترتیب اولویت بارگذاری می‌شود و تنها اولین فایل یافت‌شده استفاده می‌گردد: /etc/systemd/، /run/systemd/، /usr/local/lib/systemd/ [1]، /usr/lib/systemd/. نسخه ارائه‌شده توسط توزیع‌کننده (vendor) شامل ورودی‌های کامنت‌شده‌ای است که مقادیر پیش‌فرض را به عنوان راهنمای مدیر سیستم نشان می‌دهد. بازنویسی‌های محلی را نیز می‌توان با ایجاد قطعات تکمیلی (drop-in) مطابق توضیحات زیر انجام داد. فایل پیکربندی اصلی را نیز می‌توان برای این منظور ویرایش کرد (یا یک رونوشت در /etc/ اگر در /usr/ عرضه شده باشد)، با این حال استفاده از قطعات تکمیلی (drop-in) برای پیکربندی محلی نسبت به تغییر دادن فایل پیکربندی اصلی توصیه می‌شود.

علاوه بر فایل پیکربندی اصلی، قطعه‌های پیکربندی تکمیلی (drop-in) از دایرکتوری‌های /usr/lib/systemd/*.conf.d/، /usr/local/lib/systemd/*.conf.d/، و /etc/systemd/*.conf.d/ خوانده می‌شوند. این قطعات تکمیلی اولویت بالاتری دارند و فایل پیکربندی اصلی را بازنویسی (override) می‌کنند. فایل‌ها در زیردایرکتوری‌های پیکربندی *.conf.d/ صرف‌نظر از اینکه در کدام زیردایرکتوری قرار دارند، بر اساس نام فایل خود به ترتیب واژه‌نگاری (lexicographic) مرتب می‌شوند. هنگامی که چندین فایل یک گزینه یکسان را تعیین می‌کنند، برای گزینه‌هایی که فقط یک مقدار واحد را می‌پذیرند، ورودی موجود در فایلی که نام آن در آخرین جایگاه قرار می‌گیرد اولویت دارد، و برای گزینه‌هایی که فهرستی از مقادیر را می‌پذیرند، ورودی‌ها به همان ترتیبی که در فایل‌های مرتب‌شده ظاهر می‌شوند جمع‌آوری می‌گردند.

هنگامی که بسته‌ها نیاز به سفارشی‌سازی پیکربندی دارند، می‌توانند قطعات تکمیلی (drop-in) را در /usr/ نصب کنند. فایل‌های موجود در /etc/ برای مدیر سیستم محلی رزرو شده‌اند، که می‌تواند از این منطق برای بازنویسی فایل‌های پیکربندی نصب‌شده توسط بسته‌های توزیع‌کننده استفاده کند. برای بازنویسی قطعات تکمیلی بسته، باید از قطعات تکمیلی استفاده شود، زیرا فایل پیکربندی اصلی اولویت پایین‌تری دارد. توصیه می‌شود نام تمام فایل‌ها در این زیردایرکتوری‌ها با یک عدد دو رقمی و یک خط تیره پیشوندگذاری شود تا ترتیب آن‌ها ساده‌تر شود. این کار همچنین مفهوم اولویت‌های قطعات تکمیلی را تعریف می‌کند تا به توزیع‌کنندگان سیستم‌عامل اجازه دهد قطعات تکمیلی را در محدوده خاصی پایین‌تر از محدوده مورد استفاده کاربران عرضه کنند. این امر خطر بازنویسی تصادفی قطعات تکمیلی تعریف‌شده توسط کاربران را توسط قطعات تکمیلی بسته‌ها کاهش می‌دهد. توصیه می‌شود از محدوده 10-40 برای قطعات تکمیلی در /usr/ و از محدوده 60-90 برای قطعات تکمیلی در /etc/ و /run/ استفاده شود، تا اطمینان حاصل گردد که قطعات تکمیلی محلی و گذرا بر قطعات تکمیلی عرضه‌شده توسط توزیع‌کننده سیستم‌عامل اولویت دارند.

برای غیرفعال کردن یک فایل پیکربندی ارائه‌شده توسط توزیع‌کننده، روش توصیه‌شده قرار دادن یک پیوند نمادین (symlink) به /dev/null در دایرکتوری پیکربندی در /etc/ با همان نام فایل پیکربندی توزیع‌کننده است.

گزینه‌های زیر در بخش [Resolve] در دسترس هستند:

DNS=

فهرستی از آدرس‌های IPv4 و IPv6 جداشده با فاصله برای استفاده به عنوان سرورهای DNS سیستم. هر آدرس می‌تواند به صورت اختیاری شامل یک شماره درگاه جداشده با ":"، یک نام یا نمایه رابط شبکه جداشده با "%"، و یک شناسه نام سرور (SNI) جداشده با "#" باشد. هنگامی که یک آدرس IPv6 همراه با شماره درگاه مشخص می‌شود، آدرس باید درون کروشه (قلاب) قرار گیرد. به این معنا که قالب‌های کامل و قابل قبول عبارتند از: "111.222.333.444:9953%ifname#example.com" برای IPv4 و "[1111:2222::3333]:9953%ifname#example.com" برای IPv6. درخواست‌های DNS به یکی از سرورهای DNS فهرست‌شده، به موازات سرورهای DNS مناسب به ازای هر پیوند (per-link) که از systemd-networkd.service(8) دریافت شده یا در زمان اجرا توسط برنامه‌های خارجی تنظیم شده‌اند، ارسال می‌شوند. به دلایل سازگاری، اگر این تنظیم مشخص نشده باشد، سرورهای DNS فهرست‌شده در /etc/resolv.conf در صورت وجود این فایل و پیکربندی هر سروری در آن، استفاده می‌شوند. مقدار پیش‌فرض این تنظیم یک فهرست خالی است.

افزوده‌شده در نسخه 213.

FallbackDNS=

فهرستی از آدرس‌های IPv4 و IPv6 جداشده با فاصله برای استفاده به عنوان سرورهای DNS پشتیبان (fallback). لطفاً برای قالب قابل قبول آدرس‌ها به DNS= مراجعه کنید. هرگونه سرور DNS به ازای هر پیوند دریافت‌شده از systemd-networkd.service(8) بر این تنظیم اولویت دارد، همان‌طور که هر سرور تنظیم‌شده از طریق DNS= در بالا یا /etc/resolv.conf اولویت دارد. از این رو، این تنظیم تنها زمانی استفاده می‌شود که هیچ اطلاعات سرور DNS دیگری در دست نباشد. اگر این گزینه تعیین نشده باشد، به جای آن از فهرست سرورهای DNS تعبیه‌شده در زمان کامپایل استفاده می‌شود.

افزوده‌شده در نسخه 216.

Domains=

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

هر دامنه‌ای که با "~" پیشوندگذاری نشده باشد، به عنوان پسوندهای جستجو هنگام حل نام‌های میزبان تک‌بخشی (نام‌های دامنه‌ای که فاقد نقطه هستند) استفاده می‌شود تا آن‌ها را به نام‌های دامنه کاملاً واجد شرایط (FQDN) تبدیل کند. این «دامنه‌های جستجو» دقیقاً به همان ترتیبی که مشخص شده‌اند پردازش می‌شوند تا زمانی که نام همراه با پسوند افزوده پیدا شود. به دلایل سازگاری، اگر این تنظیم مشخص نشده باشد، دامنه‌های جستجوی فهرست‌شده در /etc/resolv.conf با کلمه کلیدی search در صورت وجود این فایل و پیکربندی هر دامنه‌ای در آن، استفاده می‌شوند.

دامنه‌هایی که با "~" پیشوندگذاری شده‌اند «دامنه‌های فقط-مسیریابی» (route-only domains) نامیده می‌شوند. تمامی دامنه‌های فهرست‌شده در این‌جا (هم دامنه‌های جستجو و هم دامنه‌های فقط-مسیریابی پس از حذف پیشوند "~") یک مسیر جستجو تعریف می‌کنند که ترجیحاً پرس‌وجوهای DNS را به این رابط هدایت می‌کند. این مسیر جستجو تنها زمانی اثرگذار است که سرورهای DNS مناسب به ازای هر پیوند شناخته شده باشند. چنین سرورهایی ممکن است از طریق تنظیم DNS= (به بالا مراجعه کنید) و به صورت پویا در زمان اجرا، برای مثال از اجاره‌های DHCP تعریف شوند. اگر هیچ سرور DNS به ازای هر پیوند شناخته نشده باشد، دامنه‌های فقط-مسیریابی هیچ اثری نخواهند داشت.

از ساختار "~." (که از "~" برای نشان دادن دامنه فقط-مسیریابی و "." برای نشان دادن دامنه ریشه DNS که پسوند ضمنی تمامی دامنه‌های DNS است، تشکیل شده) استفاده کنید تا سرورهای DNS تعریف‌شده برای این پیوند ترجیحاً برای تمامی دامنه‌ها به کار روند.

برای جزئیات نحوه استفاده از دامنه‌های جستجو و فقط-مسیریابی، به بخش "Protocols and Routing" در systemd-resolved.service(8) مراجعه کنید.

توجه داشته باشید که پیکربندی دامنه MulticastDNS با نام "local" به عنوان دامنه جستجو یا مسیریابی، این اثر را دارد که جستجوهای این دامنه را به DNS تک‌پخشی (unicast) کلاسیک هدایت می‌کند. این ویژگی ممکن است برای ارائه سازگاری با سیستم‌های قدیمی که بر خلاف تخصیص IANA برای اهداف صرفاً MulticastDNS از این دامنه در بستر DNS تک‌پخشی استفاده می‌کنند، به کار رود. دامنه‌های جستجو و مسیریابی مفهومی مربوط به DNS تک‌پخشی هستند و نمی‌توانند برای حل جستجوهای تک‌بخشی از طریق MulticastDNS استفاده شوند.

افزوده‌شده در نسخه 229.

LLMNR=

یک آرگومان بولی یا "resolve" را می‌پذیرد. پشتیبانی از حل نام چندپخشی پیوند-محلی (LLMNR - RFC 4795[2]) را روی میزبان محلی کنترل می‌کند. در صورت تنظیم روی true، پشتیبانی کامل از پاسخ‌دهنده و حل‌کننده LLMNR فعال می‌شود. در صورت تنظیم روی false، هر دو را غیرفعال می‌کند. اگر روی "resolve" تنظیم شود، تنها پشتیبانی از حل نام فعال شده، اما پاسخ‌دهی غیرفعال می‌گردد. توجه داشته باشید که systemd-networkd.service(8) نیز تنظیمات LLMNR به ازای هر پیوند را نگهداری می‌کند. LLMNR روی یک پیوند تنها زمانی فعال می‌شود که هم تنظیم به ازای پیوند و هم تنظیم سراسری روشن باشند.

افزوده‌شده در نسخه 216.

MulticastDNS=

یک آرگومان بولی یا "resolve" را می‌پذیرد. پشتیبانی از DNS چندپخشی (mDNS - RFC 6762[3]) را روی میزبان محلی کنترل می‌کند. در صورت تنظیم روی true، پشتیبانی کامل از پاسخ‌دهنده و حل‌کننده DNS چندپخشی فعال می‌شود. در صورت تنظیم روی false، هر دو را غیرفعال می‌کند. اگر روی "resolve" تنظیم شود، تنها پشتیبانی از حل نام فعال شده، اما پاسخ‌دهی غیرفعال می‌گردد. توجه داشته باشید که systemd-networkd.service(8) نیز تنظیمات DNS چندپخشی به ازای هر پیوند را نگهداری می‌کند. DNS چندپخشی روی یک پیوند تنها زمانی فعال می‌شود که هم تنظیم به ازای پیوند و هم تنظیم سراسری روشن باشند.

افزوده‌شده در نسخه 234.

DNSSEC=

یک آرگومان بولی یا "allow-downgrade" را می‌پذیرد.

در صورت تنظیم روی true، تمام جستجوهای DNS به صورت محلی با DNSSEC اعتبارسنجی می‌شوند (به استثنای LLMNR و DNS چندپخشی). اگر پاسخی برای درخواست جستجو نامعتبر تشخیص داده شود، یک خطای شکست جستجو به برنامه‌ها برگردانده می‌شود. توجه داشته باشید که این حالت به سرور DNS که از DNSSEC پشتیبانی کند نیاز دارد. اگر سرور DNS به درستی از DNSSEC پشتیبانی نکند، تمام اعتبارسنجی‌ها با شکست مواجه خواهند شد.

اگر روی "allow-downgrade" تنظیم شود، تلاش برای اعتبارسنجی DNSSEC انجام می‌شود، اما اگر سرور به درستی از DNSSEC پشتیبانی نکند، حالت DNSSEC به طور خودکار غیرفعال می‌گردد. توجه داشته باشید که این حالت، اعتبارسنجی DNSSEC را در برابر حملات «تنزل رتبه» (downgrade) آسیب‌پذیر می‌کند؛ جایی که یک مهاجم ممکن است بتواند با ساختن یک پاسخ DNS جعلی که نشان می‌دهد DNSSEC پشتیبانی نمی‌شود، تنزل به حالت غیر DNSSEC را موجب شود.

در صورت تنظیم روی false، جستجوهای DNS با DNSSEC اعتبارسنجی نمی‌شوند.

توجه داشته باشید که اعتبارسنجی DNSSEC نیازمند دریافت داده‌های DNS اضافی است و بنابراین منجر به جریمه زمانی اندکی در جستجوی DNS می‌شود.

اعتبارسنجی DNSSEC برای اثبات یکپارچگی داده‌ها به آگاهی از «لنگرهای اعتماد» (trust anchors) نیاز دارد. لنگر اعتماد برای دامنه ریشه اینترنت در درون حل‌کننده تعبیه شده است؛ لنگرهای اعتماد اضافی را می‌توان با dnssec-trust-anchors.d(5) تعریف کرد. لنگرهای اعتماد ممکن است در فواصل زمانی منظم تغییر کنند و لنگرهای اعتماد قدیمی ابطال شوند. در چنین حالتی، اعتبارسنجی DNSSEC امکان‌پذیر نخواهد بود تا زمانی که لنگرهای اعتماد جدید به صورت محلی پیکربندی شوند یا بسته نرم‌افزاری حل‌کننده با لنگر اعتماد ریشه جدید به‌روزرسانی شود. در عمل، هنگامی که لنگر اعتماد تعبیه‌شده ابطال شود و DNSSEC= روی true تنظیم باشد، تمام جستجوهای بعدی با شکست مواجه خواهند شد، زیرا دیگر نمی‌توان اثبات کرد که آیا جستجوها به درستی امضا شده‌اند یا به طور معتبر بدون امضا هستند. اگر DNSSEC= روی "allow-downgrade" تنظیم شده باشد، حل‌کننده در چنین حالتی اعتبارسنجی DNSSEC را به طور خودکار خاموش می‌کند.

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

توصیه می‌شود در سیستم‌هایی که مشخص است سرور DNS به درستی از DNSSEC پشتیبانی می‌کند و به‌روزرسانی‌های نرم‌افزار یا لنگرهای اعتماد به طور منظم اتفاق می‌افتد، DNSSEC= روی true تنظیم شود. در سیستم‌های دیگر توصیه می‌شود DNSSEC= روی "allow-downgrade" تنظیم گردد.

علاوه بر این تنظیم سراسری DNSSEC، systemd-networkd.service(8) نیز تنظیمات DNSSEC به ازای هر پیوند را نگهداری می‌کند. برای سرورهای DNS سیستم (به بالا مراجعه کنید)، تنها تنظیم سراسری DNSSEC نافذ است. برای سرورهای DNS به ازای هر پیوند، تنظیم به ازای پیوند نافذ است، مگر اینکه تنظیم نشده باشد که در این صورت تنظیم سراسری استفاده می‌شود.

زون‌های DNS خصوصی-سایت (Site-private DNS zones) به طور کلی با عملکرد DNSSEC تداخل دارند، مگر اینکه یک لنگر اعتماد منفی (اگر زون خصوصی امضا نشده باشد) یا مثبت (اگر زون خصوصی امضا شده باشد) برای آن‌ها پیکربندی شده باشد. اگر حالت "allow-downgrade" انتخاب شده باشد، تلاش می‌شود تا زون‌های DNS خصوصی-سایت با استفاده از دامنه‌های سطح بالا (TLDs) که توسط سرور ریشه DNS شناخته نشده‌اند شناسایی شوند. این منطق در تمامی ساختارهای زون‌های خصوصی کار نمی‌کند.

مقدار پیش‌فرض "no" است.

افزوده‌شده در نسخه 229.

DNSOverTLS=

یک آرگومان بولی یا "opportunistic" را می‌پذیرد. در صورت تنظیم روی true تمام اتصالات به سرور رمزگذاری خواهند شد. توجه داشته باشید که این حالت به یک سرور DNS نیاز دارد که از DNS-over-TLS پشتیبانی کند و یک گواهی معتبر داشته باشد. اگر نام میزبان در DNS= با استفاده از قالب "address#server_name" مشخص شده باشد، برای اعتبارسنجی گواهی آن و همچنین فعال‌سازی شناسه نام سرور (SNI) هنگام برقراری یک اتصال TLS استفاده می‌شود. در غیر این صورت، گواهی با نشانی IP سرور تطبیق داده می‌شود. اگر سرور DNS از DNS-over-TLS پشتیبانی نکند، تمامی درخواست‌های DNS با شکست مواجه خواهند شد.

هنگامی که روی "opportunistic" تنظیم شود، تلاش می‌شود درخواست‌های DNS به صورت رمزگذاری‌شده با DNS-over-TLS ارسال شوند. اگر سرور DNS از TLS پشتیبانی نکند، DNS-over-TLS غیرفعال می‌شود. توجه داشته باشید که این حالت، DNS-over-TLS را در برابر حملات «تنزل رتبه» (downgrade) آسیب‌پذیر می‌کند؛ جایی که یک مهاجم ممکن است بتواند با ساختن پاسخی که نشان می‌دهد DNS-over-TLS پشتیبانی نمی‌شود، باعث تنزل به حالت غیررمزگذاری‌شده گردد. در صورت تنظیم روی false، جستجوهای DNS روی UDP ارسال می‌شوند.

توجه داشته باشید که DNS-over-TLS نیازمند ارسال داده‌های اضافی برای برقراری یک اتصال رمزگذاری‌شده است و بنابراین منجر به جریمه زمانی اندکی در زمان جستجوی DNS می‌شود.

توجه داشته باشید که در حالت "opportunistic"، حل‌کننده قادر به احراز هویت سرور نیست، بنابراین در برابر حملات «مرد میانی» (man-in-the-middle) آسیب‌پذیر است.

علاوه بر این تنظیم سراسری DNSOverTLS=، systemd-networkd.service(8) نیز تنظیمات DNSOverTLS= به ازای هر پیوند را نگهداری می‌کند. برای سرورهای DNS سیستم (به بالا مراجعه کنید)، تنها تنظیم سراسری DNSOverTLS= نافذ است. برای سرورهای DNS به ازای هر پیوند، تنظیم به ازای پیوند اعمال می‌شود، مگر اینکه تنظیم نشده باشد که در این صورت از تنظیم سراسری استفاده می‌شود.

مقدار پیش‌فرض "no" است.

افزوده‌شده در نسخه 239.

Cache=

یک مقدار بولی یا "no-negative" را به عنوان آرگومان می‌پذیرد. اگر "yes" (پیش‌فرض) باشد، حل نام دامنه‌ای که قبلاً مورد پرس‌وجو قرار گرفته است، تا زمانی که نتیجه هنوز معتبر باشد، نتیجه قبلی را بازمی‌گرداند و بنابراین منجر به یک درخواست شبکه جدید نمی‌شود. آگاه باشید که خاموش کردن حافظه پنهان (caching) با کاهش کارایی همراه است، که به‌ویژه هنگام استفاده از DNSSEC بسیار زیاد خواهد بود. اگر روی "no-negative" تنظیم شود، تنها پاسخ‌های مثبت در حافظه پنهان ذخیره می‌شوند.

توجه داشته باشید که حافظه پنهان به طور پیش‌فرض برای سرورهای DNS محلیِ میزبان (host-local) خاموش است. برای جزئیات به CacheFromLocalhost= مراجعه کنید.

افزوده‌شده در نسخه 231.

CacheFromLocalhost=

یک مقدار بولی را به عنوان آرگومان می‌پذیرد. اگر "no" (پیش‌فرض) باشد و پاسخ از یک آدرس IP محلیِ میزبان (مانند 127.0.0.1 یا ::1) دریافت شده باشد، نتیجه در حافظه پنهان ذخیره نخواهد شد تا از ذخیره‌سازی محلی تکراری احتمالی جلوگیری شود.

افزوده‌شده در نسخه 248.

DNSCacheSize=, MulticastDNSCacheSize=, LLMNRCacheSize=

یک عدد صحیح غیرمنفی را می‌پذیرد. حداکثر تعداد ورودی‌های رکوردهای منبع DNS را که ممکن است به ترتیب برای DNS تک‌پخشی، DNS چندپخشی (mDNS) و حل نام چندپخشی پیوند-محلی (LLMNR) در حافظه پنهان به ازای هر حوزه (per-scope) ذخیره شوند، پیکربندی می‌کند. مقدار پیش‌فرض هر یک 4096 است. حداکثر مقدار مجاز 16777216 (2^24) می‌باشد. تنظیم هر یک از این‌ها روی 0 عملاً حافظه پنهان را برای پروتکل مربوطه غیرفعال می‌کند. این تنظیمات تنها زمانی مؤثر هستند که Cache= روی "yes" یا "no-negative" تنظیم شده باشد. اگر Cache=no باشد، حافظه پنهان صرف‌نظر از این مقادیر کاملاً غیرفعال می‌شود.

توجه داشته باشید که DNS چندپخشی برای سرکوب درخواست‌های تکراری و عملکرد کارآمد، به شدت به حافظه پنهان متکی است. توصیه می‌شود حتی هنگام کاهش DNSCacheSize=، مقدار MulticastDNSCacheSize= در حد معقولی بالا نگه داشته شود.

توجه داشته باشید که systemd-resolved هنگام فشار روی حافظه سیستم (memory pressure) به طور خودکار تمامی حافظه‌های پنهان را تخلیه می‌کند، بنابراین در بیشتر موارد پیکربندی دستی اندازه حافظه پنهان نباید لازم باشد.

توجه داشته باشید که حافظه پنهان به طور پیش‌فرض برای سرورهای DNS محلیِ میزبان خاموش است. برای جزئیات به CacheFromLocalhost= مراجعه کنید.

افزوده‌شده در نسخه 261.

DNSStubListener=

یک آرگومان بولی یا یکی از مقادیر "udp" و "tcp" را می‌پذیرد. اگر "udp" باشد، یک حل‌کننده واسط DNS (stub resolver) برای درخواست‌های UDP روی آدرس‌های 127.0.0.53 و 127.0.0.54، درگاه 53 گوش فرا می‌دهد. اگر "tcp" باشد، حل‌کننده واسط برای درخواست‌های TCP روی همان آدرس‌ها و درگاه گوش می‌دهد. اگر "yes" (پیش‌فرض) باشد، حل‌کننده واسط برای هر دو درخواست UDP و TCP گوش می‌دهد. اگر "no" باشد، شنونده واسط غیرفعال می‌شود.

حل‌کننده واسط DNS روی 127.0.0.53 مجموعه کامل ویژگی‌های حل‌کننده محلی را ارائه می‌دهد که شامل ارائه حل نام LLMNR/MulticastDNS نیز می‌شود. حل‌کننده واسط DNS روی 127.0.0.54 یک حل‌کننده محدودتر را ارائه می‌دهد که فقط در حالت «پروکسی» (proxy) عمل می‌کند؛ یعنی بیشتر پیام‌های DNS را نسبتاً بدون تغییر به سرورهای DNS بالادستی فعلی منتقل کرده و بازمی‌گرداند، اما تلاشی برای پردازش محلی پیام‌ها نمی‌کند و بنابراین DNSSEC را اعتبارسنجی نکرده یا حل نام LLMNR/MulticastDNS را ارائه نمی‌دهد. (با این حال، در صورت نیاز ارتباط را به DNS-over-TLS ترجمه خواهد کرد.)

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

افزوده‌شده در نسخه 232.

RefuseRecordTypes=

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

مثال‌ها:

RefuseRecordTypes=AAAA SRV TXT

توجه داشته باشید که برای رد کردن کامل رکوردهای AAAA (برخلاف SRV، TXT و غیره)، لطفاً پشته IPv6 را نیز در هسته با "sysctl -w net.ipv6.conf.all.disable_ipv6=1"; غیرفعال کنید.

افزوده‌شده در نسخه 258.

DNSStubListenerExtra=

یک آدرس IPv4 یا IPv6 را برای شنود می‌پذیرد. این آدرس می‌تواند به صورت اختیاری دارای پیشوندی از نام پروتکل ("udp" یا "tcp") جداشده با ":" باشد. اگر پروتکل مشخص نشود، سرویس روی هر دو پروتکل UDP و TCP گوش خواهد داد. همچنین می‌تواند به صورت اختیاری دارای پسوند شماره درگاه عددی با جداکننده ":" باشد. هنگامی که یک آدرس IPv6 با شماره درگاه مشخص می‌شود، آدرس باید درون قلاب (کروشه) قرار گیرد. اگر درگاه مشخص نشود، سرویس از درگاه 53 استفاده می‌کند. توجه داشته باشید که این گزینه مستقل از واسط اصلی DNS پیکربندی‌شده با DNSStubListener= است و فقط سوکت‌های اضافی را برای شنود پیکربندی می‌کند. این گزینه می‌تواند چندین بار مشخص شود. اگر یک رشته خالی اختصاص داده شود، تمام مقادیر اختصاص‌یافته قبلی پاک می‌شوند. مقدار پیش‌فرض تنظیم‌نشده است.

مثال‌ها:

DNSStubListenerExtra=192.168.10.10
DNSStubListenerExtra=2001:db8:0:f102::10
DNSStubListenerExtra=192.168.10.11:9953
DNSStubListenerExtra=[2001:db8:0:f102::11]:9953
DNSStubListenerExtra=tcp:192.168.10.12
DNSStubListenerExtra=udp:2001:db8:0:f102::12
DNSStubListenerExtra=tcp:192.168.10.13:9953
DNSStubListenerExtra=udp:[2001:db8:0:f102::13]:9953

افزوده‌شده در نسخه 247.

ReadEtcHosts=

یک آرگومان بولی را می‌پذیرد. اگر "yes" (پیش‌فرض) باشد، systemd-resolved فایل /etc/hosts را می‌خواند و قبل از ارسال پرس‌وجو به سرورهای DNS، تلاش می‌کند تا با استفاده از ورودی‌های این فایل، میزبان‌ها یا آدرس‌ها را حل کند.

افزوده‌شده در نسخه 240.

ReadStaticRecords=

یک آرگومان بولی را می‌پذیرد. اگر "yes" (پیش‌فرض) باشد، systemd-resolved مسیرهای /etc/systemd/resolve/static.d/*.rr، /run/systemd/resolve/static.d/*.rr، /usr/local/lib/systemd/resolve/static.d/*.rr و /usr/lib/systemd/resolve/static.d/*.rr را می‌خواند و قبل از ارسال پرس‌وجو به سرورهای DNS، تلاش می‌کند با استفاده از ورودی‌های موجود در این فایل‌ها، جستجوها را حل کند. این قابلیت بسیار شبیه به قابلیتی است که توسط ReadEtcHosts= کنترل می‌شود، اما امکان کنترل انعطاف‌پذیرتر فیلدهای رکوردهای منبع DNS را فراتر از صرفاً A/AAAA/PTR فراهم می‌کند. برای جزئیات به systemd.rr(5) مراجعه کنید.

اگر هم این گزینه و هم ReadEtcHosts= فعال باشند، این سازوکار اولویت دارد: هر رکوردی که از طریق رکوردهای منبع ایستا کشف شود، بر رکوردهای هم‌نام از /etc/hosts اولویت خواهد داشت.

افزوده‌شده در نسخه 261.

ResolveUnicastSingleLabel=

یک آرگومان بولی را می‌پذیرد. در صورت تنظیم روی false (پیش‌فرض)، systemd-resolved پرس‌وجوهای A و AAAA را برای نام‌های تک‌بخشی روی DNS کلاسیک حل نخواهد کرد. توجه داشته باشید که چنین نام‌هایی ممکن است همچنان در صورت تعیین دامنه‌های جستجو (به Domains= در بالا مراجعه کنید) یا با استفاده از سازوکارهای دیگر، به‌ویژه از طریق LLMNR یا از /etc/hosts حل شوند. در صورت تنظیم روی true، پرس‌وجوها برای نام‌های تک‌بخشی حتی اگر هیچ دامنه جستجویی تعریف نشده باشد، به سرورهای سراسری DNS ارسال می‌شوند.

این گزینه برای سازگاری با پیکربندی‌هایی ارائه شده است که در آن‌ها از سرورهای عمومی DNS استفاده نمی‌شود. ارسال نام‌های تک‌بخشی به سرورهایی که تحت کنترل شما نیستند، منطبق با استاندارد نیست؛ به بیانیه IAB[4] مراجعه کنید، و ممکن است خطرات امنیتی و حریم خصوصی ایجاد کند.

افزوده‌شده در نسخه 246.

StaleRetentionSec=SECONDS

یک مقدار مدت‌زمان را می‌پذیرد که مدت زمانی را که رکوردهای منبع DNS می‌توانند فراتر از زمان حیات (TTL) خود در حافظه پنهان نگهداری شوند، تعیین می‌کند. این امر اجازه می‌دهد تا این رکوردها به عنوان رکوردهای کهنه (stale) بازگردانده شوند. به طور پیش‌فرض، این مقدار روی صفر تنظیم شده است، به این معنی که رکوردهای منبع DNS پس از انقضای TTL در حافظه پنهان ذخیره نمی‌شوند.

این ویژگی زمانی مفید است که خرابی سرور DNS رخ دهد یا سرور غیرقابل دسترس شود. در چنین مواردی، systemd-resolved(8) همچنان به استفاده از رکوردهای کهنه برای پاسخ دادن به پرس‌وجوهای DNS ادامه می‌دهد، به‌ویژه زمانی که هیچ پاسخ معتبری از سرورهای DNS بالادستی دریافت نشود. با این حال، این مورد برای پاسخ‌های NXDOMAIN صدق نمی‌کند، زیرا آن‌ها همچنان پاسخ‌های کاملاً معتبری هستند. این ویژگی تاب‌آوری در برابر خرابی‌ها و قطعی‌های زیرساخت DNS را افزایش می‌دهد.

systemd-resolved همیشه ابتدا تلاش می‌کند تا به سرورهای بالادستی DNS دسترسی پیدا کند، قبل از اینکه هرگونه داده کهنه‌ای را در اختیار برنامه کلاینت قرار دهد. اگر این قابلیت فعال باشد، حافظه پنهان هنگام تغییر سرورها تخلیه نخواهد شد.

افزوده‌شده در نسخه 254.

systemd(1)، systemd-resolved.service(8)، systemd-networkd.service(8)، dnssec-trust-anchors.d(5)، systemd.rr(5)، resolv.conf(5)

1.
💣💥🧨💥💥💣 لطفاً توجه داشته باشید که این فایل‌های پیکربندی باید همیشه در دسترس باشند. اگر /usr/local/ یک پارتیشن جداگانه باشد، ممکن است در مراحل اولیه بوت در دسترس نباشد و نباید برای پیکربندی استفاده شود.
2.
RFC 4795
https://tools.ietf.org/html/rfc4795
3.
RFC 6762
https://tools.ietf.org/html/rfc6762
4.
بیانیه IAB
https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful
systemd 261.2