خطای Temporary failure in name resolution در لینوکس؛ تشخیص و رفع مشکل DNS سرور

این خطا چه زمانی ظاهر می‌شود؟

پیام Temporary failure in name resolution در موقعیت‌های مختلفی دیده می‌شود: هنگام apt update، اجرای ping google.com، دانلود با curl یا wget، کشیدن ایمیج داکر یا وقتی برنامهٔ شما می‌خواهد به یک API خارجی وصل شود. گاهی هم به شکل‌های دیگری مثل Could not resolve host یا Name or service not known ظاهر می‌شود.

همهٔ این پیام‌ها یک معنا دارند: سرور نتوانسته نام دامنه را به آی‌پی تبدیل کند. این کار بر عهدهٔ DNS است؛ سرویسی که مثل دفترچهٔ تلفن اینترنت عمل می‌کند. کلمهٔ «Temporary» در پیام به این معنی است که سیستم پاسخ قطعی «این دامنه وجود ندارد» نگرفته، بلکه اصلاً نتوانسته از سرور DNS پاسخی بگیرد.

گام ۱: مشکل از DNS است یا از کل اتصال؟

اولین قدم جدا کردن مشکل DNS از قطعی کامل شبکه است. به یک آی‌پی مستقیم ping بزنید؛ چون در این حالت به DNS نیازی نیست:

ping -c 3 1.1.1.1
ping -c 3 8.8.8.8
ip route

• اگر ping به آی‌پی کار می‌کند اما ping به نام دامنه خطا می‌دهد، مشکل قطعاً DNS است و ادامهٔ این مقاله به کارتان می‌آید.
• اگر ping به آی‌پی هم جواب نمی‌دهد، مشکل در اتصال شبکه یا مسیریابی است؛ ممکن است دسترسی بین‌المللی محدود شده باشد، کارت شبکه یا Gateway پیکربندی نشده باشد یا فایروال خروجی‌ها را بسته باشد. در این حالت تغییر DNS کمکی نمی‌کند. روش بررسی مسیر را در آموزش ping، traceroute و mtr ببینید.

گام ۲: سرور از کدام DNS استفاده می‌کند؟

در اوبونتو و بسیاری از توزیع‌های جدید، سرویس systemd-resolved مسئول DNS است. فایل /etc/resolv.conf در این سیستم‌ها معمولاً فقط به یک DNS محلی (127.0.0.53) اشاره می‌کند و آن سرویس درخواست را به DNSهای واقعی می‌فرستد:

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

در خروجی resolvectl status بخش DNS Servers را برای هر رابط شبکه ببینید. حالت‌های رایج مشکل:

• هیچ سرور DNSی تعریف نشده است.
• DNS تعریف‌شده از دسترس خارج است یا پاسخ نمی‌دهد.
• فایل resolv.conf لینک شکسته است یا دستی ویرایش شده و با سرویس هماهنگ نیست.
• سرویس systemd-resolved متوقف شده است.

گام ۳: پرس‌وجوی مستقیم با dig

ابزار dig (از بستهٔ dnsutils در اوبونتو و bind-utils در AlmaLinux) اجازه می‌دهد مستقیماً از یک سرور DNS مشخص سؤال کنید و ببینید کدام کار می‌کند:

dig example.com                 # از DNS پیش‌فرض سیستم
dig @1.1.1.1 example.com        # مستقیم از Cloudflare DNS
dig @8.8.8.8 example.com +short # مستقیم از Google DNS
resolvectl query example.com

اگر dig @1.1.1.1 پاسخ می‌دهد اما dig بدون مشخص کردن سرور پاسخ نمی‌دهد، DNS پیش‌فرض سرور خراب است و باید آن را تغییر دهید. اگر هیچ‌کدام پاسخ نمی‌دهد، ممکن است درخواست‌های DNS (پورت ۵۳ UDP و TCP) در فایروال خروجی سرور یا در مسیر شبکه مسدود باشد.

$ ping -c 1 1.1.1.1 | tail -n 21 packets transmitted, 1 received, 0% packet loss$ ping -c 1 example.comping: example.com: Temporary failure in name resolution$ dig @1.1.1.1 example.com +short... (IPv4 address of example.com)$ resolvectl status | grep 'DNS Servers'         DNS Servers: (none)$ 

گام ۴: تنظیم دائمی DNS

روی اوبونتو با netplan

پیکربندی شبکهٔ اوبونتو سرور در فایل‌های /etc/netplan/*.yaml است. بخش nameservers را به رابط شبکه اضافه یا اصلاح کنید (نام رابط و بقیهٔ تنظیمات را دست نزنید):

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

سپس با احتیاط اعمال کنید. دستور netplan try تغییرات را موقتاً اعمال می‌کند و اگر تأیید نکنید، پس از مدت کوتاهی برمی‌گرداند؛ این ویژگی از قطع شدن اتصال SSH جلوگیری می‌کند:

sudo netplan try
sudo netplan apply

توجه: برخی ارائه‌دهندگان شبکه را با cloud-init تنظیم می‌کنند و ممکن است فایل netplan پس از ری‌استارت بازنویسی شود. در این حالت به‌جای ویرایش فایل ساخته‌شده توسط cloud-init، یک فایل جداگانه با شمارهٔ بالاتر بسازید یا روش بعدی را به کار ببرید.

با systemd-resolved

روش ساده‌تر و مستقل از netplan، تعریف DNS سراسری در تنظیمات resolved است:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf "[Resolve]\nDNS=1.1.1.1 8.8.8.8\nFallbackDNS=9.9.9.9\n" | sudo tee /etc/systemd/resolved.conf.d/dns.conf
sudo systemctl restart systemd-resolved
resolvectl status

چرا نباید فقط resolv.conf را ویرایش کرد؟

ویرایش مستقیم /etc/resolv.conf در لحظه کار می‌کند، اما در سیستم‌هایی که systemd-resolved یا NetworkManager دارند، این فایل در ری‌استارت بعدی یا با تمدید DHCP بازنویسی می‌شود و مشکل برمی‌گردد. اگر لینک این فایل خراب شده، آن را به حالت استاندارد برگردانید:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

فایل hosts و ترتیب جست‌وجوی نام

پیش از پرس‌وجو از DNS، لینوکس فایل /etc/hosts را بررسی می‌کند. این ترتیب در فایل /etc/nsswitch.conf و سطر hosts: تعیین می‌شود. دو مشکل رایج از همین‌جا می‌آید:

• نام میزبان سرور در hosts نیست: اگر hostname سرور را تغییر داده‌اید اما در /etc/hosts اضافه نکرده‌اید، دستورهایی مثل sudo با پیام unable to resolve host کند می‌شوند یا هشدار می‌دهند. یک خط 127.0.1.1 نام-سرور به فایل hosts اضافه کنید.
• ورودی قدیمی یا اشتباه در hosts: اگر برای آزمایش، دامنه‌ای را دستی به آی‌پی خاصی نسبت داده‌اید و فراموش کرده‌اید، سرور همیشه همان آی‌پی قدیمی را استفاده می‌کند و DNS را نادیده می‌گیرد. محتوای فایل را بررسی کنید.

دستور getent hosts example.com نام را دقیقاً با همان ترتیبی که برنامه‌ها استفاده می‌کنند (اول hosts، بعد DNS) حل می‌کند و برای تشخیص این حالت از dig مناسب‌تر است، چون dig فایل hosts را نمی‌خواند.

نکته‌های ویژهٔ سرورهای ایران

روی سرورهای داخل ایران، دو موقعیت خاص پیش می‌آید. اول، در زمان‌هایی که دسترسی بین‌المللی محدود یا مختل است، DNSهای عمومی خارجی ممکن است در دسترس نباشند؛ در این حالت استفاده از DNS داخلی که ارائه‌دهندهٔ سرور یا دیتاسنتر معرفی می‌کند پایدارتر است. همیشه دست‌کم دو DNS تعریف کنید که یکی داخلی و دیگری خارجی باشد. دوم، حتی وقتی DNS درست کار می‌کند، برخی مخزن‌ها و سرویس‌ها مثل Docker Hub ممکن است به آی‌پی‌های ایران پاسخ ۴۰۳ بدهند که مشکل DNS نیست؛ راه‌حل آن در رفع خطای ۴۰۳ داکر و apt در ایران آمده است.

مشکل DNS داخل کانتینرهای داکر

کانتینرهای داکر تنظیمات DNS را از میزبان می‌گیرند، اما چون آدرس 127.0.0.53 داخل کانتینر معنا ندارد، داکر به‌جای آن DNS واقعی را از تنظیمات resolved برمی‌دارد. اگر میزبان DNS درست دارد ولی کانتینرها نام‌ها را پیدا نمی‌کنند، DNS را در /etc/docker/daemon.json صریحاً تعیین کنید و سرویس داکر را ری‌استارت کنید:

{ "dns": ["1.1.1.1", "8.8.8.8"] }

اشتباه گرفتن با مشکل رکوردهای دامنه

این مقاله دربارهٔ وقتی است که خود سرور نمی‌تواند نام‌ها را پیدا کند. اگر مشکل این است که دامنهٔ سایت شما برای بازدیدکنندگان به آی‌پی جدید اشاره نمی‌کند، موضوع متفاوت است و به رکوردهای DNS دامنه و زمان انتشار تغییرات مربوط می‌شود؛ مقالهٔ انتشار DNS چقدر طول می‌کشد و رکورد CNAME چیست را بخوانید.

چک‌لیست سریع

1. ping به آی‌پی مستقیم: اگر جواب نمی‌دهد، مشکل شبکه است نه DNS.
2. resolvectl status: کدام DNS تعریف شده است؟
3. dig @1.1.1.1 example.com: آیا DNS دیگری کار می‌کند؟
4. DNS را در netplan یا resolved.conf.d به‌طور دائمی تنظیم کنید.
5. برای کانتینرها، DNS را در daemon.json تعیین کنید.

دستورهای مدیریتی دیگر را در دستورات پرکاربرد لینوکس ببینید. در سرورهای کلودیفای، اگر پس از این مراحل هنوز مشکل دارید، از بخش پشتیبانی تیکت بزنید و خروجی resolvectl status و dig را ضمیمه کنید.

سؤالات متداول