الخلاصة

  • يرتبط بتّ Authoritative Answer في DNS بالاسم الموجود في Question أو بأول اسم مالك في Answer؛ وقد تكون لأهداف الأسماء المستعارة وسجلات Authority والغراء وبيانات Additional في الرسالة نفسها مصادر مختلفة.
  • يحفظ الإيصال القابل للتدقيق مالك كل RRset ونوعه وقسمه وحدّ النطاق ومصدره في المخبأ وحالته في DNSSEC، ويربط الاستعلامات اللاحقة، بدلاً من تحويل بتّ واحد في الترويسة إلى سلطة أو أصالة تشمل الحزمة كلها.

يسأل محلّل عن shop.example. الخادم صاحب سلطة على ذلك الاسم، فيعيد CNAME. يظهر بعده عنوان للهدف أخذه الخادم من المخبأ، ويضيف قسم Additional عنواناً آخر قد يوفر استعلاماً تالياً. قيمة AA هي 1.

لكن منصة الرصد تخزن الرسالة في صف واحد وتكتب authoritative=true. عندما يرد نطاق الهدف لاحقاً بعنوان مختلف، لا يستطيع السجل تمييز قول الخادم عن الاسم المستعار، والبيان المخبأ، والمعلومة الإضافية. لم تكن المفارقة في DNS؛ بل في اختزال ثلاث طبقات إلى صفة واحدة.

هذا مثال افتراضي لا يصف حادثة أو إساءة من مشغّل بعينه.

للبتّ مرجع واحد

يعرّف RFC 1035، الذي ألّفه Paul Mockapetris، بتّ AA في ردود DNS. وهو يعني أن خادم الأسماء المجيب صاحب سلطة على اسم النطاق في قسم Question. ولأن الأسماء المستعارة قد تجعل Answer يضم أكثر من اسم مالك، يربط النص AA بالاسم المطابق للسؤال أو بأول مالك في Answer.

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

يبيّن RFC 1034 كيف تختلط المصادر بصورة مشروعة. إذا وجد الخادم CNAME في بيانات نطاقه السلطوية، نسخه إلى Answer وغيّر QNAME إلى الاسم القانوني ثم أعاد المعالجة. وعند التفويض يضع NS في Authority، ويضيف إلى Additional ما يتوافر من عناوين، سواء جاءت من الغراء أو بيانات سلطوية أو المخبأ. ويمكنه في النهاية إرفاق سجلات محلية يراها مفيدة.

وحدة النقل ليست بالضرورة وحدة إثبات.

القسم يحتفظ بالسياق ولا يمنح الرتبة

يفصل RFC 1035 الوظائف: يضم Answer ما يجيب عن السؤال، ويشير Authority إلى جهة السلطة، ويحمل Additional معلومات مرتبطة لا تعد جواباً صارماً. حفظ القسم خطوة أولى، لكنه لا يكشف وحده من أصدر كل مجموعة سجلات.

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

يرتب RFC 2181 المصادر على درجات: ملف النطاق ونقله من دون الغراء، ثم بيانات Answer السلطوية، ثم Authority من رد سلطوي، ثم الغراء، ثم الإجابات غير السلطوية وAdditional. يمكن لجواب سلطوي جديد أن يستبدل RRset تعلمه المخبأ سابقاً من Additional، ولا ينبغي للبيان الأضعف أن ينتصر لمجرد أنه موجود أولاً.

إذا حُذفت الرتبة، غسل المخبأ سياق البيان. قد يعود عنوان وصل كمساعدة إضافية في خانة Answer فيبدو كأنه اكتسب سلطة. الذي تغير بمرور الوقت هو TTL المتبقي، لا مصدر النشر.

الاسم المستعار ينقل السؤال إلى ولاية أخرى

يقول RFC 2181 إن الرد السلطوي عن اسم مستعار لا يضمن السلطة إلا للسجل الذي يصف ذلك الاسم؛ أما السجلات التالية فقد تأتي من المخبأ. ومن يحتاج جواباً سلطوياً عن الاسم القانوني فعليه أن يستعلم عنه من جديد.

يعيد RFC 6604 تثبيت القاعدة لسلاسل CNAME وDNAME: قد تختلف حالة السلطة في كل حلقة من سلسلة xNAME، فيما يظل AA مبنياً على أول مالك في Answer.

لذلك يستطيع خادم shop.example أن يقرر بسلطته أن الاسم يشير إلى service.vendor.test. ويمكنه أن يرفق عنواناً مخبأ للهدف. لكن العنوان لا يتحول إلى قول سلطوي صادر عن نطاق المورّد. عبور الحدّ يحدث في الاستعلام التالي، وله خادم ووقت ورسالة مستقلة.

يجب أن يسجل النموذج كل حافة: اسم الدخول، RRset من CNAME أو DNAME، نطاق المصدر، الرد الأصلي، الاسم التالي والاستعلام الذي تبعه. اختزال السلسلة في عنوان نهائي يخدم السرعة، لكنه يعطّل نسبة كل قول إلى صاحبه.

السلطة ليست أصالة تشفيرية

ينص RFC 6604 صراحة على أن DNSSEC لا يحمي بتّ AA في الترويسة. قد يحمي TSIG أو SIG(0) المعاملة مع الخادم، بينما تتحقق DNSSEC من مجموعات السجلات عبر سلسلة إثبات أخرى.

يعرّف RFC 4035 أربع حالات لكل RRset: Secure وInsecure وBogus وIndeterminate. تنتج الحالة من RRSIG وDNSKEY وDS ومرساة الثقة ودليل النفي والسياسة المحلية، لا من AA.

ولا يمثل AD نسخة أقوى من AA. لا يضع خادم واعٍ بـDNSSEC بتّ AD إلا إذا عدّ مجموعات Answer وAuthority المعنية أصيلة وفق القواعد. ومع ذلك يحتاج العميل إلى الثقة بالمحلّل المتكرر والقناة أو إجراء التحقق بنفسه. ولا تدخل Additional تلقائياً في ضمان شامل بسبب بتّ في الترويسة.

يمكن إذن أن يكون AA صحيحاً للاسم الأول، وCNAME في حالة Secure، والهدف Insecure، والغراء في Additional، والقناة إلى الوسيط غير موثقة. ينبغي للسجل أن يحتمل هذه الحقائق المتزامنة بدلاً من صبغها بلون واحد.

ما الذي يثبته اسم Mockapetris؟

ينسب Internet Hall of Fame إلى Paul Mockapetris ابتكار DNS سنة 1983 في Information Sciences Institute بجامعة USC. ويسجل RFC 1034 وRFC 1035 اسمه مؤلفاً. كما توفر الصفحة صورة تاريخية علنية استُخدمت مرجعاً لهوية الصورة التحريرية.

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

إيصال لكل RRset

يبدأ السجل بـQNAME وQTYPE وQCLASS وخيار التكرار وDO وCD ومعرّف المعاملة ووقت الإرسال. ثم يحفظ بايتات الرد ونقطة النهاية والنقل ووقت الاستلام وأي توثيق للمعاملة.

بعد ذلك يفكك الرسالة إلى RRsets. لكل مجموعة: المالك والنوع والفئة والقسم وTTL المرصود وحدّ النطاق وbailiwick والمصدر المعروف ووقت دخول المخبأ وانتهائه. إذا لم يعرف العميل هل استخدم الخادم النطاق أم المخبأ، تبقى الفجوة صريحة ولا يملؤها AA.

يُحفظ مرجع AA منفصلاً: QNAME الأصلي وأول مالك في Answer والخادم والنطاق الذي يملك سلطته. ينشئ كل اسم مستعار أو تفويض رابطاً إلى الاستعلام اللاحق. تبقى NS الأب والغراء ورد الابن مرتبطة لا مندمجة.

ويضاف لكل RRset وضع DNSSEC والتوقيعات ومسار DS/DNSKEY ومرساة الثقة ووقت التحقق وسبب الفشل. يبقى AD الوارد قولاً من الطرف الأعلى. وعند استعمال التطبيق للنتيجة يسجل أي RRset وأي جيل من المخبأ استُخدما.

تصبح العبارة النهائية دقيقة: وضع هذا الخادم AA لهذا الاسم الأول؛ جاءت هذه المجموعة من هذا القسم والمصدر؛ أعطاها هذا المدقق هذه الحالة؛ وأثبت استعلام تالٍ سلطة الاسم التالي؛ واستخدم التطبيق هذه النتيجة. يحتفظ البتّ بقيمته حين يتوقف عن تمثيل الرد كله.

المصادر