الخلاصة

  • انتهاء TTL ينهي حق إعادة الاستخدام العادي ويُلزم resolver باستشارة المصدر من جديد. لا يبدأ استثناء RFC 8767 إلا إذا تعذر refresh موثوق وبقيت إجابة سابقة مؤهلة.
  • تحكم أربع مدد مختلفة في القرار: مهلة العميل، ميزانية عملية resolution، مهلة إعادة فحص الفشل، والحد الأقصى لعمر stale. لا يثبت مؤشر enabled سلوك أي منها.
  • يجب فصل RRset القديم، وفشل التحديث الحالي، وزمن RRSIG، وTTL القصير في الرد، وEDE، واستمرار refresh، ونتيجة التطبيق. جمعها تحت «نجاح DNS» ينسب قرار resolver المحلي إلى مالك المنطقة.

اسم الطوارئ الذي ظل غير موجود

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

يمكن للـresolver إظهار فشل واضح. ويمكنه أيضاً إعادة NXDOMAIN stale بسرعة، فيبدو DNS سليماً بينما يظل باب التعافي الجديد غير موجود للمستخدمين. الذاكرة هنا لا تحفظ وصولاً قديماً؛ إنها تنفّذ غياباً قديماً ضد حضور جديد.

لهذا لا تكفي عبارة «القديم أفضل من لا شيء». أحياناً يكون القديم عنواناً ما زال يعمل، وأحياناً يكون نفياً يمنع إصلاحاً. السؤال هو: أي ادعاء سابق يجوز أن يستمر، بعد أي محاولة فاشلة، ولمدة كم، ومن يتحمل أثره؟

TTL يفصل سلطة الناشر عن استثناء resolver

ربطت RFC 1035 قيمة TTL بموعد الرجوع إلى مصدر المعلومة والتخلص المعتاد من RR. ووصفتها RFC 2181 بأنها أقصى مدة حياة. ثم حدّثت RFC 8767 المعنى: عند انتهاء TTL يجب استشارة المصدر مجدداً؛ وإذا تعذر تحديث البيانات بطريقة موثوقة، يمكن استخدام السجل كأنه غير منتهٍ ضمن شروط الآلية.

الترتيب مهم. Serve-stale لا يمنح resolver حق تجاهل TTL قصير بصورة دائمة. إذا أعاد القديم دائماً ثم حاول التحديث لاحقاً، تحوّل الاستثناء إلى قاعدة وسُحبت سلطة freshness من ناشر المنطقة.

TTL بقيمة صفر يبقى خاصاً بالمعاملة الحالية، فلا يُخزّن ولا يصبح احتياطياً. ويجب عدم خلط سقف TTL الوارد، الذي توصي RFC 8767 بأن يكون في حدود سبعة أيام، مع maximum stale بعد الانتهاء. الأول يضبط التخزين العادي، والثاني يضبط سلطة محلية طارئة.

أربع ساعات لقرار واحد

Client response timer يحدد المدة التي يستطيع فيها resolver انتظار fresh answer قبل أن يفقد العميل فائدة الرد. يقترح المثال نحو 1.8 ثانية. المهلة القصيرة قد تعتبر authority بطيئة غير متاحة؛ والطويلة قد تحمي freshness لكنها تصل بعد timeout التطبيق.

Query resolution timer يحد العمل التكراري كله، وغالباً ما يكون بين عشر وثلاثين ثانية في مناقشة RFC. يجب أن يستمر بعد إرسال stale. تلبية مهلة العميل لا تعني اكتمال إصلاح cache.

Failure recheck timer يمنع كل query جديدة من تكرار فشل معروف. يمكن لفشل حديث أن يتيح stale فوراً إلى أن يحين الفحص التالي. يوصي المثال بألا يكون التكرار أكثر من مرة كل ثلاثين ثانية، ويشير إلى حد خمس دقائق. وتلزم RFC 9520 بتخزين resolution failure من ثانية واحدة إلى خمس دقائق مع backoff للفشل المستمر.

Maximum stale timer يحدد بقاء object بعد expiry. يقترح المثال يوماً إلى ثلاثة أيام. المدة الأطول تحمي من outage ممتد، لكنها تمدد أيضاً عنواناً أو delegation أو نفياً قديماً، وتستهلك ذاكرة أكبر.

يحتاج التدقيق إلى وقت بدء كل timer ونتيجته. هل حاول node refresh جديداً أم اعتمد failure cache؟ هل استمر fetch بعد الرد؟ هل استُبدل object أم طُرد تحت ضغط cache أم عاش عبر restart؟ العلم الواحد لا يجيب.

ما الذي يعد تحديثاً موثوقاً؟

تنص RFC 8767 على أن response موثوقاً يحمل AA وRCODE من نوع NOERROR أو NXDOMAIN يجب أن يحدث الحالة. أما RCODEs الأخرى فعادةً تعد فشل refresh وتترك الحالة السابقة.

يحمي ذلك آخر جواب مفيد من SERVFAIL عابر. لكنه يعني أيضاً أن NXDOMAIN حديثاً وموثوقاً يستطيع إنهاء positive قديم. لا يملك resolver طريقة مؤكدة لمعرفة إن كان الحذف مقصوداً أو خطأ، ولا يملك حق نقض النفي الحالي.

REFUSED أكثر غموضاً: إيقاف متعمد، أو ACL خاطئة، أو خادم لم يعد authoritative. تسمح RFC للتنفيذ بأن يقرر هل يمنع REFUSED من كل السلطات استخدام stale. لذلك تُوثق الدلالة حسب المنتج والإصدار.

أما failure cache الذي تفرضه RFC 9520 فهو object آخر. يمنع outgoing queries المتطابقة مؤقتاً، لكنه لا يثبت وجود الاسم أو غيابه. يجب أن يعرض ledger الإجابة المنتهية والفشل الحي الذي يفسر عدم إعادة السؤال في كل مرة.

ثلاثون ثانية ليست عمراً جديداً من المنطقة

عند إعادة expired RR يجب وضع TTL أكبر من صفر، والقيمة الموصى بها ثلاثون ثانية. هذا ليس تجديداً من مالك المنطقة، بل مدة قصيرة يمنحها resolver لنسخته stale لدى downstream cache.

لذلك لا تكفي ملاحظة TTL=30. يلزم original TTL ووقت الإدخال وordinary expiry وstale age وreply TTL وسبب fallback. يمكن للرقم نفسه أن يمثل جواباً fresh يقترب من النهاية أو جواباً عمره ساعات.

تخصص RFC 8914 الرمز EDE 3 لـStale Answer والرمز 19 لـStale NXDOMAIN والرمز 7 لـSignature Expired. تضيف EDE تفسيراً لكنها لا تغير RCODE ولا تلزم stub برفض النتيجة أو عرض تحذير. وقد يزيل forwarder الخيار، لذا ينبغي تتبع وجوده في كل hop.

النفي القديم يملك أثراً تنفيذياً

يحافظ stale A على وجهة سابقة. ويحافظ stale NXDOMAIN على عدم الوجود. وقد يستمر NSEC أو NSEC3 قديم في تغطية DS أو TLSA أو اسم طوارئ نُشر حديثاً. يصل الرد سريعاً ومنظماً، لكن التغيير الأمني يظل محجوباً.

لهذا تحتاج eligibility إلى فئات. عنوان محتوى، وتحكم شهادة، وdelegation، وrevocation، واسم استعادة ليست لها الكلفة نفسها. إذا لم يوفر المنتج دقة كافية، فالنطاق الأصغر أكثر أماناً من global flag.

وتفصل counters بين positive وNXDOMAIN وNODATA. رقم stale إجمالي لا يقول هل حُفظ الوصول أم مُنع وصول جديد.

DNSSEC لا يتبع ساعة التخزين

تطلب RFC 4035 أن يقع current time لدى validator بين inception وexpiration في RRSIG. بقاء RRset في cache لا يمد هذه الفترة. قد تكون البيانات stale مع signature ما زالت valid، ثم تصبح stale مع signature expired.

يجب تسجيل حالات منفصلة: stale-secure، وstale-signature-expired، وcached validation failure، وأي insecure local exception. عبارة «DNSSEC enabled» لا تصف النتيجة.

يمكن لمهاجم يبقي authority غير متاحة أن يطيل binding قديماً. تناقش RFC 8767 عنواناً خرج من سيطرة صاحبه وخطر domain-validated certificates. Serve-stale لا ينشئ العنوان المهجور، لكنه يختار مدة فعله أثناء الفشل.

BIND وUnbound لا ينفذان مجرد اسم مشترك

تفصل وثائق BIND الحالية بين retention والرد وreply TTL وmaximum age وrefresh وrndc serve-stale. توثق ثلاثين ثانية للرد ويوماً للحد الأقصى عند التفعيل. Client timeout معطل افتراضياً، والإصدار الموثق لا يدعم عند التفعيل إلا صفر، أي immediate response.

يفصل Unbound عبر serve-expired-* بين العمر وreply TTL والانتظار وreset بعد الفشل. وتفرق وثائقه بين immediate mode وrefresh-first mode. الإصدار والسلوك الملاحظ هما العقد الحقيقي.

تضم canary matrix authority سريعة وبطيئة وغير متاحة، وSERVFAIL وREFUSED وNXDOMAIN، وpositive/negative، وRRSIG سارية ومنتهية، وTTL صفر، وضغط cache، وrestart، وruntime override. الدليل يمتد من cache وupstream packet إلى response وEDE وrefresh اللاحق وreplacement ونتيجة التطبيق.

المصادر