قبل السجل التفويض الجديد. وظلت منطقة الأصل تحمل إجابتين

الخلاصة

• تقترح draft-brown-epp-deleg-03 عمليات EPP لقراءة سجلات DELEG الخاصة باسم نطاق وإنشائها وإضافتها وحذف سجل محدد أو حذفها جميعاً.
• تتوقع المسودة بقاء DELEG وNS التقليدي معاً زمناً طويلاً، ولذلك قد ينتج عن كائن صحيح داخل السجل تمثيلان علنيان لم يتطابقا بعد.
• لا يكتمل إيصال التغيير عند نجاح EPP؛ بل يجب أن يتتبع توليد المنطقة، والنشر عند الأصل، وDNSSEC، والخوادم الموثوقة، وقدرة المحلل، وتقادم الذاكرة المخبأة، واختبار التطبيق.

تبدأ الواقعة هنا بإيصالين صحيحين، لا برسالة خطأ.

يقبل خادم EPP أمراً يحوي deleg:all، ويعيد معرّف المعاملة. يصبح كائن النطاق في مستودع السجل خالياً من سجلات DELEG المقترحة. وفي اللحظة نفسها تنجح أداة أخرى في سؤال منطقة الأصل عن NS، لأن المسار القديم لم يتغير. يستطيع كل فريق أن يعرض ضوءاً أخضر، مع أن أياً منهما لم يسأل عما تلقاه محلل يفهم DELEG.

هذه هي الفجوة التي تجعل المراجعة 03 من خريطة EPP لسجلات DELEG مسألة قيادة تشغيلية لا مجرد بناء XML. تستبدل المراجعة الصيغة السابقة بعناصر deleg:param متكررة ذات أسماء، وترفع نسخة نطاق الأسماء، وتضيف deleg:all للحذف الكامل، وتضع متطلبات تشغيلية صريحة. ويحدد سجل Datatracker مع تاريخ المراجعات وزن النص: هو Internet-Draft فردي نشط بلا مسار RFC، وليس معياراً معتمداً ولا دليلاً على نشر فعلي.

سلطة المعاملة تتوقف عند المستودع

تعرض الخريطة ثلاث نوافذ. يمكن لرد info أن يُظهر تمثيل DELEG المخزن. ويمكن لأمر create أن يرفق سجلاً أو أكثر عند إنشاء النطاق. أما update فيستطيع الإضافة أو حذف سجل مطابق أو إزالة المجموعة كلها. هذه أدوات دقيقة لإثبات ما طلبه العميل وما قبله الخادم.

تعرّف RFC 5730 نموذج أوامر EPP وردوده ومعرّفات المعاملات. وتربط RFC 5731 البروتوكول بكائن النطاق، بينما تصف RFC 5732 كائنات المضيف. يثبت الرد الناجح أن الخادم أنهى عملية في مستودعه. لكنه ليس توقيعاً من مولد المنطقة أو موقّع DNSSEC أو خوادم الأصل أو المحللات التكرارية.

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

التعايش يخلق واجب المطابقة

تقول مسودة EPP إن معظم النطاقات ستحتاج إلى DELEG وNS في منطقة الأصل معاً في المستقبل المنظور، وإن على الخوادم السماح لـDELEG بأن يتعايش مع كائنات المضيف أو خصائصه. ليست الهجرة استبدال حقل بآخر؛ إنها إسقاط كائن واحد في تمثيلين تستهلكهما مجموعتان مختلفتان من البرمجيات.

يحاول مشروع مجموعة العمل Extensible Delegation for DNS معالجة الخلاف القديم بين NS عند الأصل وNS عند قمة النطاق الفرعي. يجعل DELEG عند الأصل مرجعاً قابلاً للتمديد والحماية بـDNSSEC. لكنه يسمح أيضاً بوجود مجموعة DELEG مع NS أو من دونه. فإذا غاب NS، لا تستطيع البرمجيات التي لا تعرف DELEG حل النطاق المفوض.

لهذا لا يحمل deleg:all معنى تشغيلياً واحداً. قد يكون عودة مقصودة إلى NS فقط، أو تراجعاً عن تجربة، أو حذفاً ناقص التفويض لا تراه مراقبة NS. يحدد XML الفعل بدقة، لكن خطة الهجرة وحالة منطقة الأصل تحددان أثره.

وتضيف مسودة DNSOP الخاصة بتغييرات بروتوكول تمديد التفويض تفاوض القدرة ومقاومة الرجوع غير الآمن. قبول السجل لبيانات على هيئة DELEG لا يستطيع أن يثبت أن الخادم الموثوق أو المحلل نفذ ذلك التفاوض كما هو مقصود.

لقاموس المفاتيح ساعته الخاصة

تلزم المراجعة 03 الخادم برفض اسم معلمة مجهول أو قيمة غير صحيحة تركيبياً، ويكون كل اسم فريداً داخل سجل DELEG واحد. كما تلزم العميل والخادم بتحديث قائمة DelegInfoKeys المسجلة دورياً.

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

تطلب مسودة DELEG الأساسية من IANA إنشاء سجل لمعلومات التفويض، وتطلب مسودة EPP تسجيل نطاق الأسماء والامتداد. تشرح RFC 7451 إطار تسجيل امتدادات EPP، أما سجل IANA الحي لامتدادات EPP فهو المرجع للتخصيص الفعلي. لا يظهر فيه الامتداد المقترح ضمن اللقطة المجمدة لهذا البحث. الطلب الوارد في مسودة ليس تخصيصاً.

يبدأ النصف الثاني عند منطقة الأصل

تمنع مسودة DELEG الأساسية وضع DELEG عند قمة النطاق الفرعي لأن الموضع الخاطئ قد يؤدي إلى فشل تحقق DNSSEC. وتشرح RFC 4035 آلية التحقق من بيانات DNS الموثقة. يستطيع التحقق الصحيح إثبات ما تسمح به السلسلة عن مجموعة السجلات المستلمة؛ ولا يثبت أنها أحدث إسقاط لطلب EPP أو أنها تعطي النتيجة نفسها التي يعطيها NS.

يبدأ سجل التغيير القابل للمراجعة قبل الأمر. يسمي قصد صاحب النطاق، ومن أجاز القرار، وهوية العميل، وبايتات الطلب، ونطاق الأسماء، ولقطة DelegInfoKeys، ومعرّفي المعاملة لدى العميل والخادم. ثم يحفظ نسخة الكائن المثبتة وقاعدة التوفيق بين DELEG وبيانات المضيف وNS.

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

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

السجل الرسمي للمصادر

يحفظ ملف الأدلة الحالة الحالية في Datatracker، وتاريخها، والنص الدقيق للمراجعة 03، ومشروعي DELEG وDELEXT، ومواصفات EPP الأساسية والنطاقات والمضيفين، وإطار تسجيل الامتدادات، ومرجع DNSSEC، وسجل IANA الحي. لا يثبت أي منها تنفيذ مؤسسة بعينها أو نتيجة خدمة مسماة.