مقدمه

یکی از رایج‌ترین مشکلات شبکه در سرورهای لینوکسی این است که سرور به IPها دسترسی دارد، اما قادر به Resolve کردن نام دامنه نیست.

برای مثال:

ping 8.8.8.8

بدون مشکل کار می‌کند، اما:

ping google.com

با خطای مربوط به Name Resolution مواجه می‌شود.

در چنین شرایطی، یکی از اولین بخش‌هایی که باید بررسی شود فایل:

/etc/resolv.conf

است.

این فایل اطلاعات مورد استفاده Resolver سیستم مانند DNS Serverها، Search Domain و برخی گزینه‌های Resolver را در اختیار کتابخانه‌های مربوط به Name Resolution قرار می‌دهد. با این حال در سیستم‌های جدید، ممکن است فایل /etc/resolv.conf مستقیماً توسط مدیر سرور مدیریت نشود و سرویس‌هایی مانند systemd-resolved یا NetworkManager آن را ایجاد یا به‌روزرسانی کنند.

فایل /etc/resolv.conf چیست؟

فایل:

/etc/resolv.conf

یکی از فایل‌های اصلی تنظیم Resolver در لینوکس است.

نمونه ساده:

nameserver 1.1.1.1
nameserver 8.8.8.8

در این مثال سیستم می‌تواند برای DNS Query از DNS Serverهای تعریف‌شده استفاده کند.

ساختار و گزینه‌های این فایل توسط Resolver کتابخانه C سیستم استفاده می‌شوند.

مشاهده محتوای resolv.conf

دستور زیر را اجرا کنید:

cat /etc/resolv.conf

نمونه:

nameserver 8.8.8.8
nameserver 1.1.1.1

ممکن است در Ubuntu خروجی متفاوتی مشاهده کنید:

nameserver 127.0.0.53

این آدرس معمولاً Stub Resolver محلی systemd-resolved است و لزوماً DNS Server نهایی سیستم نیست. systemd-resolved می‌تواند درخواست‌های DNS برنامه‌های محلی را دریافت کرده و آن‌ها را به DNS Serverهای مناسب ارسال کند.

معنی nameserver چیست؟

خط:

nameserver 8.8.8.8

آدرس یک Name Server را برای Resolver مشخص می‌کند. فایل resolv.conf می‌تواند چند nameserver داشته باشد.

مثال:

nameserver 1.1.1.1
nameserver 8.8.8.8

بررسی اینکه resolv.conf فایل است یا Symbolic Link

در سیستم‌های مدرن حتماً این مورد را بررسی کنید:

ls -l /etc/resolv.conf

ممکن است خروجی مشابه زیر باشد:

/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

در این حالت /etc/resolv.conf یک Symbolic Link است و systemd-resolved در مدیریت DNS نقش دارد. systemd چند حالت مختلف برای مدیریت /etc/resolv.conf پشتیبانی می‌کند که یکی از رایج‌ترین آن‌ها اتصال این فایل به Stub Resolver محلی است.

بررسی DNS با dig

ابتدا بررسی کنید DNS واقعاً کار می‌کند یا خیر:

dig google.com

خروجی کوتاه:

dig google.com +short

اگر IP نمایش داده شود، DNS Resolution انجام شده است.

بررسی با nslookup

nslookup google.com

این دستور علاوه بر نتیجه Query، معمولاً DNS Server مورد استفاده را نیز نمایش می‌دهد.

تست مستقیم DNS Server

برای اینکه مشخص شود مشکل از DNS Server سیستم است یا خیر، مستقیماً یک Resolver مشخص را Query کنید.

Cloudflare:

dig @1.1.1.1 google.com

Google:

dig @8.8.8.8 google.com

اگر این دستورات کار کنند ولی:

dig google.com

کار نکند، به احتمال زیاد تنظیم Resolver محلی سیستم نیاز به بررسی دارد.

تشخیص مشکل DNS با Ping

ابتدا IP را تست کنید:

ping -c 4 8.8.8.8

سپس دامنه:

ping -c 4 google.com

اگر IP پاسخ دهد اما دامنه Resolve نشود، اتصال پایه شبکه برقرار است و باید DNS Resolution بررسی شود.

بررسی Default Gateway

قبل از نتیجه‌گیری درباره DNS، Routing سیستم را نیز بررسی کنید:

ip route

باید Default Route وجود داشته باشد.

نمونه:

default via 192.168.1.1 dev eth0

بررسی DNS در Ubuntu با systemd-resolved

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

systemctl status systemd-resolved

اگر فعال باشد، اطلاعات DNS را با دستور زیر مشاهده کنید:

resolvectl status

resolvectl ابزار systemd برای مشاهده و مدیریت اطلاعات Resolver و DNS مربوط به Interfaceها است.

مشاهده DNS یک Interface

مثلاً:

resolvectl status eth0

یا در برخی سرورها:

resolvectl status ens18

نام Interface را می‌توانید با دستور زیر پیدا کنید:

ip addr

مشاهده DNS Serverهای واقعی

ممکن است /etc/resolv.conf فقط این مقدار را نشان دهد:

nameserver 127.0.0.53

در این حالت برای مشاهده Upstream DNS Serverها بهتر است:

resolvectl status

را بررسی کنید؛ زیرا 127.0.0.53 خود Stub محلی systemd-resolved است.

پاک کردن DNS Cache در systemd-resolved

sudo resolvectl flush-caches

سپس می‌توانید آمار Resolver را بررسی کنید:

resolvectl statistics

resolvectl امکان پاک‌سازی Cache محلی systemd-resolved را فراهم می‌کند.

ریستارت systemd-resolved

در صورت بروز مشکل:

sudo systemctl restart systemd-resolved

سپس:

systemctl status systemd-resolved

بررسی فایل resolved.conf

تنظیمات اصلی systemd-resolved در فایل زیر قرار می‌گیرند:

/etc/systemd/resolved.conf

برای مشاهده:

cat /etc/systemd/resolved.conf

این فایل برای تنظیم رفتار local DNS و Name Resolution در systemd-resolved استفاده می‌شود.

تنظیم DNS در systemd-resolved

می‌توانید فایل زیر را ویرایش کنید:

sudo nano /etc/systemd/resolved.conf

نمونه:

[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=9.9.9.9

سپس:

sudo systemctl restart systemd-resolved

مقادیر DNS= و FallbackDNS= از گزینه‌های تنظیم‌شده برای resolver در resolved.conf هستند.

مشکل بازنویسی resolv.conf

یکی از مشکلات رایج این است که فایل را ویرایش می‌کنید:

sudo nano /etc/resolv.conf

و مثلاً می‌نویسید:

nameserver 1.1.1.1

اما پس از Restart شبکه یا Reboot، تنظیم حذف می‌شود.

این رفتار زمانی طبیعی است که فایل توسط NetworkManager، systemd-resolved، DHCP Client یا ابزار دیگری مدیریت شود. NetworkManager می‌تواند DNS Configuration را دوباره تولید کرده و /etc/resolv.conf را به‌روزرسانی کند.

بنابراین قبل از ویرایش دستی فایل، مشخص کنید چه سرویسی آن را مدیریت می‌کند.

تشخیص مدیر resolv.conf

ابتدا:

ls -l /etc/resolv.conf

سپس:

systemctl is-active systemd-resolved

و:

systemctl is-active NetworkManager

در صورت استفاده از NetworkManager:

nmcli general status

بررسی DNS در NetworkManager

برای مشاهده اطلاعات DNS:

nmcli device show | grep DNS

نمونه:

IP4.DNS[1]: 192.168.1.1
IP4.DNS[2]: 1.1.1.1

NetworkManager تنظیمات DNS اتصال‌های فعال را مدیریت می‌کند و بسته به حالت پیکربندی می‌تواند /etc/resolv.conf را به‌روزرسانی کند یا DNS را به Resolver دیگری تحویل دهد.

مشاهده Connectionهای NetworkManager

nmcli connection show

مثلاً:

Wired connection 1

تنظیم DNS با NetworkManager

مثلاً:

sudo nmcli connection modify "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"

اگر نمی‌خواهید DNS دریافتی از DHCP استفاده شود:

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

سپس Connection را دوباره فعال کنید:

sudo nmcli connection up "Wired connection 1"

NetworkManager برای Connection Profileها امکان تعریف DNS Server و نادیده گرفتن DNS خودکار را فراهم می‌کند.

بررسی DNS دریافتی از DHCP

در بسیاری از سرورها DNS توسط DHCP دریافت می‌شود.

در NetworkManager:

nmcli device show

قسمت‌هایی مانند:

IP4.DNS

را بررسی کنید.

ممکن است DNS اشتباه توسط DHCP Server به سیستم تحویل داده شده باشد.

بررسی فایل /etc/nsswitch.conf

همیشه مشکل Name Resolution فقط به /etc/resolv.conf محدود نیست.

فایل:

/etc/nsswitch.conf

مشخص می‌کند سیستم برای پیدا کردن اطلاعات مربوط به نام‌ها از چه منابعی و با چه ترتیبی استفاده کند.

بررسی:

grep '^hosts:' /etc/nsswitch.conf

نمونه:

hosts: files dns

این مقدار یعنی سیستم ابتدا فایل‌های محلی مانند /etc/hosts را بررسی می‌کند و سپس DNS را مورد استفاده قرار می‌دهد.

بررسی /etc/hosts

cat /etc/hosts

یا برای یک دامنه خاص:

grep example.com /etc/hosts

اگر دامنه داخل این فایل به IP دیگری اشاره کند، بعضی برنامه‌ها ممکن است قبل از DNS همان مقدار را استفاده کنند؛ ترتیب دقیق منابع Name Service توسط /etc/nsswitch.conf تعیین می‌شود.

بررسی دسترسی به پورت DNS

DNS معمولاً از پورت 53 استفاده می‌کند.

برای تست UDP:

nc -zvu 8.8.8.8 53

برای TCP:

nc -zv 8.8.8.8 53

برای تست واقعی DNS بهتر است از:

dig @8.8.8.8 google.com

استفاده کنید.

بررسی Firewall

در Ubuntu:

sudo ufw status

در AlmaLinux:

sudo firewall-cmd --list-all

همچنین:

sudo nft list ruleset

را در صورت استفاده از nftables بررسی کنید.

اگر ترافیک خروجی DNS روی UDP/TCP پورت 53 مسدود شده باشد، Name Resolution می‌تواند دچار مشکل شود.

بررسی DNS با TCP

به‌طور معمول Queryهای DNS اغلب از UDP استفاده می‌کنند، اما TCP نیز بخشی از DNS است.

برای تست:

dig +tcp @8.8.8.8 google.com

اگر UDP کار نکند اما TCP کار کند، Firewall یا مسیر شبکه UDP باید بررسی شود.

خطای Temporary failure in name resolution

ممکن است هنگام اجرای:

ping google.com

خطایی مشابه زیر مشاهده کنید:

Temporary failure in name resolution

برای عیب‌یابی این ترتیب را بررسی کنید:

ping -c 4 8.8.8.8

سپس:

cat /etc/resolv.conf

بعد:

resolvectl status

و:

dig @1.1.1.1 google.com

خطای Could not resolve host

مثلاً:

curl: (6) Could not resolve host

ابتدا:

dig google.com

سپس:

dig @8.8.8.8 google.com

اگر Query مستقیم کار کند ولی Query عادی نه، Resolver محلی سیستم را بررسی کنید.

خطای no servers could be reached

اگر:

dig google.com

پیام:

no servers could be reached

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

cat /etc/resolv.conf

ip route

ping -c 4 8.8.8.8

dig @8.8.8.8 google.com

مشکل nameserver 127.0.0.53

وجود این مقدار:

nameserver 127.0.0.53

به‌تنهایی نشانه خرابی نیست.

در سیستم‌هایی که systemd-resolved از Stub Listener استفاده می‌کند، این آدرس برای ارسال Queryهای محلی به Resolver systemd استفاده می‌شود.

در چنین سیستمی ابتدا:

systemctl status systemd-resolved

و:

resolvectl status

را بررسی کنید.

اگر systemd-resolved متوقف باشد

بررسی:

systemctl status systemd-resolved

در صورت نیاز:

sudo systemctl restart systemd-resolved

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

بررسی Symbolic Link خراب

ls -l /etc/resolv.conf

سپس مقصد را بررسی کنید.

مثلاً:

ls -l /run/systemd/resolve/

اگر Symbolic Link به فایل ناموجود اشاره کند، تنظیم Resolver باید اصلاح شود.

تست با getent

گاهی dig کار می‌کند اما خود برنامه‌ها دامنه را Resolve نمی‌کنند.

در این حالت:

getent hosts google.com

را تست کنید.

getent مسیر Name Service سیستم را دنبال می‌کند و در بررسی تفاوت میان DNS Query مستقیم و Resolver واقعی برنامه‌ها مفید است.

تفاوت dig و getent در عیب‌یابی

فرض کنید:

dig google.com

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

getent hosts google.com

کار نمی‌کند.

در این شرایط فقط DNS Server را بررسی نکنید؛ تنظیمات NSS مانند:

/etc/nsswitch.conf

نیز اهمیت دارند، زیرا glibc و بسیاری از برنامه‌ها ترتیب منابع Name Service را از آن دریافت می‌کنند.

سناریوی عملی اول: IP کار می‌کند ولی دامنه نه

تست:

ping -c 4 8.8.8.8

موفق است.

اما:

ping -c 4 google.com

ناموفق است.

مراحل:

cat /etc/resolv.conf

سپس:

dig @1.1.1.1 google.com

اگر Query مستقیم موفق بود:

resolvectl status

یا:

nmcli device show | grep DNS

را بررسی کنید.

سناریوی عملی دوم: resolv.conf بعد از Reboot تغییر می‌کند

فرض کنید:

nameserver 1.1.1.1

را دستی در فایل قرار داده‌اید.

بعد از Reboot دوباره DNS قبلی ظاهر می‌شود.

ابتدا:

ls -l /etc/resolv.conf

و سپس مدیر شبکه را بررسی کنید.

اگر NetworkManager مسئول است، DNS را در Connection Profile تنظیم کنید؛ زیرا NetworkManager می‌تواند DNS Configuration را مجدداً در /etc/resolv.conf اعمال کند.

سناریوی عملی سوم: DNS Server اشتباه است

بررسی:

cat /etc/resolv.conf

مثلاً:

nameserver 192.168.1.1

مستقیماً Google را تست کنید:

dig @8.8.8.8 google.com

اگر کار کرد ولی:

dig @192.168.1.1 google.com

کار نکرد، DNS Server 192.168.1.1 باید بررسی شود.

سناریوی عملی چهارم: DNS فقط داخل Docker مشکل دارد

ممکن است DNS میزبان درست باشد اما Containerها مشکل داشته باشند.

ابتدا روی Host:

dig google.com

سپس:

docker exec CONTAINER_NAME cat /etc/resolv.conf

و:

docker exec CONTAINER_NAME getent hosts google.com

DNS داخل Container می‌تواند با Resolver میزبان تفاوت داشته باشد و باید جداگانه بررسی شود.

روش سریع عیب‌یابی DNS

به ترتیب زیر جلو بروید:

ip addr

ip route

ping -c 4 8.8.8.8

cat /etc/resolv.conf

ls -l /etc/resolv.conf

dig google.com

dig @1.1.1.1 google.com

getent hosts google.com

سپس در Ubuntu:

resolvectl status

و در سیستم‌های NetworkManager:

nmcli device show | grep DNS

این ترتیب معمولاً مشخص می‌کند مشکل در شبکه، DNS Server، Resolver محلی یا تنظیمات سیستم قرار دارد.

جدول مشکلات رایج

دستورات کاربردی

نمایش DNS:

cat /etc/resolv.conf

بررسی Symlink:

ls -l /etc/resolv.conf

بررسی systemd:

resolvectl status

بررسی NetworkManager:

nmcli device show | grep DNS

تست DNS:

dig google.com

تست مستقیم:

dig @1.1.1.1 google.com

تست Resolver سیستم:

getent hosts google.com

پاک کردن Cache:

sudo resolvectl flush-caches

بهترین روش‌ها

• قبل از ویرایش /etc/resolv.conf مشخص کنید چه سرویسی آن را مدیریت می‌کند.
• ابتدا ارتباط IP را از DNS جداگانه تست کنید.
• برای مقایسه از DNS عمومی مشخص مانند 1.1.1.1 یا 8.8.8.8 استفاده کنید.
• در Ubuntuهای مبتنی بر systemd-resolved از resolvectl استفاده کنید.
• در سیستم‌های NetworkManager تنظیمات دائمی را روی Connection Profile اعمال کنید.
• در عیب‌یابی فقط ping را ملاک قرار ندهید.
• dig و getent را در کنار یکدیگر استفاده کنید.

اشتباهات رایج

• ویرایش مستقیم /etc/resolv.conf بدون بررسی مدیر فایل
• حذف 127.0.0.53 صرفاً به دلیل ظاهر غیرعادی آن
• Disable کردن systemd-resolved بدون اصلاح /etc/resolv.conf
• نتیجه‌گیری درباره DNS بدون تست IP
• نادیده گرفتن /etc/nsswitch.conf
• فراموش کردن DNS دریافت‌شده از DHCP
• بررسی نکردن Firewall روی UDP و TCP پورت 53

چک‌لیست عیب‌یابی

هنگام بروز مشکل DNS بررسی کنید:

• IP Address
• Default Gateway
• اتصال اینترنت
• /etc/resolv.conf
• Symbolic Link فایل
• DNS Server
• systemd-resolved
• NetworkManager
• DHCP
• /etc/hosts
• /etc/nsswitch.conf
• DNS Cache
• Firewall
• UDP 53
• TCP 53
• DNS داخل Container

جمع‌بندی

فایل /etc/resolv.conf یکی از مهم‌ترین نقاط شروع برای عیب‌یابی DNS در لینوکس است، اما در سیستم‌های مدرن نباید فرض کرد که این فایل همیشه به‌صورت دستی مدیریت می‌شود. systemd-resolved و NetworkManager می‌توانند Resolver Configuration و /etc/resolv.conf را مدیریت یا بازتولید کنند.

برای عیب‌یابی صحیح ابتدا ارتباط شبکه را با IP بررسی کنید، سپس /etc/resolv.conf، DNS Serverهای واقعی، resolvectl یا NetworkManager و در نهایت /etc/hosts و /etc/nsswitch.conf را کنترل کنید. این روش کمک می‌کند دقیقاً مشخص شود مشکل از اتصال شبکه، DNS Server، Cache یا Resolver محلی سیستم است.

کیان پور