Guidance for NSEC3 in DNSSec and Automation for Delegated Child Zones for DNSSEC Trust Zone with CDS and CDNSKEY

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...
NdM : 2025/07/15 - Cette page est en cours de complément rédactionnel…
NdM : 2025/07/17 - Cette page est en cours de complément rédactionnel…
NdM : 2025/07/18 - Cette page est en cours de complément rédactionnel…
NdM : 2025/07/21 - Cette page est en cours de complément rédactionnel…

Je ferais un papier plus propre quand j'aurais finit ;-)

                                          

Cette page concerne les RFC (Requests For Comments) suivant entre Mars 2005 et Août 2022 pour DNSSec et les améliorations du protocole en manière de sécurité et de rapidité avec divers optimisations technique et fonctionnelle.

• 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

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.

---

• 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 commande dnssec-cds. Vous pouvez également utiliser la commande dnssec-cds -u pour écrire un script nsupdate sur la sortie standard. Les options -u et -i permettent de maintenir un fichier dsset et de déclencher un script nsupdate.

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 -T ou de la commande nsupdate 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-*
002do
003    d=${f#dsset-}
004    dig +dnssec +noall +answer $d DNSKEY $d CDNSKEY $d CDS |
005    dnssec-cds -i -f /dev/stdin -d $f $d
006done

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 SHA256
003# ---
004# Creation des keys
005root@lb1.dns:~ # dnssec-keygen -a ECDSAP256SHA256 -n ZONE zw3b.app
006root@lb1.dns:~ # dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE zw3b.app
007
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-cds
014# ;-)
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.hosts
019# 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.hosts
021Verifying the zone using the following algorithms: ECDSAP256SHA256.
022Zone fully signed:
023Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
024                            ZSKs: 1 active, 0 stand-by, 0 revoked
025/etc/bind/masters/zw3b.app.hosts.signed
026Signatures generated:                       37
027Signatures retained:                         0
028Signatures dropped:                          0
029Signatures successfully verified:            0
030Signatures unsuccessfully verified:          0
031Signing time in seconds:                 0.018
032Signatures per second:                1978.080
033Runtime in seconds:                      0.110

Exemple pour la zone dans fichier "/etc/bind/named.conf.local" :

Script avec 10 lignes

001    zone "zw3b.app" {
002        type master;
003#        file "/etc/bind/masters/zw3b.app.hosts";
004        file "/etc/bind/masters/zw3b.app.hosts.signed";
005        allow-transfer {  key "ns1-ldap"; };
006        allow-update { key "update-dd-zone"; };
007
008//      notify master-only;
009        notify 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 -→ 20250704
002zw3b.app.               0       IN      NSEC3PARAM 1 0 10 0802585BC0273018
003zw3b.app.               0       IN      RRSIG   NSEC3PARAM 13 2 0 20250704230901 20250604230901 47132 zw3b.app. 30rqfVvBZqv/iNlauVRJnizN/0oqZnL3Eeakebgf6SiRlw6n7xwMQnCR K7yqp65V4NZNu2vHLP6qSAjuJm18og==
004
005# 20250605 -→ 20250705
006zw3b.app.               0       IN      NSEC3PARAM 1 0 0 8A42593B218B51D5
007zw3b.app.               0       IN      RRSIG   NSEC3PARAM 13 2 0 20250705001251 20250605001251 47132 zw3b.app. CtplT/gELWrUaA0aQfC0h50ohb4JwK+DxV4Dzsig+OGLvjq/sR97DpkE qiZTwxKkua9zEhL8APlAqQ19W7W9pQ==
008
009# 20250630 -→ 20250730
010zw3b.app.               0       IN      NSEC3PARAM 1 0 0 876435C96D1CDA22
011zw3b.app.               0       IN      RRSIG   NSEC3PARAM 13 2 0 20250730214956 20250630214956 47132 zw3b.app. K/SXG41lZs2llrsrjAIzM3+FeKVEluBnXROHBMURg+Lz2oHO9aaBNbTn KDpjCT8D92xp2oqiI9VIXconcFfVAA==
012
013# 20250701 -→ 20250731
014zw3b.app.               0       IN      NSEC3PARAM 1 0 0 -
015zw3b.app.               0       IN      RRSIG   NSEC3PARAM 13 2 0 20250731013215 20250701013215 47132 zw3b.app. /xB5gI0JvErGqi2SRDImt2COxil4I4qv24Pnjufgtx1ea6vk02sAGyaA TWZ/bxVClxrDANogWxOT1s7oEDT2Xw==

Retirer les numéros de lignes

Ou avec la commande :

Script avec 15 lignes

001root@lb1.dns:~ # dig zw3b.app NSEC3PARAM +short
0021 0 10 0802585BC0273018
003
004root@lb1.dns:~ # dig zw3b.app NSEC3PARAM +short
0051 0 0 8A42593B218B51D5
006
007root@lb1.dns:~ # dig zw3b.app NSEC3PARAM +short
0081 0 0 876435C96D1CDA22
009
010# no salt ; no iteration
011# dnssec-signzone -A -H 0 -3 "" -N INCREMENT -g -t -o zw3b.app -K /etc/bind/keys/ -t /etc/bind/masters/zw3b.app.hosts
012# return :
013root@lb1.dns:~ # dig zw3b.app NSEC3PARAM +short
0141 0 0 -
015

Retirer les numéros de lignes

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 .... et perl hash-nsec3.pl ;-)

Script avec 2 lignes

001root@lb1.dns:~ # nsec3hash "" 1 0 zw3b.app.
002VBGUBR18R59HLBMOR25UK556EUPPTK9H (salt=, hash=1, iterations=0)

Retirer les numéros de lignes

Maintenant le domaine zw3b.app DNSSEC ressemble à cela sur DNSViz (Updated: 2025-07-01 02:33:39 UTC) ; c'est mieux.

À 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 Signer
002root@gate:~ # dig +trace +noadditional DS zw3b.app. @dns.google
003
004; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +trace +noadditional DS zw3b.app. @dns.google
005;; global options: +cmd
006.                       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 ms
021
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 AEC31836
028app.                    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 ms
030
031zw3b.app.               1800    IN      DS      47132 13 2 4BEC9D1881C4E242EA6E2568A23902BAD941A23E184EC5EB98A9B731 4993C4FD
032zw3b.app.               1800    IN      DS      39028 13 2 576972AE44C607058D1A795BAF20A76942BEAF6691F7AD9752E746A8 0144A0AA
033zw3b.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 Signer
002root@gate:~ # dig +trace +noadditional DS zw3b.app. @dns.google | grep DS
003; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +trace +noadditional DS zw3b.app. @dns.google
004app.                    86400   IN      DS      23684 8 2 3A5CC8A31E02C94ABA6461912FABB7E9F5E34957BB6114A55A864D96 AEC31836
005app.                    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 4993C4FD
007zw3b.app.               1800    IN      DS      39028 13 2 576972AE44C607058D1A795BAF20A76942BEAF6691F7AD9752E746A8 0144A0AA
008zw3b.app.               1800    IN      RRSIG   DS 8 2 1800 20250718144244 20250626144244 17620 app. VDe2VOrziqvgKDy7QKMlnV7AatUfVpsc36SmjM8wI/6Y7VHdzbNJFMXv MSefhYcWE3DEh7b+moExuOQyw8GFYx1kUiAUrM0jFy3XUoMx6JgJvVG1 uVFFormoJr9V84Znf7IxJhmQK6C4EAt9q+7NhntJzGgq8+5xJWctFkSn Yiw=

J'ajoute 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. +rtrace
002;; fetch: dns.google/A
003;; fetch: dns.google/AAAA
004;; fetch: zw3b.app/A
005;; fetch: zw3b.app/DNSKEY
006;; fetch: zw3b.app/DS
007;; fetch: app/DNSKEY
008;; fetch: app/DS
009;; fetch: ./DNSKEY
010; fully validated
011zw3b.app.               3600    IN      A       158.69.126.137
012zw3b.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. +rtrace
002;; fetch: dns.google/A
003;; fetch: dns.google/AAAA
004;; fetch: fail01.zw3b.app/A
005;; fetch: zw3b.app/DNSKEY
006;; fetch: zw3b.app/DS
007;; fetch: app/DNSKEY
008;; fetch: app/DS
009;; fetch: ./DNSKEY
010;; fetch: web.zw3b.app/A
011; unsigned answer
012fail01.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 validated
016web.zw3b.app.           3600    IN      A       57.128.171.43
017web.zw3b.app.           3600    IN      A       90.5.102.244
018web.zw3b.app.           3600    IN      A       135.125.133.51
019web.zw3b.app.           3600    IN      A       139.99.171.39
020web.zw3b.app.           3600    IN      A       158.69.126.137
021web.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.

• Afnic.fr - Déployer DNSSEC, comment, quoi, où ? (Version 3 – Juin 2015)

---

Note de moi-même du 15 juillet 2025 - TODO !

Je link ces 2 impressions d'écran qui concerne ma sous-zone DNS, les zones enfant « fr.lab3w.fr », « fr.lab3w.com » et « *.fr.lab3w.fr », « *.fr.lab3w.com » que je n'ai pas encore déléguée DNSSEC.quement à ma zone parentale/autoritaire « lab3w.fr » :

Pour infos :

J'ai créé il y quelques temps un certificat Let's Encrypt (sans zone-enfant DNSSec), le certificat pour mes web serveurs « gate.fr.lab3w.com », « srv.fr.lab3w.com » et autres.

Let's Encrypt ne veut plus les valider, depuis que ce sont des zones enfants ; çà doit être lié, puisqu'elles sont gérées sur un autre serveur DNS qui est actuallement non valide DNSSSEC ;

Ce n'est que la zone (child-zone) que je gère sur mon server DNS chez moi, rien de grave pour le moment ;-)

---

En passant depuis quelques jours Let's Encrypt permet de créer des certificats sur des adresses IP.

Source Let's Encrypt : We've Issued Our First IP Address Certificate du 01/07/2025.

Note de moi-même du 17 juillet 2025.

J'ai supprimé la délégation DNS qui concerne ma sous-zone DNS, les zones enfant « fr.lab3w.fr », « fr.lab3w.com » et « *.fr.lab3w.fr », « *.fr.lab3w.com » que je n'ai pas encore déléguée DNSSEC.quement à ma zone parentale/autoritaire « lab3w.fr » pour les serveurs « gate.fr.lab3w.com », « srv.fr.lab3w.com » et autres :

Quelques minutes après j'obtient toujours un « SERVFAIL » ; j'attends que le TTL soit arrivé à échéance. Est-ce cela ; ou est-ce plus compliqué ;-)

OK normal dans la zone principale :

Script avec 11 lignes

001root@srv-fr.h2.ns2:~ $ nslookup srv.ca.lab3w.com dns.google
002Server:         dns.google
003Address:        2001:4860:4860::8844#53
004
005Non-authoritative answer:
006lab3w.com       dname = lab3w.fr.
007srv.ca.lab3w.com        canonical name = SRv.cA.lab3w.fr.
008Name:   SRv.cA.lab3w.fr
009Address: 158.69.126.137
010Name:   SRv.cA.lab3w.fr
011Address: 2607:5300:60:9389::1

Retirer les numéros de lignes

KO :

Script avec 9 lignes

001root@srv-fr.h2.ns2:~ $ nslookup srv.fr.lab3w.fr dns.google
002;; Got SERVFAIL reply from 2001:4860:4860::8888, trying next server
003;; Got SERVFAIL reply from 2001:4860:4860::8844, trying next server
004;; Got SERVFAIL reply from 8.8.8.8, trying next server
005;; Got SERVFAIL reply from 8.8.4.4
006Server:         dns.google
007Address:        8.8.4.4#53
008
009** server can't find srv.fr.lab3w.fr: SERVFAIL

Retirer les numéros de lignes

Script avec 18 lignes

001root@srv-fr.h2.ns2:~ $ dig ANY srv.fr.lab3w.fr @dns.google
002
003; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> ANY srv.fr.lab3w.fr @dns.google
004;; global options: +cmd
005;; Got answer:
006;; →>HEADER<← opcode: QUERY, status: SERVFAIL, id: 54681
007;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
008
009;; OPT PSEUDOSECTION:
010; EDNS: version: 0, flags:; udp: 512
011; EDE: 22 (No Reachable Authority): (At delegation fr.lab3w.fr for srv.fr.lab3w.fr/all)
012;; QUESTION SECTION:
013;srv.fr.lab3w.fr.               IN      ANY
014
015;; Query time: 243 msec
016;; SERVER: 2001:4860:4860::8844#53(dns.google) (TCP)
017;; WHEN: Thu Jul 17 15:34:57 CEST 2025
018;; MSG SIZE  rcvd: 99

Retirer les numéros de lignes

Script avec 18 lignes

001root@srv-fr.h2.ns2:~ $ dig ANY fr.lab3w.fr @dns.google
002
003; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> ANY fr.lab3w.fr @dns.google
004;; global options: +cmd
005;; Got answer:
006;; →>HEADER<← opcode: QUERY, status: SERVFAIL, id: 16219
007;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
008
009;; OPT PSEUDOSECTION:
010; EDNS: version: 0, flags:; udp: 512
011; EDE: 22 (No Reachable Authority): (At delegation fr.lab3w.fr for fr.lab3w.fr/all)
012;; QUESTION SECTION:
013;fr.lab3w.fr.                   IN      ANY
014
015;; Query time: 351 msec
016;; SERVER: 2001:4860:4860::8888#53(dns.google) (TCP)
017;; WHEN: Thu Jul 17 15:40:31 CEST 2025
018;; MSG SIZE  rcvd: 91

Retirer les numéros de lignes

Retour : EDE: 22 (No Reachable Authority): (At delegation fr.lab3w.fr for srv.fr.lab3w.fr/all)

---

Note du 18/07/2025 : La chaîne de confiance - TODO ;-)

24 heures après j'obtient toujours un « SERVFAIL ».

• Dig through SERVFAILs with EDE → Extended DNS error codes (cloudflare)

À priori ; tout est lié puisque je n'ai pas ma zone (child-zone) enfant signée. J'ai 2 solutions :

1. répondre avec les bonnes réponses (répondre avec la zone signée) - DNSkey, RRsig...
2. supprimer le Delegation Signer (DS) du parent et donc ; ne plus avoir de DNSSEC

Enregistrements signataires de délégation

Source Comment fonctionne le DNSSEC ? (cloudflare)

DNSSEC introduit un enregistrement Delegation Signer (DS) pour permettre la propagation de la confiance dans une zone parent à une zone enfant. Un opérateur de zone hache l'enregistrement DNSKEY contenant la KSK publique et le donne à la zone parent pour qu'elle le publie en tant qu'enregistrement DS.

• RRSIG : contient une signature cryptographique
• DNSKEY : contient une clé de signature publique
• DS : contient le hachage d'un enregistrement DNSKEY
• NSEC et NSEC3 : pour le déni d'existence explicite d'un enregistrement DNS
• CDNSKEY et CDS : pour une zone fille demandant des mises à jour d'un ou de plusieurs enregistrements DS dans la zone parent.

---

D'autres explications sur AWS Route 53 :

• Configuration de la signature DNSSEC dans Amazon Route 53
• Activation de la signature DNSSEC et établissement d'une chaîne d'approbation

;-)

Note de moi-même du 21 juillet 2025.

Je viens tomber sur ce retour de la commande dig (je ne sais pas que veut dire ces options) - que depuis la machine "dc2".

Script avec 18 lignes

001root@srv-fr.h2.dc2:~ $ dig fr.lab3w.fr. ANY @dns.google
002
003; <<>> DiG 9.11.5-P4-5.1+deb10u11-Debian <<>> fr.lab3w.fr. ANY @dns.google
004;; global options: +cmd
005;; Got answer:
006;; →>HEADER<← opcode: QUERY, status: SERVFAIL, id: 30832
007;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
008
009;; OPT PSEUDOSECTION:
010; EDNS: version: 0, flags:; udp: 512
011; OPT=15: 00 16 41 74 20 64 65 6c 65 67 61 74 69 6f 6e 20 66 72 2e 6c 61 62 33 77 2e 66 72 20 66 6f 72 20 66 72 2e 6c 61 62 33 77 2e 66 72 2f 61 6c 6c ("..At delegation fr.lab3w.fr for fr.lab3w.fr/all")
012;; QUESTION SECTION:
013;fr.lab3w.fr.                   IN      ANY
014
015;; Query time: 369 msec
016;; SERVER: 8.8.8.8#53(8.8.8.8)
017;; WHEN: lun. juil. 21 17:20:08 CEST 2025
018;; MSG SIZE  rcvd: 91

Retirer les numéros de lignes

Sinon depuis d'autres machines ; j'en suis au même point -- ou presque :

Script avec 18 lignes

001root@srv-fr.h1.ns1:~ $ dig fr.lab3w.fr. ANY @dns.google
002
003; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> fr.lab3w.fr. ANY @dns.google
004;; global options: +cmd
005;; Got answer:
006;; →>HEADER<← opcode: QUERY, status: SERVFAIL, id: 21716
007;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
008
009;; OPT PSEUDOSECTION:
010; EDNS: version: 0, flags:; udp: 512
011; EDE: 22 (No Reachable Authority): (At delegation fr.lab3w.fr for fr.lab3w.fr/all)
012;; QUESTION SECTION:
013;fr.lab3w.fr.                   IN      ANY
014
015;; Query time: 347 msec
016;; SERVER: 2001:4860:4860::8844#53(dns.google) (TCP)
017;; WHEN: Mon Jul 21 17:50:25 CEST 2025
018;; MSG SIZE  rcvd: 91

Retirer les numéros de lignes

---

Domains vu par DNSViz :

lab3w.fr (Updated: 2025-07-21 15:28:57 UTC) → 8 errors NSEC3 proving non-existence -- facile à corriger : itération à 0 et sel vide ; si j'ai bien compris.

Alias de domain → lab3w.com (Updated: 2025-07-21 15:28:54 UTC) → 8 errors NSEC3 proving non-existence -- facile à corriger : itération à 0 et sel vide ; si j'ai bien compris.

Child Zone → (mais je l'ai supprimé cette child-zone déléguée - qui ne fonctionne plus) fr.lab3w.com (Updated: 2025-07-21 15:33:35 UTC) → 0 error

Pour info au 23 avril 2025 ; j'ai fais un "mini-tuto" sur la délégation IPv6 (donc, reverse ; d'une adresse IPv6 à un nom) ; sans DNSSec, pour ma compréhension sur comment fonctionne la délégation de zone) si cela vous interesse.

→ Fibre - IP❤6 - Routers - Configuration Networks - Délégation rDNS (« Réponse #39 : 23 avril 2025 sur LaFibre.info »).

---

---

<< Configuration BIND9 Masters et Slaves

Comment-faire un réseau IPv6 - Firewall ICMPv6 >>

---

Load balancer d'IP over DNS for service HTTP

J'ajoute ce lien qui date un peu mais qui est très intéressant.

• Haute-disponibilité et Load-Balancing par Cascade de NS

---

---