غيّر DNS ترتيب السجلات. فأعاد المحوّل تشغيل نفسه.

Summary

• تقترح مسودة فردية بتاريخ 5 نوفمبر ترتيب إجابة DNS التي تتضمن CNAME: الاسم البديل المطلوب أولاً، ثم الروابط التالية في السلسلة، وأخيراً السجل النهائي. حُصرت القاعدة في الحالة التي كشفت عطلاً حقيقياً.
• يسجل وصف حادث يناير في المسودة فشل استعلامات glibc وإعادة تشغيل بعض المحوّلات عند حل أسماء خوادم NTP. تحدد وثيقة الدعم الرسمية من Cisco عائلات الأجهزة وخطأً قاتلاً في عملية DNSC.

لم يحتج الخطأ إلى حقل جديد. يستطيع محلّل DNS التكراري جمع أول CNAME واسم بديل تالٍ وعنوان A النهائي في قسم Answer واحد. وصفت RFC 1034 سجل CNAME بأنه قد يسبق الإجابة وأمرت بنسخ السجلات إليها، لكنها لم تحدد صراحة أن «النسخ» يعني إضافتها وفق ترتيب ثابت. تعامل طرف مع القسم كمجموعة، وقرأه آخر كسلسلة. في 8 يناير 2026 غيّر تحديث برمجي للمحلّل ترتيب مجموعات RRSet في إجابات CNAME. تقول ملحقة المسودة إن اختبارات الرجوع لم تلحظ ذلك لأنها عدّت الترتيب بلا أثر. فشلت عمليات glibc، وأعادت بعض المحوّلات تشغيل نفسها عند البحث عن اسم خادم الوقت المضبوط.

تذكر نشرة Cisco سلسلتي Catalyst 1200/1300 وCBS 250/350 وإصدارات برمجية محددة. تصف خطأ DNSC القاتل، وترجح ارتباطه ببعض صيغ إجابات DNS، وتقترح خادم DNS آخر أو وقف البحث بالأسماء أو تعييناً ثابتاً. لا تسرد عدداً شاملاً للأجهزة المتأثرة. يربط مؤلفو IETF الواقعة بترتيب CNAME؛ ولا تقيس السجلات الرسمية أثرها في كامل الشبكات.

تقترح مراجعة نوفمبر 02 إصلاحاً محدداً: يضيف الخادم CNAME الخاص باسم السؤال أولاً، ثم الروابط التالية بالترتيب، ثم سجل الوجهة المطلوب. يبقى ترتيب السجلات داخل مجموعة RRSet الواحدة غير مهم. ينبغي للعملاء قبول مجموعات CNAME بأي ترتيب، لكن لا يجوز للخوادم الاتكال على هذا التسامح. شملت مراجعة أغسطس 01 أقسام DNS على نطاق أوسع؛ وضيّقت المراجعة الجديدة المجال بعد ملاحظات فريق العمل. لا تزال صفحة IETF تصنفها مسودة فردية، ولن تحدّث RFC 1034 إلا إذا اعتُمدت.

المسألة توزيع كلفة البرمجيات القديمة: إخراج محافظ لدى الخادم وقراءة مرنة لدى العميل. يجب أن يحتفظ الاختبار بإصدار المحلّل، وبايتات الترتيبين، وسلسلة CNAME، ونتيجة glibc، واستعلام NTP، وسجل المحوّل. نجاح رمز استجابة DNS لا يثبت بقاء الجهاز عاملاً.