عیب‌یابی systemd-resolved و DNS در Ubuntu؛ رفع خطاهای DNS مرحله‌به‌مرحله

اگر سرور Ubuntu به اینترنت متصل است و IPهایی مثل 1.1.1.1 را Ping می‌کند، اما دستورهایی مثل apt update، curl یا اتصال به یک دامنه با خطای Temporary failure in name resolution روبه‌رو می‌شوند، به احتمال زیاد مشکل در مسیر DNS است. در Ubuntuهای جدید، یکی از اولین بخش‌هایی که باید بررسی شود سرویس systemd-resolved، DNS رابط شبکه و وضعیت /etc/resolv.conf است.

systemd-resolved چیست و چرا روی DNS تأثیر دارد؟

systemd-resolved سرویس مدیریت Name Resolution در systemd است. این سرویس می‌تواند درخواست‌های DNS برنامه‌های سیستم را دریافت کند، DNS مربوط به هر رابط شبکه را مدیریت کند، پاسخ‌ها را Cache کند و در صورت پیکربندی از قابلیت‌هایی مانند DNSSEC، LLMNR و mDNS استفاده کند.

در بسیاری از نصب‌های Ubuntu، برنامه به‌جای ارتباط مستقیم با DNS عمومی، درخواست خود را به Resolver محلی می‌دهد. systemd-resolved سپس تصمیم می‌گیرد درخواست از طریق کدام رابط و کدام DNS بالادستی ارسال شود. به همین دلیل تغییر دستی و عجولانه فایل /etc/resolv.conf همیشه راه‌حل درستی نیست.

قبل از دست‌کاری DNS مشخص کنید مشکل واقعاً DNS است

ابتدا باید اتصال شبکه را از Name Resolution جدا کنیم. اگر خود شبکه قطع باشد، تغییر DNS کمکی نمی‌کند.

مرحله ۱: وضعیت IP و رابط شبکه را ببینید

ip addr
ip route

وجود IP به‌تنهایی کافی نیست. در خروجی ip route معمولاً باید یک مسیر پیش‌فرض با عبارت default via مشاهده کنید.

مرحله ۲: اتصال را بدون DNS آزمایش کنید

ping -c 4 1.1.1.1

اگر این آزمایش موفق بود، مسیر IP تا اینترنت احتمالاً برقرار است. حالا همان آزمایش را با یک نام دامنه انجام دهید:

ping -c 4 example.com

اگر Ping به IP کار می‌کند ولی دامنه Resolve نمی‌شود، بررسی DNS منطقی است. اگر حتی IP هم در دسترس نیست، ابتدا Gateway، Route، رابط شبکه، فایروال یا شبکه دیتاسنتر را بررسی کنید.

بررسی وضعیت systemd-resolved

وضعیت سرویس را با systemctl ببینید:

systemctl status systemd-resolved --no-pager

در حالت عادی باید وضعیت active (running) مشاهده شود. اگر سرویس Failed یا Inactive است، قبل از Restart کردن، لاگ آن را بخوانید:

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

گزینه -b خروجی را به Boot فعلی محدود می‌کند و برای پیدا کردن خطایی که بعد از Restart یا Reboot ایجاد شده مفید است.

اگر خطای مشخصی مشاهده نمی‌شود، سرویس را Restart کنید:

sudo systemctl restart systemd-resolved
systemctl status systemd-resolved --no-pager

DNS واقعی سرور را با resolvectl بررسی کنید

یکی از مفیدترین فرمان‌ها برای عیب‌یابی DNS در Ubuntu جدید، resolvectl status است:

resolvectl status

در خروجی، رابط شبکه فعال خود مانند eth0، ens3، ens18 یا enp1s0 را پیدا کنید و موارد Current DNS Server و DNS Servers را بررسی کنید.

برای پیدا کردن نام رابط نیز می‌توانید اجرا کنید:

ip -br addr

تست مستقیم DNS با resolvectl

به‌جای Ping می‌توانید مستقیماً از Resolver خود Ubuntu بخواهید دامنه را Resolve کند:

resolvectl query example.com

در یک پاسخ موفق، IP دامنه و اطلاعات مربوط به رابط یا پروتکل مورد استفاده نمایش داده می‌شود. اگر این فرمان Timeout می‌شود یا DNS Server مناسبی در وضعیت Resolver وجود ندارد، مسیر عیب‌یابی به سمت تنظیم DNS رابط شبکه می‌رود.

بررسی /etc/resolv.conf؛ 127.0.0.53 خطا نیست

ابتدا مشخص کنید فایل واقعی است یا Symbolic Link:

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

در حالت Stub ممکن است چیزی شبیه این ببینید:

nameserver 127.0.0.53

این IP متعلق به DNS عمومی اینترنت نیست؛ Stub Resolver محلی systemd-resolved روی Loopback است. بنابراین صرف مشاهده آن دلیل کافی برای جایگزین‌کردن فایل با 8.8.8.8 یا 1.1.1.1 نیست.

مشکل زمانی محتمل‌تر است که Symbolic Link شکسته باشد، systemd-resolved اجرا نشود یا Resolver هیچ DNS بالادستی قابل استفاده‌ای نداشته باشد.

پاک‌کردن Cache و اطلاعات آموخته‌شده DNS

اگر DNS قبلاً کار می‌کرده و بعد از تغییر شبکه یا DNS دچار مشکل شده، ابتدا Cache را Flush کنید:

sudo resolvectl flush-caches
sudo resolvectl reset-server-features

سپس دوباره آزمایش کنید:

resolvectl query example.com

تنظیم موقت DNS برای پیدا کردن علت مشکل

اگر می‌خواهید بدون تغییر دائمی Netplan بفهمید مشکل از DNS فعلی است یا خیر، می‌توانید موقتاً DNS یک رابط را تغییر دهید. ابتدا نام رابط را با ip -br addr پیدا کنید. فرض کنیم رابط سرور ens3 است:

sudo resolvectl dns ens3 1.1.1.1 8.8.8.8
resolvectl status ens3
resolvectl query example.com

اگر DNS بلافاصله با این تغییر کار کرد، DNS قبلی رابط یا تنظیمات DHCP/Netplan یکی از مظنون‌های اصلی است.

برای بازگرداندن تنظیم موقت رابط:

sudo resolvectl revert ens3

این روش برای تشخیص مناسب است، اما برای تنظیم دائمی سرور بهتر است DNS در لایه‌ای که شبکه را مدیریت می‌کند، مانند Netplan، تعریف شود.

تنظیم دائمی DNS در Netplan

در Ubuntu Server معمولاً تنظیمات شبکه در فایل‌های YAML مسیر /etc/netplan/ قرار دارند. قبل از تغییر ابتدا وضعیت فعلی را ببینید:

sudo netplan get
ls -l /etc/netplan/

نام فایل در سرورهای مختلف یکسان نیست و ممکن است توسط Cloud-init، نصب‌کننده Ubuntu یا سرویس دیگری ساخته شده باشد. فایل موجود را بدون بررسی حذف نکنید.

نمونه ساده تنظیم DNS برای رابط ens3 می‌تواند چنین ساختاری داشته باشد:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

این فقط نمونه ساختار است. نام رابط، Renderer و سایر تنظیمات را باید با پیکربندی واقعی سرور تطبیق دهید. فایل موجود را با نمونه بالا کورکورانه جایگزین نکنید؛ به‌خصوص روی VPS با IP استاتیک.

ابتدا صحت Syntax را بررسی کنید:

sudo netplan generate

روی سرور Remote، استفاده از netplan try نسبت به Apply مستقیم ایمن‌تر است:

sudo netplan try

Netplan در این حالت منتظر تأیید می‌ماند و اگر تنظیم جدید تأیید نشود، تلاش می‌کند آن را Rollback کند. با این حال روی سرور راه دور همچنان داشتن Console اضطراری توصیه می‌شود.

بررسی اینکه پورت 53 در اختیار چه سرویسی است

اگر DNS Server، Pi-hole، dnsmasq، Unbound، Docker یا سرویس دیگری نصب کرده‌اید، احتمال تداخل روی پورت DNS وجود دارد. وضعیت Listenerها را ببینید:

sudo ss -lntup | grep ':53'

وجود systemd-resolved روی Loopback به‌تنهایی مشکل نیست. هدف این بررسی پیدا کردن سرویس دیگری است که ممکن است با Resolver مورد انتظار شما تداخل داشته باشد.

اگر apt update خطای Temporary failure resolving می‌دهد

نمونه این خطا معمولاً شبیه عبارت زیر است:

Temporary failure resolving ...

به‌جای تغییر فوری Repositoryهای Ubuntu، این ترتیب را بررسی کنید:

پس از اصلاح DNS دوباره اجرا کنید:

sudo apt update

اگر DNS بعد از Reboot دوباره خراب می‌شود

این نشانه مهمی است. اگر تغییر با resolvectl dns مشکل را حل می‌کند ولی پس از Reboot از بین می‌رود، احتمالاً فقط یک تنظیم Runtime ایجاد کرده‌اید. در این شرایط باید منبع اصلی تنظیم شبکه را پیدا کنید.

این فرمان‌ها کمک می‌کنند:

sudo netplan get
resolvectl status
systemctl is-active systemd-networkd
systemctl is-active NetworkManager

Ubuntu Server معمولاً از backend مبتنی بر systemd-networkd استفاده می‌کند، در حالی که Ubuntu Desktop اغلب NetworkManager دارد. تنظیم دائمی را باید متناسب با همان مدیر شبکه انجام دهید.

بررسی DNS با dig

اگر ابزار dig روی سیستم نصب است، می‌توانید DNS مشخصی را مستقل از Resolver محلی آزمایش کنید:

dig @1.1.1.1 example.com

اگر این Query پاسخ می‌دهد ولی resolvectl query example.com شکست می‌خورد، دسترسی شبکه به DNS خارجی وجود دارد و مشکل احتمالاً در Resolver محلی یا تنظیم DNS رابط است.

برای مشاهده DNS پیش‌فرض نیز می‌توانید اجرا کنید:

dig example.com

جدول تشخیص سریع خطاهای DNS در Ubuntu

چه کارهایی را برای رفع DNS انجام ندهیم؟

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

چک نهایی بعد از رفع مشکل

بعد از هر اصلاح، از ابتدا مسیر را دوباره آزمایش کنید:

systemctl is-active systemd-resolved
resolvectl status
resolvectl query example.com
ping -c 4 1.1.1.1
ping -c 4 example.com

اگر همه این مراحل موفق‌اند، یک سرویس واقعی نیز آزمایش کنید:

sudo apt update

پرسش‌های رایج درباره systemd-resolved و DNS

آیا nameserver 127.0.0.53 در Ubuntu اشتباه است؟

خیر. وقتی systemd-resolved در حالت Stub Resolver استفاده می‌شود، این IP می‌تواند کاملاً طبیعی باشد. باید DNS بالادستی را با resolvectl status بررسی کنید.

چرا Ping به IP کار می‌کند ولی دامنه باز نمی‌شود؟

این وضعیت یکی از نشانه‌های مهم مشکل Name Resolution است. DNS رابط، systemd-resolved و resolv.conf از اولین بخش‌هایی هستند که باید بررسی شوند.

چرا DNS که با resolvectl تنظیم کردم بعد از Reboot پاک شد؟

فرمان resolvectl dns برای تغییر Runtime مفید است، اما برای تنظیم دائمی باید منبع اصلی شبکه، مانند Netplan، NetworkManager یا DHCP را اصلاح کنید.

آیا باید systemd-resolved را Disable کنم؟

در عیب‌یابی معمول DNS، خیر. ابتدا علت را پیدا کنید. غیرفعال‌کردن Resolver بدون طراحی جایگزین ممکن است Name Resolution برنامه‌های سیستم را مختل کند.

بهتر است DNS را در resolv.conf تغییر دهم یا Netplan؟

اگر شبکه سرور با Netplan مدیریت می‌شود و به تنظیم دائمی نیاز دارید، معمولاً تنظیم DNS در Netplan مسیر مناسب‌تری است. resolv.conf ممکن است توسط سرویس‌های شبکه مدیریت و دوباره تولید شود.

چطور بفهمم مشکل از DNS سرور است یا خود systemd-resolved؟

یک Query از طریق Resolver سیستم و یک Query مستقیم به DNS مشخص انجام دهید. اگر DNS مستقیم پاسخ می‌دهد ولی Resolver سیستم شکست می‌خورد، پیکربندی Resolver محلی یا DNS رابط باید بررسی شود.