رجوع DNS من UDP إلى TCP مسار سعة، لا حالة استثنائية

الخلاصة

• TCP مسار اعتيادي لخدمة DNS، وليس استثناءً مخصصاً لنقل المناطق فقط.
• يوسّع EDNS الحيز المتاح لـUDP، لكنه لا يضمن وصول الحمولة عبر كل مسار.
• يجب أن يتتبع دليل الجاهزية الاستعلام نفسه من البتر إلى إنشاء TCP واكتمال الإجابة وإعادة الاستخدام الآمنة.

تبدأ الحادثة الكاشفة بلوحة كلها خضراء. تستجيب UDP/53 سريعاً وتكون البيانات السلطوية محدثة. ثم تعود إجابة أكبر وعليها بتّ TC. يفتح المحلّل اتصال TCP، لكن موقع الخدمة يملك طابور قبول ضيقاً، أو مهلة جدار ناري غير ملائمة لمسار الاتصال هذا، أو عمليات تتأخر بسبب طرف بطيء. بيانات DNS صحيحة، إلا أن مسار تسليمها غير جاهز.

حددت RFC 1035 خدمة DNS عبر UDP وTCP على المنفذ 53، وحددت في TCP بادئة من ثمانيتي بت لطول الرسالة. كما أوصت بدعم اتصالات متعددة وألا يحجب انتظار بيانات TCP بقية العمل. وسّع EDNS لاحقاً الحد الأصلي لـUDP، لكن الحقيقة المعمارية لم تتغير: البتر ينقل العمل اللازم لإتمام السؤال نفسه إلى مسار نقل آخر.

تتيح RFC 6891 للطالب إعلان أكبر حمولة UDP يستطيع إعادة تجميعها وتسليمها في سياق DNS. هذه قرينة على قدرة الطرف، وليست وعداً بشأن كل وصلة وسيطة. لذلك فإن غياب TC في المختبر لا يلغي TCP من عقد الإنتاج.

تلزم RFC 7766 تطبيقات DNS العامة بدعم TCP، وتتعامل مع إعادة استخدام الاتصال بوصفها وسيلة لتجنب كلفة إنشاء اتصال لكل استعلام. لم يعد سؤال السعة مقتصراً على نجاح فتح المنفذ: هل يكتمل العمل المتزامن؟ هل يؤخر طرف بطيء غيره؟ وهل تحفظ سياسة الإغلاق الاتصالات المفيدة من دون إبقاء الحالة المحدودة بلا ضابط؟

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