[{"data":1,"prerenderedAt":218},["ShallowReactive",2],{"seo-verification":3,"blog-تغيير-مفتاح-الجذر-dnssec-2026-فحص-المحلل-ar":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-تغيير-مفتاح-الجذر-dnssec-2026-فحص-المحلل-ar",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":162,"ctaBody":163,"ctaButton":164,"ctaUrl":165,"relatedPosts":166},493,"تغيير-مفتاح-الجذر-dnssec-2026-فحص-المحلل",{"fr":12,"en":13,"ar":10,"es":14},"rollover-ksk-racine-dns-2026-dnssec-resolveurs","root-dnssec-ksk-rollover-2026-check-your-resolver","rollover-ksk-raiz-dnssec-2026-revisar-resolver","تغيير مفتاح الجذر في DNSSEC: افحص المحلل لديك","أصبح جذر DNS موقّعًا بالمفتاح KSK-2024 (key tag 38696). افحص مرساة الثقة في Unbound وBIND وKnot Resolver وsystemd-resolved وdnsmasq وصحّحها.",12,0,false,"2026-10-22T00:00:00+00:00","2026-10-23T13:27:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"الأمان والمراقبة","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Frollover-ksk-racine-dns-2026-dnssec-resolveurs-poster.svg","منذ 11 أكتوبر 2026، أصبحت منطقة الجذر في DNS موقّعة بمفتاح جديد هو KSK-2024، ورقم تعريفه (key tag) هو 38696. المحلل المتحقِّق الذي لا يعرف هذا المفتاح لم يعد قادرًا على بناء سلسلة الثقة في DNSSEC: فيردّ بالخطأ SERVFAIL حتى على أسماء تعمل في أماكن أخرى، ويبدو العطل كأنه انقطاع في الشبكة. يشرح هذا الدليل كيف تفحص خلال عشر دقائق مرساة الثقة في Unbound وBIND وKnot Resolver وsystemd-resolved وdnsmasq، وتثبت ذلك باستخدام `dig` و`delv`، ثم تصحّحها.",[35,39,49,52,55,80,116,140,143,147,150,159],{"type":36,"title":37,"body":38},"h2","ما الذي تغيّر في 11 أكتوبر 2026","يعتمد DNSSEC على جذر ثقة واحد: مفتاح توقيع المفاتيح (KSK) لمنطقة الجذر. يحتفظ كل محلل متحقِّق بنسخة محلية منه تُسمّى مرساة الثقة، ويتحقق انطلاقًا منها من كل ما عداها. وبحسب IANA، نُشر المفتاح KSK-2024 (key tag 38696) في منطقة الجذر في 11 يناير 2025، ثم بدأ توقيع الجذر في 11 أكتوبر 2026 بدلًا من KSK-2017 (key tag 20326).\n\nفي 15 أكتوبر 2026، أعلنت ICANN أن تغيير المفتاح اكتمل كما كان مقرّرًا. ويذكر الإعلان بلاغات تخصّ عددًا محدودًا من الأنظمة، ويوضّح أن ICANN ما زالت تقيّم ما إذا كانت مرتبطة بالتغيير: فلا يقدّم رقمًا ولا سببًا، ولا يفترض هذا الدليل أيًّا منهما. ولم ينتهِ الجدول الزمني بعد: تعتزم IANA إلغاء KSK-2017 في 11 يناير 2027، ثم سحبه من المنطقة في 22 مارس 2027.",{"type":40,"title":41,"items":42},"ul","ما يجب تذكّره",[43,44,45,46,47,48],"**المفتاح المطلوب** — KSK-2024، رقم التعريف 38696، الخوارزمية 8 (RSA\u002FSHA-256). أما المفتاح السابق KSK-2017 فرقمه 20326.","**العَرَض** — المحلل الذي لا يثق إلا بالمفتاح 20326 لم يعد قادرًا على التحقق من الجذر. وتحذّر Verisign وICANN من أنه يفشل حينها في الحلّ، سواء كان الاسم المطلوب موقّعًا أم لا.","**الآلية المعتادة** — يتيح RFC 5011 للمحلل أن يعتمد مفتاحًا جديدًا تلقائيًا بعد مراقبته 30 يومًا، بشرط أن يكون قيد التشغيل وقادرًا على الكتابة في ملف المرساة.","**الحالات المعرّضة للخطر** — صورة نظام أو لقطة أقدم من المفتاح، أو ملف مرساة للقراءة فقط، أو مرساة ثابتة في dnsmasq أو في BIND.","**ما لا يتغيّر** — سجل DS الخاص بنطاقك لدى السجل: التغيير يخصّ مفتاح الجذر، لا مفتاح منطقتك.","**المراحل التالية** — إلغاء KSK-2017 مقرّر في 11 يناير 2027، وسحبه في 22 مارس 2027. والمحلل الذي يثق أصلًا بالمفتاح 38696 يتحقق من الجذر الموقّع بهذا المفتاح.",{"type":36,"title":50,"body":51},"مالك النطاق أم مدير الخادم: من عليه التصرّف","كثيرًا ما يُخلط بين دورين في طلبات الدعم. مالك النطاق الموقَّع ينشر سجل DS لدى السجل، يشير إلى مفتاح منطقته هو. وهذا السجل لا يعتمد على مفتاح الجذر: لا شيء يجب تغييره بسبب هذا التبديل، لا في منطقة `example.com` ولا لدى مسجّل النطاقات. وإذا كنت تدير سجلاتك فقط (راجع \u003Ca href=\"\u002Fblog\u002Fajouter-enregistrement-dns-domaine\">إضافة سجل DNS\u003C\u002Fa>)، فأنت غير معنيّ.\n\nأما مدير الخادم الذي يشغّل محللًا متحقِّقًا فمعنيّ. Unbound خلف خادم بريد، أو BIND على خادم مراقبة، أو Knot Resolver داخل حاوية، أو systemd-resolved مع تفعيل DNSSEC، أو dnsmasq أو Pi-hole مع تفعيل التحقق: لكلٍّ منها مرساته الخاصة. وعلى خادم VPS تملك فيه صلاحيات root، فإن هذا المدير هو أنت. أما الخادم الذي يمرّر استعلاماته إلى محلل عام دون أن يتحقق بنفسه، فيعتمد على مرساة ذلك المحلل لا على مرساته.",{"type":36,"title":53,"body":54},"متطلبات التشخيص","خصّص عشر دقائق وصلاحيات root أو sudo على الخادم. تكفي أداتان: `dig` و`delv`، ويوفّرهما على Debian وUbuntu الحزمة `bind9-dnsutils` (`sudo apt install bind9-dnsutils`)، وعلى AlmaLinux أو Rocky Linux الحزمة `bind-utils`. لا حاجة إلى موارد خاصة: حجم الاستعلامات بضعة كيلوبايتات.\n\nدوّن عنوان الاستماع الخاص بمحللك، وهو عادة `127.0.0.1`، أو `127.0.0.53` في حالة systemd-resolved، واحتفظ بعنوان محلل عام متحقِّق للمقارنة، مثل `9.9.9.9`. المخرجات الموصوفة أدناه أمثلة على الشكل، لا قياسات من خادمك: المهم هو الحقول المذكورة فقط. وتستهدف الاختبارات الجذر و`com.`، وهما منطقتان موقّعتان، فلا تعتمد على أي نطاق بعينه.",{"type":56,"title":57,"steps":58},"steps","شخّص محللك في سبع خطوات",[59,62,65,68,71,74,77],{"title":60,"body":61},"حدّد المحلل الذي يجيب","يعرض `cat \u002Fetc\u002Fresolv.conf` العنوان الذي يستعلمه النظام، ويبيّن `resolvectl status` ما إذا كان systemd-resolved يتوسّط، ويسمّي `sudo ss -lunp 'sport = :53'` العملية التي تستمع على المنفذ 53: `unbound` أو `named` أو `kresd` أو `dnsmasq` أو `pihole-FTL`. هذه هي العملية التي ستفحصها.",{"title":63,"body":64},"استعلم الجذر باستخدام dig +dnssec","شغّل `dig +dnssec . SOA @127.0.0.1` ثم `dig +dnssec com. SOA @127.0.0.1`. انظر إلى حقلين في الترويسة: `status:` و`flags:`. القيمة `status: NOERROR` مع العلم `ad` تعني أن الإجابة تم التحقق منها. أما `status: SERVFAIL` على الجذر نفسه فهو أوضح علامة على مرساة قديمة.",{"title":66,"body":67},"اعزل التحقق باستخدام +cd","يطلب `dig +dnssec +cd com. SOA @127.0.0.1` من المحلل أن يجيب دون تحقق (checking disabled). إذا عاد هذا الاستعلام بـ `NOERROR` بينما فشل السابق بـ `SERVFAIL`، فالشبكة والخوادم الأعلى تعمل: ما يعطّل هو التحقق في DNSSEC، أي المرساة أو الساعة.",{"title":69,"body":70},"قارن بمحلل عام متحقِّق","يجب أن يعيد `dig +dnssec com. SOA @9.9.9.9` القيمة `NOERROR` مع `ad`. إذا كان المحلل العام يتحقق ومحللك لا، فالمشكلة محلية. وتحقّق في الوقت نفسه من ساعة الخادم باستخدام `timedatectl`: فالساعة المنحرفة تُفشل أيضًا التحقق من التواقيع وتنتج الخطأ SERVFAIL نفسه.",{"title":72,"body":73},"اعرف أيّ مفتاح يوقّع الجذر","يعرض `dig +dnssec +multi . DNSKEY @9.9.9.9` المفاتيح المنشورة. المفاتيح ذات العلم `257` هي مفاتيح KSK، ومع `+multi` يضيف dig قيمة `key id` لكلٍّ منها كتعليق. في المرحلة الحالية ما زال KSK-2017 منشورًا، لكن التوقيع (RRSIG) على مجموعة المفاتيح يحمل الرقم 38696: هذا هو المفتاح الذي يجب أن تعرفه مرساتك.",{"title":75,"body":76},"اقرأ المرساة المحمّلة فعلًا","في Unbound: يجب أن يعيد `sudo grep 'id = 38696' \u002Fvar\u002Flib\u002Funbound\u002Froot.key` (مسار Debian؛ وفي غيره يعطيك `unbound-checkconf -o auto-trust-anchor-file` مسارك) سطرًا موسومًا بـ `VALID`. في BIND: يجب أن يسرد `sudo rndc secroots -` السطر `.\u002FRSASHA256\u002F38696 ; managed`، وأن يعرض `sudo rndc managed-keys status` مدخلًا `keyid: 38696` يليه `trusted since`. في Knot Resolver: استدعِ `trust_anchors.summary()` من وحدة التحكم. في dnsmasq: ابحث عن سطر `trust-anchor=.,38696,8,2,…` في الإعداد المحمّل.",{"title":78,"body":79},"تأكّد باستخدام delv","يتحقق `delv @127.0.0.1 com. SOA` من الإجابة بنفسه ويعرض `; fully validated` عندما تكتمل السلسلة. انتبه: يستخدم delv المرساة المضمّنة في ملفه التنفيذي، لا مرساة محللك. لذلك قد يفشل delv قديم وحده: حدّث الحزمة قبل أن تستنتج شيئًا عن المحلل.",{"type":81,"title":82,"headers":83,"rows":87},"comparison","أين توجد مرساة الثقة، محللًا تلو الآخر",[84,85,86],"المحلل","أين تبحث","تحديث المفتاح",[88,92,96,100,104,108,112],[89,90,91],"Unbound","التوجيه `auto-trust-anchor-file` (في Debian: `\u002Fvar\u002Flib\u002Funbound\u002Froot.key`)","RFC 5011 إذا كان الملف ومجلده قابلين للكتابة، وإلا `unbound-anchor`",[93,94,95],"BIND","`rndc secroots -` و`managed-keys.bind`؛ مرساة مدمجة مع `dnssec-validation auto`","RFC 5011 مع `auto` أو `initial-key` أو `initial-ds`؛ لا تحديث مع `static-key`",[97,98,99],"Knot Resolver","`trust_anchors.add_file()` في v5، و`dnssec\u002Ftrust-anchors-files` في v6","RFC 5011، إلا إذا عُرّف الملف للقراءة فقط",[101,102,103],"systemd-resolved","مرساة مدمجة في الملف التنفيذي؛ ملفات `*.positive` في `\u002Fetc\u002Fdnssec-trust-anchors.d\u002F`","لا تحديث عبر DNS: يلزم تحديث حزمة systemd",[105,106,107],"dnsmasq","أسطر `trust-anchor=` في الإعداد المحمّل","لا تحديث: سطر ثابت يُعدَّل يدويًا",[109,110,111],"Pi-hole v6","`\u002Fetc\u002Fpihole\u002Fdnsmasq.conf` الذي يولّده FTL","يعيد FTL كتابته ويُدرج المفتاحين 20326 و38696",[113,114,115],"delv (أداة)","مرساة مضمّنة في الملف التنفيذي","تحديث الحزمة التي توفّره",{"type":56,"title":117,"steps":118},"صحّح بحسب محللك",[119,122,125,128,131,134,137],{"title":120,"body":121},"Unbound: حدّث المرساة","حدّث النظام أولًا (`sudo apt update && sudo apt upgrade`). في Debian توفّر الحزمة `dns-root-data` الملف `\u002Fusr\u002Fshare\u002Fdns\u002Froot.key`، وينسخ سكربت تشغيل Unbound هذا الملف إلى `\u002Fvar\u002Flib\u002Funbound\u002Froot.key` عندما يكون أحدث؛ والإصدار `2024071801~deb12u1` المتاح لـ Debian 12 يتضمّن KSK-2024 بالفعل. ثم افرض الفحص بالأمر `sudo -u unbound unbound-anchor -a \u002Fvar\u002Flib\u002Funbound\u002Froot.key -v`، يليه `sudo systemctl restart unbound`. ويتضمّن المفتاح المدمج في `unbound-anchor` المفتاح KSK-2024 منذ Unbound 1.21.0.",{"title":123,"body":124},"Unbound: اجعل RFC 5011 ممكنًا","إذا ظلّ المفتاح غائبًا، فتحقّق من أن المستخدم `unbound` يستطيع الكتابة في الملف وفي مجلده أيضًا: فالتوثيق يشترط ذلك لإنشاء ملف مؤقت. ويكفي `ls -ld \u002Fvar\u002Flib\u002Funbound \u002Fvar\u002Flib\u002Funbound\u002Froot.key` لرؤية ذلك. والملف المركّب للقراءة فقط داخل حاوية يمنع التحديث التلقائي دون أي خطأ ظاهر لدى العميل.",{"title":126,"body":127},"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.",{"title":129,"body":130},"Knot Resolver: افحص ملف المرساة","حدّث الحزمة، ثم انظر كيف عُرّف ملف المرساة. إذا كان للقراءة فقط (الوسيط الثاني `true` في `trust_anchors.add_file()` في v5، أو `read-only: true` في v6)، فالمحلل لا يعدّله أبدًا: على حزمة توزيعتك أن تجلب المفتاح. وإلا فتحقّق من أن `kresd` يستطيع الكتابة في الملف. ويوضّح التوثيق أنه عند غياب الملف يحاول المحلل تهيئة مرساة الجذر بنفسه.",{"title":132,"body":133},"systemd-resolved: حدّث systemd","لا يحدّث systemd-resolved مرساته عبر DNS: وحده تحديث الحزمة يجلب المفتاح الجديد. وقد أُدرج في الشيفرة الأصلية، ولا سيما منذ systemd 256.12 و257.4، كما تتضمّنه حزمة `systemd-resolved` الحالية في Debian 12. افحص `\u002Fetc\u002Fdnssec-trust-anchors.d\u002F`: فملف `*.positive` يعرّف مفتاحًا للجذر يعطّل المرساة المدمجة. احذفه أو أضف إليه المفتاح 38696، ثم شغّل `sudo systemctl restart systemd-resolved` و`resolvectl flush-caches`.",{"title":135,"body":136},"dnsmasq: أضف السطر الثابت","لا يطبّق dnsmasq معيار RFC 5011: المرساة سطر ثابت. أضف `trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16` بجانب سطر المفتاح 20326، ثم أعد تشغيل الخدمة. في Debian 12 لا يحتوي الملف `\u002Fusr\u002Fshare\u002Fdnsmasq-base\u002Ftrust-anchors.conf` من الحزمة `dnsmasq-base` 2.90-4~deb12u2 إلا على المفتاح 20326، بينما يحتوي ملف Debian 13 على المفتاحين: تحقّق من الملف الذي يحمّله إعدادك فعلًا. أما Pi-hole v6 فيكتب السطرين بنفسه في `\u002Fetc\u002Fpihole\u002Fdnsmasq.conf` عند تفعيل التحقق في DNSSEC.",{"title":138,"body":139},"أتمِت الأمر للمرة القادمة","لا تتقادم المرساة إلا على خادم توقّف عن التحديث. فعّل التحديثات الأمنية التلقائية لحزم المحلل (راجع \u003Ca href=\"\u002Fblog\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu\">التحديثات التلقائية على Debian وUbuntu\u003C\u002Fa>)، وأضف إلى نظام المراقبة لديك فحصًا `dig +dnssec com. SOA @127.0.0.1` ينبّهك عند ظهور `SERVFAIL`. وإذا كان DNS المحلي لديك يمرّ عبر Pi-hole، فدليل \u003Ca href=\"\u002Fblog\u002Fpihole-v6-dns-bloquer-pubs-vps-2026\">Pi-hole v6 على VPS\u003C\u002Fa> يشرح كيف تضع Unbound قبله.",{"type":36,"title":141,"body":142},"بعد التصحيح: ما الذي يجب مراقبته","بعد عودة العلم `ad` إلى الإجابات، تستحق ثلاث نقاط التحقق.\n\nأولًا الصور واللقطات. الجهاز المستعاد من نسخة احتياطية قديمة يعود بملف المرساة الذي كان موجودًا حينها. وإذا كان هذا الملف لا يعرف إلا المفتاح 20326، فلا يستطيع RFC 5011 تداركه بعد الآن: فهو لا يقبل مفتاحًا جديدًا إلا إذا كانت مجموعة المفاتيح موقّعة بمفتاح موثوق مسبقًا، والجذر لم يعد موقّعًا بالمفتاح 20326. يجب حينها تحديث المرساة يدويًا كما سبق.\n\nثانيًا صور الحاويات. الصورة المبنية بمرساة ثابتة تحتفظ بها في كل إعادة نشر: أعد بناءها انطلاقًا من قاعدة محدّثة.\n\nوأخيرًا الإلغاء. في 11 يناير 2027 يُنتظر نشر KSK-2017 مع بِت الإلغاء. والمحلل الذي يتبع RFC 5011 سيعلّمه ملغًى: في ملف Unbound سينتقل سطر المفتاح 20326 إلى الحالة `REVOKED`. هذه هي الحالة المتوقعة، وليست عطلًا.",{"type":144,"title":145,"body":146},"tip","لا تعطّل التحقق لإسكات الخطأ","التحويل إلى `dnssec-validation no` أو `val-permissive-mode: yes` أو `DNSSEC=no` يُخفي الخطأ SERVFAIL، لكنه يزيل أيضًا كل حماية من الإجابات المزوّرة. صحّح المرساة ثم اختبر. ولا تلصق أبدًا مفتاحًا وجدته في منتدى: المصدر المرجعي هو `https:\u002F\u002Fdata.iana.org\u002Froot-anchors\u002Froot-anchors.xml`، ويُتحقق من توقيعه باستخدام `root-anchors.p7s` و`icannbundle.pem`، وتنشرهما IANA في المكان نفسه. وفيه تجد بصمة SHA-256 الخاصة بـ KSK-2024: `683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16`.",{"type":36,"title":148,"body":149},"استكشاف الأخطاء: الرسائل التي ستراها","الرسائل أدناه مأخوذة من الشيفرة المصدرية أو من توثيق البرامج المعنية. وهي تتيح التمييز بين مرساة قديمة ومشكلة في الشبكة أو ساعة منحرفة أو أداة تشخيص قديمة بدورها. في Unbound، ارفع أولًا مستوى تفاصيل السجلات بإضافة `val-log-level: 2` في القسم `server:` ثم أعد التشغيل: سيُسجَّل كل استعلام مرفوض مع سببه والخادم الذي قدّم البيانات الخاطئة.",{"type":40,"title":151,"items":152},"رسائل الخطأ وحلولها",[153,154,155,156,157,158],"**`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` وأعد قراءة الملف.",{"type":36,"title":160,"body":161},"الخلاصة","لا يطلب تغيير مفتاح الجذر شيئًا من مالكي النطاقات، ولا من الخوادم التي تتابع حزمها التحديثات. إنه يعاقب المحللات المجمّدة: صورة قديمة، أو ملف مرساة غير قابل للكتابة، أو مرساة ثابتة في dnsmasq أو BIND. وتكفي ثلاث خطوات للحسم: `dig +dnssec com. SOA` مقابل محللك، ثم الاستعلام نفسه مع `+cd`، ثم قراءة المرساة المحمّلة. واحتفظ في ذهنك بتاريخ 11 يناير 2027: سيظهر إلغاء KSK-2017 في ملفات المرساة لديك، وهذه حالة متوقعة. وعلى خادم تملك فيه صلاحيات root، يستغرق هذا الفحص عشر دقائق ويمكن جدولته مرة واحدة وإلى الأبد في نظام المراقبة.","محللك، ومرساة ثقتك","على خادم VPS من ServOrbit.com، تحصل على صلاحيات root: تختار نظامك، وتحدّث حزم المحلل متى قرّرت، وتقرأ سجلات التحقق بنفسك. وإذا فضّلت ألا تتولّى ذلك، فخيار إدارة VPS متاح.","اكتشف خوادم VPS","\u002Fvps-cloud",[167,183,200],{"id":168,"slug":169,"slugs":170,"title":174,"excerpt":175,"readTime":176,"views":18,"isPinned":19,"publishedAt":177,"updatedAt":178,"category":179,"categories":180,"featuredImage":30,"bgImage":31,"posterImage":182,"relatedSolution":30},416,"pihole-v6-dns-حجب-الإعلانات-vps-2026",{"fr":171,"en":172,"ar":169,"es":173},"pihole-v6-dns-bloquer-pubs-vps-2026","pihole-v6-dns-block-ads-vps-2026","pihole-v6-dns-bloquear-publicidad-vps-2026","‏Pi-hole v6 على VPS: حجب الإعلانات والمتتبعين على مستوى DNS","‏نشر Pi-hole v6 على خادم VPS باستخدام Docker Compose وتأمين محلل DNS الخاص بك وحجب الإعلانات والمتتبعين لجميع خدماتك المستضافة ذاتياً.",13,"2026-10-05T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[181],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fpihole-v6-dns-bloquer-pubs-vps-2026-poster.svg",{"id":184,"slug":185,"slugs":186,"title":190,"excerpt":191,"readTime":192,"views":193,"isPinned":19,"publishedAt":194,"updatedAt":195,"category":196,"categories":197,"featuredImage":30,"bgImage":31,"posterImage":199,"relatedSolution":30},382,"تحديثات-أمان-تلقائية-vps-debian-ubuntu",{"fr":187,"en":188,"ar":185,"es":189},"securite-vps-mises-a-jour-automatiques-debian-ubuntu","vps-automatic-security-updates-debian-ubuntu","actualizaciones-seguridad-vps-debian-ubuntu","تحديثات الأمان التلقائية على VPS بنظام Debian\u002FUbuntu","قم بتكوين unattended-upgrades على خوادم VPS الخاصة بك لأتمتة تصحيحات الأمان وتقليل سطح الهجوم عبر أسطول عملائك.",10,2,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[198],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg",{"id":201,"slug":202,"slugs":203,"title":207,"excerpt":208,"readTime":193,"views":18,"isPinned":19,"publishedAt":209,"updatedAt":210,"category":211,"categories":215,"featuredImage":30,"bgImage":31,"posterImage":217,"relatedSolution":30},447,"إضافة-أو-تعديل-سجل-dns-للنطاق",{"fr":204,"en":205,"ar":202,"es":206},"ajouter-enregistrement-dns-domaine","add-edit-dns-record-domain","anadir-registro-dns-dominio","إضافة أو تعديل سجل DNS: A وCNAME وMX وTXT","أنشئ سجل DNS أو عدّله أو احذفه (A وAAAA وCNAME وMX وTXT) في المنطقة المُدارة لنطاقك، مباشرةً من مساحة العميل.","2026-10-16T00:00:00+00:00","2026-10-16T01:57:35+00:00",{"id":17,"name":212,"slug":213,"color":214,"icon":213},"أدلة","guides","bg-emerald-500\u002F10 text-emerald-400",[216],{"id":17,"name":212,"slug":213,"color":214,"icon":213},"\u002Fblog\u002Fcovers\u002Fajouter-enregistrement-dns-domaine-poster.svg",1792763025007]