احتياطي DNS في شبكتك الافتراضية: إلى أين يذهب الاستعلام حقاً

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

الاحتياط سياسة وليس سلوكاً واحداً

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

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

هوية المُحلِّل البديل هي أول حقيقة يجدر إثباتها. المُحلِّل العام التابع لمزوّد تثق به بالفعل حالة مختلفة عن عنوان تقدمه الشبكة التي تصادف وجودك فيها. نادراً ما يخبرك العنوان نفسه بأي الاثنين تنظر إليه.

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

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

الأسماء الداخلية تجعل التمييز ملموساً. المُحلِّل العام لا يستطيع عادة الإجابة عن اسم من نوع split-horizon، فيفشل الاستعلام بينما يكون الاسم قد كُشف لطرف لم يكن له شأن برؤيته. لذلك يسير التوافر والخصوصية معاً هنا بدل أن يتبادلا.

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

تحقّق من المسار والمتلقي معاً

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

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

إذا أظهر التسجيل أن الاستعلام يغادر الواجهة الفيزيائية بينما النفق قائم، فقد تجاوز الاحتياط النفق بصرف النظر عما تقوله قائمة المُحلِّلات. وإذا ظهر على واجهة النفق، يصبح السؤال من يدير الطرف البعيد وما يحتفظ به.

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

قرّر ما إذا كان ينبغي السماح بالاحتياط

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

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

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