لماذا خطأ DS انقطاع للخدمة وليس ثغرة
يعتمد DNSSEC على سلسلة ثقة: تنشر المنطقة الأم (مثل منطقة الامتداد) سجل DS هو بصمة مفتاح توقيع منطقة العميل، وتقارن المحللات المُدقِّقة هذه البصمة بالمفاتيح التي تنشرها المنطقة فعلاً. فإذا لم تعد البصمة تطابق أي مفتاح، لا يستطيع المحلل إثبات صحة الردود فيرفض الإجابة، ويتلقى المستخدم رد SERVFAIL.
وهذا ما يجعل الخطأ خادعاً. يواصل النطاق الاستجابة عند محلل لا يدقّق، فيبدو اختبار سريع من جهاز أو شبكة شركة سليماً، بينما لا يستطيع المستخدمون خلف محلل عام مُدقِّق حل أي اسم. DS اليتيم لا يخفض الأمان، بل يقطع النطاق. ويهدف بقية الدليل إلى عدم صنع واحد منها أبداً، وإلى معرفة كيفية الخروج منه.
من يفعل ماذا: مشغّل DNS والمسجّل والسجل
يتدخل ثلاثة أطراف، والخلط بينها يسبب معظم الحوادث. يستضيف مشغّل DNS المنطقة ويملك المفاتيح: فهو يوقّع وينشر سجلات DNSKEY وRRSIG. والمسجّل هو الواجهة التجارية التي يدير فيها المالك اسمه، وينقل سجل DS إلى السجل. أما السجل فيدير المنطقة الأم وينشر DS.
لذلك لا يُنشأ DS لدى المسجّل وحده أبداً: إنه ينسخ معلومة ينتجها مشغّل DNS. فإذا كان النطاق مسجلاً لدى مسجّل بينما تشير خوادم الأسماء إلى مشغّل آخر، يُطلب التوقيع من مشغّل DNS ويُدخل DS لدى المسجّل. يُفترض هنا أن التعريف العام لـ DNSSEC ودوره ضد تسميم الذاكرة المؤقتة معروف؛ أما المقال عن تغيير المفتاح الجذر في 11 أكتوبر 2026 من جهة المحلل فيعالج الطرف الآخر من السلسلة.
تفعيل DNSSEC بالترتيب الصحيح
التأكد من أن الامتداد والمسجّل يقبلان DS
قبل لمس المنطقة، تأكد من أن المسجّل يوفّر حقل DS لهذا الامتداد وأن السجل يقبل الخوارزمية المقررة. لا تقبل كل السجلات كل الخوارزميات: قائمة الامتداد هي المعتمدة وليست قائمة مشغّل DNS. وبعض الامتدادات لا توفّر DNSSEC إطلاقاً بحكم قاعدة السجل.
كتابة خطة التراجع قبل البدء
دوّن الحالة الراهنة: خوادم الأسماء، وقيم TTL للمنطقة، وغياب DS. التقطها بالأمرين
dig NS your-domain.com +shortوdig DS your-domain.com +short. واكتب أيضاً من يستطيع حذف DS لدى المسجّل وعبر أي قناة إذا حدثت مشكلة. التراجع الذي يعتمد على شخص لا يمكن بلوغه ليس تراجعاً.توقيع المنطقة لدى مشغّل DNS
فعّل التوقيع في واجهة المشغّل، أو بأدواته إن كنت تدير الخادم بنفسك. يولّد المشغّل مفتاح توقيع المفاتيح (KSK) ومفتاح توقيع المنطقة (ZSK) ثم ينشر سجلات DNSKEY وRRSIG. في هذه المرحلة لا يتغير شيء بالنسبة إلى المحللات: فبدون DS في المنطقة الأم تكون المنطقة موقّعة لكنها غير مُدقَّق فيها، فلا خطر.
انتظار انتشار DNSKEY والتوقيعات
تحتفظ المحللات بالردود القديمة في الذاكرة المؤقتة حتى ينتهي TTL. انتظر على الأقل أطول TTL في المنطقة قبل المتابعة، وتحقق من أن
dig +dnssec your-domain.com DNSKEYيعيد المفاتيح وتوقيعها من كل خادم أسماء.استخراج معاملات DS
يزوّدك مشغّل DNS بأربع قيم: معرّف المفتاح key tag، والخوارزمية، ونوع الملخّص، والبصمة. تأكد من أنها تطابق مفتاح KSK المنشور (قيمة flags تساوي 257) واختر ملخّص SHA-256 من النوع 2. انسخها والصقها بدل كتابتها يدوياً: حرف واحد خاطئ ينتج DS يتيماً.
نشر DS لدى المسجّل
أدخل القيم الأربع في حقل DS لدى المسجّل. ينشر السجل بعدها DS في المنطقة الأم بمهلة خاصة بالامتداد. وما دامت هذه المهلة لم تنقضِ، ترى بعض المحللات الحالة القديمة: لا تستنتج إلا بعد التحقق.
التحقق من السلسلة من البداية إلى النهاية
استعلم من خادم المنطقة الأم، ثم من محلل مُدقِّق، ثم بـ
delvكما يفصّل القسم التالي. أبقِ خطة التراجع مفتوحة حتى تنجح الفحوص الثلاثة من محللين عامين مُدقِّقين مختلفين على الأقل.
الخوارزميات والملخّصات: ما تفرضه RFC 8624
مرّر الجدول أفقيًا
| المعامل | القيمة | الحالة في RFC 8624 |
|---|---|---|
| توقيع ECDSAP256SHA256 | 13 | MUST، الخيار الشائع |
| توقيع RSASHA256 | 8 | MUST |
| توقيع ED25519 | 15 | RECOMMENDED |
| توقيع ED448 وECDSAP384SHA384 | 16 و14 | MAY |
| توقيعات RSASHA1 ومتغيراتها | 5 و7 و10 | NOT RECOMMENDED |
| ملخّص DS: SHA-256 | 2 | MUST |
| ملخّص DS: SHA-1 وGOST | 1 و3 | MUST NOT للتفويض |
التحقق بـ dig وdelv مع مخرجات فعلية
تكفي أربعة فحوص. الأول dig +dnssec your-domain.com DNSKEY يجب أن يعيد سجلَّي DNSKEY بالعلمين 256 (ZSK) و257 (KSK) مع RRSIG. والثاني dig DS your-domain.com @<parent server> يستعلم مباشرة من المنطقة الأم ويجب أن يعيد سطراً بالصيغة <key tag> <algorithm> <digest type> <digest>، مثل 2371 13 2 <digest> (قيم توضيحية): يجب أن يكون key tag هو معرّف مفتاح KSK الذي ينشره المشغّل.
الثالث dig +dnssec your-domain.com A @1.1.1.1 يجب أن يُظهر العلم ad (authenticated data) في سطر flags، مثل flags: qr rd ra ad. والرابع delv your-domain.com A @1.1.1.1 يجب أن يطبع ; fully validated قبل الجواب. ويبدو الفشل هكذا: يعيد dig القيمة status: SERVFAIL، وغالباً مع EDE 9 DNSKEY Missing، ويفيد delv بـ resolution failed.
ما قد يعيقك لدى المسجّل أو السجل
- لا حقل DS — لا يوفّر المسجّل الإدخال لهذا الامتداد، أو يوفّره عبر تذكرة فقط: اسأل قبل توقيع المنطقة.
- خوارزمية مرفوضة — يقبل السجل جزءاً فقط من خوارزميات RFC 8624؛ اقرأ قائمة الامتداد لا قائمة مشغّل DNS.
- ملخّص محدود — بعض النماذج تقبل SHA-256 فقط؛ وهو الخيار الصحيح، لكن يجب معرفة ذلك قبل توليد DS.
- مهلة النشر — لا تُحدَّث المنطقة الأم لحظياً؛ وتختلف المهلة باختلاف الامتداد، فلا تختبر مبكراً.
- امتداد بلا DNSSEC — بعض الامتدادات لا توفّر الميزة؛ يبقى النطاق صالحاً لكن لا يمكن توقيعه.
- تحقق يدوي — يمر الطلب عبر تذكرة لدى المسجّل أو جهة اتصال، فيطول التراجع: أدرج ذلك في الخطة.
تغيير مزوّد DNS دون ترك DS يتيم
هذه الحالة هي الأكثر تسبباً في الانقطاعات. يبقى DS لدى المسجّل بينما تتغير خوادم الأسماء: فإذا لم يوقّع المشغّل الجديد، أو وقّع بمفاتيح أخرى، لا يطابق DS القديم أي شيء وتردّ المحللات المُدقِّقة بـ SERVFAIL. ويحدث الحادث نفسه عند ترحيل منطقة مع الإبقاء على DS القديم.
تميّز RFC 6781 بين حالتين بحسب تعاون المشغّل القديم. إذا تعاون، يتبادل المشغّلان مفاتيحهما العامة وينشران المجموعتين أثناء التحويل، فلا تمر فترة غير موقّعة. وإذا لم يتعاون، تخلص RFC إلى أن العملية الوحيدة الممكنة هي ترك المنطقة تصبح غير موقّعة: حذف DS، وتغيير خوادم الأسماء، ثم إدخال DS يشير إلى المنطقة الموقّعة حديثاً. وعند الشك، طبّق النسخة الحذرة أدناه، فهي تصلح للحالتين.
إجراء حذر لتغيير مزوّد DNS
تجهيز المنطقة لدى المشغّل الجديد
أعد إنشاء كل السجلات دون توقيع ودون تغيير خوادم الأسماء. قارن المنطقتين سجلاً بسجل، مثلاً بـ
dig @<old server> your-domain.com MX +shortثمdig @<new server> your-domain.com MX +short، وكذلك للسجلين A وTXT.تدوين TTL الخاص بـ DS
استعلم بـ
dig DS your-domain.com @<parent server>ودوّن قيمة TTL المعروضة: إنها المدة التي قد تظل فيها المحللات تصدّق DS القديم.حذف DS لدى المسجّل
اطلب حذف DS ثم تأكد من اختفائه بالأمر نفسه على خادم المنطقة الأم. تصبح المنطقة غير موقّعة بالنسبة إلى المحللات، وهي حالة صالحة لا تسبب انقطاعاً.
انتظار انتهاء TTL الخاص بـ DS
انتظر على الأقل المدة المدوّنة قبل لمس خوادم الأسماء. إن سحب المفاتيح قبل انقضاء DS من الذاكرة المؤقتة يعيد صنع DS اليتيم الذي تحاول تفاديه.
تغيير خوادم الأسماء
عدّل سجلات NS لدى المسجّل. تحقق من التحويل بـ
dig NS your-domain.com @<parent server>ثم اختبر الحل من محلل مُدقِّق. ويفصّل الدليل الخاص بتغيير خوادم الأسماء العملية في فضاء العميل.التوقيع لدى المشغّل الجديد ثم إعادة نشر DS
فعّل التوقيع، وانتظر انتشار DNSKEY، واستخرج المعاملات الجديدة وانشر DS كما في التفعيل الأولي. واختم بفحوص dig وdelv الأربعة.
تدوير المفاتيح وسجلات CDS وCDNSKEY
عمليتا صيانة متشابهتان لكن أثرهما لدى المسجّل مختلف. لا يتطلب تدوير ZSK أي إجراء لدى المسجّل، لأن DS لا يغطي إلا KSK. أما تدوير KSK فيستلزم DS جديداً: تصف RFC 6781 طريقة التوقيع المزدوج في أربع مراحل، مع انتظار TTL الخاص بـ DS على الأقل قبل سحب المفتاح القديم. وعند تغيير الخوارزمية، تطلب RFC نفسها سحب DS من المنطقة الأم أولاً، ثم DNSKEY والتوقيعات.
ولتفادي الإدخال اليدوي، تعرّف RFC 7344 سجلَّي CDS وCDNSKEY: ينشر مشغّل DNS في المنطقة سجل DS المطلوب ويمكن لوكيل المنطقة الأم أن يستهلكه بعد التحقق عبر DNSSEC. وتضيف RFC 8078 الحذف عبر CDS 0 0 0 0 أو CDNSKEY 0 3 0 0. ويبقى أن السجل أو المسجّل هو من يقرر استهلاكها، وأن دعمها يتوقف على الامتداد. وفي 13 أكتوبر 2026 فتحت ICANN مشاورة عامة حول تقييم الأمن والاستقرار لأتمتة DS، مفتوحة حتى 23 نوفمبر 2026. ولا يذكر الإعلان CDS ولا CDNSKEY: فالأتمتة غير معتمدة ولا وشيكة في هذه المرحلة.
الأعراض والأسباب والحلول
مرّر الجدول أفقيًا
| العرض | السبب المحتمل | الحل |
|---|---|---|
| SERVFAIL عند 1.1.1.1 أو 8.8.8.8 وجواب عادي في غيرهما | DS يتيم أو مفتاح غائب عن المنطقة | سحب DS وانتظار TTL ثم نشر DS صحيح |
| `EDE: 9 (DNSKEY Missing)` في مخرجات dig | لا يطابق أي DNSKEY سجل DS | مقارنة key tag الخاص بـ DS مع KSK المنشور |
| يجيب `delv` بـ `resolution failed` | سلسلة الثقة مقطوعة | الاختبار بـ `dig +cd` للتأكد من أن المنطقة تجيب دون تدقيق |
| لا علم `ad` ولا خطأ | محلل لا يدقّق أو DS لم يُنشر بعد | الاستعلام من محلل آخر وانتظار مهلة السجل |
| انقطاع بعد تغيير خوادم الأسماء | مشغّل جديد غير موقّع مع بقاء DS القديم | اتباع الإجراء الحذر بدءاً بسحب DS |
| توقيعات منتهية الصلاحية | توقف التوقيع التلقائي لدى المشغّل | إعادة تشغيل التوقيع ومقارنة تواريخ RRSIG |
خطة التراجع تُكتب قبل العملية لا أثناءها
دوّن كتابةً الحالة الأولية، والأمر الذي يثبت كل مرحلة، والشخص القادر على حذف DS عند الطوارئ. وعند الشك، يبقى المخرج الأقصر واحداً: حذف DS لدى المسجّل ثم انتظار TTL الخاص به. تعود المنطقة غير موقّعة لكنها قابلة للوصول، ثم يُشخَّص الأمر دون ضغط بـ dig +cd.
ما تفعله ServOrbit.com وما لا تفعله
لا يُفعَّل DNSSEC ذاتياً من فضاء العميل. لطلبه، افتح تذكرة من فضاء العميل أو راسلنا على [email protected]. ويتوقف الدعم على الامتداد وسجلّه، ولا سيما بالنسبة إلى نطاقات .ma. ولا توقّع ServOrbit.com المناطق نيابةً عنك ولا تعرض حقل DS في فضاء العميل: يصف هذا الدليل الطريقة وليس ميزة تلقائية. أما DNS المُدار من Cloudflare، الوارد في دليل التفعيل الخاص به، فلا يُذكر هنا إلا في نقطة واحدة: تغيير خوادم الأسماء على نطاق موقّع أصلاً يعرّض لخطر DS اليتيم. ولإضافة السجلات أو تعديلها أثناء التحضير يبقى دليل سجلات DNS هو المرجع، ويغطي دليل النقل الصادر حالة تغيير المسجّل. دليل مقدَّم دون دعم مشمول.
الوثائق الرسمية
RFC 6781، الممارسات التشغيلية لـ DNSSEC: https://www.rfc-editor.org/rfc/rfc6781.html
RFC 8624، الخوارزميات والملخّصات: https://www.rfc-editor.org/rfc/rfc8624.html
RFC 7344، سجلات CDS وCDNSKEY: https://www.rfc-editor.org/rfc/rfc7344.html
RFC 8078، إدارة DS من جهة المنطقة الفرعية: https://www.rfc-editor.org/rfc/rfc8078.html
مشاورة ICANN حول أتمتة DS: https://www.icann.org/en/announcements/details/icann-seeks-input-on-security-stability-assessment-of-dnssec-ds-automation-13-10-2026-en
تغيير KSK الجذر: https://www.icann.org/resources/pages/ksk-rollover-en
