رکورد A را عوض کرده‌اید، Nameserverها را هم به سرور جدید اشاره داده‌اید، ولی وقتی آدرس سایت را در مرورگر می‌زنید همان صفحه قدیمی بالا می‌آید. یا بدتر: برای شما سایت جدید باز میشود و مشتری‌تان هنوز نسخه قدیمی را می‌بیند. اینجا لحظهای است که اکثر آدم‌ها می‌گویند «باید ۲۴ تا ۴۸ ساعت صبر کنیم». آن عدد تقریباً همیشه غلط است، و صبر کردن به‌جای عیب‌یابی، فقط وقت تلف کردن است.
انتشار DNS یک رویداد لحظهای است، نه یک بازه زمانی. لحظهای که رکورد در سرور معتبر شما ثبت میشود، انتشار تمام شده. آنچه طول می‌کشد، منقضی شدن نسخه‌های کش‌شده در ریزالورها و ماشین‌های واسط است. پس سؤال درست این نیست که «چقدر طول می‌کشد»، بلکه این است که «چه چیزی هنوز نسخه قدیمی را نگه داشته».
چرا «۲۴ تا ۴۸ ساعت» تقریباً همیشه غلط است
آن عدد از دوره‌ای می‌آید که TTL پیش‌فرض رکوردها ۸۶۴۰۰ ثانیه بود، یعنی دقیقاً یک روز، و بعضی ارائه‌دهنده‌ها دو برابر آن را توصیه می‌کردند تا مطمئن شوند همه کش‌ها منقضی شده‌اند. امروز TTL پیش‌فرض در اکثر پنل‌ها بین ۳۰۰ تا ۳۶۰۰ ثانیه است. یعنی بدترین حالت تئوریک، یک ساعت. در عمل هم چیزی که می‌بینید معمولاً بین ۵ تا ۳۰ دقیقه حل میشود.
عدد ۴۸ ساعت یک حاشیه امنیت بود، نه یک واقعیت فنی. اگر امروز کسی این را به شما می‌گوید، دارد از پاسخ دادن به سؤال واقعی شما فرار میکند.
TTL دقیقاً چه چیزی را کنترل میکند
TTL به ریزالور می‌گوید این پاسخ را چند ثانیه می‌تواند در حافظه نگه دارد. نکته‌ای که خیلی‌ها نمی‌دانند: TTL فقط از لحظهای که ریزالور آن رکورد را کش کرده اعمال میشود، نه از لحظهای که شما تغییرش میدهید. اگر ریزالور ۵ دقیقه پیش رکورد شما را با TTL ۳۶۰۰ کش کرده باشد، تا ۵۵ دقیقه دیگر هم نسخه قدیمی را سرو میکند، حتی اگر شما همین حالا TTL را به ۶۰ ثانیه کاهش داده باشید.
پس کاهش TTL بعد از تغییر، بی‌فایده است. باید قبل از تغییر انجام شود.
روش درست: TTL را قبل از انتقال پایین بیاورید
اگر می‌دانید فردا ظهر می‌خواهید سرور را عوض کنید، امروز TTL رکوردهای A و AAAA و CNAME را به ۳۰۰ ثانیه کاهش دهید. یک روز صبر کنید تا کش‌های قبلی با TTL قدیمی منقضی شوند. بعد تغییر را انجام دهید. حالا پنجره انتشار شما حدود پنج دقیقه است، نه یک روز.
ترتیب کار به این شکل است:
- ۲۴ ساعت قبل: TTL را روی ۳۰۰ بگذارید و منتظر بمانید تا کش قدیمی منقضی شود.
- رکورد A را به IP سرور جدید تغییر دهید.
- با
digاز چند نقطه مختلف بررسی کنید که پاسخ جدید برگردد. - بعد از تثبیت، TTL را به مقدار عادی برگردانید.
برای بررسی، از ریزالور معتبر بپرسید نه از کش محلی:
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8
dig +trace example.comاگر پاسخ 1.1.1.1 و 8.8.8.8 یکی است و IP جدید را نشان میدهد، انتشار در سطح عمومی تمام شده. اگر یکی از آن‌ها هنوز IP قدیمی را برمی‌گرداند، آن ریزالور هنوز کش دارد و باید TTL باقی‌مانده‌اش تمام شود.
چرا بعضی کاربران هنوز سایت قدیمی را می‌بینند
سه لایه کش وجود دارد و اکثر عیب‌یابی‌ها فقط لایه اول را می‌بینند:
- کش ریزالور ISP: بعضی ISPهای داخلی TTL را نادیده می‌گیرند و ساعت‌ها پاسخ قدیمی را نگه می‌دارند. این خارج از کنترل شماست.
- کش سیستم‌عامل: روی ویندوز با
ipconfig /flushdnsو روی لینوکس باsystemd-resolve --flush-cachesپاک میشود. - کش مرورگر: مستقل از DNS است و با تغییر رکورد پاک نمی‌شود.
اینجا اشتباه می‌کنند: کاربر IP جدید را در dig می‌بیند، نتیجه می‌گیرد DNS درست شده، و بعد شکایت مشتری را نادیده می‌گیرد. در حالی که مشتری پشت یک ISP با ریزالور سرسخت است. راه‌حل عملی این است که مدتی هر دو سرور را بالا نگه دارید تا ترافیک از هر دو مسیر بیاید.
انتقال بدون قطعی: نکته‌ای که کمتر گفته میشود
اگر سایت فروشگاهی دارید، پنجره انتشار DNS فقط یک مسئله فنی نیست. کاربری که وسط تسویه حساب است و ناگهان به سرور دیگری می‌رود، سبد خریدش را از دست میدهد. راه‌حل این است که دیتابیس را قبل از تغییر رکورد روی سرور جدید آماده کنید و بعد از تغییر، هر دو سرور را مدتی همگام نگه دارید. برای این کار انتقال وردپرس بدون افزونه مسیر امن‌تری است تا اینکه وسط کار به افزونه‌های مهاجرت تکیه کنید.
هزینه‌ای که این روش دارد: باید چند ساعت دو سرور را همزمان بپردازید و همگام‌سازی دستی انجام دهید. اگر سایت شخصی یا وبلاگ کوچک است، این کار اضافه است و می‌توانید ریسک را بپذیرید. برای فروشگاه، نه.
رکوردهای CNAME و MX رفتار متفاوتی دارند
رکورد A سریع منتشر میشود چون فقط یک IP است. CNAME زنجیره‌ای است و هر حلقه TTL خودش را دارد؛ اگر CNAME شما به یک دامنه دیگر اشاره کند که آن هم CNAME دارد، مجموع تأخیر بیشتر میشود. رکورد MX برای ایمیل معمولاً TTL بالاتری دارد و تغییرش می‌تواند تا چند ساعت ایمیل‌ها را به سرور قدیمی بفرستد. اگر همزمان با انتقال سایت، ایمیل هم جابه‌جا میکنید، این دو را جدا و با فاصله انجام دهید.
مقایسه گزینه‌ها: کاهش TTL یا صبر کردن
| رویکرد | پنجره انتشار | هزینه | مناسب برای |
|---|---|---|---|
| کاهش TTL از قبل | حدود ۵ دقیقه | بار کمی بیشتر روی ریزالورها | سایت‌های فعال و فروشگاهی |
| تغییر با TTL پیش‌فرض | ۳۰ تا ۶۰ دقیقه | ریسک دیدن نسخه قدیمی | سایت‌های کم‌ترافیک |
| صبر ۲۴ تا ۴۸ ساعت | همان بازه، بدون دلیل | از دست دادن زمان | هیچ‌کس |
انتخاب من روش اول است. تنها شرطی که روش دوم را قابل قبول میکند این است که سایت شما ترافیک ناچیزی داشته باشد و قطعی کوتاه برایتان بی‌اهمیت باشد.
ابزارهایی که کار را سریع‌تر می‌کنند
برای بررسی انتشار از چند نقطه جغرافیایی، از سرویس‌های DNS propagation checker استفاده کنید، ولی حواستان باشد این ابزارها هم فقط از ریزالورهای خودشان می‌پرسند، نه از همه دنیا. اگر می‌خواهید مطمئن شوید سرور جدید واقعاً پاسخ درست میدهد، قبل از تغییر رکورد با curl و هدر Host تست کنید:
curl -I -H "Host: example.com" http://192.0.2.10/اگر پاسخ ۲۰۰ برگشت، سرور جدید آماده است و می‌توانید با خیال راحت رکورد را عوض کنید. این یک قدم کوچک، نصف دردسرهای بعد از انتقال را حذف میکند.
اگر روی وردپرس کار میکنید، بعد از انتقال حتماً کش آبجکت و کش صفحه را پاک کنید، وگرنه ممکن است DNS درست باشد ولی سایت همچنان نسخه کش‌شده را نشان دهد. برای بررسی سریع وضعیت از ترمینال، دستورهای ضروری WP-CLI چند دستور آماده برای پاک کردن کش و بررسی وضعیت دیتابیس دارد.
پرسش‌های پرتکرار
انتشار DNS واقعاً چقدر طول می‌کشد؟
در عمل بین ۵ تا ۶۰ دقیقه، بسته به TTL رکورد و رفتار ریزالور ISP. اگر TTL را از قبل به ۳۰۰ ثانیه کاهش داده باشید، معمولاً زیر ۱۰ دقیقه تمام میشود. عدد ۲۴ تا ۴۸ ساعت مربوط به دوره‌ای است که TTL پیش‌فرض یک روز بود.
چرا سایت جدید را می‌بینم ولی مشتری سایت قدیمی را می‌بیند؟
چون کش DNS در سمت کاربر یا ISP او هنوز منقضی نشده. این وضعیت تا پایان TTL باقی‌مانده ادامه دارد و از سمت شما قابل تسریع نیست. تنها راه عملی، بالا نگه داشتن سرور قدیمی در این بازه است تا کاربران قدیمی هم پاسخ درست بگیرند.
آیا کاهش TTL بعد از تغییر رکورد فایده دارد؟
نه. TTL از لحظهای که ریزالور رکورد را کش کرده اعمال میشود، نه از لحظه تغییر شما. اگر ریزالور نسخه قدیمی را با TTL ۳۶۰۰ کش کرده باشد، کاهش TTL به ۶۰ ثانیه هیچ تأثیری روی آن کش ندارد. کاهش TTL باید حداقل یک روز قبل از تغییر انجام شود.
چطور بفهمم انتشار DNS تمام شده است؟
با پرسیدن مستقیم از چند ریزالور عمومی. اگر dig +short A example.com @1.1.1.1 و همان دستور با @8.8.8.8 هر دو IP جدید را برگرداندند، انتشار در سطح عمومی تمام شده. برای اطمینان بیشتر، سرور جدید را با curl -I -H "Host: example.com" تست کنید تا مطمئن شوید پاسخ HTTP درست میدهد.
خلاصهاش این است: TTL را قبل از انتقال پایین بیاورید، سرور جدید را قبل از تغییر رکورد تست کنید، و بعد از تغییر هر دو سرور را مدتی بالا نگه دارید. اگر روی زیرساختی کار میکنید که این جابهجاییها را مکرر انجام میدهید، هاست لینوکس با کنترل کامل روی DNS و TTL، این چرخه را قابل پیشبینیتر میکند.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!