رفع خطاهای DNS و مشکل باز نشدن سایت پس از تغییر نیم سرور

مقدمه:

اگر بعد از تغییر Name Server دامنه، سایت باز نمی‌شود، نباید فوراً نتیجه گرفت که هاست یا سرور خراب است. رفع خطاهای DNS و مشکل باز نشدن سایت پس از تغییر نیم سرور با بررسی چند بخش مشخص انجام می‌شود: نیم‌سرورهای ثبت‌شده در رجیسترار، رکوردهای DNS روی سرور authoritative، کش Resolverها، رکوردهای A و AAAA، DNSSEC و در نهایت وضعیت وب‌سرور. DNS برای یافتن مقصد یک نام دامنه استفاده می‌شود و Name Serverهای authoritative پاسخ نهایی مربوط به رکوردهای دامنه را ارائه می‌کنند.

فهرست مطالب پیشنهادی

1. چرا بعد از تغییر نیم سرور سایت باز نمی‌شود؟
2. رفع خطاهای DNS و مشکل باز نشدن سایت پس از تغییر نیم سرور
3. تفاوت مشکل DNS با مشکل هاست یا سرور
4. بررسی صحیح Name Server دامنه
5. بررسی رکورد A و AAAA
6. DNS Propagation و Cache چیست؟
7. بررسی خطاهای SERVFAIL و NXDOMAIN
8. نقش DNSSEC در باز نشدن سایت
9. آموزش تست DNS با nslookup و dig
10. چک‌لیست عیب‌یابی مرحله‌به‌مرحله
11. اشتباهات رایج هنگام تغییر DNS
12. جمع‌بندی و سؤالات متداول

CTA اول: اگر بعد از تغییر نیم سرور نمی‌توانید تشخیص دهید مشکل از دامنه، DNS Zone، هاست یا خود سرور است، کارشناسان شرکت تجارت الکترونیک نوژن می‌توانند ساختار DNS و تنظیمات سرویس شما را بررسی کنند تا قبل از ایجاد تغییرات بیشتر، علت اختلال مشخص شود.

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

تغییر Name Server در ظاهر کار ساده‌ای است، اما در پشت صحنه مشخص می‌کند کدام DNS Server مسئول پاسخ‌دادن به درخواست‌های دامنه باشد. در ساختار DNS، Delegation باعث می‌شود دامنه والد به Name Serverهای authoritative دامنه اشاره کند.

بنابراین اگر Name Serverهای جدید ثبت شوند اما DNS Zone روی آن‌ها کامل نباشد، دامنه ممکن است دیگر IP صحیح سایت را برنگرداند.

برای مثال فرض کنید قبل از انتقال، دامنه شما چنین رکوردی داشته باشد:

example.com    A    192.0.2.10

بعد از تغییر نیم سرور، اگر روی DNS جدید این A Record ایجاد نشده باشد، کاربر نمی‌تواند از طریق DNS به IP موردنظر برسد.

مشکل فقط به A Record محدود نیست. وجود AAAA اشتباه، CNAME نادرست، Name Server غیرقابل‌دسترسی یا تنظیم DNSSEC ناسازگار نیز می‌تواند باعث شود سایت برای بخشی یا تمام کاربران باز نشود.

[لینک داخلی پیشنهادی: انکرتکست «DNS چیست و چگونه کار می‌کند؟» ← مقاله DNS چیست و معرفی رکوردهای A، CNAME، MX و TXT]

رفع خطاهای DNS و مشکل باز نشدن سایت پس از تغییر نیم سرور از کجا شروع می‌شود؟

بهترین روش، تغییر چند تنظیم به‌صورت هم‌زمان نیست. ابتدا باید مشخص کنید DNS دامنه در حال حاضر از کدام Name Server پاسخ می‌گیرد و همان مسیر را مرحله‌به‌مرحله بررسی کنید.

ترتیب منطقی عیب‌یابی به شکل زیر است:

1. وضعیت دامنه و Name Serverهای ثبت‌شده را بررسی کنید.
2. Name Server authoritative را مستقیماً Query کنید.
3. رکورد A و در صورت وجود AAAA را کنترل کنید.
4. پاسخ چند Recursive Resolver را با هم مقایسه کنید.
5. DNSSEC را بررسی کنید.
6. اگر DNS صحیح است، سراغ وب‌سرور، SSL، فایروال و تنظیمات Virtual Host بروید.

Cloudflare در راهنمای عیب‌یابی DNS پیشنهاد می‌کند برای جداکردن مشکل Cache از مشکل Zone، ابتدا Name Server authoritative مستقیماً Query شود؛ زیرا این کار کش Resolverهای میانی را دور می‌زند.

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

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

DNS ممکن است کاملاً درست باشد ولی وب‌سرور پاسخ ندهد، پورت 443 بسته باشد، گواهی SSL مشکل داشته باشد یا سایت روی IP جدید در Apache، Nginx، LiteSpeed یا کنترل‌پنل تعریف نشده باشد.

جدول زیر در تشخیص سریع‌تر کمک می‌کند:

CTA دوم: اگر DNS دامنه شما به سرور مجازی، هاست یا زیرساخت اختصاصی متصل است و پس از انتقال سرویس با اختلال مواجه شده‌اید، می‌توانید خدمات هاست، سرور و پشتیبانی زیرساخت شرکت تجارت الکترونیک نوژن را بررسی کنید. قبل از هر مهاجرت، تطبیق DNS Zone با معماری واقعی سرویس اهمیت زیادی دارد.

بررسی Name Server دامنه

اولین سؤال این است: دامنه واقعاً از کدام Name Server استفاده می‌کند؟

ممکن است در کنترل‌پنل هاست رکوردها را تغییر داده باشید، اما دامنه در Registrar هنوز به Name Serverهای شرکت دیگری متصل باشد. در این وضعیت، تغییراتی که در DNS Zone اشتباه انجام می‌دهید هیچ تأثیری روی پاسخ عمومی دامنه ندارند.

Name Serverهای authoritative همان سرورهایی هستند که پاسخ نهایی DNS دامنه را ارائه می‌کنند.

با nslookup چگونه Name Server را ببینیم؟

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

nslookup -type=ns example.com

به‌جای example.com دامنه خودتان را قرار دهید.

خروجی باید Name Serverهایی را نشان دهد که انتظار دارید دامنه روی آن‌ها قرار داشته باشد.

بررسی با dig

در سیستم‌هایی که dig نصب است:

dig NS example.com

برای بررسی مسیر Delegation نیز می‌توانید از:

dig +trace example.com

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

dig +trace برای عیب‌یابی مفید است، زیرا مسیر DNS را از Root تا Name Serverهای دامنه نشان می‌دهد.

رکورد A را بررسی کنید

یکی از متداول‌ترین دلایل باز نشدن سایت بعد از تغییر Name Server، نبودن یا اشتباه بودن A Record است.

A Record باید Host موردنظر را به IPv4 صحیح سرور متصل کند.

مثلاً:

example.com    A    192.0.2.50

آدرس بالا صرفاً نمونه مستنداتی است و نباید در DNS واقعی استفاده شود.

برای مشاهده A Record:

nslookup example.com

یا:

dig A example.com

IP برگشتی را با IP واقعی هاست یا VPS مقایسه کنید.

[لینک داخلی پیشنهادی: انکرتکست «آدرس IP چیست؟» ← مقاله آی پی چیست و چگونه کار می‌کند]

فراموش نکنید www رکورد جداگانه‌ ای است

اینکه example.com باز می‌شود به معنی صحیح بودن www.example.com نیست.

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

www    CNAME    example.com

یا:

www    A    192.0.2.50

انتخاب روش مناسب به زیرساخت شما بستگی دارد.

اگر دامنه بدون www باز می‌شود اما با www باز نمی‌شود، ابتدا همین رکورد را بررسی کنید.

رکورد AAAA می‌تواند مشکل پنهانی ایجاد کند

رکورد AAAA مشابه A Record است، اما برای IPv6 استفاده می‌شود.

گاهی سایت به IPv4 جدید منتقل شده، اما AAAA قدیمی همچنان در DNS باقی مانده است. دستگاه یا شبکه‌ای که IPv6 را ترجیح می‌دهد ممکن است سعی کند از IPv6 اشتباه استفاده کند.

نتیجه می‌تواند عجیب باشد: سایت برای شما باز شود، اما برای کاربر دیگری باز نشود.

برای بررسی:

dig AAAA example.com

اگر IPv6 استفاده نمی‌کنید ولی AAAA در DNS وجود دارد، قبل از حذف آن مطمئن شوید رکورد متعلق به سرویس دیگری نیست. از DNS Zone فعلی نیز نسخه تهیه کنید.

DNS Propagation چیست و چرا سایت برای همه هم‌ زمان درست نمی‌شود؟

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

DNS Resolverها برای کاهش تعداد درخواست‌ها، پاسخ‌ها را Cache می‌کنند. بنابراین حتی اگر رکورد authoritative تغییر کرده باشد، برخی Resolverها ممکن است تا پایان اعتبار داده Cache شده، پاسخ قدیمی را ارائه کنند.

به همین دلیل عبارت «DNS باید منتشر شود» کمی ساده‌شده است. رکورد جدید الزاماً از یک سرور مرکزی به تمام اینترنت Push نمی‌شود؛ Resolverها بر اساس Cache و TTL خود پاسخ جدید را دریافت می‌کنند.

TTL چیست؟

TTL یا Time To Live تعیین می‌کند یک DNS Record تا چه مدت می‌تواند Cache شود.

اگر قبل از مهاجرت TTL بالا بوده باشد، کاهش آن بعد از تغییر DNS باعث نمی‌شود Cache قبلی فوراً ناپدید شود.

این نکته هنگام برنامه‌ریزی مهاجرت اهمیت دارد.

چگونه بفهمیم مشکل از Cache است یا DNS جدید؟

بهترین راه این است که Authoritative Name Server را مستقیم Query کنید.

فرض کنید Name Server شما:

ns1.example-dns.com

باشد.

می‌توانید اجرا کنید:

dig @ns1.example-dns.com example.com A

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

Cloudflare نیز برای تشخیص این شرایط، Query مستقیم Authoritative Name Server را توصیه می‌کند.

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

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

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

Command Prompt را باز کنید و اجرا کنید:

ipconfig /flushdns

پیام موفقیت باید نمایش داده شود.

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

نکته مهم

پاک‌کردن DNS Cache ویندوز فقط Cache همان سیستم را پاک می‌کند. این دستور Cache شرکت اینترنت، DNS Resolver یا کاربران دیگر را تغییر نمی‌دهد.

با DNS Resolver دیگری تست کنید

گاهی برای تشخیص مشکل می‌توانید پاسخ دامنه را از چند Resolver مقایسه کنید.

مثلاً:

nslookup example.com 1.1.1.1

و:

nslookup example.com 8.8.8.8

اگر پاسخ Resolverها متفاوت باشد، باید پاسخ authoritative را نیز بررسی کنید تا مشخص شود کدام IP صحیح است.

در عیب‌یابی DNS، پاسخ authoritative مرجع مهم‌تری نسبت به Resolver Cache شده است.

خطای NXDOMAIN چیست؟

NXDOMAIN یعنی Resolver نتیجه گرفته نام درخواست‌شده وجود ندارد.

این خطا می‌تواند در شرایط مختلف دیده شود؛ برای مثال:

• رکورد موردنظر واقعاً وجود ندارد.
• DNS Zone به‌درستی ایجاد نشده است.
• Name Server اشتباه است.
• دامنه یا زیردامنه موردنظر در Zone تعریف نشده است.
• Resolver هنوز پاسخ منفی قبلی را Cache کرده است.

DNS حتی می‌تواند پاسخ‌های منفی را Cache کند. استاندارد Negative Caching این رفتار را تعریف کرده است.

به همین دلیل ممکن است رکوردی را ایجاد کنید ولی Resolverی که قبلاً NXDOMAIN دریافت کرده است، تا مدتی همان پاسخ منفی را نگه دارد.

خطای SERVFAIL چه معنایی دارد؟

SERVFAIL با NXDOMAIN متفاوت است.

در NXDOMAIN پاسخ مشخص می‌کند نام وجود ندارد، اما SERVFAIL معمولاً به این معنی است که Resolver نتوانسته یک پاسخ معتبر و قابل‌استفاده برای Query به دست آورد.

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

• Name Serverها قابل‌دسترسی هستند؟
• DNS Zone معتبر است؟
• Delegation صحیح است؟
• DNSSEC درست پیکربندی شده؟
• سرور authoritative پاسخ می‌دهد؟
• هر دو Name Server داده سازگار دارند؟

صرفاً چند بار تغییر دادن رکورد A معمولاً راه‌حل مناسبی برای SERVFAIL نیست.

DNSSEC بعد از تغییر Name Server می‌تواند سایت را از دسترس خارج کند

این مورد برای مدیران سایت مهم است.

اگر دامنه قبلاً DNSSEC داشته باشد و Name Server را عوض کنید، ممکن است اطلاعات DNSSEC موجود در Registrar با DNS Provider جدید هماهنگ نباشد.

Resolverهای DNSSEC-validating در صورت عدم اعتبارسنجی صحیح ممکن است پاسخ را معتبر ندانند. استانداردهای DNS نیز کش‌کردن برخی خطاهای validation و resolution را تعریف می‌کنند.

اگر دقیقاً بعد از تغییر Name Server خطای SERVFAIL مشاهده می‌کنید، DNSSEC یکی از مواردی است که باید بررسی شود.

هشدار: بدون شناخت ساختار DNSSEC، DS Record یا تنظیمات امضای Zone را به‌صورت آزمون و خطا تغییر ندهید. ابتدا از وضعیت فعلی مستند تهیه کنید و راهنمای رسمی Registrar و DNS Provider خود را بررسی کنید.

Custom Name Server و Glue Record را فراموش نکنید

گاهی Name Server دامنه به شکل زیر است:

ns1.example.com
ns2.example.com

و خود example.com نیز همان دامنه‌ای است که این Name Serverها قرار است مدیریت کنند.

در چنین ساختاری ممکن است نیاز به Glue Record در Registrar وجود داشته باشد تا Resolver بتواند IP Name Server را بدون ایجاد وابستگی دوری پیدا کند.

اگر از Private Name Server یا Child Name Server استفاده می‌کنید، بررسی Glue Record یکی از مراحل ضروری عیب‌یابی است.

[لینک داخلی پیشنهادی: انکرتکست «آموزش ساخت سرور مجازی» ← مقاله آموزش ساخت سرور مجازی]

DNS درست است اما سایت باز نمی‌شود؛ حالا چه کنیم؟

اگر Queryهای DNS IP درست را برمی‌گردانند، مشکل احتمالاً در لایه بعدی است.

در این مرحله موارد زیر را بررسی کنید.

۱. وب‌سرور روی IP جدید فعال است؟

IP جدید را در مرورگر وارد کردن همیشه تست کاملی نیست، زیرا بسیاری از وب‌سایت‌ها با Virtual Host و Host Header کار می‌کنند.

بهتر است وضعیت Nginx، Apache یا LiteSpeed و تنظیم دامنه روی سرور بررسی شود.

۲. دامنه روی هاست اضافه شده است؟

در کنترل‌پنل‌هایی مانند Plesk، cPanel یا DirectAdmin باید دامنه روی Account یا Subscription صحیح تعریف شده باشد.

صرف تغییر A Record باعث ایجاد خودکار سایت روی وب‌سرور نمی‌شود.

۳. پورت‌های 80 و 443 در دسترس هستند؟

اگر فایروال یا Security Group دسترسی را بسته باشد، DNS صحیح هم مشکل را حل نمی‌کند.

۴. SSL مشکل ندارد؟

گاهی HTTP باز می‌شود اما HTTPS خطا می‌دهد. در این حالت موضوع ممکن است صدور گواهی، SNI یا تنظیمات Virtual Host باشد نه DNS.

۵. CDN یا Reverse Proxy دارید؟

اگر CDN استفاده می‌کنید، IP مشاهده‌شده ممکن است IP CDN باشد و نه IP Origin Server.

در این ساختار باید DNS، CDN و Origin را جداگانه بررسی کنید.

[لینک داخلی پیشنهادی: انکرتکست «خرید سرور مجازی» ← صفحه خدمات سرور مجازی]

سناریوی واقعی عیب‌ یابی

فرض کنید یک سایت از هاست قدیمی به VPS جدید منتقل شده است.

IP قدیمی:

192.0.2.20

IP جدید:

192.0.2.80

مالک سایت Name Server را عوض کرده اما سایت برای برخی کاربران باز می‌شود و برای برخی دیگر خیر.

مرحله اول

NS دامنه را بررسی می‌کنیم:

dig NS example.com

Name Server جدید نمایش داده می‌شود.

مرحله دوم

Authoritative Server را مستقیماً بررسی می‌کنیم:

dig @ns1.newdns.example example.com A

پاسخ:

192.0.2.80

در نتیجه رکورد روی DNS جدید صحیح است.

مرحله سوم

Resolver محلی:

nslookup example.com

هنوز:

192.0.2.20