الخلاصة

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

انتهت إعادة المحاولة ولم ينته النشر

يعرّف RFC 1996 آلية NOTIFY كتنبيه فوري بدلاً من انتظار مؤقت التحديث. عندما تصل الاستجابة المطابقة، يستطيع الخادم الرئيسي حذف ذلك الثانوي من قائمة إعادة المحاولة الخاصة بالحدث. هذا هو النطاق الدقيق للدليل.

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

بعد NOTIFY صالح لـ SOA، يتصرف الثانوي كما لو انتهت مدة التحديث: يستعلم من خادم رئيسي معروف، ويقارن الرقمين، ويبدأ IXFR أو AXFR إذا تقدم الرقم البعيد. تقع هذه الأعمال بعد الإقرار.

النقل ليس آخر نقطة تحقق

قسم الإجابة الاختياري في NOTIFY مجرد تلميح غير آمن، ولا يجوز استعماله لتحديث البيانات المحلية. كما يعرّف RFC 1982 حساب الأرقام التسلسلية ويترك مقارنة مسافة نصف المجال غير معرّفة. لذلك يجب حفظ الرقمين ونتيجة المقارنة الفعلية.

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

الدليل الأخير هو استعلام مباشر لكل خادم موثوق عن SOA وعن سجل تغير فعلاً، مع فصل ذاكرة المحللات المؤقتة ومدة TTL عن حالة النشر الموثوق.

المصادر