الراية التي لم تقل إن الفحص قد اكتمل

الخلاصة

• تشير DO إلى القدرة على قبول سجلات الأمان، لا إلى أن التحقق من التوقيعات قد انتهى. تبقى شروط RRSIG مرتبطة بطريقة الإجابة وحالة المنطقة والطلب.
• أتاح RFC 8482 إجابات ANY صغيرة وغير فارغة، يمكن حفظها بالطريقة المعتادة، لتقليل تكرار السؤال من دون اشتراط تعديل جميع العملاء.
• قد يحجب HINFO المصطنع سجلا حقيقيا من النوع نفسه داخل الذاكرة المؤقتة. لذلك تشمل كلفة الاختيار معنى السجل ومدة بقائه، لا حجم الرد وحده.

إعلان استعداد لا شهادة إنجاز

عرّف RFC 3225، في ديسمبر 2001، راية DO في أعلام سجل OPT الخاص بامتداد EDNS. وظيفتها التعبير عن قدرة الطرف السائل على قبول سجلات أمان DNSSEC. لا تقول إن ذلك الطرف أجرى التحقق بالفعل، ولا إن كل ما طلبه التطبيق متاح في الجواب.

هذه الدقة مهمة عند قراءة رد مقتضب على ANY. ربما يحتوي الرد على مجموعة واحدة وتوقيعها المناسب، بينما لا يعرض أنواعا أخرى موجودة للاسم. التوقيع يتعلق بالمجموعة المعادة؛ لا يتحول إلى تعهد بأن كل نوع آخر قد أُدرج أو نُفي وجوده.

ليس المطلوب إعادة تطبيق إجراءات التوقيع القديمة الواردة في وثيقة 2001 على إجابة حديثة. دورها هنا توضيح معنى الإشارة. أما شروط RRSIG للإجابات الصغيرة فتأتي من RFC 8482، الصادر في يناير 2019.

حدّد هذا المعيار سلوكا اختياريا للمبادِرين والمجيبين، وعدّل RFC 1034 وRFC 1035. لم يحظر ANY، ولم يلزم جميع الخوادم بكتابة HINFO. سمح للمجيب بأن يختار جوابا أصغر ضمن قواعد واضحة، وبأن يستفيد من سلوك موجود أصلا عند الطرف الآخر: حفظ الإجابة.

لماذا لم يكن الرفض كافيا؟

للنوع ANY استخدامات مشروعة، منها التشخيص وفحص حالة بيانات اسم ما. وُجدت أيضا تطبيقات تحاول جمع MX وA وAAAA بسؤال واحد. لكن هذه الراحة لا تثبت أن السؤال يصل إلى خادم موثوق لكل تلك البيانات، أو أن كل المجموعات الموجودة ستعود. على التطبيق أن يوفر طريقة أخرى للحصول على ما يحتاجه إذا لم يتحقق افتراضه.

في المقابل، قد يكلف تكوين الإجابة الواسعة عملا إضافيا، وقد يساعد على جمع بيانات كثيرة دفعة واحدة. كما أن سؤال UDP صغيرا يستدعي ردا كبيرا يمكن أن يزيد جاذبية الخادم في هجمات الانعكاس التي تزور عنوان المصدر. يصغر هذا الحافز عندما يصغر الرد، لكن ذلك لا يجعل كل استخدام لـANY هجوما ولا يحول بقية DNS العام إلى معلومات سرية.

ناقش RFC 8482 اقتراح استخدام رمز استجابة جديد ليقول المجيب إنه لا يقدم الإجابة التقليدية. المشكلة أن محلّلات تلقت الرمز غير المألوف حاولت سؤال خوادم موثوقة أخرى متاحة. كان الرفض يغير جهة السؤال، لا ينهيه بالضرورة.

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

ANY لا يمحو حدود السؤال

في RFC 1035، المنشور في نوفمبر 1987، عُرّف نوع السؤال 255 بالنجمة. شاع اسم ANY في التطبيقات. وتصفه سجلات معلمات DNS لدى IANA الآن بأنه طلب لبعض السجلات المتاحة في الخادم أو كلها. وتبقى HINFO مسجلة بالنوع 13 لمعلومات المضيف.

هذه قيود ودلالات مسجلة، وليست إحصاء لاعتماد طريقة بعينها اليوم. كذلك لا تعني النجمة هنا البحث عن جميع الأسماء. يفصل RFC 1034، من نوفمبر 1987 أيضا، بين الاسم QNAME والنوع QTYPE والفئة QCLASS. اختيار ANY في خانة النوع ليس اسما ذا علامة بدل، وليس نقل منطقة AXFR.

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

تنطبق طرق RFC 8482 المعنية هنا على اسم موجود، وفئة IN، ونوع سؤال ANY. تظل القواعد المعتادة سارية فيما عدا التغييرات المحددة. لا تمنح السياسة المجيب رخصة اختراع وجود اسم غير موجود، ولا تسويغ وصف اسم قائم بأنه NXDOMAIN لمجرد تجنب الإجابة الواسعة.

مجموعة كاملة، وقائمة ناقصة

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

لكن الاختيار يقع بين مجموعات، لا بين أعضاء المجموعة الواحدة اعتباطا. يعرّف RFC 2181، الصادر في يوليو 1997، RRset من خلال الاسم والفئة والنوع، مع إمكان اختلاف البيانات بين السجلات. إذا كانت مجموعة العناوين تحتوي عدة سجلات، فلا يساوي انتقاء سجل واحد منها إعادة المجموعة كاملة.

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

سجل قديم يؤدي عملا جديدا

في الطريقة الثانية يمكن تكوين HINFO عندما لا يوجد CNAME عند الاسم المطابق. توصي الوثيقة بسجل واحد تكون فيه سلسلة CPU هي RFC8482 وسلسلة OS فارغة. لا يتطلب ذلك إضافة السجل إضافة دائمة إلى بيانات المنطقة.

صُممت HINFO في RFC 1035 من سلسلتين نصيتين، للمعالج ونظام التشغيل. وكان من أغراضها التاريخية إتاحة إجراءات، مثل بعض إجراءات FTP، تختلف بحسب تشابه الآلات وأنظمتها. استعار الرد الجديد البنية نفسها لكي يحصل العميل على شيء مألوف يمكن حفظه.

عندما نعلم أن السجل كُوّن بهذه الطريقة، لا يكون الرقم في CPU قياسا لمعمارية معالج. كما أن OS الفارغة سلسلة بطول صفر ما زالت موجودة في البنية، لا خانة مفقودة ولا تقريرا بأن الآلة بلا نظام تشغيل.

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

وبصورة منفصلة، تسمح الوثيقة بالحفظ المعتاد، وبإمكان استخدام HINFO المطابق المحفوظ لتقليل إرسال ANY أو الإجابة من الذاكرة كالمعتاد. ينبغي الاحتفاظ بالجانبين معا: الاستفادة المسموح بها من الذاكرة، وعدم الادعاء بأن القيم وحدها تثبت كيفية إنشاء السجل.

الصغر لا يعفي من شروط التوقيع

في طريقة اختيار مجموعات موجودة من منطقة موقعة، تُرفق توقيعات RRSIG المناسبة. وفي طريقة HINFO المصطنع، إذا كانت DO مضبوطة وكان المجيب يعرف أن المنطقة موقعة، يلزم توقيع صحيح. عندما تكون DO صفرا، تقول الوثيقة إنه ينبغي حذف التوقيع في هذه الطريقة.

توجد طريقة ثالثة تحاول تخمين حاجة السائل، فتختار مجموعات موجودة مثل CNAME أو MX أو A أو AAAA وتستبعد أنواعا أخرى مثل TXT وDNSKEY. إذا كانت المنطقة موقعة وطلب الطرف سجلات DNSSEC عبر DO، تنطبق متطلبات التوقيع المناسبة أيضا. قد تكون هذه الإجابة أكبر، ولا يضمن التخمين أنه عرف قصد التطبيق.

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

ما يبقى في الذاكرة قد يخفي شيئا آخر

على المشغل اختيار TTL قابل للضبط: طويل بما يكفي لتقليل الأسئلة المتكررة من المبادِر نفسه عن الاسم نفسه، من دون أن يعرقل تغيير سياسة ANY لاحقا أكثر مما يريد. لا تعطي الوثيقة رقما واحدا صالحا لكل خدمة.

ويذكر RFC 2181 أن TTL حد أقصى للاحتفاظ، لا التزام بأن كل ذاكرة ستحتفظ بالسجل حتى آخر ثانية. قد تضع التطبيقات سقفا أقل. لا توجد بذلك ساعة انتهاء عالمية موحدة، ولا تؤدي إعادة إعداد الخادم الموثوق إلى محو النسخ البعيدة فورا.

هناك كلفة أدق: قد يحجب HINFO المصطنع المحفوظ سجلا حقيقيا في المنطقة عندما يأتي لاحقا سؤال مباشر عن HINFO. يحذر RFC 8482 المشغلين الذين يعتمدون على الاستخدام العادي لهذا النوع، ويقترح عليهم اختيار مجموعات موجودة أو نوع آخر. الاعتقاد بأن HINFO كان نادر الاستخدام في رصد مؤلفي الوثيقة سنة 2019 لا يساوي إثبات انعدام قيمته، ولا إحصاء جديدا لعام 2026.

ولا يساوي هذا الحجب إجابة سلبية عن الأنواع المحذوفة. يميز RFC 2308، الصادر في مارس 1998، بين خطأ الاسم NXDOMAIN وغياب بيانات النوع المطلوب الذي يستدل عليه ضمن رد NOERROR مناسب، مع قواعد خاصة للحفظ السلبي وبيانات SOA. مجموعة صغيرة غير فارغة في ANY ليست نفيا عاما لكل ما لم يظهر.

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