زمن البقاء، أو TTL، رقم مرفق بكل سجل DNS يُخبر أي مُحلِّل يخزّن ذلك السجل مؤقتًا بالضبط بعدد الثواني المسموح له فيها استخدام الإجابة المخزَّنة قبل أن يضطر لسؤال الخادم المرجعي مجددًا. إنه إعداد صغير مسؤول عن كل ما يختبره الناس تقريبًا باسم "انتشار DNS" — مصطلح يوحي بأن شيئًا ما ينتشر فعليًا للخارج، بينما ما يحدث في الواقع أبسط وأكثر آلية من ذلك.
ما هو TTL فعليًا
لكل سجل DNS — سجل A يوجِّه نطاقًا لعنوان IP، سجل MX للبريد، سجل CNAME، أي منها — قيمة TTL محدَّدة بالثواني. يعني TTL بقيمة 3600 أن أي مُحلِّل يستعلم عن ذلك السجل مسموح له بتخزين الإجابة مؤقتًا وإعادة استخدامها لمدة تصل إلى ساعة قبل أن يُطالَب بسؤال الخادم المرجعي من جديد عن إجابة حديثة. تُضبَط هذه القيمة لكل سجل من قِبل من يدير منطقة DNS، وتنتقل مع السجل نفسه — أي مُحلِّل في أي مكان بالعالم يستعلم عن ذلك السجل يتلقى TTL مرفقًا مع الإجابة ويلتزم به.
لماذا "الانتشار" انتهاء صلاحية ذاكرة مؤقتة، لا دفعًا
يسري تغيير سجل DNS على الخادم المرجعي فورًا — لا يوجد تأخير من تلك الناحية. يأتي التأخير الذي يختبره الناس بالكامل من كل مُحلِّل، في كل مكان، خزَّن القيمة القديمة مؤقتًا بالفعل ولم تنتهِ صلاحية نسخته بعد. مُحلِّل مزوّد خدمة إنترنت، نظام تشغيل زائر، ذاكرة DNS مؤقتة في شركة — أي منها استعلم عن السجل قبل التغيير وخزَّنه وفق TTL الذي كان ساريًا وقتها، سيستمر في خدمة تلك الإجابة القديمة المخزَّنة لأي شخص يسأل عبره حتى تنتهي صلاحية نسخته. لا شيء يدفع القيمة الجديدة إلى تلك الذاكرات المؤقتة؛ تستمر ببساطة في الإجابة من الذاكرة حتى ينفد TTL لديها، وعندها تسأل مجددًا وتحصل على الإجابة الجديدة. هذا سبب كون الانتشار غير فوري رغم أن التغيير المرجعي كذلك: محكوم بأقدم TTL لا يزال مخزَّنًا مؤقتًا في مكان ما بالعالم، لا بالمسافة التي يجب أن يقطعها التغيير.
مثال عملي: خفض TTL قبل عملية نقل
لنفترض موقعًا ينتقل إلى خادم جديد بعنوان IP جديد، وسجل A الحالي له TTL بقيمة 86400 ثانية (24 ساعة). تغيير عنوان IP يوم النقل، مع بقاء ذلك TTL ساريًا، يعني أن أي مُحلِّل خزَّن العنوان القديم مؤقتًا في أي وقت خلال الساعات الأربع والعشرين السابقة سيستمر بإرسال الزوار إلى الخادم القديم لمدة تصل إلى يوم كامل بعد التغيير — بالضبط السيناريو الذي يجعل بعض الزوار يرون الموقع الجديد بينما لا يزال آخرون يصلون القديم. الحل خفض TTL قبل النقل، لا في يوم النقل نفسه: تغييره مثلاً إلى 300 ثانية (خمس دقائق) قبل يوم أو يومين من الانتقال يمنح الذاكرات المؤقتة الحالية وقتًا لتنتهي صلاحيتها وتلتقط TTL الجديد الأقصر. بحلول وقت تغيير IP فعليًا، تكون معظم المُحلِّلات تعيد التحقق كل خمس دقائق بدلاً من كل 24 ساعة، فينتشر تغيير IP نفسه خلال دقائق لا خلال يوم كامل محتمل. رفع TTL لقيمته الطبيعية بعد ذلك، بمجرد تأكُّد استقرار النقل، خطوة أخيرة معقولة.
TTL منخفض مقابل مرتفع: المقايضة الحقيقية
TTL منخفض (ثوانٍ إلى بضع دقائق) يعني أن التغييرات تسري بسرعة في كل مكان تقريبًا، وهذا مفيد حول تغييرات مخطَّط لها أو حين يهم التبديل السريع. الثمن أنه يزيد حجم استعلامات DNS، لأن كل مُحلِّل يضطر لإعادة السؤال أكثر بكثير بدلاً من الخدمة من الذاكرة المؤقتة — تكلفة ضئيلة لمعظم المواقع، لكنها ليست مجانية حرفيًا. أما TTL مرتفع (ساعات إلى يوم أو أكثر) فيقلل حجم الاستعلامات ومناسب للسجلات نادرة التغيير، لكنه يعني أن أي تصحيح غير مخطَّط له — خطأ، تغيير IP طارئ — يستغرق وقتًا أطول بالمثل ليصل للجميع. لا أحدهما صحيح عالميًا؛ تعتمد القيمة الصحيحة على مدى استقرار سجل معيّن المتوقع وكم سيكلف أن يستغرق تصحيحه ساعات ليسري بالكامل. إعداد افتراضي معقول لمعظم السجلات التي لا تتغيّر فعلاً يقع في مدى 3600 إلى 14400 ثانية (ساعة إلى أربع ساعات) — قصير بما يكفي ليسري تصحيح طارئ حقيقي خلال نافذة معقولة، وطويل بما يكفي ليبقى حجم الاستعلامات العادي معتدلاً. يمكن للسجلات المرتبطة ببنية تحتية يُتوقَّع استقرارها لفترات طويلة، كسجلات NS لنطاق بمجرد ضبط خوادمه الاسمية، استخدام TTL أطول من ذلك.
TTL عبر أنواع السجلات المختلفة
ليس كل سجل مرشحًا جيدًا لـ TTL منخفض جدًا، وبعضها له قيود خارجة عن تحكم مالك النطاق المباشر. تُستعلَم سجلات NS (التي تحدد الخوادم الاسمية المرجعية للنطاق) وتُخزَّن مؤقتًا في مستوى أعلى من تسلسل DNS الهرمي، بواسطة مُحلِّلات وخوادم اسمية أخرى لا تحترم بالضرورة TTL منخفضًا بشكل غير معتاد بنفس الطريقة التي تفعلها مع سجل A عادي — يمكن أن تستغرق تغييرات الخوادم الاسمية وقتًا أطول لتستقر بالكامل بغض النظر عن TTL المضبوط على السجل، ببساطة بسبب مدى اتساع وتكرار تخزين معلومات NS مؤقتًا عبر النظام. توجد أيضًا قيمة منفصلة تُسمى TTL التخزين المؤقت السلبي، تُضبَط في سجل SOA للمنطقة، وتتحكم في المدة التي تخزّن فيها المُحلِّلات مؤقتًا حقيقة عدم وجود سجل (مفيدة حين يُستعلَم عن سجل لم يُنشأ قط، أو حُذف) — هذا رقم مختلف عن TTL أي سجل فردي، ويستحق عدم الخلط بينهما عند تشخيص سبب استمرار ظهور سجل قديم أو مُزال في مكان ما. بالنسبة لمعظم التغييرات اليومية — إعادة توجيه سجل A، تحديث سجل MX — فإن TTL العادي لكل سجل الموضَّح أعلاه هو ما يهم؛ أما TTL مستوى NS وSOA فطبقة منفصلة وأقل مساسًا بالتغييرات اليومية.
أكثر خطأ شائع في TTL
الخطأ الأكثر شيوعًا هو تغيير TTL في نفس وقت تغيير السجل نفسه، لا مسبقًا. بحلول اللحظة التي تصبح فيها قيمة TTL المخفَّضة مرئية للمُحلِّلات، يكون الوقت قد فات بالفعل على تسريع انتشار التغيير الذي دفع لخفضها — لا يزال TTL القديم الأطول هو المخزَّن مؤقتًا في كل مكان، وهو ما يحدد مدة بقاء الإجابة القديمة. خفض TTL لا يفيد إلا إن تم مبكرًا بما يكفي ليكون TTL الأطول السابق قد انتهت صلاحيته بالفعل في كل مكان قبل حدوث التغيير الفعلي.
إرشادات عملية
لأي تغيير مخطَّط له — نقل خادم، تغيير مزوّد بريد، إعادة توجيه نطاق فرعي — اخفض TTL على السجل المحدَّد قيد التغيير قبل 24 إلى 48 ساعة من الموعد، ولا تُجرِ التغيير الفعلي إلا بعد انقضاء تلك النافذة، ثم ارفع TTL لقيمته الطبيعية (3600 إلى 86400 ثانية، حسب مدى توقّع تغيّر السجل) بمجرد التأكد من عمل القيمة الجديدة في كل مكان. بالنسبة للسجلات التي لا تتغيّر تقريبًا أبدًا، فإن TTL أطول ببساطة أكفأ دون أي عيب حقيقي. هذا موضوع أضيق وأكثر آلية من DNS ككل — راجع دليلك العملي إلى DNS لمعرفة كيف تعمل أنواع السجلات وسلسلة التحليل الأوسع، ونقل النطاقات لمعرفة كيف يتناسب تخطيط TTL مع نقل نطاق تحديدًا.
