تطابق الملخص وبقيت المنطقة خاطئة: حدود ما تثبته ZONEMD

الخلاصة

• تربط ZONEMD المحتوى القانوني للمنطقة برقم تسلسلي محدد في SOA؛ وتحتاج النتيجة إلى DNSSEC كي تثبت المصدر، لا أن تكتفي بكشف التلف العرضي.
• يثبت التطابق أن النسخة المستلمة هي الجسم الذي مثّله الناشر بملخصه، لكنه لا يثبت أن السجلات كانت القرار الصحيح ولا أن حجب النسخة الجديدة أفضل دائماً من استمرار آخر نسخة سليمة.

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

يحدد RFC 8976 سجلاً يرافق المنطقة نفسها. فالمنطقة قد تصل عبر AXFR أو IXFR أو ملف أو أرشيف أو تغذية سياسات. حماية قناة النقل قد تنتهي بانتهاء الجلسة، أما ZONEMD فيتيح إعادة فحص نسخة مستقلة لاحقاً، بصرف النظر عن ترتيب النص أو المسافات أو التعليقات.

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

يستخدم مخطط SIMPLE الصيغة السلكية والترتيب القانوني الواردين في RFC 4034. تدخل سجلات glue والبيانات المحجوبة في الحساب، وتُحتسب النسخ المتطابقة مرة واحدة، بينما يُستثنى ZONEMD المؤقت في القمة والتوقيع الذي يغطي مجموعته لتجنب الدوران. أما ZONEMD خارج القمة فلا يحمل معنى تحقق في هذه المواصفة.

يسجل جدول IANA الحالي SIMPLE بالقيمة 1، وSHA-384 بالقيمة 1، وSHA-512 بالقيمة 2. يجب دعم SIMPLE مع SHA-384، وينبغي دعم SHA-512. ويمكن نشر أكثر من زوج فريد أثناء الانتقال؛ يكفي تطابق زوج تدعمه السياسة المحلية. لكن إبقاء الزوج القديم بعد الانتقال يبقي مسار الثقة الأضعف مفتوحاً.

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

في المنطقة غير الموقعة يستطيع من يغير السجلات أن يعيد حساب الملخص. يظل ZONEMD مفيداً لكشف القطع أو التلف العرضي أو اختلاف النسخ، لكنه يعمل كرقم تحقق لا كإثبات مصدر ضد مهاجم. يضيف DNSSEC سلسلة الثقة التي يشرح RFC 4033 نطاقها وحدودها. يحمي DNSSEC مجموعات السجلات، وتضيف ZONEMD رؤية الجسم الكامل؛ أحدهما لا يلغي الآخر.

حتى النتيجة الأقوى لا تقرأ نية العمل. قد يحذف الناشر الصحيح MX بالخطأ، أو يدرج عنواناً احتياطياً، أو ينشر قاعدة RPZ واسعة. يثبت الملخص أن هذا ما نُشر، لا أن تذكرة التغيير أو العقد أو الحكم المهني كان صحيحاً. تلك أسئلة تحتاج أدلة وأصحاب قرار آخرين.

تظهر وثائق التطبيقات هذا الفصل عملياً. يفصل Knot DNS بين zonemd-verify عند التحميل أو التحديث وبين التوليد بـSHA-384 أو SHA-512، وتكون الإجراءات معطلة افتراضياً، مع تنبيه إلى كلفة المناطق الكبيرة. ويفصل Unbound بين الفحص ورفض الغياب والوضع المتسامح الذي يسجل الفشل من دون حجب المنطقة. ويوثق PowerDNS أمراً صريحاً للتحقق من ملف. دعم السجل لا يفرض نتيجة تشغيلية واحدة.

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

يقدم RFC 5936 قاعدة استمرارية مفيدة في AXFR: تُستقبل النسخة المرشحة وتُفحص، ثم تُحمّل ذرياً بعد النجاح؛ وعند الخطأ تُحذف المرشحة ويستمر تقديم النسخة السابقة إن كانت موجودة. تقوي ZONEMD فحص المرشح، ولا تأمر بإتلاف آخر حالة سليمة معروفة.

لكن الحالة القديمة تحتاج إلى حد زمني. تختلف مخاطر القدم بين نسخة محلية من الجذر ومنطقة مؤسسة وتغذية سياسات. لذلك تحدد السياسة المحلية أقصى عمر ومتى يُصعّد الأمر ومن يجيز الاستثناء. لا يستطيع حقل عام في الملخص تمثيل ضرر كل خدمة.

للزمن أثر في الدليل نفسه. يجب نشر SOA وZONEMD المتطابقين معاً، ولا يجوز أن يؤدي توقيع ZONEMD إلى رفع SOA مرة أخرى. وبعد تدوير KSK قد يصبح توقيع لم تنته صلاحيته غير قابل للتحقق إذا اختفى DS أو مرتكز الثقة المطلوب لإعادة بناء السلسلة.

يعيد SIMPLE المرور على المنطقة كاملة عند كل تغيير. ويرى RFC 8976 أنه غير مناسب للمناطق الكبيرة أو شديدة التغير عندما يقترب وقت الحساب من دورة التحديث أو الانتشار. فالتحكم الذي لا يدخل في الميزانية التشغيلية يتحول إلى تأخير أو تجاوز طارئ.

ينبغي أن يحفظ التدقيق طبقات منفصلة: المرشح، والهوية القانونية، وأصالة DNSSEC، والفحص الدلالي، وقرار القبول المحلي، والإصدار المحمّل، والإجابات الفعلية. وتدعم كتابات Heng Lu عن أولوية الشيفرة العاملة والمواصفة الأولية الدنيا والقرار اللاحق المحلي وطبقات الواقع هذا الانضباط: تكون قاعدة التحقق مشتركة وضيقة، بينما يبقى أثر الفشل قراراً واضحاً لمن يشغل النظام.

وتسجل صفحة تصحيحات RFC 8976 خطأ تقنياً في مثال ملحق يعرض SHA-384 الخاص بطول أقصر من اللازم؛ ولا يتغير الشرط المعياري البالغ 48 ثمانية. الإفصاح عن هذا الحد مثال على سلامة سجل الأدلة نفسه.

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