systemd-resolved.service, systemd-resolved -
سرویس
تحلیل و
کشگذاری
محلی
نامهای
شبکه (DNS/LLMNR/mDNS)
systemd-resolved.service
/usr/lib/systemd/systemd-resolved
systemd-resolved یک
سرویس
سیستمی است
که تفکیک و
تحلیل نام
شبکه را
برای
برنامههای
کاربردی
محلی فراهم
میکند. این
سرویس یک
تفکیککنندهٔ
فرعی (stub resolver)
اعتبارسنج
و
ذخیرهساز
موقت (caching) برای
DNS/DNSSEC و همچنین
تفکیککننده
و
پاسخدهندهٔ
LLMNR و MulticastDNS را
پیادهسازی
مینماید.
برنامههای
کاربردی
محلی
میتوانند
درخواستهای
تفکیک نام
شبکه را از
طریق سه
رابط ارسال
کنند:
•رابط
برنامهنویسی
(API) بومی و با
امکانات
کامل که
systemd-resolved
از طریق D-Bus
ارائه
میدهد؛
برای
جزئیات به
org.freedesktop.resolve1(5) و
org.freedesktop.LogControl1(5)
مراجعه
کنید.
استفاده از
این رابط
برنامهنویسی
عموماً به
کلاینتها
توصیه
میشود چرا
که ناهمگام
(asynchronous) و دارای
تمامی
قابلیتها
است (برای
نمونه،
وضعیت
اعتبارسنجی
DNSSEC و دامنهٔ
رابط را
برای
نشانیها
در صورت
نیاز جهت
پشتیبانی
از
شبکهبندی
پیوند-محلی
به درستی
بازمیگرداند).
•رابط
برنامهنویسی
بومی که systemd-resolved
از طریق Varlink
روی سوکت AF_UNIX
به نشانی
/run/systemd/resolve/io.systemd.Resolve
ارائه
میدهد. این
رابط
عملکرد
مشابهی با
رابط D-Bus
ارائه
میکند،
اما در تمام
طول زمان
اجرا بدون
نیاز به
اجرای
سرویس
کارگزار
گذرگاه
سیستم D-Bus در
دسترس است.
•رابط
برنامهنویسی
getaddrinfo(3) در glibc
مطابق با
تعریف
RFC3493[1] و
توابع
تفکیککنندهٔ
مرتبط با
آن، از جمله
gethostbyname(3). این
رابط
بهطور
گسترده، از
جمله فراتر
از پلتفرم
لینوکس،
پشتیبانی
میشود. با
این حال، در
شکل کنونی
خود
اطلاعات
وضعیت
اعتبارسنجی
DNSSEC را ارائه
نمیدهد و
تنها همگام
(synchronous) است. این
رابط
برنامهنویسی
توسط سوئیچ
سرویس نام glibc
(
nss(5))
پشتیبانی
میشود.
استفاده از
ماژول NSS
گلیبک
nss-resolve(8)
برای اینکه
توابع
تفکیککنندهٔ
NSS در glibc
بتوانند
نامهای
میزبان را
از طریق
systemd-resolved
تفکیک
کنند،
الزامی
است.
•علاوه
بر این،
systemd-resolved
یک شنوندهٔ
فرعی (stub listener)
محلی DNS روی
نشانیهای IP
با مقادیر
127.0.0.53
و
127.0.0.54 بر روی
رابط محلی
لوپبک
فراهم
میکند.
برنامههایی
که
درخواستهای
DNS را
مستقیماً
ارسال کرده
و هرگونه API
محلی را دور
میزنند،
میتوانند
به این
تفکیککنندهٔ
فرعی هدایت
شوند تا به
systemd-resolved متصل
گردند. با
این حال
توجه داشته
باشید که
اکیداً
توصیه
میشود
برنامههای
محلی در عوض
از
رابطهای
برنامهنویسی
NSS گلیبک یا
گذرگاه
(همانطور
که در بالا
توضیح داده
شد) استفاده
کنند، زیرا
مفاهیم
گوناگون
تفکیک شبکه
(مانند
نشانیدهی
پیوند-محلی
یا
دامنههای
یونیکد LLMNR) را
نمیتوان
به پروتکل
تکپخشی (unicast) DNS
نگاشت کرد.
تفکیککنندهٔ
فرعی DNS روی 127.0.0.53
مجموعه
ویژگیهای
کامل
تفکیککننده
محلی را
ارائه
میدهد که
شامل ارائه
تفکیک LLMNR/MulticastDNS
نیز میشود.
تفکیککنندهٔ
فرعی DNS روی 127.0.0.54
تفکیککنندهٔ
محدودتری
فراهم
میکند که
تنها در
حالت
«پروکسی»
عمل
مینماید،
یعنی اکثر
پیامهای DNS
را نسبتاً
بدون تغییر
به سرورهای
بالادستی DNS
فعلی و
برعکس
منتقل
میکند،
اما تلاش
نمیکند
پیامها را
بهطور
محلی
پردازش
کند، و
بنابراین DNSSEC
را
اعتبارسنجی
نکرده و LLMNR/MulticastDNS
را ارائه
نمیدهد. (با
این حال در
صورت نیاز،
ارتباط را
به پروتکل
DNS-over-TLS تبدیل
خواهد کرد.)
سرورهای DNS
مورد تماس
بر اساس
تنظیمات
سراسری در
/etc/systemd/resolved.conf،
تنظیمات
ایستا به
ازای هر
پیوند در
فایلهای
/etc/systemd/network/*.network (در
صورتی که از
systemd-networkd.service(8)
استفاده
شود)،
تنظیمات
پویای به
ازای هر
پیوند
دریافتی از
طریق DHCP،
اطلاعات
ارائهشده
از طریق resolvectl(1)
و هرگونه
اطلاعات
سرور DNS که
توسط سایر
سرویسهای
سیستمی در
دسترس قرار
گرفته است،
تعیین
میشوند.
برای
جزئیات
مربوط به
فایلهای
پیکربندی
خود systemd برای
سرورهای DNS،
به resolved.conf(5) و systemd.network(5)
مراجعه
کنید. برای
بهبود
سازگاری،
/etc/resolv.conf جهت کشف
سرورهای DNS
پیکربندیشده
سیستم
خوانده
میشود،
اما تنها در
صورتی که یک
پیوند
نمادین (symlink) به
/run/systemd/resolve/stub-resolv.conf، /usr/lib/systemd/resolv.conf
یا /run/systemd/resolve/resolv.conf
نباشد (به
زیر مراجعه
کنید).
systemd-resolved
رکوردهای
منبع (RRها) DNS را
برای موارد
زیر به صورت
ساختگی (synthesize)
تولید
میکند:
•نام
میزبان
محلی و
پیکربندیشده
به تمام
نشانیهای IP
محلی
پیکربندیشده
به ترتیب
دامنه (scope)
آنها
تفکیک
میشود، یا
— در صورتی
که هیچ
نشانیای
پیکربندی
نشده باشد —
به نشانی IPv4
با مقدار 127.0.0.2
(که روی رابط
لوپبک
محلی است) و
نشانی IPv6 با
مقدار ::1 (که
میزبان
محلی است)
تفکیک
میگردد.
•نامهای
میزبان "localhost"
و "localhost.localdomain" و
همچنین هر
نام
میزبانی که
به ".localhost" یا
".localhost.localdomain" ختم
شود، به
نشانیهای IP
با مقادیر 127.0.0.1
و ::1 تفکیک
میشوند.
•نام
میزبان "_gateway"
به تمام
نشانیهای
درگاه (gateway)
مسیریابی
پیشفرض
فعلی، به
ترتیب سنجه
(metric) آنها
تفکیک
میشود. این
کار یک نام
میزبان
پایدار به
درگاه فعلی
اختصاص
میدهد که
برای ارجاع
به آن مستقل
از وضعیت
پیکربندی
فعلی شبکه
مفید است.
•نام
میزبان "_outbound"
به
نشانیهای IPv4
و IPv6 محلی که
به احتمال
زیاد برای
ارتباط با
سایر
میزبانها
استفاده
میشوند،
تفکیک
میگردد.
این
نشانیها
همان
نشانیهای
مبدأ
ترجیحی
درگاههای
پیشفرض در
صورت مشخص
شدن هستند،
یا با
درخواست یک
تصمیمگیری
مسیریابی
برای
درگاههای
پیشفرض
پیکربندیشده
از هسته و
سپس
استفاده از
نشانیهای IP
محلی
انتخابشده
توسط این
تصمیمگیری
تعیین
میشوند.
این نام
میزبان
تنها در
صورتی در
دسترس است
که حداقل یک
درگاه
پیشفرض
محلی
پیکربندی
شده باشد.
این کار یک
نام میزبان
پایدار به
نشانیهای IP
خروجی محلی
اختصاص
میدهد که
برای ارجاع
به آنها
مستقل از
وضعیت
پیکربندی
شبکه فعلی
سودمند
است.
•نام
میزبان "_localdnsstub"
به نشانی IP با
مقدار 127.0.0.53،
یعنی
نشانیای
که خادم
فرعی محلی DNS
(به بالا
مراجعه
کنید) روی آن
گوش
میدهد،
تفکیک
میشود.
•نام
میزبان "_localdnsproxy"
به نشانی IP با
مقدار 127.0.0.54،
یعنی
نشانیای
که پروکسی
محلی DNS (به
بالا
مراجعه
کنید) روی آن
گوش
میدهد،
تفکیک
میشود.
•نگاشتهای
تعریفشده
در /etc/hosts به
نشانیهای
پیکربندیشدهشان
و برعکس
تفکیک
میشوند،
اما بر
جستجوهای
مربوط به
انواع
غیرنشانی
(مانند MX)
تأثیری
نخواهند
داشت.
پشتیبانی
از /etc/hosts را
میتوان با
ReadEtcHosts=no
غیرفعال
کرد، به
resolved.conf(5)
مراجعه
کنید.
درخواستهای
جستجویی که
systemd-resolved.service دریافت
میکند، بر
اساس قواعد
زیر به
سرورهای DNS
موجود، و
رابطهای LLMNR
و MulticastDNS هدایت
میشوند:
•نامهایی
که
رکوردهای
ساختگی
برای آنها
تولید
میشود (نام
میزبان
محلی، "localhost" و
"localdomain"، درگاه
محلی،
همانطور
که در بخش
پیش فهرست
شد) و
نشانیهای
پیکربندیشده
در /etc/hosts هرگز به
شبکه هدایت
نمیشوند و
یک پاسخ
بلافاصله
ارسال
میگردد.
•نامهای
تکبخشی (Single-label)
با استفاده
از LLMNR روی
تمامی
رابطهای
محلی که LLMNR در
آنها فعال
است تفکیک
میشوند.
جستجوها
برای
نشانیهای IPv4
تنها از
طریق LLMNR روی IPv4 و
جستجوها
برای
نشانیهای IPv6
تنها از
طریق LLMNR روی IPv6
ارسال
میگردند.
توجه داشته
باشید که
جستجوها
برای
نامهای
ساختگی
تکبخشی به
LLMNR، MulticastDNS یا DNS
تکپخشی
هدایت
نمیشوند.
•پرسوجوها
برای
رکوردهای
نشانی (A و AAAA)
نامهای
تکبخشی
غیرساختگی
از طریق DNS
تکپخشی (unicast)
با استفاده
از
دامنههای
جستجو (search domains)
تفکیک
میشوند.
برای هر
رابطی که
دامنههای
جستجو
تعریف کرده
باشد، چنین
جستجوهایی
به سرورهای
تعریفشده
برای آن
رابط هدایت
میشوند و
با هر یک از
آن
دامنههای
جستجو
پسوندگذاری
میگردند.
هنگامی که
دامنههای
جستجوی
سراسری
تعریف شده
باشند، این
جستجوها به
سرورهای
سراسری
هدایت
میشوند.
برای هر
دامنه
جستجو،
پرسوجوها
با افزودن
هر یک از
دامنههای
جستجو به
نوبت به
انتهای نام
انجام
میشوند.
علاوه بر
این،
جستجوی
نامهای
تکبخشی از
طریق DNS
تکپخشی را
میتوان با
تنظیم ResolveUnicastSingleLabel=yes
فعال کرد.
جزئیات
مربوط به
اینکه کدام
سرورها
مورد
پرسوجو
قرار
میگیرند و
پاسخ نهایی
چگونه
انتخاب
میشود، در
ادامه شرح
داده شده
است. توجه
داشته
باشید این
بدین
معناست که
پرسوجوهای
نشانی برای
نامهای
تکبخشی
بهطور
پیشفرض
هرگز به
سرورهای
راه دور DNS
ارسال
نمیشوند و
تفکیک تنها
در صورتی
امکانپذیر
است که
دامنههای
جستجو
تعریف شده
باشند.
•نامهای
چندبخشی (Multi-label)
با پسوند
دامنهٔ ".local"
با استفاده
از MulticastDNS روی
تمامی
رابطهای
محلی که MulticastDNS
در آنها
فعال است
تفکیک
میشوند.
همانند LLMNR،
جستجوهای
نشانی IPv4 از
طریق IPv4 و
جستجوهای
نشانی IPv6 از
طریق IPv6 ارسال
میگردند.
•پرسوجوها
برای
نامهای
چندبخشی از
طریق DNS
تکپخشی
روی
رابطهای
محلی که
سرور DNS برای
آنها
پیکربندی
شده است، به
علاوه
سرورهای DNS
پیکربندیشدهٔ
سراسری (در
صورت وجود)
هدایت
میشوند.
اینکه از
کدام
رابطها
استفاده
شود، بر
اساس منطق
مسیریابی
مبتنی بر
دامنههای
جستجو و
دامنههای
صرفاً
مسیریابی (route-only)
که در زیر
شرح داده
شده، تعیین
میگردد.
توجه داشته
باشید که
بهطور
پیشفرض،
جستجوها
برای
دامنههای
دارای
پسوند ".local" به
سرورهای DNS
هدایت
نمیشوند،
مگر اینکه
آن دامنه به
صراحت به
عنوان
دامنهٔ
مسیریابی
یا جستجو
برای سرور DNS و
رابط مشخص
شده باشد.
این بدان
معناست که
در
شبکههایی
که دامنهٔ
".local" در یک
سرور DNS ویژهٔ
آن پایگاه
تعریف شده
است، باید
دامنههای
جستجو یا
مسیریابی
صریح
پیکربندی
شوند تا
جستجوها در
آن دامنه DNS
کار کنند.
توجه داشته
باشید که
امروزه
عموماً
توصیه
میشود از
تعریف ".local" در
سرور DNS
خودداری
شود، زیرا
RFC6762[2] این
دامنه را
منحصراً
برای
استفاده MulticastDNS
رزرو کرده
است.
•جستجوهای
نشانی
(جستجوهای
معکوس یا reverse lookups)
مشابه با
نامهای
چندبخشی
هدایت
میشوند،
با این
استثنا که
نشانیهای
محدوده
نشانی
پیوند-محلی
هرگز به DNS
تکپخشی
هدایت
نمیشوند و
تنها با
استفاده از
LLMNR و MulticastDNS (در صورت
فعال بودن)
تفکیک
میگردند.
اگر
جستجوها به
چندین رابط
هدایت
شوند،
نخستین
پاسخ موفق
بازگردانده
میشود
(بدین ترتیب
مناطق
جستجو روی
تمامی
رابطهای
منطبق
عملاً با
یکدیگر
ادغام
میشوند).
اگر جستجو
روی همهٔ
رابطها با
شکست مواجه
شود، آخرین
پاسخ
ناموفق
بازگردانده
میشود.
مسیریابی
جستجوها
توسط
دامنههای
مسیریابی
به ازای هر
رابط (جستجو
و صرفاً
مسیریابی) و
دامنههای
جستجوی
سراسری
تعیین
میشود.
برای شرح
چگونگی
تنظیم
پویای این
گزینهها
به systemd.network(5) و resolvectl(1)
و برای بحث
دربارهٔ Domains=
در resolved.conf(5) جهت
شرح
تنظیمات DNS
پیکربندیشده
سراسری
مراجعه
کنید.
منطق
مسیریابی
پرسوجوی
زیر برای
جستجوهای DNS
تکپخشی که
توسط systemd-resolved.service
آغاز
میشوند
اعمال
میگردد:
•اگر یک
نام مورد
جستجو با هر
یک از
دامنههای
مسیریابی
پیکربندیشده
(جستجو یا
صرفاً
مسیریابی)
در هر
پیوند، یا
تنظیمات DNS
سراسری
پیکربندیشده
مطابقت
داشته باشد
(یعنی: برابر
با آن باشد
یا آن را به
عنوان
پسوند
داشته
باشد)،
«بهترین
دامنهٔ
منطبق»
تعیین
میشود:
دامنه
منطبقی که
بیشترین
برچسبها (labels)
را دارد. سپس
پرسوجو به
تمام
سرورهای DNS در
هر پیوند یا
سرورهای DNS
سراسریِ
پیکربندیشده
مرتبط با
این
«بهترین
دامنه
منطبق»
ارسال
میگردد.
(توجه داشته
باشید که
ممکن است
بیش از یک
پیوند
دارای همین
«بهترین
دامنه
منطبق»
پیکربندی
شده باشد،
که در این
صورت
پرسوجو به
همهٔ آنها
به صورت
موازی
ارسال
میشود).
در مورد
نامهای
تکبخشی،
هنگامی که
دامنههای
جستجو
تعریف شده
باشند،
همین منطق
اعمال
میشود، با
این تفاوت
که ابتدا
نام با هر یک
از
دامنههای
جستجو به
نوبت
پسوندگذاری
میگردد.
توجه داشته
باشید که
این منطق
جستجو برای
نامهایی
با حداقل یک
نقطه اعمال
نمیشود.
همچنین بحث
مربوط به
سازگاری با
تفکیککننده
سنتی glibc در
زیر را
ببینید.
•اگر
پرسوجویی
با هیچیک
از
دامنههای
مسیریابی
پیکربندیشده
(چه به ازای
هر پیوند یا
سراسری)
مطابقت
نداشته
باشد، به
تمامی
سرورهای DNS که
روی
پیوندهای
پیکربندیشده
به عنوان
مسیر
پیشفرض
تنظیم
شدهاند و
همچنین
سرور DNS
پیکربندیشده
سراسری
ارسال
میشود.
•اگر هیچ
سرور DNS روی
هیچ پیوندی
که به عنوان
مسیر
پیشفرض
نیز
پیکربندی
شده باشد
وجود
نداشته
باشد و هیچ
سرور DNS
سراسری نیز
پیکربندی
نشده باشد،
یکی از
سرورهای DNS
جایگزینِ
درونساخت
(fallback) استفاده
میشود.
•در غیر
این صورت،
پرسوجوی DNS
تکپخشی با
شکست مواجه
میشود،
زیرا هیچ
سرور DNS
مناسبی
تعیین
نمیگردد.
اینکه یک
پیوند مسیر
پیشفرض
است یا خیر
را میتوان
با دستور resolvectl
default-route یا تنظیم
DNSDefaultRoute= در
فایلهای .network
پیکربندی
کرد. در صورت
عدم
پیکربندی
صریح، بر
اساس
دامنههای DNS
پیکربندیشده
برای یک
پیوند
بهطور
ضمنی تعیین
میشود: اگر
یک دامنهٔ
صرفاً
مسیریابی
غیر از "~."
وجود داشته
باشد،
مقدار
پیشفرض آن
نادرست (false) و
در غیر این
صورت درست (true)
خواهد بود.
در عمل این
بدان
معناست: به
منظور
پشتیبانی
از نامهای
تکبخشی
غیرساختگی،
دامنههای
جستجوی
مناسب را
تعریف کنید.
به منظور
هدایت
ترجیحی
تمام
پرسوجوهای
DNS که بهطور
صریح با
پیکربندی
دامنهٔ
مسیریابی
مطابقت
ندارند به
یک پیوند
خاص، یک
دامنهٔ
صرفاً
مسیریابی
"~." روی آن
پیکربندی
کنید. این
کار تضمین
میکند که
سایر
پیوندها
برای این
پرسوجوها
در نظر
گرفته
نخواهند شد
(مگر اینکه
آنها نیز
چنین
دامنهٔ
مسیریابی
را داشته
باشند). برای
هدایت تمام
این
پرسوجوهای
DNS به یک
پیوند خاص
تنها در
صورتی که
هیچ پیوند
دیگری
ترجیح داده
نشده باشد،
پیوند را به
عنوان مسیر
پیشفرض
پیکربندی
کنید و
دامنهٔ
صرفاً
مسیریابی
"~." را روی آن
پیکربندی
نکنید. در
نهایت، به
منظور
جلوگیری از
دریافت
هرگونه
ترافیک DNS
توسط یک
پیوند خاص
که با
هیچیک از
دامنههای
مسیریابی
پیکربندیشده
آن مطابقت
ندارد، آن
را به یک
مسیر
پیشفرض
تبدیل
نکنید.
برای
اطلاعات
درباره
رابطهای
برنامهنویسی
D-Bus که systemd-resolved
ارائه
میدهد، به
org.freedesktop.resolve1(5)
مراجعه
کنید.
این بخش
خلاصهای
کوتاه از
تفاوتهای
تفکیککنندهٔ
پیادهسازیشده
توسط nss-resolve(8)
همراه با
systemd-resolved و
تفکیککنندهٔ
فرعی سنتی
پیادهسازیشده
در nss-dns را
ارائه
میدهد.
•برخی
نامها
همواره به
صورت داخلی
تفکیک
میشوند (به
بخش
رکوردهای
ساختگی در
بالا
مراجعه
کنید).
بهطور
سنتی در
صورتی که
این نامها
در /etc/hosts ارائه
شده بودند،
توسط nss-files
تفکیک
میشدند.
اما توجه
داشته
باشید که
جزئیات
چگونگی
ساخته شدن
یک پرسوجو
تحت کنترل
کتابخانهٔ
کلاینت است.
nss-dns ابتدا
تلاش
میکند
نامها را
با استفاده
از
دامنههای
جستجو
تفکیک کند و
حتی اگر آن
پرسوجوها
به systemd-resolved هدایت
شوند،
آنها را با
استفاده از
قواعد
معمول برای
مسیریابی
نامهای
چندبخشی از
طریق شبکه
به بیرون
ارسال
خواهد کرد [3].
•نامهای
تکبخشی
برای
رکوردهای A و
AAAA با استفاده
از DNS تکپخشی
تفکیک
نمیشوند
(مگر اینکه
با
ResolveUnicastSingleLabel= لغو
شده باشد،
به
resolved.conf(5)
مراجعه
کنید). این
شبیه به
تنظیم
گزینهٔ
no-tld-query
در
resolv.conf(5) است.
•دامنههای
جستجو برای
پسوندگذاری
(suffixing) نامهای
چندبخشی
استفاده
نمیشوند.
(با این حال
دامنههای
جستجو برای
مسیریابی
جستجو،
برای
نامهایی
که در ابتدا
به صورت
تکبخشی یا
چندبخشی
مشخص شده
بودند
استفاده
میشوند). هر
نامی که
حداقل یک
نقطه داشته
باشد
همواره به
عنوان یک
نام دامنه
کاملاً
واجد شرایط
(FQDN) تفسیر
میشود. nss-dns
نامها را
هم به عنوان
نسبی (با
استفاده از
دامنههای
جستجو) و هم
به عنوان
نامهای FQDN
مطلق تفکیک
میکرد.
برخی
نامها
ابتدا به
صورت نسبی و
پس از
ناموفق
بودن آن
پرسوجو،
به صورت
مطلق تفکیک
میشدند،
در حالی که
نامهای
دیگر به
ترتیب
معکوس
تفکیک
میشدند.
گزینهٔ ndots در
/etc/resolv.conf برای
کنترل
اینکه نام
به چند نقطه
نیاز دارد
تا ابتدا به
صورت نسبی
تفکیک شود،
استفاده
میشد. این
تفکیککنندهٔ
فرعی این
رفتار را
اصلاً
پیادهسازی
نمیکند:
نامهای
چندبخشی
تنها به
عنوان FQDN
تفکیک
میشوند[4].
•این
تفکیککننده
شناختی از
دامنهٔ
ویژهٔ ".local"
مورد
استفاده
برای MulticastDNS
دارد، و
پرسوجوهای
دارای این
پسوند را به
سرورهای DNS
تکپخشی
هدایت
نمیکند
مگر اینکه
صراحتاً
پیکربندی
شده باشد،
به بالا
مراجعه
کنید.
همچنین،
جستجوهای
معکوس برای
نشانیهای
پیوند-محلی
به سرورهای DNS
تکپخشی
ارسال
نمیشوند.
•این
تفکیککننده
/etc/hosts را به صورت
داخلی
خوانده و در
حافظه موقت
(کش) قرار
میدهد. (به
عبارت
دیگر، nss-resolve
علاوه بر nss-dns،
جایگزین nss-files
نیز میشود).
مدخلهای
موجود در /etc/hosts
دارای
بالاترین
اولویت
هستند.
•این
تفکیککننده
علاوه بر
پروتکل
کلاسیک DNS
تکپخشی، LLMNR
و MulticastDNS را نیز
پیادهسازی
میکند، و
نامهای
تکبخشی را
با استفاده
از LLMNR (در صورت
فعال بودن) و
نامهای
ختمشده به
".local" را با
استفاده از
MulticastDNS (در صورت
فعال بودن)
تفکیک
خواهد کرد.
•متغیرهای
محیطی
$LOCALDOMAIN و
$RES_OPTIONS توضیح
داده شده در
resolv.conf(5) در حال
حاضر
پشتیبانی
نمیشوند.
•تفکیککنندهٔ
nss-dns وضعیت
بسیار کمی
را بین
پرسوجوهای
متوالی DNS
نگهداری
میکند، و
برای هر
پرسوجو
همیشه
ابتدا با
نخستین
سرور DNS
فهرستشده
از /etc/resolv.conf گفتگو
میکند، و
در صورت
شکست با
سرور بعدی
ادامه
میدهد تا
به انتهای
فهرست برسد
که در آن
هنگام
پرسوجو با
شکست مواجه
میشود.
تفکیککننده
در systemd-resolved با
این حال
وضعیت را
حفظ
میکند، و
برای تمام
پرسوجوها
در یک
محدودهٔ
جستجوی
خاص،
پیوسته با
همان سرور
گفتگو
خواهد کرد
تا زمانی که
نوعی خطا
مشاهده
شود، که در
این نقطه به
سرور بعدی
سوئیچ
میکند، و
سپس برای
تمام
پرسوجوها
در آن
محدوده روی
آن باقی
میماند تا
شکست بعدی
رخ دهد، و به
همین ترتیب
ادامه
میدهد تا
در نهایت به
نخستین
سرور
پیکربندیشده
بازگردد.
این کار
برای
بهینهسازی
زمانهای
جستجو
انجام
میشود،
بهویژه با
توجه به
اینکه
تفکیککننده
هنگام
گفتگو با یک
سرور
معمولاً
ابتدا باید
مجموعه
ویژگیهای
سرور را
بررسی کند،
که زمانبر
است. این
رفتار
متفاوت
ایجاب
میکند که
سرورهای DNS
فهرستشده
به ازای هر
محدودهٔ
جستجو در
مناطقی (zones) که
به آنها
سرویس
میدهند
معادل
باشند، به
طوری که
ارسال یک
پرسوجو به
یکی از
آنها
نتایج
یکسانی با
ارسال آن به
سرور DNS
پیکربندیشدهٔ
دیگری به
همراه
داشته
باشد.
چهار حالت
مدیریت /etc/resolv.conf
(به resolv.conf(5)
مراجعه
کنید)
پشتیبانی
میشود:
•systemd-resolved
فایل /run/systemd/resolve/stub-resolv.conf
را جهت
سازگاری با
برنامههای
سنتی
لینوکس
نگهداری
میکند. این
فایل،
تفکیککنندهٔ
فرعی DNS روی 127.0.0.53
(به بالا
مراجعه
کنید) را به
عنوان تنها
سرور DNS فهرست
میکند.
همچنین
شامل
فهرستی از
دامنههای
جستجو است
که توسط systemd-resolved
استفاده
میشوند.
فهرست
دامنههای
جستجو
همواره
بهروز نگه
داشته
میشود.
توجه داشته
باشید که
/run/systemd/resolve/stub-resolv.conf نباید
مستقیماً
توسط
برنامهها
استفاده
شود، بلکه
تنها از
طریق یک
پیوند
نمادین از
/etc/resolv.conf به کار
رود. این
فایل
میتواند
از /etc/resolv.conf پیوند
نمادین
داده شود تا
تمامی
کلاینتهای
محلی که APIهای
محلی DNS را دور
میزنند،
با تنظیمات
صحیح
دامنههای
جستجو به
systemd-resolved متصل
شوند. این
حالت
عملیاتی
توصیه
میشود.
•یک فایل
ایستا به
نام /usr/lib/systemd/resolv.conf
ارائه شده
است که
تفکیککنندهٔ
فرعی DNS روی 127.0.0.53
(به بالا
مراجعه
کنید) را به
عنوان تنها
سرور DNS فهرست
میکند. این
فایل
میتواند
از /etc/resolv.conf پیوند
نمادین
داده شود تا
تمامی
کلاینتهای
محلی که APIهای
محلی DNS را دور
میزنند به
systemd-resolved متصل
شوند. این
فایل شامل
هیچ دامنهٔ
جستجویی
نیست.
•systemd-resolved
فایل /run/systemd/resolve/resolv.conf
را جهت
سازگاری با
برنامههای
سنتی
لینوکس
نگهداری
میکند. این
فایل
میتواند
از /etc/resolv.conf پیوند
نمادین
داده شود و
همواره
بهروز نگه
داشته
میشود، و
حاوی
اطلاعاتی
دربارهٔ
تمامی
سرورهای
شناختهشدهٔ
DNS است. به
محدودیتهای
قالب این
فایل توجه
داشته
باشید:
قالبی از
مفهوم
سرورهای DNS به
ازای هر
رابط
نمیشناسد
و بنابراین
تنها شامل
تعاریف
سرور DNS در سطح
سیستم است.
توجه داشته
باشید که
/run/systemd/resolve/resolv.conf نباید
مستقیماً
توسط
برنامهها
استفاده
شود، بلکه
تنها از
طریق یک
پیوند
نمادین از
/etc/resolv.conf به کار
رود. اگر از
این حالت
عملیاتی
استفاده
شود،
کلاینتهای
محلی که
هرگونه API
محلی DNS را دور
میزنند،
همچنین systemd-resolved
را نیز دور
خواهند زد و
مستقیماً
با سرورهای DNS
شناختهشده
گفتگو
میکنند.
•به
عنوان روش
دیگر، /etc/resolv.conf
ممکن است
توسط سایر
بستهها
مدیریت
شود، که در
این صورت
systemd-resolved آن را
برای
دادههای
پیکربندی DNS
خواهد
خواند. در
این حالت
عملیاتی
systemd-resolved به جای
ارائهدهنده،
مصرفکنندهٔ
این فایل
پیکربندی
است.
توجه
داشته
باشید که
حالت
عملیاتی
انتخابشده
برای این
فایل
بهطور
کاملاً
خودکار
شناسایی
میشود،
بسته به
اینکه /etc/resolv.conf یک
پیوند
نمادین به
/run/systemd/resolve/resolv.conf باشد
یا 127.0.0.53 را به
عنوان سرور
DNS فهرست
کرده باشد.
SIGUSR1
به محض
دریافت
سیگنال
فرآیند
SIGUSR1،
systemd-resolved
محتویات
تمامی
حافظههای
موقت (کشها)
رکوردهای
منبع DNS را که
نگهداری
میکند، و
همچنین
تمامی
اطلاعات
سطح ویژگی
را که
دربارهٔ
سرورهای DNS
پیکربندیشده
آموخته است
در لاگهای
سیستم
تخلیه
میکند (dump
مینماید).
افزودهشده
در نسخهٔ 231.
SIGUSR2
به محض
دریافت
سیگنال
فرآیند
SIGUSR2،
systemd-resolved تمام
حافظههای
موقت (کشها)
که نگهداری
میکند را
پاکسازی (flush)
خواهد کرد.
توجه داشته
باشید که
معمولاً
درخواست
صریح این
مورد ضروری
نیست – مگر
برای اهداف
اشکالزدایی
– زیرا
systemd-resolved
به هر حال هر
بار که
پیکربندی
شبکهٔ
میزبان
تغییر
میکند،
حافظههای
موقت را به
صورت
خودکار
پاکسازی
مینماید.
ارسال این
سیگنال به
systemd-resolved معادل
با دستور
resolvectl
flush-caches است، با
این حال
دومی توصیه
میشود
زیرا به
صورت همگام
(synchronous) عمل
میکند.
افزودهشده
در نسخهٔ 231.
SIGRTMIN+1
به محض
دریافت
سیگنال
فرآیند
SIGRTMIN+1،
systemd-resolved هر آنچه
را که
درباره
سرورهای DNS
پیکربندیشده
آموخته است
فراموش
خواهد کرد.
بهویژه
هرگونه
اطلاعات
دربارهٔ
پشتیبانی
از
ویژگیهای
سرور
پاکسازی
میشود، و
منطق بررسی
ویژگیهای
سرور در
درخواست
بعدی
مجدداً
راهاندازی
میشود و با
کاملترین
سطح
ویژگیها
آغاز
میگردد.
توجه داشته
باشید که
معمولاً
درخواست
صریح این
مورد ضروری
نیست – مگر
برای اهداف
اشکالزدایی
– زیرا
systemd-resolved
به صورت
خودکار با
هر بار
تغییر
پیکربندی
سرور DNS،
اطلاعات
آموختهشده
را فراموش
میکند.
ارسال این
سیگنال به
systemd-resolved معادل
با دستور
resolvectl
reset-server-features است، با
این حال
دومی توصیه
میشود
زیرا به
صورت همگام
عمل میکند.
افزودهشده
در نسخهٔ 235.
SIGHUP
به محض
دریافت
سیگنال
فرآیند
SIGHUP،
systemd-resolved تمام
حافظههای
موقتی را که
نگهداری
میکند
پاکسازی
خواهد کرد،
تمام
اتصالات
باز TCP (در
صورت وجود)
را قطع
نموده، و
فایلهای
پیکربندی
خود را
دوباره
بارگذاری
میکند.
افزودهشده
در نسخهٔ 256.
systemd-resolved از
منطق
اعتبارنامههای
سرویس
همانطور
که توسط
ImportCredential=/LoadCredential=/SetCredential=
پیادهسازی
شده است
پشتیبانی
میکند
(برای
جزئیات به
systemd.exec(5) مراجعه
کنید).
اعتبارنامههای
زیر در صورت
ارسال
استفاده
میشوند:
network.dns, network.search_domains
میتواند
حاوی
فهرستی از
نشانیهای IP
سرور DNS و
دامنههای
جستجوی DNS
باشد که با
فاصله از هم
جدا
شدهاند.
این
اطلاعات
تنها زمانی
استفاده
میشود که
هیچ
پیکربندی
صریحی از
طریق /etc/systemd/resolved.conf،
/etc/resolv.conf یا خط
فرمان هسته
ارائه نشده
باشد.
افزودهشده
در نسخهٔ 253.
systemd-resolved
همچنین از
دو گزینهٔ
خط فرمان
هسته پیروی
میکند:
nameserver=, domain=
نشانی IP
یک سرور DNS (در
مورد
nameserver=) و یک
دامنهٔ
جستجوی DNS (در
مورد
domain=) را
میپذیرد.
میتواند
چندین بار
برای تعریف
چندین سرور
DNS/دامنهٔ
جستجو
استفاده
شود. اگر هر
یک از این
گزینهها
مشخص شوند،
/etc/resolv.conf خوانده
نخواهد شد و
تنظیمات
DNS= و
Domains= در
resolved.conf(5)
نادیده
گرفته
میشوند.
بنابراین
این دو
گزینهٔ خط
فرمان
هسته،
پیکربندی
سیستم را
لغو (override)
میکنند.
افزودهشده
در نسخهٔ 253.
سرویس systemd-resolved
روی
درگاههای IP
زیر گوش
میدهد:
•درگاه 53
روی
نشانیهای IPv4
با مقادیر 127.0.0.53
و 127.0.0.54 (هر دو
روی رابط
لوپبک
محلی "lo"). این
همان
تفکیککنندهٔ
فرعی محلی DNS
است،
همانطور
که در بالا
مورد بحث
قرار گرفت.
هر دو
پروتکل UDP و TCP
تحت پوشش
هستند.
•درگاه 5353
روی تمامی
نشانیهای
محلی، هم IPv4 و
هم IPv6 (مقادیر
0.0.0.0 و ::0)، برای MulticastDNS
روی UDP. توجه
داشته
باشید
اگرچه سوکت
از طریق
نشانیهای IP
نویسه
عمومی (wildcard) به
تمامی
رابطهای
محلی مقید
شده است،
اما
دیتاگرامهای
ورودی توسط
رابط
شبکهای که
از آن وارد
میشوند
فیلتر
میگردند،
و
دامنههای
پیوند-محلی
مجزای MulticastDNS
برای هر یک
نگهداری
میشود و با
در نظر
گرفتن
اینکه MulticastDNS
برای آن
رابط فعال
است یا خیر،
عمل
میکند.
•درگاه 5355
روی تمامی
نشانیهای
محلی، هم IPv4 و
هم IPv6 (مقادیر
0.0.0.0 و ::0)، برای LLMNR،
روی هر دو
پروتکل TCP و UDP.
همانند MulticastDNS
فیلتر کردن
بر اساس
رابط شبکه
ورودی
اعمال
میشود.
- 1.
- RFC3493
- 2.
- RFC6762
- 3.
- برای
نمونه، اگر
/etc/resolv.conf حاوی این
مورد باشد:
nameserver 127.0.0.53
search foobar.com barbar.com
و ما "localhost" را
جستجو
کنیم، nss-dns
پرسوجوهای
زیر را به systemd-resolved
که روی 127.0.0.53:53
گوش میدهد
ارسال
خواهد کرد:
ابتدا
"localhost.foobar.com"، سپس
"localhost.barbar.com"، و در
نهایت "localhost".
اگر
(امیدوارانه)
دو
پرسوجوی
اول ناموفق
باشند، systemd-resolved
پاسخی را
برای
پرسوجوی
سوم به صورت
ساختگی (synthesize)
تولید
خواهد کرد.
هنگام
استفاده از
nss-dns با هرگونه
دامنه
جستجو،
بنابراین
بسیار
حیاتی است
که همواره nss-files
با اولویت
بالاتر
پیکربندی
شود و
نگاشتهایی
برای
نامهایی
که نباید با
استفاده از
دامنههای
جستجو
تفکیک شوند
ارائه دهد.
- 4.
- در حال حاضر
بیش از ۱۵۰۰
نام دامنه
سطح بالا
تعریف شده
است، و
موارد جدید
مرتباً
اضافه
میشوند،
که اغلب از
نامهای
«جذاب»
استفاده
میکنند که
احتمالاً
به صورت
محلی نیز
استفاده
میشوند.
عدم جستجوی
نامهای
چندبخشی به
این شیوه از
شکنندگی در
هر دو جهت
جلوگیری
میکند: یک
نام معتبر
سراسری
میتواند
توسط یک نام
محلی مبهم
شود، و
تفکیک یک
نام محلی
نسبی ممکن
است هنگام
ایجاد یک
دامنه سطح
بالای جدید
یا هنگام
ثبت یک
زیردامنه
جدید از یک
دامنه سطح
بالا در
رجیستری،
ناگهان از
کار بیفتد.
تفکیک هر
نام
دادهشده
به عنوان
نسبی یا
مطلق از این
ابهام
جلوگیری
میکند.
