الخلاصة

  • قدّم ISC في APNIC 62 سرد المناطق وتصفيتها وكشف اختلاف الرقم التسلسلي باعتبارها وظائف متاحة اليوم في Stork. لم يوثّق العرض تشغيلاً إنتاجياً لدى APNIC ولا حادثة حقيقية لمنطقة قديمة.
  • يصف الاختلاف صفوف الخوادم والعروض وتهيئات المناطق التي اكتشفها Stork وجلبها. ولا تعني قائمة خالية من الاختلاف أن كامل بيئة DNS متطابق ما لم يشمل السجل إخفاقات الجلب والعروض غير المدعومة والاستثناءات وعمر البيانات.
  • الأثر التشغيلي الأنسب هو إيصال مقارنة يجمع إصدار Stork وإصدار خدمة DNS، والنطاق المقصود والمرصود، وحالة الجلب، والقيم الخام لـ SOA، ووقت الرصد وحدّ الصلاحية ومصير كل صف غير متاح.

الصف الغائب لا يستطيع أن يختلف

تغري إشارة اختلاف الرقم التسلسلي بالاختصار. تظهر المنطقة نفسها على خادمين، تختلف قيمتا SOA، فيبرز صف واحد يحتاج إلى انتباه. وفي عرض Stork خلال APNIC 62، وضع Marcin Siodelski سرد المناطق وتصفيتها وعارض المنطقة و«كشف اختلاف الرقم التسلسلي» ضمن وظائف DNS المتاحة حالياً. ثم وصف تقرير جلسة APNIC الإشارة نفسها عبر أكثر من خادم.

هذه إشارة جديرة بالاستخدام، لكن لا بد لها من مقام.

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

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

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

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

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

تكشف العروض مشكلة الهوية بوضوح. يستطيع Stork ربط اسم المنطقة ذاته بعروض مختلفة في BIND 9. وعندما يطلب المشغّل فحص السجلات عبر AXFR، يحتاج العرض غير الافتراضي إلى مفتاح TSIG حتى يستطيع BIND تحديد العرض المقصود بالطلب. وتحدد قواعد match-clients وallow-transfer أي مفتاح يصلح للعمل. وفي المقابل، لا يدعم Stork 2.4.1 عروض PowerDNS 5.0 صراحةً. والعرض غير المرئي هناك حد موثّق للمنتج، لا دليلاً على اتفاق الرقم التسلسلي.

ينبغي أيضاً فصل مسارين للبيانات. تُجمع قائمة المناطق وأرقامها التسلسلية عبر تكاملات خادم DNS، وتُخزن بعد Fetch Zones. أما محتوى المنطقة فيُطلب عند اختيار Show Zone، ويستخدم AXFR وقد يعرض نسخة مخزنة إلى أن يختار المشغّل Refresh from DNS. قد يفشل AXFR فيمنع تصفح السجلات من دون أن يمحو بالضرورة رقماً تسلسلياً ظهر سابقاً في القائمة. وبالعكس، لا يثبت ظهور الرقم التسلسلي أن Stork حصل على كل سجلات المنطقة. جمع المسارين في ادعاء واحد يحوّل دليلاً على شيء إلى دليل زائف على شيء آخر.

وينطبق الفصل نفسه على مراقبة النقل. يصف عرض Siodelski مراقبة XFR بأنها وظيفة جديدة في النسخة التطويرية 2.5.1. ويوضح دليل وكيل 2.5.1 أن تتبع السجلات هذا يخص BIND، وهو معطل افتراضياً ويحتاج إلى تفعيل صريح، ولا يستطيع متابعة عمليات النقل المسجلة عبر syslog وحده. ليست هذه الوظيفة هي مقارنة الأرقام التسلسلية المستقرة في 2.4.1. وتسمي ISC الإصدار 2.4.1 مستقراً والإصدار 2.5.1 تطويرياً في صفحة Stork. لذلك يجب أن يحمل كل ادعاء صادر من لوحة المتابعة رقم الإصدار، بدلاً من استعارة قدرات من إصدار مجاور.

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

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

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

يمكن لإيصال المقارنة أن يظل موجزاً. يسمّي إصدار خادم Stork والوكلاء، وتنفيذ DNS وإصدار الخدمة؛ ويعرّف الآلة والخدمة والمنطقة والفئة والعرض من دون كشف الأسرار؛ ويذكر الجرد المقصود ومن يملكه؛ ويسجل نافذة الجلب وحالة كل خدمة؛ ويحفظ Zone Configs Count وDistinct Zones والاستثناءات الصريحة والعروض غير المدعومة؛ ويضم القيم الخام ووقت الذاكرة أو الرصد وحدّ الصلاحية والنتيجة؛ ثم يحتفظ بقرار التنبيه وأي تصحيح لاحق.

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

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

المصادر