الخلاصة

  • اشترطت RFC 2845 أن تتضمن قيمة MAC في استجابة DNS الموقعة قيمة MAC للطلب الذي استدعاها.
  • في تبادل DNS/TCP متعدد الرسائل، غطّت قيمة MAC تراكمية القيمة السابقة والرسائل اللاحقة بالترتيب؛ ووضعت TSIG في الرسالة الأولى والأخيرة، وعلى الأقل كل مئة رسالة.
  • فرضت RFC 8945 لاحقًا على المرسل وضع TSIG في كل رسالة استجابة، مع إبقاء تسامح توافق محدود لدى المدقّق. لا تحوّل أي من القاعدتين توثيق المعاملة إلى سرية أو صحة للمصدر أو تفويض محلي.

لم تكن الاستجابة حزمة منفصلة

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

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

هذا الربط يثبت توافق البايتات المغطاة مع علاقة مفتاح محددة. وبما أن الطرفين يتشاركان السر، فإن نجاح التحقق يعني أن الرسالة طابقت المفتاح المضبوط؛ لكنه لا يحدد الشخص أو العملية التي كانت تحوزه. لا يشفّر TSIG بيانات DNS ولا يقرر قبول تحديث. تحدد RFC 2136 عملية DNS UPDATE، بينما تظل سياسة الخادم المحلية هي التي تقرر إن كان الطرف الموثق يستطيع تغيير المنطقة.

صار نقل المنطقة سجلًا متسلسلًا

تظهر الصعوبة حين تتوزع الاستجابة على رسائل عدة، كما في نقل منطقة عبر TCP. لو عولجت كل حزمة بمعزل عن الأخرى، لضاعت علاقة الترتيب بينها. لذلك أوجبت RFC 2845 وجود TSIG في أول رسالة وآخرها، ونقطة تحقق موقعة واحدة على الأقل كل مئة رسالة. وبين نقطتي تحقق، تُضمّن كل رسالة DNS بالترتيب في حساب MAC التالي، إلى جانب MAC السابقة وحقول الوقت ذات الصلة.

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

تغيّرت القاعدة وبقي الحد الفاصل

أضافت RFC 4635 معرّفات خوارزميات HMAC-SHA إلى تصميم HMAC-MD5 الأصلي. وفي 2020، حلّت RFC 8945 محل RFC 2845 وRFC 4635 بوصفها المعيار STD 93. شددت قاعدة الإرسال: يوقّع المرسل المتوافق كل رسالة في الاستجابة. أما قاعدة التوافق لدى المدقّق فمختلفة؛ إذ يجب أن يقبل ما يصل إلى 99 رسالة وسيطة بلا TSIG، مع اشتراط توقيع الأولى والأخيرة. لا يجيز هذا التسامح للمرسل الحديث حذف التوقيع.

وتوضح RFC 8945 حد الإثبات أيضًا: يوثق TSIG الإرسال بين طرفين يتشاركان سرًا، لا مصدر البيانات الأصلية ولا صحتها. وهذا يختلف عن DNSSEC الذي يوثق البيانات وفق نموذج ثقة آخر. يمكن استخدام TKEY لإنشاء مفاتيح في بعض البيئات، لكن توزيعها ليس وظيفة يقدمها TSIG. تصف المعايير آلية محدودة النطاق، لا ختم ثقة شاملًا.

المصادر: RFC 1035، RFC 2104، RFC 2845، RFC 8945، RFC 4635، RFC 2136، RFC 2930.