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

في هذه الورشة لا نبدأ من تعريف cache، بل من سؤال قرار يواجه resolver: هل لدي إجابة سلبية صالحة، أم أن الاسم موجود بلا هذا النوع، أم أن عملية الحل فشلت؟ تظهر الفروع على هيئة decision tree مع مؤقت انتهاء لكل إدخال. هذا يجعل مشاريع تخرج شبكات الحاسوب أكثر دقة من شاشة تعرض NXDOMAIN لكل مشكلة. يصف RFC 2308 التخزين السلبي لغياب الاسم أو مجموعة السجلات، ويتناول RFC 9520 تخزين حالات فشل الحل.

سير الاستعلام في المختبر

يرسل العميل السؤال؛ يفحص resolver مخزونه؛ إن وجد نتيجة صالحة يعيدها مع بيان أنها cached؛ وإلا يطلب من authoritative fixture نتيجة الحالة الحالية ويخزنها وفق سياسة السيناريو. عند تغيير zone fixture، لا تحذف الذاكرة تلقائياً، لأن هذا تحديداً ما يريد الطالب رؤيته. يستطيع المستخدم مسح cache يدوياً أو الانتظار إلى انتهاء TTL. اعرض كل خطوة في timeline مع الساعة الحالية ومصدر الإجابة. احفظ event log منفصلاً عن حالة cache حتى يمكن إعادة بناء سبب كل نتيجة لاحقة.

الأسماء المقارنة تحتاج normalization صحيحاً؛ لا تقارن الأحرف الكبيرة والصغيرة كما لو كانت اسمين مختلفين إذا كان النموذج يقرر التعامل معها وفق قواعد DNS. لا تدخل Unicode IDNs في النسخة الأولى إلا إذا حددت تحويلها واختبرته. إذا كان نوع السجل غير مدعوم، أظهر unsupported بدلاً من إرجاع NXDOMAIN. كذلك لا تجعل انقطاع الشبكة الاصطناعي يتحول إلى إجابة سلبية لمجرد أن كلاهما يعني «لم نصل إلى عنوان» للمستخدم.

ارسم شجرة القرار بدءاً من cache lookup: إدخال صالح يعاد مع مصدره؛ إدخال منتهٍ يزال ثم يجرب الاستعلام؛ لا توجد إجابة من authoritative فتسجل فئة الخطأ المناسبة. فرع الاسم الموجود بلا RRset يختلف عن فرع الاسم غير الموجود. لا تخلط SERVFAIL مع NXDOMAIN، ولا تحول timeout إلى نتيجة سلبية لمجرد أن العميل لم يحصل على عنوان.

مثال يوضح بقاء النتيجة القديمة

في الزمن صفر يسأل العميل عن lab.example وسجل A غير موجود؛ يعيد authoritative fixture حالة NXDOMAIN ويضعها المحاكي في cache لمدة افتراضية قدرها 30 ثانية. في الثانية الخامسة يضيف الطالب سجل A إلى fixture ثم يسأل ثانية. النتيجة تظل سلبية من cache مع إظهار 25 ثانية متبقية. بعد انتهاء الوقت، يعيد resolver السؤال فيجد الإجابة الجديدة. هذا المثال يشرح فكرة TTL فقط، والقيمة المختارة ليست توصية لتكوين DNS حقيقي ولا تمثل سلوك كل resolver.

أعد الحالة مع الاسم موجوداً لكن بلا AAAA، ثم أضف AAAA. ينبغي ألا يخلط التقرير بين هذه الحالة وبين عدم وجود الاسم كلياً. بعد ذلك افصل authoritative fixture لثوانٍ وشاهد كيف يسجل المختبر فشل الاستعلام. لا تفرض على المحاكي نتيجة بعينها عند فشل الشبكة من دون توثيق سياسته. يسجل الطالب timeline ويشرح لماذا يرى العميل استجابة تختلف عن الحالة الحالية للمصدر.

صمم ذاكرة قابلة للتفسير

يمثل المفتاح اسم DNS بعد normalization ونوع RRset، وتحتفظ القيمة بحالة الإجابة ووقت انتهاء صلاحيتها ومصدرها. عند استعلام جديد، يفحص resolver إن كان الإدخال موجوداً وما زال صالحاً. إذا انتهى TTL، يمسح الإدخال أو يضعه stale ثم يعود إلى المصدر authoritative. لا تجعل NXDOMAIN وNODATA وSERVFAIL قيمة واحدة: الأول يدل على عدم وجود الاسم، والثاني أن الاسم موجود لكن لا توجد إجابة لهذا النوع، والثالث فشل في الحصول على نتيجة موثوقة. هذا التمييز يساعد الطالب على قراءة RFCs بدقة.

في النموذج التعليمي، يمكن تمثيل negative TTL بوقت انتهاء محدد يقرأه المحاكي من إعداد المنطقة. وضح في الشرح أن التفاصيل الفعلية تتبع حقول الرسالة وقواعد المواصفة وتنفيذ resolver. لا تختزل الفرق بين RFC 2308 وRFC 9520 إلى قاعدة واحدة عامة عن كل خطأ. أضف لكل cache entry سبب إنشائه وقيمة الوقت المتبقي، واجعل ضغط زر «تقدم 10 ثوان» يؤدي إلى تحديث مرئي. لا تسمح بتعديل الساعة للخلف من غير تسجيل الحدث لأن ذلك قد يجعل TTL يبدو أطول من المتوقع.

اختبارات القبول وحالات الفشل

اختبر cache hit قبل انتهاء TTL، ثم miss بعده، وتغيير المصدر بعد تخزين نتيجة، ومسحاً يدوياً، وأسماء وأنواع سجلات متباينة. اختبر إدخال TTL صفري أو سالب، واسم غير صالح، ومصدر authoritative غير متاح، ونتيجة SERVFAIL. يجب أن يتضمن كل صف في سجل الأحداث المصدر ووقت القرار. كرر السيناريو بعد reset وتأكد أن النتيجة مطابقة. اختبر أيضاً تقدم الساعة ثم التراجع؛ إما أن يمنعه النظام أو يسجل أثره بوضوح. لا يكفي screenshot واحد لإثبات صحة الذاكرة.

خط الأساس هو سؤال مباشر للمصدر في كل مرة من دون caching. قارن عدد طلبات المصدر وزمن ظهور التغيير في السيناريوهات ذاتها، واذكر أن هذه أرقام المحاكي لا قياس لشبكة خارجية. مع cache، يتوقع أن ينخفض عدد استعلامات المصدر في حالة التكرار، لكن قد يتأخر ظهور التغيير حتى انتهاء المدة. يجب أن يكون هذا tradeoff واضحاً، وألا يصنف المختبر النتيجة القديمة عطباً غير مفسر.

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

حدد الحالة التي تريد شرحها

ابدأ بثلاث مكونات تعليمية: authoritative zone مصطنعة، resolver بذاكرة، وعميل يرسل استعلامات. لا تتصل بخادم DNS حقيقي ولا تغير إعدادات جهاز المستخدم. يتحكم الطالب في إضافة سجل أو حذفه وفي وقت المحاكاة. يسجل كل استعلام اسمه ونوعه ووقت الإرسال والنتيجة ومصدرها: authoritative أو cached. هذه التفاصيل تمنع الخلط بين «الاسم غير موجود» و«لم يصل رد»؛ فالأولى إجابة سلبية لها معنى، والثانية خطأ اتصال مختلف يمكن أن يخضع لقواعد تخزين أخرى.

اكتب نطاق المشروع في صفحة البداية: يدعم A وAAAA مثلاً، ويعرض نموذج TTL مبسطاً، ولا يطبق كل أنواع السجلات أو كل سياسات resolver. لا تسمي النتيجة محاكاة كاملة لبنية الإنترنت؛ الهدف درس قابل لإعادة الإعادة حول cache state. سجل قيم TTL كما دخلت، والوحدة بالثواني، وحدد هل ساعة المختبر تتقدم آلياً أم يغيرها الطالب. بذلك يمكن مقارنة توقيت الانتهاء على نحو ثابت.

مخرجات المشروع والقيود

يمكن تسليم الورشة ضمن مشاريع التخرج أو تطويرها في المشاريع البرمجية: واجهة timeline، نموذج cache، ملفات سيناريو، وتقرير يشرح حالات RFC. أرفق مجموعة fixtures صغيرة يستطيع المشرف تشغيلها دون شبكة، ورسماً يوضح العميل والresolver والـauthoritative zone. إذا أردت ربط أداة خارجية لاحقاً، اعمل داخل بيئة اختبار تملكها واطلب الإذن اللازم، ولا تغير DNS عام لغرض العرض.

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