چرا پاسخ DNS عمومی با نیم‌سرور دامنه فرق دارد؟ راهنمای پیدا کردن محل خطا

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

در این راهنما از یک مثال ساده استفاده می‌کنیم و نتیجه هر آزمایش را تفسیر می‌کنیم. این آزمایش‌ها رکوردی را تغییر نمی‌دهند. نام‌های example.com و ns1.example.net ساختگی‌اند؛ آن‌ها را با دامنه و نیم‌سرور واقعی خودتان جایگزین کنید.

نام کامل رکورد، نوع آن و مقدار مورد انتظار را یادداشت کنید. برای مثال ممکن است بخواهید رکورد A دامنه اصلی به نشانی جدید سایت اشاره کند، اما www یک نام مستعار CNAME باشد. پرسیدن رکورد A دامنه اصلی و مقایسه آن با رکورد MX ایمیل، مقایسه درستی نیست؛ ابتدا باید نام و نوع هر دو پرس‌وجو یکسان باشند.

زمان تغییر و TTL قبلی را نیز اگر دارید ثبت کنید. TTL مدت مجاز نگه داشتن پاسخ است، اما کاهش آن پس از تغییر، نسخه‌هایی را که قبلاً با TTL طولانی ذخیره شده‌اند فوراً پاک نمی‌کند. آموزش تفاوت نیم‌سرور و انتشار DNS مفهوم پایه را توضیح می‌دهد؛ اینجا تمرکز ما بر مقایسه مستقیم پاسخ‌هاست.

اگر از CDN یا سامانه توزیع ترافیک استفاده می‌کنید، ممکن است پاسخ‌های متفاوت برای مناطق یا زمان‌های مختلف عمدی باشند. به‌ویژه هنگام فعال بودن پراکسی، IP عمومی می‌تواند متعلق به CDN باشد، نه IP هاست اصلی. قبل از اینکه تفاوت آدرس‌ها را خطا بدانید، رفتار مورد انتظار همان سرویس را بشناسید.

در پنل ثبت‌کننده دامنه، بخش Nameservers یا مدیریت نیم‌سرورها را باز کنید و نام نیم‌سرورهای ثبت‌شده را بنویسید. برای بسیاری از دامنه‌های عمومی، ابزار اطلاعات ثبت دامنه نیز می‌تواند نشانی‌های منتشرشده را نشان دهد. پنل نگهداری رکورد و پنل ثبت‌کننده ممکن است دو جای جدا باشند.

در PowerShell ویندوز می‌توانید پاسخ یک DNS عمومی درباره NS را هم ببینید:

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

همه نیم‌سرورهای واگذارشده را یادداشت کنید، نه فقط اولی را. در دامنه‌ای با DNSSEC، ناهماهنگی DS و کلیدهای ناحیه جدید می‌تواند باعث شکست اعتبارسنجی شود؛ برای تغییر امن، راهنمای جابه‌جایی نیم‌سرور با DNSSEC را ببینید. حذف عجولانه DS یا خاموش کردن بررسی امنیتی، راه‌حل عمومی نیست.

فرض کنید نیم‌سرورهای واقعی شما ns1.example.net و ns2.example.net هستند. در PowerShell، نام دامنه و هر دو نیم‌سرور نمونه را با مقادیر واقعی جایگزین کنید:

این پرس‌وجوها از هر سرور نام‌برده درباره همان رکورد می‌پرسند و درخواست recursion نمی‌دهند. خروجی را همراه با زمان نگه دارید. نام نیم‌سرور باید ابتدا برای دستگاه شما به IP قابل دسترسی تبدیل شود؛ اگر این مرحله مشکل دارد، مدیر DNS می‌تواند IP معتبر همان نیم‌سرور را برای آزمون مستقیم اعلام کند. زمان‌انتظار ممکن است ناشی از مسیر شبکه یا مسدود بودن پرس‌وجوی DNS باشد، نه الزاماً نبود رکورد.

گزینه NoRecursion به‌تنهایی ثابت نمی‌کند پاسخی که می‌بینید authoritative است. اگر به لینوکس و ابزار dig دسترسی دارید، این دستور با جایگزینی نام واقعی، پاسخ کامل و پرچم‌های آن را نشان می‌دهد:

در خروجی، status و بخش ANSWER را بخوانید. پرچم aa در پاسخ، نشانه authoritative بودن آن پاسخ از دید سرور پاسخ‌دهنده است. برای نیم‌سرور دوم هم دستور را با نام واقعی آن تکرار کنید. در صورت وجود CNAME یا واگذاری زیردامنه به ناحیه دیگر، پاسخ و مرجع آن مرحله ممکن است متفاوت باشد؛ فقط IP نهایی را بدون دیدن زنجیره مقایسه نکنید.

در همان رایانه ویندوزی، نام نمونه را با نام واقعی عوض کنید:

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

اگر همه نیم‌سرورهای معتبر پاسخ جدید می‌دهند ولی یک resolver برای مدتی پاسخ قدیمی می‌دهد، کش یکی از علت‌های محتمل است. مطابق TTL قبلی و زمان ثبت‌شده دوباره آزمایش کنید. پاک کردن کش سیستم خودتان فقط بر همان سیستم اثر می‌گذارد؛ لزوماً کش اینترنت یا سرویس ارائه‌دهنده کاربر را پاک نمی‌کند.

| چیزی که می‌بینید | معنی احتمالی و اقدام | | --- | --- | | هر دو نیم‌سرور معتبر پاسخ قدیمی دارند | احتمالاً رکورد در ناحیه فعال تغییر نکرده یا در پنل دیگری ویرایش شده است. نام نیم‌سرور و حساب ارائه‌دهنده DNS را تطبیق دهید و رکورد درست را همان‌جا اصلاح کنید. | | یک نیم‌سرور پاسخ جدید و دیگری قدیمی می‌دهد | اگر سرویس شما باید پاسخ یکسان بدهد، ممکن است همگام‌سازی یا تنظیم یکی از سرورها مشکل داشته باشد. هر دو خروجی و زمان را برای مدیر DNS بفرستید و وضعیت انتشار Zone را بررسی کنید. | | نیم‌سرورها پاسخ درست می‌دهند ولی یک resolver قدیمی است | کش قبلی می‌تواند علت باشد. TTL و زمان تغییر را ثبت و پس از گذشت بازه مناسب دوباره تست کنید؛ اگر اختلاف ادامه دارد، مسیر واگذاری و زنجیره CNAME را هم بررسی کنید. | | نیم‌سرور رکورد را می‌دهد ولی resolver خطای SERVFAIL دارد | صرف تفاوت کافی نیست. ممکن است اعتبارسنجی DNSSEC، دسترسی به یکی از نیم‌سرورها یا مشکل دیگری در مسیر دخیل باشد. خطای کامل را به مدیر DNS بدهید و DS و کلید را مطابق راهنمای سرویس بررسی کنید. | | resolver پاسخ نبود رکورد می‌دهد ولی در پنل رکورد را ساخته‌اید | مطمئن شوید نام کامل، نوع رکورد و Zone فعال درست است؛ پاسخ منفی قبلی هم ممکن است مدتی کش شده باشد. |

برای پاسخ منفی، زمان نگهداری به قواعد پاسخ منفی و تنظیمات ناحیه وابسته است و همیشه با TTL رکوردی که تازه ساخته‌اید برابر نیست. راهنمای مشکلات DNS در Cloudflare نمونه بررسی کش پاسخ منفی و نیم‌سرور authoritative را نشان می‌دهد. اگر نام روی DNS دیگری میزبانی می‌شود، همان مفهوم را با پنل و مستندات سرویس خود دنبال کنید.

اول از رکوردهای فعلی و تنظیمات نیم‌سرورها نسخه یا خروجی قابل بازگشت نگه دارید. اگر هر دو نیم‌سرور بخشی از یک سرویس مدیریت‌شده‌اند، از پنل همان سرویس وضعیت Zone و پیام‌های خطا را ببینید. در تنظیمات سرور اختصاصی، انتقال و نسخه Zone و مجاز بودن پاسخ هر سرور باید توسط مدیر DNS بررسی شود. بدون شناخت معماری، رکوردهای ایمیل، DS یا همه نیم‌سرورها را حذف نکنید.

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

دوباره همان نوع رکورد را از همه نیم‌سرورهای واگذارشده و سپس از resolverهای مورد آزمایش بخواهید. نام‌های اصلی، www و رکوردهای ایمیل را فقط اگر در تغییر شما درگیر بوده‌اند جداگانه کنترل کنید؛ اصلاح A سایت نباید ناخواسته MX را تغییر دهد. برای سایت، باز شدن صفحه با HTTPS و گواهی درست را نیز آزمایش کنید؛ پاسخ درست DNS به‌تنهایی سلامت خود وب‌سایت را ثابت نمی‌کند.

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