- Modifié
Mettre en place un serveur DNS avec Bind9 et DNSSEC
Changelog :
Un changelog est disponible sur Github pour que vous puissiez suivre les évolutions du tutoriel facilement.
>> CHANGELOG <<
Installation de Bind
apt-get install bind9 dnsutilsLes fichiers de configuration sont placés dans le répertoire /etc/bind.
Voici la liste des fichiers principaux :
- named.conf.local : Configuration local du serveur DNS, on y déclare les zones associées au domaine.
- named.conf.options : Ce fichier contient l'ensemble des options de configuration du serveur DNS.
- named.conf.default-zones : Ce fichier contient des zones pré-définies
Configuration de bind
Dans ce tutoriel, nous allons détailler la configuration d'un serveur DNS primaire (votre serveur) et deux serveurs DNS secondaires (celui de votre registrar et celui de votre hébergeur par exemple) au cas où le primaire ne réponde plus aux requêtes DNS.
Attention : Dans la suite du tutoriel, n'oubliez pas de remplacer domain.tld par votre nom domaine
Liste des serveurs DNS :
Serveur primaire (votre serveur) :
ns1.domain.tld / xxx.xxx.xxx.xxx
Serveurs secondaires :
ns6.gandi.net / 217.70.177.40
ns.kimsufi.com / 213.186.33.199
Fichier de configuration principal :
# vim /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
# Activer DNSSEC
dnssec-enable yes;
dnssec-validation auto;
auth-nxdomain no; # RFC1035
listen-on { any; };
listen-on-v6 { any; };
# Autoriser les requêtes récursives locales uniquement
allow-recursion { 127.0.0.1; ::1; };
# Ne pas transférer les informations des zones aux DNS secondaires
allow-transfer { none; };
# Ne pas autoriser la mise à jour des zones maîtres
allow-update { none; };
version none;
hostname none;
server-id none;
};
Fichier de configuration local du serveur DNS, on va déclarer la zone associée au domaine.
# vim /etc/bind/named.conf.local
zone "domain.tld" IN {
# Zone de type maître
type master;
# Fichier de zone
file "/etc/bind/domain.tld/db.domain.tld";
# On autorise le transfert de la zone aux serveurs DNS secondaires
allow-transfer { 217.70.177.40; 213.186.33.199; 127.0.0.1; ::1; };
# On autorise tout le monde à envoyer des requêtes vers cette zone
allow-query { any; };
# Prévenir les serveurs DNS secondaires qu'un changement a été effectué dans la zone maître
notify yes;
};
La directive zone détermine la zone à gérer.
La directive type peut prendre deux valeurs, master ou slave. Le serveur primaire sera toujours de type master. Les serveurs secondaires seront quant à eux de type slave et iront récupérer les informations de la zone depuis le serveur primaire grâce à la directive allow-transfer.
Créer un nouveau répertoire qui contiendra les fichiers de configuration liés à votre domaine :
mkdir /etc/bind/domain.tldConfiguration du fichier de zone :
Cette partie du tutoriel est très importante, on va définir le fichier de zone principal de votre domaine et ajouter les enregistrements nécessaires au bon fonctionnement de votre nom de domaine.
/etc/bind/domain.tld/db.domain.tld
# vim /etc/bind/domain.tld/db.domain.tld
; ZONE : domain.tld
; ------------------------------------------------------------------
$TTL 7200
@ IN SOA ns1.domain.tld. hostmaster.domain.tld. (
2014102001 ; Serial
14400 ; Refresh
3600 ; Retry
1209600 ; Expire - 1 week
86400 ) ; Minimum
; NAMESERVERS
@ IN NS ns1.domain.tld.
@ IN NS ns6.gandi.net.
@ IN NS ns.kimsufi.com.
$TTL : (Time To Live) exprime la durée (en secondes) de validité des informations contenues dans votre fichier de zone. Une fois ce délai expiré, les autres serveurs DNS doivent vérifier à nouveau les enregistrements.
SOA : permet de définir les informations relatives à la zone. En l'occurrence le nom du serveur DNS primaire et l'adresse mail du contact technique (hostmaster.domain.tld. le symbole @ est remplace par un point). Cet enregistrement est composé de plusieurs champs :
Serial : est un entier non signé de 32 bits. C'est le numéro de série à incrémenter à chaque modification du fichier. Cela permet aux serveurs secondaires de savoir si une modification a été apportée au fichier de zone principal. Le serial est généralement formaté à partir de la date de modification de la zone, AAAAMMDDXX, par exemple pour le 10 octobre 2014 => 2014102001 (première modification), 2014102002 (deuxième modification), ... etc.
Refresh : définit la période de rafraîchissement des données.
Retry : si une erreur survient au cours du dernier rafraîchissement, celle-ci sera répétée au bout du délai Retry.
Expire : le serveur sera considéré comme non disponible au bout du délai Expire.
Negative cache TTL : définit la durée de vie d'une réponse NXDOMAIN de notre part.
Après c'est à vous de personnaliser ce fichier en fonction de vos besoins, voici un exemple :
; Enregistrements A/AAAA
@ IN A IPv4 de votre serveur
@ IN AAAA IPv6 de votre serveur
hostname IN A IPv4 de votre serveur
hostname IN AAAA IPv6 de votre serveur
ns1 IN A IPv4 de votre serveur
ns1 IN AAAA IPv6 de votre serveur
; Sous-domaines - Serveur web
www IN CNAME hostname
blog IN CNAME hostname
forum IN CNAME hostname
...
; Sous-domaines - Serveur mail
smtp IN CNAME hostname2
imap IN CNAME hostname2
pop IN CNAME hostname2
...
; Sous-domaines - Seedbox
plex IN CNAME hostname3
torrent IN CNAME hostname3
...
; Enregistrement MX (Mail Exchanger)
@ IN MX 10 mail.domain.tld.
; Enregistrement SFP, DKIM, ...etc
...
Modification du fichier resolv.conf
Ajouter la ligne suivante dans le fichier /etc/resolv.conf :
nameserver 127.0.0.1Vérification des fichiers de configuration :
Avant de démarrer le service, il faut vérifier la syntaxe des fichiers de configuration de Bind :
# named-checkconf -z
zone domain.tld/IN: loaded serial 2014102001
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
On va aussi vérifier la validité du fichier de zone :
# named-checkzone domain.tld /etc/bind/domain.tld/db.domain.tld
zone domain.tld/IN: loaded serial 2014102001
OK
On peut maintenant démarrer le service :
service bind9 startÀ chaque modification du fichier de zone, le serial doit être incrémenté et le serveur DNS être redémarré pour que les modifications soient prises en compte.
Déclaration des serveurs de nom
N'oubliez pas de déclarer les serveurs de nom associés à votre nom de domaine à partir de l'interface de votre registrar (OVH, gandi, godaddy...etc), par exemple chez gandi :
Mise en place du serveur DNS secondaire de votre hébergeur
Exemple chez Kimsufi/SYS :
OVH s'assure que vous êtes bien le propriétaire de la zone en vous demandant d'ajouter un enregistrement de type TXT :
# vim /etc/bind/domain.tld/db.domain.tld
ownercheck IN TXT "be236ffd"
N'oubliez pas d'incrémenter le sérial et de redémarrer Bind pour que la modification soit prise en compte. Attendez quelques secondes, le temps que l'information se propage (dans ce cas là, le temps de propagation est quasi instantané) au niveau des serveurs DNS d'OVH puis cliquer sur Confirmer.
Modification des Glues records
Quand un domaine est délégué à un serveur de nom qui appartient à ce sous-domaine (par exemple, dans notre cas il s'agit de ns1.domain.tld), il est nécessaire de fournir également l'adresse IP de ce serveur pour éviter les références circulaires.
Sécurisation du serveur DNS avec DNSSEC
DNSSEC permet de signer cryptographiquement chaque enregistrement présent au sein de votre fichier de zone afin de ne pas être vulnérable aux attaques MITM ou DNS cache poisoning (Empoisonnement du cache DNS).
Regardez cet article d'OVH pour comprendre le fonctionnement de DNSSEC simplement :
https://www.ovh.com/fr/domaines/service_dnssec.xml
Pour comprendre le mécanisme un peu plus en détail, vous pouvez lire la section suivante :
Comment ça marche ?
Je vous conseille vivement de lire cette section, j'explique brièvement le fonctionnement de DNSSEC, je pense que c'est important de comprendre le mécanisme avant de le configurer. Sinon vous pouvez aller directement à l'étape suivante.
Je vais prendre mon nom de domaine (meshup.net) pour l'exemple. Imaginez un serveur DNS qui n'est pas sécurisé avec DNSSEC, demandez lui ses serveurs de nom :
# dig +short NS meshup.net
ns1.meshup.net.
ns6.gandi.net.
ns.kimsufi.com.
En réponse, il vous retourne la liste des serveurs de nom contenue dans le fichier de zone. Avec un serveur sécurisé avec DNSSEC, il vous retourne en plus la signature des enregistrements NS :
# dig +short +dnssec NS meshup.net
ns1.meshup.net.
ns6.gandi.net.
ns.kimsufi.com.
NS 8 2 7200 20141114161733 20141015161733 55473 meshup.net. DRLeUM8H0X0x3/66QYGPR+ng0ySee7M4VrsdJYiAZFSzdZQDTlB13n0n HajqOBTvV
ZF/2M6X2QnU25sSQJxTbxKUKAbtWJUk40VtF9/QCpCMYz6K hVMo/0TNmMlSjOI61Ywro4+kl2TJEkqN/1XZEm2ucmSfnMv7FfXIzVWs w99zlAiK/6cOPGrf7ZeZE
baUioZjV0aJE8DqORS0wjFw2ZFKoc6XuzAL yB84ZgXyQRTbKK+T34ZwCAXZwtsXnL6UVs2g4Tah8TMEkePII1wXykJT TpEPSvQBqt8X6yiCyKTum9WexSgPkha+Y
i5xvb0RSclonWpMSbWqkz+P +FTUbw==
Dans une zone signée avec DNSSEC, chaque enregistrement (RRSET) est associé avec un autre enregistrement de type RRSIG contenant une signature générée avec la clé privée correspondante.
Afin de vérifier cryptographiquement que la signature est valide, le résolveur a besoin de la clé publique (DNSKEY) :
# dig +short DNSKEY meshup.net
256 3 8 AwEAAcWNbmDidZrzYTO+bmlAdr870/rI4PcHk3ECk/geisQ9Xaw3LlCZ
zOEGeyTMurOQac9gGUrKLxpMR6K8MJHK9pn4e91VWoulWKa1Ouf3+weL
t1gqUfhgeDy8ezhK3oeZ0cfWDbAdVJdCN8mQKRvoIkEF/+kpvc0/dzdv
V5pms+s5wOdZSrDakYHHvQ4889VBizceixR3+TAaKF2hycrk0Vx8yUCV
jW9RSZEOsKM4wiaqwhxtu9xGVJtw2jTXNQRL+2NaMyas3ZeSv8oNqE9p
AT+eqNpQO8VDHwSzcJpjZGEjz8aqyI1MR6ez+uHh1Kuhz39AVP/3d3uQ
nLCeecO/+cU=
257 3 8 AwEAAZTt+fZFx/qU1TTf3I6kTd8XmJXbP8VrOxlv7pZvwAlLtAeE98HD
8s/9TXls+hwmX/aSDVGWBJTPkbcSQF7ayoBynns8BvtXtf5s+5RMWNay
Hs40qMoyDkROBFOAFndNTViyaKJwFKsP+MGHzTRb1vtEOUlBcEvVR7Ed
Dm20uDbJ+TnfNy6Hoan0Inpj+AZD1yW6Mg8c4rKCaURyb5+J8wHQ+HAV
O0wQmOiPP1krTXWHh9VaB6piKT/kgWLtP7fmhazTGIakvBEm4na52Sta
t3luXbBMYOyJNGMhZEEqiV6sDI6e7yv4+SRqDtQCfXCcbpfZMrW8NDqb
/8P61/NAlnk=
Bon ok, maintenant le resolveur possède nos enregistrement NS, leurs signatures, la clé publique correspondante à la clé privée qui a été utilisée pour signer les enregistrements. Il peut maintenant vérifier leur validité sans soucis. Mais comment s'assurer de l'authenticité de la clé publique et de la signature ? Un attaquant peut très bien spoofer un enregistrement DNS puis modifier la clé publique et la signature en même temps. L'élement qui va nous permettre d'éviter ce genre de scénario s'appelle le FINGERPRINT, c'est une chaine de caractère qui permet d'identifier de manière unique la clé publique, elle est stockée dans la zone parent grâce à un enregistrement DS (Delegation Signer). Dans le cas de mon domaine (meshup.net), cet enregistrement se trouve dans la zone du domaine "net" :
dig +short DS meshup.net
KEYTAG Algorithme condensât (ou FINGERPRINT)
---------------------------------------------------------------------------------------
26329 8 2 97E570B2F73C8E31605B92496E02A6C4B680F8BF0C65C0530A735A757242FAE0Il faut bien avoir compris que cet enregistrement n'est pas dans notre fichier de zone, c'est primordial. Il sera toujours stocké dans la zone du domaine parent.
Oui mais comment peut-on s'assurer que cet enregistrement n'a pas lui aussi été compromit par un attaquant ?
Parce que la zone "net" possède aussi un enregistrement DNSKEY et a signé chacun de ses enregistrements avec une clé privée en mettant le résultat de la signature dans un champ RRSIG.
Ok très bien mais comment peut-on s'assurer de la validité de la clé publique (DNSKEY) et des signatures de la zone "net" ?
Parce que la zone root "." possède aussi un enregistrement DS contenant le fingerprint de la clé publique, ainsi qu'un enregistrement DNSKEY et RRSIG de la même manière que pour la zone "net".
Oui mais comment peut-on être sûr et certain que la zone root n'a pas été compromise elle aussi ?
Tous simplement parce que chaque serveur DNS possède la clé publique de la zone root (.) dans le fichier /etc/bind/bind.keys :
managed-keys {
# ROOT KEY: See https://data.iana.org/root-anchors/root-anchors.xml
# for current trust anchor information.
# NOTE: This key is activated by setting "dnssec-validation auto;"
# in named.conf.
. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
};
Vous pouvez retrouver cette clé sur le site de l'ISC (Internet Systems Consortium) ici : http://www.isc.org/downloads/bind/bind-keys/
Voici un petit schéma qui permet de mieux comprendre la hiérarchie de ce mécanisme :
Avant de mettre en place DNSSEC, vous devez vous assurer que votre registrar supporte ce mécanisme. A ma connaissance, OVH et Gandi prennent en charge DNSSEC relativement bien. Il faut aussi que la zone parent de votre domaine supporte DNSSEC, pour le vérifier, il suffit de taper cette commande :
dig +short DNSKEY fr
257 3 8 ...
dig +short DNSKEY eu
256 3 7 ...
dig +short DNSKEY com
256 3 7 ...
etc...Les types de clés
DNSSEC utilise deux types de clé :
- La clé de signature de la zone (Zone Signing Key - ZSK)
- La clé de signature des clés (Key Signing Keys - KSK)
Ces deux clés peuvent être visualisées avec une commande que l'on a utilisé tout à l'heure :
# dig +short DNSKEY meshup.net
# Clé de signature de la zone - ZSK
----------------------------------------------------------------
256 3 8 AwEAAcWNbmDidZrzYTO+bmlAdr870/rI4PcHk3ECk/geisQ9Xaw3LlCZ
zOEGeyTMurOQac9gGUrKLxpMR6K8MJHK9pn4e91VWoulWKa1Ouf3+weL
t1gqUfhgeDy8ezhK3oeZ0cfWDbAdVJdCN8mQKRvoIkEF/+kpvc0/dzdv
V5pms+s5wOdZSrDakYHHvQ4889VBizceixR3+TAaKF2hycrk0Vx8yUCV
jW9RSZEOsKM4wiaqwhxtu9xGVJtw2jTXNQRL+2NaMyas3ZeSv8oNqE9p
AT+eqNpQO8VDHwSzcJpjZGEjz8aqyI1MR6ez+uHh1Kuhz39AVP/3d3uQ
nLCeecO/+cU=
# Clé de signature des clés - KSK
----------------------------------------------------------------
257 3 8 AwEAAZTt+fZFx/qU1TTf3I6kTd8XmJXbP8VrOxlv7pZvwAlLtAeE98HD
8s/9TXls+hwmX/aSDVGWBJTPkbcSQF7ayoBynns8BvtXtf5s+5RMWNay
Hs40qMoyDkROBFOAFndNTViyaKJwFKsP+MGHzTRb1vtEOUlBcEvVR7Ed
Dm20uDbJ+TnfNy6Hoan0Inpj+AZD1yW6Mg8c4rKCaURyb5+J8wHQ+HAV
O0wQmOiPP1krTXWHh9VaB6piKT/kgWLtP7fmhazTGIakvBEm4na52Sta
t3luXbBMYOyJNGMhZEEqiV6sDI6e7yv4+SRqDtQCfXCcbpfZMrW8NDqb
/8P61/NAlnk=
Le type de la clé est indiqué grâce au premier nombre, les enregistrements commençants par 257 indiquent une clé KSK, 256 indique une clé ZSK. On signe la zone avec une clé ZSK puis on signe la ZSK avec la clé KSK. L'enregistrement DS contenu dans la zone parent correspond au fingerprint de la clé KSK.
Il est actuellement recommandé de changer la ZSK tous les 3 mois et la KSK tous les ans.
Configuration de DNSSEC avec Bind
Maintenant que vous avez compris le mécanisme, on va le mettre en place avec les outils fournit avec Bind9. Il faut dans un premier temps générer les clés avec dnssec-keygen. Mais le soucis, c'est que ça prend tu temps, énormement de temps car le système à besoin d'entropie pour pouvoir générer des nombres quasi-aléatoires.
Pour l'aider dans cette tâche, on va installer rng-tools (Hardware Random Generator) :
apt-get install rng-toolsEditer le fichier /etc/default/rng-tools et ajouter ces deux lignes :
HRNGDEVICE=/dev/urandom
RNGDOPTIONS="-W 80% -t 20"Puis on lance le service :
/etc/init.d/rng-tools startOn peut maintenant générer les clés très rapidement, déplacez-vous avant dans le répertoire /etc/bind/domain.tld.
Générer la clé KSK :
# dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE domain.tld
Generating key pair.......................................................................
..............+++ ..........................................................+++
Kdomain.tld.+008+62062
Dans notre cas, les clés commencent par Kdomain.tld.+008+62062, pour plus de clarté, on va les renommer :
mv Kdomain.tld.+008+62062.key Kdomain.tld.ksk.key
mv Kdomain.tld.+008+62062.private Kdomain.tld.ksk.private
Générer la clé ZSK :
# dnssec-keygen -a RSASHA256 -b 2048 -n ZONE domain.tld
Generating key pair.........................................................+++ .+++
Kdomain.tld.+008+32898
On renomme aussi les clés pour plus de clarté :
mv Kdomain.tld.+008+32898.key Kdomain.tld.zsk.key
mv Kdomain.tld.+008+32898.private Kdomain.tld.zsk.private
Vérifier les permissions sur les clé privées .private (chmod 600) :
# ls /etc/bind/domain.tld
-rw-r--r-- 1 root bind 603 Oct 20 14:45 Kdomain.tld.ksk.key
-rw-r--r-- 1 root bind 604 Oct 20 14:54 Kdomain.tld.zsk.key
-rw------- 1 root bind 1776 Oct 20 14:45 Kdomain.tld.ksk.private
-rw------- 1 root bind 1776 Oct 20 14:54 Kdomain.tld.zsk.private
Importation des clés dans le fichier de zone
Les fichiers .key contiennent les clés publiques qu'il faut inclure dans le fichier de zone. Pour cela, il faut utiliser la directive $INCLUDE en dessous du champ SOA :
@ IN SOA domain.tld. hostmaster.domain.tld. (
2014102003 ; Serial
7200 ; Refresh
1800 ; Retry
604800 ; Expire - 1 week
86400 ) ; Minimum
$INCLUDE "/etc/bind/domain.tld/Kdomain.tld.zsk.key" ;
$INCLUDE "/etc/bind/domain.tld/Kdomain.tld.ksk.key" ;
...
Il ne faut surtout pas oublier d'incrémenter le serial pour prendre en compte les modifications, c'est très important. Dans mon cas, j'ai mis 2014102003 car c'est la troisième modification que j'ai apporté à ma zone aujourd'hui.
Signature du fichier de zone
Pour signer un fichier de zone, il faut utiliser la commande dnssec-signzone comme ceci :
dnssec-signzone -eYYYYMMDDHHMMSS -t -g -k Kdomain.tld.ksk.key -o domain.tld db.domain.tld Kdomain.tld.zsk.key
-eYYYYMMDDHHMMSS : Date d'expiration de la zone (obligatoire, par défaut 30 jours)
-t : Affiche quelques statistiques lors de la signature de la zone
-g: Générer les enregistrements DS (Delegation Signer)
-k : Clé KSK
-o : La zone concernée (domain.tld)
{zonefile} : Le fichier de zone
et en dernier paramètre la clé de signature de la zone (ZSK)
Cette commande génére une zone entièrement signée nommée : db.domain.tld.signed
Modifier le nom du fichier de zone dans le fichier named.conf.local :
# vim /etc/bind/named.conf.local
zone "domain.tld" IN {
...
# Fichier de zone
file "/etc/bind/domain.tld/db.domain.tld.signed";
...
};
Et pour finir, relancer Bind :
service bind9 restartConfiguration de la zone parent
Il ne reste plus qu'à fournir le condensât (fingerprint) de notre clé KSK au registrar pour qu'il puisse la rajouter au registre du domaine parent. Chez gandi, c'est très simple. Il suffit d'accéder à l'interface de configuration de votre domaine puis de cliquer sur "Gérer DNSSEC".
Pour récupérer votre clé publique KSK, exécutez cette commande :
tail -n 1 Kdomain.tld.ksk.key
domain.tld. IN DNSKEY 257 3 8 AwEAAbulFobmhae+iYuGQJ7h0RZcVOZE/FL2IcDo6P2cAD0HZaUFPl0k[.........]ba5IEC9gnok=
Puis la donner à votre registrar :
Une fois validé, votre registrar se chargera de générer le condensât, et de le transmettre au registre. Il faut attendre quelques heures pour que les champs DS soient disponibles au niveau de la zone parent.
Exemple chez GoDaddy : (Merci à Solinvictus pour le screenshot)
head -n 1 /etc/bind/domain.tld/dsset-domain.tld.
domain.tld. IN DS 59704 8 1 EB6646E2A2F95A29895CDC3AE69BB8B62AD3B4D6
On renseigne en conséquence les champs chez correspondants :
Maintenir sa zone
Lors de la modification d'un enregistrement contenu au sein de votre fichier de zone, vous devez IMPERATIVEMENT :
- Incrémenter le numéro de série de l'enregistrement SOA
- Resigner votre zone avec la commande dnssec-signzone
- Redémarrer Bind
Attention à la validité de votre zone. Lors de sa signature, vous avez spécifié une date d'expiration, pensez toujours à resigner votre zone avant d'arriver à cette date d'expiration sinon votre domaine ne sera plus accessible car il sera considéré comme expiré par les autres serveurs DNS (ça m'est déjà arrivé 
).
Mettre en place une nouvelle clé ZSK (recommandé : tous les 3 mois)
Il suffit de suivre les étapes suivantes :
- Générer une nouvelle clé ZSK
- Inclure votre nouvelle clé dans votre fichier de zone
- Mettre à jour le numéro de série de l'enregistrement SOA
- Resigner votre zone
- Redémarrer Bind
Mettre en place une nouvelle clé KSK (recommandé : tous les ans)
Il suffit de suivre les étapes suivantes :
- Générer de nouvelles clés KSK et ZSK
- Inclure vos nouvelles clés dans votre fichier de zone
- Mettre à jour le numéro de série de l'enregistrement SOA
- Resigner votre zone
- Redémarrer Bind
- Reconfigurer la zone parent avec la nouvelle clé publique
Vérification du fonctionnement de DNSSEC
Vous pouvez utiliser ces deux outils pour vérifier la validité de votre domaine :
http://dnssec-debugger.verisignlabs.com/
http://dnsviz.net/
Si tous les voyants sont au vert c'est que tout est bon 
