الخلاصة
- تعالج RFC 9103 جمع محتوى النطاق من خلال التنصت السلبي على نقل واضح. ولا تخفي بالضرورة هوية الخوادم أو توقيت الحركة وحجمها، ولا تمنع تعداد DNSSEC أو الاستعلامات السلطوية العادية.
- يحتاج ادعاء XoT القابل للتدقيق إلى إيصالات مستقلة: هوية الخادم primary، وتفويض الطلب للنطاق، وفرض TLS، واكتمال النقل، وقبول النسخة، واتساق transfer group، وقواعد الحفظ بعد الاستلام.
لم يحتج المتنصت إلى طلب النطاق
يمكن لخادم primary أن يقصر AXFR على عناوين معروفة وأن يطلب TSIG. هكذا يُرفض العميل غير المصرح له. لكن إذا عبر الرد المصرح به اتصال TCP واضحاً، فلا يحتاج المراقب الموجود على المسار إلى تجاوز ACL أو امتلاك السر المشترك. يكفيه أن يقرأ السجلات المرسلة إلى secondary الشرعي.
تغلق RFC 9103 هذا المسار بعينه. نُشرت في أغسطس 2021 بوصفها وثيقة Standards Track من IETF، وحددت XFR over TLS لكل من AXFR الكامل وIXFR التزايدي. والفائدة كبيرة لأن تدفق النسخ يستطيع أن يكشف دفعة واحدة أسماء وعناوين وعلاقات تشغيلية لا تُجمع عادة إلا عبر استعلامات كثيرة.
لكن نموذج التهديد منضبط. فهو يعامل محتوى النطاق الحالي وحجمه على أنهما حساستان أثناء النقل. ولا يحاول إخفاء وجود النطاق أو وقوع النقل أو هوية خوادم الأسماء. وحتى مع التشفير قد يكشف الحجم والتوقيت بعض النشاط.
لذلك يمكن إثبات أن «المسار المختبر لم يعد يعرض الحمولة للمراقبة السلبية». أما عبارة «أصبح النطاق خاصاً» فتحتاج إلى أدلة أخرى.
TSIG وTLS لا يؤديان الوظيفة نفسها
تعرّف RFC 8945 آلية TSIG لمصادقة رسائل DNS بواسطة سر مشترك وحماية سلامتها. وتستخدم RFC 5936 الآلية في تفويض عملاء النقل. لكن TSIG لا يشفّر الرسالة؛ فقد تكون الحمولة صحيحة المصدر وسليمة، وتظل قابلة للقراءة على المسار.
يعالج TLS القناة. وفق RFC 9103، يصادق secondary هوية primary بملف Strict Privacy، بينما يتحقق primary من حق العميل بواسطة mutual TLS، أو ACL عنوان IP مع TSIG/SIG(0) صالح. يمنح Strict TLS مصادقة الخادم وسرية القناة، ويضيف mTLS مصادقة العميل، بينما يثبت TSIG أصل البيانات. هذه خصائص متكاملة وليست مترادفات.
قبول اتصال TLS لا يفتح كل نطاق. يمكن لطلبات متعددة ولنطاقات مختلفة أن تعيد استخدام القناة نفسها، وغالباً ما تطبق الخوادم ACL عند وصول طلب XFR المحدد. الاستماع على المنفذ، ونجاح المصافحة، والسماح بنسخ نطاق بعينه ثلاثة أحداث منفصلة.
الاستثناء هو الذي يحدد قوة السياسة
تسمي RFC 9103 جميع خوادم primaries وsecondaries المشاركة transfer group. ولكي تُحمى المجموعة، يجب أن تستخدم كل مسارات AXFR وIXFR آلية XoT. يكفي secondary قديم أو مسار طوارئ واضح أو وصلة خلفية غير مشفرة بعد TLS proxy لإبقاء نقطة الضعف.
ولا يكفي Opportunistic TLS. فقد يستمر من دون مصادقة ناجحة للخادم، أو يعود إلى النص الواضح عندما لا يتوفر TLS. قد يكون ذلك تحسيناً في سياقات أخرى، لكنه لا يثبت سياسة تمنع النقل الواضح.
ويجب تمييز fallback. انتقال IXFR إلى AXFR داخل اتصال TLS موثق يزيد حجم النقل ولا يغير بالضرورة سريته. أما الرجوع من TLS إلى TCP الواضح فيلغي الخاصية ذاتها. ويمكن لتغيير موضع انتهاء proxy أن يحدث الأثر نفسه.
بعض الاختبارات السلبية سهلة نسبياً: طلب النقل من دون TSIG، أو من عنوان غير مصرح، أو بقناة واضحة. الأصعب هو إثبات أن كل secondary يرفض بيانات بلا مصادقة، ويستخدم ملفاً صارماً، ويفرض XoT على نظرائه اللاحقين. تنسيق هذه السياسة وإنفاذها خارج نطاق RFC.
بعد التسليم تبدأ سلطة جديدة
لنفترض نجاح السلسلة: صادق secondary على primary، وفوّض primary العميل، وحمى TLS 1.3 عملية IXFR، وقُبل serial الجديد. فقد المراقب السلبي المحتوى، لكن نسخة النطاق دخلت مجالاً إدارياً آخر.
قد تظهر النسخة في zone file أو journal أو قاعدة بيانات أو snapshot أو backup أو support log. وقد يصل إليها أشخاص وأدوات داخلية، أو تنتقل إلى secondaries آخرين. وسيبقى DNS السلطوي يجيب عن السجلات المعدة للنشر.
هذه ليست أعطالاً في TLS، بل نتائج نجاح النسخ. لذلك يجب تسجيل التخزين والوصول المحلي والنسخ الاحتياطية والسجلات والوجهات التالية وإجراءات إضافة peers وحذفهم. إلغاء شهادة أو مفتاح TSIG يوقف النقل المقبل، لكنه لا يسترد ملفاً أو backup سُلّم سابقاً.
ويكشف ZONEMD حداً آخر. توفر RFC 8976 digest للتحقق من كائن نطاق مستقل عن القناة. وهو مكمّل لـXoT ومتعامد معه. لا يخفي digest الحمولة أثناء النقل، ولا يثبت TLS أن محتوى النطاق صحيح أو حديث أو معتمد من صاحب القرار المناسب.
يبقى DNS العام عاماً
التنصت على النقل وتعداد النطاق مساران مختلفان. قد يتيح NSEC اجتياز نطاق موقع، بينما يحاول NSEC3 جعل ذلك أصعب عبر تجزئة أسماء المالكين. ولا يغير XoT هذه الآلية. كذلك تظل الاستعلامات السلطوية العادية تعيد السجلات المعدة للنشر.
ينبغي الحفاظ على حقيقتين معاً: كون بعض بيانات DNS عامة لا يبرر إرسال تدفق النسخ كاملاً بنص واضح؛ وتشفير تدفق النسخ لا يجعل كل سجل منشور سرياً. يغلق XoT قناة جمع كثيفة ومحددة.
ثمانية أسطر لإيصال السرية
يحدد النطاق اسم المنطقة ونسخة السياسة وtransfer group والمسؤولين. وتسجل هوية primary اسم المصادقة أو SPKI pin والشهادة وإصدار TLS والنقطة الفعلية. ويسجل قبول secondary هوية mTLS أو ACL مع TSIG/SIG(0)، وقرار كل نطاق واختبارات الرفض.
يصف النقل AXoT أو IXoT ومنع النص الواضح وfallback وحدود proxy. ويسجل الاكتمال serial المطلوب والمقبول والتحول من IXFR إلى AXFR والأخطاء. وتوثق حراسة النسخة التخزين والوصول وbackup وlogs والنظراء اللاحقين.
ويغطي التعرض المتبقي الاستعلامات العادية وNSEC/NSEC3 والعلاقات المرئية وإشارات التوقيت والحجم. وتحدد إعادة التحقق تغييرات الشهادة أو المفتاح أو ACL أو proxy أو secondary أو topology أو سياسة التوقيع أو المشغل.
تثبت مصافحة TLS خصائص قناة. ويثبت TSIG خصائص رسالة. ويثبت serial المقبول حالة نسخة. ولا يثبت أي منها منفرداً سرية جميع النسخ.
المصادر
- سجل RFC 9103 لدى RFC Editor
- RFC 9103 — DNS Zone Transfer over TLS
- RFC 1995 — Incremental Zone Transfer in DNS
- RFC 5936 — DNS Zone Transfer Protocol
- RFC 8310 — Usage Profiles for DNS over TLS and DNS over DTLS
- RFC 8945 — Secret Key Transaction Authentication for DNS
- RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence
- RFC 8976 — Message Digest for DNS Zones
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

