الخلاصة

  • يوصي RFC 9953 بأن يضع عميل DoC معرّف ترويسة DNS عند 0 كي تشترك الطلبات المتكافئة في Cache-Key واحدة لدى CoAP.
  • قابلية إعادة الاستخدام مقيدة بحساب Max-Age وTTL DNS، ولا تثبت وحدها نتيجة DNS أو مصدرها أو تحققها أو سماح السياسة أو الأثر.

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

يعرّف RFC 9953، المنشور في مارس 2026، DNS over CoAP أو DoC لاستعلامات DNS ذات OPCODE 0. تُحوَّل كل زوجية استعلام واستجابة DNS إلى عملية طلب-استجابة في CoAP. يحمل جسم طلب FETCH استعلام DNS، ويستخدم application/dns-message بترميز Content-Format 553. يناسب ذلك الأجهزة ذات الذاكرة والطاقة والإطار المحدود؛ ولا يجعل الغلاف CoAP حكماً شاملاً على معنى بيانات DNS.

فكرة الصفر ضيقة ومفيدة. على عميل DoC أن يضبط حقل ID في ترويسة DNS إلى 0 حتى لا تغير أرقام المعاملات التقليدية Cache-Key عندما تكون بيانات DNS المطلوبة نفسها. عندئذ تستطيع ذاكرة مخبئية أو وكيل واقع في المسار أن يعيد التمثيل. وعلى خادم DoC أن ينسخ ID الوارد في الطلب إلى الاستجابة المقابلة. الصفر ليس هوية خادم، ولا ختم ثقة، ولا إذناً بعمل آلي؛ بل إزالة لتغير لا ينبغي أن يقسم مفتاح التخزين.

لكن RFC 9953 لا يسمح بأن يصبح ذلك تمديداً صامتاً للوقت. يجب على خادم DoC أن يضمن أن مجموع Max-Age في استجابة CoAP وكل TTL DNS فيها لا يتجاوز TTL المقابل الذي وصل من DNS الأعلى. ويشمل ذلك Max-Age الافتراضي في CoAP، وهو 60 ثانية، إذا لم يُرسل الخيار. وعند الاستلام، يجب على العميل أن يضيف Max-Age إلى جميع قيم TTL في DNS ويستخدم القيم المحسوبة. الوقت في الغلاف والوقت داخل السجل ميزانية واحدة موزعة، لا معلومتان يمكن اختيار إحداهما.

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

وتوجد لغتان للنتيجة يجب عدم دمجهما. توصي المواصفة بأن تصل استجابة DNS القابلة للتحليل داخل CoAP 2.05 Content حتى لو احتوت DNS نفسها على NXDOMAIN أو RCODE للفشل. أما أكواد CoAP غير الناجحة فهي لخطأ طبقة CoAP أو لطلب يخالف متطلبات DoC. تحويل 2.05 إلى «نجاح DNS» يمحو ما قاله DNS. وتحويل RCODE إلى «فشل نقل» يمحو ما حدث في CoAP.

ولا يحدد المخبأ وحده صفة من أجاب. يمكن لخادم DoC أن يكون خادماً سلطوياً أو stub أو محللاً تكرارياً، ويجوز له أن يكون محقق DNSSEC لعملاء مقيدين. ويمكن حماية الرسائل بـ (D)TLS أو OSCORE. هذه إمكانات لا برهان شامل: لا تثبت أن كل رد تحقق بـ DNSSEC، أو أن السياسة المحلية قبلته، أو أن التطبيق حقق النتيجة المنسوبة إليه. يستخدم Daniel Kade فصل Heng Lu بين طبقات الواقع كعدسة تحريرية: التمثيل القابل للتخزين ليس مالكاً لحقائق المصدر والتحقق والفعل.

المصادر