الخلاصة

  • يعلن TC أن طول الرسالة تجاوز ما تسمح به قناة النقل. أوضح RFC 2181 أن العلامة تخص RRset مطلوبة لم تدخل كاملة، وأن على العميل تجاهل الرد المبتور بدلاً من اعتبار السجلات الظاهرة مجموعة نهائية.
  • حمل TCP إعادة الاستعلام الأكبر، ثم خرج من موقع الاستثناء. ألزم RFC 7766 تطبيقات DNS العامة بدعم UDP وTCP وسمح بالبدء عبر TCP، وجعل RFC 9210 السعة والسماح والمراقبة مسؤوليات تشغيلية عادية.

لم يكن ضيق الحزمة دليلاً على ضيق الاسم

حدد RFC 1035 عام 1987 خدمة DNS على المنفذ 53 عبر UDP وTCP. وفّر UDP سؤالاً خفيفاً من دون إنشاء اتصال أو حفظ قدر كبير من الحالة، لكنه قيّد رسالة DNS بـ512 بايت من دون رؤوس IP وUDP.

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

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

أصبحت RRset وحدة الدليل

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

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

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

اختار DNS خسارة المحاولة على صناعة يقين كاذب. اكتمال وحدة الدليل أهم من الاستفادة من جزء وصل مصادفة.

أبلغ الخادم عن الحد، واختار المحلّل الخطوة التالية

في المسار المعروف يرسل المحلّل سؤال UDP، ثم يعيده عبر TCP بعد TC. تسبق رسالة DNS في TCP خانة طول من بايتين، فلا تبقى مقيدة بحزمة UDP واحدة.

لكن البِت لا يفتح الاتصال ولا يفرض كل سياسة. يقرر المحلّل إعادة الاستخدام أو تجربة خادم آخر، ويقرر الخادم قبول الاتصالات وحدود التزامن ومدة الخمول. من يتحمل كلفة الحالة يملك ضوابطها.

ولا تمنح تلك الضوابط سلطة تعديل السجلات. يقتصر قول الخادم على أن هذا التسليم ناقص، ويتحمل مستهلك الدليل مسؤولية استرجاع النسخة الكاملة.

وسّع EDNS العرض ولم يضمن الطريق

أتاح RFC 6891 للطالب أن يعلن حجم حمولة UDP التي يستطيع استقبالها. تجاوزت إجابات كثيرة سقف 512 بايت بفضل EDNS(0) من دون مغادرة UDP.

لكن الرقم المعلن عند طرف واحد لا يقيس كل وصلة ونفق وجدار ناري في الطريق. قد تضيع شظايا IP أو تُحجب، وأضاف DNSSEC توقيعات وأدلة جعلت الإجابات أكبر.

يعرض EDNS ميزانية استقبال، بينما يقر TC بأن البيانات المطلوبة لم تدخل في الميزانية القابلة للاستخدام. الرقم الكبير ليس إيصال تسليم من طرف إلى طرف. وإذا ضاعت الحزمة الكبيرة بصمت، فقد لا يصل TC أصلاً؛ لذا يجب ألا يختلط انقضاء مهلة UDP بإجابة DNS سلبية موثوقة.

لم يعد TCP باباً للطوارئ فقط

ظل الوصف الشائع يحصر TCP في نقل المناطق أو إعادة المحاولة بعد البتر. شجع ذلك بعض الشبكات على حجب TCP/53، أي إغلاق الطريق الذي يحتاجه البروتوكول عند عجز UDP.

غيّر RFC 7766 هذا الوضع عام 2016. يجب أن تدعم خوادم السلطة والخوادم العودية والممررات والمحللات العامة UDP وTCP. كما لم يعد واجباً أن يبدأ كل سؤال عادي عبر UDP؛ يمكن اختيار TCP لسبب تشغيلي محلي وإعادة استخدام اتصال قائم.

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

احتاج التدفق الموثوق إلى اقتصاد في الحالة

إنشاء اتصال لكل سؤال يكرر زمن المصافحة وكلفتها. أوصى RFC 7766 بإعادة الاستخدام وإرسال عدة أسئلة في pipeline من دون انتظار كل رد. يمكن للخادم معالجتها بالتوازي وإعادة النتائج بترتيب مختلف.

على العميل مطابقة كل رد بسؤاله، وعلى الخادم وأدوات الرصد إعادة تجميع stream؛ فمقطع TCP واحد ليس بالضرورة رسالة DNS كاملة.

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

وجب على التشغيل أن يرى UDP وTCP معاً

حوّل RFC 9210 الدعم إلى التزام تشغيلي. على الخوادم والمحللات خدمة النقلين، وعلى مشغلي الشبكات السماح بهما في الحالة العامة. حجب TCP يزيل مسار استعادة الإجابات الكبيرة.

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

وتحتاج المراقبة إلى تجميع stream وفهم إعادة استخدام الاتصال وpipeline والردود الخارجة عن الترتيب. من يراقب UDP وحده لا يعرف هل انتهى اعتراف TC باستعادة كاملة أم بفشل صامت.

أعادت هشاشة التجزئة قيمة الإشارة القديمة

أوصى RFC 9715 عام 2025 بتجنب تجزئة IP في DNS/UDP وبحد أقصى موصى به قدره 1400 بايت حين لا يفرض الطريق حداً أصغر. التجزئة هشة وقد تفتح مجالاً لتسميم الذاكرة المؤقتة.

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

لم يدّع البِت أكثر مما يعرف

لا يثبت TC فشل DNSSEC أو الرقابة أو الهجوم أو عدم وجود الاسم أو ملكيته. وليس كل حذف من قسم Additional سبباً للبتر، كما أن TCP ليس الوسيلة الأكبر الوحيدة إلى الأبد.

قوة الإشارة في ضيقها: لم تحمل هذه القناة كل المطلوب. قبل DNS بظرف أول رخيص ومحدود، ورفض أن يجعل حدود الظرف حقيقة عن المحتوى.

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

تأتي القاعدة الأصلية من RFC 1035، وتكامل RRset من RFC 2181، وEDNS من RFC 6891، وواجبات TCP من RFC 7766 وRFC 9210، وتجنب التجزئة من RFC 9715. لا تقيس هذه الوثائق النسب العالمية الحالية لـTC أو الحجب أو نجاح المحللات.