الخلاصة
- يمكن لسجل NSEC3 يحمل Opt-Out أن يغطي تفويضاً غير آمن موجوداً من دون أن يقرر وجوده أو عدمه. ولهذا لا تمثل العقد الموقعة نسخة موثقة كاملة من جرد المنطقة الأم.
- ينبغي فصل قاعدة التفويض الأصلية عن جيل التوقيع وإجابات NS وDS على جميع الخوادم وقرار المحقق. غياب العقدة يعني أن السلسلة لا تجيب، لا أن الاسم محذوف.
يتتبع مدقق آلي حلقة NSEC3 كاملة، ويتحقق من كل RRSIG، ثم لا يجد عقدة توافق اسم طفل معين. يسجل النظام أن التفويض غير موجود. لكن الاستعلام المباشر إلى المنطقة الأم يعيد إحالة NS عادية بلا DS. الطفل موجود، والتفويض غير آمن.
المشهد توضيحي، أما القاعدة فمحددة في RFC 5155. يجوز إسقاط hash اسم التفويض غير الآمن إذا وقعت قيمته داخل مدى NSEC3 يحمل علم Opt-Out. ولا يؤكد ذلك المدى وجود التفويضات التي يغطيها ولا عدمها. بهذه الحدود يستطيع الأب إضافة تفويض مؤهل أو حذفه من دون إعادة بناء العقد المجاورة.
الخطأ هو منح السلسلة سلطة جرد لم تطلبها ولم تحصل عليها.
ما يملكه الأب وما ينتجه الموقّع
يحتفظ المصدر باسم الطفل وNS وglue عند الحاجة وDS ووقت التغيير والجهة التي سمحت به. يأخذ الموقّع هذه الحالة ويبني سلسلة مرتبة في فضاء hash. يحمل NSEC3 الخوارزمية والأعلام وعدد التكرارات والملح وhash التالي وخريطة الأنواع.
التفويض الآمن لديه NS وDS، أما غير الآمن فلديه NS من دون DS. Opt-Out لا يبيح إسقاط أي اسم تختاره الأداة؛ يخص الفئة غير الآمنة وما يشتق منها وحدها وفق القواعد. وتظل الأسماء ذات البيانات الموثوقة والتفويضات الآمنة ممثلة كما يوجب البروتوكول.
لكل اسم غائب عن السلسلة يجب حفظ رابطة عكسية: الاسم الأصلي، حالة NS/DS، hash المحسوب، السجل المغطي، العلم، خريطة الأنواع، جيل التوقيع، وما أعادته كل سلطة. من دونها تتشابه ثلاثة أوضاع مختلفة: إسقاط صحيح، خطأ في الموقّع، وخادم ثانوي متأخر.
الحالة الثالثة هي عدم القدرة على الحكم
لا تكفي حالتا موجود وغير موجود. عندما يقع hash داخل مدى Opt-Out تكون النتيجة الصحيحة: لا يمكن تحديده من هذه السلسلة. ولإثبات الجرد يلزم مصدر مخول، أو نقل منطقة مسموح، أو استعلاما NS وDS المباشران إلى الأب.
يطبق RFC 8198 الحد نفسه على التخزين السلبي الاستباقي. يستطيع المحقق أحياناً إعادة استخدام مدى NSEC/NSEC3 موثوق لتوليد جواب سلبي. فإذا كان السجل المغطي Opt-Out، فهو لا يثبت عدم وجود الاسم، ولا يجوز توليد ذلك الجواب.
إذا حذفت منصة الرصد العلم واحتفظت بعبارة «DNSSEC صالح» فقط، فإنها تحذف الشرط الذي يمنع الادعاء الكاذب.
أقرب سلف موجود ليس دائماً أقرب سلف قابل للإثبات
تعتمد إجابات wildcard والنفي على closest encloser، أي أطول سلف موجود. وقد لا تكون للتفويض المسقط أو empty non-terminal المشتق منه عقدة NSEC3. عندها تصل السلسلة إلى closest provable encloser فقط.
لذلك تحفظ مادة القرار الاستعلام وNSEC3 وRRSIG وnext-closer وعلاقة المطابقة أو التغطية ودوران مدى hash وخريطة الأنواع ووقت التحقق. اللون الأخضر لا يبين أين توقف الإثبات وأين بدأ الصمت المسموح.
التوصية الحديثة تقلل العمل
يوصي RFC 9276 باستخدام NSEC إذا لم تكن خصائص NSEC3 مطلوبة. وعند استخدام NSEC3 تكون القاعدة الموصى بها: الخوارزمية 1، صفر تكرارات إضافية، وملح فارغ.
تزيد التكرارات عبء الخوادم والمحققين ومخاطر عدم التوافق. ولا يجعل الملح الأسماء المتوقعة أسراراً. قد يعامل المحقق قيمة تتجاوز سياسته كغير آمنة أو يعيد SERVFAIL، وبعد التحقق من السجل المناسب قد يعيد EDE 27. هذا حكم على تكلفة المعالجة لا على وجود التفويض.
ولا يوصى بـOpt-Out للمناطق الصغيرة. يمكن تبريره في منطقة شديدة الضخامة تتمحور حول التفويضات ومعظم أطفالها بلا DS. ينبغي قياس الحجم ونسبة DS ومعدل التغيير وكلفة التوقيع وقدرة المطابقة بدلاً من توريث إعداد قديم.
تغيير المعلمات يعني جيلاً جديداً كاملاً
تغيير الملح أو التكرارات يتطلب سلسلة NSEC3 جديدة كاملة وإعادة توقيع. يتحقق المحقق من المعلمات داخل سجلات NSEC3؛ ولا يمثل NSEC3PARAM وحده إثبات نفي.
قبل التفعيل تقارن قاعدة المصدر والجيلان القديم والجديد وserial ونوافذ RRSIG وحالة النقل إلى كل خادم ثانوي. وتشمل الاختبارات اسماً معروف العدم، وتفويضاً غير آمن مسقطاً، وتفويضاً آمناً، وحد wildcard على كل عنوان موثوق.
إذا استمرت سلطات مختلفة في تقديم جيلين خارج النافذة المخططة، فلا تكفي قابلية الوصول. يدخل TTL وبقاء الأدلة القديمة في cache في قرار الإكمال أو الرجوع إلى آخر جيل متسق.
المصادر
- RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence
- RFC 9276 — Guidance for NSEC3 Parameter Settings
- RFC 8198 — Aggressive Use of DNSSEC-Validated Cache
- RFC 4033 — DNS Security Introduction and Requirements
- RFC 4034 — Resource Records for DNS Security Extensions
- RFC 4035 — Protocol Modifications for DNS Security Extensions
- RFC 4592 — The Role of Wildcards in the Domain Name System
- RFC 6840 — DNS Security Clarifications
- RFC 6781 — DNSSEC Operational Practices, Version 2
- RFC 7129 — Authenticated Denial of Existence in the DNS
- IANA — DNSSEC NSEC3 Parameters
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
