الخلاصة

  • تنطلق RFC 5625 التي ألّفها Ray Bellis من أن وسيط DNS بسيطًا لا يستطيع تنفيذ كل الوظائف الحالية والمستقبلية. لذلك تمر الرايات والتسميات والأنواع والفئات المجهولة، وتبقى الاستجابة كاملة مع EDNS وTC وTCP والبايتات الحساسة للتوثيق؛ أما الرسائل المشوّهة فعلًا والسياسة النشطة فيجب أن تظهر بوصفها رفضًا صريحًا.
  • نُشرت الوثيقة سنة 2009 بوصفها BCP 152، لكنها لا تثبت امتثال الأجهزة الحالية أو التبنّي الشامل. كما أن التمرير الشفاف ليس تحقق DNSSEC. إسهامها الدائم هو فصل السلطة: المواصفات والطرفان يملكان المعنى، والوسيط يدير حالة محدودة وواجهاته وخيارات محلية قابلة للإسناد.

حين يصبح الصمت قرارًا في البروتوكول

يرسل تطبيق استعلامًا يتضمن راية جديدة في ترويسة DNS. يفهمها العميل، ويفهمها المحلّل التكراري في الطرف الآخر. لا تصل الحزمة. يعيد العميل المحاولة، ثم يتوقف بعد انتهاء المهلة. السبب جهاز بينهما صُمّم يوم كانت تلك الخانة محجوزة للصفر؛ رأى القيمة الجديدة وأسقط الرسالة من دون رد.

لم يختلف الطرفان. لكن البرنامج الثابت القديم قرر، من غير تفويض، أي توسعات DNS يمكن أن تعمل.

تعالج RFC 5625، وعنوانها DNS Proxy Implementation Guidelines، هذا النوع من السلطة العارضة. نُشرت في أغسطس 2009 بوصفها Best Current Practice 152، ويحمل النص اسم Ray Bellis وحده، وكان آنذاك في Nominet UK. تقر الوثيقة بأن بوابات المنازل محدودة العتاد، وأن دورات تحديثها طويلة، وأن وظائف DNS المستقبلية لا يمكن حصرها مسبقًا.

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

عينة تاريخية وليست تعدادًا للحاضر

يوثّق الملخص التنفيذي لتقرير SAC035 والتقرير الكامل اختبارات مضبوطة أُجريت في يوليو وأغسطس 2008 على 24 موجّهًا منزليًا أو جدارًا ناريًا لمكتب صغير.

استطاعت الأجهزة الأربعة والعشرون توجيه استعلامات DNSSEC مباشرة إلى محللات أعلى. وقدّم 22 جهازًا وضع الوسيط أيضًا، وواجهت ستة من تلك الوسائط مشكلات مع رايات متصلة بـDNSSEC أو استجابات جرى التحقق منها. قيّد 18 جهازًا استجابات UDP عند 512 بايت أو حجم متعلق بـMTU؛ وأعاد أربعة فقط استجابات تصل إلى 4096 بايت، ولم يمرّر DNS عبر TCP سوى جهاز واحد. كان ستة أجهزة متوافقة بالكامل في الإعداد الافتراضي، وأمكن إعادة إعداد تسعة أخرى لتجاوز عدم توافق الوسيط.

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

يسجل محضر موافقة IETF إجماعًا قويًا في مجموعة DNS Extensions واهتمامًا من البائعين والمشترين. هذه بينة على مسار الوثيقة والحاجة إليها، وليست قياسًا للتنفيذ بعد النشر.

المجهول ليس رسالة فاسدة

أهم فصل في RFC 5625 هو الفصل بين قيمة لا يفهمها الوسيط وبنية لا يمكن أن تكون صحيحة. إذا ظهرت راية مجهولة في ترويسة DNS، يتجاهل الوسيط معناها في منطقه الداخلي لكنه يمرر الحزمة. ويسري الأمر على صيغ التسميات وعلى QTYPE وQCLASS وقيم TYPE وCLASS في سجلات الموارد.

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

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

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

اكتمال الإجابة موجود في TC وTCP أيضًا

إذا قطع الوسيط استجابة UDP بعد 512 بايت ولم يضع راية TC، فهو لا يحذف سجلات فحسب؛ بل يجعل الجزء الباقي يبدو جوابًا كاملًا. وإذا أزال TC التي وضعها الخادم، حذف تعليمات إعادة المحاولة عبر TCP.

تقول RFC 5625 إن تجاوز 512 بايت ليس سببًا كافيًا للقطع. وإذا فرض حد محلي القطع، وجب وضع TC، ولا يجوز إزالة TC القادمة من الأعلى. يستطيع العميل التعافي من حد معلن، لكنه لا يستطيع استعادة معلومات غابت في صورة نجاح.

ويجب أن يستقبل الوسيط DNS عبر TCP ويمرره. إذا وصل استعلام العميل عبر TCP، يستمر إلى الخادم الأعلى عبر TCP بدل تخفيضه إلى UDP أولًا. وقد جعلت RFC 7766، التي شارك Bellis أربعة مؤلفين آخرين في كتابتها لاحقًا، دعم TCP مطلبًا في تنفيذ DNS. تؤكد الوثيقة اللاحقة حد النقل، لكنها لا تثبت امتثال كل جهاز.

يجسّد سجل OPT في EDNS قابلية التوسّع. لا ينبغي أن يؤدي وجوده إلى الرفض. وتوضح RFC 6891 لاحقًا أن الصناديق الوسيطة الممتثلة لا تفرض سقف UDP القديم البالغ 512 بايت، وأن الممرر البسيط لا يعدّل محتوى OPT ولا يحذفه في الاتجاهين. أما توصية 4096 بايت في وثيقة 2009 فتنتمي إلى سياق تنفيذها، وليست حدًا أبديًا.

الشفافية لا تلغي سطح التشغيل

الوسيط الرقيق ليس سلكًا. يربط الاستجابة بعميلها، ويقرر مدة الحالة، ويختار المحلل الأعلى، وقد يغير Query ID الصادر. كما يحدد الواجهات التي تستقبل الطلبات والعنوان الذي يعلنه DHCP.

تحيل RFC 5625 إلى RFC 5452 لزيادة مقاومة الإجابات المزوّرة، ومنها عشوائية معرّفات الاستعلام ومنافذ المصدر. تقلل العشوائية بعض فرص التزوير، لكنها لا توثّق الجواب ولا تستبدل DNSSEC.

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

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

ويبقى طريق الخروج. ما لم تمنع سياسة صريحة ذلك، ينبغي أن يتمكن المستخدم من تحديد محلل أعلى وتجاوز الوسيط. التقاط كل البدائل يحوّل خدمة مريحة إلى نقطة اختناق دلالية إلزامية.

اختبار Bellis يبدأ بما لا تعرفه الآلة

تسرد صفحة Ray Bellis في IETF Datatracker عشر وثائق RFC، بينها RFC 5625. وتعرّفه صفحة فريق ISC حاليًا بأنه Director of DNS Operations. تظهر النظرة التشغيلية في معيار النجاح: ليس عدد الميزات التي تسميها الواجهة، بل ما يحدث عند ظهور قيمة غير متوقعة.

هل تمر الراية الجديدة؟ هل يحتفظ النوع المجهول بالبايتات نفسها؟ هل تصل TC وOPT؟ هل يبقى TCP عبر الطريق؟ وهل يستطيع المشغل التمييز بين حظر مقصود وجهل البرنامج الثابت؟

تحول RFC 8906، التي ألّفها لاحقًا Mark Andrews وRay Bellis، الحقول والأنواع وإصدارات EDNS وخياراته وراياته غير المتوقعة، إلى جانب القطع وTCP، إلى حالات اختبار صريحة. وبذلك يتحول الصمت الغامض إلى نتائج قابلة للمقارنة.

لا تعني شفافية RFC 5625 تحقق DNSSEC أو ضمان الخصوصية والتوافر. ولا تمنع المشغل من اختيار خادم أعلى أو حماية الواجهة أو تطبيق سياسة معلنة. الحد أدق: لا يملك الوسيط، لمجرد أنه في المنتصف، حق تعريف ما لا يعرفه. يدير الطريق، لكنه لا يملك معنى البروتوكول الذي يعبره.

المصادر