Informations :
Dates
- Publish : : Thursday 05 june 2025
- Modification : Tuesday 01 july 2025
- 439 views
Share :
Orientation pour NSEC3 dans DNSSec et automatisation pour les zones enfants délégués pour zone de confiance DNSSEC avec les RRSet CDS et CDNSKEY.
NdM : 2025/07/01 - Cette page est en cours de complément rédactionnel...
Exemple sur "un domaine de test" → zw3b.app
DNSViz Erreurs : https://dnsviz.net/d/zw3b.app/dnssec/[...] (Updated: 2025-06-05 00:24:47 UTC)
- NSEC3 proving non-existence of ay0p7.u4xid.zw3b.app/CNAME: An iterations count of 0 must be used in NSEC3 records to alleviate computational burdens. See RFC 9276, Sec. 3.1.
- NSEC3 proving non-existence of zw3b.app/CDNSKEY: An iterations count of 0 must be used in NSEC3 records to alleviate computational burdens. See RFC 9276, Sec. 3.1. (Un nombre d'itérations de 0 doit être utilisé dans les enregistrements NSEC3 afin d'alléger la charge de calcul.)
- NSEC3 proving non-existence of zw3b.app/CDS: An iterations count of 0 must be used in NSEC3 records to alleviate computational burdens. See RFC 9276, Sec. 3.1.
- NSEC3 proving non-existence of zw3b.app/CNAME: An iterations count of 0 must be used in NSEC3 records to alleviate computational burdens. See RFC 9276, Sec. 3.1.
Un nombre d'itérations de 0 doit être utilisé dans les enregistrements NSEC3 afin d'alléger la charge de calcul.
DNSViz Warnings : https://dnsviz.net/d/zw3b.app/dnssec/[...] (Updated: 2025-06-05 00:24:47 UTC)
- NSEC3 proving non-existence of ay0p7.u4xid.zw3b.app/CNAME: The salt value for an NSEC3 record should be empty. See RFC 9276, Sec. 3.1.
- NSEC3 proving non-existence of zw3b.app/CDNSKEY: The salt value for an NSEC3 record should be empty. See RFC 9276, Sec. 3.1.
- NSEC3 proving non-existence of zw3b.app/CDS: The salt value for an NSEC3 record should be empty. See RFC 9276, Sec. 3.1.
- NSEC3 proving non-existence of zw3b.app/CNAME: The salt value for an NSEC3 record should be empty. See RFC 9276, Sec. 3.1.
La valeur salt d'un enregistrement NSEC3 doit être vide.
DNSSEC Objectif :
Modifier les enregistrements de signature de délégation (DS) d'une zone enfant en fonction du signataire de délégation enfant (CDS) et de la clé de serveur de noms de domaine enfant (CDNSKEY) et créer les RR (Ressource Records) CDNSKEY / CDS.
Exemple Zone enfant « fr.lab3w.com » parent de « lab3w.com » : https://dnsviz.net/d/fr.lab3w.com/dnssec/ sur un alias DNAME de domaine qui plus est.
• ou mieux encore pour l'entité « srv.fr.lab3w.com » : https://dnsviz.net/d/srv.fr.lab3w.com/dnssec/
Commençons par lire cette page : RFC 8078 : Managing DS Records from the Parent via CDS/CDNSKEY sur le blog de Stéphane Bortzmeyer.
- RFC 4033 : DNS Security Introduction and Requirements
- RFC 4034 : Resource Records for the DNS Security Extensions
- RFC 5155 : DNSSEC Hashed Authenticated Denial of Existence
- RFC 6840 : Clarifications and Implementation Notes for DNS Security (DNSSEC)
- RFC 7344 : Automating DNSSEC Delegation Trust Maintenance
- RFC 8078 : Managing DS Records from the Parent via CDS/CDNSKEY
- RFC 8901 : Multi-Signer DNSSEC Models
- RFC 9276 : Guidance for NSEC3 Parameter Settings
- Le blog de Stéphane Bortzmeyer : RFC 4033: DNS Security Introduction and Requirements, RFC 4034: Resource Records for the DNS Security Extensions ; RFC 5155: DNSSEC Hashed Authenticated Denial of Existence, RFC 6840 : Clarifications and Implementation Notes for DNS Security (DNSSEC), RFC 7344: Automating DNSSEC Delegation Trust Maintenance et RFC 8078: Managing DS records from the Parent via CDS/CDNSKEY, RFC 8901 : Multi-Signer DNSSEC Models, RFC 9276: Guidance for NSEC3 Parameter Settings.
Commande dnssec-cds
Source : dnssec-keygen : https://www.ibm.com/docs/en/aix/7.3.0?topic=d-dnssec-cds-command
Modifier les enregistrements de signature de délégation (DS) d'une zone enfant en fonction du signataire de délégation enfant (CDS) et de la clé de serveur de noms de domaine enfant (CDNSKEY).
Description
La commande dnssec-cds modifie les enregistrements DS au niveau d'un point de délégation en fonction des enregistrements CDS ou CDNSKEY publiés dans la zone enfant. Si les enregistrements CDS et CDNSKEY sont tous deux présents dans la zone enfant, les enregistrements CDS sont prioritaires. Cela permet à une zone enfant d'informer sa zone parent des modifications à venir de ses clés de signature de clé (KSK Key Signing Key) en effectuant une interrogation périodique à l'aide de la commande dnssec-cds. La zone parent maintient les enregistrements DS à jour et active le déploiement automatique des KSK.
L'option -f child-file spécifie un fichier contenant les enregistrements CDS d'un fichier enfant et les enregistrements CDNSKEY, ainsi que la signature de l'enregistrement de ressource (RRSIG) et les enregistrements DNSKEY afin de garantir leur authentification. L'option -d path spécifie l'emplacement d'un fichier contenant les enregistrements DS actuels. Par exemple, le fichier peut être un fichier dsset généré par la commande dnssec-signzone, le résultat de la commande dnssec-dsfromkey ou celui de la commande dnssec-cds précédente.
La commande dnssec-cds utilise une logique de validation DNSSEC spécifique, spécifiée par la RFC 7344. Elle exige que les enregistrements CDS et CDNSKEY soient signés par une clé représentée dans les enregistrements DS existants. Cette exigence correspond généralement à la clé KSK (Key Signing Key) préexistante.
Pour se protéger contre les attaques par rejeu, les signatures des enregistrements enfants ne doivent pas être plus anciennes que lors d'une précédente exécution de la commande dnssec-cds. L'âge de la signature est obtenu à partir de la date de modification du fichier dsset ou à l'aide de l'option -s.
Pour protéger les enregistrements DS contre toute violation de la délégation, la commande dnssec-cds garantit que le jeu d'enregistrements de ressources DNSKEY (RRset) est vérifié par chaque algorithme de clé du nouveau RRset DS. Le même jeu de clés est couvert par chaque type de condensé DS.
Par défaut, les enregistrements DS de remplacement sont écrits sur la sortie standard à l'aide de l'option -i et le fichier d'entrée est écrasé. Les enregistrements DS de remplacement sont identiques aux enregistrements existants, lorsqu'aucune modification n'est nécessaire. La sortie peut être vide si les enregistrements CDS et CDNSKEY spécifient que la zone enfant doit être non sécurisée.
Attention : Ne supprimez pas les enregistrements DS en cas d'échec de la commandednssec-cds. Vous pouvez également utiliser la commandednssec-cds -upour écrire un scriptnsupdatesur la sortie standard. Les options-uet-ipermettent de maintenir un fichier dsset et de déclencher un scriptnsupdate.
Flags
-a algorithm
Spécifie un algorithme de résumé à utiliser lors de la conversion des enregistrements CDNSKEY en enregistrements DS. Cette option peut être réutilisée pour créer plusieurs enregistrements DS pour chaque enregistrement CDNSKEY. Si aucun enregistrement CDS n'utilise un type de résumé acceptable, dnssec-cds tente d'utiliser les enregistrements CDNSKEY à la place. En l'absence d'enregistrement CDNSKEY, une erreur est signalée.
La valeur de l'algorithme peut être SHA-1, SHA-256 ou SHA-384. Ces valeurs sont insensibles à la casse et le trait d'union peut être omis. Si aucun algorithme n'est spécifié, la valeur par défaut est SHA-256.
-c class
Spécifie la classe DNS des zones.
-D
Génère des enregistrements DS à partir des enregistrements CDNSKEY si les enregistrements CDS et CDNSKEY sont présents dans la zone enfant. Par défaut, les enregistrements CDS sont préférés.
-d dsset-file
Spécifie l'emplacement des enregistrements DS parents. Le chemin correspond au nom du fichier contenant les enregistrements DS. S'il s'agit d'un répertoire, la commande dnssec-cds recherche un fichier dsset pour le domaine dans ce répertoire.
Pour protéger les enregistrements DS contre les attaques par rejeu, les enregistrements enfants sont rejetés s'ils ont été signés avant la date de modification du fichier dsset. Vous pouvez ajuster la durée de validité à l'aide de l'option -s.
-f child-file
Spécifie le fichier contenant les enregistrements CDS du fichier enfant et les enregistrements CDNSKEY, ainsi que les enregistrements DNSKEY et les enregistrements RRSIG de couverture, afin qu'ils puissent être authentifiés.
-i extension
Met à jour le fichier dsset au lieu d'écrire les enregistrements DS sur la sortie standard.
Il ne doit pas y avoir d'espace entre -i et l'extension. Si l'extension n'est pas spécifiée, l'ancien fichier dsset est supprimé. Si une extension est spécifiée, une sauvegarde de l'ancien fichier dsset est enregistrée avec la valeur d'extension ajoutée à son nom de fichier.
Pour protéger les enregistrements DS contre les attaques par rejeu, l'heure de modification du fichier dsset est définie pour correspondre à l'heure de création de la signature des enregistrements enfants, si elle est postérieure à l'heure de modification actuelle du fichier.
-s start-time
Spécifie la date et l'heure après lesquelles les enregistrements RRSIG deviennent acceptables. Il peut s'agir d'une heure absolue ou relative. Une heure de début absolue est indiquée par un nombre au format AAAAMMJJHHMMSS. 20170827133700 correspond à 13:37:00 UTC (Temps universel coordonné) le 27 août 2017. Une heure relative au fichier dsset est indiquée par -N, ce qui signifie N secondes avant l'heure de modification du fichier. Une heure relative à l'heure actuelle est indiquée par now+N.
Si l'heure-début n'est pas spécifiée, l'heure de modification du fichier dsset est utilisée.
-T ttl
Spécifie une durée de vie (TTL) à utiliser pour les nouveaux enregistrements DS. Si la valeur n'est pas spécifiée, la valeur par défaut correspond à la durée de vie des anciens enregistrements DS. Si les anciens enregistrements DS n'avaient pas de durée de vie explicite, les nouveaux enregistrements DS n'en auront pas non plus.
-u
Écrit un script nsupdate sur la sortie standard au lieu d'afficher les nouveaux enregistrements DS. La sortie est vide si aucune modification n'est nécessaire.
Note : la durée de vie TTL des nouveaux enregistrements doit être spécifiée dans le fichier dsset d'origine à l'aide de l'indicateur-Tou de la commandensupdate ttl.
-V
Affiche les informations de version.
-v level
Définit le niveau de débogage. Le niveau 1 est destiné aux utilisateurs généraux. Les niveaux supérieurs sont destinés aux développeurs.
domain
Indique le nom du point de délégation ou de l'apex de la zone enfant.
État de sortie
La commande dnssec-cds renvoie un état de retour de 0 en cas de réussite, ou différent de zéro en cas d'erreur. En cas de succès, il n'est peut-être pas nécessaire de modifier les enregistrements DS.
Exemples
Avant d'exécuter la commande dnssec-signzone, assurez-vous que les délégations sont mises à jour en utilisant la commande dnssec-cds sur chaque fichier dsset.
Pour récupérer les enregistrements enfants requis par la commande dnssec-cds, exécutez la commande dig comme indiqué dans le script suivant. Même en cas d'échec, la commande dnssec-cds effectue toutes les vérifications nécessaires.
Script avec 6 lignes
001for f in dsset-*002do003d=${f#dsset-}004dig +dnssec +noall +answer $d DNSKEY $d CDNSKEY $d CDS |005dnssec-cds -i -f /dev/stdin -d $f $d006done
Pour conserver une délégation en utilisant la commande dnssec-cds avec la commande nsupdate lorsque la commande nommée signe automatiquement la zone parente, saisissez la commande suivante :
Script avec 3 lignes
001dig +dnssec +noall +answer $d DNSKEY $d CDNSKEY $d CDS |002dnssec-cds -u -i -f /dev/stdin -d $f $d |003nsupdate -l
Le fichier dsset ne permet pas au script de récupérer et de valider les enregistrements DS parents, et il maintient le délai de protection contre les attaques par rejeu.
Commande dnssec-keygen
Source : dnssec-keygen : https://www.ibm.com/docs/en/aix/7.3.0?topic=d-dnssec-keygen-command
Outil de génération de clés d'extensions de sécurité du système de noms de domaine (DNSSEC).
Description
La commande dnssec-keygen génère des clés pour DNSSEC (Secure DNS), telles que définies dans les RFC 2535 et RFC 4034. Elle peut également générer des clés à utiliser avec les signatures de transaction (TSIG) telles que définies dans la RFC 2845, ou la clé de transaction (TKEY) telle que définie dans la RFC 2930.
Début de la modification : Le nom de la clé est spécifié sur la ligne de commande. Pour les clés DNSSEC, il doit correspondre au nom de la zone pour laquelle la clé est générée.
Début de la modification : La commande dnssec-keymgr agit comme un wrapper autour de la commande dnssec-keygen, générant et mettant à jour les clés selon les besoins pour appliquer les politiques de sécurité définies, telles que la planification du renouvellement des clés. L'utilisation de dnssec-keymgr peut être préférable à l'utilisation directe de dnssec-keygen.
Commande dnssec-signzone
Source : dnssec-signzone : https://www.ibm.com/docs/en/aix/7.3.0?topic=d-dnssec-signzone-command
Outil de signature de zone d'extensions de sécurité du système de noms de domaine (DNSSEC).
Description
La commande dnssec-signzone signe une zone. Elle génère des enregistrements NSEC et RRSIG et produit une version signée de la zone. La présence ou l'absence d'un fichier de jeu de clés pour chaque zone enfant détermine l'état de sécurité des délégations de la zone signée (c'est-à-dire si les zones enfants sont sécurisées ou non).
Flags
-A
Indique que, lors de la génération d'une chaîne NSEC3, BIND 9 doit définir l'indicateur OPTOUT sur tous les enregistrements NSEC3 et ne doit pas générer d'enregistrements NSEC3 pour les délégations non sécurisées.
L'utilisation de cette option deux fois (c'est-à-dire -AA) désactive l'indicateur OPTOUT pour tous les enregistrements. Ceci est utile lors de l'utilisation de l'option -u pour modifier une chaîne NSEC3 sur laquelle l'indicateur OPTOUT a été défini.
-H iterations
Indique que, lors de la génération d'une chaîne NSEC3, BIND 9 doit utiliser le nombre d'itérations spécifié. La valeur par défaut est 10.
-g
Génère des enregistrements DS pour les zones enfants à partir des fichiers de jeux de clés. Cet indicateur supprime les enregistrements DS existants.
-N soa-serial-format
Spécifie le format du numéro de série SOA de la zone signée. L'argument soa-serial-format peut prendre l'une des valeurs suivantes :
keep
Ne modifie pas le numéro de série SOA. Il s'agit de la valeur par défaut.increment
Augmente le numéro de série SOA en utilisant l'arithmétique RFC 1982.unixtime
Définit le numéro de série SOA sur le nombre de secondes écoulées depuis epoch.date
Définit le numéro de série SOA sur la date du jour, au format AAAAMMJJNN, sauf si le numéro de série est déjà supérieur ou égal à cette valeur, auquel cas il est simplement incrémenté de un.
-t
Affiche les statistiques une fois l'opération terminée.
-u
Met à jour la chaîne NSEC/NSEC3 lors de la re-signature d'une zone précédemment signée. Cette option permet de basculer une zone signée avec NSEC vers NSEC3, ou de basculer une zone signée avec NSEC3 vers NSEC ou vers NSEC3 avec des paramètres différents. Sans cette option, la commande dnssec-signzone conserve la chaîne existante lors de la re-signature.
-x
Indique que BIND 9 doit signer uniquement les RRsets DNSKEY, CDNSKEY et CDS avec des clés de signature de clé, et omettre les signatures des clés de signature de zone. (Similaire à l'option second-dnskey-kskonly yes; zone option de la commande named.)
DNSSEC exemple :
Le tutoriel que j'ai suivis (il y a quelques temps) pour configurer du DNSSEC pour mes noms de domaines : How To Setup DNSSEC on an Authoritative BIND DNS Server.
En 4 commandes :
Script avec 33 lignes
001# -----002# Zone DNS SEC → algorithm 13 = ECDSA P256 SHA256003# ---004# Creation des keys005root@lb1.dns:~ # dnssec-keygen -a ECDSAP256SHA256 -n ZONE zw3b.app006root@lb1.dns:~ # dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE zw3b.app007 008# On colle les clefs dans la zone :009root@lb1.dns:~ # for key in `ls Kzw3b.app*.key`; do echo "$INCLUDE /etc/bind/keys/$key" >> /etc/bind/masters/zw3b.app.hosts; done;010 011# ---012# Avant d'exécuter la commande dnssec-signzone, assurez-vous que les délégations sont mises à jour en utilisant la commande dnssec-cds sur chaque fichier dsset.013# TODO : commande dnssec-cds014# ;-)015 016# ---017# On signe la zone (avec un sel aléatoire)018# root@lb1.dns:~ # dnssec-signzone -A -H 0 -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N INCREMENT -g -t -o zw3b.app -K /etc/bind/keys/ -t /etc/bind/masters/zw3b.app.hosts019# no salt (RFC 9276, Sec. 3.1.)020root@lb1.dns:~ # dnssec-signzone -A -H 0 -3 "" -N INCREMENT -g -t -o zw3b.app -K /etc/bind/keys/ -t /etc/bind/masters/zw3b.app.hosts021Verifying the zone using the following algorithms: ECDSAP256SHA256.022Zone fully signed:023Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked024ZSKs: 1 active, 0 stand-by, 0 revoked025/etc/bind/masters/zw3b.app.hosts.signed026Signatures generated: 37027Signatures retained: 0028Signatures dropped: 0029Signatures successfully verified: 0030Signatures unsuccessfully verified: 0031Signing time in seconds: 0.018032Signatures per second: 1978.080033Runtime in seconds: 0.110
Exemple pour la zone dans fichier "/etc/bind/named.conf.local" :
Script avec 10 lignes
001zone "zw3b.app" {002type master;003# file "/etc/bind/masters/zw3b.app.hosts";004file "/etc/bind/masters/zw3b.app.hosts.signed";005allow-transfer { key "ns1-ldap"; };006allow-update { key "update-dd-zone"; };007 008// notify master-only;009notify yes;010};
Note de Moi-même 2025/07/01 - Exemple sur "un domaine de test" → zw3b.app
J'ai ouvert un fichier "DNSViz-zw3b.app.txt" sur lequel j'ecris mes tests pour avoir mes RFC 5155: DNSSEC Hashed Authenticated Denial of Existence" valident ; par l'instant çà ressemble à cela (Updated: 2025-06-30 23:34:51 UTC).
Je vois 2 NSEC3PARAM sur mon domaine dans DNSViz -- j'ai dû louper un truc -- j'avais envoyé 10 intérations (sans le-H 0) puis selon la RFC il faut 0 itération ; déjà.
Je trouve çà sur le retour de la commande :dig ANY zw3b.app +dnssec @dns.google
Script avec 15 lignes
001# 20250604 -→ 20250704002zw3b.app. 0 IN NSEC3PARAM 1 0 10 0802585BC0273018003zw3b.app. 0 IN RRSIG NSEC3PARAM 13 2 0 20250704230901 20250604230901 47132 zw3b.app. 30rqfVvBZqv/iNlauVRJnizN/0oqZnL3Eeakebgf6SiRlw6n7xwMQnCR K7yqp65V4NZNu2vHLP6qSAjuJm18og==004 005# 20250605 -→ 20250705006zw3b.app. 0 IN NSEC3PARAM 1 0 0 8A42593B218B51D5007zw3b.app. 0 IN RRSIG NSEC3PARAM 13 2 0 20250705001251 20250605001251 47132 zw3b.app. CtplT/gELWrUaA0aQfC0h50ohb4JwK+DxV4Dzsig+OGLvjq/sR97DpkE qiZTwxKkua9zEhL8APlAqQ19W7W9pQ==008 009# 20250630 -→ 20250730010zw3b.app. 0 IN NSEC3PARAM 1 0 0 876435C96D1CDA22011zw3b.app. 0 IN RRSIG NSEC3PARAM 13 2 0 20250730214956 20250630214956 47132 zw3b.app. K/SXG41lZs2llrsrjAIzM3+FeKVEluBnXROHBMURg+Lz2oHO9aaBNbTn KDpjCT8D92xp2oqiI9VIXconcFfVAA==012 013# 20250701 -→ 20250731014zw3b.app. 0 IN NSEC3PARAM 1 0 0 -015zw3b.app. 0 IN RRSIG NSEC3PARAM 13 2 0 20250731013215 20250701013215 47132 zw3b.app. /xB5gI0JvErGqi2SRDImt2COxil4I4qv24Pnjufgtx1ea6vk02sAGyaA TWZ/bxVClxrDANogWxOT1s7oEDT2Xw==Ou avec la commande :
Script avec 15 lignes
001root@lb1.dns:~ # dig zw3b.app NSEC3PARAM +short0021 0 10 0802585BC0273018003 004root@lb1.dns:~ # dig zw3b.app NSEC3PARAM +short0051 0 0 8A42593B218B51D5006 007root@lb1.dns:~ # dig zw3b.app NSEC3PARAM +short0081 0 0 876435C96D1CDA22009 010# no salt ; no iteration011# dnssec-signzone -A -H 0 -3 "" -N INCREMENT -g -t -o zw3b.app -K /etc/bind/keys/ -t /etc/bind/masters/zw3b.app.hosts012# return :013root@lb1.dns:~ # dig zw3b.app NSEC3PARAM +short0141 0 0 -015
Je vous laisse lire la page du blog de monsieur Stéphane Bortzmeyer sur la RFC 5155 et ce RFC 9276, Sec. 3.1. - et cette page 9276.
Commande :nsec3hash; donc -- j'ai les bonnes valeurs "sans salt" et "sans itération" sur les .... etperl hash-nsec3.pl;-)Script avec 2 lignes
001Maintenant le domaine zw3b.app DNSSEC ressemble à cela sur DNSViz (Updated: 2025-07-01 02:33:39 UTC) ; c'est mieux.root@lb1.dns:~ # nsec3hash "" 1 0 zw3b.app.002VBGUBR18R59HLBMOR25UK556EUPPTK9H (salt=, hash=1, iterations=0)
À voir la suite...
Déjà, je souhaiterais supprimer l'enregistrement "NSEC3PARAM 1 0 10" et m'occuper enfin des champs CDNSKEY, CDS et CNAME ?
J'utilise nsupdate pour modifier ma zone ; sinon c'est l'enfer.
Un papier que j'ai écris : Configuration BIND9 Masters et Slaves.
Comment configurer le serveur DNS (Domain Names Services) de nom de domaines #BIND9 (Berkeley InterNet Domain) / NAMED avec son/ses #DNS secondaire(s) par #TSIG (Transaction SIGnature) - Mise à jour par nsupdate..
Je reviens vite ; je lis toutes les RFC et les explications de monsieur Bortzmeyer et je vous fais une doc ;-)
DNSSEC RRset DS : Delegation Signer
DS : Delegation Signer appelé Délégation du Signataire. Enregistrement DNS qui correspond à l’empreinte de la clé publique.
Script avec 34 lignes
001# Afficher les DS : Delegation Signer002root@gate:~ # dig +trace +noadditional DS zw3b.app. @dns.google003 004; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +trace +noadditional DS zw3b.app. @dns.google005;; global options: +cmd006. 87203 IN NS j.root-servers.net.007. 87203 IN NS i.root-servers.net.008. 87203 IN NS k.root-servers.net.009. 87203 IN NS g.root-servers.net.010. 87203 IN NS b.root-servers.net.011. 87203 IN NS d.root-servers.net.012. 87203 IN NS c.root-servers.net.013. 87203 IN NS m.root-servers.net.014. 87203 IN NS e.root-servers.net.015. 87203 IN NS f.root-servers.net.016. 87203 IN NS a.root-servers.net.017. 87203 IN NS l.root-servers.net.018. 87203 IN NS h.root-servers.net.019. 87203 IN RRSIG NS 8 0 518400 20250713170000 20250630160000 53148 . F5VWx/WSeDHePd6EPBrbWIgCMzUu7qWfQLVPYUKKkS20Q3RGvt+aT18U j+CLqBizgcDgpThikC8dDV/IHPTj3YANGn2ZN8lt4MdOHimpeRaitF9K yo/26vRDEYOWDHXRxqlxoMOPd/JsDpK3xkD4MPRBnFKK+Kl/U5WzrYIg E6XARCdJzJL4Y+Yoq6yLPRjTz0BCDknMK3mzakkfxvsTLC+EtU8vND3k gvj62lzxzcEna3G75RCWAFB79z+mkirwNorrUpLMqCkClSdbArvbh0be 3W80FYg6A/QJvc3tCGIdRTMhMUW5blqIYX5vO9go+k3NzgBG0ZkTw1lW ppm3/A==020;; Received 525 bytes from 2001:4860:4860::8888#53(dns.google) in 12 ms021 022app. 172800 IN NS ns-tld1.charlestonroadregistry.com.023app. 172800 IN NS ns-tld2.charlestonroadregistry.com.024app. 172800 IN NS ns-tld3.charlestonroadregistry.com.025app. 172800 IN NS ns-tld4.charlestonroadregistry.com.026app. 172800 IN NS ns-tld5.charlestonroadregistry.com.027app. 86400 IN DS 23684 8 2 3A5CC8A31E02C94ABA6461912FABB7E9F5E34957BB6114A55A864D96 AEC31836028app. 86400 IN RRSIG DS 8 1 86400 20250713170000 20250630160000 53148 . C04Re2JyyQxEi8C8eqBQmGG/rWHfGezgMQSLkH3kaDhLGYLtozUCXITR ZBrOQLfpRhtYpHfs0O4+k5snmDy8yLFKFGGjYA2Mv1Gj43KKJpjdfNOV gmy7eMUNH7xiOk2KdZxNSEZSZhumPHkvKePkVbqzFaOoqtB+GpNu1yNE n+8Y6CnODVy4+Mj3DGdBiWfmJUHGQOIWAHvWefwlCZz7FTm5vUOLWEwp YPOQTDeHPaA7xDjFLKVqy8nzbehqVd+rGgfmbHnPdaaOTkKtfEKlrWtM NbQ0/8Yd6E5pmxDMqVA6zaoqCuF7t8EfW3Q07yLhNNN1FzgJI8zDSstm B/Pg3A==029;; Received 728 bytes from 192.58.128.30#53(j.root-servers.net) in 12 ms030 031zw3b.app. 1800 IN DS 47132 13 2 4BEC9D1881C4E242EA6E2568A23902BAD941A23E184EC5EB98A9B731 4993C4FD032zw3b.app. 1800 IN DS 39028 13 2 576972AE44C607058D1A795BAF20A76942BEAF6691F7AD9752E746A8 0144A0AA033zw3b.app. 1800 IN RRSIG DS 8 2 1800 20250718144244 20250626144244 17620 app. VDe2VOrziqvgKDy7QKMlnV7AatUfVpsc36SmjM8wI/6Y7VHdzbNJFMXv MSefhYcWE3DEh7b+moExuOQyw8GFYx1kUiAUrM0jFy3XUoMx6JgJvVG1 uVFFormoJr9V84Znf7IxJhmQK6C4EAt9q+7NhntJzGgq8+5xJWctFkSn Yiw=034;; Received 329 bytes from 2001:4860:4805::69#53(ns-tld5.charlestonroadregistry.com) in 116 ms
Script avec 8 lignes
001# Afficher les DS : Delegation Signer002root@gate:~ # dig +trace +noadditional DS zw3b.app. @dns.google | grep DS003; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +trace +noadditional DS zw3b.app. @dns.google004app. 86400 IN DS 23684 8 2 3A5CC8A31E02C94ABA6461912FABB7E9F5E34957BB6114A55A864D96 AEC31836005app. 86400 IN RRSIG DS 8 1 86400 20250713170000 20250630160000 53148 . C04Re2JyyQxEi8C8eqBQmGG/rWHfGezgMQSLkH3kaDhLGYLtozUCXITR ZBrOQLfpRhtYpHfs0O4+k5snmDy8yLFKFGGjYA2Mv1Gj43KKJpjdfNOV gmy7eMUNH7xiOk2KdZxNSEZSZhumPHkvKePkVbqzFaOoqtB+GpNu1yNE n+8Y6CnODVy4+Mj3DGdBiWfmJUHGQOIWAHvWefwlCZz7FTm5vUOLWEwp YPOQTDeHPaA7xDjFLKVqy8nzbehqVd+rGgfmbHnPdaaOTkKtfEKlrWtM NbQ0/8Yd6E5pmxDMqVA6zaoqCuF7t8EfW3Q07yLhNNN1FzgJI8zDSstm B/Pg3A==006zw3b.app. 1800 IN DS 47132 13 2 4BEC9D1881C4E242EA6E2568A23902BAD941A23E184EC5EB98A9B731 4993C4FD007zw3b.app. 1800 IN DS 39028 13 2 576972AE44C607058D1A795BAF20A76942BEAF6691F7AD9752E746A8 0144A0AA008zw3b.app. 1800 IN RRSIG DS 8 2 1800 20250718144244 20250626144244 17620 app. VDe2VOrziqvgKDy7QKMlnV7AatUfVpsc36SmjM8wI/6Y7VHdzbNJFMXv MSefhYcWE3DEh7b+moExuOQyw8GFYx1kUiAUrM0jFy3XUoMx6JgJvVG1 uVFFormoJr9V84Znf7IxJhmQK6C4EAt9q+7NhntJzGgq8+5xJWctFkSn Yiw=
J'ajojute cette page : osso.nl > dnssec validation / authoritative server pour mémo, pour la suite du tuto.
Script avec 12 lignes
001root@lb1.dns:~ # delv -t A @dns.google zw3b.app. +rtrace002;; fetch: dns.google/A003;; fetch: dns.google/AAAA004;; fetch: zw3b.app/A005;; fetch: zw3b.app/DNSKEY006;; fetch: zw3b.app/DS007;; fetch: app/DNSKEY008;; fetch: app/DS009;; fetch: ./DNSKEY010; fully validated011zw3b.app. 3600 IN A 158.69.126.137012zw3b.app. 3600 IN RRSIG A 13 2 3600 20250731013215 20250701013215 47132 zw3b.app. 18gVm2FgyR3pQLAaUhAm1iSR3pT1w45OFjdlLTg7GLFFWOy0O+uO+BeA n82G6WY2lR2eaQQKliicXbG/JxCvRQ==
Script avec 21 lignes
001root@lb1.dns:~ # delv -t A @dns.google fail01.zw3b.app. +rtrace002;; fetch: dns.google/A003;; fetch: dns.google/AAAA004;; fetch: fail01.zw3b.app/A005;; fetch: zw3b.app/DNSKEY006;; fetch: zw3b.app/DS007;; fetch: app/DNSKEY008;; fetch: app/DS009;; fetch: ./DNSKEY010;; fetch: web.zw3b.app/A011; unsigned answer012fail01.zw3b.app. 60 IN CNAME web.zw3b.app.013fail01.zw3b.app. 60 IN RRSIG CNAME 13 2 3600 20250731013215 20250701013215 47132 zw3b.app. s8ifKq7R4ZSefU5h5Nym5+Vli+LDp/NF7xisOZBqUI9duCh+cisICvI0 A7OQbxiKWJcwtKklYd3nS5DYm9378g==014 015; fully validated016web.zw3b.app. 3600 IN A 57.128.171.43017web.zw3b.app. 3600 IN A 90.5.102.244018web.zw3b.app. 3600 IN A 135.125.133.51019web.zw3b.app. 3600 IN A 139.99.171.39020web.zw3b.app. 3600 IN A 158.69.126.137021web.zw3b.app. 3600 IN RRSIG A 13 3 3600 20250731013215 20250701013215 47132 zw3b.app. drR8858CWnD+leEN+YyJTi4nQhlyRUs6OQnDapBKK9CsDoiToQJeDECQ qlZ7vFZlmujHV4NTFrj2+fp+C2ZX9w==
Romain (LAB3W.ORJ).
À lire aussi sur la documentation de Bind9 : Creating a Custom DNSSEC Policy, Maintenance Tasks, The CDS and CDNSKEY Resource Records, Working with the Parent Zone (2), Alternate Ways of Signing a Zone, Semi-Automatic Signing, , Proof of Non-Existence (NSEC and NSEC3).
Cet article "VirtIT : Signer ses entrées DNS avec DNSSEC sous Bind9" explique la politique à prendre en compte sur le "Roll-Over" renouvellement (dnssec-policy) des clefs -- changer sa clef ZSK (Zone Signing Key) tous les 3 mois, et les KSK (Key Signing Key) tous les ans.
