[{"data":1,"prerenderedAt":218},["ShallowReactive",2],{"seo-verification":3,"blog-rollover-ksk-racine-dns-2026-dnssec-resolveurs-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-rollover-ksk-racine-dns-2026-dnssec-resolveurs-fr",{"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,"rollover-ksk-racine-dns-2026-dnssec-resolveurs",{"fr":10,"en":12,"ar":13,"es":14},"root-dnssec-ksk-rollover-2026-check-your-resolver","تغيير-مفتاح-الجذر-dnssec-2026-فحص-المحلل","rollover-ksk-raiz-dnssec-2026-revisar-resolver","Rollover KSK racine DNSSEC : vérifier votre résolveur","La racine DNS est signée par KSK-2024 (key tag 38696). Vérifiez l'ancre de confiance d'Unbound, BIND, Knot Resolver, systemd-resolved ou dnsmasq, et corrigez.",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,"Sécurité & Monitoring","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","Depuis le 11 octobre 2026, la zone racine du DNS est signée par une nouvelle clé, KSK-2024, de key tag 38696. Un résolveur validant qui ne connaît pas cette clé ne peut plus établir la chaîne de confiance DNSSEC : il répond SERVFAIL, y compris pour des noms qui fonctionnent ailleurs, et la panne ressemble à une coupure réseau. Ce guide montre comment vérifier en dix minutes l'ancre de confiance d'Unbound, BIND, Knot Resolver, systemd-resolved et dnsmasq, le prouver avec `dig` et `delv`, puis corriger.",[35,39,49,52,55,80,116,140,143,147,150,159],{"type":36,"title":37,"body":38},"h2","Ce qui a changé le 11 octobre 2026","DNSSEC repose sur une seule racine de confiance : la clé de signature de clé (KSK) de la zone racine. Chaque résolveur validant en garde une copie locale, appelée ancre de confiance, et vérifie tout le reste à partir d'elle. D'après l'IANA, KSK-2024 (key tag 38696) a été publiée dans la zone racine le 11 janvier 2025, puis a commencé à signer la racine le 11 octobre 2026, à la place de KSK-2017 (key tag 20326).\n\nLe 15 octobre 2026, l'ICANN a annoncé que le changement de clé s'était terminé comme prévu. L'annonce mentionne des signalements sur un nombre limité de systèmes et précise que l'ICANN évalue encore s'ils sont liés au changement : elle ne donne ni chiffre ni cause, et ce guide n'en avance pas. Le calendrier n'est pas clos : l'IANA prévoit la révocation de KSK-2017 le 11 janvier 2027, puis son retrait de la zone le 22 mars 2027.",{"type":40,"title":41,"items":42},"ul","Ce qu'il faut retenir",[43,44,45,46,47,48],"**La clé à chercher** — KSK-2024, key tag 38696, algorithme 8 (RSA\u002FSHA-256). L'ancienne, KSK-2017, porte le key tag 20326.","**Le symptôme** — un résolveur qui ne fait confiance qu'à 20326 ne peut plus valider la racine. Verisign et l'ICANN préviennent qu'il échoue alors à résoudre, que le nom demandé soit signé ou non.","**Le mécanisme normal** — la RFC 5011 permet à un résolveur d'adopter seul une nouvelle clé après l'avoir observée 30 jours, à condition qu'il tourne et puisse écrire son fichier d'ancre.","**Les cas à risque** — une image système ou un instantané plus ancien que la clé, un fichier d'ancre en lecture seule, une ancre statique dans dnsmasq ou dans BIND.","**Ce qui ne change pas** — l'enregistrement DS de votre domaine chez le registre : le changement concerne la clé de la racine, pas celle de votre zone.","**La suite du calendrier** — révocation de KSK-2017 prévue le 11 janvier 2027, retrait le 22 mars 2027. Un résolveur qui fait déjà confiance à 38696 valide la racine signée par cette clé.",{"type":36,"title":50,"body":51},"Propriétaire de domaine ou administrateur de serveur : qui doit agir","Deux rôles se confondent souvent dans les tickets. Le propriétaire d'un domaine signé publie un enregistrement DS chez son registre, qui désigne la clé de SA zone. Ce DS ne dépend pas de la clé de la racine : il n'y a rien à modifier pour ce changement, ni dans la zone de `votre-domaine.com`, ni chez votre bureau d'enregistrement. Si vous gérez seulement vos enregistrements (voir \u003Ca href=\"\u002Fblog\u002Fajouter-enregistrement-dns-domaine\">ajouter un enregistrement DNS\u003C\u002Fa>), vous n'êtes pas concerné.\n\nL'administrateur d'un serveur qui fait tourner un résolveur validant, lui, l'est. Unbound derrière une messagerie, BIND sur un serveur de supervision, Knot Resolver dans un conteneur, systemd-resolved avec DNSSEC activé, dnsmasq ou Pi-hole avec la validation cochée : chacun porte sa propre ancre. Sur un VPS dont vous avez l'accès root, cet administrateur, c'est vous. Un serveur qui transmet ses requêtes à un résolveur public sans valider lui-même dépend de l'ancre de ce résolveur, pas de la sienne.",{"type":36,"title":53,"body":54},"Prérequis du diagnostic","Prévoyez dix minutes et un accès root ou sudo au serveur. Deux outils suffisent : `dig` et `delv`, fournis sur Debian et Ubuntu par le paquet `bind9-dnsutils` (`sudo apt install bind9-dnsutils`), et sur AlmaLinux ou Rocky Linux par `bind-utils`. Aucune ressource particulière n'est nécessaire : les requêtes se comptent en kilooctets.\n\nNotez l'adresse d'écoute de votre résolveur, en général `127.0.0.1`, ou `127.0.0.53` pour systemd-resolved, et gardez l'adresse d'un résolveur public validant pour comparer, par exemple `9.9.9.9`. Les sorties décrites ci-dessous sont des exemples de forme, pas des mesures de votre serveur : seuls les champs nommés comptent. Les tests portent sur la racine et sur `com.`, deux zones signées : ils ne dépendent d'aucun domaine en particulier.",{"type":56,"title":57,"steps":58},"steps","Diagnostiquer votre résolveur en sept étapes",[59,62,65,68,71,74,77],{"title":60,"body":61},"Identifier le résolveur qui répond","`cat \u002Fetc\u002Fresolv.conf` donne l'adresse interrogée par le système, `resolvectl status` indique si systemd-resolved s'intercale, et `sudo ss -lunp 'sport = :53'` nomme le processus qui écoute sur le port 53 : `unbound`, `named`, `kresd`, `dnsmasq` ou `pihole-FTL`. C'est ce processus que vous allez examiner.",{"title":63,"body":64},"Interroger la racine avec dig +dnssec","Lancez `dig +dnssec . SOA @127.0.0.1`, puis `dig +dnssec com. SOA @127.0.0.1`. Regardez deux champs de l'en-tête : `status:` et `flags:`. Un `status: NOERROR` accompagné du drapeau `ad` signifie que la réponse a été validée. Un `status: SERVFAIL` sur la racine elle-même est le signe le plus net d'une ancre périmée.",{"title":66,"body":67},"Isoler la validation avec +cd","`dig +dnssec +cd com. SOA @127.0.0.1` demande au résolveur de répondre sans valider (checking disabled). Si cette requête revient en `NOERROR` alors que la précédente échoue en `SERVFAIL`, le réseau et les serveurs amont fonctionnent : c'est la validation DNSSEC qui bloque, donc l'ancre ou l'horloge.",{"title":69,"body":70},"Comparer avec un résolveur public validant","`dig +dnssec com. SOA @9.9.9.9` doit répondre `NOERROR` avec `ad`. Si le résolveur public valide et le vôtre non, le problème est local. Vérifiez au passage l'heure du serveur avec `timedatectl` : une horloge décalée fait elle aussi échouer la vérification des signatures, et produit le même SERVFAIL.",{"title":72,"body":73},"Voir quelle clé signe la racine","`dig +dnssec +multi . DNSKEY @9.9.9.9` affiche les clés publiées. Celles de flag `257` sont les KSK ; avec `+multi`, dig ajoute leur `key id` en commentaire. Dans la phase actuelle, KSK-2017 reste publiée, mais la signature (RRSIG) du jeu de clés porte le key tag 38696 : c'est cette clé que votre ancre doit connaître.",{"title":75,"body":76},"Lire l'ancre réellement chargée","Unbound : `sudo grep 'id = 38696' \u002Fvar\u002Flib\u002Funbound\u002Froot.key` (chemin Debian ; ailleurs, `unbound-checkconf -o auto-trust-anchor-file` donne le vôtre) doit renvoyer une ligne marquée `VALID`. BIND : `sudo rndc secroots -` doit lister `.\u002FRSASHA256\u002F38696 ; managed`, et `sudo rndc managed-keys status` une entrée `keyid: 38696` suivie de `trusted since`. Knot Resolver : appelez `trust_anchors.summary()` depuis sa console de contrôle. dnsmasq : cherchez une ligne `trust-anchor=.,38696,8,2,…` dans la configuration chargée.",{"title":78,"body":79},"Confirmer avec delv","`delv @127.0.0.1 com. SOA` valide lui-même la réponse et affiche `; fully validated` quand la chaîne est complète. Attention : delv utilise l'ancre compilée dans son propre binaire, pas celle de votre résolveur. Un delv ancien peut donc échouer seul : mettez à jour le paquet avant d'en tirer une conclusion sur le résolveur.",{"type":81,"title":82,"headers":83,"rows":87},"comparison","Où vit l'ancre de confiance, résolveur par résolveur",[84,85,86],"Résolveur","Où regarder","Mise à jour de la clé",[88,92,96,100,104,108,112],[89,90,91],"Unbound","Directive `auto-trust-anchor-file` (Debian : `\u002Fvar\u002Flib\u002Funbound\u002Froot.key`)","RFC 5011 si le fichier et son répertoire sont inscriptibles, sinon `unbound-anchor`",[93,94,95],"BIND","`rndc secroots -` et `managed-keys.bind` ; ancre intégrée avec `dnssec-validation auto`","RFC 5011 avec `auto`, `initial-key` ou `initial-ds` ; aucune avec `static-key`",[97,98,99],"Knot Resolver","`trust_anchors.add_file()` en v5, `dnssec\u002Ftrust-anchors-files` en v6","RFC 5011, sauf si le fichier est déclaré en lecture seule",[101,102,103],"systemd-resolved","Ancre intégrée au binaire ; fichiers `*.positive` de `\u002Fetc\u002Fdnssec-trust-anchors.d\u002F`","Aucune par le DNS : il faut un paquet systemd à jour",[105,106,107],"dnsmasq","Lignes `trust-anchor=` de la configuration chargée","Aucune : ligne statique à éditer à la main",[109,110,111],"Pi-hole v6","`\u002Fetc\u002Fpihole\u002Fdnsmasq.conf`, généré par FTL","Réécrit par FTL, qui inscrit les clés 20326 et 38696",[113,114,115],"delv (outil)","Ancre compilée dans le binaire","Mise à jour du paquet qui le fournit",{"type":56,"title":117,"steps":118},"Corriger selon votre résolveur",[119,122,125,128,131,134,137],{"title":120,"body":121},"Unbound : rafraîchir l'ancre","Mettez d'abord le système à jour (`sudo apt update && sudo apt upgrade`). Sur Debian, le paquet `dns-root-data` fournit `\u002Fusr\u002Fshare\u002Fdns\u002Froot.key`, et le script de démarrage d'Unbound recopie ce fichier vers `\u002Fvar\u002Flib\u002Funbound\u002Froot.key` lorsqu'il est plus récent ; la version `2024071801~deb12u1` livrée pour Debian 12 contient déjà KSK-2024. Forcez ensuite la vérification avec `sudo -u unbound unbound-anchor -a \u002Fvar\u002Flib\u002Funbound\u002Froot.key -v`, puis `sudo systemctl restart unbound`. La clé intégrée à `unbound-anchor` inclut KSK-2024 depuis Unbound 1.21.0.",{"title":123,"body":124},"Unbound : rendre la RFC 5011 possible","Si la clé manque encore, vérifiez que l'utilisateur `unbound` peut écrire le fichier ET son répertoire : la documentation l'exige pour créer un fichier temporaire. `ls -ld \u002Fvar\u002Flib\u002Funbound \u002Fvar\u002Flib\u002Funbound\u002Froot.key` suffit à le voir. Un fichier monté en lecture seule dans un conteneur bloque la mise à jour automatique sans erreur visible côté client.",{"title":126,"body":127},"BIND : auto ou ancre déclarée","Avec `dnssec-validation auto;`, BIND part de l'ancre fournie avec le logiciel et la tient à jour par RFC 5011 dans `managed-keys.bind`. Mettez à jour le paquet, vérifiez que `managed-keys-directory` est inscriptible par `named`, puis lancez `sudo rndc managed-keys refresh`. Avec `dnssec-validation yes;` et une ancre déclarée à la main, ajoutez dans le bloc `trust-anchors` la ligne `. initial-ds 38696 8 2 \"683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16\";` et retirez toute ancre `static-key` qui ne connaît que 20326.",{"title":129,"body":130},"Knot Resolver : vérifier le fichier d'ancre","Mettez à jour le paquet, puis regardez comment le fichier d'ancre est déclaré. En lecture seule (second argument `true` de `trust_anchors.add_file()` en v5, `read-only: true` en v6), le résolveur ne le modifie jamais : c'est le paquet de votre distribution qui doit apporter la clé. Sinon, vérifiez que `kresd` peut écrire le fichier. La documentation précise qu'en l'absence de fichier, le résolveur tente d'amorcer lui-même l'ancre de la racine.",{"title":132,"body":133},"systemd-resolved : mettre à jour systemd","systemd-resolved ne met pas à jour son ancre par le DNS : seule une mise à jour du paquet apporte la nouvelle clé. Le code amont l'intègre notamment depuis systemd 256.12 et 257.4, et le paquet `systemd-resolved` actuel de Debian 12 la contient aussi. Vérifiez `\u002Fetc\u002Fdnssec-trust-anchors.d\u002F` : un fichier `*.positive` qui déclare une clé racine désactive l'ancre intégrée. Retirez-le ou ajoutez-y la clé 38696, puis `sudo systemctl restart systemd-resolved` et `resolvectl flush-caches`.",{"title":135,"body":136},"dnsmasq : ajouter la ligne statique","dnsmasq n'applique pas la RFC 5011 : l'ancre est une ligne fixe. Ajoutez `trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16` à côté de la ligne 20326, puis redémarrez le service. Sur Debian 12, le fichier `\u002Fusr\u002Fshare\u002Fdnsmasq-base\u002Ftrust-anchors.conf` du paquet `dnsmasq-base` 2.90-4~deb12u2 ne contient que la clé 20326, alors que celui de Debian 13 contient les deux : vérifiez quel fichier votre configuration charge réellement. Pi-hole v6 écrit lui-même les deux lignes dans `\u002Fetc\u002Fpihole\u002Fdnsmasq.conf` quand la validation DNSSEC est activée.",{"title":138,"body":139},"Automatiser pour la prochaine fois","Une ancre ne se périme que sur un serveur qui ne se met plus à jour. Activez les mises à jour de sécurité automatiques des paquets de résolveur (voir \u003Ca href=\"\u002Fblog\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu\">mises à jour automatiques sur Debian et Ubuntu\u003C\u002Fa>) et ajoutez à votre supervision une sonde `dig +dnssec com. SOA @127.0.0.1` qui alerte sur `SERVFAIL`. Si votre DNS local passe par Pi-hole, le guide \u003Ca href=\"\u002Fblog\u002Fpihole-v6-dns-bloquer-pubs-vps-2026\">Pi-hole v6 sur VPS\u003C\u002Fa> montre comment placer Unbound en amont.",{"type":36,"title":141,"body":142},"Après la correction : ce qu'il faut surveiller","Une fois le drapeau `ad` revenu dans les réponses, trois points méritent une vérification.\n\nLes images et les instantanés d'abord. Une machine restaurée à partir d'une sauvegarde ancienne repart avec le fichier d'ancre de l'époque. Si ce fichier ne connaît que 20326, la RFC 5011 ne peut plus la rattraper : elle n'accepte une nouvelle clé que si le jeu de clés est signé par une clé déjà approuvée, et la racine n'est plus signée par 20326. Il faut alors rafraîchir l'ancre à la main, comme ci-dessus.\n\nLes images de conteneurs ensuite. Une image construite avec une ancre statique la garde à chaque redéploiement : reconstruisez-la à partir d'une base à jour.\n\nLa révocation enfin. Le 11 janvier 2027, KSK-2017 doit être publiée avec le bit de révocation. Un résolveur qui suit la RFC 5011 la marquera comme révoquée : dans le fichier d'Unbound, la ligne 20326 passera à l'état `REVOKED`. C'est l'état attendu, pas une panne.",{"type":144,"title":145,"body":146},"tip","Ne coupez pas la validation pour faire taire l'erreur","Passer à `dnssec-validation no`, `val-permissive-mode: yes` ou `DNSSEC=no` fait disparaître le SERVFAIL, mais retire aussi toute protection contre les réponses falsifiées. Corrigez l'ancre, puis testez. Ne collez jamais une clé trouvée sur un forum : la source qui fait foi est `https:\u002F\u002Fdata.iana.org\u002Froot-anchors\u002Froot-anchors.xml`, dont la signature se vérifie avec `root-anchors.p7s` et `icannbundle.pem`, publiés au même endroit par l'IANA. Le condensé SHA-256 de KSK-2024 y figure : `683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16`.",{"type":36,"title":148,"body":149},"Dépannage : les messages que vous verrez","Les messages ci-dessous sont repris du code source ou de la documentation des logiciels concernés. Ils permettent de distinguer une ancre périmée d'un problème réseau, d'une horloge décalée ou d'un outil de diagnostic lui-même trop ancien. Pour Unbound, augmentez d'abord la précision des journaux avec `val-log-level: 2` dans la section `server:`, puis redémarrez : chaque requête refusée sera journalisée avec sa raison et le serveur qui a fourni la donnée fautive.",{"type":40,"title":151,"items":152},"Messages d'erreur et remèdes",[153,154,155,156,157,158],"**`failed to prime trust anchor -- DNSKEY rrset is not secure`** (journal d'Unbound, suivi de `. DNSKEY IN`) — Unbound a obtenu les clés de la racine mais n'a pas pu les valider avec son ancre : ancre périmée ou horloge fausse. Rafraîchissez `root.key`.","**`failed to prime trust anchor -- could not fetch DNSKEY rrset`** — Unbound n'obtient même pas les clés de la racine : réseau, pare-feu ou fragmentation UDP, pas l'ancre. Testez `dig +dnssec . DNSKEY` vers le serveur amont.","**`status: SERVFAIL` avec `+dnssec`, `NOERROR` avec `+cd`** — signature d'un échec de validation. Avec `ede: yes` dans Unbound, le client reçoit en plus un code d'erreur étendu (RFC 8914).","**`resolution failed: broken trust chain`** ou **`no valid RRSIG`** (delv) — delv n'a pas pu remonter jusqu'à une ancre valide. Vérifiez d'abord que delv lui-même est à jour.","**`; initializing managed`** dans `rndc secroots -` — BIND connaît la clé mais ne l'a jamais confirmée par une requête de rafraîchissement. Lancez `rndc managed-keys refresh` et vérifiez les droits sur `managed-keys-directory`.","**`unbound-anchor` sort avec le code 0 sans rien changer** — selon sa page de manuel, 0 signifie aussi bien « aucune mise à jour nécessaire » qu'« erreur ». Relancez avec `-v` et relisez le fichier.",{"type":36,"title":160,"body":161},"En résumé","Le changement de clé de la racine ne demande rien aux propriétaires de domaines, ni aux serveurs dont les paquets suivent les mises à jour. Il pénalise les résolveurs figés : image ancienne, fichier d'ancre non inscriptible, ancre statique dans dnsmasq ou BIND. Trois gestes suffisent à trancher : `dig +dnssec com. SOA` contre votre résolveur, la même requête avec `+cd`, puis la lecture de l'ancre chargée. Gardez la date du 11 janvier 2027 en tête : la révocation de KSK-2017 apparaîtra dans vos fichiers d'ancre, et c'est un état attendu. Sur un serveur dont vous avez l'accès root, ce contrôle prend dix minutes et se planifie une fois pour toutes dans votre supervision.","Votre résolveur, votre ancre de confiance","Sur un VPS ServOrbit.com, vous avez l'accès root : vous choisissez votre système, vous mettez à jour vos paquets de résolveur quand vous le décidez et vous lisez vous-même les journaux de validation. Si vous préférez ne pas tenir ce poste, l'option d'administration VPS existe.","Découvrir les 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-bloquer-pubs-vps-2026",{"fr":169,"en":171,"ar":172,"es":173},"pihole-v6-dns-block-ads-vps-2026","pihole-v6-dns-حجب-الإعلانات-vps-2026","pihole-v6-dns-bloquear-publicidad-vps-2026","Pi-hole v6 sur VPS : bloquer pubs et trackers au niveau DNS","Déployez Pi-hole v6 sur VPS avec Docker Compose, sécurisez votre résolveur DNS et bloquez publicités et trackers pour tous vos services self-hosted.",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,"securite-vps-mises-a-jour-automatiques-debian-ubuntu",{"fr":185,"en":187,"ar":188,"es":189},"vps-automatic-security-updates-debian-ubuntu","تحديثات-أمان-تلقائية-vps-debian-ubuntu","actualizaciones-seguridad-vps-debian-ubuntu","Mises à jour de sécurité automatiques sur VPS Debian\u002FUbuntu","Configurez unattended-upgrades sur vos VPS Debian\u002FUbuntu pour automatiser les patches de sécurité et réduire la surface d'attaque de votre parc client.",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,"ajouter-enregistrement-dns-domaine",{"fr":202,"en":204,"ar":205,"es":206},"add-edit-dns-record-domain","إضافة-أو-تعديل-سجل-dns-للنطاق","anadir-registro-dns-dominio","Ajouter ou modifier un enregistrement DNS (A, CNAME, MX, TXT)","Créez, modifiez ou supprimez un enregistrement DNS (A, AAAA, CNAME, MX, TXT) dans la zone managée de votre domaine, depuis l'espace client.","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","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",1792763140487]