موقعان، ومنطقة DNS خاصة واحدة: من يملك السجلات؟

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

العَرَض يسمّي المالك الغائب

من المرجح أن لكل موقع تجاوزًا محليًا أو إدخال Pi-hole أو سطر dnsmasq أضافه أحدهم حين احتاج اسمًا. السجل الأخضر موجود على المُحلِّل الأخضر فقط، فيسأل عميل في الأصفر مُحلِّله ويحصل على "لا يوجد اسم كهذا" بصدق. أما الإجابة القديمة فتبدو مختلفة: انتقل المضيف، وحدّث أحد الموقعين نسخته، وما زال الآخر يعيد العنوان القديم.

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

إذن السؤال التصميمي ضيق وقابل للإجابة: من يجوز له إنشاء سجل، وكيف يصل ذلك السجل إلى كل مُحلِّل يجب أن يجيب عنه؟

الخيار A: منطقة موثوقة واحدة مع خوادم ثانوية

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

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

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

الثمن هو التنسيق: مسار تحرير واحد، ومراجعة تغيير واحدة، وفهم مشترك لمن يكون في الخدمة عندما يكون سجل ما خطأً.

الخيار B: نطاق فرعي لكل موقع

فوّض green.internal.example.com للموقع الأخضر و yellow.internal.example.com للموقع الأصفر. يصبح كل موقع موثوقًا لأسمائه، ولا تحمل المنطقة الأم سوى سجلات التفويض. يختفي التنازع على ملف واحد، ويستطيع فريق محلي إضافة مضيف دون انتظار تغيير مركزي.

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

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

اجعل كل مُحلِّل يتبع الاختيار

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

إذا كان Pi-hole يوفر التحليل المحلي، فاكتب أي السجلات يملك وأي الاستعلامات يمرّر. قائمتا Pi-hole تُحرَّران باستقلال لا تتكرران. في Pi-hole v6، تُضبط أسطر dnsmasq المخصصة عبر خيارات على جانب المضيف مثل TOML أو CLI أو متغيرات البيئة ولا تُعرض عبر API؛ وتحميل ملفات /etc/dnsmasq.d/ خيار منفصل معطّل افتراضيًا.

ثم اختبر من الجانبين باسم ينبغي أن يكون مرئيًا في كل مكان:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

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

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