الخلاصة

  • كان SLAAC يمنح مضيف IPv6 عنواناً ومساراً من دون أن يزوّده بمحلّل DNS تكراري يحوّل الأسماء إلى وجهات.
  • نقل RDNSS اكتشاف المحلّل إلى Router Advertisements، وأضاف DNSSL لاحقات البحث، ثم تناولت المواصفات أعمار الخيارات وترتيب المصادر ومتطلبات الدعم.

العنوان ليس محلّل أسماء

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

تولّى Neighbor Discovery وStateless Address Autoconfiguration الجزء الأول. حملت Router Advertisements معلومات الوصلة، وأتاح SLAAC للمضيف تكوين عنوان بلا عقد إيجار عنوان عبر DHCPv6. أما DNS فسلك طريقاً مختلفاً. في 2007، ذكر RFC 5006 أن DHCP هو آلية إعداد DNS الوحيدة لدى IETF على مسار Standards Track. وبالنسبة إلى حاسوب ينتقل بين الشبكات اللاسلكية، كان استبدال عنوان المحلّل يدوياً عند كل محطة حلاً مرهقاً.

طرح RFC 5006 طريقاً آخر، لكنه صنّفه Experimental: يمكن أن تحمل Router Advertisement في IPv6 خيار Recursive DNS Server، أو RDNSS. يتعلم المضيف عنوان المحلّل من الإعلان نفسه الذي ينقل إعدادات الوصلة، من دون تبادل بروتوكولي ثانٍ. لكن الموجّه يظل بحاجة إلى إعداد؛ فالوثيقة لم تجعل الموجّهات تكتشف خوادم DNS الخاصة بها تلقائياً.

الموجّه بدأ يعلن عن الأسماء

في 2010، نقل RFC 6106 خيارات DNS إلى Standards Track وأضاف DNSSL، أي قائمة لاحقات البحث. يزوّد RDNSS المضيف بعنوان محلّل واحد أو أكثر. أما DNSSL فيقدّم لاحقات يمكن إضافتها إلى اسم غير مكتمل يطلبه تطبيق. وهكذا أمكن لتدفق Router Advertisements نفسه أن يحمل البادئة والموجّه والمحلّل وقائمة البحث.

لم يختف DHCPv6. وصف RFC 6106 كلاً من DHCPv6 وRA كآليتين يمكن أن تتعايشا وتخدما شبكات وإعدادات مضيف مختلفة. ثم أوصى RFC 8106 المضيف بالاحتفاظ بقائمة مرتبة عندما تصله معلومات DNS عبر عدة Router Advertisements أو عبر DHCP. وظل DNS الذي يضبطه المستخدم خياراً مستقلاً. صار السؤال عن ترتيب المصادر، لا عن فائز واحد في كل شبكة.

فقد الحزم غيّر المؤقّت

لمدخلي RDNSS وDNSSL عمر محدد. عند انقضائه يحذف المضيف المعلومة؛ فالإعلان مهلة لصلاحية إعداد المحلّل، لا إعداد دائم. وضع RFC 6106 حدوداً للعمر نسبةً إلى الفاصل الأقصى بين Router Advertisements. وفي 2017، أوضح RFC 8106 أن الحد الأدنى السابق، أي ضعفي ذلك الفاصل، قد يترك خيارات DNS تنتهي على الوصلات كثيرة الفقد. رفع التعديل القيمة الافتراضية إلى ثلاثة أضعاف الفاصل الأقصى.

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

دخل الدعم في خط أساس IPv6

ارتفع مستوى الإلزام مع تطور الآلية. في 2011، قال RFC 6434 إن على التطبيقات SHOULD دعم خيار DNS في RA. وفي 2019، ألزم RFC 8504 عقد IPv6 MUST بدعم هذا الخيار. انتقل المسار من مخرج تجريبي إلى قدرة مطلوبة لأن العنوان وحده لا يكفي لخدمة إنترنت عملية.

قواعد المصدر هي ما يمنح الميزة أثرها التشغيلي. يطلب RFC 8106 من المضيف الاحتفاظ بقائمة مرتبة لمعلومات RA وDHCP؛ وتأتي معلومات DHCP عادةً أولاً. ويُفضَّل RA المحمي بـSEND على مصدر DHCP غير الموثّق. وقد تتقدم إعدادات DNS الثابتة التي يضعها المستخدم على المعلومات المعلنة.

تثبت هذه الوثائق تغيّر التصميم والمتطلبات، لكنها لا تقدم تعداداً رسمياً للأجهزة التي تستخدم RDNSS؛ لذلك لا يمكن تحديد عدد العملاء الذين اعتمدوه.

المصادر

RFC 4339 — IPv6 Host Configuration of DNS Server Information Approaches, RFC 4861 — Neighbor Discovery for IP Version 6، RFC 4862 — IPv6 Stateless Address Autoconfiguration، RFC 5006 — IPv6 Router Advertisement Option for DNS Configuration، RFC 6106 — IPv6 Router Advertisement Options for DNS Configuration، RFC 6434 — IPv6 Node Requirements، RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration، وRFC 8504 — IPv6 Node Requirements.