Scroll to navigation

SYSTEMD-RESOLVED.SERVICE(8) systemd-resolved.service SYSTEMD-RESOLVED.SERVICE(8)

الاسم

systemd-resolved.service، systemd-resolved - مدير تحليل أسماء الشبكة

موجز

systemd-resolved.service

/usr/lib/systemd/systemd-resolved

الوصف

systemd-resolved هي خدمة نظام توفر تحليل أسماء الشبكة للتطبيقات المحلية. تنفذ محللًا ناقصًا (stub resolver) يُجري التخزين في خبيئة والمصادقة لـ DNS/DNSSEC، بالإضافة إلى محلل ومستجيب لـ LLMNR وMulticastDNS. يمكن للتطبيقات المحلية تقديم طلبات تحليل أسماء الشبكة عبر ثلاث واجهات:

•واجهة برمجة التطبيقات الأصلية كاملة الميزات التي يعرضها systemd-resolved عبر D-Bus، انظر org.freedesktop.resolve1(5) وorg.freedesktop.LogControl1(5) للتفاصيل. يُوصى عمومًا باستخدام هذه الواجهة للعملاء لأنها غير متزامنة وكاملة الميزات (على سبيل المثال، تُرجع حالة مصادقة DNSSEC ونطاق الواجهة للعناوين حسب الحاجة لدعم الشبكات المحلية الرابطة).

•واجهة برمجة التطبيقات الأصلية التي يعرضها systemd-resolved عبر Varlink على مقبس /run/systemd/resolve/io.systemd.Resolve AF_UNIX. توفر وظائف مشابهة لواجهة D-Bus، لكنها متاحة طوال وقت التشغيل، دون الحاجة إلى خدمة وسيط ناقل نظام D-Bus قيد التشغيل.

•واجهة برمجة التطبيقات getaddrinfo(3) من glibc كما هو معرف بواسطة RFC3493[1] ووظائف المحلل المرتبطة بها، بما في ذلك gethostbyname(3). هذه الواجهة مدعومة على نطاق واسع، بما في ذلك خارج منصة Linux. في شكلها الحالي، لا تعرض معلومات حالة مصادقة DNSSEC، وهي متزامنة فقط. هذه الواجهة مدعومة بواسطة مبدل خدمة الأسماء (nss(5)) من glibc. استخدام وحدة NSS من glibc nss-resolve(8) مطلوب للسماح لوظائف محلل NSS من glibc بتحليل أسماء المضيفين عبر systemd-resolved.

•بالإضافة إلى ذلك، يوفر systemd-resolved مستمعًا محليًا لـ DNS stub على عناوين IP 127.0.0.53 و127.0.0.54 على واجهة الاسترجاع المحلية. يمكن توجيه البرامج التي تصدر طلبات DNS مباشرة، متجاوزة أي واجهة محلية، إلى هذا الـ stub، لربطها بـ systemd-resolved. لاحظ مع ذلك أنه يُوصى بشدة أن تستخدم البرامج المحلية واجهات glibc NSS أو الناقل بدلاً من ذلك (كما هو موضح أعلاه)، حيث لا يمكن تعيين مفاهيم تحليل الشبكة المختلفة (مثل العنونة المحلية الرابطة، أو نطاقات Unicode لـ LLMNR) إلى بروتوكول DNS أحادي الإرسال.

يوفر محلل DNS الناقص (stub resolver) على 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 متاحة من خدمات النظام الأخرى. انظر resolved.conf(5) وsystemd.network(5) للتفاصيل حول ملفات تكوين systemd الخاصة لخوادم DNS. لتحسين التوافق، يُقرأ /etc/resolv.conf لاكتشاف خوادم DNS النظامية المُهيأة، ولكن فقط إذا لم يكن رابطًا رمزيًا إلى /run/systemd/resolve/stub-resolv.conf أو /usr/lib/systemd/resolv.conf أو /run/systemd/resolve/resolv.conf (انظر أدناه).

السجلات الاصطناعية

يقوم systemd-resolved بتوليد سجلات موارد DNS (RRs) للحالات التالية:

•يُحل اسم المضيف المحلي المُهيأ إلى جميع عناوين IP المحلية المُهيأة مرتبة حسب نطاقها، أو — إذا لم يُضبط أي منها — عنوان IPv4 127.0.0.2 (الموجود على واجهة الاسترجاع المحلية) وعنوان IPv6 ::1 (وهو المضيف المحلي).

•يُحل أسماء المضيفين "localhost" و"localhost.localdomain" بالإضافة إلى أي اسم مضيف ينتهي بـ ".localhost" أو ".localhost.localdomain" إلى عناوين IP 127.0.0.1 و::1.

•يُحل اسم المضيف "_gateway" إلى جميع عناوين بوابات التوجيه المبدئية الحالية، مرتبة حسب المتري (metric) الخاص بها. يؤدي هذا إلى تعيين اسم مضيف ثابت للبوابة الحالية، وهو مفيد للإشارة إليها بشكل مستقل عن حالة إعداد الشبكة الحالية.

•يُحل اسم المضيف "_outbound" إلى عناوين IPv4 و IPv6 المحلية التي من المرجح استخدامها للتواصل مع المضيفين الآخرين. هذه هي عناوين المصدر المفضلة للبوابات المبدئية إذا حُددت، أو تُحدد عن طريق طلب قرار توجيه إلى البوابات المبدئية المهيأة من النواة ثم استخدام عناوين IP المحلية المختارة بهذا القرار. يتوفر اسم المضيف هذا فقط إذا كان هناك بوابة مبدئية محلية واحدة مهيأة على الأقل. يؤدي هذا إلى تعيين اسم مضيف ثابت لعناوين IP الصادرة المحلية، وهو مفيد للإشارة إليها بشكل مستقل عن حالة إعداد الشبكة الحالية.

•يُحل اسم المضيف "_localdnsstub" إلى عنوان IP 127.0.0.53، أي العنوان الذي يستمع عليه الـ DNS stub المحلي (انظر أعلاه).

•يُحل اسم المضيف "_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 لا تُوجّه أبدًا إلى الشبكة ويُرسل رد فوري.

•تُحل الأسماء أحادية التسمية باستخدام LLMNR على جميع الواجهات المحلية حيث يكون LLMNR مفعلًا. تُرسل عمليات البحث عن عناوين IPv4 فقط عبر LLMNR على IPv4، وتُرسل عمليات البحث عن عناوين IPv6 فقط عبر LLMNR على IPv6. لاحظ أن عمليات البحث عن الأسماء الاصطناعية أحادية التسمية لا تُوجّه إلى LLMNR أو MulticastDNS أو DNS أحادي الإرسال.

•تُحل استعلامات سجلات العناوين (A وAAAA) للأسماء غير الاصطناعية أحادية التسمية عبر DNS أحادي الإرسال باستخدام نطاقات البحث. بالنسبة لأي واجهة تحدد نطاقات بحث، تُوجه عمليات البحث هذه إلى الخوادم المعرفة لتلك الواجهة، مع إضافة لاحقة كل من نطاقات البحث تلك. عند تعريف نطاقات بحث عامة، تُوجه عمليات البحث هذه إلى الخوادم العامة. لكل نطاق بحث، تُنفذ الاستعلامات بإضافة لاحقة الاسم مع كل نطاق من نطاقات البحث بالتناوب. بالإضافة إلى ذلك، يمكن تمكين البحث عن الأسماء أحادية التسمية عبر DNS أحادي الإرسال باستخدام الإعداد ResolveUnicastSingleLabel=yes. تفاصيل أي الخوادم يُستعلم عنها وكيفية اختيار الرد النهائي موصوفة أدناه. لاحظ أن هذا يعني أن استعلامات العناوين للأسماء أحادية التسمية لا تُرسل أبدًا إلى خوادم DNS بعيدة مبدئيًا، والتحليل ممكن فقط إذا عُرفت نطاقات البحث.

•تُحل الأسماء متعددة التسميات مع لاحقة النطاق ".local" باستخدام MulticastDNS على جميع الواجهات المحلية حيث يكون MulticastDNS مفعلًا. كما هو الحال مع LLMNR، تُرسل عمليات البحث عن عناوين IPv4 عبر IPv4 وعمليات البحث عن عناوين IPv6 عبر IPv6.

•تُوجه استعلامات الأسماء متعددة التسميات عبر DNS أحادي الإرسال على الواجهات المحلية التي تملك خادم DNS مُهيئة، بالإضافة إلى خوادم DNS المُهيئة عالميًا إن وجدت. وتُحدد الواجهات المستخدمة بواسطة منطق التوجيه بناءً على نطاقات البحث ونطاقات التوجيه فقط، الموصوفة أدناه. لاحظ أنه مبدئيًا، لا تُوجه عمليات البحث عن النطاقات ذات اللاحقة ".local" إلى خوادم DNS، إلا إذا حُدد النطاق صراحةً كنطاق توجيه أو بحث لخادم DNS والواجهة. وهذا يعني أنه في الشبكات التي يُعرف فيها نطاق ".local" في خادم DNS خاص بالموقع، يجب تهيئة نطاقات بحث أو توجيه صريحة لجعل عمليات البحث تعمل داخل نطاق DNS هذا. لاحظ أنه في هذه الأيام، يُوصى عمومًا بتجنب تعريف ".local" في خادم DNS، حيث يحجز RFC6762[2] هذا النطاق لاستخدام MulticastDNS الحصري.

•تُوجه عمليات البحث عن العناوين (البحث العكسي) بشكل مشابه للأسماء متعددة التسميات، باستثناء أن العناوين من نطاق عناوين الرابط المحلي لا تُوجه أبدًا إلى DNS أحادي الإرسال وتُحل فقط باستخدام LLMNR وMulticastDNS (عند التمكين).

إذا كانت عمليات البحث موجهة إلى واجهات متعددة، تُعاد أول استجابة ناجحة (وبذلك تُدمج مناطق البحث فعليًّا على جميع الواجهات المطابقة). وإذا فشلت عملية البحث على جميع الواجهات، تُعاد آخر استجابة فاشلة.

توجيه عمليات البحث يُحدد بواسطة نطاقات التوجيه الخاصة بكل واجهة (بحث وتوجيه فقط) ونطاقات البحث العامة. انظر systemd.network(5) وresolvectl(1) لوصف كيفية تعيين هذه الإعدادات ديناميكيًا، ونقاش Domains= في resolved.conf(5) لوصف إعدادات DNS المكونة عالميًا.

المنطق التالي لتوجيه الاستعلامات ينطبق على عمليات بحث DNS أحادية الإرسال التي يبدأها systemd-resolved.service:

•إذا طابق اسم للبحث (أي: يساوي أو له كلاحقة) أيًا من نطاقات التوجيه المكونة (بحث أو توجيه فقط) لأي رابط، أو إعدادات DNS المكونة عالميًا، يُحدد نطاق التوجيه "الأفضل تطابقًا": المطابق الذي يحتوي على أكبر عدد من اللصائق. ثم يُرسل الاستعلام إلى جميع خوادم DNS لأي روابط أو خوادم DNS المكونة عالميًا المرتبطة بنطاق التوجيه "الأفضل تطابقًا". (لاحظ أن أكثر من رابط قد يكون لديه نفس نطاق التوجيه "الأفضل تطابقًا" المكون، وفي هذه الحالة يُرسل الاستعلام إلى جميعها بالتوازي).

في حالة الأسماء ذات التسمية الواحدة، عندما تُعرف نطاقات البحث، ينطبق نفس المنطق، باستثناء أن الاسم يُلحق أولاً بكل نطاق بحث بدوره. لاحظ أن منطق البحث هذا لا ينطبق على أي أسماء تحتوي على نقطة واحدة على الأقل. انظر أيضًا النقاش حول التوافق مع المحلل التقليدي glibc أدناه.

•إذا لم يطابق استعلام أي نطاق توجيه مكون (سواء لكل رابط أو عالمي)، يُرسل إلى جميع خوادم DNS المكونة على روابط مكونة كمسار مبدئي، بالإضافة إلى خادم DNS المكون عالميًا.

•إذا لم تكن هناك خوادم DNS مكونة على أي رابط مكون أيضًا كمسار مبدئي ولا خادم DNS عالمي مكون، يُستخدم أحد خوادم DNS الاحتياطية المضمنة في الترجمة.

•وإلا، يفشل استعلام DNS أحادي الإرسال، حيث لا يمكن تحديد خوادم DNS مناسبة.

ما إذا كان الرابط هو المسار المبدئي أم لا يمكن تهيئته باستخدام أمر resolvectl default-route أو إعداد DNSDefaultRoute= في ملفات .network. إذا لم يُهيئة صراحةً، يُحدد ضمنيًا بناءً على نطاقات DNS المكونة لرابط: إذا كان هناك نطاق توجيه فقط غير "~."، فالمبدئي هو خطأ، وإلا فالمبدئي هو صحيح.

يعني هذا فعليًا: لدعم الأسماء غير المركبة ذات التسمية الواحدة، عرّف نطاقات بحث مناسبة. لتوجيه جميع استعلامات DNS التي لم تُطابق صراحةً بواسطة تهيئة نطاق التوجيه إلى رابط معين بشكل مفضل، اضبط نطاق توجيه فقط "~." عليه. سيضمن هذا عدم اعتبار الروابط الأخرى لهذه الاستعلامات (ما لم تحمل هي أيضًا نطاق توجيه كهذا). لتوجيه جميع استعلامات DNS هذه إلى رابط معين فقط إذا لم يُفضل رابط آخر، اضبط الرابط كمسار مبدئي ولا تضبط نطاق توجيه فقط "~." عليه. أخيرًا، لتجنب استقبال رابط معين لأي حركة DNS لا تطابق أيًا من نطاقات التوجيه المكونة له، لا تجعله مسارًا مبدئيًا.

انظر org.freedesktop.resolve1(5) للحصول على معلومات حول واجهات برمجة تطبيقات D-Bus التي يوفرها systemd-resolved.

التوافق مع المحلل التقليدي GLIBC STUB

يقدم هذا القسم ملخصًا قصيرًا للاختلافات في المحلل المنفذ بواسطة nss-resolve(8) مع systemd-resolved والمحلل التقليدي المنفذ في nss-dns.

•بعض الأسماء تُحل دائمًا داخليًا (انظر السجلات التركيبية أعلاه). تقليديًا، كانت تُحل بواسطة nss-files إذا وُردت في /etc/hosts. لكن لاحظ أن تفاصيل كيفية بناء الاستعلام تخضع لسيطرة مكتبة العميل. سيحاول nss-dns أولاً حل الأسماء باستخدام نطاقات البحث، وحتى إذا وُجهت تلك الاستعلامات إلى systemd-resolved، فسيرسلها عبر الشبكة باستخدام القواعد المعتادة لتوجيه الأسماء متعددة التسميات [3].

•الأسماء ذات التسمية الواحدة لا تُحل لسجلات A وAAAA باستخدام DNS أحادي الإرسال (ما لم يُتجاوز باستخدام ResolveUnicastSingleLabel=، انظر resolved.conf(5)). هذا مشابه لضبط خيار no-tld-query في resolv.conf(5).

•نطاقات البحث لا تُستخدم لـ إلحاق الأسماء متعددة التسميات. (تُستخدم نطاقات البحث مع ذلك لـ توجيه البحث، للأسماء التي كانت محددة أصلاً كتسمية واحدة أو متعددة التسميات.) أي اسم يحتوي على نقطة واحدة على الأقل يُفسر دائمًا كاسم نطاق مؤهل بالكامل (FQDN). سيحل nss-dns الأسماء كأسماء نسبية (باستخدام نطاقات البحث) وأسماء FQDN مطلقة. بعض الأسماء تُحل كأسماء نسبية أولاً، وبعد فشل ذلك الاستعلام، كأسماء مطلقة، بينما تُحل أسماء أخرى بترتيب معاكس. كان خيار ndots في /etc/resolv.conf يُستخدم للتحكم في عدد النقاط التي يحتاجها الاسم ليُحل كاسم نسبي أولاً. هذا المحلل لا ينفذ هذا على الإطلاق: الأسماء متعددة التسميات تُحل فقط كأسماء FQDN.[4]

•هذا المحلل لديه مفهوم النطاق الخاص ".local" المستخدم لـ MulticastDNS، ولن يوجه الاستعلامات بهذه اللاحقة إلى خوادم DNS أحادية الإرسال ما لم يُهيئة صراحةً، انظر أعلاه. أيضًا، عمليات البحث العكسي لعناوين الرابط المحلي لا تُرسل إلى خوادم DNS أحادية الإرسال.

•هذا المحلل يقرأ ويخبئ /etc/hosts داخليًا في خبيئة. (بمعنى آخر، nss-resolve يحل محل nss-files بالإضافة إلى nss-dns). الإدخالات في /etc/hosts لها الأولوية القصوى.

•هذا المحلل ينفذ أيضًا LLMNR وMulticastDNS بالإضافة إلى بروتوكول DNS أحادي الإرسال الكلاسيكي، وسيحل الأسماء ذات التسمية الواحدة باستخدام LLMNR (عند التمكين) والأسماء المنتهية بـ ".local" باستخدام MulticastDNS (عند التمكين).

•متغيرات البيئة $LOCALDOMAIN و$RES_OPTIONS الموصوفة في resolv.conf(5) غير مدعومة حاليًا.

•محلل nss-dns يحتفظ بحالة قليلة بين استعلامات DNS المتعاقبة، ولكل استعلام يتحدث دائمًا إلى أول خادم DNS مدرج من /etc/resolv.conf أولاً، وعند الفشل يستمر مع التالي حتى يصل إلى نهاية القائمة، وعندها يفشل الاستعلام. المحلل في systemd-resolved مع ذلك يحتفظ بالحالة، وسيتحدث باستمرار إلى نفس الخادم لجميع الاستعلامات في نطاق بحث معين حتى يُرى شكل من أشكال الخطأ، وعندها سيتحول إلى الخادم التالي، ثم يبقى معه لجميع الاستعلامات في النطاق حتى الفشل التالي، وهكذا، ليعود في النهاية إلى أول خادم مُهيئة. يُفعل هذا لتحسين أوقات البحث، خاصةً بالنظر إلى أن المحلل يجب عادةً أن يختبر أولاً مجموعات ميزات الخادم عند التحدث إلى خادم، مما يستغرق وقتًا. هذا السلوك المختلف يعني أن خوادم DNS المدرجة لكل نطاق بحث يجب أن تكون متكافئة في المناطق التي تخدمها، بحيث أن إرسال استعلام إلى أحدها سينتج نفس النتائج مثل إرساله إلى خادم DNS مكون آخر.

/ETC/RESOLV.CONF

أربعة أوضاع لمعالجة /etc/resolv.conf (انظر resolv.conf(5)) مدعومة:

•يحتفظ systemd-resolved بملف /run/systemd/resolve/stub-resolv.conf للتوافق مع برامج Linux التقليدية. يسرد هذا الملف الـ DNS stub 127.0.0.53 (انظر أعلاه) كخادم DNS الوحيد. كما يحتوي على قائمة بنطاقات البحث المستخدمة بواسطة systemd-resolved. تُحفظ قائمة نطاقات البحث محدثة دائمًا. لاحظ أنه لا ينبغي استخدام /run/systemd/resolve/stub-resolv.conf مباشرةً بواسطة التطبيقات، ولكن فقط من خلال رابط رمزي من /etc/resolv.conf. قد يُربط هذا الملف برابط رمزي من /etc/resolv.conf لربط جميع العملاء المحليين الذين يتجاوزون واجهات برمجة تطبيقات DNS المحلية بـ systemd-resolved مع إعدادات نطاقات البحث الصحيحة. وضع التشغيل هذا موصى به.

•يُوفر ملف ثابت /usr/lib/systemd/resolv.conf يسرد الـ DNS stub 127.0.0.53 (انظر أعلاه) كخادم DNS الوحيد. قد يُربط هذا الملف برابط رمزي من /etc/resolv.conf لربط جميع العملاء المحليين الذين يتجاوزون واجهات برمجة تطبيقات DNS المحلية بـ systemd-resolved. لا يحتوي هذا الملف على أي نطاقات بحث.

•يحتفظ systemd-resolved بملف /run/systemd/resolve/resolv.conf للتوافق مع برامج Linux التقليدية. قد يُربط هذا الملف برابط رمزي من /etc/resolv.conf ويُحفظ دائمًا محدثًا، ويحتوي على معلومات حول جميع خوادم DNS المعروفة. لاحظ قيود تنسيق الملف: فهو لا يعرف مفهوم خوادم DNS لكل واجهة، وبالتالي يحتوي فقط على تعريفات خوادم DNS على مستوى النظام. لاحظ أنه لا ينبغي استخدام /run/systemd/resolve/resolv.conf مباشرةً بواسطة التطبيقات، بل فقط من خلال رابط رمزي من /etc/resolv.conf. إذا استُخدم وضع التشغيل هذا، فإن العملاء المحليين الذين يتجاوزون أي واجهة برمجة تطبيقات 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 المهيأة في سجلات النظام.

أُضيف في الإصدارة 231.

SIGUSR2

عند استقبال إشارة العملية SIGUSR2، سيمسح systemd-resolved جميع الخبيئات التي يحتفظ بها. لاحظ أنه لا ينبغي عادةً أن يكون طلب ذلك ضروريًا صراحةً u0628]استثناء أغراض تنقيح الأخطاء u0625]ذ يمسح systemd-resolved الخبيئات آليًا على أي حال كلما تغيرت تهيئة شبكة المضيف. إرسال هذه الإشارة إلى systemd-resolved يعادل أمر resolvectl flush-caches، لكن يُوصى بالأخير لأنه يعمل بطريقة متزامنة.

أُضيف في الإصدارة 231.

SIGRTMIN+1

عند استقبال إشارة العملية SIGRTMIN+1، سينسى systemd-resolved كل ما تعلمه حول خوادم DNS المهيأة. تحديدًا، تُمسح أي معلومات حول دعم ميزات الخادم، وتُعاد بدء منطق فحص ميزات الخادم عند الطلب التالي، بدءًا من المستوى الأكثر اكتمالاً للميزات. لاحظ أنه لا ينبغي عادةً أن يكون طلب ذلك ضروريًا صراحةً u0628]استثناء أغراض تنقيح الأخطاء u0625]ذ ينسى 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). وبالتالي، يتجاوز خيارا سطر أوامر النواة هذان تهيئة النظام.

أُضيف في الإصدار 253.

منافذ IP

تستمع خدمة systemd-resolved على منافذ IP التالية:

•المنفذ 53 على عناوين IPv4 127.0.0.53 و 127.0.0.54 (كلاهما على واجهة الاسترجاع المحلية "lo"). هذا هو DNS stub المحلي، كما نوقش أعلاه. يُغطي كلًا من UDP و TCP.

•المنفذ 5353 على جميع العناوين المحلية، لكل من IPv4 و IPv6 (0.0.0.0 و ::0)، لـ MulticastDNS على UDP. لاحظ أنه على الرغم من ربط المقبس بجميع الواجهات المحلية عبر عناوين IP "البديلة" المختارة، تُصفى حزم البيانات الواردة بواسطة واجهة الشبكة التي تصل منها، وتُحفظ نطاقات MulticastDNS محلية الارتباط منفصلة لكل منها، مع مراعاة ما إذا كان MulticastDNS ممكّنًا للواجهة أم لا.

•المنفذ 5355 على جميع العناوين المحلية، لكل من IPv4 و IPv6 (0.0.0.0 و ::0)، لـ LLMNR، على كل من TCP و UDP. كما هو الحال مع MulticastDNS، يُطبق التصفية بواسطة واجهة الشبكة الواردة.

انظر أيضًا

systemd(1)، resolved.conf(5)، dnssec-trust-anchors.d(5)، nss-resolve(8)، resolvectl(1)، resolv.conf(5)، hosts(5)، systemd.network(5)، systemd-networkd.service(8)، org.freedesktop.resolve1(5)

ملاحظات

1.
RFC3493
https://tools.ietf.org/html/rfc3493
2.
RFC6762
https://tools.ietf.org/html/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 إجابة للاستعلام الثالث.

عند استخدام nss-dns مع أي نطاقات بحث، من الضروري دائمًا تهيئة nss-files بأولوية أعلى وتوفير تعيينات للأسماء التي لا ينبغي حلها باستخدام نطاقات البحث.
4.
يوجد حاليًا أكثر من 1500 اسم نطاق من المستوى الأعلى مُعرّف، وتُضاف أسماء جديدة بانتظام، غالبًا باستخدام أسماء "جذابة" يُحتمل استخدامها محليًا أيضًا. عدم البحث عن الأسماء متعددة التسميات بهذه الطريقة يتجنب الهشاشة في كلا الاتجاهين: يمكن حجب اسم عالمي صالح بواسطة اسم محلي، ويمكن أن ينكسر حل اسم محلي نسبي فجأة عند إنشاء نطاق جديد من المستوى الأعلى، أو عند تسجيل نطاق فرعي جديد لنطاق من المستوى الأعلى. حل أي اسم معين إما نسبي أو مطلق يتجنب هذا الغموض.

ترجمة

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.

systemd 257.13