العَرَض المُربك
تُجري تغييراً في DNS. تُحدّث سجلّ A، تُبدّل nameservers، أو تُضيف سجلّ MX. ثمّ تفحص الموقع — وحسب الجهاز أو الشبكة أو المتصفّح، تحصل على إجابات مختلفة. هاتفك يرى الموقع القديم. حاسوبك المحمول يرى الجديد. صديقك في المدينة يرى القديم. بعد ساعات، الصورة لا تزال مختلطة.
هذا ليس خطأً في مزوّد DNS. هذا DNS يفعل بالضبط ما صُمّم له — والطريقة الوحيدة للتوقّف عن الإحباط منه هي فهم ما يحدث فعلاً.
ما يعنيه "الانتشار" حقّاً
"انتشار DNS" تقنياً تسمية خاطئة. نظام DNS لا يدفع التغييرات إلى أيّ مكان. بدلاً من ذلك، كل حاسوب يطلب سجلّ DNS يحصل على إجابة بالإضافة إلى TTL (Time To Live) — عدد ثوانٍ يُسمح بتخزين تلك الإجابة مؤقّتاً. خلال ذلك TTL، recursive resolvers (الخوادم التي تسألها أجهزتك) تستمرّ في إعادة الإجابة المُخزَّنة بدل الاستعلام مجدّداً.
إذن حين تُجري تغيير DNS، الإجابة الجديدة متاحة فوراً في nameserver authoritative. لكن كل recursive resolver في العالم يحمل الإجابة القديمة حتّى تنتهي صلاحية ذاكرته المؤقّتة. "الانتشار" مجرّد دورة حياة كل تلك الإدخالات المُخزَّنة وهي تنتهي صلاحيّتها وتُحدَّث.
TTL هو المقبض
كل سجلّ DNS لديه قيمة TTL، يضبطها مالك النطاق. القيم الشائعة:
- 300 ثانية (5 دقائق): عدواني، جيّد للاختبار والتغييرات المتكرّرة.
- 3600 ثانية (ساعة): افتراضي شائع لمعظم السجلّات.
- 86400 ثانية (24 ساعة): الحدّ الأقصى الموصى به للسجلّات الثابتة.
- حتّى 7 أيّام: الحدّ الأقصى النظري؛ نادراً مفيد.
TTLs أقلّ تعني انتشاراً أسرع لكن استعلامات DNS أكثر (تكلفة أعلى قليلاً على الجانب الموثوق، تجربة أبطأ قليلاً للمستخدمين عند فقد الذاكرة المؤقّتة). TTLs أعلى تعني استعلامات أقلّ لكن انتشاراً أبطأ.
الاستراتيجية: قبل إجراء تغيير، اخفض TTL إلى 300 ثانية وانتظر مدّة TTL السابق. ثمّ أجرِ التغيير. بعد الاستقرار، ارفع TTL إلى 3600 أو أعلى.
طبقات التخزين المؤقّت
الذاكرة المؤقّتة ليست شيئاً واحداً. توجد طبقات تخزين متعدّدة بين nameserver authoritative وجهازك:
- ذاكرة المتصفّح: Chrome وFirefox وSafari كلٌّ منها يُخزّن إجابات DNS لـ30–120 ثانية.
- ذاكرة OS: Windows وmacOS وLinux كلّها تُخزّن استعلامات DNS محلّياً.
- ذاكرة الموجّه: كثير من موجّهات المنزل/المكتب تُخزّن DNS لشبكتها المحلّية.
- ذاكرة ISP/recursive resolver: Comcast، Verizon، resolver مزوّد خدمتك — وresolvers عامّة مثل 1.1.1.1 و8.8.8.8 — تُخزّن لمدّة TTL.
- nameserver authoritative: مصدر الحقيقة.
تغيير على الخادم authoritative يصبح مرئياً لجهازك فقط حين تُحدِّث كلّ الطبقات الفوقية. لذا تستطيع رؤية إجابات مختلفة على أجهزة مختلفة على نفس الشبكة — ذاكرات مختلفة، توقيتات انتهاء مختلفة.
لماذا تغييرات nameserver أبطأ
تغيير سجلّ A فردي شيء. تغيير nameservers الخاصّة بك (سجلّات NS عند السجلّ) شأن أكبر. سجلّات nameserver يُديرها سجلّ TLD (Verisign لـ.com)، وTTL على تلك السجلّات عادةً 24–48 ساعة وغير قابل للضبط من المستخدم.
لذا نقل مزوّدي DNS — التبديل من DNS مسجّلك إلى Cloudflare، مثلاً — يمكن أن يستغرق يوماً أو يومَين كاملَين لآخر المتأخّرين للحاق. خطّط وفقاً لذلك.
كيف تتحقّق من حالة الانتشار
أدوات يمكنك استخدامها:
- dig +trace example.com على طرفية Linux/macOS — يُظهر المسار الكامل من الجذر إلى authoritative.
- nslookup example.com 1.1.1.1 — استعلم من resolver عامّ محدّد لرؤية ما يُعيده حالياً.
- whatsmydns.net أو dnschecker.org — يفحصان الإجابة من عشرات resolvers حول العالم. إن كان معظمهم يُظهر الإجابة الجديدة، الانتشار شبه مكتمل.
مهمّ: الخادم authoritative هو مصدر الحقيقة الوحيد. إن أظهرت لوحة مزوّد DNS authoritative السجلّ الجديد، فعلت دورك. الباقي انتظار.
كيف تُسرّعه (حيث ممكن)
- اخفض TTLs مسبقاً. الرافعة الأكبر منفردة. اخفض إلى 300 ثانية يوماً قبل أيّ تغيير مخطّط.
- امسح الذاكرات المحلّية:
- Windows: ipconfig /flushdns
- macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Linux (systemd): sudo systemd-resolve --flush-caches
- Chrome: chrome://net-internals/#dns → Clear host cache
- اختبر من شبكة مختلفة. بيانات الجوّال بدل Wi-Fi غالباً تضرب resolver مختلف وتُريك الحالة الحالية.
- استخدم resolver عاماً مباشرة. اضبط جهازك لاستخدام 1.1.1.1 أو 8.8.8.8 بدل resolver مزوّد خدمتك — كلاهما لديه سياسات تخزين أقصر وغالباً يُحدِّثان أسرع.
ما تتجنّبه أثناء الانتشار
- لا تُعدِّل بهلع. إن لم يظهر التغيير في 5 دقائق، هذا طبيعي. إعادة تحرير السجلّ أثناء انتشاره فقط يُضيف ارتباكاً.
- لا تفترض "معطّل" يعني معطّلاً. أجهزة مختلفة تُظهر إجابات مختلفة هي الحالة المتوقّعة أثناء الانتشار، لا فشل.
- لا تحذف البنية التحتية القديمة بسرعة. إن بدّلت المضيفين وفكّكت الخادم القديم قبل اكتمال الانتشار، سترى انقطاعات حقيقية للمستخدمين الذين ما زالوا يضربون IP القديم.
الجدول الزمني الصادق
لمعظم تغييرات DNS:
- 5–15 دقيقة: الانتشار مرئي في بيئتك المباشرة.
- 1–4 ساعات: غالبية resolvers حول العالم مُحدَّثة.
- 24 ساعة: شبه كل الذاكرات مُحدَّثة.
- 48 ساعة: المتأخّرون والحالات الحدّية لاحقوا.
لتغييرات nameserver خصوصاً، ضاعف هذه الأرقام.
النموذج الذهني الذي تحتفظ به
انتشار DNS ليس مفتاحاً يُقلَب. إنّه ملايين الذاكرات تنتهي صلاحيّتها مستقلّةً في أوقات مختلفة قليلاً. مهمّتك إجراء التغيير مرّة واحدة، خفض TTLs مسبقاً لتقصير نوافذ التخزين، والانتظار. الفحص الهوسي لا يُسرّعه؛ يُجعلك أكثر وعياً بالاختلافات.