الخلاصة

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

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

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

يعرّف RFC 8976 سجل ZONEMD عند قمة المنطقة ليحمل message digest لبيانات المنطقة في حالة السكون. يعيد المستلم بناء التسلسل المعياري نفسه، ويحسب البصمة محلياً، ثم يقارنها بالقيمة المنشورة. قد يتطابق الرقم التسلسلي، لكن فقد سجل واحد داخل نطاق الحساب يمنع تطابق البصمة. هنا تتحول المقارنة من تأكيد وصول إصدار إلى إثبات أهلية محتوى للتفعيل.

الرقم التسلسلي يرتب الأجيال ولا يشتق هوية المحتوى

جاء حقل Serial في SOA من RFC 1035، ثم حدّد RFC 1982 كيفية مقارنة الأرقام في فضاء محدود، بما في ذلك الالتفاف بعد أعلى قيمة. يتيح ذلك للخوادم الثانوية أن تقرر محلياً ما إذا كان هناك جيل أحدث من دون ساعة عالمية.

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

يحتوي RDATA في ZONEMD على Serial وScheme وHash Algorithm وDigest. تكرار Serial يربط البصمة بنسخة معينة صرّح بها الناشر. تجيب SOA عن سؤال «أي جيل يحمل هذا الاسم؟»، بينما تجيب البصمة عن «ما المحتوى المعياري الكامل الذي التزم به الناشر لهذا الجيل؟». لا يقوم أحد الدليلين مقام الآخر.

ولا يقوم النقل بهذا الدور أيضاً. يصف RFC 1995 النقل التزايدي IXFR، ويحدد RFC 5936 نقل المنطقة الكاملة AXFR. يسلّم كلاهما نسخة مرشحة أو يعيد تركيبها. لكنه لا يترك، بعد التخزين والنسخ والاستعادة وإعادة التشغيل والتحميل، التزاماً دائماً يغطي الكائن كله. يحرس ZONEMD المحتوى بعد انتهاء سلطة القناة.

SIMPLE يوحّد معنى DNS لا شكل الملف

حصل ZONEMD على RR type 63. المخطط القياسي الوحيد في RFC 8976 هو SIMPLE بالقيمة 1، ويجب على التطبيقات دعمه. كما يجب دعم SHA-384، الخوارزمية 1، مع نشر 48 octet كاملة. وينبغي دعم SHA-512، الخوارزمية 2، مع 64 octet كاملة. يعرض سجل معلمات DNS لدى IANA القيم المخصصة ونطاقات الاستخدام الخاص وغير المخصصة.

لا يطبق SIMPLE التجزئة على النص الخام لملف master. قد تختلف التعليقات والمسافات وحالة الأحرف من دون أن تختلف بيانات DNS. تُحوّل السجلات إلى canonical wire format من دون ضغط، وتُرتب وفق RFC 4034، مع ترتيب RRsets ذات owner واحد بحسب القيمة الرقمية لنوع RR. وهكذا يمكن لملفين مختلفين شكلاً أن يعبرا عن الالتزام نفسه، لكن لا يمكن لاختلاف دلالي أن يختبئ خلف التنسيق.

تشمل القاعدة كل سجل داخل المنطقة ما لم يرد استثناء صريح. تدخل بيانات glue، وكذلك occluded data. وتُحسب النسخ المتطابقة تماماً مرة واحدة. ولا تدخل بيانات خارج المنطقة لمجرد وجودها بجانب الملف. وفي المنطقة الموقعة تدخل سجلات DNSSEC، باستثناء ZONEMD placeholder عند القمة وRRSIG التي ستغطي RRset النهائي، تجنباً لمرجع دائري.

هذا الاتساع لا يحول ZONEMD إلى بديل من DNSSEC. يوثق DNSSEC مجموعات RR والأدلة المستخدمة للتحقق من الإجابات. أما المنطقة الكاملة كقطعة موزعة فتحتوي بيانات تفويض وglue لا تحظى كلها بالحماية نفسها التي يحظى بها RRset سلطوي عادي في child. يوفر ZONEMD التزاماً على مستوى الكائن الكامل لخادم سلطوي أو مستودع أو مستهلك آخر للمنطقة.

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

ترتيب التوقيع جزء من صحة الالتزام

إضافة ZONEMD بعد توقيع منطقة DNSSEC تغيّر type bitmap في NSEC أو NSEC3 عند القمة. لذلك يبدأ الإجراء بحذف سجلات ZONEMD القديمة وتوقيعاتها، ثم يضيف placeholder قبل توقيع DNSSEC، لكي تعكس أدلة عدم الوجود حضور النوع منذ البداية.

بعد التوقيع تُحسب بصمة SIMPLE على تسلسل السجلات المعياري. لا يدخل placeholder عند القمة، ولا تدخل RRSIG التي ستغطي ZONEMD النهائي. يستبدل الناشر القيمة المؤقتة بالبصمة، ثم ينشئ توقيع RRset أو يحدثه.

هناك قيد يمنع العملية من مطاردة نفسها: يجب ألا يؤدي إنشاء توقيع ZONEMD إلى زيادة Serial مرة أخرى. ينبغي نشر SOA وZONEMD المتطابقين في الوقت نفسه. وإلا غيّر فعل توثيق الالتزام النسخة التي يدّعي وصفها.

لهذا لا تكفي سلسلة سداسية من نتيجة استعلام كسجل إثبات. يلزم ربط snapshot المصدر، والسياسة المعتمدة، وإصدار builder وsigner، وSerial، والمخطط، والخوارزمية، والبصمة، وسياق مفاتيح DNSSEC، ووقت النشر الذري. بهذه السلسلة فقط يمكن تحديد ما إذا ظهر الاختلاف في المصدر أو البناء أو التوقيع أو التوزيع.

يبدأ التحقق بتحديد الأمن المتوقع

وجود ZONEMD في النسخة لا يقرر وحده مستوى الثقة. يحدد المستلم أولاً هل يُتوقع DNSSEC، باستخدام trust anchors المحلية، وعند الحاجة سلسلة DS موثقة في parent. يوفر RFC 4035 سياق التحقق.

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

بعد ذلك يأتي الفحص البنيوي. عند نشر عدة سجلات ZONEMD يجب أن يكون كل زوج Scheme/Hash Algorithm فريداً. يمكن للسياسة المحلية تجاهل زوج ترفضه. ولكل مرشح مقبول يجب أن يتطابق Serial تماماً مع SOA، وأن تكون الخوارزمية والمخطط مدعومين، وأن يكون طول Digest صحيحاً، وأن تساوي القيمة المحسوبة القيمة المستلمة.

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

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

من دون DNSSEC يستطيع المهاجم تعديل البصمة أيضاً

يفيد ZONEMD غير الموقع كـchecksum ضد القطع وأخطاء النقل وتلف التخزين غير المقصود، ما دامت البصمة الأصلية باقية. أما من يستطيع تعديل المنطقة عمداً فيستطيع حساب Digest جديد واستبدال السجل. لذلك لا يقدم هذا النمط حماية حقيقية من ذلك الخصم.

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

ويحمي TSIG حداً آخر. يحدد RFC 8945 توثيق معاملات DNS بسر مشترك، وهو مفيد لهوية طرف AXFR/IXFR وسلامة رسائله. لكن MAC المعاملة القديمة لا يبقى مرتبطاً بالمنطقة الكاملة خلال النسخ والاستعادة وإعادة التحميل. يجعل ZONEMD التحقق من الكائن قابلاً للتكرار بعد انتهاء القناة.

حتى الدليل الموقع له حد زمني. قد يؤدي سحب DS أو تغيير trust anchor إلى منع تحقق تاريخي، رغم أن RRSIG تبدو ضمن نافذتها الزمنية. لذلك يحفظ receipt طويل الأجل سياق الثقة الذي استُخدم عند قرار التفعيل، لا ملف المنطقة وحده.

رفض النسخة الخاطئة قد يرفض الخدمة أيضاً

يستطيع الخادم التحقق في staging ورفض load عند عدم تطابق البصمة. هذه الفائدة الأساسية: لا تتحول نسخة معيبة إلى حالة سلطوية.

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

لذلك يناقش RFC 8976 التدرج من warning إلى error بعد اكتساب الخبرة. كما تعاملت وثيقة RZERC003 لدى ICANN مع إدخال ZONEMD في root zone كتغيير منسق بين المشرف والجهات المشغلة والمطورين ومستهلكي النسخ المحلية. ليست العبرة نسخ سياسة الجذر، بل إدراك أن enforcement يغير عدة نطاقات فشل في آن واحد.

تحتاج السياسة الناضجة إلى ثلاثة مسارات. المرشح المتحقق يصبح مؤهلاً للتفعيل. والمرشح المختلف يدخل quarantine بينما يستمر الجيل السابق المتحقق لمدة محدودة. أما الدليل غير الحاسم، مثل تعذر سلسلة الثقة بدلاً من اختلاف المحتوى، فيحتاج إلى قرار fail-open أو fail-closed من سلطة مسماة ولفترة معلومة.

الجيل السابق ليس ملجأ دائماً. يحافظ على سلامة معروفة لكنه يراكم staleness. تحدد قيم refresh وexpire، ومعدل التغيير، والأثر، مدة الاحتمال. يجب اختبار rollback كمنتج: كائن محفوظ، وإعادة تحقق مستقلة، وقدرة على التحميل، ومشاهدة الجيل المستعاد في الإجابات.

لا تنتهي حجة التفعيل عند خادم التجهيز

قد تتوزع DNS السلطوية بين عدة مزودين ومواقع anycast كثيرة، كما يناقش RFC 8901. نجاح التحقق في جهاز واحد لا يثبت أن الأسطول حمل الجيل. ونجاح API لإعادة التحميل لا يثبت ما يقدمه process. واستعلام من catchment واحد لا يصف البقية.

يربط activation receipt خمس حدود. عند الناشر: المصدر وSerial والبصمة الموقعة. عند النقل أو المستودع: هوية الكائن وحجمه وhash محلي وأحداث الحراسة. عند المتحقق: توقع DNSSEC وtrust anchors والزوج المسموح والقيمة والسبب. عند التفعيل: الجيلان القديم والجديد، والقرار، ونتيجة load. وفي runtime: استعلامات SOA وZONEMD وسجلات مشمولة عبر النطاق المطلوب.

لا ينبغي أن تقتصر canaries على SOA، وإلا أعادت نقطة العمى نفسها. يجب أن تشمل أسماء حساسة للتفويض، وعناوين glue مختارة، وRRsets موقعة، وإجابات سلبية، مع حفظ هوية الخادم السلطوي ونقطة الرصد. وإذا شُغلت root محلية وفق RFC 8806، تحتاج النسخة المحلية ومسار تحديثها إلى receipt مستقل؛ لا تثبت حالة root العامة حالة resolver المحلي.

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

المصادر