الخلاصة

  • إصدار IP الذي يحمل تبادل DNS لا يحدد عائلة العناوين المطلوبة في السجلات: يمكن نقل استعلام AAAA عبر IPv4، واستعلام A عبر IPv6.
  • أضاف RFC 3596 سجل AAAA ذي 128 بت وحدّث بعض قواعد الإجابة، لكنه أبقى بيانات DNS منفصلة عن المسار الشبكي الذي حمل السؤال.

«IPv6» في أي طبقة؟

لنتخيل محلّلاً يرسل سؤال DNS داخل حزمة IPv4: «ما سجلات AAAA المرتبطة بهذا الاسم؟». يصف ترويس IPv4 كيفية انتقال هذه الرسالة بعينها. أما نوع السؤال فيطلب بيانات عنوان IPv6. لا تناقض بين الأمرين. ينص RFC 3596 صراحة على أن إصدار IP المستخدم للاستعلام عن السجلات مستقل عن إصدار البروتوكول الذي تمثله تلك السجلات. ويوضح RFC 4472 النتيجة التشغيلية: يمكن الاستعلام عن AAAA عبر IPv4، وعن A عبر IPv6.

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

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

إضافة سجل، لا استبدال الطريق

استخدم نموذج DNS السابق سجل A لتخزين عنوان IPv4 ذي 32 بت. وأدخل RFC 1886 سجل AAAA لتخزين عنوان IPv6 ذي 128 بت، إلى جانب آلية للبحث العكسي. ثم نقل RFC 3152 شجرة الأسماء العكسية من IP6.INT إلى IP6.ARPA. جمع RFC 3596 هذه التغييرات، وأبقى دعم IPv4 القائم، وعرّف AAAA ذي النوع 28 كسجل يحتوي عنوان IPv6 كاملاً.

كان ذلك توسيعاً لنموذج البيانات داخل DNS، لا إنشاء وسيلة نقل IPv6 خاصة برسائل DNS. ظلت الأسئلة والإجابات تستخدم تبادل DNS المعتاد. ويمكن أن يكون نقل IP عبر IPv4 أو IPv6 بصرف النظر عن طلب A أو AAAA. لذلك لم يكن على فضاء الأسماء العالمي أن ينقسم إلى «DNS لـ IPv4» و«DNS لـ IPv6» لمجرد أن البيانات باتت تستوعب العائلتين.

كان هناك بديل حقيقي. فقد أمكن لسجلات A6 تقسيم العنوان إلى أجزاء وربطها عبر DNS، بما قد يقلل بعض التحديثات عند تغير البادئة. لكن هذه المرونة جلبت استعلامات متسلسلة واعتماديات إضافية. وثّق RFC 3363 قرار إبقاء AAAA على مسار المعايير ونقل A6 وBit Labels إلى الحالة التجريبية؛ وشرح RFC 3364 المفاضلات. وهكذا اختار RFC 3596 سجلاً كاملاً يسهل استرجاعه، لا حلاً شاملاً لإعادة الترقيم أو لنشر IPv6.

قواعد الإجابة احتاجت إلى تحديث أيضاً

حدّث RFC 3596 معالجة القسم الإضافي لاستعلامات NS وSRV وMX، بحيث يمكن إدراج عناوين A وAAAA ذات الصلة والمتاحة محلياً. أما استعلام AAAA فلا يطلق هذه المعالجة بنفسه. فالسجل المطلوب مباشرة والعنوان المرفق بوصفه معلومة مساعدة في إجابة أخرى سلوكان مختلفان.

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

لا تثبت إجابة AAAA إلا أن DNS أعاد بيانات عنوان IPv6 لاسم معين. ولا تثبت وجود مسار IPv6 من هذا المحلّل، أو وجود خدمة تستمع عند العنوان، أو سماح جدار الحماية بالجلسة، أو تحقق DNSSEC من البيانات، أو اتصال التطبيق. كما أن تلقي الإجابة عبر IPv4 لا يكشف إصدار IP الذي سيستخدمه اتصال لاحق بالخدمة.

حدّ جعل التعايش مفهوماً

غالباً ما يُلخّص أثر RFC 3596 التاريخي في عبارة «أضاف DNS سجل AAAA». لكنه حافظ أيضاً على قاعدة ثابتة بينما أضاف الإنترنت عائلة عناوين جديدة: الحزمة التي تحمل السؤال وعائلة العنوان المشفّرة في السجل بُعدان مستقلان. خلال الانتقال، أمكن لنقل IPv4 استرجاع بيانات IPv6، كما ظل نقل IPv6 قادراً على استرجاع بيانات IPv4، ضمن فضاء أسماء مشترك.

تحدد وثائق RFC الآلية والفصل المقصود. لكنها لا تثبت مدى التزام التطبيقات به، ولا سلوك محلّل بعينه، ولا أن سجلي A وAAAA لاسم واحد كانا صالحين للاستخدام في الوقت نفسه. تحتاج تلك الأسئلة إلى أدلة منفصلة عن التطبيق والإعداد والقياس وإمكانية الوصول.

المصادر: RFC 1034؛ RFC 1035؛ RFC 1886؛ RFC 3152؛ RFC 3363؛ RFC 3364؛ RFC 3596؛ RFC 3597؛ RFC 4472.