أساسيات DNSSEC لمالكي النطاقات: ما الذي يحميه وكيف تفعّله وكيف تتحقق منه

صُمم نظام DNS دون وسيلة تتيح لخادم الحل التأكد من أن الإجابة صادرة فعلاً عن مالك النطاق. ويضيف DNSSEC (امتدادات أمان DNS) تواقيع رقمية إلى بيانات DNS بحيث تستطيع خوادم الحل التي تتحقق منها كشف الإجابات المزورة أو المعدلة. ويؤكد RFC 9364 (BCP 237) أن استخدام DNSSEC للتحقق من مصدر بيانات DNS هو أفضل ممارسة حالية.

فهم DNSSEC مهم حتى لو لم تفعّله بعد، لأن الإعداد المعطوب أسوأ من عدم وجوده: فخوادم الحل التي تتحقق ترفض الإجابة عن النطاق، ومنذ 15 مارس 2026 يجب على جهات إصدار الشهادات العامة أيضاً رفض إصدار الشهادات له.

ما الذي يحميه DNSSEC وما الذي لا يحميه

بحسب شرح ICANN، يضيف DNSSEC خاصيتين: التحقق من مصدر البيانات (أن الإجابة جاءت من المنطقة التي تدّعي أنها منها)، وسلامة البيانات (أنها لم تُعدّل بعد توقيعها). وهذا يحمي من تسميم الذاكرة المؤقتة، حيث يدفع المهاجم خادم حل إلى قبول إجابة مزورة ثم تقديمها لعدد كبير من المستخدمين.

ويوضح RFC 4033 الحدود بالقدر نفسه من الوضوح:

• لا يوفر السرية؛ فالاستعلامات والإجابات تبقى مرئية على الشبكة.
• لا يوفر حماية من هجمات حجب الخدمة.
• لا يحمي عمليات مثل نقل المنطقة والتحديث الديناميكي.
• لا يفيد إذا دخل مهاجم إلى حسابك لدى المسجّل أو مزود DNS، فالسجلات التي تُغيَّر هناك تُوقَّع كغيرها. احمِ هذه الحسابات بكلمات مرور قوية والتحقق بخطوتين.
• لا يحمي إلا المستخدمين الذين يتحقق خادم الحل لديهم، وتشير ICANN إلى أن التحقق يجب أن يفعّله مشغلو خوادم الحل.

السجلات المعنية

يتبع التحقق تسلسلاً للثقة: تثق خوادم الحل بمفتاح منطقة الجذر (الموقّعة منذ 2010 بحسب ICANN)، والجذر يضمن مفتاح النطاق العلوي، وسجل DS لدى النطاق العلوي يضمن مفتاحك. إذا غابت حلقة عُومِلت منطقتك كمنطقة غير موقّعة (insecure)، وإذا وُجدت حلقة خاطئة، كسجل DS لا يطابق أي مفتاح حالي، عُومِلت منطقتك كمنطقة معطوبة (bogus) وأعادت خوادم الحل الخطأ SERVFAIL.

التفعيل

لـDNSSEC شقان يتولاهما طرفان مختلفان:

1. التوقيع لدى مزود DNS. ينشئ المزود المفاتيح ويوقّع المنطقة ويعيد توقيعها مع اقتراب انتهاء التواقيع. وتشير ICANN إلى أن الأمر لدى كثير من المزودين لا يتعدى خانة اختيار. أما إذا كنت تدير BIND أو خادماً موثوقاً آخر بنفسك فهذه مهمتك.
2. نشر سجل DS لدى المسجّل. يعطيك مزود DNS بيانات DS (رقم المفتاح والخوارزمية ونوع البصمة والبصمة)، فتقدمها عبر المسجّل الذي يمررها إلى جهة التسجيل. بعض المزودين يؤتمتون هذه الخطوة، لكنها كثيراً ما تبقى يدوية. تأكد قبل البدء من أن المسجّل وجهة تسجيل نطاقك العلوي يقبلان سجلات DS.

الترتيب مهم: وقّع أولاً، وتأكد من ظهور سجلات DNSKEY، ثم أضف DS. فإذا وصل سجل DS إلى المنطقة الأم قبل توقيع منطقتك بالمفتاح المطابق، أصبح النطاق معطوباً.

التحقق من الإعداد

على Debian أو Ubuntu تأتي الأداتان dig وdelv من الحزمة bind9-dnsutils (sudo apt install bind9-dnsutils).

dig example.com DS +short
dig example.com DNSKEY +short
dig example.com A +dnssec

يعرض الأمر الأول سجل DS الذي تنشره المنطقة الأم، والثاني مفاتيح منطقتك. وفي الثالث يضع خادم الحل المتحقق العلامة ad (بيانات موثقة) في الترويسة عند نجاح التحقق، ويطلب الخيار +dnssec تضمين سجلات RRSIG.

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

delv example.com A
delv example.com A +vtrace

يعرض الخيار +vtrace منطق المتحقق عند الفشل. وللحصول على عرض مرئي للتسلسل كاملاً، توصي وثائق Let's Encrypt بأداة تشخيص مثل dnsviz.net.

اللحظات الحرجة

• تغيير مزود DNS. يوقّع المزود الجديد بمفاتيح جديدة، فلا يعود سجل DS القديم مطابقاً. يصف RFC 6781 تسليماً تعاونياً للمفاتيح بين المزودَين، وعند عدم تعاون المزود القديم يكون الخيار الوحيد العملي ترك المنطقة غير موقّعة مؤقتاً: احذف DS لدى المسجّل، وانتظر انتهاء صلاحيته في الذاكرات المؤقتة، ثم انقل المنطقة ووقّعها، ثم أضف DS الجديد.
• إيقاف DNSSEC. احذف DS أولاً، وانتظر انتهاءه من الذاكرات المؤقتة، ثم أوقف التوقيع. العكس يترك سجل DS يشير إلى تواقيع لم تعد موجودة.
• توقف التوقيع الذاتي. للتواقيع تواريخ انتهاء، وإذا توقفت إعادة التوقيع تصبح المنطقة معطوبة عند انتهائها.
• إصدار الشهادات. منذ 15 مارس 2026 تُلزم المتطلبات الأساسية لمنتدى CA/Browser جهاتِ الإصدار بالتحقق من DNSSEC أثناء التحقق من النطاق وفحص CAA، وتمنع اعتبار أخطاء مثل SERVFAIL إذناً بالإصدار. أي أن المنطقة المعطوبة تعني الآن فشل تجديد الشهادات إضافة إلى تعذر الوصول إلى الخدمات.

ما الذي ينبغي فعله

• أمّن حساباتك لدى المسجّل ومزود DNS أولاً، فـDNSSEC لا يحمي من التغييرات التي تتم هناك.
• إذا كان مزود DNS والمسجّل يدعمانه، فعّل التوقيع، وتحقق من سجلات DNSKEY، ثم أضف سجل DS.
• افحص النتيجة بـdelv وdig +dnssec، وراجع التسلسل في أداة تشخيص DNSSEC.
• قبل تغيير مزود DNS أو إيقاف DNSSEC، خطط لحذف DS ومدة الانتظار.
• أضف فحصاً لـDNSSEC إلى أدوات المراقبة لديك ليُكتشف عطب المنطقة قبل أن يفشل المستخدمون أو تجديد الشهادات.

المصادر

• rfc-editor.org/rfc/rfc9364.html
• rfc-editor.org/rfc/rfc4033.html
• rfc-editor.org/rfc/rfc6781.html
• icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
• manpages.debian.org/trixie/bind9-dnsutils/delv.1.en.html
• manpages.debian.org/trixie/bind9-dnsutils/dig.1.en.html
• letsencrypt.org/docs/caa
• cabforum.org/working-groups/server/baseline-requirements/documents
• github.com/cabforum/servercert/blob/main/docs/BR.md