إصلاح مشكلة "فشل مؤقت في حل أسماء النطاقات" في دبيان 12 باستخدام systemd-resolved

يشير هذا الخطأ Temporary failure in name resolutionإلى أن أحد التطبيقات لم يتمكن من تحويل اسم مضيف، مثل `<hostname>`، deb.debian.orgإلى عنوان IP. في نظام Debian 12 (Bookworm)، لا يعني هذا بالضرورة systemd-resolvedوجود خلل في نظام DNS. لا يتم تثبيت Debian 12 systemd-resolvedافتراضيًا، وقد تتم إدارة DNS مباشرةً بواسطة NetworkManager أو ifupdown أو أدوات DHCP أو أي مُحلِّل أسماء آخر. إذا قمتَ بتفعيل DNS عمدًا systemd-resolved، فإن أسرع حل هو تحديد الطبقة التي بها المشكلة قبل تغيير الإعدادات.

يركز هذا المرجع العملي على الأنظمة التي تستخدم، أو يُراد لها استخدام، نظام إدارة systemd-resolvedأسماء النطاقات (DNS). تشير وثائق حزمة Bookworm الخاصة بنظام دبيان إلى أن تثبيتها systemd-resolvedيُفعّل /etc/resolv.confإدارة نظام إدارة أسماء النطاقات (DNS) باستخدام systemd. توفر هذه الخدمة نفسها خادم DNS محليًا، 127.0.0.53وتستقبل معلومات DNS من مصادر خارجية مثل التكوين العام، وتكوين الشبكة لكل رابط، وبروتوكول DHCP، resolvectlوخدمات إدارة الشبكة. راجع صفحة حزمة systemd-resolved ودليلها على موقع دبيان الإلكتروني .

قائمة فحص التشخيص السريع

1. تأكد من أن المشكلة تتعلق بنظام أسماء النطاقات (DNS)، وليس بالاتصال العام.

ابدأ باختبار اسم المضيف ثم عنوان IP:

getent ahosts debian.org
ping -c 3 debian.org
ping -c 3 1.1.1.1

إذا فشل البحث عن اسم المضيف بينما نجح اختبار عنوان IP المباشر، فمن المرجح أن يكون نظام أسماء النطاقات (DNS) هو سبب المشكلة. في حال فشل كليهما، يجب أولاً فحص الواجهة، أو المسار، أو البوابة، أو شبكة VLAN، أو اتصال Wi-Fi، أو جدار الحماية، أو الشبكة الرئيسية. لا يمكن لتغيير نظام أسماء النطاقات (DNS) إصلاح مسار افتراضي مفقود.

لإجراء فحص توجيه أكثر دقة، قم أيضًا بتشغيل ما يلي:

ip address
ip route

عادةً ما يكون لديك عنوان على الواجهة المتوقعة ومسار افتراضي. قد يكون اسم الواجهة الدقيق هو enp1s0، ens160أو eth0، أو اسم آخر.

2. تحقق مما إذا كان systemd-resolved قيد الاستخدام بالفعل

لا تفترض وجوده لمجرد أن الجهاز يستخدم systemd. تحقق من كل من الحزمة والخدمة:

dpkg -s systemd-resolved 2>/dev/null | grep '^Status'
systemctl status systemd-resolved --no-pager
resolvectl status

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

sudo systemctl enable --now systemd-resolved

إذا فشل هذا الأمر، فافحص السجلات قبل إعادة تشغيل الخدمة بشكل متكرر:

journalctl -u systemd-resolved -b --no-pager

3. افحص الملف /etc/resolv.conf قبل استبداله

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

ls -l /etc/resolv.conf
cat /etc/resolv.conf

لا يُعدّ الملف العادي خاطئًا بالضرورة. فقد يكون مدير الشبكة أو مدير محلل أسماء آخر هو المسؤول عنه عمدًا. مع ذلك، إذا صُمّم هذا المضيف لاستخدام وضع stub المُحلَّل بواسطة systemd، فقد يتسبب ملف عادي قديم، أو رابط رمزي معطّل، أو ملف يشير إلى خوادم أسماء غير قابلة للوصول، في فشل عمليات البحث.

قم باستعادة رابط الوصلة الموصى به عند الرغبة في استخدام وضع الوصلة.

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf

من المتوقع رؤية ذلك nameserver 127.0.0.53في ملف stub. إنه المستمع المحلي، وليس خادم DNS الرئيسي. استخدمه resolvectl statusلمعرفة خوادم DNS الرئيسية التي سيتصل بها systemd-resolved فعليًا. هذا التمييز موثق في دليل systemd-resolved الخاص بـ Bookworm .

4. تحقق مما إذا كان لدى systemd-resolved خادم DNS علوي قابل للاستخدام

يجري:

resolvectl status

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

يمكنك اختبار المُحلِّل مباشرةً:

resolvectl query debian.org

يوثق دليل Debian resolvectl أوامر DNS الخاصة بكل رابط المستخدمة للفحص واستكشاف الأخطاء وإصلاحها.statusqueryflush-caches

5. إذا كان مدير الشبكة يمتلك الواجهة، فقم بإصلاح نظام أسماء النطاقات (DNS) في ملف تعريف الاتصال.

في أنظمة سطح المكتب والعديد من أنظمة دبيان العامة، قد يوفر مدير الشبكة معلومات نظام أسماء النطاقات (DNS) لكل رابط إلى systemd-resolved. حدد أولاً الملف الشخصي النشط وقيم نظام أسماء النطاقات الحالية:

nmcli connection show --active
nmcli device show

إذا كان خادم DHCP يُزوّد ​​بخادم DNS غير صالح، فغيّر ملف تعريف NetworkManager بدلاً من تعديله /etc/resolv.confبعد كل إعادة تشغيل. على سبيل المثال، إذا كانت سياسة الشبكة لديك تسمح باستخدام خوادم DNS العامة:

sudo nmcli connection modify "Wired connection 1"   ipv4.ignore-auto-dns yes   ipv4.dns "1.1.1.1 9.9.9.9"
sudo nmcli connection up "Wired connection 1"

استبدل اسم الملف الشخصي وخوادم نظام أسماء النطاقات (DNS) بقيم مناسبة لشبكتك. غالبًا ما تتطلب شبكات الشركات، وشبكات VPN، وبيئات Active Directory، وإعدادات DNS المنفصلة، ​​خوادم DNS داخلية؛ وقد يؤدي استخدام DNS العام إلى تعطيل أسماء المضيفين الخاصة. يوثق مرجع التكوين الرسمي لـ NetworkManager تكامله مع systemd-resolved...

6. إذا كان systemd-networkd يمتلك الواجهة، فقم بتكوين DNS لكل رابط

بالنسبة للخوادم التي تستخدم بروتوكول DHCP systemd-networkd، ضع إعدادات DNS في .networkالملف المطابق الموجود ضمن المسار المحدد /etc/systemd/network/. مثال بسيط يعتمد على DHCP هو:

[Match]
Name=ens160

[Network]
DHCP=yes
DNS=1.1.1.1
DNS=9.9.9.9
Domains=~.

[DHCPv4]
UseDNS=no

UseDNS=noيُعدّ هذا الأمر مهمًا عندما ترغب تحديدًا في تجاهل خوادم نظام أسماء النطاقات (DNS) المُقدّمة من DHCP. فبدونه، يتم استخدام خوادم DHCP DNS افتراضيًا. Domains=~.وهو نطاق توجيه فقط لجذر DNS، مما يجعل هذا الرابط مناسبًا للاستعلامات التي لا تتطابق مع نطاق توجيه أكثر تحديدًا. لا تُضفه بشكل عشوائي على أنظمة متعددة المنافذ أو أنظمة VPN حيث يكون تقسيم DNS مقصودًا.

sudo systemctl restart systemd-networkd
resolvectl status ens160

تم توثيق سلوك DNS=و Domains=و DHCP في دليل نظام الشبكة الخاص بـ Debian Bookworm .UseDNS=

7. استخدم ملف resolved.conf العام فقط عندما تريد فعلاً نظام أسماء نطاقات على مستوى النظام.

/etc/systemd/resolved.confأو يمكن تحديد خوادم نظام أسماء النطاقات (DNS) من خلال خيار "إضافة" في الإعدادات /etc/systemd/resolved.conf.d/. يُعد هذا مفيدًا لسياسة على مستوى المضيف، ولكنه أقل دقة من التكوين لكل رابط على الأجهزة التي تستخدم شبكات VPN أو واجهات متعددة أو مناطق DNS خاصة.

عادةً ما يكون التعديل المحلي أسهل من تعديل الملف الرئيسي المصمم على غرار ملفات الموردين:

sudo mkdir -p /etc/systemd/resolved.conf.d
sudoedit /etc/systemd/resolved.conf.d/10-dns.conf

مثال:

[Resolve]
DNS=1.1.1.1 9.9.9.9

ثم قم بتطبيقه:

sudo systemctl restart systemd-resolved
resolvectl status

يشرح دليل Debian resolved.conf أن خوادم DNSDNS= الخاصة بالنظام توفر ذلك، وأن عمليات الإدخال الإضافية للمسؤولين /etc/systemd/resolved.conf.d/لها الأولوية على التكوين ذي الأولوية الأقل.

8. قم بمسح ذاكرة التخزين المؤقت فقط بعد إصلاح التكوين الأساسي

قد يؤدي وجود بيانات قديمة في ذاكرة التخزين المؤقت إلى تعقيد عملية استكشاف الأخطاء وإصلاحها، ولكن مسح ذاكرة التخزين المؤقت ليس بديلاً عن إصلاح خادم المصدر غير المتاح أو إعدادات الاتصال المعطلة. بعد إجراء تغيير فعلي في الإعدادات، يمكنك تشغيل الأمر التالي:

sudo resolvectl flush-caches
resolvectl query debian.org

تشير وثائق Systemd الخاصة إلى أن ذاكرة التخزين المؤقت يتم مسحها تلقائيًا عند تغيير تكوين الشبكة، لذلك لا ينبغي أن يكون المسح اليدوي المتكرر هو الحل الأساسي.

9. اقرأ سجل المُحلِّل عندما يستمر الفشل

إذا resolvectl statusبدا الأمر معقولاً ولكن الاستعلامات لا تزال تنتهي بمهلة زمنية، فافحص سجل محلل boot-local:

journalctl -u systemd-resolved -b --no-pager
journalctl -u systemd-resolved -b --no-pager | tail -n 50

ابحث عن حالات انقطاع متكررة للخادم، أو تغييرات في خادم النسخ الاحتياطي، أو فشل في التحقق من صحة DNSSEC، أو رسائل تشير إلى تقليل ميزات البروتوكول. قد يعمل محلل أسماء النطاقات بشكل طبيعي بينما يكون خادم المصدر المُكوّن له غير قابل للوصول إليه عبر جدار الحماية، أو شبكة VPN، أو سياسة التوجيه، أو قائمة التحكم بالوصول إلى الشبكة.

10. تحقق من مسار البحث الكامل

لا تتوقف بعد resolvectlاستعلام واحد ناجح. تحقق من المسار الذي تستخدمه التطبيقات العادية:

getent ahosts debian.org
resolvectl query debian.org
sudo apt update

getentيُعدّ هذا مفيدًا لأنّ عمليات البحث عن اسم المضيف في مكتبة glibc تتبع السطر المذكور hosts:في ملف /etc/nsswitch.conf. إذا resolvectl queryنجحت العملية ثم فشلت، فافحص إعدادات NSS. يصف دليل nss-resolve الخاصgetent بنظام Debian الوحدة الاختيارية والترتيب المُوصى به الذي يُمكنه توجيه عمليات البحث عن اسم المضيف في مكتبة glibc عبر systemd-resolved مع الاحتفاظ بالخيارات البديلة.libnss-resolve

الأعراض الشائعة والمكان الأكثر احتمالاً للبحث

ترتيب الإصلاح الموصى به

1. تأكد من وجود اتصال الشبكة الأساسي والمسار الافتراضي.
2. تأكد مما إذا systemd-resolvedكان المقصود فعلاً إدارة نظام أسماء النطاقات (DNS) على هذا المضيف.
3. تحقق من systemd-resolvedحالة الخدمة و resolvectl status...
4. تحقق من /etc/resolv.confملكية الملفات ووضع الروابط الرمزية قبل تغييرها.
5. إذا كان المقصود هو وضع الجذع، فقم باستعادة stub-resolv.confالرابط.
6. قم بإصلاح نظام أسماء النطاقات (DNS) في المصدر الرئيسي عند المالك الفعلي: NetworkManager، أو systemd-networkd، أو DHCP، أو VPN، أو التكوين المُحلَّل عالميًا.
7. قم بمسح ذاكرة التخزين المؤقت فقط بعد تصحيح الإعدادات.
8. تحقق باستخدام resolvectl، getent، والتطبيق الذي فشل في الأصل.

المبدأ الأساسي هو الملكية: /etc/resolv.confفـ systemd-resolved ومدير الشبكة جزء من سلسلة محلل أسماء نطاقات واحدة. ويُجري الإصلاح الدائم تغييرًا في نظام أسماء النطاقات على مستوى الطبقة المالكة له، بدلًا من استبدال الملف النهائي المُنشأ بشكل متكرر.