آموزش تنظیم DNS در ویندوز و لینوکس؛ راه‌حل مشکل آپدیت نشدن سرور و دانلود نشدن پکیج‌ها از گیت‌هاب

چرا این روزها سرورهای ایرانی نمی‌توانند آپدیت شوند؟

چند روزی است که روی برخی از DNS‌های دیتاسنترهای ایران محدودیت‌هایی اعمال شده و این موضوع مستقیماً روی سرورهای مجازی (VPS) و سرورهای اختصاصی (Dedicated Server) اثر گذاشته است.
اگر روی یک سرور مجازی لینوکس ایران یا نسخه‌ی ویندوزی آن کار می‌کنید، احتمالاً همین چند روز با این ماجرا روبه‌رو شده‌اید.
نتیجه‌اش را احتمالاً خودتان هم دیده‌اید: سروری که تا دیروز بدون مشکل کار می‌کرد، حالا نمی‌تواند یک پکیج ساده را از گیت‌هاب دانلود کند، ایمیج داکر را pull کند، یا حتی سیستم‌عامل اوبونتو، دبیان، آلمالینوکس و راکی‌لینوکس خودش را آپدیت کند.

نکته‌ی مهم اینجاست که در بیشتر این موارد سرور شما مشکلی ندارد، پهنای باند شما هم قطع نشده و فایروال هم چیزی را نبسته است. مشکل در لایه‌ی Name Resolution یا همان تبدیل نام دامنه به آی‌پی است. وقتی DNS پیش‌فرض دیتاسنتر نتواند دامنه‌ای مثل github.com یا archive.ubuntu.com را درست resolve کند، همه‌چیز از کار می‌افتد؛ حتی اگر اتصال اینترنت سرور کاملاً سالم باشد.

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

DNS چیست و چرا اینقدر تعیین‌کننده است؟

DNS مخفف Domain Name System است؛ چیزی شبیه دفترچه تلفن اینترنت. شما نام دامنه را می‌شناسید ولی شبکه فقط آی‌پی می‌فهمد. وقتی روی سرورتان دستور نصب یک پکیج را می‌زنید، اولین کاری که سیستم‌عامل انجام می‌دهد این است که از سرویس‌دهنده DNS بپرسد «آدرس این دامنه چند است؟». اگر پاسخ اشتباه، خالی یا کند برگردد، ادامه‌ی زنجیره هرگز اتفاق نمی‌افتد.

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

• خطای Temporary failure resolving هنگام آپدیت اوبونتو و دبیان
• خطای Could not resolve host در دستورات git clone و curl و wget
• گیر کردن یا timeout شدن pull ایمیج‌های داکر
• نصب نشدن پکیج‌های npm، pip، composer و go get
• باز نشدن مخازن EPEL، Remi و ریپازیتوری‌های شخص ثالث در آلمالینوکس و راکی
• کند شدن عجیب سایت یا اپلیکیشن، بدون آنکه منابع سرور پر شده باشد

به همین دلیل است که در پایش سرور، بررسی سلامت DNS به‌اندازه‌ی بررسی CPU و رم اهمیت دارد؛ خیلی وقت‌ها ریشه‌ی یک قطعی، نه دیتابیس است و نه ترافیک، بلکه یک resolver خراب است.

چطور مطمئن شویم مشکل از DNS است؟

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

۱) تست اتصال با آی‌پی خام

ping -c 4 8.8.8.8

اگر این دستور جواب می‌دهد، یعنی اینترنت سرور برقرار است.

۲) تست resolve شدن نام دامنه

ping -c 4 github.com

اگر دستور بالا با پیام Name or service not known شکست خورد، مشکل از DNS است.

۳) بررسی دقیق‌تر با dig و nslookup

dig github.com +short
dig @8.8.8.8 github.com +short
nslookup github.com 1.1.1.1

اگر dig github.com چیزی برنگرداند ولی dig @8.8.8.8 github.com جواب درست بدهد،
یعنی resolver فعلی سرور شما مشکل دارد و باید تعویض شود.

۴) دیدن DNS فعلی سرور

cat /etc/resolv.conf
resolvectl status

و در ویندوز:

ipconfig /all
Get-DnsClientServerAddress

بهترین DNS‌های عمومی خارجی

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

DNS‌های داخلی و ایرانی

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

پیشنهاد عملی: ترکیب کردن یک DNS داخلی به‌عنوان گزینه‌ی اول و یک DNS جهانی به‌عنوان گزینه‌ی دوم، معمولاً بهترین نتیجه را می‌دهد؛ مثلاً 178.22.122.100 در کنار 8.8.8.8.

هیچ ترکیب واحدی برای همه‌ی دیتاسنترها بهترین نیست و باید روی سرور خودتان تست کنید.

آموزش تنظیم DNS در ویندوز

مراحل زیر هم روی ویندوز دسکتاپ و هم روی ویندوز سرور یکسان است؛ بنابراین اگر از سرور مجازی ویندوز ایراناستفاده می‌کنید، دقیقاً همین مسیر را از طریق ریموت دسکتاپ دنبال کنید.

روش اول: از طریق رابط گرافیکی (ویندوز ۱۰، ۱۱ و ویندوز سرور)

1. کلیدهای Win + R را بزنید، عبارت ncpa.cpl را تایپ و اجرا کنید.
2. روی کارت شبکه‌ی فعال (Ethernet یا Wi-Fi) کلیک راست کرده و Properties را انتخاب کنید.
3. گزینه‌ی Internet Protocol Version 4 (TCP/IPv4) را انتخاب و روی Properties کلیک کنید.
4. گزینه‌ی Use the following DNS server addresses را فعال کنید.
5. در فیلد Preferred DNS server و Alternate DNS server مقادیر دلخواه را وارد کنید.
6. تیک Validate settings upon exit را بزنید و روی OK کلیک کنید.

روش دوم: تنظیم DNS با PowerShell

ابتدا نام کارت شبکه را پیدا کنید:

Get-NetAdapter

سپس DNS را ست کنید (نام Ethernet را با نام کارت شبکه‌ی خودتان جایگزین کنید):

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("178.22.122.100","8.8.8.8")

برای بازگرداندن تنظیمات به حالت خودکار (DHCP):

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses

روش سوم: تنظیم DNS با netsh در CMD

netsh interface ip set dns name="Ethernet" static 178.22.122.100 primary
netsh interface ip add dns name="Ethernet" 8.8.8.8 index=2

پاک کردن کش DNS در ویندوز

بعد از هر تغییر، حتماً کش را خالی کنید تا نتایج قدیمی اعمال نشوند:

ipconfig /flushdns
ipconfig /registerdns

و برای بررسی نتیجه:

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName github.com

آموزش تنظیم DNS در لینوکس

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

روش ۱: ویرایش مستقیم فایل resolv.conf (سریع اما موقت)

nano /etc/resolv.conf

محتوای فایل را به شکل زیر تغییر دهید:

nameserver 178.22.122.100
nameserver 8.8.8.8
nameserver 1.1.1.1

سپس تست کنید:

dig github.com +short
apt update

اگر می‌خواهید این فایل با ریبوت بازنویسی نشود، می‌توانید آن را قفل کنید
(این کار را فقط وقتی انجام دهید که مطمئن هستید DNS انتخابی درست کار می‌کند):

chattr +i /etc/resolv.conf

و برای برداشتن قفل:

chattr -i /etc/resolv.conf

روش ۲: تنظیم دائمی با systemd-resolved (اوبونتو ۱۸ به بعد و دبیان)

nano /etc/systemd/resolved.conf

خطوط زیر را اضافه یا از حالت کامنت خارج کنید:

[Resolve]
DNS=178.22.122.100 8.8.8.8
FallbackDNS=1.1.1.1 208.67.222.222
DNSStubListener=yes

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

systemctl restart systemd-resolved
systemctl status systemd-resolved
resolvectl status

برای پاک کردن کش DNS در این حالت:

resolvectl flush-caches

روش ۳: تنظیم DNS با Netplan (اوبونتو سرور ۱۸.۰۴ به بعد)

ابتدا فایل کانفیگ را پیدا کنید:

ls /etc/netplan/

سپس فایل مربوطه را ویرایش کنید:

nano /etc/netplan/00-installer-config.yaml

ساختار فایل باید چیزی شبیه این باشد (به فاصله‌گذاری YAML دقت کنید):

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [178.22.122.100, 8.8.8.8, 1.1.1.1]

در نهایت تغییرات را اعمال کنید:

netplan try
netplan apply

روش ۴: تنظیم DNS با NetworkManager و nmcli (آلمالینوکس، راکی، سنت‌اواس، فدورا)

ابتدا لیست کانکشن‌ها را ببینید:

nmcli connection show

سپس DNS را روی کانکشن مورد نظر ست کنید:

nmcli connection modify "System eth0" ipv4.dns "178.22.122.100 8.8.8.8"
nmcli connection modify "System eth0" ipv4.ignore-auto-dns yes
nmcli connection down "System eth0" && nmcli connection up "System eth0"

روش ۵: ویرایش فایل ifcfg در توزیع‌های قدیمی‌تر RHEL

nano /etc/sysconfig/network-scripts/ifcfg-eth0

خطوط زیر را اضافه کنید:

PEERDNS=no
DNS1=178.22.122.100
DNS2=8.8.8.8

و سرویس شبکه را ری‌استارت کنید:

systemctl restart NetworkManager

روش ۶: تنظیم DNS برای داکر

نکته‌ای که خیلی‌ها از آن غافل می‌شوند: کانتینرهای داکر لزوماً از DNS سرور میزبان استفاده نمی‌کنند.
اگر docker pull یا بیلد شدن ایمیج‌ها با خطای DNS متوقف می‌شود، فایل کانفیگ داکر را ویرایش کنید:

nano /etc/docker/daemon.json

محتوای زیر را وارد کنید:

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

و سرویس داکر را ری‌استارت کنید:

systemctl restart docker

تست نهایی بعد از تغییر DNS

بعد از اعمال تنظیمات، این چند دستور به شما می‌گویند که آیا مشکل واقعاً حل شده یا نه:

dig github.com +short
curl -I https://github.com
apt update
yum makecache

برای اندازه‌گیری سرعت پاسخ‌دهی DNS و مقایسه‌ی چند resolver:

dig @8.8.8.8 github.com | grep "Query time"
dig @1.1.1.1 github.com | grep "Query time"
dig @178.22.122.100 github.com | grep "Query time"
dig @217.218.127.127 github.com | grep "Query time"

هر کدام که Query time کمتری داشت و پاسخ درست برگرداند، برای شبکه‌ی شما گزینه‌ی بهتری است.

نکات مهم و اشتباهات رایج

• همیشه بیش از یک DNS ست کنید. اگر resolver اول از دسترس خارج شود، دومی جلوی قطعی کامل را می‌گیرد.
• DNS داخلی و خارجی را ترکیب کنید. این کار پوشش بهتری برای دامنه‌های داخلی و بین‌المللی می‌دهد.
• بعد از هر تغییر، کش را پاک کنید. در غیر این صورت ممکن است ساعت‌ها با نتایج قدیمی سر کنید.
• قبل از قفل کردن resolv.conf تست کنید. قفل کردن یک کانفیگ اشتباه، عیب‌یابی را سخت می‌کند.
• حواستان به داکر و کانتینرها باشد. تنظیم DNS روی هاست، لزوماً مشکل داخل کانتینر را حل نمی‌کند.
• DNS را پایش کنید. خرابی resolver اغلب بی‌سروصداست و تا وقتی کاربر شکایت نکند متوجه نمی‌شوید.

گام بعدی: پایش دائمی به‌جای عیب‌یابی لحظه‌ای

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

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

بهترین DNS برای سرورهای ایران کدام است؟

پاسخ واحدی وجود ندارد، چون به دیتاسنتر و مسیر شبکه‌ی شما بستگی دارد.
اما ترکیب یک DNS داخلی مثل 178.22.122.100 با یک DNS جهانی مثل 8.8.8.8 یا 1.1.1.1 در بیشتر موارد نتیجه‌ی خوبی می‌دهد. حتماً با دستور dig چند گزینه را تست کنید.

چرا سرورم بعد از تغییر DNS هنوز آپدیت نمی‌شود؟

سه دلیل رایج دارد: کش DNS پاک نشده، فایل /etc/resolv.conf پس از ریبوت بازنویسی شده،
یا مشکل اصلاً از DNS نبوده و فایروال / مسیر شبکه دخیل است. با دستور
dig @DNS_IP domain می‌توانید این موارد را از هم تفکیک کنید.

آیا تغییر DNS سرعت سایت را زیاد می‌کند؟

به‌طور مستقیم پهنای باند را افزایش نمی‌دهد، اما زمان resolve شدن دامنه بخشی از زمان بارگذاری هر درخواست است.
یک resolver کند می‌تواند ده‌ها تا صدها میلی‌ثانیه به هر اتصال اضافه کند؛ پس بله، اثر محسوسی دارد.

تغییر DNS روی سرور خطرناک است؟

اگر تنظیمات را درست وارد کنید، ریسک بسیار پایینی دارد و کاملاً برگشت‌پذیر است.
فقط پیش از ویرایش، از فایل کانفیگ نسخه‌ی پشتیبان بگیرید و روی سرورهای حساس در ساعات کم‌ترافیک تغییر دهید.

فرق DNS معمولی با DoH و DoT چیست؟

در DNS معمولی، درخواست‌ها رمزنگاری نشده‌اند. در DoH (DNS over HTTPS) و DoT (DNS over TLS) این درخواست‌ها رمزنگاری می‌شوند و امنیت و حریم خصوصی بالاتری دارند. برای سرورهای پروडکشن، در صورتی که resolver انتخابی پشتیبانی کند، استفاده از آن‌ها توصیه می‌شود.

جمع‌بندی

محدودیت‌های اخیر روی DNS دیتاسنترهای ایران نشان داد که چقدر زیرساخت‌های ما به یک لایه‌ی به‌ظاهر کم‌اهمیت وابسته‌اند. خوشبختانه راه‌حل ساده است: چند DNS را روی سرور خودتان تست کنید، بهترینشان را انتخاب کنید و تنظیمات را به‌صورت دائمی اعمال کنید.
چه روی ویندوز باشید، چه اوبونتو، دبیان، آلمالینوکس یا راکی‌لینوکس، همه‌ی دستورهای لازم را در همین مقاله دارید.

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