عنوان محلّل واحد لا يعني قراراً واحداً

الخلاصة

• مع الانتقال من خادم موثوق واحد إلى خادمين، انخفض المتوسط المرصود من 3.43 إلى 2.57 استعلاماً لكل اختبار، وارتفعت نسبة الاختبارات ذات الاستعلام الواحد من 58% إلى 71%.
• لم يحدد APNIC Labs آلية سببية. وجود موزّع أمام مجموعة من محركات التحليل فرضية ممكنة، وليس وصفاً مثبتاً للبنية التي خضعت للرصد.
• ينبغي أن تربط وحدة التدقيق طلب العميل، وقرار التوزيع، والمحرك الخلفي، وحالة الذاكرة المؤقتة، والمحاولة نحو الخادم الموثوق، والاستجابة، وقرار التكرار، واكتمال التحليل.

القياس	خادم موثوق واحد	خادمان موثوقان
عدد الاختبارات	254,894,985	150,221,951
مجموع الاستعلامات	875,316,423	385,725,364
الاستعلامات لكل اختبار	3.43	2.57
اختبارات ذات استعلام واحد	58%	71%
متوسط التكرار حين وقع التكرار	3.80	2.56

تغيير صغير في الوجهة كشف فرقاً كبيراً في السلوك

بدأت تجربة APNIC Labs بنطاق له اسم خادم موثوق واحد وعنوانان، IPv4 وIPv6. ثم أضيف اسم خادم ثان مع عنوانيه. ظلت الإجابات إيجابية؛ لم تكن التجربة حالة انقطاع أو صمت أو SERVFAIL.

مع الخادم الواحد، أنتج نحو 255 مليون اختبار أكثر من 875 مليون استعلام شوهد عند الطرف الموثوق. ومع الخادمين، أنتج نحو 150 مليون اختبار قرابة 386 مليون استعلام. وبين الاختبارات التي كررت الاستعلام، هبط متوسط التكرار من 3.80 إلى 2.56.

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

الفارق الأسرع من مهلة الانتظار المعتادة

وصلت معظم الاستعلامات المكررة بسرعة. في إعداد الخادم الواحد، وصل نحو 85% منها خلال الثانية الأولى، مقابل نحو 75% مع الخادمين. وفي الحالتين وصل قرابة 90% خلال خمس ثوان. ظهرت في الحالة الأولى قمم قرب 100 و310 و800 ملي ثانية، بينما أظهرت الثانية قمماً إضافية قرب 50 و370 و750 ملي ثانية.

تركز قدر كبير من الفرق بين 10 و70 ملي ثانية، ولا سيما بين 10 و40. هذه نافذة أقصر من أن تفسرها وحدها مهلة انتظار UDP تقليدية لاستعلام منفرد. كما تراجعت التكرارات المتلاحقة خلال أقل من 10 ملي ثوان من نحو 17% إلى 12%.

تحدد دراسة APNIC السابقة عن الاستجابات السلبية والفشل حدود المقارنة. فقد بلغ المتوسط 3.43 مع الإجابة الإيجابية، و51.73 مع SERVFAIL، و83.46 عند غياب الإجابة. تلك دراسة عن تضخيم الفشل والتخزين المؤقت. أما هنا فالإجابة إيجابية والتغيير في طوبولوجيا السلطة. دمج القصتين يحجب السؤال الجديد.

يمكن لواجهة عامة واحدة أن تدير عدة محركات

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

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

ينطبق التحفظ نفسه على anycast وترجمة العناوين وموازنة الحمل ومجموعات العمليات. عنوان IP صالح للتوجيه، لكنه لا يصبح تلقائياً هوية للعميل والمحرك وعملية التحليل في آن واحد.

تطابق الحقول لا يساوي تطابق العمل

يفصل RFC 9520 بين الخادم والعنوان ووسيلة النقل، ويصف الاستعلام بواسطة QNAME وQTYPE وQCLASS. ويحدد RFC 1035 معرّفاً من 16 بت يستخدمه الطالب لمطابقة الإجابة مع استعلام معلق. تساعد هذه الحقول في فرز الحزم، لكنها لا تعيد بناء العملية المنطقية كاملة.

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

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

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

التكرار للخدمة لا يشرح تكرار الحزم

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

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

المصادر

• APNIC Labs: One or two nameservers?
• APNIC Labs: What part of “no” is so hard for the DNS to understand?
• RFC 1035 وRFC 2182 وRFC 9520
• الدليل الرسمي لـ dnsdist