الخلاصة

  • فتح DNSOP في 2 سبتمبر دعوة لتبنّي draft-farrokhi-dnsop-ede-nta-01، وتنتهي في 16 سبتمبر. ما زالت الوثيقة Internet-Draft فردية، وليست RFC أو نتيجة تبنٍّ نهائية.
  • يبين EDE 33 أن NTA مغطية كانت سارية عند إنشاء الإجابة. وتجيز المسودة إرساله حتى عندما لا يكون للاستثناء أثر مادي في المحتوى.
  • يمكن لسجل أثر محدود أن يربط مصدر EDE وحماية الوصلة بقياس متزامن للتحقق من دون NTA، أو يحتفظ بحالة «لم يُقَس» بدلاً من اختراع نتيجة مقابلة.

الرمز حاضر والقرار لم يكتمل

تطلب دعوة DNSOP من المشاركين بيان ما إذا كان على مجموعة العمل أن تتولى وثيقة الإفصاح عن NTAs داخل إجابات DNS. بدأت في 2 سبتمبر وتنتهي في 16 منه. وما زالت صفحة Datatracker تعرض Call For Adoption By WG Issued. الإصدار 01 مسودة فردية ذات وضع مستهدف Informational، لا RFC ولا قرار IETF منجزاً.

لكن سجل معلمات DNS لدى IANA يتضمن فعلاً الرمز 33 باسم Negative Trust Anchor. يتيح الرقم المشترك للمطورين تجنب تخصيصات متعارضة. ولا يعني أن مجموعة العمل تبنت النص، أو أن مضمونه صار نهائياً، أو أن المحللات تنشره على نطاق معين.

فهذه سلطات مختلفة: IANA تحفظ المعرّف؛ رئاسة المجموعة تسجل نتيجة النقاش؛ مسار النشر يمنح الوثيقة حالتها اللاحقة؛ والمشغل يختار البرمجية والسياسة. لا يحمل رقم من 16 بت تلك القرارات كلها.

الاستثناء يغيّر سياسة المحلل لا سلطة النطاق

يعرّف RFC 7646 الـ NTA كسلوك محلي داخل محلل تكراري يتحقق من DNSSEC. ابتداءً من اسم محدد، يتوقف المحلل عن تتبع سلسلة المصادقة المعتادة ويعامل الإجابات المغطاة كما لو كانت المنطقة غير موقعة. لا يصلح التوقيعات، ولا يعدل التفويض، ولا يصبح خادماً موثوقاً للمنطقة.

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

تخص هذه الوقائع سجل التفويض والمدة والإزالة، وقد تناولتها تغطية سابقة. أما موضوع هذه المقالة فهو أضيق: ماذا تثبت إجابة واحدة تحمل 33؟

التغطية ليست دليلاً على تغيير النتيجة

ينص الإصدار 01 على أن ظهور حالة أو أكثر من EDE 33 يعني أن NTA مغطية كانت سارية وقت إنشاء الإجابة. الإشارة تشخيصية، لا تعدل معالجة بت AD، ولا ينبغي لخادم موثوق فقط أن يرسلها وكأنه أجرى تحققاً.

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

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

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

d وt يضيفان سياقاً محدوداً

يمكن أن يحمل EXTRA-TEXT اسم موضع الإعداد، أو السبب، أو مرجعاً، أو مدة متوقعة. ويستخدم الشكل المنظم d لاسم النطاق الذي ضُبطت عنده NTA، وt لوقت تقريبي قد تبقى حتى بلوغه.

ليسا حقلين إلزاميين. يحدد d مجال التغطية ولا يقول إن هذه الإجابة اعتمدت عليها. ويصف t توقعاً لا واقعة إزالة. أما السبب النصي فليس توقيعاً من صاحب صلاحية. وإذا انطبقت عدة NTAs، تستطيع الإجابة إرفاق عدة حالات مع نص لكل واحدة؛ تعدد المرشحين لا يكشف أيها غيّر النتيجة.

ويضع RFC 8914 حدود النقل. EDE معلومات إضافية لا يجوز أن تغير معالجة DNS، ولا تتمتع بمصادقة ذاتية ما لم تُحمَ المعاملة أو الوصلة بآلية مناسبة. يمكن لمعيد التوجيه حذف الإشارة أو تمريرها أو صنع إشارة جديدة؛ لذلك ينبغي إسناد المصدر كي لا يبدو آخر مرسل مؤلف التشخيص بالضرورة.

والصياغة الدقيقة هي: «يعلن النظام المجيب أن NTA كانت تغطي هذه الإجابة في ذلك الوقت». لا تثبت أن المنطقة مكسورة، أو أن القرار مبرر، أو أن المحتوى تغير، أو أن NTA ما زالت سارية. وغياب 33 لا يثبت العكس، لأن الإرسال موصى به لا مفروضاً، وقد يزيله وسيط.

بيئة العرض أصلحت نفسها

أعطى نقاش التبنّي مثالاً حياً على تغير الدليل. يحتوي الإصدار 01 على تفويض فرعي معطوب عمداً لعرض EDE 33. وفي رد بتاريخ 2 سبتمبر، أوضح المؤلف المشارك Joe Abley أن آليات Cloudflare الافتراضية كانت تصلح التفويض أو تزيل zone cut باستمرار، فلم تعد الحالة الحية تعرض ما أراده المثال في تلك اللحظة. وقال إن المؤلفين سيصلحون ذلك.

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

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

سجل أثر منفصل يحمي صغر البروتوكول

ليس من المناسب ملء EXTRA-TEXT بعناوين العملاء وسجل الاستعلامات والتذاكر الداخلية والتفاصيل الحساسة. يمكن أن يبقى الدليل الناقص في سجل أثر NTA لدى المشغل. هذا اقتراح تحريري من Daniel Kade، لا متطلب من IETF أو IANA.

لكل عينة أو حادثة، يربط السجل وقت الإجابة وبصمتها؛ ودور المحلل أو معيد التوجيه؛ ومصدر EDE؛ وحماية المقطع المرصود؛ والرمز وقيمتي d وt إن وجدتا؛ وحالة AD؛ ونتيجة تحقق متزامنة في مسار معزول بلا NTA، أو سبب «لم يُقَس»؛ وأي اختلاف في البيانات أو النتيجة؛ ورابطاً إلى سجل التفويض والانتهاء المنفصل.

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

يفصل The Policy Mirror لـ Heng Lu بين الفاعل والقاعدة والدليل: IANA تدير الفهرس، وعملية IETF تحدد حالة النص، والمشغل يتحكم في الاستثناء، ومسار بعينه ينقل الإشارة. ويطلب Running Code Primary أن يعتمد الحكم على مقارنة في نظام يعمل، لا على غاية مكتوبة وحدها.

يجعل EDE 33 استثناء DNSSEC قابلاً للرؤية. وتبقى رؤيته موثوقة حين نقبل أنه يعلن الوجود ولا يدعي الأثر.

المصادر

  1. دعوة DNSOP للتبنّي
  2. سجل Datatracker الحالي
  3. الإفصاح عن NTAs في إجابات DNS، الإصدار 01
  4. تاريخ الوثيقة
  5. إفصاح Joe Abley عن حالة المثال
  6. نقاش حدود التنفيذ
  7. RFC 7646 — Negative Trust Anchors في DNSSEC
  8. RFC 8914 — Extended DNS Errors
  9. معلمات DNS لدى IANA
  10. سجل مجموعة DNSOP
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Running Code Primary