انتشار DNS: لماذا يتأخر التغيير وكم يستغرق؟

نقلت متجرك souq-alataba.com إلى خادم جديد في العاشرة صباحاً بتوقيت القاهرة. زميلك في الإسكندرية يرى الموقع الجديد بعد دقائق، وعميل في لندن ما زال يصل إلى الخادم القديم في الثالثة عصراً. لا شيء معطّل هنا، ولا شيء «ينتشر» أصلاً: خادم الأسماء لا يدفع تغييرك إلى أحد، بل تحتفظ آلاف المحلّلات حول العالم بالجواب القديم إلى أن تنتهي صلاحيته، كلٌّ في موعده. حين تعرف من يحتفظ بالجواب وكم يحتفظ به، تستطيع أن تخطط لأي تغيير دون أن يلاحظه زوارك.

01لا شيء ينتشر: ذاكرات تنتهي صلاحيتها

حين يكتب زائرك اسم نطاقك، لا يسأل جهازه خادم أسمائك مباشرة. يسأل محلّلاً تكرارياً، هو غالباً خادم مزود الإنترنت أو محلّل عام، وهذا يتتبع السلسلة من جذر DNS إلى خوادم الامتداد ثم إلى الخادم الرسمي لنطاقك، ويحفظ الجواب في ذاكرته. ومع كل جواب رقم اسمه TTL: عدد الثواني التي يحق فيها للمحلّل أن يعيد الجواب نفسه دون أن يسأل من جديد.

تعديلك في لوحة DNS يصل إلى الخادم الرسمي فوراً. لكن محلّلاً حفظ الجواب القديم قبل ساعة، وTTL فيه 86400 ثانية، سيعطيه لكل من يسأله 23 ساعة أخرى. ومحلّل آخر لم يسأل عن نطاقك منذ أيام سيأخذ الجواب الجديد من أول طلب. لذلك لا يصل التغيير إلى بلد دفعة واحدة، بل إلى كل محلّل حين تنتهي نسخته. وبين زائرك والمحلّل طبقات تحفظ الأجوبة أيضاً: نظام التشغيل، والمتصفح، وأحياناً جهاز التوجيه في المنزل.

جرّب ذلك في المحاكي: حرّك الزمن بعد تغيير سجل A، وراقب كيف يصل الجواب الجديد إلى كل بلد بحسب ما بقي من TTL في ذاكرة محلّله.

02TTL: الرقم الذي يحكم المدة

أهم ما يجب أن تتذكره: مدة الانتظار يحددها TTL القديم، أي القيمة التي كانت في السجل حين حفظته المحلّلات، لا القيمة التي تكتبها الآن. إن كان TTL سجلك يوماً كاملاً، وخفّضته إلى 300 ثانية في التعديل نفسه الذي غيّرت فيه العنوان، فالمحلّلات التي تحمل النسخة القديمة ستحتفظ بها حتى يكتمل يومها.

لماذا لا تجعل TTL منخفضاً دائماً؟ لأن كل انتهاء يعني سؤالاً جديداً يمر بالسلسلة كلها، فيضيف عشرات الميلي ثواني إلى أول طلب بعده، ويزيد الحمل على خوادم الأسماء، ويجعل موقعك أكثر حساسية لأي انقطاع فيها. ثم إن المحلّلات لا تلتزم كلها بالرقم حرفياً: بعضها يرفع القيم المنخفضة جداً إلى حد أدنى خاص به، وبعضها يضع سقفاً أعلى يوماً أو أسبوعاً. اعتبر TTL القديم المدة المتوقعة عند أغلب زوارك، واترك هامشاً لقلة تخالفه.

03التخزين السلبي: حين يُحفظ جواب «غير موجود»

المحلّلات لا تحفظ الأجوبة الموجودة وحدها. إن سألت عن اسم لا وجود له، يعود الجواب NXDOMAIN، ويحفظه المحلّل أيضاً مدةً يحددها سجل SOA في منطقة نطاقك: الأصغر بين TTL سجل SOA نفسه وحقله الأخير المسمّى MINIMUM. هذا هو التخزين السلبي، ووراءه مشكلة تتكرر كثيراً.

مثال: ستطلق shop.souq-alataba.com في العاشرة. قبلها بخمس دقائق تفتح الرابط لتجربته قبل أن تضيف السجل، فيحفظ محلّل مزودك جواب «غير موجود». تضيف السجل في العاشرة فيراه زملاؤك فوراً، وتبقى أنت ترى خطأ حتى تنتهي مدة الجواب السلبي، وقد تبلغ ساعة. القاعدة بسيطة: أضف السجل أولاً، ثم جرّبه. ولتعرف المدة في نطاقك، اقرأ الحقل الأخير من SOA:

# الحقل الأخير في الجواب هو مدة التخزين السلبي بالثوانيdig souq-alataba.com SOA +nocmd +noall +answer# مثال على الناتج، والمدة هنا 300 ثانية:# souq-alataba.com. 3600 IN SOA ns1.souq-alataba.com. hostmaster.souq-alataba.com. 2026101101 7200 1800 1209600 300

وكثير من برامج المحلّلات تضع سقفاً لهذه المدة، بين ساعة وثلاث ساعات في إعداداتها الافتراضية، لكن لا تبنِ خطتك على ذلك.

04لماذا يتأخر تغيير خوادم الأسماء أكثر

تغيير سجل داخل منطقتك يمر بطبقة واحدة من الذاكرات. أما تغيير خوادم الأسماء نفسها، كأن تنقل إدارة نطاقك من مزود إلى آخر، فيمر بطبقة أعلى: سجلات التفويض في منطقة الامتداد نفسه، مثل .com أو .net، ولا تتحكم أنت في TTL الخاص بها. في امتدادات كثيرة يبلغ 172800 ثانية، أي 48 ساعة، ومن هنا جاء الرقم الشائع. والقيمة تختلف من امتداد لآخر، وبعض الجهات المديرة للامتدادات لا تنشر التعديل إلا في دورة تحديث دورية، فيضاف وقتها إلى الانتظار.

خلال هذه المدة يسأل بعض المحلّلات الخوادم القديمة وبعضها الجديدة. لذلك تبدأ خطة النقل الآمنة بنسخ المنطقة كاملة إلى المزود الجديد قبل التغيير، وتُبقي المنطقة القديمة تعمل بسجلات مطابقة ثلاثة أيام على الأقل بعده. لا تحذفها يوم التغيير، ولا تعدّل سجلاً في إحداهما دون الأخرى. ولتعرف TTL التفويض في امتداد نطاقك، اسأل خادم الامتداد مباشرة:

# اسأل أحد خوادم الامتداد عن تفويض نطاقك دون تكرار (غيّر com. إلى امتداد نطاقك)dig @$(dig +short NS com. | head -n1) souq-alataba.com NS +norecurse +noall +authority# الرقم بعد اسم النطاق في كل سطر هو TTL التفويض بالثواني

05خطة تغيير بلا انقطاع

هذه الخطوات تصلح لنقل موقع أو بريد إلى خادم جديد، وتحوّل الانتظار إلى جدول زمني تعرفه مسبقاً:

1. 01اقرأ TTL الحالي: اسأل الخادم الرسمي عن السجل الذي ستغيّره ودوّن TTL. إن كان 86400، فأمامك يوم كامل بين خفضه وتغيير السجل.
2. 02اخفضه مسبقاً: غيّر TTL إلى 300 ثانية، وانتظر مدة لا تقل عن قيمته القديمة حتى تنتهي كل النسخ الطويلة.
3. 03جهّز الخادم الجديد واختبره: اختبره باسم نطاقك قبل أن تغيّر DNS، بأمر curl الأخير في أوامر التحقق أدناه، فيصل إلى عنوانه الجديد مباشرة دون أن يسأل أي محلّل.
4. 04غيّر السجل في ساعة هادئة: وأبقِ الخادم القديم يخدم الزوار، أو يحوّلهم إلى الجديد، لأن بعضهم سيصل إليه دقائق أخرى.
5. 05تحقق وراقب: اسأل الخادم الرسمي ثم المحلّلات العامة، وتابع سجل الوصول في الخادم القديم حتى تتوقف الطلبات.
6. 06أعد TTL: بعد يوم أو يومين من الاستقرار، أعده إلى 3600 أو أكثر، ثم أوقف الخادم القديم.

06تحقق بنفسك: dig وفحص الانتشار

لا تحكم من متصفحك، فهو آخر حلقة في سلسلة الذاكرات. اسأل كل طبقة على حدة:

# 1. الخادم الرسمي: ما يجب أن يراه الجميع (TTL هنا هو القيمة الكاملة)dig @$(dig +short NS souq-alataba.com | head -n1) souq-alataba.com A +nocmd +noall +answer# 2. محلّلات عامة: TTL هنا هو المتبقي في ذاكرتها، ويتناقص مع كل سؤالdig @1.1.1.1 souq-alataba.com A +nocmd +noall +answerdig @8.8.8.8 souq-alataba.com A +nocmd +noall +answer# 3. السلسلة كاملة من الجذر، دون أي ذاكرة مؤقتةdig +trace souq-alataba.com A# 4. اختبر الخادم الجديد باسم نطاقك قبل تغيير DNS أو أثناء الانتظارcurl -sI --resolve souq-alataba.com:443:203.0.113.50 https://souq-alataba.com/

اقرأ العمود الثاني في كل جواب. في جواب المحلّل العام هو الثواني الباقية قبل أن يسأل من جديد: إن رأيت العنوان القديم ومعه 41000، فأنت تعرف أنه سيتغير بعد نحو 11 ساعة، فلا داعي للقلق ولا لتعديل جديد. والمحلّلات العامة الكبيرة موزعة على خوادم كثيرة، فقد يختلف الرقم بين سؤال وآخر.

ثم انظر إلى الصورة العالمية بأداة فحص انتشار DNS في إليفانتي: تسأل 19 نقطة حول العالم، من دبي والرياض والقاهرة إلى فرانكفورت وسنغافورة، عن سجلات نطاقك، وتقارن كل جواب بما تقوله خوادم أسمائه الرسمية. فترى في دقيقة أين وصل الجواب الجديد، وأين ما زالت نسخة قديمة تنتظر انتهاءها. وإن ظهر التغيير في كل مكان إلا جهازك، فامسح ذاكرة نظامك، ثم أغلق المتصفح وافتحه:

# Windowsipconfig /flushdns# macOSsudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder# Linux (systemd-resolved)resolvectl flush-caches

أعراض شائعة وأسبابها

المشكلةالخادم الرسمي نفسه يعطي القيمة القديمة

الحلعدّلت منطقة لا يقرأ منها أحد، لأن نطاقك يشير إلى خوادم أسماء أخرى. قارن ناتج dig NS بالمكان الذي تعدّل فيه، وأعد التعديل في المنطقة الفعلية.

المشكلةمرّ يوم وبعض المحلّلات ما زالت تعطي العنوان القديم

الحلكان TTL القديم مرتفعاً، أو يحتفظ بعض المحلّلات أطول منه. راقب TTL المتبقي في dig، وأبقِ الخادم القديم يخدم الزوار حتى ينتهي.

المشكلةنطاق فرعي جديد يعطيك «غير موجود» وحدك

الحلتخزين سلبي من تجربة سبقت إضافة السجل. انتظر مدة SOA الأخيرة أو اسأل محلّلاً آخر، وامسح ذاكرة جهازك.

المشكلةبعد تغيير خوادم الأسماء تعطي نقاط الفحص أجوبة مختلفة

الحلبعضها ما زال يسأل الخوادم القديمة بسبب TTL التفويض. تأكد أن المنطقتين متطابقتان، ولا تحذف القديمة قبل مرور ثلاثة أيام.

المشكلةالموقع يعمل والبريد توقف بعد نقل المنطقة

الحلنُقل سجل A ونُسي MX أو TXT. قارن السجلات كلها بين المنطقتين، لا سجل الموقع وحده.

07قبل أن تغيّر سجلاً غداً

اجعل TTL المعتاد لسجلات موقعك وبريدك ساعة، وخفّضه إلى 300 ثانية قبل أي تغيير مخطط بمدة لا تقل عن قيمته القديمة، ثم أعده بعد يومين. أضف السجلات الجديدة قبل أن تجربها، وأبقِ الخادم القديم والمنطقة القديمة حيّين حتى تنتهي آخر نسخة محفوظة. وتحقق بالترتيب: الخادم الرسمي أولاً، ثم المحلّلات العامة، ثم فحص الانتشار من 19 نقطة.

وإن كنت تدير سجلاتك في DNS Console، فكل حفظ يصل إلى خوادم أسماء إليفانتي في لحظته، وما يبقى هو انتظار الذاكرات الذي شرحناه هنا. أما أنواع السجلات وقيم TTL المناسبة لكل منها، فنشرحها في مقال مستقل على المدونة.