الخلاصة

  • يستخدم DET البادئة 2001:30::/28 ويأخذ شكل عنوان IPv6 صالح لكنه غير قابل للتوجيه؛ يحمل الشكل تسلسلاً هرمياً للهوية، لا وجهة للحزم ولا إحداثيات.
  • يضم سجل HHIT من النوع 67 بيانات التسجيل والشهادة القانونية، فيما يحمل BRID من النوع 68 معلومات Broadcast RID الثابتة والاعتمادات.
  • يتحقق DNSSEC من أصل جواب DNS وسلامته، لكنه لا يثبت الحضور المادي أو السيطرة الحالية على المفتاح أو حق الوصول إلى البيانات الخاصة أو سلطة الطيران.

لم يرَ المحلل طائرة ولم يستقبل جهاز الراديو رسالة. مع ذلك تبدو الشاشة حاسمة: ظهر سجل HHIT، وظهر BRID، ونجحت سلسلة DNSSEC، وصحت شهادة التسجيل والاعتمادات. تقترح القاعدة الآلية نقل الحالة مباشرة إلى «تم تحديد موقع الطائرة».

البيانات صحيحة، لكن الاستنتاج يتجاوزها.

تحدد RFC 9886 طريقة تسجيل DRIP Entity Tags، أو DETs، والبحث عنها في DNS. يستطيع المراقب اكتشاف الهرمية والمفتاح العام والشهادات التي تدعم التسجيل. أما خادم الأسماء فلا يراقب السماء. نجاح الاستعلام يجيب عن واقعة في السجل، ولا يقيس واقعة في المكان.

ينشأ الالتباس من هيئة المعرّف. خصصت RFC 9374 البادئة 2001:30::/28 لـDET ووصفت HHIT بأنه عنوان IPv6 صالح لكنه غير قابل للتوجيه. يسمح ذلك بإعادة استخدام بنية 128 بت ونظام الأسماء العكسية. لا ينشئ مساراً إلى الطائرة ولا يخزن خط العرض أو الطول.

يقع النطاق العكسي تحت 3.0.0.1.0.0.2.ip6.arpa. ويُحوَّل كل DET بعكس أنصاف البايتات كما في IPv6، لكن السؤال يطلب HHIT أو BRID لا سجل PTR المعتاد. ما يعود هو وصف عام للمعرّف، لا نقطة على خريطة.

سجلان وحدّان مختلفان للإثبات

يجب أن يُحل كل DET إلى HHIT، ويجب وجود BRID أيضاً عند استخدام UAS Remote ID. لا يعني اجتماع السجلين أنهما يوثقان الحدث نفسه.

يحتوي HHIT RR Type 67 نوع الكيان واختصار الهرمية وشهادة التسجيل القانونية. تحمل الشهادة المفتاح العام للكيان موقّعاً من المسجّل أو مرساة ثقة أخرى. تستطيع السلسلة المتحققة دعم الادعاء بأن المعرّف المشتق من المفتاح سُجل في تلك الهرمية. وقد تحمل الشهادة URI يقود إلى مورد معلومات خاصة.

أما BRID RR Type 68 فيحتفظ بالمواد الثابتة المرتبطة بـBroadcast RID. وظيفته الأساسية نشر Broadcast Endorsements أصدرها المسجّل بعد نجاح التسجيل. يمكن أن يعوض مادة ثابتة لم تصل عبر الراديو أو يساعد في المقارنة.

وجود BRID في DNS لا يثبت أن مستقبلاً ميدانياً سمع الاعتماد أثناء العملية الحالية. DNS قناة للسجل العام؛ وBroadcast RID مشاهدة لاسلكية محلية لها مستقبل ومدى ووقت خاص. تشابه الاسم لا يوحّد الحدثين.

توضح RFC 9434 أن DET الذي يعلنه صاحبه لا يكفي لإثبات هوية المرسل. كما أن إعادة مادة موقعة قد تكون replay. إثبات الحيازة الحالية للمفتاح يحتاج بيانات جديدة متغيرة يمكن للمراقب فحصها من الخارج؛ مثال ذلك رسالة مكان وزمان موقعة تتوافق مع الطائرة المرئية في اللحظة نفسها. وحتى عندئذ يبقى توثيق الرسالة مختلفاً عن القياس المستقل للموقع.

يؤمّن DNSSEC الجواب لا السماء

تفرض RFC 9886 استخدام DNSSEC على كيانات apex ذات شهادة التسجيل الموقعة ذاتياً وتوصي به لغيرها. من دونه قد تتيح الأجوبة المزورة حجب الخدمة أو replay أو انتحال الطائرات واستنساخها أو اختطاف تسجيل DET أو حقن بيانات فاسدة أو إفساد علاقات الثقة. وعلى العميل الذي لا يستخدم DNSSEC أن يسير في شجرة شهادات HHIT، مع تحقق منفصل من اعتمادات BRID.

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

قد توقع المنطقة بيان تسجيل غير دقيق توقيعاً صحيحاً، وقد يصبح سجل أصيل قديماً بالنسبة إلى القرار. حالة secure حكم محدد على DNS، لا شهادة مطلقة على العالم الموصوف.

مؤشر المعلومات الخاصة ليس تصريح دخول

يمكن للسجل العام أن يشير إلى خدمة خاصة. لكن RFC 9886 تتعمد عدم تحديد آليات المصادقة والتفويض والمحاسبة التي تحمي معلومات التعريف الشخصية. وتضع RFC 9434 الرقم التسلسلي للمصنّع ومعرّف القصد التشغيلي ومعلومات منظمة أخرى في الطبقة الخاصة.

لذلك قد يبدأ مسؤول سلامة عامة ومزود خدمة جوية وعابر فضولي من DET نفسه، ويحصل كل منهم على نتيجة قانونية مختلفة. يخبر DNS أين يُسأل؛ أما السجل الخاص فيقرر من يعرف ولماذا وتحت أي سياسة محلية. نجاح البحث العام لا يصنع اعتماداً خاصاً.

ولا تمنح الإجابة الخاصة إذن الطيران أو التدخل. يشهد المسجّل على التسجيل ولا يقود الطائرة. يصف UAS Service Supplier عملية من دون أن يصبح المنظم. يستقبل المراقب رسالة من دون أن يضمن صحة الموقع المعلن.

للنشر زمن غير زمن الرحلة

نشر HHIT خاص بكل DET يكشف المفتاح العام اللازم للتحقق. لذلك توصي RFC 9886، عندما يكون ذلك عملياً، بعدم نشر السجلات حتى تحتاجها جهة أخرى. وتقترح أن تشير الطائرة أو منظومة UTM إلى قرب بدء عملية تستخدم Specific Session ID أو انتهائها.

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

تقدم المعايير أدلة محدودة بدقة، ولا تقدم زر «تم تحديد موقع الدرون». أولوية الكود العامل هنا تعني الاعتماد على ما أنتجه كل مكون فعلاً، في وقته، وللغرض الذي صُمم له فقط.

المصادر