تغيير مفتاح الجذر في DNSSEC: افحص المحلل لديك

ما الذي تغيّر في 11 أكتوبر 2026

ما يجب تذكّره

• المفتاح المطلوب — KSK-2024، رقم التعريف 38696، الخوارزمية 8 (RSA/SHA-256). أما المفتاح السابق KSK-2017 فرقمه 20326.
• العَرَض — المحلل الذي لا يثق إلا بالمفتاح 20326 لم يعد قادرًا على التحقق من الجذر. وتحذّر Verisign وICANN من أنه يفشل حينها في الحلّ، سواء كان الاسم المطلوب موقّعًا أم لا.
• الآلية المعتادة — يتيح RFC 5011 للمحلل أن يعتمد مفتاحًا جديدًا تلقائيًا بعد مراقبته 30 يومًا، بشرط أن يكون قيد التشغيل وقادرًا على الكتابة في ملف المرساة.
• الحالات المعرّضة للخطر — صورة نظام أو لقطة أقدم من المفتاح، أو ملف مرساة للقراءة فقط، أو مرساة ثابتة في dnsmasq أو في BIND.
• ما لا يتغيّر — سجل DS الخاص بنطاقك لدى السجل: التغيير يخصّ مفتاح الجذر، لا مفتاح منطقتك.
• المراحل التالية — إلغاء KSK-2017 مقرّر في 11 يناير 2027، وسحبه في 22 مارس 2027. والمحلل الذي يثق أصلًا بالمفتاح 38696 يتحقق من الجذر الموقّع بهذا المفتاح.

مالك النطاق أم مدير الخادم: من عليه التصرّف

متطلبات التشخيص

شخّص محللك في سبع خطوات

1. 01

   حدّد المحلل الذي يجيب

   يعرض cat /etc/resolv.conf العنوان الذي يستعلمه النظام، ويبيّن resolvectl status ما إذا كان systemd-resolved يتوسّط، ويسمّي sudo ss -lunp 'sport = :53' العملية التي تستمع على المنفذ 53: unbound أو named أو kresd أو dnsmasq أو pihole-FTL. هذه هي العملية التي ستفحصها.

2. 02

   استعلم الجذر باستخدام dig +dnssec

   شغّل dig +dnssec . SOA @127.0.0.1 ثم dig +dnssec com. SOA @127.0.0.1. انظر إلى حقلين في الترويسة: status: وflags:. القيمة status: NOERROR مع العلم ad تعني أن الإجابة تم التحقق منها. أما status: SERVFAIL على الجذر نفسه فهو أوضح علامة على مرساة قديمة.

3. 03

   اعزل التحقق باستخدام +cd

   يطلب dig +dnssec +cd com. SOA @127.0.0.1 من المحلل أن يجيب دون تحقق (checking disabled). إذا عاد هذا الاستعلام بـ NOERROR بينما فشل السابق بـ SERVFAIL، فالشبكة والخوادم الأعلى تعمل: ما يعطّل هو التحقق في DNSSEC، أي المرساة أو الساعة.

4. 04

   قارن بمحلل عام متحقِّق

   يجب أن يعيد dig +dnssec com. SOA @9.9.9.9 القيمة NOERROR مع ad. إذا كان المحلل العام يتحقق ومحللك لا، فالمشكلة محلية. وتحقّق في الوقت نفسه من ساعة الخادم باستخدام timedatectl: فالساعة المنحرفة تُفشل أيضًا التحقق من التواقيع وتنتج الخطأ SERVFAIL نفسه.

5. 05

   اعرف أيّ مفتاح يوقّع الجذر

   يعرض dig +dnssec +multi . DNSKEY @9.9.9.9 المفاتيح المنشورة. المفاتيح ذات العلم 257 هي مفاتيح KSK، ومع +multi يضيف dig قيمة key id لكلٍّ منها كتعليق. في المرحلة الحالية ما زال KSK-2017 منشورًا، لكن التوقيع (RRSIG) على مجموعة المفاتيح يحمل الرقم 38696: هذا هو المفتاح الذي يجب أن تعرفه مرساتك.

6. 06

   اقرأ المرساة المحمّلة فعلًا

   في Unbound: يجب أن يعيد sudo grep 'id = 38696' /var/lib/unbound/root.key (مسار Debian؛ وفي غيره يعطيك unbound-checkconf -o auto-trust-anchor-file مسارك) سطرًا موسومًا بـ VALID. في BIND: يجب أن يسرد sudo rndc secroots - السطر ./RSASHA256/38696 ; managed، وأن يعرض sudo rndc managed-keys status مدخلًا keyid: 38696 يليه trusted since. في Knot Resolver: استدعِ trust_anchors.summary() من وحدة التحكم. في dnsmasq: ابحث عن سطر trust-anchor=.,38696,8,2,… في الإعداد المحمّل.

7. 07

   تأكّد باستخدام delv

   يتحقق delv @127.0.0.1 com. SOA من الإجابة بنفسه ويعرض ; fully validated عندما تكتمل السلسلة. انتبه: يستخدم delv المرساة المضمّنة في ملفه التنفيذي، لا مرساة محللك. لذلك قد يفشل delv قديم وحده: حدّث الحزمة قبل أن تستنتج شيئًا عن المحلل.

أين توجد مرساة الثقة، محللًا تلو الآخر

مرّر الجدول أفقيًا

صحّح بحسب محللك

1. 08

   Unbound: حدّث المرساة

   حدّث النظام أولًا (sudo apt update && sudo apt upgrade). في Debian توفّر الحزمة dns-root-data الملف /usr/share/dns/root.key، وينسخ سكربت تشغيل Unbound هذا الملف إلى /var/lib/unbound/root.key عندما يكون أحدث؛ والإصدار 2024071801~deb12u1 المتاح لـ Debian 12 يتضمّن KSK-2024 بالفعل. ثم افرض الفحص بالأمر sudo -u unbound unbound-anchor -a /var/lib/unbound/root.key -v، يليه sudo systemctl restart unbound. ويتضمّن المفتاح المدمج في unbound-anchor المفتاح KSK-2024 منذ Unbound 1.21.0.

2. 09

   Unbound: اجعل RFC 5011 ممكنًا

   إذا ظلّ المفتاح غائبًا، فتحقّق من أن المستخدم unbound يستطيع الكتابة في الملف وفي مجلده أيضًا: فالتوثيق يشترط ذلك لإنشاء ملف مؤقت. ويكفي ls -ld /var/lib/unbound /var/lib/unbound/root.key لرؤية ذلك. والملف المركّب للقراءة فقط داخل حاوية يمنع التحديث التلقائي دون أي خطأ ظاهر لدى العميل.

3. 10

   BIND: auto أم مرساة مُعرّفة يدويًا

   مع dnssec-validation auto; ينطلق BIND من المرساة المرفقة بالبرنامج ويبقيها محدّثة عبر RFC 5011 في managed-keys.bind. حدّث الحزمة، وتحقّق من أن named يستطيع الكتابة في managed-keys-directory، ثم شغّل sudo rndc managed-keys refresh. ومع dnssec-validation yes; ومرساة معرّفة يدويًا، أضف إلى الكتلة trust-anchors السطر . initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16"; واحذف أي مرساة static-key لا تعرف إلا المفتاح 20326.

4. 11

   Knot Resolver: افحص ملف المرساة

   حدّث الحزمة، ثم انظر كيف عُرّف ملف المرساة. إذا كان للقراءة فقط (الوسيط الثاني true في trust_anchors.add_file() في v5، أو read-only: true في v6)، فالمحلل لا يعدّله أبدًا: على حزمة توزيعتك أن تجلب المفتاح. وإلا فتحقّق من أن kresd يستطيع الكتابة في الملف. ويوضّح التوثيق أنه عند غياب الملف يحاول المحلل تهيئة مرساة الجذر بنفسه.

5. 12

   systemd-resolved: حدّث systemd

   لا يحدّث systemd-resolved مرساته عبر DNS: وحده تحديث الحزمة يجلب المفتاح الجديد. وقد أُدرج في الشيفرة الأصلية، ولا سيما منذ systemd 256.12 و257.4، كما تتضمّنه حزمة systemd-resolved الحالية في Debian 12. افحص /etc/dnssec-trust-anchors.d/: فملف *.positive يعرّف مفتاحًا للجذر يعطّل المرساة المدمجة. احذفه أو أضف إليه المفتاح 38696، ثم شغّل sudo systemctl restart systemd-resolved وresolvectl flush-caches.

6. 13

   dnsmasq: أضف السطر الثابت

   لا يطبّق dnsmasq معيار RFC 5011: المرساة سطر ثابت. أضف trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 بجانب سطر المفتاح 20326، ثم أعد تشغيل الخدمة. في Debian 12 لا يحتوي الملف /usr/share/dnsmasq-base/trust-anchors.conf من الحزمة dnsmasq-base 2.90-4~deb12u2 إلا على المفتاح 20326، بينما يحتوي ملف Debian 13 على المفتاحين: تحقّق من الملف الذي يحمّله إعدادك فعلًا. أما Pi-hole v6 فيكتب السطرين بنفسه في /etc/pihole/dnsmasq.conf عند تفعيل التحقق في DNSSEC.

7. 14

   أتمِت الأمر للمرة القادمة

   لا تتقادم المرساة إلا على خادم توقّف عن التحديث. فعّل التحديثات الأمنية التلقائية لحزم المحلل (راجع التحديثات التلقائية على Debian وUbuntu)، وأضف إلى نظام المراقبة لديك فحصًا dig +dnssec com. SOA @127.0.0.1 ينبّهك عند ظهور SERVFAIL. وإذا كان DNS المحلي لديك يمرّ عبر Pi-hole، فدليل Pi-hole v6 على VPS يشرح كيف تضع Unbound قبله.

بعد التصحيح: ما الذي يجب مراقبته

استكشاف الأخطاء: الرسائل التي ستراها

رسائل الخطأ وحلولها

• failed to prime trust anchor -- DNSKEY rrset is not secure (سجل Unbound، يليه . DNSKEY IN) — حصل Unbound على مفاتيح الجذر لكنه لم يستطع التحقق منها بمرساته: مرساة قديمة أو ساعة خاطئة. حدّث root.key.
• failed to prime trust anchor -- could not fetch DNSKEY rrset — لا يحصل Unbound حتى على مفاتيح الجذر: المشكلة في الشبكة أو الجدار الناري أو تجزئة UDP، لا في المرساة. اختبر dig +dnssec . DNSKEY مقابل الخادم الأعلى.
• status: SERVFAIL مع +dnssec، وNOERROR مع +cd — هذه بصمة فشل في التحقق. ومع ede: yes في Unbound يتلقى العميل أيضًا رمز خطأ موسّعًا (RFC 8914).
• resolution failed: broken trust chain أو no valid RRSIG (delv) — لم يستطع delv الوصول إلى مرساة صالحة. تحقّق أولًا من أن delv نفسه محدّث.
• ; initializing managed في مخرجات rndc secroots - — يعرف BIND المفتاح لكنه لم يؤكّده قط عبر استعلام تحديث. شغّل rndc managed-keys refresh وافحص صلاحيات managed-keys-directory.
• unbound-anchor ينتهي بالرمز 0 دون تغيير أي شيء — بحسب صفحة الدليل الخاصة به، يعني الرمز 0 «لا حاجة إلى تحديث» كما يعني «خطأ». أعد تشغيله مع -v وأعد قراءة الملف.

الخلاصة