الخلاصة

  • القيمة في طلب RFC 9664 هي مدة مرغوبة؛ أما LEASE وKEY-LEASE في الاستجابة الناجحة فهما المدة التي منحها الخادم الموثوق فعلاً.
  • انتهاء المهلة يوقف النشر الموثوق، لكنه لا يثبت سلامة الخدمة أو اتساق جميع الخوادم أو زوال إجابة ما زال TTL الخاص بها قائماً في الذاكرة المخبأة.

لنفترض تسجيلاً توضيحياً. يطلب جهاز نشر سجلات خدمته لمدة ثلاثين دقيقة. تنجح مصادقة DNS UPDATE وتتحقق شروط RFC 2136، لكن الخادم يعيد استجابة ناجحة تمنح أربع ساعات. بعد عشرين دقيقة ينطفئ الجهاز من دون حذف صريح ومن دون تجديد.

يمكن أن تظل إجابة DNS صحيحة وفقاً للمهلة الممنوحة، مع أن الوجهة لم تعد تقدم أي خدمة. هذا ليس حادثاً تاريخياً ولا قيمة افتراضية لمنتج. إنه يوضح قاعدة RFC 9664: يعبّر الطلب عن الرغبة، بينما تقرر الاستجابة المدة الفعلية، أقصر كانت أو مساوية أو أطول.

قبول التحديث ليس شهادة حياة

لا تستبدل Update Lease بروتوكول التحديث. إنها خيار EDNS(0) داخل رسالة DNS UPDATE عادية. تبقى أقسام Zone وPrerequisite وUpdate وAdditional Data، وتظل العملية ذرية: إما أن تتحقق الشروط كلها ويقبل التغيير، أو يرفض كله.

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

تستطيع TSIG أو SIG(0) مصادقة المعاملة وهوية المرسل وفق سياسة المفتاح. لكنها لا ترى عملية التطبيق أو منفذ الاستماع أو المسار أو نتيجة معاملة المستخدم. التسجيل الموثق لخدمة متوقفة يظل تسجيلاً لخدمة متوقفة.

لذلك يجب حفظ أقسام الرسالة كاملة، واسم مفتاح TSIG أو هوية SIG(0)، وقرار السياسة، وطول الخيار، والقيم المطلوبة، وRCODE، والقيم المعادة. عبارة «نجحت المهلة» لا تكشف من منح أي زمن.

أربعة بايتات أم ثمانية: الخدمة ليست حجز الاسم

تحمل الصيغة ذات الأربعة بايتات قيمة LEASE واحدة من 32 بت، وتطبق على جميع RR في قسم Update بما فيها KEY. تضيف صيغة الثمانية بايتات KEY-LEASE، فتستخدم السجلات العادية المدة الأولى وتستخدم KEY المدة الثانية.

يستفيد Service Registration Protocol في RFC 9665 من هذا الفصل. قد تنتهي سجلات اكتشاف الخدمة، بينما تبقى KEY لتحجز الاسم مدة أطول لصاحب المفتاح نفسه. ما يبقى هو حق المطالبة بالاسم، لا خدمة حية.

قد تلغي التوافقية هذا الفصل. الخادم الذي يتلقى أربعة بايتات يطبق القيمة على النوعين. والطالب الذي أرسل ثمانية وتلقى أربعة يجب أن يفعل الشيء نفسه. لا تثبت النية المحلية بقاء «مهلة قصيرة للخدمة ومهلة طويلة للاسم»؛ تثبتها الاستجابة الفعلية فقط.

أما السجلات المحذوفة صراحة في التحديث فتزال بصورة دائمة. المهلة لا تجعل الحذف توقفاً مؤقتاً.

الاستجابة هي التي تبدأ الساعة التشغيلية

على الخادم الداعم أن يعيد الخيار في كل استجابة ناجحة لطلب احتواه. يحسب الطالب موعد التجديد عند 80% من المدة الممنوحة، مضافاً إليه مقدار عشوائي بين 0% و5%. يخفف ذلك اندفاع أجهزة كثيرة في اللحظة نفسها ويترك قرابة 15% إلى 20% لإعادة المحاولة.

حساب الموعد ليس دليلاً على التمديد. يلزم تسجيل المقدار العشوائي ووقت الإرسال والمحاولات والاستجابة الموثقة والمنحة الجديدة.

إذا غاب الخيار عن استجابة ناجحة، فذلك مؤشر على أن الخادم لا يدعم Update Lease. توصي RFC بأن يواصل الطالب التجديد كما لو أن القيمة المطلوبة قد أعيدت. هذه ملاءمة من جانب العميل، وليست برهاناً على أن الخادم سيجمع السجل عند نهاية الزمن. يجب وسم الحالة: «تجديد توافقي مستمر، انتهاء الخادم غير مثبت».

يفصل المعيار أيضاً بين Registration وRefresh. الأولى تضيف معلومات يعتقد أنها غير موجودة، والثانية تمدد حالة قائمة من دون تغيير المحتوى. إذا فقد الخادم حالته بعد إعادة تشغيل، فقد يعيد Refresh إضافة السجلات. عندئذ يتغير محتوى المنطقة ويجب تحديث serial. أما تمديد لا يغير المحتوى فلا ينبغي أن يزيده.

انتهت لدى الخادم، وبقيت في الذاكرة المخبأة

عند انقضاء المهلة بلا تجديد، يجب ألا يعيد الخادم RR في الإجابات. يجوز له حذف البيانات المخزنة، لكنه غير ملزم بذلك. حالة الاستعلام وحالة التخزين دليلان مختلفان.

تدير TTL زمناً آخر. قد يكون محلل تكراري قد حصل على الإجابة قبل الانقضاء بقليل، فيعيد استخدامها حتى نفاد TTL المتبقي. لا يقدر الخادم الموثوق على استرجاع النسخة. وبالمقابل، لا تنهي TTL قصيرة تسجيلاً ما زال الخادم يحتفظ به لساعات.

يجب فصل موعد المنحة، وجدول التجديد وإعادة الإرسال، وانتقال التغيير عبر journal والتوقيع والخوادم الثانوية، وTTL الذي رآه كل مراقب. وإذا كان المسجل hidden primary، فلا تثبت طاولة المهلة الداخلية ما تجيبه كل سلطة عامة أو كل موقع anycast.

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

الحدود سياسة محلية وليست حقاً للطالب

المهلة الطويلة جداً تشبه عدم وجود مهلة؛ والقصيرة جداً تزيد الحمل وقد تزيل سجلاً سليماً عند أول تأخير. توصي RFC 9664 بحد أقصى افتراضي 24 ساعة لـLEASE وسبعة أيام لـKEY-LEASE، وبحد أدنى افتراضي لا يقل عن 30 ثانية، مع الإشارة إلى أن ساعة أو أكثر أنسب غالباً. ويمكن للمشغل تغيير القيم.

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

المصادر