مقدمه

یکی از مشکلات رایج هنگام مدیریت دامنه و سرور این است که یک دامنه روی سرور به یک IP Resolve می‌شود، اما همان دامنه روی کامپیوتر شخصی، لپ‌تاپ یا شبکه دیگری IP متفاوتی نمایش می‌دهد.

برای مثال ممکن است روی سرور لینوکسی دستور زیر:

dig example.com

یک IP جدید را نمایش دهد، اما روی کامپیوتر شخصی:

nslookup example.com

هنوز IP قدیمی مشاهده شود.

این مشکل معمولاً به معنی خرابی DNS نیست و می‌تواند به دلیل کش DNS، استفاده از DNS Resolver متفاوت، TTL، فایل hosts، DNS داخلی، VPN، CDN یا تنظیمات اشتباه Name Server ایجاد شود.

در این مقاله به‌صورت مرحله‌به‌مرحله علت تفاوت پاسخ DNS بین سرور و کامپیوتر شخصی را بررسی و عیب‌یابی می‌کنیم.

DNS چگونه Resolve می‌شود؟

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

example.com

را در مرورگر یا ترمینال وارد می‌کنید، سیستم معمولاً مستقیماً به Authoritative DNS Server دامنه متصل نمی‌شود.

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

Computer
   ↓
Local DNS Cache
   ↓
Configured DNS Resolver
   ↓
Recursive DNS
   ↓
Authoritative DNS Server
   ↓
IP Address

بنابراین دو سیستم مختلف می‌توانند از Resolverهای متفاوت استفاده کنند و موقتاً پاسخ متفاوتی دریافت کنند.

سناریوی نمونه

فرض کنید IP قدیمی سایت:

192.0.2.10

بوده و آن را به IP جدید زیر تغییر داده‌اید:

203.0.113.20

روی سرور:

dig example.com +short

خروجی:

203.0.113.20

اما روی کامپیوتر شخصی:

nslookup example.com

خروجی:

192.0.2.10

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

مرحله اول: بررسی DNS روی سرور

در لینوکس:

dig example.com

برای خروجی ساده‌تر:

dig example.com +short

نمونه:

203.0.113.20

دستور dig برای بررسی مستقیم پاسخ DNS Serverها طراحی شده و یکی از ابزارهای اصلی عیب‌یابی DNS است.

مرحله دوم: بررسی DNS روی کامپیوتر شخصی

در Windows:

nslookup example.com

نمونه:

Server: 192.168.1.1
Address: 192.168.1.1

Name: example.com
Address: 192.0.2.10

در این مثال مشخص می‌شود که کامپیوتر از DNS Server روتر یعنی:

192.168.1.1

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

مرحله سوم: مشخص کردن DNS Server مورد استفاده

یکی از مهم‌ترین مراحل عیب‌یابی این است که بررسی کنیم هر دستگاه از چه DNS Resolverی استفاده می‌کند.

در Linux

cat /etc/resolv.conf

نمونه:

nameserver 127.0.0.53

در سیستم‌هایی که از systemd-resolved استفاده می‌کنند:

resolvectl status

resolvectl اطلاعات Resolverهای مورد استفاده توسط سیستم و Interfaceهای شبکه را نمایش می‌دهد.

در Windows

ipconfig /all

بخش زیر را پیدا کنید:

DNS Servers

ممکن است مشاهده کنید:

192.168.1.1

یا:

8.8.8.8
1.1.1.1

مرحله چهارم: تست با DNS Server یکسان

برای مقایسه صحیح، باید هر دو سیستم را مستقیماً با یک DNS Resolver تست کنیم.

مثلاً Google DNS:

dig @8.8.8.8 example.com +short

روی Windows:

nslookup example.com 8.8.8.8

سپس Cloudflare:

dig @1.1.1.1 example.com +short

روی Windows:

nslookup example.com 1.1.1.1

اگر نتیجه هر دو سیستم با Resolver یکسان یکی باشد، مشکل از DNS عمومی دامنه نیست و احتمالاً Resolver پیش‌فرض یکی از سیستم‌ها پاسخ قدیمی را Cache کرده است.

مرحله پنجم: مقایسه چند DNS Resolver

برای دامنه موردنظر این تست‌ها را اجرا کنید:

dig @8.8.8.8 example.com +short

dig @1.1.1.1 example.com +short

dig @9.9.9.9 example.com +short

اگر نتایج متفاوت باشند، معمولاً تغییر DNS هنوز در Cache بعضی Resolverها باقی مانده است.

TTL چیست و چه تأثیری دارد؟

هر DNS Record دارای مقداری به نام TTL یا Time To Live است.

TTL مشخص می‌کند DNS Resolver چه مدت اجازه دارد پاسخ یک رکورد را در Cache نگهداری کند.

برای مشاهده TTL:

dig example.com

نمونه:

example.com. 3600 IN A 203.0.113.20

عدد:

3600

یعنی Resolver می‌تواند این پاسخ را تا 3600 ثانیه، یعنی یک ساعت، Cache کند.

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

مرحله ششم: پاک کردن DNS Cache در Windows

برای پاک کردن DNS Cache:

ipconfig /flushdns

این دستور محتویات DNS Client Resolver Cache ویندوز را پاک و Reset می‌کند.

خروجی معمول:

Successfully flushed the DNS Resolver Cache.

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

nslookup example.com

مشاهده DNS Cache در Windows

برای مشاهده Cache:

ipconfig /displaydns

اگر IP قدیمی دامنه در Cache وجود داشته باشد، می‌توانید آن را مشاهده کنید.

Microsoft نیز هنگام عیب‌یابی DNS Client بررسی Cache و سپس اجرای ipconfig /flushdns را توصیه می‌کند.

مرحله هفتم: پاک کردن DNS Cache در Linux

روش پاک کردن Cache بستگی به Resolver مورد استفاده دارد.

در سیستم‌هایی که systemd-resolved فعال است:

sudo resolvectl flush-caches

سپس:

resolvectl statistics

در صورت استفاده از سرویس‌های DNS Cache دیگر باید همان سرویس بررسی شود.

مرحله هشتم: بررسی فایل hosts

یکی از دلایل مهم تفاوت نتیجه DNS، تعریف دستی دامنه در فایل hosts است.

Linux

فایل:

/etc/hosts

بررسی:

grep example.com /etc/hosts

Windows

مسیر فایل:

C:\Windows\System32\drivers\etc\hosts

برای مثال اگر داخل آن نوشته شده باشد:

192.0.2.10 example.com

سیستم ممکن است بدون مراجعه به DNS، همان IP را استفاده کند.

مرحله نهم: تفاوت nslookup با مرورگر

گاهی:

nslookup example.com

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

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

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

• Browser DNS Cache
• HTTP Cache
• Service Worker
• Proxy
• VPN
• Secure DNS یا DNS over HTTPS
• CDN

برای تست می‌توانید ابتدا از مرورگر دیگری یا Private/Incognito Mode استفاده کنید.

بررسی DNS over HTTPS

مرورگرهایی مانند Chrome، Firefox و Edge می‌توانند از DNS over HTTPS (DoH) استفاده کنند.

در این شرایط ممکن است:

nslookup example.com

از DNS سیستم استفاده کند، اما مرورگر DNS Query را به Resolver دیگری ارسال کند.

بنابراین ممکن است نتیجه مرورگر با nslookup متفاوت باشد.

مرحله دهم: بررسی VPN

اگر VPN فعال باشد، ممکن است DNS Server توسط VPN تغییر کرده باشد.

در Windows:

ipconfig /all

را اجرا کرده و DNS مربوط به Adapter فعال را بررسی کنید.

در Linux:

resolvectl status

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

پس از قطع VPN دوباره Query را تست کنید.

مرحله یازدهم: بررسی DNS روتر

گاهی کامپیوتر DNS خود را از Router دریافت می‌کند.

برای مثال:

DNS Server: 192.168.1.1

در این حالت Router می‌تواند Cache DNS داشته باشد.

برای بررسی، به‌جای DNS Router مستقیماً از DNS عمومی استفاده کنید:

nslookup example.com 1.1.1.1

اگر پاسخ درست شد ولی:

nslookup example.com

همچنان IP قدیمی را برگرداند، مشکل احتمالاً از Resolver شبکه یا Router است.

مرحله دوازدهم: بررسی Authoritative DNS

باید مشخص کنیم DNS اصلی دامنه چه پاسخی ارائه می‌دهد.

ابتدا Name Serverها را پیدا کنید:

dig example.com NS +short

نمونه:

ns1.example.net.
ns2.example.net.

سپس مستقیماً یکی از آن‌ها را Query کنید:

dig @ns1.example.net example.com A

اگر Authoritative DNS:

203.0.113.20

را نمایش دهد، رکورد اصلی صحیح است.

مقایسه Authoritative DNS با Resolver

مثلاً:

dig @ns1.example.net example.com A +short

خروجی:

203.0.113.20

اما:

dig @8.8.8.8 example.com A +short

خروجی:

192.0.2.10

این وضعیت معمولاً نشان می‌دهد Resolver هنوز رکورد قبلی را Cache کرده است.

مرحله سیزدهم: استفاده از dig +trace

برای بررسی مسیر کامل DNS:

dig +trace example.com

این دستور Query را از Root DNSها تا Authoritative DNS دنبال می‌کند و در عیب‌یابی Delegation و Name Server بسیار مفید است.

مرحله چهاردهم: بررسی Name Serverهای دامنه

dig NS example.com +short

همچنین می‌توانید:

whois example.com

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

اگر Name Serverهای Registrar با Name Serverهایی که انتظار دارید متفاوت باشند، مشکل از Delegation دامنه است.

مرحله پانزدهم: بررسی رکورد A و AAAA

گاهی مشکل از IPv4 نیست، بلکه سیستم یکی از رکوردهای IPv6 را استفاده می‌کند.

IPv4:

dig example.com A +short

IPv6:

dig example.com AAAA +short

ممکن است رکورد A به سرور جدید اشاره کند ولی AAAA همچنان به سرور قدیمی متصل باشد.

مرحله شانزدهم: بررسی www و دامنه اصلی

این دو لزوماً رکورد یکسانی ندارند.

بررسی دامنه اصلی:

dig example.com +short

بررسی www:

dig www.example.com +short

ممکن است:

example.com

به IP جدید اشاره کند، اما:

www.example.com

هنوز CNAME یا A Record قدیمی داشته باشد.

بررسی CNAME

dig www.example.com CNAME

اگر CNAME تعریف شده باشد، مقصد آن را نیز بررسی کنید:

dig target.example.net +short

مرحله هفدهم: بررسی Split DNS

در بعضی شبکه‌ها از Split DNS استفاده می‌شود.

در این حالت یک دامنه ممکن است:

از داخل شرکت:

10.10.10.20

و از اینترنت:

203.0.113.20

را برگرداند.

این رفتار می‌تواند کاملاً عمدی باشد.

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

مرحله هجدهم: بررسی DNS Server خود سرور

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

طبق مستندات BIND، اگر برای dig DNS Server مشخص نکنید، این ابزار معمولاً Resolverهای موجود در /etc/resolv.conf را Query می‌کند.

بررسی:

cat /etc/resolv.conf

مثلاً:

nameserver 127.0.0.53

یا:

nameserver 8.8.8.8

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

dig example.com

ممکن است با:

dig @1.1.1.1 example.com

تفاوت داشته باشد.

مرحله نوزدهم: بررسی DNS Cache روی DNS Server محلی

اگر سازمان یا سرور شما DNS Resolver اختصاصی مانند:

• BIND
• Unbound
• dnsmasq
• Windows DNS Server

دارد، ممکن است پاسخ قدیمی داخل Cache همان Resolver باقی مانده باشد.

در این شرایط باید Cache Resolver مربوطه بررسی شود.

مرحله بیستم: بررسی CDN و Proxy

اگر دامنه پشت سرویس‌هایی مانند CDN یا Reverse Proxy قرار داشته باشد، ممکن است DNS عمداً IP سرویس واسط را نمایش دهد.

در این حالت IP نمایش‌داده‌شده الزاماً IP واقعی Web Server نیست.

بنابراین قبل از نتیجه‌گیری بررسی کنید دامنه از CDN یا Proxy استفاده می‌کند یا خیر.

جدول علت‌های رایج تفاوت DNS

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

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

1. بررسی IP روی هر دو سیستم

Linux:

dig example.com +short

Windows:

nslookup example.com

2. تست Google DNS

Linux:

dig @8.8.8.8 example.com +short

Windows:

nslookup example.com 8.8.8.8

3. تست Cloudflare DNS

Linux:

dig @1.1.1.1 example.com +short

Windows:

nslookup example.com 1.1.1.1

4. بررسی Authoritative DNS

dig example.com NS +short

سپس:

dig @NAME-SERVER example.com +short

5. بررسی TTL

dig example.com

6. پاک کردن Cache ویندوز

ipconfig /flushdns

7. پاک کردن Cache لینوکس

در سیستم‌های مبتنی بر systemd-resolved:

sudo resolvectl flush-caches

8. بررسی hosts

Linux:

grep example.com /etc/hosts

Windows:

C:\Windows\System32\drivers\etc\hosts

سناریوی عملی کامل

فرض کنید:

dig example.com +short

روی سرور:

203.0.113.20

اما کامپیوتر:

nslookup example.com

نمایش می‌دهد:

192.0.2.10

ابتدا:

nslookup example.com 1.1.1.1

اگر خروجی:

203.0.113.20

شد، DNS عمومی Cloudflare رکورد جدید را دریافت کرده است.

سپس DNS پیش‌فرض سیستم را بررسی کنید:

ipconfig /all

اگر DNS Server:

192.168.1.1

باشد، احتمالاً Router یا DNS مربوط به ISP هنوز رکورد قبلی را Cache کرده است.

در این شرایط می‌توان DNS سیستم را موقتاً روی:

1.1.1.1
8.8.8.8

قرار داد و دوباره تست کرد.

اگر فقط مرورگر مشکل دارد چه کنیم؟

اگر:

nslookup example.com

IP صحیح را برمی‌گرداند اما سایت همچنان از سرور قبلی باز می‌شود، این موارد را بررسی کنید:

• Browser Cache
• Secure DNS
• Proxy
• VPN
• CDN
• فایل hosts
• Service Worker
• IPv6

در این مرحله مشکل الزاماً DNS سیستم نیست.

چه زمانی باید منتظر DNS Propagation باشیم؟

اگر رکورد DNS یا Name Server اخیراً تغییر کرده باشد، Resolverهای مختلف ممکن است تا پایان TTL قبلی پاسخ قدیمی را نگهداری کنند.

بنابراین عبارت «DNS Propagation» معمولاً به این معناست که Cacheهای مختلف در زمان‌های متفاوت منقضی می‌شوند، نه اینکه یک رکورد به‌صورت فیزیکی از یک DNS Server به DNS Server دیگر منتقل شود.

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

• بررسی DNS فقط با یک Resolver
• تصور اینکه ping ابزار مناسبی برای بررسی DNS Record است
• پاک کردن Cache بدون بررسی Authoritative DNS
• نادیده گرفتن فایل hosts
• فراموش کردن رکورد AAAA
• تست example.com ولی باز کردن www.example.com
• نادیده گرفتن VPN و DNS over HTTPS
• نتیجه‌گیری اینکه هر تفاوت DNS به معنی مشکل DNS Server است

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

برای عیب‌یابی حرفه‌ای همیشه سه سطح را جداگانه بررسی کنید:

Authoritative DNS
        ↓
Public Resolver
        ↓
Local Client

ابتدا مشخص کنید رکورد اصلی صحیح است یا خیر، سپس Resolver عمومی و در نهایت Cache و تنظیمات دستگاه کاربر را بررسی کنید.

چک‌لیست

هنگام مشاهده نتیجه متفاوت DNS بررسی کنید:

• Authoritative DNS
• Google DNS
• Cloudflare DNS
• DNS Server سیستم
• TTL
• DNS Cache
• فایل hosts
• VPN
• Proxy
• DNS over HTTPS
• A Record
• AAAA Record
• www
• CNAME
• Split DNS
• CDN

مطالعات بیشتر

• مستندات dig در BIND 9؛ این ابزار برای Query مستقیم DNS Server و عیب‌یابی DNS طراحی شده است.

جمع‌بندی

تفاوت نتیجه DNS بین سرور و کامپیوتر شخصی معمولاً به دلیل استفاده از DNS Resolverهای متفاوت، Cache قدیمی، TTL، فایل hosts، VPN، DNS over HTTPS، Split DNS یا رکوردهای متفاوت IPv4 و IPv6 ایجاد می‌شود.

بهترین روش عیب‌یابی این است که ابتدا پاسخ Authoritative DNS را بررسی کنید، سپس همان دامنه را با Resolverهای عمومی مانند Google و Cloudflare تست کرده و در نهایت Cache و تنظیمات DNS سیستم شخصی را بررسی کنید.

با این روش می‌توان دقیقاً مشخص کرد اختلاف پاسخ DNS در کدام قسمت از مسیر Resolve ایجاد شده است.

کیان پور