موافقة علنية لا تكشف دليل الأسماء الداخلي

الخلاصة

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

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

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

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

لماذا لا تكفي إجابة محلية تعمل؟

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

يعالج RFC 9704 العميل الهجين: عميل يقبل حلاً محلياً لبعض الأسماء المتجذرة في DNS العالمي، ويحتفظ بطريقة أخرى لحل بقية الأسماء. لا يشمل نطاقه العميل الذي يعتمد دائماً على الحل المحلي، ولا العميل الذي يتمسك دائماً بالحل الخارجي أو الكامل المستقل. كذلك لا يجوز استخدامه للتحقق من الأسماء ذات الاستخدام الخاص مثل local. وhome.arpa..

الموافقة المطلوبة تأتي بمشاركة النطاق الأب العام. لذلك لا تمنح الآلية مشغل الشبكة حق ترشيح أسماء جهات أخرى لمجرد أنه يستطيع الإعلان عن محلل. ويجب أن يدعم المحلل المحلي اتصال DNS مشفراً موثَّق الهوية. وجوده على الشبكة القريبة ليس بديلاً عن هذه الشروط.

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

بيان محلي وقيمة تحقق عامة

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

أما النطاق العام فينشر سجل TXT للتحقق. يدخل في اسم السجل اسم المحلل والعنصر _splitdns-challenge واسم النطاق الأب. وتحمل بياناته قيمة مشتقة من البيان وفق ترتيب وتطبيع محددين للأسماء، مع طول الملح والملح نفسه. تتضمن العملية استبدال لاحقة النطاق الأب وفق الصيغة التي يحددها المعيار، ثم حساب التجزئة وتمثيل قيمة التحقق بالترميز المحدد.

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

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

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

الاسم الذي يظل على الواجهة

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

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

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

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

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

لا يصدق المشغل نفسه بنفسه

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

يمكن استخدام محلل خارجي مشفر سبق ضبطه، مع بقاء قواعده المعتادة لقبول الإجابات. إذا لم يصل الرد خلال مدة معقولة، تفشل محاولة التحقق؛ لا يتحول الصمت إلى موافقة. ويمكن بدلاً من ذلك إجراء تحقق DNSSEC كاملاً محلياً. يصلح الناتج Secure للاستخدام، بينما يُرفض Bogus وIndeterminate. أما Insecure فينبغي معه تجربة طريقة أخرى، أو الفشل عند تعذر ذلك.

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

نجاح التحقق لا يمنح حق استخدام التطبيق الذي يشير إليه الاسم. قد يعرف العميل العنوان ويظل محتاجاً إلى هوية مستخدم أو سياسة وصول أو اتصال مسموح. وتنبّه إرشادات تقنيات البوابات لدى ASD's ACSC إلى عدم التعامل مع تقسيم إجابات DNS بالاعتماد على عنوان IP بوصفه آلية أمنية، وإلى فحص نموذج الثقة والتهديد قبل كشف المشاهد الداخلية لمزودي خدمات خارجيين. هذه إرشادات، لا دليل انتشار ولا إلزام قانوني عام.

ما توفره الموافقة الواسعة وما تنقله

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

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

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

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

يوضح RFC 8801 سياق نطاقات التهيئة وصلتها بمعلومات DNS ومسارات الشبكة ومواعيد صلاحية المعلومات. ويسجل سجل IANA لنطاقات التهيئة البنية splitDnsClaims وحقولها الخمسة: resolver وparent وsubdomains وalgorithm وsalt. هذا دليل تنسيق للصيغة، لا تعداد للأجهزة التي تدعمها.

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