رفع مشکل DNS در Ubuntu با systemd-resolved؛ عیب‌یابی resolvectl و 127.0.0.53

اگر در Ubuntu Server دستورهایی مانند apt update، curl یا ping example.com با خطای Temporary failure in name resolution روبه‌رو می‌شوند، ابتدا اتصال IP را از DNS جدا کنید، سپس وضعیت systemd-resolved، سرورهای DNS هر رابط و مسیر /etc/resolv.conf را بررسی کنید. وجود آدرس 127.0.0.53 در resolv.conf به‌تنهایی خطا نیست؛ این آدرس در بسیاری از نسخه‌های اوبونتو، DNS Stub محلیِ systemd-resolved است. تغییر کورکورانه آن به 8.8.8.8 می‌تواند DNS داخلی یا تنظیمات مدیریت‌شده سرور را خراب کند.

این راهنما برای Ubuntu Server مبتنی بر systemd-resolved و Netplan نوشته شده است. اگر سرویس دیگری مانند NetworkManager، dnsmasq یا یک resolver اختصاصی مسئول DNS است، ابتدا مالک تنظیمات را مشخص کنید و دستورهای تغییر را بدون تطبیق اجرا نکنید.

نشانه‌های خرابی DNS و تفاوت آن با قطع شبکه

ممکن است ping 1.1.1.1 کار کند اما getent ahostsv4 example.com خروجی ندهد؛ در این حالت مسیر IP احتمالاً برقرار است و باید Resolver را بررسی کرد. اگر ارتباط مستقیم با IP هم قطع است، مسئله احتمالاً در Interface، Gateway، Route یا Firewall قرار دارد؛ راهنمای عیب‌یابی خطای Network is unreachable در لینوکس برای این مرحله مناسب‌تر است. برای آشنایی با مفهوم خطاهای تبدیل نام به IP نیز مقاله رفع DNS Resolution Failure را ببینید.

ip -br addr
ip -4 route show
ip -4 route get 1.1.1.1
ping -c 2 -W 2 1.1.1.1
getent ahostsv4 example.com

تفسیر: خروجی ip route get باید رابط خروجی و مسیر را نشان دهد. موفق‌بودن Ping به یک IP، صحت کامل اینترنت را تضمین نمی‌کند؛ ممکن است ICMP مسدود باشد. اگر getent نام دامنه را به IP تبدیل نکرد ولی دسترسی IP برقرار بود، بررسی DNS را ادامه دهید. در محیط سازمانی، برای تست از یک دامنه مجاز و شناخته‌شده همان شبکه استفاده کنید.

بررسی وضعیت systemd-resolved و DNS هر کارت شبکه

ابتدا بدون هیچ تغییری وضعیت سرویس، رابط‌های فعال و DNSهای دریافت‌شده از DHCP یا Netplan را بخوانید:

systemctl is-active systemd-resolved
resolvectl status
resolvectl dns
resolvectl domain
ip -br link
resolvectl query example.com

در خروجی resolvectl status به Current DNS Server، DNS Servers، DefaultRoute و DNS Domain در بخش Link توجه کنید. نام رابط ممکن است ens3، eth0 یا enp1s0 باشد؛ هیچ‌کدام را از پیش فرض نکنید. اگر سرویس inactive است، پیش از فعال‌سازی بررسی کنید آیا عمداً Resolver دیگری روی سیستم استفاده می‌شود یا نه.

برای خطاهای ثبت‌شده در سرویس و سرنخ‌هایی مانند DNSSEC validation failed، Timeout یا Failed to send hostname reply از لاگ استفاده کنید:

journalctl -u systemd-resolved -b --no-pager -n 80
sudo ss -lunp | grep ':53' || true

در خروجی دستور دوم ممکن است Listener روی 127.0.0.53:53 دیده شود. نبودن آن به‌تنهایی ثابت نمی‌کند سرویس خراب است؛ ممکن است Stub Listener غیرفعال شده یا برنامه دیگری DNS را مدیریت کند.

آیا 127.0.0.53 در /etc/resolv.conf اشتباه است؟

خیر. طبق مستندات رسمی systemd، آدرس 127.0.0.53 Stub Resolver محلی است که درخواست‌ها را با توجه به DNSهای Upstream و تنظیمات Per-Link هدایت می‌کند. فایل /etc/resolv.conf در حالت رایج به /run/systemd/resolve/stub-resolv.conf اشاره می‌کند. تغییر آن بدون تشخیص مالک تنظیمات می‌تواند Split DNS، VPN سازمانی یا دامنه‌های داخلی را مختل کند.

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
ls -l /run/systemd/resolve/stub-resolv.conf
resolvectl status

اگر readlink -f مسیر Stub را نشان داد و systemd-resolved فعال بود، صرفاً به‌خاطر 127.0.0.53 فایل را جایگزین نکنید. اگر فایل واقعاً شکسته، حذف یا به مسیری ناموجود متصل است، پس از تهیه نسخه پشتیبان و اطمینان از فعال‌بودن سرویس، در بخش اصلاح Symlink اقدام کنید.

تفکیک مشکل DNS بالادستی از Stub محلی

سه مسیر را جداگانه بسنجید: Resolver سیستم، Stub محلی و DNS بالادستیِ مجاز شبکه. برای dig بسته dnsutils لازم است؛ اگر DNS فعلاً کار نمی‌کند، برای نصب بسته عجله نکنید و از resolvectl و getent استفاده کنید.

resolvectl query example.com
getent ahostsv4 example.com
# فقط اگر dig از قبل نصب است:
dig @127.0.0.53 example.com A +time=2 +tries=1
# DNS_UPSTREAM را با IP واقعی DNS شبکه خود جایگزین کنید:
dig @DNS_UPSTREAM example.com A +time=2 +tries=1

اگر DNS بالادستی پاسخ می‌دهد ولی resolvectl query شکست می‌خورد، تنظیمات Per-Link، DNSSEC، مسیر فایل Resolver یا وضعیت سرویس را بررسی کنید. اگر هر دو شکست می‌خورند، اتصال UDP/TCP پورت 53، سیاست فایروال، مسیر خروجی و صحت DNS معرفی‌شده توسط DHCP را بررسی کنید. در شبکه‌های دارای DNS خصوصی، استفاده از Resolver عمومی ممکن است دامنه‌های داخلی را Resolve نکند.

اگر فقط DNS داخل کانتینر Docker خراب است ولی Resolver میزبان سالم است، موضوع متفاوت است؛ راهنمای رفع مشکل DNS در Docker و ارتباط آن با 127.0.0.53 را بررسی کنید.

راهکار موقت: تنظیم DNS برای یک Interface با resolvectl

پس از تأیید اینکه DNS بالادستیِ فعلی پاسخ نمی‌دهد، می‌توانید برای آزمایش DNS مجاز دیگری را موقتاً روی همان Interface ثبت کنید. آدرس‌های مثال عمومی‌اند؛ در شبکه شرکتی، دامنه داخلی یا زیرساخت دارای DNS اختصاصی، از آدرس‌های تأییدشده مدیر شبکه استفاده کنید.

# ens3 را با نام رابط واقعی از resolvectl status عوض کنید:
sudo resolvectl dns ens3 9.9.9.9 1.1.1.1
resolvectl dns ens3
resolvectl query example.com
getent ahostsv4 example.com

این تغییر معمولاً پایدار نیست و ممکن است با تمدید DHCP یا بازپیکربندی رابط بازنویسی شود. برای Rollback همان رابط:

sudo resolvectl revert ens3
resolvectl status

دستور revert تنظیمات DNS و Domain موقتیِ همان رابط را به وضعیت مدیریت‌شده آن برمی‌گرداند؛ اگر تنظیمات قبلی مهم هستند، خروجی resolvectl status را قبل از آزمایش ذخیره کنید. دستور resolvectl flush-caches فقط کش را پاک می‌کند و جایگزین اصلاح DNS نادرست نیست.

اصلاح پایدار DNS در Ubuntu با Netplan

در بسیاری از نصب‌های Ubuntu Server، تنظیم پایدار شبکه با Netplan انجام می‌شود. قبل از ویرایش، مسیر فایل و نام Interface را پیدا کنید. روی VPS از کنسول یا روش بازیابی خارج از SSH مطمئن شوید؛ تغییر اشتباه YAML یا Route می‌تواند اتصال را قطع کند.

sudo netplan get
ls -la /etc/netplan/
ip -br addr
sudo cp -a /etc/netplan /root/netplan-backup-before-dns

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

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      nameservers:
        addresses: [9.9.9.9, 1.1.1.1]

اگر DHCP همچنان DNS دیگری تزریق می‌کند، ابتدا اولویت‌های DNS را در resolvectl status بررسی کنید. گزینه dhcp4-overrides: {use-dns: false} فقط زمانی مناسب است که عمداً قصد نادیده‌گرفتن DNS ارائه‌شده توسط DHCP را دارید؛ در شبکه‌های دارای Split DNS ممکن است نتیجه نامطلوبی بدهد.

sudo netplan generate
sudo netplan try --timeout 120
# پس از تایید اتصال در همان نشست:
resolvectl status
resolvectl query example.com

netplan try در حالت معمول، اگر تنظیمات تأیید نشوند تلاش می‌کند آن‌ها را برگرداند؛ اما این مکانیزم تضمین بازیابی همه سناریوها نیست. از کنسول بازیابی استفاده کنید و در صورت بروز مشکل فایل پشتیبان را از طریق کنسول بازگردانید. اگر Netplan توسط Cloud-init مدیریت می‌شود، تغییر مستقیم فایل تولیدشده ممکن است در بوت بعدی بازنویسی شود؛ منبع اصلی تنظیمات را شناسایی کنید.

ترمیم Symlink شکسته /etc/resolv.conf فقط در صورت اثبات مشکل

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

systemctl is-active systemd-resolved
test -f /run/systemd/resolve/stub-resolv.conf && echo "stub exists"
sudo cp -aP --no-clobber /etc/resolv.conf /root/resolv.conf.before-dns
sudo ln -sfn /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
readlink -f /etc/resolv.conf
resolvectl query example.com

Rollback: اگر فایل پشتیبان در مسیر بالا موجود است، پس از بررسی نوع آن و با دسترسی کنسول:

sudo cp -aP --remove-destination /root/resolv.conf.before-dns /etc/resolv.conf
ls -l /etc/resolv.conf
resolvectl status

توجه کنید اگر فایل اصلی از ابتدا وجود نداشته است، دستور پشتیبان‌گیری خطا می‌دهد؛ در این حالت پیش از ساخت لینک جدید علت حذف فایل و سرویس مالک Resolver را مشخص کنید.

پاک‌کردن کش، بررسی DNSSEC و خطاهای رایج

اگر پس از اصلاح DNS هنوز پاسخ قدیمی دریافت می‌شود، کش محلی را پاک کنید و دوباره تست بگیرید:

sudo resolvectl flush-caches
resolvectl statistics
resolvectl query example.com
journalctl -u systemd-resolved -b --no-pager -n 50

اگر لاگ از DNSSEC validation failed می‌گوید، ابتدا زمان سیستم، رکوردها، زنجیره اعتماد و وضعیت DNS بالادستی را بررسی کنید؛ DNSSEC را صرفاً برای پنهان‌کردن مشکل غیرفعال نکنید. اگر خطا connection timed out است، احتمال اختلال DNS بالادستی، فایروال یا مسیر بیشتر است. اگر resolvectl: command not found مشاهده می‌کنید، نسخه سیستم و بسته‌های نصب‌شده را بررسی کنید و بدون تشخیص سرویس Resolver فعلی را تغییر ندهید.

کنترل نهایی و تصمیم درباره زیرساخت VPS

بعد از هر اصلاح، فقط به موفقیت یک Ping اکتفا نکنید؛ Resolver، DNS سیستم و سرویس واقعی را با هم بسنجید:

systemctl is-active systemd-resolved
resolvectl status
resolvectl query example.com
getent ahostsv4 example.com
curl -I --connect-timeout 8 https://example.com

در خروجی سالم، دامنه به IP تبدیل می‌شود و درخواست HTTPS می‌تواند به مرحله اتصال برسد؛ وضعیت HTTP مثل 200 یا 301 به‌خودی‌خود معیار صحت DNS نیست. اگر خطا فقط برای یک دامنه داخلی است، تنظیمات Search Domain و Route-only Domain را بررسی کنید.

اگر عیب‌یابی را روی VPS انجام می‌دهید، در کنار اصلاح DNS فعلی، برای انتخاب زیرساخت آینده به دسترسی کنسول مستقل، روش بازیابی و نحوه مدیریت DNS توسط ارائه‌دهنده توجه کنید. می‌توانید مشخصات پلن‌های سرور مجازی وان‌سرور را در همین چارچوب ارزیابی کنید؛ تغییر یا خرید VPS به‌تنهایی خرابی Resolver فعلی را برطرف نمی‌کند و درباره امکانات هر پلن باید جداگانه استعلام گرفت.

منابع فنی و دامنه کاربرد

دستورها با مستندات رسمی systemd-resolved، resolvectl، Ubuntu Server Networking و Netplan try تطبیق داده شده‌اند. قبل از اجرای تغییرات روی سرور عملیاتی، نسخه Ubuntu، Renderer شبکه و تنظیمات اختصاصی سازمان را بررسی کنید.