تحمل كل إجابة DNS قيمة TTL (مدة البقاء) تخبر خوادم الحل (resolvers) بالمدة التي يجوز لها فيها الاحتفاظ بالإجابة في ذاكرتها المؤقتة. وعند نقل موقع أو خدمة بريد، تحدد هذه القيمة المدة التي يظل فيها بعض الزوار يصلون إلى الخادم القديم. بالتخطيط الجيد ينتهي التحويل خلال دقائق، وبدونه قد يمتد يوماً أو أكثر.
يشرح هذا الدليل الآلية كما تحددها معايير DNS، مع جدول زمني عملي يمكنك متابعته باستخدام dig.
ما الذي يتحكم فيه TTL فعلاً
يعرّف RFC 1035 قيمة TTL بأنها الفترة بالثواني التي يجوز فيها تخزين السجل مؤقتاً قبل الرجوع إلى المصدر مجدداً، والقيمة صفر تعني استخدام الإجابة للعملية الحالية فقط. تبدأ خوادم الحل (لدى مزود الإنترنت أو الشركة أو الخوادم العامة) العد التنازلي منذ لحظة جلب السجل، وحتى يصل إلى الصفر تجيب من ذاكرتها المؤقتة مهما غيّرت لدى مزود DNS.
يترتب على ذلك أمران:
- تغيير TTL نفسه يُخزَّن مؤقتاً. إذا كانت قيمة TTL للسجل 86400 (يوم كامل) وخفضتها إلى 300، فإن خوادم الحل التي جلبته قبل ساعة تحتفظ بالنسخة القديمة بقيمتها القديمة لمدة قد تصل إلى 23 ساعة أخرى. خفض TTL لا يفيد إلا بعد انقضاء القيمة القديمة.
- تغيير TTL والقيمة في الوقت نفسه لا يحقق شيئاً. فالقيمة القصيرة الجديدة تنطبق فقط على من يجلب السجل الجديد.
الإجابات السلبية تُخزَّن أيضاً
عندما لا يوجد اسم أو نوع سجل، تُخزَّن الإجابة السلبية (NXDOMAIN أو إجابة فارغة) أيضاً. ويحدد RFC 2308 مدة هذه الإجابة بالقيمة الأصغر بين حقل MINIMUM في سجل SOA وقيمة TTL لسجل SOA نفسه. ويلغي المعيار ذاته الاستخدام القديم لحقل MINIMUM كحد أدنى للمنطقة كلها، ويقترح أن تضع خوادم الحل سقفاً للتخزين السلبي، مشيراً إلى أن ساعة إلى ثلاث ساعات تعمل جيداً وأن القيم التي تتجاوز يوماً سببت مشكلات.
عملياً: إذا اختبرت new.example.com قبل إنشائه، فقد تتذكر خوادم الحل أنه غير موجود طوال المدة التي يسمح بها سجل SOA لديك. أنشئ السجلات أولاً ثم اختبرها.
اعرف قيم TTL التي تنشرها
استعلم من أحد خوادم الأسماء الموثوقة مباشرة حتى لا تتدخل أي ذاكرة مؤقتة:
dig @ns1.your-dns-host.example www.example.com A +norecurse +noall +answer
dig @ns1.your-dns-host.example example.com MX +norecurse +noall +answer
dig example.com SOA +shortالعمود الثاني في كل سطر إجابة هو قيمة TTL. ويعرض سجل SOA بالترتيب: خادم الأسماء الأساسي، وصندوق بريد المسؤول، والرقم التسلسلي، ثم قيم refresh وretry وexpire وminimum، والقيمة الأخيرة هي التي تغذي التخزين السلبي كما سبق.
أما عبر خادم حل عام فالقيمة التي تراها هي الوقت المتبقي في ذاكرته المؤقتة، لذا تتناقص بين استعلام وآخر:
dig @1.1.1.1 www.example.com A +noall +answer
dig @8.8.8.8 www.example.com A +noall +answerجدول زمني للترحيل
لنفترض أن قيمة TTL للسجلات التي ستغيرها 3600 ثانية (ساعة). عدّل أوقات الانتظار وفق قيمك الفعلية.
- قبل التغيير بمدة TTL القديمة على الأقل مع هامش (هنا: في اليوم السابق): خفّض قيمة TTL لكل سجل ستغيره إلى 300 ثانية. والمرشحون المعتادون سجلات A وAAAA للموقع وأي سجلات CNAME، وفي نقل البريد سجلات MX وسجل SPF من نوع TXT وسجلات autodiscover. لا تغيّر أي قيمة بعد.
- تحقق من نشر القيمة الجديدة على كل خادم أسماء موثوق، ثم انتظر انقضاء TTL القديمة حتى تنتهي كل النسخ المخزنة لدى خوادم الحل.
- نفّذ التغيير (عنوان IP جديد أو مضيف MX جديد)، وستلتقطه خوادم الحل خلال خمس دقائق تقريباً.
- أبقِ الخادم القديم يعمل. فقد يصل إليه بعض العملاء وخوادم الحل لفترة، كما يسمح RFC 8767 لخوادم الحل بمواصلة تقديم بيانات منتهية الصلاحية إذا تعذر عليها الوصول إلى خوادم أسمائك، مع اقتراح سقف قدره سبعة أيام. في حالة الموقع قدّم المحتوى نفسه أو إعادة توجيه، وفي حالة البريد أبقِ الخادم القديم يستقبل الرسائل ويعيد توجيهها.
- ارفع قيمة TTL مجدداً بعد استقرار كل شيء، إلى 3600 مثلاً. فالقيم الصغيرة جداً بشكل دائم تزيد اعتماد كل زائر على توافر مزود DNS وترفع حجم الاستعلامات دون فائدة تذكر خارج نوافذ التغيير.
ما لا يسرّعه خفض TTL
- تغيير خوادم الأسماء لدى المسجّل. سجلات NS وأي سجل DS (لـDNSSEC) الخاصة بنطاقك موجودة في المنطقة الأم التي تديرها جهة التسجيل، بقيم TTL لا تتحكم فيها، ولا تختصرها قيمة NS في منطقتك. أبقِ مزود DNS القديم يقدم المنطقة نفسها حتى يظهر التفويض الجديد في كل مكان.
- ذاكرات مؤقتة خارج DNS. التطبيقات التي تحتفظ باتصالات طويلة أو تحفظ نسختها الخاصة من العنوان قد لا تعيد البحث عن الاسم حتى تُعاد تشغيلها، وإبقاء الخادم القديم يعمل يغطي هذه الحالات أيضاً.
أخطاء شائعة
- خفض TTL قبل التغيير بساعة واحدة لسجل كانت قيمته يوماً كاملاً.
- نسيان السجلات المرتبطة:
wwwمقابل النطاق المجرد، أو سجلات AAAA التي ما زالت تشير إلى عنوان IPv6 القديم، أو سجلات MX وSPF في نقل البريد. - اختبار اسم مضيف قبل إنشائه وتخزين الإجابة السلبية.
- إيقاف الخادم القديم أو مزود DNS القديم لحظة تغيير السجل.
- ترك قيم TTL عند 60 أو 300 ثانية بشكل دائم بعد انتهاء الترحيل.
ما الذي ينبغي فعله
- افحص قيم TTL الحالية على خوادم الأسماء الموثوقة قبل التخطيط لأي تغيير.
- خفّض قيمة TTL للسجلات التي ستغيرها قبل التغيير بمدة TTL القديمة على الأقل مع هامش، وتحقق من ذلك.
- أنشئ السجلات الجديدة قبل اختبارها، واعرف قيمة التخزين السلبي في سجل SOA.
- غيّر القيم، وتحقق بـ
digمقابل خوادم أسمائك واثنين من خوادم الحل العامة، وأبقِ الخادم القديم يعمل. - أعد قيم TTL إلى وضعها الطبيعي بعد اكتمال النقل.
Comments
0 total · 0 threads