الخلاصة

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

دقائق تتكلم فيها السلطة بصوتين

توزيع منطقة DNS على عدة خوادم موثوقة يمنع آلة أو وصلة واحدة من أن تكون نقطة الفشل الوحيدة. لكن التكرار يخلق سؤالاً عند كل تعديل: ما المدة التي يمكن أن يستمر خلالها خادمان موثوقان في تقديم نسختين مختلفتين من الحاضر؟

وصف RFC 1034 خادماً أساسياً تُنسق عنده التغييرات، وخوادم ثانوية تستعلم دورياً عن سجل بدء السلطة SOA. يقارن الثانوي حقل SERIAL، فإذا كانت نسخة الأساسي أحدث نقل المنطقة. يحدد REFRESH موعد الفحص المعتاد، وRETRY إعادة المحاولة بعد الفشل، وEXPIRE الحد الذي بعده يتوقف الثانوي عن ادعاء السلطة إن تعذر عليه التجديد. أما RFC 1035 فحدد هذه الحقول في 32 بت وعرّف AXFR لنقل المنطقة كاملة.

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

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

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

كلفة السؤال حين لا يتغير شيء

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

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

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

الطرق لا يعني إدخال الطرد

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

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

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

رد NOTIFY يثبت الاستلام فقط، ولا يثبت اكتمال التحديث. يمكن لعنوان مصدر مزور أن يسبب استعلامات SOA عبثية، ويمكن لخادم قديم أن يجيب NOTIMP. وإذا ضاع الإخطار، بقي فحص REFRESH طريق الاسترداد. لذلك لا يصح وصف الآلية بأنها دفع للمنطقة كاملة: ما دُفع هو الاستعجال، أما البيانات والقرار فبقيا منفصلين.

رقم يعود إلى الصفر ولا يعود إلى الماضي

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

الجمع معياري ومحدود. يمكن ترتيب قيم قريبة حتى عند عبور الصفر، أما قيمتان تفصل بينهما نصف المساحة تماماً فلا ترتيب معرفاً بينهما. لا يجوز أن يتقدم الرقم بأكثر من 2^31−1 خلال فترة EXPIRE، وإلا أمكن لنسخة قديمة أن تبدو أحدث.

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

نقل التعديل بدلاً من الخزانة كلها

قلّل NOTIFY وقت اكتشاف التغيير. وعرّف RFC 1995 IXFR لتقليل ما يلزم نقله. يرسل العميل سجل SOA ورقم النسخة التي يملكها. فإذا احتفظ الخادم بالتاريخ المناسب، أعاد سلاسل حذف وإضافة مرتبة حتى نسخته الحالية.

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

لم يُطلب من الخادم حفظ التاريخ إلى الأبد. يستطيع حذف الإصدارات القديمة، وخصوصاً عندما يصبح رد IXFR أكبر من AXFR، كما يستطيع حذف ما تجاوز EXPIRE أو دمج عدة نسخ في فرق صافٍ. إذا لم يعد يعرف نقطة بداية العميل، عاد إلى نقل المنطقة كاملة.

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

الحفظ قبل النشر

طلب RFC 1995 حفظ النسخة الجديدة في تخزين ثابت قبل توزيعها عبر IXFR أو AXFR. وإلا أمكن للخادم أن ينشرها ثم يتعطل ويعود من دون النسخة التي قبلتها الخوادم الثانوية، فتنتج السرعة جيلاً لا يستطيع المصدر نفسه استعادته.

وضح RFC 5936 حدود الطرف المستقبل في AXFR. تُستقبل المنطقة في مكان منفصل، وتُفحص، ثم تُفعّل دفعة واحدة. إذا فشل النقل تظل النسخة الصحيحة السابقة في الخدمة. وينطبق المبدأ على IXFR: لا يجوز أن تصبح سلسلة فروق ناقصة سلطة عامة جزئية.

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

مصادقة المسار لا تقديس المحتوى

قد يكشف نقل المنطقة معلومات كثيرة ويغير مباشرة أجوبة خادم موثوق. يوصي RFC 5936 بتقييد الوصول وحماية السلامة. يعرّف RFC 8945 TSIG، حيث يحمي سر مشترك ورمز مصادقة معاملة DNS.

في نقل TCP متعدد الرسائل، يمكن ربط رموز MAC لكشف العبث. يعرف المستقبل أن الطرف يملك المفتاح المتفق عليه. لكن TSIG لا يشفر القناة، ولا يوزع الأسرار، وتزداد إدارته صعوبة مع كثرة العلاقات.

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

تقسيم هادئ للسلطة

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

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

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

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

المصادر وحدود الدليل

يثبت RFC 1034 وRFC 1035 الاستطلاع ومؤقتات SOA وAXFR. يحدد RFC 1982 الحساب التسلسلي. يحدد RFC 1995 IXFR والرجوع الكامل. يحدد RFC 1996 NOTIFY والرسم المضبوط. يوضح RFC 5936 التفعيل الكامل والذري. ويحدد RFC 8945 TSIG وحدوده.

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