قد يبدو نقل خوادم الأسماء ناجحًا في جميع لوحات التحكم، ومع ذلك يظل الموقع غير قابل للوصول. النطاق نشط، وخوادم الأسماء المخوّلة الجديدة تُرجع عنوان IP المتوقع، ولم يتغير خادم الويب. لكن محلّلات DNS التي تتحقق من صحة DNSSEC تُرجع SERVFAIL. وغالبًا ما يكون السبب حلقةً مفقودة في تفويض DNSSEC: فالمنطقة الأب ما زالت تثق بمفتاح التوقيع الخاص بمشغّل DNS السابق.
في الحادثة التي تستند إليها هذه الدراسة، فشلت الاستعلامات العادية، بينما نجحت الاستعلامات نفسها عند تجاوز التحقق من DNSSEC. كانت المنطقة الأب لا تزال تنشر سجل DS قديمًا، في حين كانت المنطقة المخوّلة الجديدة غير موقّعة في البداية. وقد أدّى نشر مفتاح مطابق وتوقيع المنطقة الجديدة إلى عودة الإجابات التي اجتازت التحقق لدى محلّلات DNS التي شملها الاختبار. والدرس المهم ليس أن DNSSEC ينبغي تعطيله، بل أن نقل خوادم الأسماء ونقل سلسلة الثقة الخاصة بـ DNSSEC عمليتان منفصلتان.
لماذا قد يظهر SERVFAIL رغم صحة سجلات A؟
يجيب DNS عن سؤالين مختلفين. يحدد سجل A عنوان IPv4 المرتبط بالاسم، بينما يحدد DNSSEC ما إذا كان يمكن لمحلّل يتحقق من التواقيع أن يثق بالإجابة. فصحة عنوان IP لا تعني تلقائيًا سلامة سلسلة الثقة في DNSSEC.
في النطاق الموقّع، تبدأ سلسلة الثقة من منطقة أب موثوقة، وتمرّ بسجل DS (اختصار Delegation Signer)، وصولًا إلى مفتاح DNSKEY في المنطقة التابعة. وتنشر المنطقة التابعة تواقيع (RRSIG) لبيانات DNS الخاصة بها. يحتوي سجل DS على بصمة تجزئة تحدد مفتاح DNSKEY مخوّلًا؛ فهو ليس سجل A، ولا نسخة من المفتاح الخاص، ولا إعدادًا في محرّر ملفات المنطقة المعتاد.
بعد تغيير خوادم الأسماء المخوّلة، قد تظل المنطقة الأب تنشر سجل DS مرتبطًا بالمفتاح الذي استخدمه الموقّع السابق. وإذا كانت المنطقة الجديدة لا تقدم مفتاح DNSKEY الموافق له والتواقيع اللازمة، فلن يستطيع محلّل DNS الذي يجري التحقق إكمال سلسلة الثقة. وعادةً ما يعتبر الإجابة غير موثوقة من منظور DNSSEC ويُرجع SERVFAIL بدلًا من تقديم عنوان لم يتحقق منه.
ويختلف هذا عن تعطل HTTP؛ فقد لا يصل الطلب أصلًا إلى خادم الويب. كما يختلف عن انتهاء صلاحية شهادة TLS: يتحقق DNSSEC من بيانات DNS، بينما يحمي HTTPS الاتصال اللاحق بين المتصفح والخادم.
اختبار يميّز خلل DNSSEC من غياب السجل
أوضح اختبار هو استعلام الاسم نفسه عبر محلّل DNS نفسه مرتين. ابدأ باستعلام عادي، وافحص حالة الاستجابة لا الإجابة وحدها:
dig example.com A +noall +comments +answerثم كرر الاستعلام مع ضبط بت تعطيل التحقق من DNSSEC (CD):
dig example.com A +cdflag +noall +comments +answerفي العطل المرصود، أعاد الاستعلام العادي SERVFAIL، بينما أعاد الاستعلام باستخدام CD سجل A المتوقع. وكان هذا التباين مؤشرًا قويًا إلى أن المشكلة في التحقق من DNSSEC، لا في غياب سجل DNS أو عدم استجابة التطبيق. يطلب الخيار +cdflag من محلّل DNS التكراري الذي يدعم ذلك ألّا يجري التحقق المعتاد من DNSSEC لهذا الاستعلام. وهو وسيلة تشخيص، وليس إصلاحًا من جهة المتصفح ولا طريقة لتعطيل DNSSEC لدى الزوار.
لا تستنتج الكثير من نتيجة فارغة عند استخدام +short. فقد يظهر كل من غياب الإجابة وحالة SERVFAIL دون أي نص في هذا التنسيق. احتفظ بالخيار +comments أثناء التشخيص كي تظل حالتا status: SERVFAIL وstatus: NOERROR ظاهرتين.
ولا يحدد اختبار CD وحده أي جزء من DNSSEC فشل؛ إنه يحدد موضع البحث التالي. فقد يواجه محلّل DNS أيضًا خطأً عابرًا في الخوادم العليا، لذا أعد الاختبار عند الحاجة وافحص التفويض في المنطقة الأب.
افحص سجل DS في المنطقة الأب، لا في محرّر DNS فقط
ابحث عن سجلات DS الخاصة بالنطاق:
dig example.com DS +noall +comments +answerولرؤية مسار التفويض بمزيد من التفصيل، تتبّع تسلسل DNS مباشرة:
dig +trace example.com DSيعتمد خادم الأسماء المخوّل للمنطقة الأب على نطاق المستوى الأعلى المعني. والمهم هو مجموعة سجلات DS التي تنشرها المنطقة الأب، لا مجرد ملخّص في لوحة تحكم استضافة DNS. فقد يحدث نقل تسجيل النطاق إلى مسجّل آخر دون تغيير خوادم الأسماء، كما يمكن تغيير خوادم الأسماء دون نقل النطاق إلى مسجّل آخر؛ وفي الحالتين يجب أن تظل سجلات DS في المنطقة الأب متوافقة مع المنطقة المخوّلة الفعلية.
يتكون سجل DS من أربعة حقول مهمة: معرّف المفتاح (key tag)، والخوارزمية، ونوع البصمة (digest type)، والبصمة نفسها. يسهّل معرّف المفتاح استكشاف الأخطاء، لكنه لا يثبت وحده تطابق DNSKEY. فلا بد أيضًا من توافق معلومات البصمة والخوارزمية مع مفتاح تقدّمه المنطقة المخوّلة فعلًا.
كانت الحالة الحاسمة في هذه الواقعة واضحة: استمرت المنطقة الأب في نشر معلومات ثقة DNSSEC القديمة، بينما أفادت خدمة DNS المخوّلة البديلة بأن توقيع المنطقة غير مفعّل. وكانت سجلات A موجودة ويمكن الحصول عليها عند تجاوز التحقق. لذلك لم يكن تغيير إعدادات التطبيق أو تعديل سجل A نفسه مرارًا ليصلح عدم التطابق.
طريقتان لإصلاح تفويض DNSSEC المعطّل
هناك استراتيجيتان مشروعَتان للاستعادة. كلتاهما تعالجان عدم التطابق في سلسلة الثقة، لكن آثارهما التشغيلية مختلفة. اختر إحداهما عن قصد، وتجنب الانتقال العشوائي بينهما.
الخيار الأول: إزالة سجل DS القديم وتشغيل المنطقة دون توقيع مؤقتًا
اطلب من مسجّل النطاق الحالي، أو استخدم واجهة إدارة DNSSEC التي يتيحها، إزالة سجل DS القديم من المنطقة الأب. وبعد أن تتوقف المنطقة الأب عن إعلان تفويض آمن، يمكن لمحلّلات DNS التي تجري التحقق اعتبار المنطقة التابعة غير الموقّعة غير مؤمّنة بواسطة DNSSEC بدلًا من اعتبار بياناتها غير صالحة. يستمر DNS في العمل، لكن مصادقة DNSSEC لهذا النطاق تتوقف مؤقتًا.
غالبًا ما يكون هذا الخيار الأبسط في الطوارئ، بشرط توفر وسيلة موثوقة لتعديل مجموعة سجلات DS في المنطقة الأب. أبقِ إعدادات التوقيع الحالية مستقرة حتى تنتهي مدة بقاء سجل DS القديم في ذاكرات التخزين المؤقت لدى المحلّلات التكرارية. إزالة DS من لوحة التحكم ليست دليلًا كافيًا بحد ذاتها؛ تحقق خارجيًا من سجل المنطقة الأب، وراعِ قيمة TTL الخاصة به. يظل HTTPS مستقلًا عن إعدادات DNSSEC. ويَرِد أيضًا وصف للانتقال المؤقت إلى منطقة غير موقّعة في RFC 8078.
الخيار الثاني: توقيع المنطقة الجديدة ونشر سجل DS مطابق
البديل هو تفعيل DNSSEC لدى مشغّل DNS المخوّل الجديد، وإنشاء مفاتيح DNSKEY وتوقيع المنطقة، ثم نشر سجل DS المقابل في المنطقة الأب. عندئذ يستطيع محلّل DNS الذي يجري التحقق بناء مسار ثقة إلى DNSKEY الجديد والتحقق من سجل A.
وهذا هو مسار الاستعادة الذي لوحظ بالفعل. فقد أفادت واجهة إدارة DNS بأنها أنشأت المفاتيح ووقّعت المنطقة ونشرت سجل DS جديدًا. ثم أظهر استعلام إلى المنطقة الأب سجل DS الجديد إلى جانب القديم. وبدأت الاستعلامات التكرارية التي تتحقق من DNSSEC تُرجع سجل A المتوقع؛ كما أعاد اختبار لاحق NOERROR مع ظهور العلامة ad، وهو ما يدل على أن محلّل DNS هذا اعتبر البيانات موثّقة.
ترتيب الخطوات مهم: لا ينفع نشر سجل DS ما لم يكن مفتاح DNSKEY المطابق والتواقيع الصالحة متاحَين بالفعل من خدمة DNS المخوّلة. وظهور عبارة «تم النشر» في لوحة التحكم لا يغني عن التحقق الخارجي. وقد يؤدي تخزين سجلات DS وDNSKEY وRRSIG وNS مؤقتًا إلى تعافي المحلّلات المختلفة في أوقات متفاوتة.
لماذا لم يؤدِّ وجود سجلَّي DS بالضرورة إلى استمرار العطل؟
من النتائج اللافتة أن المنطقة الأب احتوت مؤقتًا على سجل DS قديم لم يعد صالحًا للاستخدام وآخر جديد صالح، ومع ذلك نجح التحقق من DNSSEC. ولا يوجد تناقض هنا. يمكن أن تحتوي مجموعة سجلات DS على عدة سجلات، كما يحدث كثيرًا أثناء تبديل المفاتيح. لا يشترط المحلّل الذي يجري التحقق أن يشير كل سجل DS إلى مفتاح قابل للاستخدام حاليًا؛ بل يكفي وجود مسار مصادقة صالح عبر سجل DS مناسب إلى DNSKEY وتواقيع صحيحة. ويوضح RFC 6840 أن على المحلّلات قبول مسار صالح واحد.
لكن هذا لا يعني أن الاحتفاظ بالمفاتيح القديمة إلى الأبد أمر مستحسن. فسجل DS المتقادم يزيد الغموض التشغيلي وينبغي تنظيفه لاحقًا بعد التحقق من سلامة سلسلة الثقة الجديدة. غير أن إزالته تُعدّ صيانة، وليست مبررًا لإجراء إعادة ضبط محفوفة بالمخاطر لـ DNSSEC بينما تنجح الاستعلامات المتحقق منها بالفعل.
وهنا فخ خطير في بعض لوحات التحكم: قد يعني إجراء بعنوان «إلغاء نشر DS في حالات الطوارئ» إزالة جميع سجلات DS، بما فيها السجل الجديد الذي يعمل بصورة صحيحة. وبالمثل، فإن تعطيل توقيع المنطقة مع بقاء سجل DS منشورًا قد يعيد العطل فورًا. ولا يعادل أيٌّ من الإجراءين حذف سجل DS قديم بعينه. إذا لم تسمح الواجهة باستهداف سجل منفرد، فاستخدم تعديلًا انتقائيًا مدعومًا من مسجّل النطاق بدلًا من إعادة ضبط شاملة.
كيفية تغيير خوادم الأسماء المخوّلة بأمان
يعتمد التسلسل الأكثر أمانًا على إمكانية تنسيق المفاتيح بين مشغّل DNS القديم والجديد. في النقل المعتاد الذي يتضمن فترة مؤقتة بلا توقيع، يساعد الترتيب التالي على تجنب عدم التطابق الذي ظهر في هذه الحادثة:
- جهّز المنطقة الوجهة أولًا. انسخ سجلات A وAAAA وCNAME وMX وTXT المطلوبة، وغيرها من السجلات ذات الصلة. اختبر خوادم الأسماء المخوّلة الجديدة مباشرة قبل تغيير التفويض.
- افحص DNSSEC لدى المنطقة الأب. تحقق من وجود سجلات DS، وحدد الجهة القادرة على تحديثها. افعل ذلك حتى لو لم تفعّل DNSSEC يدويًا من قبل؛ إذ تُجري بعض خدمات DNS التوقيع تلقائيًا.
- أزل سجل DS القديم بينما لا تزال المنطقة القديمة الموقّعة تعمل. أكّد التغيير لدى خادم المنطقة الأب المخوّل، ثم انتظر مدة تكفي لانتهاء صلاحية بيانات DS المخزّنة سابقًا لدى المحلّلات. تتحدد مدة الانتظار وفق قيم TTL المرصودة، وليس وفق عدد ثابت يصلح لكل الحالات.
- غيّر تفويض خوادم الأسماء. أبقِ خدمة DNS المخوّلة السابقة متاحة ما دامت بعض التفويضات المخزّنة مؤقتًا قد تشير إليها. ضع قيم TTL لسجلات NS لدى المنطقة الأب في الحسبان، وتحقق من الخوادم التي تستخدمها المحلّلات المختلفة بالفعل.
- قرر ما إذا كنت ستعيد تفعيل DNSSEC. إذا كانت الخدمة الجديدة ستظل غير موقّعة، فلا تنشر سجل DS. أما إذا أردت توقيعها، فتحقق من أن DNSKEY الجديد والتواقيع يُقدَّمان بصورة صحيحة قبل نشر سجل DS المطابق. نسّق ذلك مع ذاكرات التخزين المؤقت التي ما زالت تشير إلى خوادم الأسماء القديمة لتجنب عدم تطابق جديد أثناء التحقق.
- تحقق بصورة مستقلة. افحص سجل DS لدى المنطقة الأب، وDNSKEY لدى الخادم المخوّل، ونتيجة حلّ الأسماء التكراري العادي، وحالة مصادقة البيانات لدى محلّلات DNS التي تتحقق من DNSSEC.
إذا كان استمرار حماية DNSSEC دون انقطاع شرطًا أساسيًا، فمن الأفضل تنسيق تدوير المفاتيح أو الانتقال بتوقيع متعدد الجهات صراحةً بدل المرور بفترة بلا توقيع. ويتطلب ذلك دعم المشغّلَين لترتيبات المفاتيح والتوقيع اللازمة؛ فمجرد نسخ بصمة DS القديمة إلى المزوّد الجديد ليس تدويرًا للمفاتيح.
قائمة تحقق قصيرة بعد النقل
بعد أي تغيير يتعلق بـ DNSSEC، تحقق من سجلات DNS ومن الدليل على أن المحلّلات تقبلها:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerاستخدم محلّل DNS تكراريًا يتحقق من DNSSEC لفحص الإجابة الموثّقة. تشير NOERROR مع سجل A المتوقع في استجابته إلى نجاح حلّ الاسم؛ كما تشير العلامة ad، إذا ظهرت، إلى أن المحلّل صادق على الإجابة وفق سياسة DNSSEC التي يتبعها. وغياب العلامة ad لا يثبت وحده وجود مشكلة، إذ تختلف قدرات المحلّلات وسياساتها وعلامات الاستعلام. وإذا فشلت استعلامات DNSKEY عبر محلّل يجري التحقق أثناء العطل، فاستعلم مباشرة من خدمة DNS المخوّلة النشطة ضمن التحقيق.
لا تتوقف عند نجاح استعلام واحد عبر محلّل واحد؛ فقد تحتفظ ذاكرات التخزين المؤقت المختلفة مؤقتًا بتفويضات ومفاتيح مختلفة. وحدّث أيضًا أي طلب دعم فني ما زال مفتوحًا: فقد تصبح تعليمات سابقة بحذف جميع سجلات DS خطيرة بعد نشر سجل جديد يعمل. يجب أن تؤكد المتابعة صراحةً ضرورة الإبقاء على المفتاح النشط، وأن تطلب، عند الحاجة، إزالة السجل القديم وحده.
لم ينشأ العطل عن عنوان خاطئ لخادم الويب؛ بل نتج عن تغيير الجهة التي تقدّم إجابات DNS دون مواءمة معلومات الثقة التي تُخبر المحلّلات بأي الإجابات ينبغي تصديقها. ولذلك فإن سؤال الفحص المسبق العملي قبل كل تغيير لخوادم الأسماء هو: ما سجلات DS التي تنشرها المنطقة الأب، وهل تتوافق معها مفاتيح DNSKEY والتواقيع لدى الوجهة الجديدة؟