الخلاصة

  • يقارن DNS حروف ASCII من دون اعتبار لحالتها، مع أن خوادم كثيرة تنسخ هيئة السؤال نفسها إلى الرد. حاول DNS-0x20 جعل هذه المطابقة الدقيقة جزءاً مؤقتاً من هوية المعاملة.
  • لا يضيف كل حرف مؤهل أكثر من بت واحد، وقد تمحو الخوادم أو الوسائط تلك البتات. كما يلزم استرجاع السؤال قبل فك الضغط ومنع التراجع القابل للإجبار. لم تكن الآلية توثيقاً، وانتهت المسودة من دون أن تصبح RFC نهائية.

الاسم واحد، لكن شرط القبول تغيّر

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

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

لذلك لم يمنح DNS-0x20 الحروف الكبيرة معنى جديداً داخل فضاء الأسماء. لقد استعار تمثيلاً متسامحاً لاستخدامه حالة عابرة بين إرسال السؤال ووصول الرد.

قرار قديم فصل الهوية عن المظهر

تنص RFC 1035، الصادرة سنة 1987، على أن المقارنات الرسمية في DNS لا تميز بين حروف ASCII الكبيرة والصغيرة. فالاسمان المختلفان في الحالة فقط متطابقان بروتوكولياً. وفي الوقت نفسه تطلب الوثيقة الحفاظ على الحالة الأصلية متى أمكن وتقليل فقدها.

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

أوضحت RFC 4343 لاحقاً أن القاعدة تخص A-Z وa-z في ASCII، وليست تحويلًا لغوياً عاماً ولا بديلاً من IDNA. كما أن حفظ الهيئة ليس ضماناً: قد تتشارك كتابتان موضع تخزين واحداً، وقد تجعل آلية ضغط الأسماء تمثيل ملصق في الرد معتمداً على بايتات في موضع آخر من الرسالة.

وجد مقترح 0x20 فرصته بين قاعدتين: التكافؤ واجب، أما بقاء الهيئة فكان شائعاً لكنه مشروط.

بت عشوائي داخل كل حرف متاح

قدمت مسودة الإنترنت Use of Bit 0x20 in DNS Labels في مارس 2008 طريقة لتبديل بت 0x20 عشوائياً في كل حرف ASCII من QNAME. هذا البت هو الذي يفصل بين الشكل الكبير والصغير. يطوي الخادم الفرق عند البحث، بينما يتعامل صاحب السؤال مع كل نمط بوصفه تحدياً مختلفاً طوال عمر الاستعلام.

اعتمدت الفكرة على نسخ قسم Question من الطلب إلى الرد كما هو. ذكر المؤلفون أن الخوادم السلطوية الرئيسية التي اختبروها آنذاك كانت تنسخ الاسم بتاً ببت، رغم أن مواصفات DNS لم تكن تلزم بحفظ الحالة في النسخة. ورصدوا أيضاً تطبيقات قليلة تحوّل السؤال كله إلى حروف صغيرة. تلك ملاحظة مؤرخة بعام 2008 وليست ضماناً لكل شبكة لاحقة.

تضع RFC 5452 الفكرة في سياق قبول الردود: يجب أن يتوافق السؤال، وأن تتطابق هوية المعاملة والعناوين والمنافذ والفئة والنوع. حتى المعرّف العشوائي الكامل ذي 16 بتاً يبقى هدفاً محدوداً، ويزيد المنفذ المصدري غير المتوقع فضاء التخمين. أراد 0x20 إضافة اختيارات أخرى موجودة أصلاً داخل QNAME.

هذه زيادة في كلفة التخمين، لا في سلطة البيانات. لم ينشأ توقيع أو سر مشترك أو إثبات للمنشأ. وإذا خمن رد مزور كل العناصر قبل الرد الصحيح، فلا تمنعه الحالة وحدها.

لم تكن الحماية متساوية بين الأسماء

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

لا يكفي إذن مؤشر «0x20 مفعّل». يجب عد الحروف في السؤال الفعلي، وفحص عدم قابلية النمط للتنبؤ، وقياس عدد الاختيارات التي بقيت حتى الرد. الإعداد واحد، لكن ميزانية التخمين تتغير مع كل اسم ومسار.

ولا يجوز توسيع العد تلقائياً إلى الملصقات الدولية. تفصل RFC 4343 قواعد ASCII عن معالجة IDNA. وقد يغيّر تطبيق قواعد حالة لغوية على القيمة المنقولة الاسم نفسه بدلاً من أن يضيف تمثيلاً متكافئاً.

يستطيع وسيط سليم محو التحدي

قد يحوّل ممرر DNS السؤال كله إلى حروف صغيرة ثم يعيد مجموعة السجلات الصحيحة. وفق دلالة DNS الأساسية لم يغيّر الاسم. لكنه، وفق اختبار 0x20، أزال الحالة التي ينتظرها المحلّل.

تكشف هذه المفارقة تبعية موزعة. ينشئ المحلّل النمط، لكن الخادم السلطوي والممررات وأجهزة الفحص تقرر عملياً هل يعود. لم يكن سلوك النسخ الذي رُصد في منتجات 2008 تعهداً من كل تنفيذ مستقبلي.

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

يجب أن تختفي العشوائية قبل الذاكرة المخبأة

تسمح رسائل DNS بضغط الأسماء بواسطة مؤشرات. فقد يشير اسم في أقسام Answer أو Authority أو Additional إلى الاسم الموجود في Question. إذا فك المحلّل الضغط والنمط العشوائي ما زال في السؤال، يمكن أن تنتقل تلك الهيئة إلى الذاكرة المخبأة ثم إلى ردود لاحقة.

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

هذه الخطوة أهم من مجرد توليد العشوائية. عندما تتحول مساحة تمثيل متسامحة إلى nonce، يجب تحديد لحظة إزالتها. وإلا أصبحت حماية معاملة واحدة مصدراً لتغيير حالة مشتركة تخص مستخدمين آخرين.

التراجع السهل يفتح سطحاً للخفض

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

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

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

DNSSEC يمحو الفرق نفسه بقصد مختلف

تعرّف RFC 4034 الصيغة القانونية لسجلات DNSSEC بفك ضغط الأسماء وتحويل حروف ASCII الكبيرة ذات الصلة إلى صغيرة. يحتاج الموقّع والمدقق إلى بناء السلسلة الثمانية نفسها حتى يكون التوقيع قابلاً للتحقق.

يريد 0x20 بقاء اختلاف عشوائي في رحلة واحدة. ويريد DNSSEC إزالة الاختلاف لتوثيق بيانات قانونية. التطابق الدقيق يزيد صعوبة التخمين فحسب؛ أما التوقيع الصحيح فيستطيع ربط RRset بسلسلة سلطة. لا يقوم أحدهما مقام الآخر.

ما تبقى من وثيقة منتهية

انتهت صلاحية مسودة DNS-0x20 في سبتمبر 2008. لم تصبح RFC، ولا تصلح قائمة تطبيقاتها دليلاً على الانتشار الحالي. قيمتها التاريخية في نموذج التفكير الذي عرضته.

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

لم تغيّر الحروف الكبيرة معنى الاسم. لكنها، طوال استعلام واحد، غيّرت ما يقبله المحلّل بوصفه رداً مناسباً.

المصادر والحدود

يعتمد المقال على RFC 1035 وRFC 4343 وRFC 5452 وRFC 4034 وعلى مسودة DNS-0x20 الصادرة في مارس 2008. لا تثبت هذه المصادر الإعدادات الافتراضية الراهنة أو نسب الانتشار أو التوافق العالمي اليوم.