چرا تغییرات DNS اعمال نمی شود؟ تشخیص کش و هاست قدیمی

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

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

قبل از تغییر دوباره، این چهار مورد را یادداشت کنید

نام دقیق دامنه یا زیردامنه، نوع رکورد، مقدار قبلی و مقدار مورد انتظار را کنار هم بگذارید. «DNS سایت تغییر کرده» برای پیگیری کافی نیست؛ تغییر A برای example.com با تغییر CNAME مربوط به www.example.com یا عوض کردن nameserver دامنه یک کار واحد نیست. زمان آخرین تغییر و TTL قبلی را هم بنویسید. اگر چند نفر به پنل دسترسی دارند، مشخص کنید آخرین ویرایش را چه کسی انجام داده است.

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

کدام پنل واقعا DNS دامنه را کنترل می کند؟

ثبت کننده دامنه، هاست و ارائه دهنده DNS ممکن است سه مجموعه متفاوت باشند. در تنظیمات ثبت دامنه، nameserverهای واگذار شده مشخص می شوند؛ در زون آن ارائه دهنده، رکوردهایی مانند A و MX قرار می گیرند. ویرایش رکورد در cPanel قدیمی اثری بر اینترنت ندارد اگر دامنه به nameserverهای سرویس دیگری واگذار شده باشد. راهنمای تنظیم nameserver در Cloudflare نیز تغییر واگذاری در ثبت کننده را از تنظیم رکوردهای زون جدا می کند.

در ویندوز، فرمان زیر nameserverهای گزارش شده توسط یک resolver عمومی را نشان می دهد. example.com فقط دامنه نمونه است و باید با دامنه خودتان عوض شود. اگر dig نصب دارید، فرمان دوم مسیر واگذاری از بالای درخت DNS را نشان می دهد؛ خروجی آن طولانی تر است و برای تشخیص اختلاف با اطلاعات پنل ثبت کننده کاربرد دارد.

nslookup -type=NS example.com 1.1.1.1
dig example.com NS +trace

خروجی nslookup هم می تواند کش شده باشد. برای همین، هنگام تعویض nameserver، نتیجه یک پرس و جو را سند نهایی نگیرید. نام های ثبت شده در پنل دامنه و واگذاری دیده شده در مسیر trace باید با برنامه انتقال سازگار باشند. ایجاد رکورد NS در جدول زون، جای تغییر واگذاری دامنه در ثبت کننده را نمی گیرد. برای بررسی حساب و تنظیم دامنه می توانید از بخش خدمات دامنه آفاق هاست شروع کنید.

پاسخ مرجع را با پاسخ کش مقایسه کنید

حالا مستقیما از nameserver فعال سوال کنید. در مثال زیر، ns1.example.net را با یکی از nameserverهای واقعی همان دامنه جایگزین کنید. دو فرمان آخر، پاسخ resolverهای عمومی را نشان می دهند. این فرمان ها فقط اطلاعات می خوانند و تنظیمی را تغییر نمی دهند.

dig @ns1.example.net example.com A +noall +answer
dig @ns1.example.net example.com AAAA +noall +answer
dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer

کنار نام، عدد TTL، نوع رکورد و مقدار آن را می بینید. آزمایش مستقیم را برای همه nameserverهای واگذار شده تکرار کنید. اگر یکی مقصد تازه و دیگری مقصد قدیمی را برمی گرداند، اول هماهنگی زون ها را پیگیری کنید؛ این اختلاف را نباید صرفا گردن کش کاربر انداخت. راهنمای عیب یابی DNS در Cloudflare نیز پرسش مستقیم از authoritative را برای جدا کردن مشکل رکورد از کش پیشنهاد می کند.

چیزی که می بینید	احتمال اصلی	اقدام بعدی
همه authoritativeها IP قدیمی دارند	زون اشتباه ویرایش شده یا تغییر ذخیره نشده است	پنل فعال و نام کامل رکورد را بررسی کنید
authoritative درست است، یک resolver قدیمی است	کش پاسخ قبلی	TTL باقی مانده و زمان پرسش را ثبت کنید
nameserverها پاسخ متفاوت دارند	ناهماهنگی زون یا انتقال ناقص	خروجی هر مرجع را به ارائه دهنده DNS بدهید
A درست است ولی AAAA مقصد قبلی را دارد	مسیر IPv6 هنوز به میزبان قدیم می رسد	مقصد واقعی IPv6 را با میزبان تطبیق دهید
همه پاسخ ها درست اند، صفحه قدیمی است	کش وب، CDN یا تنظیم سایت	مقصد اتصال و لایه وب را بررسی کنید

TTL دقیقا چه چیزی را مشخص می کند؟

TTL مدت مجاز نگهداری پاسخ DNS در کش است و معمولا با ثانیه بیان می شود. TTL برابر ۳۶۰۰ یعنی یک ساعت؛ اما پایین آوردن آن بعد از تغییر، پاسخ هایی را که پیش تر با TTL بزرگ تر گرفته شده اند از کش همه resolverها پاک نمی کند. اگر برای انتقال برنامه دارید، TTL را از قبل کاهش دهید و به اندازه TTL قبلی فرصت بدهید تا پاسخ های قدیمی عادی منقضی شوند. توضیح رسمی TTL رکورد و nameserver نشان می دهد که این دو زمان هم لزوما یک تنظیم مشترک نیستند.

بنابراین جمله «همیشه ۲۴ تا ۴۸ ساعت صبر کنید» تشخیص فنی کاملی نیست. رکورد اشتباه با گذشت دو روز درست نمی شود؛ از طرف دیگر، یک TTL کوچک هم وعده تغییر فوری همه دستگاه ها نیست. زمان کش محلی، کش resolver و تغییر واگذاری را جدا ببینید. چند بار عوض کردن IP یا جابه جا کردن nameserver در حین بررسی، ردگیری اینکه هر پاسخ به کدام تغییر مربوط است را سخت تر می کند.

اگر زیردامنه تازه ساخته شده، کش منفی هم مطرح است

ممکن است کسی قبل از ساخت shop.example.com آن را باز کرده و پاسخ «وجود ندارد» گرفته باشد. resolver می تواند همان پاسخ منفی را مدتی نگه دارد. این زمان از TTL رکورد تازه ساخته شده تعیین نمی شود. طبق RFC 2308 درباره کش منفی، TTL پاسخ منفی با اطلاعات SOA ارتباط دارد و از کمینه TTL خود رکورد SOA و مقدار SOA.MINIMUM محاسبه می شود. پس ساخت رکورد با TTL شصت ثانیه، کش منفی قبلی را فورا حذف نمی کند.

dig @1.1.1.1 shop.example.com A +noall +answer +authority
dig @ns1.example.net shop.example.com A +noall +answer +authority

اگر پاسخ مرجع مثبت و پاسخ resolver منفی است، همین دو خروجی همراه زمان، شواهد بهتری از چند تصویر پراکنده ابزارهای آنلاین هستند. در پاسخ منفی، بخش authority و SOA را نیز نگه دارید. نبودن پاسخ A با خطای SERVFAIL یک معنی ندارد.

دامنه اصلی، www و IPv6 را جداگانه ببینید

رکورد A مقصد IPv4 و رکورد AAAA مقصد IPv6 را معرفی می کند. CNAME هم نام دیگری را مقصد می گیرد. ممکن است A دامنه اصلی به هاست تازه منتقل شده باشد، اما AAAA همچنان به سرور قبلی برسد یا www زنجیره متفاوتی داشته باشد. مرجع انواع رکورد DNS تفاوت این مقصدها را توضیح می دهد. به جای حذف کورکورانه IPv6، آدرس معتبر سرویس تازه و پشتیبانی میزبان از آن را مشخص کنید.

مثلا در یک سناریوی فرضی، روی اینترنت موبایل صفحه تازه باز می شود اما روی شبکه دفتر نسخه قدیمی دیده می شود. پاسخ A هر دو شبکه تازه است؛ بررسی AAAA نشان می دهد مسیر IPv6 هنوز قدیمی است. اصلاح فقط A در این سناریو کافی نبوده است. معیار پایان کار، پاسخ سازگار برای تمام نام ها و نوع رکوردهای مورد استفاده سایت است، نه موفق بودن یک فرمان.

وقتی DNS درست است ولی سایت هنوز قدیمی دیده می شود

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

در زمان تعویض nameserver، اگر پاسخ SERVFAIL شده است، وضعیت DNSSEC و DS ثبت شده در ثبت کننده اهمیت دارد. راهنمای DNSSEC در Cloudflare ناسازگاری این اطلاعات با ارائه دهنده تازه را از علت های قابل بررسی می داند. تنظیمات امنیتی را چند بار تصادفی خاموش و روشن نکنید؛ خروجی خطا، nameserverها و سابقه انتقال را برای مسئول DNS بفرستید.

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

پرسش هایی که بعد از تغییر DNS پیش می آید

چرا پاک کردن کش مرورگر کمکی نکرد؟

کش محتوای مرورگر با کش DNS resolver یک لایه نیست. ابتدا پاسخ DNS را مقایسه کنید. اگر مقصد درست است، سراغ کش وب بروید؛ اگر مقصد قدیمی است، پاک کردن عکس و فایل های مرورگر پاسخ DNS را اصلاح نمی کند.

آیا کم کردن TTL همین الان انتقال را تمام می کند؟

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

چه زمانی باید به پشتیبانی درخواست بررسی بدهم؟

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