پروپاگیشن DNS چیست و چقدر طول می‌کشد؟

یکی از پرتکرارترین سوال‌هایی که در پروژه‌های مهاجرت می‌شنوم این است: «چرا بعد از تغییر DNS، نیمی از کاربران سایت قدیمی را می‌بینند و نیمی دیگر سایت جدید را؟» و پاسخ همیشه یکسان است: چون پروپاگیشن DNS یک پدیده‌ی توزیع‌شده است، نه یک عملیات متمرکز. اولین باری که خودم این پدیده را با تمام جزئیاتش دیدم، در یک مهاجرت سرور بود: بعد از تغییر رکورد A، حدود ۲۰ دقیقه بعد، بخشی از کاربران به سرور جدید می‌رسیدند و بخشی دیگر همچنان به سرور قدیمی. دو ساعت بعد، تنها درصد کمی از کاربران همچنان به سرور قدیمی می‌رسیدند. آن تجربه باعث شد سال‌ها بعد، پیش از هر تغییر DNS، یک استراتژی مشخص برای مدیریت این بازه داشته باشم. این مقاله، همان استراتژی و مکانیزم پشت آن است.

پیش از ادامه، اگر با مفاهیم پایه‌ی DNS آشنا نیستید، DNS چیست و چگونه کار می‌کند را بخوانید و برای شناخت رکوردها، رکوردهای DNS کدامند راهنمای دقیقی است.

پروپاگیشن DNS دقیقاً چیست؟

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

پس آنچه به‌عنوان «پروپاگیشن» می‌شناسیم، در حقیقت نتیجه‌ی دو عامل است: میزان TTL رکورد و رفتار کش هر Resolver. برخی Resolverها به TTL احترام می‌گذارند، برخی دیگر نه؛ برخی سرویس‌های ISP، به دلایل عملکرد، TTL را بیشتر یا کمتر اعمال می‌کنند. به همین دلیل، تغییر یک رکورد با TTL ۳۶۰۰ ثانیه ممکن است روی برخی کاربران در ۱۰ دقیقه اعمال شود و روی برخی دیگر در ۲ ساعت.

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

مکانیزم کش در DNS و نقش TTL

برای درک پروپاگیشن، باید مکانیزم کش DNS را بشناسید. وقتی کاربر آدرسی را در مرورگر می‌زند، یک زنجیره از کوئری‌ها اتفاق می‌افتد:

1. Cache سیستم‌عامل: اولین جایی که چک می‌شود، کش محلی سیستم‌عامل کاربر است.
2. Resolver محلی: اگر کش سیستم‌عامل نداشت، کوئری به Resolver پیش‌فرض (معمولاً ISP یا DNS عمومی) می‌رود.
3. Resolver بازگشتی: اگر Resolver محلی هم نداشت، از یک Resolver بازگشتی — مثل Google DNS یا Cloudflare — استفاده می‌شود.
4. سرورهای Authoritative: اگر هیچ‌کدام از سه لایه‌ی بالا پاسخ معتبر نداشتند، درخواست به سرورهای Authoritative می‌رسد که داده را از Zone می‌خوانند.

در هر لایه‌ای که پاسخ پیدا شود، مقدار تا مدت TTL کش می‌شود. یعنی اگر TTL ۳۶۰۰ ثانیه باشد، آن لایه تا یک ساعت به سرور Authoritative برنمی‌گردد. این یعنی پس از تغییر شما، هر لایه در بازه‌ای متفاوت، نسخه‌ی جدید را می‌بیند.

TTL کجا ذخیره می‌شود؟

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

پروپاگیشن چقدر طول می‌کشد؟

پاسخ دقیق به این سوال بستگی به TTL فعلی و نوع تغییر دارد. جدول زیر تخمین‌های عملی را نشان می‌دهد:

نکته‌ی مهم: این اعداد، تخمین هستند، نه تضمین. در پروژه‌ها دیده‌ام که تغییر یک رکورد با TTL ۳۶۰۰ ثانیه، روی بخشی از کاربران در نیم‌ساعت و روی بخشی دیگر در ۱۲ ساعت اعمال شده. دلیل این تفاوت، رفتار متفاوت ISPها و Resolverهای محلی است.

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

راهکار اصلی، کاهش TTL پیش از تغییر است. سه گام عملی:

1. کاهش TTL پیش از تغییر: حداقل ۲۴ تا ۴۸ ساعت پیش از تغییر، TTL رکورد را به ۳۰۰ ثانیه یا کمتر کاهش دهید. در این بازه، کش Resolverها با مقدار جدید جایگزین می‌شود.
2. انتخاب زمان کم‌ترافیک برای تغییر: حتی با TTL پایین، بازه‌ی پروپاگیشن وجود دارد. اگر تغییر را در ساعات کم‌ترافیک انجام دهید، تعداد کاربرانی که در پنجره‌ی انتقال تحت تأثیر قرار می‌گیرند، کمتر است.
3. بازگردانی TTL پس از تثبیت: بعد از تثبیت تغییر (معمولاً ۲۴ تا ۴۸ ساعت بعد)، TTL را به مقدار پیش‌فرض برگردانید تا بار روی سرور Authoritative کاهش یابد.

یک استراتژی مکمل: اگر می‌خواهید مهاجرت را با ریسک حداقلی انجام دهید، ابتدا یک ساب‌دامین تستی (مثلاً test.example.com) را با همان TTL پایین تغییر دهید و رفتار پروپاگیشن را مشاهده کنید. این تست کوچک، تصویر واقعی رفتار شبکه برای دامنه‌ی شما را نشان می‌دهد.

تست پروپاگیشن از چند نقطه‌ی جغرافیایی

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

۱. ابزارهای آنلاین DNS Lookup

سرویس‌های زیادی هستند که هم‌زمان از چند نقطه‌ی جغرافیایی رکورد را بررسی می‌کنند و نشان می‌دهند کدام Resolverها مقدار قدیمی و کدام‌ها مقدار جدید دارند.

۲. خط فرمان با dig

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

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +short

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

۳. تست از شبکه‌های مختلف

اگر می‌خواهید رفتار ISPهای مختلف را ببینید، باید از شبکه‌های مختلف — حتی VPN یا شبکه‌ی موبایل — تست بگیرید. تجربه‌ام این است که در ایران، تفاوت رفتار ISPها در پروپاگیشن، گاهی چند ساعت است. برای عیب‌یابی سیستماتیک، چگونه DNS را عیب‌یابی کنیم را ببینید.

در بازه‌ی پروپاگیشن چه اتفاقی می‌افتد؟

در بازه‌ی پروپاگیشن، سه سناریو ممکن است رخ دهد:

1. نسخه‌ی ناهمگون: بخشی از کاربران نسخه‌ی جدید و بخشی دیگر نسخه‌ی قدیمی را می‌بینند. برای سایت‌های محتوایی، این معمولاً مسئله‌ای نیست؛ برای فروشگاه‌های اینترنتی، ممکن است مشکل‌ساز باشد.
2. خطای موقت: اگر سرور مقصد آماده نباشد یا رکورد ناقص منتقل شده باشد، برخی کاربران با خطای NXDOMAIN یا Server Not Found مواجه می‌شوند.
3. کندی موقت: اگر سرور مقصد در منطقه‌ای دورتر باشد، کاربران تا تثبیت مسیریابی، تأخیر بیشتری تجربه می‌کنند.

برای مدیریت این بازه، دو رویکرد مؤثر وجود دارد:

• نگه‌داشتن هر دو سرور فعال: در بازه‌ی پروپاگیشن، سرور قدیم و جدید هر دو فعال باشند. این کار اجازه می‌دهد کاربران، هر کدام به هر سرور که Resolverشان می‌گوید، پاسخ معتبر بگیرند.
• استفاده از CDN یا Reverse Proxy: اگر از یک لایه‌ی میانی استفاده می‌کنید، می‌توانید ترافیک را از هر دو سرور عبور دهید و تجربه‌ی ناهمگون را مدیریت کنید. برای درک نقش CDN، CDN چگونه سرعت سایت را بهبود می‌دهد را ببینید.

اشتباهات رایج در مدیریت پروپاگیشن

چهار اشتباه که در پروژه‌ها زیاد دیده‌ام:

• تغییر DNS بدون کاهش TTL: رایج‌ترین اشتباه. تغییر بدون آماده‌سازی، پروپاگیشن را طولانی و غیرقابل پیش‌بینی می‌کند.
• خاموش کردن سرور قدیم بلافاصله پس از تغییر: در بازه‌ی پروپاگیشن، برخی کاربران همچنان به سرور قدیم می‌رسند. اگر آن را خاموش کنید، این کاربران سایت را نمی‌بینند.
• نادیده گرفتن رکوردهای جانبی: فقط رکورد A را عوض می‌کنید و فراموش می‌کنید که رکورد CNAME یک ساب‌دامین هم باید منتقل شود. مسئله‌ای که در اشتباهات رایج در تنظیم DNS به‌تفصیل آورده‌ام.
• تست از یک نقطه: دیدن مقدار جدید از شبکه‌ی خودتان، به این معنی نیست که پروپاگیشن کامل شده است. حتماً از چند نقطه تست کنید.

پروپاگیشن را نمی‌شود عجله کرد، اما می‌شود مدیریتش کرد. تفاوت تیم حرفه‌ای و غیرحرفه‌ای، در همین مدیریت است.

پرسش‌های پرتکرار درباره پروپاگیشن DNS

پروپاگیشن با TTL صفر چقدر طول می‌کشد؟ حتی با TTL صفر، همچنان بازه‌ای وجود دارد. دلیلش این است که برخی Resolverها و سرویس‌های میانی به TTL احترام کامل نمی‌گذارند و برای مدت کوتاهی کش می‌کنند. تجربه‌ی من: با TTL ۳۰۰ ثانیه، اکثر تغییرات در یک ساعت روی اکثر کاربران اعمال می‌شود. برای جزئیات بیشتر تغییر DNS، تغییر DNS چه تاثیری بر سایت و رتبه Google دارد را ببینید.

آیا پروپاگیشن روی همه‌ی کاربران یکسان است؟ نه، و این نکته‌ی مهمی است. کاربران با ISPهای مختلف، رفتار متفاوتی می‌بینند. حتی کاربران یک ISP می‌توانند بسته به Resolverهای منطقه‌ای، نتیجه‌ی متفاوت بگیرند.

آیا می‌توانم پروپاگیشن را دستی مجبور به تکمیل کنم؟ نه در سطح اینترنت. اما می‌توانید روی سیستم‌های خودتان کش را پاک کنید. روی ویندوز با ipconfig /flushdns و روی لینوکس با sudo systemd-resolve --flush-caches. این فقط برای خود شما اثر دارد.

اگر در بازه‌ی پروپاگیشن سایت خطا داد، چه کنم؟ اول مطمئن شوید سرور قدیم همچنان فعال است. اگر خطا از سرور جدید می‌آید، سریعاً رکورد را به سرور قدیم برگردانید. بازگشت، به‌سرعت انتشار نمی‌شود، اما در بازه‌ی کوتاهی بخش بزرگی از کاربران به وضعیت قبلی برمی‌گردند. پس از رفع مشکل، تغییر را دوباره انجام دهید.

آیا پروپاگیشن روی ایمیل هم اثر دارد؟ بله، و به‌طور جدی‌تر. تغییر رکورد MX می‌تواند باعث گم‌شدن ایمیل در بازه‌ی پروپاگیشن شود. اگر می‌خواهید MX را تغییر دهید، از قبل برنامه‌ریزی دقیق داشته باشید و سرور ایمیل قبلی را برای چند روز فعال نگه دارید.

آیا DNS ابری پروپاگیشن را سریع‌تر می‌کند؟ به‌طور مستقیم نه، چون مکانیزم کش در سطح اینترنت است، نه در سطح سرور Authoritative. اما DNS ابری از این جهت کمک می‌کند که مدیریت TTL ساده‌تر و پایدارتر است. مفهوم DNS ابری را در DNS ابری چیست و چه تفاوتی با DNS سنتی دارد توضیح داده‌ام.

آیا سرعت DNS روی زمان پروپاگیشن اثر دارد؟ بله، غیرمستقیم. اگر سرور Authoritative شما کند باشد، Resolverها در بازه‌ی پروپاگیشن دیرتر به‌روزرسانی می‌شوند. برای بهبود سرعت، چگونه سرعت DNS را بهبود دهیم را ببینید.

آیا پروپاگیشن روی سئو اثر منفی می‌گذارد؟ اثر مستقیم ندارد، اما اگر باعث downtime یا تجربه‌ی ناهمگون برای کاربران و Googlebot شود، به‌طور غیرمستقیم می‌تواند روی رتبه اثر بگذارد. برای درک چارچوب کلی، سئو چیست و چگونه به رشد سایت کمک می‌کند را ببینید.

چطور بفهمم پروپاگیشن تمام شده است؟ وقتی از چند نقطه‌ی جغرافیایی مختلف (حداقل ۵ نقطه) تست کنید و همه‌ی Resolverها یک مقدار را برگردانند، پروپاگیشن عملاً تمام شده است. ابزارهای آنلاین Multiple DNS Check این تست را ساده می‌کنند. برای چارچوب عیب‌یابی، چگونه DNS را عیب‌یابی کنیم.

آیا می‌توانم با GeoDNS، پروپاگیشن را برای بخشی از کاربران حذف کنم؟ نه مستقیم، اما با GeoDNS می‌توانید پاسخ‌های متفاوتی برای مناطق مختلف بدهید و اثر انتقال را برای هر منطقه به‌طور جداگانه مدیریت کنید. این تکنیک در مهاجرت‌های بزرگ مفید است. مفهوم دقیق‌تر در DNS ابری چیست آمده است.

سه اصل کلیدی مدیریت بازه‌ی پروپاگیشن

اگر بخواهم تجربه‌ی چندین پروژه را در سه اصل خلاصه کنم:

1. آماده‌سازی: پیش از هر تغییر، TTL را کاهش دهید و از چند روز قبل، رفتار شبکه را با یک تست کوچک بسنجید.
2. صبر و پایش: در بازه‌ی پروپاگیشن، هر دو سرور فعال بمانند و از چند نقطه تست کنید. عجله، دشمن این بازه است.
3. برنامه‌ی بازگشت: همیشه یک راه بازگشت داشته باشید. اگر مشکلی پیش آمد، سریع رکورد را به مقدار قبلی برگردانید و پس از رفع مشکل، تغییر را دوباره انجام دهید.

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

در چارچوب کلی، این مقاله را در کنار رکوردهای DNS کدامند و تفاوت DNS و Nameserver چیست بخوانید تا تصویر کامل‌تری از لایه‌ی DNS داشته باشید. اگر تجربه‌ای از یک پروپاگیشن غیرمنتظره دارید — مخصوصاً اگر یک ISP خاص رفتار عجیبی داشته — در دیدگاه بنویسید. اسم ISP و رفتارش، برای خوانندگان بعدی که در همان منطقه هستند، بسیار ارزشمند است. ⏳