خادم أسماء مشترك يثبت الاستمرارية لا السيطرة على التفويض

الخلاصة

• تعتبر النسخة 14 من مسودة DNSOP التفويض مستمراً عندما تظل المنطقة الأم تحيل إلى نقطة التفويض نفسها، ويتشارك طقما NS الحالي والمخبأ اسماً واحداً على الأقل. وإذا ظهرت بيانات DS في الحالتين، فيجب أن يبقى مُوقّع مفوّض واحد مشترك على الأقل أيضاً.
• طاقم NS جديد بالكامل، أو طاقم DS جديد بالكامل، أو الانتقال بين غياب DS ووجوده يعني تغير السلطة في الخوارزمية. لا يعود مسموحاً استخدام بيانات الذاكرة المؤقتة عند تلك النقطة أو تحتها، بينما يوزع النمطان الصارم والانتهازي مخاطر الفشل والتراجع بصورة مختلفة.
• التقاطع حكم لاستمرارية الذاكرة وليس توثيقاً لإذن الانتقال. ينبغي أن يسجل إيصال انتقال التفويض عناصر التداخل المقصودة، وحالتي الأم والابن، ومرجع التغيير، ومؤقتات TTL، وموعد السحب، وصاحب التراجع. هذا اقتراح Daniel Kade وليس نصاً من IETF.

للتفويض التقليدي وجهان. تنشر المنطقة الأم أسماء NS التي تقود إلى الابن، وبيانات glue الضرورية، وDS إن كان التفويض مؤمناً. وتنشر المنطقة الابنة عند قمتها طاقم NS موثوقاً من جهتها. تطلب RFC 1034 من مسؤولي المنطقتين إبقاء جانبي الحد متسقين، لكن DNS لا يوفر معاملة واحدة تغيّرهما في اللحظة نفسها.

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

نُشرت النسخة 14 من Delegation Revalidation by DNS Resolvers في 2 سبتمبر/أيلول 2026. يسجلها Datatracker بوصفها Internet-Draft فعالة ضمن فريق DNSOP، في مسار المعايير وبحالة مستهدفة Proposed Standard، تنتظر إشارة التقدم من رئيسي الفريق، وتنتهي في 6 مارس/آذار 2027. ليست RFC ولا أمراً بالتنفيذ.

تجمع الخوارزمية الاختيارية ثلاثة أعمال. بعد اتباع إحالة الأم، يرسل المحلّل سؤالاً صريحاً عن NS قمة الابن، ويعطي الإجابة الموثوقة ترتيباً أعلى من نسخة الإحالة غير الموثوقة وفق RFC 2181. كما يحاول الحصول على عناوين A وAAAA من مصادرها الموثوقة. ثم يعود دورياً إلى الأم ليتأكد من أن التفويض ما زال موجوداً، ولم يُنقل إلى سلطة جديدة بالكامل.

التقاطع ليس تصويت أغلبية

تحتفظ الذاكرة بأسماء NS التي وردت من الأم وبـTTL الخاص بها، وبـTTL طاقم DS إن رأته. عند إعادة التحقق، يجب أن ترد الأم بإحالة إلى النقطة نفسها. ويجب أن يتقاطع طاقم NS الجديد مع الطاقم السابق في اسم واحد على الأقل.

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

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

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

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

الابن يصف خدمته والأم تستطيع سحب التفويض

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

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

لكن أولوية الابن لا تمنحه حق تجديد تفويضه إلى الأبد. قد تكون الأم قد أزالت التفويض أو نقلته إلى مشغل آخر. المحلّل الذي ينعش NS الابن وحده قد يظل متمسكاً بمزود قديم بعد إعادة التفويض. العودة إلى الأم تقيد خطر «النطاق الشبح» هذا.

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

هذا التراجع ينقذ الخدمة، لكنه يجعل صورة NS وحدها غير كافية لفهم المسار الحقيقي. قابلية الوصول وترتيب الذاكرة وتسلسل الإجابات ووقت التحقق كلها تؤثر في القرار.

الصرامة والانتهازية عقدان مختلفان

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

لهذا توصي المسودة بحصر رفع الموثوقية الصارم في الجذر والمناطق المفوضة منه مباشرة. في المستويات الأعمق توجد خوادم لا تجيب بطريقة صحيحة عن سؤال NS القمة الصريح.

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

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

أقصر ثلاثة مؤقتات يواجه حداً أدنى محلياً

يجب بدء إعادة التحقق في موعد لا يتجاوز أقصر TTL بين NS الأم، وDS الأم عند وجوده، وNS قمة الابن. يقيد مؤقت الأم بقاء تفويض أزيل أو نُقل، بينما يسمح مؤقت الابن بطلب ملاحظة أسرع لتغييره.

لكن المسودة توصي أيضاً بأن يفرض المحلّل حداً أدنى معقولاً كي لا تستطيع منطقة خبيثة فرض عمل حسابي متكرر عبر قيم شديدة القصر. ولا تحدد رقماً عالمياً. لذلك لا يضمن أقصر TTL منشور إبطالاً متزامناً في كل ذاكرات العالم.

يجب تخزين إخفاقات الحل سلبياً وفق RFC 9520 حتى لا تولّد محاولات عدوانية. وقد تزيد استعلامات NS والعناوين الإضافية حمل الخوادم الموثوقة بدرجة كبيرة. سقف العمل لكل استعلام جزء من الدفاع لا مجرد تحسين أداء.

تقرير الاختلاف شاهد لا قاضٍ

عندما يختلف NS الابن عن إحالة الأم، يمكن للمحلّل إرسال تقرير عبر قنوات RFC 9567 إلى الطرفين. تقترح النسخة 14 رمز Extended DNS Error للحالة، لكنه لا يزال TBD ولم تخصصه IANA بعد.

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

حتى النجاح ليس حكماً. قد يجيب الخادم القديم جيداً بينما لم يعد هناك طرف يعترف بمسؤولية بقائه.

إيصال يشرح سبب بقاء ذلك الاسم

في انتقال من المشغل A إلى B قد يكون الاحتفاظ باسم واحد ومُوقّع قديم إجراءً حكيماً. بالنسبة إلى المحلّل توجد استمرارية؛ وبالنسبة إلى التشغيل يجب أن تكون هناك جسر له نهاية.

يفصل الإيصال الحالة القديمة عن الحالة المستهدفة وفترة التداخل المسموحة. يسجل NS وglue في الأم، وDS، وNS قمة الابن، والعناوين الموثوقة. ويحدد الأسماء والموقعين الذين ينبغي أن يبقوا مشتركين، وسبب ذلك، وشرط سحبهم.

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

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

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

لا يقرأ المحلّل هذا الإيصال، ولا تفرضه المسودة. وظيفته أن يثبت ما لا يحاول تقاطع DNS إثباته: أن الاستمرار كان مأذوناً ومحدوداً وانتهى بمسؤولية.

المصادر

1. إعادة التحقق من التفويض بواسطة محللات DNS — النسخة 14
2. سجل Datatracker للمسودة
3. تاريخ وثيقة إعادة التحقق
4. وثائق DNSOP الفعالة
5. ميثاق DNSOP
6. RFC 1034 — مفاهيم ومرافق أسماء النطاقات
7. RFC 2181 — توضيحات مواصفة DNS
8. RFC 9520 — التخزين السلبي لإخفاقات الحل
9. RFC 9567 — الإبلاغ عن أخطاء DNS
10. التفويض القابل للتوسيع في DNS — النسخة 11