الخلاصة

  • يحافظ RFC 10029 على سؤال DNS أساسي واحد، ويطلب QTYPE إضافية عبر EDNS. لا تسرد استجابة MQTYPE-Response إلا الأنواع الإضافية التي عولجت كاملة تحت RCODE والأعلام الملائمة نفسها للاستجابة الأساسية.
  • لا تصنع الحزمة المشتركة لقطة ذرية بين الأنواع. يجب سؤال الأنواع المحذوفة منفردة، بينما تحتفظ مجموعات RRset المعادة بنطاقها وموقّعها وTTL وحالة التخزين والتحقق وقرار التطبيق كأدلة مستقلة.

لنبدأ من نهاية المسار. اختار التطبيق عنواناً وفتح اتصالاً، ثم كتب نظام المراقبة أن «استعلام DNS نجح». لكن الطلب الأصلي كان يحتاج A وAAAA وHTTPS. وضعت A في السؤال الأساسي، وأضيف النوعان الآخران في خيار متعدد الأنواع. أدرجت الاستجابة AAAA في قائمة الأنواع المكتملة ولم تدرج HTTPS.

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

RFC 10029، المنشور في مسار المعايير في يوليو 2026، يعالج الحاجة إلى جلب أنواع مترابطة من دون إرسال سؤال مستقل منذ البداية لكل نوع. لكنه لا يضيف عدة أسئلة عادية. فقد حسم RFC 9619 أن رسالة QUERY لا يجوز أن تحمل QDCOUNT أكبر من واحد، وإلا عوملت كرسالة مشوهة.

لهذا يبقى QNAME وQCLASS وQTYPE الأساسي واضحاً، وتنتقل قائمة أنواع البيانات الإضافية داخل EDNS. التجميع يختصر النقل، ولا يخلط هوية السؤال الأساسي ببقية الاحتياجات.

ما طُلب ليس ما اكتمل

يحمل MQTYPE-Query الرمز 20، وتحمل MQTYPE-Response الرمز 21. يسجل سجل IANA لمعاملات DNS الخيارين بوصفهما اختياريين ويحيل إلى RFC 10029.

الفصل بين الرمزين يمنع وسيطاً يكرر خيار الطلب آلياً من الظهور كأنه أنشأ شهادة اكتمال. السؤال الأساسي مع الأنواع الواردة في خيار الاستجابة هو إيصال ما أجيب عنه كاملاً.

حتى القائمة الفارغة مفيدة: الخادم فهم الامتداد، لكنه لم يكمل أي نوع إضافي. أما غياب خيار الاستجابة، أو عودة خيار الطلب خطأ، أو تكرار نوع، أو FORMERR، فيعيد العميل إلى الاستعلامات العادية للأنواع التي ما زال يحتاجها.

ولا يحل ANY محل هذا الإيصال. يسمح RFC 8482 برد أدنى على ANY، وقد يختار الخادم RRset واحدة فقط. لا يعد RFC 10029 بكل شيء؛ بل يعلن بدقة ما اكتمل في هذه الاستجابة.

الاستجابة الأساسية تحكم الرأس المشترك

يبني الخادم أولاً نتيجة QTYPE الأساسي ويقرر RCODE والأعلام مثل AA وAD وTC. إذا احتاجت النتيجة الأساسية إلى البتر، فلا يعالج الأنواع الإضافية من أجل الدمج.

بعد ذلك يفحص كل نوع إضافي كما لو كان سؤالاً منفرداً. لا يدخل في الحزمة إلا إذا وافق RCODE والأعلام اللازمة للنتيجة الأساسية. لا يجوز إخفاء SERVFAIL لنوع إضافي تحت NOERROR للنوع الأساسي. وعند حد نطاق، قد تكون إجابة DS من جهة الأب سلطوية بينما لا تحمل بيانات NS هناك علم AA نفسه؛ لا يمكن وضع الاثنين تحت وصف واحد من دون تشويه أحدهما.

يقدم RFC 2181 سياق ترتيب بيانات DNS، لكن الترتيب المتساوي لا يعني ناشراً واحداً أو قرار نشر واحداً أو سلسلة إثبات واحدة.

النوع المكتمل يجب أن يدخل كاملاً

تدمج سجلات كل QTYPE إضافي في الأقسام التي كانت ستظهر فيها لو كان السؤال منفرداً، وتزال النسخ المكررة داخل القسم. غير أن إدراج النوع في قائمة الاستجابة لا يحدث إلا إذا أمكن وضع كل ما يلزم لتلك المجموعة.

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

يضيف RFC 6891 حدود المسار. لا تُخزن OPT مؤقتاً، وحجم UDP المعلن خاص بالمعاملة ولا يضمن أن الطريق أو الجدار الناري يقبل القيمة نفسها. يجب على الوسطاء المطابقين ألا يحذفوا الخيار، لكن المعيار لا يثبت سلوك كل طريق منشور. يلزم ربط دليل الدعم بالمسار والمحاولة.

الإغفال ليس نفياً

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

غياب HTTPS من MQTYPE-Response ليس دليلاً على عدم وجود HTTPS. لا يمثل إجابة سلبية كاملة وفق RFC 2308، ولا يحمل تلقائياً دليل الإنكار الموثق في RFC 4035. كما لا يثبت حجباً أو عطلاً أو عدم أهمية.

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

الوصول معاً لا يوحد الزمن أو الموقّع

ينبه RFC 10029 إلى أن السجلات قد تأتي من نطاقات DNS مختلفة، وأن أدلة عدم الوجود قد يصدرها موقّعون مختلفون. تختلف قيم TTL، وقد تكون RRset دخلت الذاكرة في أوقات متباعدة. الحزمة الواحدة تجمع التسليم ولا تخلق لحظة نشر مشتركة.

تحمي مصطلحات RFC 9499 هذا الفرق: RRset، والخادم السلطوي، والمحلل العودي، والذاكرة المؤقتة أدوار مستقلة. لا ينبغي لقاعدة الأدلة أن تختصرها إلى خانة واحدة باسم نجاح DNS.

وإذا وصلت HTTPS كاملة، يبقى قرار العميل. يحدد RFC 9460 معالجة الأولويات والمعاملات الإلزامية والعناوين والبدائل. وصول السجل لا يثبت فهمه أو اختياره أو نجاح الاتصال.

سجل اكتمال لكل نوع

يجب حفظ QNAME وQCLASS والنوع الأساسي والقائمة المرتبة للأنواع الإضافية، وهوية المحلل والمسار، وحجم EDNS، ووجود خيار الاستجابة ومحتواه الدقيق، وRCODE وAA وAD وTC. ويجب حساب الفرق الصريح بين مجموعة الطلب ومجموعة الاكتمال.

لكل نوع معاد، تُحفظ RRsets وأدلة النفي والنطاق الأصلي وحالة السلطة والموقّع ونتيجة DNSSEC وTTL ومصدر الذاكرة ووقت الرصد. ترتبط أسئلة الاسترجاع المنفصلة واختيار التطبيق ونتيجة الاتصال بمعرف قرار واحد.

يبقى بذلك أربعة أشياء منفصلة: استلام الحزمة، اكتمال QTYPE، التحقق من RRset، واكتمال حاجة التطبيق.

تمنع أولوية الشفرة العاملة عند Heng Lu استخدام النشر والتسجيل بديلاً من إثبات التشغيل. ويؤيد إطار المواصفة الأولية الدنيا والقرار المحلي والتبني الطوعي شكلاً مشتركاً ضيقاً، وحدوداً يقررها المشغل، وتوافقاً معلناً، وطريق خروج عبر الأسئلة العادية. أما مبدأ الواقع لا المناصرة فيفصل الخطاب عن الدليل: سجل IANA يثبت إمكان الاستخدام، والحزمة الفعلية وقائمة الاكتمال والتحقق ونتيجة التطبيق تثبت الواقع.

قد تتشارك السجلات الغلاف، لكنها لا تتشارك السلطة تلقائياً.