راي بيليس: من يحمل مخاطرة ما لا تفهمه الشبكة

الخلاصة

• الوثيقة الأولى (RFC 5625) صدرت في أغسطس 2009 كـ BCP 152 بكاتب واحد، ووثيقة BCP 152 لا تضمّ سوى معيار واحد حسب صفحة المحرر؛ والثانية (RFC 8490) معيار مقترح من مارس 2019 بستة كتّاب.
• الأفعال القوية في الأولى تُستخدم أساسًا لمنع التدخل، وفي الثانية لإنشاء حالة مشتركة؛ وكلتاهما لا تبلغ من يقرر ألا ينفّذ. والسجل يحفظ الرقم بعد الكاتب، ولا يحفظ أن أحدًا يشغّله.

درع مقابل بناء

الفرق بين الوثيقتين ليس في التقنية وحدها، بل في موضع المخاطرة. الوسيط في الشبكة المنزلية يستقبل حزمة من امتداد لم يسمع به، والخيار المتاح له أن يمرّرها كما هي أو أن يخترع سلوكًا لا يعرفه أحد. النص الأول يختار الدرع: يُلزم الوسيط بأن يتجاهل أي علم غير معروف في DNS وأن يمرّر الحزمة كالمعتاد، وأن يضع بت TC إن اضطر إلى تقليص استجابة من طرف واحد، وأن يكون قادرًا على تمرير حزم تحوي سجلات TKEY (نص RFC 5625).

وما هو إيجابي في النص جاء بدرجة أضعف. الفقرة 3 توصي بأن يكون الوسيط شفافًا قدر الإمكان، والفقرة 4.4.1 تقول إنه عند استقبال طلب عبر TCP ينبغي تمريره عبر TCP وألا تُجرَّب UDP أولًا، والفقرة 5.2 توصي بأن تكون القيمة الافتراضية للخيار الموصوف فارغة. هذا اختيار محسوب لا جبن: جهاز يُشترى اليوم قد يبقى في الخدمة بعد سنوات، وأقوى ما يصلح لِذاك الأفق هو قاعدة واحدة — لا تعترض طريق ما لا تفهمه.

الوثيقة الثانية تعمل في اتجاه معاكس. هنا لا يوجد طرف ثالث يُحتمى به، بل طرفان ولا شيء بينهما بعد. الفقرة 5.1 تمنع الخادم من بدء رسائل طلب DSO أو الرسائل أحادية الاتجاه قبل أن تكون الجلسة قد أُنشئت بالتراضي. والفقرة 5.1.1 تمنع الخادم الذي ينفّذ DSO من إعادة DSOTYPENI على طلب Keepalive، لأن حقل Keepalive إلزامي التنفيذ. والفقرة 5.4.1 تعتبر استجابة DSO بمعرّف رسالة صفر خطأً قاتلًا يوجب قطع الاتصال فورًا (نص RFC 8490).

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

صفحة التصحيحات الفارغة

الاختبار الأرخص لأي قارئ خارجي هو سجل التصحيحات. في 18 أكتوبر 2026 لم تُظهر صفحة تصحيحات RFC 5625 ولا صفحة تصحيحات RFC 8490 أي مدخل، ولم تُشر أي من صفحتي المعلومات إلى وثيقة لاحقة أو مُبطِلة. هذه ملاحظة عن الصفحات في ذلك اليوم، ولا شيء أكثر.

وللفراغ قراءتان متطابقتان في المظهر: نص صمد أمام الاستخدام، أو نص لم يتقدم أحد لتصحيحه. ولا يميّز بينهما إلا من يقرأ ما هو أبعد من الصفحة. الأمر نفسه ينطبق على تاريخ الصياغة: سجلا Datatracker لـ RFC 5625 ولـ RFC 8490 كانا متاحين كملخصات صفحات لا كتاريخ مراجعات كامل، فيظهر نصف السلسلة فقط: نعرف أن إحداهما مرّت عبر DNSEXT والأخرى عبر DNSOP، ولا نعرف أي مسودة أنتجت أي جملة.

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

رقم يبقى بعد صاحبه

في سجل معاملات DNS لدى IANA يظهر OpCode بالقيمة 6 بوصفه DNS Stateful Operations مع إحالة إلى RFC 8490، وإلى جانبه جدول DSO Type Codes بأكواد 0x0001 KeepAlive و0x0002 RetryDelay و0x0003 EncryptionPadding. ثلاثة أسطر أُسندت إجراءً وبقيت محفوظة بوظيفة إدارية لا تعتمد على كاتب الوثيقة.

هذا هو الجزء الذي يدوم فعلًا. توقيع معيار واقعة مؤرَّخة، أما سطر في السجل فهو علامة تُقرأ بعد أن يتغيّر عمل الكاتب وشركته واهتمامه. لكن الدوام للسجل لا لصاحبه: IANA تحفظ أن الرمز موجود، لا أن أحدًا يرسله.

ما يملكه الكاتب فعلًا

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

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