الخلاصة

  • خصص RFC 5855 نطاقي أسماء لخوادم منطقتي البحث العكسي لـ IPv4 وIPv6، مع عناوين glue في النطاق الأب، بحيث يصبح تشغيل المنطقتين على مجموعتين مختلفتين ممكناً.
  • لا يفرض RFC فصل المشغّلين. فالاختيار من وظائف IANA، واختلاف الأسماء لا يثبت استقلال المسارات أو مواقع الاستضافة أو نطاقات الأعطال.

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

تناول RFC 5855، المعنون Nameservers for IPv4 and IPv6 Reverse Zones، مسار الوصول هذا. نُشر في مايو 2010 بوصفه Best Current Practice، وشارك في تأليفه Joe Abley وTerry Manderson. ووثّق الوضع القائم آنذاك: كانت مجموعة فرعية من خوادم الجذر تخدم IN-ADDR.ARPA، بينما كانت أنظمة تشغّلها APNIC وARIN وICANN وLACNIC وRIPE NCC تخدم IP6.ARPA.

اقترح النص مساحة أسماء مستقرة مستقلة لكل شجرة عكسية. تُسمّى خوادم IPv4 تحت IN-ADDR-SERVERS.ARPA، وخوادم IPv6 تحت IP6-SERVERS.ARPA. ويتضمن نطاق ARPA الأب عناوين glue اللازمة للوصول إلى كل مجموعة عبر IPv4 وIPv6. وهكذا يستطيع المحلّل متابعة الإحالة من بيانات النطاق الأب، من دون بدء بحث تكراري إضافي لمعرفة عنوان خادم تابع لـ IP6.ARPA.

توضح أمثلة الاستعلام في RFC سبب أهمية هذه الخطوة. فقد كانت إحالة IP6.ARPA القديمة قد تصل من دون عناوين glue في القسم الإضافي. عندئذ يضطر المحلّل إلى حل اسم أحد الخوادم أولاً، قبل أن يتمكن من الاستعلام عن المنطقة العكسية. يعالج RFC 5855 هذا الاعتماد عند تصميم الإحالة: أسماء مخصصة وعناوين في النطاق الأب تجعل المسار أوضح وأسهل في الفحص. التغيير محدود ظاهرياً، لكنه يقع في طريق لا بد أن يسلكه كل بحث عكسي.

يناقش النص أيضاً كلفة ترميز أسماء خوادم IPv6. ففي المثال التاريخي تشغل أسماء سجلات NS مقدار 74 بايتاً، بينما يشغل الطقم المقترح تحت IP6-SERVERS.ARPA مقدار 39 بايتاً. وهذه مقارنة لحجم الترميز في صيغة DNS، وليست قياساً للزمن أو لمعدل فشل الاستعلامات. إنها توضح كيف يمكن ضغط اللواحق المتكررة في إحالة تُستخدم كثيراً، وكيف يصبح عنوان الخادم التالي أكثر تحديداً.

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

ويحدد النص بوضوح الجهة التي تتخذ القرار المتبقي. يسجل قسم IANA التفويضات وعناوين glue، لكنه يضع اختيار المشغّلين خارج نطاق RFC ويصفه بأنه وظيفة من وظائف IANA بموجب مذكرة التفاهم بين IETF وICANN. لذلك يحدد RFC 5855 نقطة اتصال تقنية وينقل المسؤولية بعدها إلى جهة تشغيلية. لكنه لا يوثق من يشغّل كل خادم اليوم، ولا مقدار الاستقلال بين مجموعات الخوادم.

وتظهر خبرة Manderson على جانبي هذا الحد. فقد شارك في تأليف RFC، ويُدرجه Datatracker التابع لـ IETF بين وثائقه. ويذكر تاريخ لاحق لـ RSSAC أنه تولى إدارة قسم DNS Operations في ICANN عام 2013؛ ثم انتقل الفريق إلى ICANN IT وأصبح اسمه DNS Engineering في 2014. كما تقدمه مقابلة مع ICANN بصفته مديراً للقسم في ذلك الوقت. تثبت هذه السجلات خبرة تشغيلية، لا أنه صمم أو اختار أو نشر المشغّلين وحده.

هذا التحفظ يجعل RFC دليلاً أفضل. فهو يميز بين ما تستطيع طبقة البروتوكول تسميته وما يجب أن تقرره ترتيبات التشغيل. ولمعرفة إن كان DNS العكسي لـ IPv4 وIPv6 يتعطل فعلاً على نحو مستقل، على المهندسين فحص مجموعات NS الفعلية، وعناوين glue، والاستضافة، والمسارات، وسلوك الاستجابة. لا تكفي لاحقتان مختلفتان في معيار للإجابة.

المصادر