الخلاصة

  • ينقل DNS Push دليل حداثة RRset من عدّ TTL إلى واجب تسليم تغييرات، ولا يحق للعميل وقف التقادم إلا ما دام الاشتراك الموافق مقبولاً في جلسة DSO بعينها.
  • إغلاق الاتصال ينهي جميع الاشتراكات. استئناف TLS يخفض كلفة المصافحة، لكنه يبدأ بلا حالة DNS Push؛ يجب إعادة كل NAME وTYPE وCLASS والحصول على حالة أولية جديدة.
  • إثبات «الحالة الحالية» يربط الاكتشاف وهوية TLS وعمر DSO واستجابة SUBSCRIBE ورسائل الإضافة والحذف وساعة الذاكرة وفحص الخدمة الحقيقي.

عاد الضوء الأخضر وانتهى الدين

لنفترض حالة توضيحية لا حادثة مسجلة. يشترك عميل في RRset من نوع SRV ويتلقى في PUSH أولي وجهة خدمية ذات TTL مقداره 120 ثانية. يبقى الاشتراك حياً عشر دقائق، لذلك لا تنقص القيمة المخزنة. ثم يسحب المشغل الوجهة، وفي اللحظة نفسها تقريباً يقطع جهاز وسيط الاتصال الطويل.

يستأنف العميل TLS بسرعة وتعود لوحة النقل إلى اللون الأخضر. لكن الجلسة الجديدة لم تقبل SUBSCRIBE جديداً. انتهى واجب الخادم القديم بإرسال رسالة الحذف عندما انتهت جلسة DSO. إذا استمر العميل في تجميد TTL فقد حوّل إعلاناً مدته دقيقتان إلى ادعاء محلي بلا نهاية.

يفصل RFC 8765 بين الطبقات بوضوح. نهاية اتصال TLS تنهي DSO، واستئناف TLS لا يعيد حالة الاشتراك. الذي يعود هو اختصار مسار التشفير، لا تعهد التطبيق بتسليم التغيير. لذلك لا تصلح كلمة «متصل» وحدها لوصف السلطة التي يحملها النظام.

لماذا تتوقف ساعة TTL

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

يستبدل DNS Push هذه الاستعلامات بحالة. يطلب العميل اشتراكاً لاسم ونوع وفئة محددة، ويقبل الخادم كل اشتراك أو يرفضه منفرداً. إذا كانت مجموعة الإجابة غير فارغة عند القبول، يرسل الخادم PUSH أولياً مباشرة؛ ثم تأتي التغييرات اللاحقة عبر مسار TLS/TCP المرتب.

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

تنهي UNSUBSCRIBE اشتراكاً واحداً، وينهي إغلاق DSO الجميع. عندئذ يعود تقادم TTL من القيمة المخزنة، ويحذف السجل عند الصفر. يجب أن يكون وقت إيقاف الساعة ووقت تشغيلها حدثين قابلين للتدقيق.

الاكتشاف والحماية والاشتراك ثلاث حجج مختلفة

يبدأ العميل عادةً مع المحلل التكراري المضبوط عبر DNS over TLS على المنفذ 853. قد يقبل المحلل الاشتراك ويحافظ على اشتراك أعلى منه ثم يمرر النتائج. وإذا تعذر ذلك يمكن أن يظهر مسار _dns-push-tls._tcp.<zone>. يجب حفظ جواب الاكتشاف وTTL ونتيجة DNSSEC والمحلل ونقطة الرصد.

يتطلب البروتوكول Strict Privacy، لكن TLS يحمي الطرف الذي عُرف من مدخلات الاكتشاف. إذا زُوِّر SRV فقد ينشئ العميل قناة صحيحة تشفيرياً إلى هدف خاطئ. لذلك تبقى target وSNI والشهادة أو TLSA وعنوان peer حقولاً مستقلة.

تنشأ DSO بواسطة Keepalive أو طلب Push نفسه. يحمل SUBSCRIBE MESSAGE ID غير صفري وNAME وTYPE وCLASS واحدة. تحدد استجابة RCODE وجود الاشتراك. قد يدعم الخادم DSO ولا يدعم Push، أو لا يكون مخولاً للاسم، أو يرفض الحالة لضيق السعة. الاتصال ليس قبولاً.

رسائل تغيير بلا مؤشر دائم

PUSH رسالة أحادية الاتجاه من الخادم، MESSAGE ID فيها صفر ولا يرد العميل عليها. قيمة TTL من صفر إلى 0x7FFFFFFF تضيف RR؛ 0xFFFFFFFF تحذف سجلاً منفرداً؛ و0xFFFFFFFE تنفذ حذفاً جماعياً مع RDATA فارغة ونطاق يحدده TYPE وCLASS.

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

ترتيب TCP يخص اتصالاً واحداً. صفر MESSAGE ID ليس رقم تسلسل، ويمكن لرسالة واحدة جمع تغييرات اشتراكات متعددة. لا يوجد مؤشر يثبت أن الاتصال الجديد بدأ بعد آخر تغيير في القديم من دون فجوة. الاستعادة الصحيحة تعيد الاشتراك وتأخذ الحالة الأولية من جديد.

ولا يعني نجاح SUBSCRIBE أن RRset غير فارغ. يلزم PUSH أولي عندما تكون الإجابة غير فارغة فقط. قد يكون الصمت بعد القبول حالة صحيحة لمجموعة فارغة، ولهذا يجب فصل دليل القبول عن دليل المحتوى.

حدود Keepalive وRECONFIRM

يحافظ Keepalive على حالة NAT وfirewall ويختبر وصول الطرفين. الاشتراك الفعال يمنع اعتبار الجلسة خاملة حتى مع غياب التغييرات. لكنه لا يثبت سلامة اشتراك upstream أو اكتمال الحذف أو صحة تطبيق الذاكرة أو عمل الخدمة المشار إليها.

في سياق Discovery Proxy يمكن لـ RECONFIRM أن يطلب استعلامات multicast جديدة لسجل مشتبه فيه، ثم يؤدي اكتشاف الزوال إلى PUSH حذف. أما في أنواع الخوادم الأخرى فالأثر غير محدد، وقد يعود NOERROR من دون عمل إضافي. لا يجوز عرضه على أنه شهادة صحة عامة.

استئناف TLS لا يورّث حالة التطبيق

يسجل مسار التعافي نهاية DSO القديمة وعودة تقادم TTL، ثم اتصال TCP/TLS جديداً مع تمييز full أو resumed، ثم DSO جديدة، وSUBSCRIBE لكل RRset مطلوب، وRCODE، وحالة أولية جديدة عند عدم الفراغ. بعد اكتمال هذه السلسلة فقط يمكن إيقاف الساعة ثانية.

يجوز إرسال SUBSCRIBE في TLS early data، لكن 0-RTT لا يضمن عدم replay بين الاتصالات ولا يمنح السرية الأمامية نفسها. قد تنشئ النسخة المكررة حالة مؤقتة أخرى. إرسال الطلب مبكراً ليس إيصال تنفيذ مرة واحدة؛ المرجع هو الاستجابة المقبولة في الجلسة الفعلية.

عند فشل Push يتحول العميل إلى polling بصورة معلنة. يوصي RFC 8765 بألا يقل الفاصل لنفس NAME/TYPE/CLASS عن الأصغر بين 900 ثانية وTTL مضافاً إليه ثانيتان، مع محاولة Push قبل كل استطلاع. هذا يضبط الحمل ولا يضمن حداثة فورية.

سجل يبرر كلمة «حالي»

يحفظ السجل سؤال الاكتشاف وجوابه وTTL وDNSSEC وvantage؛ ثم target وSNI وpeer ونتيجة الشهادة أو TLSA ونوع المصافحة. ويحفظ بدء DSO ونهايتها وKeepalive وinactivity وRetry Delay.

لكل اشتراك: MESSAGE ID وNAME وTYPE وCLASS والطلب وRCODE ووقت القبول. ولكل PUSH: ترتيب داخل المسار ونوع الإضافة أو الحذف وRR وTTL المخزن والاشتراك المطابق وقرار الذاكرة. ويُفصل UNSUBSCRIBE وclose_notify وFIN وtimeout وreset والخطأ القاتل.

وأخيراً يختبر استعلام مباشر ما تنشره السلطة الآن، ويختبر probe مستقل ما إذا كانت الخدمة تعمل. «DNS حالي» و«الخدمة متاحة» عبارتان مختلفتان.

حد أدنى مشترك وقرار محلي

تظهر مبادئ Heng Lu في توزيع السلطة. المواصفة الأولية الدنيا توحد OPCODE وTLV والأدوار وهوية الاشتراك والتوقيت والأمان والنهاية. ميزانية الاشتراكات والاحتفاظ والواجهة وfallback وrollback تبقى قرارات مستقبلية محلية لدى من يتحمل التكلفة.

لا يثبت RFC أو codepoint في IANA التبني. تثبته تطبيقات متوافقة واختبارات انقطاع وآثار على السلك. وأولوية running code لا تعني أن كل ما نفذه البرنامج مشروع؛ إذا جمد TTL بعد زوال الاشتراك، فالنتيجة المنفذة هي دليل التجاوز.

المصادر