الخلاصة

  • يتيح RFC 8005 لسجل HIP أن يحمل الهوية العامة HI ووسمها HIT وأسماء اختيارية لخوادم الالتقاء؛ وهذه بيانات اكتشاف لا اختبار حياة.
  • يثبت DNSSEC بيانات DNS داخل سلسلة التحقق، وتحدد TTL مدة إعادة استخدام النسخة المخبأة. ولا يطّلع أي منهما على تسجيل HIT والعنوان الحالي داخل RVS أو على استعمال المفتاح الخاص.
  • يحتاج حكم الوصول إلى ربط السجل المختار بعنوان RVS وتسجيله الحالي وترحيل I1 والمصادقة القائمة على HI واكتمال ارتباط HIP ونتيجة التطبيق.

حقيقة قديمة داخل مؤقت لم ينته

عند التاسعة، يسترجع محلل DNS سجل HIP لعقدة متنقلة. يحتوي الجواب HI المتوقعة وHIT واسم RVS، وتنجح سلسلة DNSSEC، وتبقى ساعة كاملة من TTL. تلخص لوحة الضمان ذلك بعبارة «الهوية موثقة والعقدة قابلة للوصول».

بعد اثنتي عشرة دقيقة تنتقل العقدة إلى شبكة جديدة، ولا يصل تحديث عنوانها إلى RVS. لا يصبح DNS كاذباً: ما زال اسم نقطة الالتقاء المنشور صحيحاً والتوقيع صالحاً والنسخة ضمن مدتها. عند إرسال I1، يجد RVS عنواناً قديماً ويرحل الحزمة إلى مكان غادرته العقدة.

هذا مشهد تحليلي مفترض، لا تقرير عن منتج أو حادث. المشكلة ليست في الجواب، بل في السؤال الذي حمّلته اللوحة له. أثبت الجواب ما نُشر، ولم يزعم أنه شاهد الموضع الحالي.

المادة العامة لا تثبت حضور المفتاح الخاص

عرّف RFC 5205 سجل النوع 55 سنة 2008 بوصفه Experimental، ثم حل محله RFC 8005 على Standards Track سنة 2016. يستطيع السجل نشر الجزء العام من هوية المضيف وHIT المشتق منها وأسماء RVS.

يساعد الحصول على HI قبل التبادل في تجنب اتصال انتهازي بلا معرفة سابقة بهوية المستجيب. ويمنح HIT اسماً مضغوطاً للهوية. لكن جواب DNS لا يحتوي المفتاح الخاص ولا توقيعاً حياً صادراً عنه وقت الاستعلام.

لهذا ينص RFC 8005 على ألا يصادق طرف HIP على النظير بالاعتماد فقط على HIT المسترجع من DNS، بل يستخدم مصادقة قائمة على HI. العثور على معرّف منشور واستعمال المفتاح المقابل في تبادل حالي واقعتان منفصلتان.

إذا كتبت قاعدة الأصول authenticated=true فور حل HIT، فهي تحذف الخطوة التي يفترض أن تولد الدليل. قد يكون المفتاح غير متاح، بينما تبقى مادته العامة منشورة على نحو صحيح.

DNSSEC يحمي قولاً محدوداً

يسمح العبث بسجل غير محمي باستبدال مادة المفتاح أو إعادة توجيه I1. لذلك يوصي RFC 8005 بقناة توفر سلامة بيانات السجل وأصالتها، ويقدم DNSSEC لهذه الوظيفة.

لكن النص يحدد السلطة بوضوح. الحماية تخص القناة بين خادم DNS الذي ينشر المنطقة وعقدة HIP. وهي لا تثبت أن الجهة الناشرة موثوقة. ولا يجوز تفسير RRSIG لمجموعة HIP بوصفه شهادة تربط HI أو HIT باسم المالك.

إذن نتيجة secure قوية ضمن موضوعها: بايتات، وسلسلة تحقق، ومرساة ثقة، ووقت، وسياسة. لا ترى مخزن المفتاح الخاص ولا جدول RVS ولا طريق IP ولا عملية التطبيق.

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

TTL ساعة للذاكرة المخبأة لا للخدمة

يوضح RFC 8005 أنه عند تجاوز الزمن منذ الاسترجاع قيمة TTL يجب اعتبار السجل غير صالح وحذفه، وإجراء استعلام جديد إذا بقي ضرورياً لبدء الاتصال.

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

حتى الاستعلام الجديد قد يعيد السجل نفسه مع تحقق صحيح فيما يظل تسجيل RVS قديماً. تجديد دليل طبقة لا يجدد حالة طبقة أخرى.

تغري سهولة حساب TTL أنظمة الأتمتة بتجنب اختبار التشغيل. النتيجة الصحيحة لـ cacheAge < ttl هي السماح باستخدام البيانات، وليست endpointLive=true.

اسم RVS وتسجيله يعيشان في سلطتين

تنشر العقدة المتنقلة أسماء RVS المستقرة نسبياً في DNS، ثم تحدث خادم الالتقاء بصورة منفصلة بعناوينها الحالية. ويصف RFC 8004 كيف يفحص RVS تسجيلاته الجارية قبل ترحيل I1.

يمكن أن يحل الاسم بصورة صحيحة بينما لا يوجد تسجيل للـ HIT. وقد يكون الخادم متاحاً وجدوله يحمل عنواناً قديماً. وقد ينجح الترحيل نفسه من دون أن تستقبل العقدة الحزمة.

السلسلة الصادقة هي:

سجل منشور → DNSSEC متحقق → TTL جارٍ → RVS مختار → تسجيل حالي → I1 مرحل → HI مصادق عليها → ارتباط مكتمل → نتيجة مرصودة.

تعبر كل وصلة حدود نظام. غياب الوصل التالي يعني «مجهول»، لا نسخ اللون الأخضر من السابق.

تعدد السجلات يجعل الاقتران جزءاً من الدليل

قد يرتبط أكثر من سجل HIP باسم واحد، ويترك RFC 8005 اختيار أحدها للتطبيق. وقد تختلف معلومات RVS. وعند تعدد الخيارات يجب التأكد من أن RVS المستخدم مرتبط بالـ HI المستخدمة.

إن استخراج كل هويات HI في قائمة وكل أسماء RVS في قائمة أخرى قد يصنع أزواجاً لم تنشرها المنطقة قط. يظهر الخطر عند تدوير المفاتيح، حين تعيش سجلات قديمة وجديدة معاً.

يجب أن يحتفظ الإيصال بكل سجل كوحدة: الخوارزمية وHI وHIT وRVS وTTL وبصمة الجواب وسبب الاختيار. وإلا قد ننسب فشل توليفة اخترعها مخزن محلي إلى البروتوكول.

إيصال الوصول الفعلي

يبدأ السجل التشغيلي باسم الاستعلام ونوعه والمحلل والخادم السلطوي والوقت وبصمة الحزمة. ثم يحفظ مجموعة RR وعلاقاتها ونتيجة DNSSEC ومرساة الثقة وسياسة التحقق وعمر الذاكرة وTTL وإعادة الاستعلام. ولعناوين A وAAAA الخاصة بـ RVS أدلتها المستقلة.

بعد ذلك تأتي هوية التسجيل والـ HIT والعناوين والتحديث والانتهاء والإلغاء وجيل الإعداد. وتربط ملاحظات إرسال I1 ووصوله إلى RVS والبحث والترحيل والاستلام. وتحفظ مصادقة HI وحالة الطرفين، ثم مسار الحمولة ونتيجة التطبيق على حدة.

أضاف RFC 8005 دعم ECDSA ووضح إعادة الاستعلام وتعدد السجلات وصيغة عدة خوادم. نشر المواصفة لا يثبت هجرة برنامج عامل. النسخة والبناء والإعداد والحزم هي أدلة التنفيذ.

لا تنقص قيمة اكتشاف HIP حين نحافظ على حدوده. كانت اللوحة الدقيقة في المثال ستقول: «السجل آمن؛ TTL جارٍ؛ تسجيل RVS غير مؤكد؛ الوصول مجهول». تلك العبارة تشير إلى التحديث المفقود بدلاً من اتهام DNS الذي أدى عمله.

المصادر