الخلاصة

  • تتيح RFC 8767 للمحلّل التكراري أن يعيد بيانات مخبأة انتهت صلاحيتها إذا حاول بجدية تحديثها من المصدر الموثوق وفشل؛ القرار استثناء محلي للاستمرارية وليس تمديداً لحداثة أعلنتها المنطقة.
  • لا يمكن مراجعة القرار من دون فصل TTL الأصلي، وعمر البيانات بعد الانتهاء، والحد الأقصى، وTTL الذي أُعيد للعميل، وصلاحية DNSSEC، ونوع الفشل، ومجموعة المحلّلات المتأثرة، ودليل التعافي.

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

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

تصف RFC 8767 هذه الآلية باسم Serve Stale. عند انقضاء TTL ينبغي الرجوع إلى مصدر المعلومات. وإذا تعذر التحديث الموثوق، يجوز للمحلّل، ضمن حدود، أن يستخدم البيانات المحتفظ بها كما لو أنها لم تنته. عبارة «كما لو» لا تجعلها حديثة.

بعد TTL ينتقل أساس السلطة

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

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

لذلك يجب أن يسجل الدليل وقت إدخال البيانات، وTTL الأصلي، ووقت الانقضاء المحسوب، والعمر الحالي بعد الانتهاء، ونهاية نافذة stale، وTTL الموجود في الرد. ظهور «30 ثانية» عند العميل لا يعني أن الناشر أكد السجل قبل ثلاثين ثانية؛ غالباً هو فاصل قصير أضافه المحلّل إلى بيانات أقدم بكثير.

إذا لم يظهر هذا الانتقال في السجل التشغيلي، نُسب قرار الاستمرارية إلى ناشر لم يتخذه. التوافر لا ينبغي أن يتحول إلى تمديد مجهول لسياسة المنطقة.

أربع ساعات لا مفتاح واحد

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

مؤقت استجابة العميل يحدد مقدار الانتظار قبل التفكير في الإجابة القديمة؛ يقترح المثال 1.8 ثانية. مؤقت حل الاستعلام يحد مجموع عمل التحليل التكراري، وغالباً ما يكون بين عشر وثلاثين ثانية في النقاش. مؤقت إعادة الفحص يمنع تكرار المحاولة بسرعة تجاه مصدر فاشل، ويقترح المثال ثلاثين ثانية. أما الحد الأقصى لـ stale فيمنع الاستخدام بعد عمر مطلق.

عبارة «Serve Stale مفعّل» لا تكشف هذه المفاضلات. انتظار قصير يحسن تجربة العميل لكنه قد يفضّل القديم على خادم بطيء فقط. إعادة فحص متباعدة تخفف الضغط أثناء الهجوم لكنها تؤخر اكتشاف العودة. الاحتفاظ الطويل يعبر انقطاعاً كبيراً، لكنه يطيل عناوين مهجورة وحالات أمان قديمة.

ينبغي أن تسبق الإجابة محاولة حديثة وحسنة النية للتحديث. ليست الآلية إذناً بأن يجيب المحلّل دائماً من الماضي ثم يسأل لاحقاً. وحتى بعد إرسال الإجابة القديمة، ينبغي أن يستمر مسار الحل إلى حد مؤقته. الاستثناء يمنح وقتاً للتعافي، ولا يلغي واجب التعافي.

فشل التحديث يحتاج وصفاً محدداً

تعدّ RFC 8767 جواباً موثوقاً يحمل NOERROR أو NXDOMAIN مع AA تحديثاً للبيانات. أهمية NXDOMAIN واضحة: إذا حذف الناشر اسماً عمداً، لا يستطيع المحلّل إبقاء الجواب الإيجابي القديم لأن الاستمرارية تبدو أفضل. لا توجد وسيلة عامة تميز الحذف المقصود من الخطأ التحريري.

كذلك لا تتساوى المهلة، وانقطاع الشبكة، وSERVFAIL، وREFUSED، والرسالة المشوهة، وفشل DNSSEC، والتفويض المعيب. تشير كل حالة إلى جهة معالجة مختلفة. وتقيد RFC 2308 تخزين مؤشر الخادم الفاشل أو غير القابل للوصول بخمس دقائق.

يجب أن يتضمن السجل كل خادم موثوق جُرّب، وعنوانه، والنقل، والتوقيت، وRCODE، وAA، ونتيجة التحقق، وخطأ الشبكة، ومحاولة تحديث التفويض. كما يلزم سياق RD وCD وDO، ومفتاح الذاكرة، والتمييز بين جواب إيجابي وNODATA وNXDOMAIN.

قد يجيب محلّلان عن السؤال نفسه بطريقتين مختلفتين بسبب اختلاف التاريخ والمسار والسياسة. نسبة نجاح مجمعة لا تظهر أي مجموعة مستخدمين تعيش على البيانات الحالية وأيها تعيش على الاستثناء.

TTL قصير في الرد لا يجدد البيانات

عند إرسال سجلات منتهية، يجب أن يكون TTL في الرد أكبر من الصفر، وتوصي RFC 8767 بثلاثين ثانية. تسبب الصفر في مشكلات توافق، وقد تؤدي القيم القصيرة جداً إلى سيل من المحاولات أثناء العطل. القيمة الصغيرة تضبط الطلب في الطبقات اللاحقة.

لكنها لا تصفّر العمر الحقيقي. إذا خزّن forwarder الإجابة، سيرى العميل التالي المدة القصيرة ولن يرى متى انتهت النسخة الأصلية. يجب ربط الإجابة بهوية المحلّل الذي منح الاستثناء، ووقت التخزين، وآخر محاولة تحديث.

توفر RFC 8914 إشارات EDE إضافية. الرمز 3 يعني Stale Answer، والرمز 19 يميز Stale NXDOMAIN Answer، والرمز 22 يعني No Reachable Authority. ويمكن أن ترافق هذه الإشارات NOERROR.

غير أن EDE سياق تشخيصي. لا يغير معالجة RCODE، وقد يحذفه وسيط أو ينشئ إشارة جديدة. ومن دون معاملة أو قناة محمية لا يكون موثقاً. رؤية الرمز 3 تثبت أن المرسل وصف جوابه بأنه قديم؛ لا تثبت وحدها عمر الذاكرة ولا المحاولات التي نفذها.

لـ DNSSEC موعد انتهاء مستقل

نجاح تحقق RRset عند دخوله الذاكرة لا يضمن نجاحه عند إعادة استخدامه. وقت بدء RRSIG وانتهائه مستقلان عن TTL وعن نافذة stale. وكلما طال الاحتفاظ زادت فرصة تجاوز التوقيع لحده الزمني.

ينبغي أن يعكس بت AD حالة التحقق الحالية، لا ذكرى تحقق سابق. يلزم الاحتفاظ بأوقات RRSIG، ووقت التحقق، وحالة مرساة الثقة، وسياق CD وDO. وحتى العنوان القديم الذي ما زال يحمل توقيعاً صحيحاً قد يشير إلى بنية لم يعد الناشر يسيطر عليها؛ أصالة السجل وسلامة الوجهة الآن حكمان مختلفان.

وللبيانات السلبية أثر خاص. قد يحجب NXDOMAIN قديم اسماً أضيف حديثاً. وقد تؤخر أدلة NSEC أو NSEC3 القديمة استخدام DS أو TLSA جديد. تسمح RFC 8198 بتوليد أجوبة من أدلة سلبية موثقة ما زالت مؤهلة في الذاكرة. أما Serve Stale فيسأل عن استخدامها بعد انقضاء الأهلية العادية وفشل التحديث.

المصادر