الخلاصة

  • خزّن RFC 3403 قواعد DDDS في سجلات NAPTR، لكن موضع السجل في استجابة DNS لم يكن ترتيب التنفيذ. رتب العميل حسب ORDER واستخدم PREFERENCE بين بدائل الطبقة نفسها.
  • بعد مطابقة قاعدة، لم يجز العبور إلى ORDER آخر لأن خدمة مألوفة ظهرت لاحقاً. ظلت Additional وDNSSEC ونجاح الخدمة أدلة منفصلة.

تظهر استجابة DNS في هيئة أسطر، فيبدو السطر الأول صاحب الأولوية. رفض RFC 3403 هذا الاستنتاج. كانت NAPTR تعيد مجموعة مرشحين، أما الترتيب الملزم فكان مكتوباً داخل السجلات.

صدرت الوثيقة على مسار المعايير في أكتوبر 2002 وعرّفت DNS بوصفه قاعدة قواعد DDDS. المفتاح اسم نطاق صالح؛ يستعلم العميل عن NAPTR ذي النوع 35. وحلت المواصفة محل RFC 2915 وRFC 2168.

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

يمكن للخادم أو الذاكرة أو المكتبة إعادة ترتيب RRset من دون تغيير المعنى. فإذا أخذ العميل أول Services يعرفها، استبدل ترتيب المسؤول بحادث عرض أو نقل.

عمل PREFERENCE داخل ORDER الواحد. وهو مقابل Priority ويرتب البدائل من الأصغر. يمكن اختيار بديل أقل تفضيلاً لضعف دعم بروتوكول ما، لكن لا يجوز استخدامه لعبور طبقة السلطة.

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

تحدد مواصفة التطبيق معنى Flags وServices، ومنها الأعلام النهائية. معرفة الحروف لا تثبت فهم عقد التطبيق.

كان REGEXP وREPLACEMENT شكلين متنافيين. يطبق الأول على السلسلة الأصلية، ويحمل الثاني اسم نطاق كاملاً لاستبدال بسيط بلا ضغط. وجود قيمتين معاً يجعل السجل خاطئاً.

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

استخدمت الحقول UTF-8. خارج ASCII يجب العمل على نقاط الترميز لا البايتات. وحُظرت التبعية لإعداد POSIX locale حتى لا يتغير معنى القاعدة بين العملاء.

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

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

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

وعند فشل الاستعلام بعد إعادة الكتابة، شجع RFC الإبلاغ عن الفشل بدلاً من الرجوع لمسارات بديلة. الرجوع الانتهازي يحول التفويض إلى بحث ويخفي سلطة الفشل.

يستطيع DNSSEC توثيق NAPTR، لكنه لا يثبت سلامة التعبير أو صحة الترتيب أو انتماء Services إلى التطبيق أو نجاح الخدمة. لذلك حذرت الوثيقة من تسليم التعبيرات بلا فحص إلى بيئة تنفذ شيفرة.

يسجل IANA NAPTR كنوع 35، وهو دليل تنسيق. أما Errata 2868 الحالية، Held for Document Update، فتحذف فقط تكرار this this في Services ولا تغير المعالجة.

يجب أن يحفظ الإيصال المفتاح وRRset وDNSSEC وTTL وترتيب الوصول ومجموعات ORDER وPREFERENCE وFlags وServices وصحة الاستبدال وUTF-8 ومقارنة المنطقة بالشبكة والرفض والاختيار وAdditional المستخدم والاستعلام التالي ونتيجة المستهلك.

يفسر الحد الأدنى للمواصفة الأولية لدى Lu Heng التصميم: توحيد التمثيل المشترك وترك المعنى للتطبيق. وتختبر أولوية الشيفرة العاملة العقد بخلط RRset وحذف Additional وتغيير locale وإنهاء TTL. يجب أن تتبع النتيجة حقول السلطة.

أول NAPTR في الحزمة كان أول ما ظهر فقط. أما القاعدة الأولى فحددها ORDER.

المصادر