cd / ;
apropos ;
find * ;
Le DNS (Domain Name System), c'est ce qui vous permet de reconnaître les noms de machines sur Internet. Ce sont les panneaux indicateurs et les annuaires téléphoniques du net.
C'est aussi ce qui indique où doit être envoyé le courrier, ainsi que plein d'autres détails techniques barbants 🧔🏽 dont la plupart des gens n'ont pas idée mais qui contribuent à la robustesse du réseau.
Ce système repose d'abord sur l'idée de zone. On commence par la zone racine, représentée par un point à l'extrémité d'une adresse. Cette zone racine contient les adresses des serveurs de noms autoritaires des tld (.fr, .de, .dk, .ph, .com, .net, .org etc). Chaque TLD constitue lui-même une zone contenant les adresses des serveurs de noms autoritaires pour les niveaux suivants.
.
|
|
+-------+-------+---+--+-------+-------+
| | | | | |
v v v v v v
.fr .com .tld .xyz .org .net
|
+-------------+--------------+
| | |
v v v
site.tld chezmoi.tld autre.tld
|
+------------------+
| |
v v
webmail.chezmoi.tld wiki.chezmoi.tld
Ainsi, pour peu que l'on connaisse les adresses des serveurs de la zone racine (aussi appelés serveurs racines, ou serveurs root), on peut normalement connaître n'importe quelle adresse dans le système de noms Internet : il suffit de commencer à la racine et parcourir la chaîne, zone après zone.
Cette action de parcourir la zone s'appelle la résolution (de noms). Les serveurs qui effectuent cette recherche sont dits "résolveurs". Les serveurs qui portent l'information relative à chaque zone sont appelés "autoritaires".
Lorsqu'un résolveur a récupéré l'adresse d'une machine, d'un site web ou autre, ce serveur va mettre l'adresse en cache, en mémoire, et ce pour la durée de validité des données, indiquée par le serveur autoritaire sous le nom de TTL ou Time To Live.
Cette durée de validité implique un délai de propagation, le temps que les différents résolveurs mettent à jour les informations de la zone considérée. Plus le TTL est élevé, plus les délais de propagation des informations d'une zone seront importants, mais plus le trafic réseau sera réduit. C'est donc un choix d'équilibre.
Il y a quelques années, des gens très intelligents ont commencé à s'inquiéter : DNS étant critique, il était donc important qu'il soit sécurisé.
En fait, il est assez facile, lorsque vous surfez sur le web, de vous envoyer sur de fausses adresses. On a donc cherché à s'assurer que le DNS ne délivre que des adresses authentiques, autrement dit, dont on soit sûr qu'elles sont vraies.
Pour ce faire, chaque détenteur d'un nom de domaine écrit sa zone DNS, puis la signe à l'aide d'un algorithme cryptographique.
Les résolveurs sont alors chargés de vérifier que ces signatures sont bien valides.
Logique non ?
Concrètement, ça permet à chacun d'être sûr d'être sur le bon site web, pas sur celui d'un pirate.
On peut aussi y publier des informations sûres : c'est le principe de DANE/TLSA qui consiste à publier les empreintes des certificats de chiffrements TLS (sites web, serveurs mail).
https://fr.wikipedia.org/wiki/DNS_-_based_Authentication_of_Named_Entities
Ces notions sont revues et approfondies sur cet article de lord.re :
https://lord.re/posts/63-dns-mega-guide/
Les fichiers de zone DNS suivent un format standard, que tous les serveurs de noms autoritaires suivent, à quelques exceptions près.
On va montrer ici la zone d'exemple typique (un truc idéal qui n'arrive jamais dans la réalité).
Voici un fichier type de zone /var/nsd/zones/chezmoi.tld :
$TTL 1D
@ IN SOA maitre.chezmoi.tld. hostmaster.chezmoi.tld. (
; domaine A du serveur DNS autoritaire
; suivi de l'adresse mail pour
; contacter le responsable du serveur.
; Ici, cette adresse
; est hostmaster@chezmoi.tld.
; Oui, le "@" est remplacé par un "."
2014110502 ; numero de serie à augmenter
; à chaque modification.
86400 ; Refresh
7200 ; Retry
3600000 ; Expire
172800 ) ; Negative Cache TTL
$ORIGIN chezmoi.tld.
@ IN NS maitre
@ IN NS secondaire
@ IN MX 10 mail1
@ IN MX 20 mail2
maitre IN A 192.0.2.2
maitre IN AAAA 2001:db8:1:1::2
mail1 IN A 192.0.2.10
mail2 IN A 192.0.2.11
ipv4only IN A 192.0.2.15
ipv6only IN AAAA 2001:db8:1:1::400
dualstack IN A 192.0.2.200
dualstack IN AAAA 2001:db8:1:1::200
passerelle IN AAAA %%ipv6_passerelle
maitre IN A %%ip_pub_maitre
maitre IN AAAA %%ipv6_maitre
secondaire IN A %%ip_pub_second
secondaire IN AAAA %%ipv6_second
...
Les enregistrements DNS sont (généralement) structurés ainsi (entre parenthèse le nom anglais officiel du champ) :
NOM(NAME) TTL CLASSE(CLASS) TYPE DONNÉE(RDATA)
Le NOM correspond à ce que vous cherchez lors d'une requête à un résolveur.
Le TTL désigne le Time To Live soit le temps pour lequel la donnée est considérée comme valide.
La CLASSE désigne internet (IN). Au début d'internet, d'autres classes étaient utilisées. Aujourd'hui de nombreuses documentations omettent la classe du fait qu'il n'y en a qu'une seule en activité, et que la plupart des résolveurs fonctionnent bien sans. Néanmoins, il arrive que certains programmes ou processus de résolution DNS plantent si la classe n'est pas présente.
TYPE désigne le type de donnée du champ.
Enfin la DONNÉE correspond à l'information désignée par le nom de type TYPE.
"$ORIGIN" fait normalement référence au nom complet de la zone. Par exemple, chezmoi.tld.
Dans le cas où le fichier de zone ne comporte pas de directive "$ORIGIN", le serveur de nom va en produire une avec le nom de la zone.
"@" sera remplacé par "$ORIGIN".
Si vous souhaitez davantage d'informations à propos de cette directive "$ORIGIN", vous pouvez lire la documentation suivante :
http://www.zytrax.com/books/dns/apa/origin.html
"$TTL" est la durée de validité par défaut des données. La valeur recommandée est de 1 jour (1D).
Chaque enregistrement DNS peut avoir son propre TTL (MX et NS sont normalement très stables, et peuvent par exemple avoir des TTL d'une semaine voir plus, ceci permet de réduire la charge réseau).
"$ORIGIN" et "$TTL" doivent être placés en premier dans le fichier de zone.
Le premier enregistrement avec "$ORIGIN" et "$TTL" s'appelle le SOA, pour Source Of Authority. C'est un élément très important.
Le premier champ après SOA désigne le serveur de nom d'origine, en l'occurrence "maitre.chezmoi.tld." et le dernier champ désigne l'adresse de l'administrateur du domaine. "hostmaster.chezmoi.tld." se transformera en "hostmaster@chezmoi.tld". Le premier point sera transformé en @. Vous avez dû mettre un alias sur hostmaster lors de la mise en place du serveur mail. Si vous ne pouvez pas et devez utiliser un point dans la partie "username" (avant @) de l'adresse (Vous vous compliquez vraiment la vie ! 😲), vous devrez alors mettre un "\" devant :
jean\.perrin.chezmoi.tld.
Il faut bien voir que le serveur source d'autorité et l'adresse de l'administrateur du domaine ne sont pas forcément situés dans le domaine en question.
Le numéro de série peut-être de diverses formes, mais il doit toujours aller en augmentant à chaque mise à jour de la zone. Ça permet aux serveurs secondaires de repérer qu'il existe une version plus récente de la zone. Certains administrateurs utilisent la date suivie d'un numéro incrémenté (2017021312 pour une zone modifiée le 13/02/2017 pour la 12è fois - oui, ça peut arriver 😁). D'autres utilisent le timestamp du moment de l'édition (horodatage unix à la seconde près). D'autres se contentent de commencer à 1 et d'incrémenter. Chaque méthode a ses avantages.
Les valeurs du SOA (refresh, retry, expire, négative), indiquées ici, ainsi que celle du TTL, sont celles recommandées par les normes (RFC). Il est tout à fait possible de mettre d'autres valeurs, toutefois celles indiquées ici ont fait leurs preuves.
Les valeurs sont par défaut en secondes. On peut aussi indiquer les valeurs en heures (H) jours (D) ou semaines (W).
"Refresh" et "Retry" indiquent au bout de combien de temps les serveurs secondaires (esclaves), mais néanmoins toujours autoritaires pour la zone, doivent renouveler la zone. Aujourd'hui beaucoup de serveurs de noms signalent à leurs secondaires qu'ils doivent récupérer les nouvelles informations. Ces valeurs ont donc moins d'importance.
"Expire" indique la date limite d'utilisation des informations pour le cas où les serveurs de noms de la zone ne sont plus accessibles. C'est bien différent du TTL.
La valeur "negative" est en fait le temps durant lequel une réponse NXDOMAIN (non existence de la donnée recherchée) sera conservée en cache.
Deux des enregistrements les plus importants. Ils suivent encore une fois : {NOM, TTL, CLASSE, TYPE, RDATA}.
Les adresses de la machine maitre.chezmoi.tld sont donc enregistrées sous cette forme :
maitre IN A 192.0.2.2 maitre IN AAAA 2001:db8:1:1::2
Rappelez-vous bien que le dernier point dans les adresses, implicite dans la plupart des documentations avec des adresses Internet, devient ici très important. Il représente la zone racine. Si une donnée d'adresse ne se termine pas par un point, elle sera complétée ou provoquera un bug.
Dit autrement:
@ 1W IN NS machine.chezmoi.tld.
N'est pas complété avec le "$ORIGIN". Cependant :
@ 1W IN NS machine
Est complété en machine.chezmoi.tld (avec le "$ORIGIN").
CNAME, pour Canonical NAME est un alias.
Dans l'exemple suivant, le nom canonique (réel) de www est maitre.chezmoi.tld.
www IN CNAME maitre
C'est ce qu'on fait dans le cas des hôtes virtuels (ex : blog.chezmoi.tld, webmail.chezmoi.tld...).
Une zone DNS devrait avoir au minimum 2 enregistrements NS d'après les règles communément admises puisqu'il s'agit des adresses des serveurs de noms autoritaires. Techniquement la zone fonctionnera très bien avec un seul, pour autant que le serveur de nom derrière cet enregistrement n'ait jamais de problème.
Il n'y a pas de limite technique au nombre de serveurs NS (autoritaires) dans une zone. Si vous en avez 2, c'est déjà bien : votre serveur et celui d'un ami à qui vous rendez la pareille 😉.
chezmoi.tld. IN NS maitre.chezmoi.tld.
Cet enregistrement signifie : pour la zone chezmoi.tld, le serveur de nom autoritaire (NS) est maitre.chezmoi.tld. On aurait pu aussi l'écrire comme ça :
@ IN NS maitre
Dans ce cas, le @ se trouve remplacé par le "$ORIGIN" de la zone, soit en fait son nom (complet, jusqu'à la racine, c'est-à-dire avec un point final) et maitre est complété avec "$ORIGIN" puisqu'il n'a pas de point soit : maitre.chezmoi.tld.
Pour que les serveurs de noms soient connus du reste du monde, il vous faut les enregistrer dans le registre. C'est d'ailleurs un des deux seuls enregistrements à faire sur le registre, avec l'enregistrement des clés DNSSEC. En effet, une fois que les serveurs autoritaires sont publiés, tout se passe directement sur votre serveur.
Lors de l'enregistrement des NS sur le registre (via le bureau d'enregistrement, ou registrar), on fournit en général deux champs : le nom d'hôte complet de la machine, maitre.chezmoi.tld en l'occurrence, et l'adresse(s). On parle dans ce cas de Glue Record. Comment faire pour connaître l'adresse de maitre.chezmoi.tld puisque c'est lui-même qui a les adresses de la zone chezmoi.tld ? Dans ce cas, exceptionnellement, l'adresse sera écrite directement dans le registre.
Pour enregistrer des serveurs de noms autoritaires sur le registre, il vous faut vous connecter chez votre bureau d'enregistrement.
Vous trouverez une interface "GLUE" dans le panneau de gestion de votre domaine.
Une fois le nouveau GLUE enregistré, vous pouvez modifier la liste des serveurs de noms pour votre domaine.
Au sujet des registres, vous pouvez lire l'article suivant.
https://www.22decembre.eu/2016/09/11/registrars-fr/
MX, c'est un peu comme NS, ça indique un service pour la zone, en l'occurrence le dépôt du courrier. L'enregistrement est un peu conçu de la même manière :
@ IN MX 10 mail1 @ IN MX 20 mail2
Pour la zone chezmoi.tld, les serveurs de mail (MX) sont mail1.chezmoi.tld et mail2.chezmoi.tld.
Seule différence, le 10, qui indique la priorité. Quand on a plusieurs serveurs dans la zone, quel est le serveur qui doit recevoir le courrier en priorité ? Celui qui a le poids le plus faible.
En auto-hébergement, vous pouvez vous contenter d'utiliser le nom de domaine seul plutôt que de créer un sous-domaine mail correspondant à un champ A. Tout simplement :
@ IN MX 10 chezmoi.tld.
MX et NS ne peuvent pas être des redirections (CNAME), ils doivent pointer vers des enregistrements A ou AAAA.
Tout au plus accepte-t-on, avec réticence, des adresses IP. Mais normalement, les champs MX et NS pointent sur des noms d'hôtes, soit des enregistrements A et AAAA.
Les enregistrements TXT permettent de publier des informations variées concernant votre zone. Ce sera pratique pour rendre disponible des clés de vérification par exemple.
Cela peut par exemple ressembler à ceci :
@ IN TXT "v=spf1 a mx ~all"
Ce sera tout pour cette longue description d'une zone. N'hésitez pas à y revenir en cas de besoin.
Il est évidemment possible d'en faire bien davantage (SRV, SSHFP, ...), il en sera fait mention plus tard selon les cas.
Unwind est présent par défaut dans OpenBSD. Il permet en l'état de résoudre les noms de domaines et de garder le résultat en cache pour de meilleures performances. Votre serveur peut le faire lui-même plutôt que de compter sur le résolveur de votre fournisseur d'accès à internet (FAI). En plus, cela permet de gagner quelques millisecondes avec la mise en cache 😎.
Notez toutefois qu'unwind ne propose pas de faire des résolutions pour d'autre machines. Tournez-vous vers unbound pour proposer ce genre de service.
Pour utiliser unwind, activez-le avec les commandes habituelles :
# rcctl enable unwind # rcctl start unwind
Pour indiquer au serveur de demander la résolution des noms de domaines à son instance d'unwind, on édite le fichier /etc/resolv.conf pour y écrire :
nameserver 127.0.0.1
Dans le cas où votre serveur se connecte via dhcp, vous n'avez normalement rien à faire, le démon resolvd se charge tout seul de détecter unwind.
Et voilà, votre serveur se débrouille maintenant tout seul pour résoudre des noms de domaine.
Vous pouvez tester l'efficacité d'unwind avec la commande dig qui nous montre les résultats d'une résolution DNS :
$ dig si3t.ch [...] ;; Query time: 61 msec
Il a fallu ici 61 millisecondes pour avoir une réponse. Relancez une deuxième fois cette commande pour voir la différence :
$ dig si3t.ch [...] ;; Query time: 0 msec
L'adresse a été mise en cache, et sera vérifiée régulièrement (à l'issue d'une durée égale au TTL). C'est toujours un gain de performance bienvenu !
Pour aller plus loin, je vous conseille la lecture des man unwind, unwind.conf et unbound suivants :
https://man.openbsd.org/unwind
https://man.openbsd.org/unwind.conf
https://man.openbsd.org/unbound
Il y a encore un service que vous pouvez administrer par vous-même plutôt que de le laisser entre des mains extérieures : le serveur DNS autoritaire. C'est justement ce pourquoi est fait nsd, présent par défaut dans une installation d'OpenBSD. Un pas de plus vers l'indépendance 😏.
Pour configurer nsd, on édite le fichier /var/nsd/etc/nsd.conf.
server:
hide-version: yes
zonesdir: "/var/nsd/zones"
ip-address: 192.168.1.2
ip-address: 2001:db8:1:1::2
debug-mode: no
verbosity: 1
# master zones
zone:
name: "chezmoi.tld"
zonefile: "master/chezmoi.tld"
Ici nsd suit cette organisation : les zones sont classées selon si le serveur est autoritaire (master) ou esclave (slave). Chaque zone correspond à un fichier portant le nom du domaine. Par exemple /var/nsd/zones/master/chezmoi.tld. Vous pouvez bien sûr vous organiser différemment.
N'oubliez pas de modifier cet exemple avec l'adresse IP locale du serveur.
Une fois configuré, vous pouvez finalement lancer nsd comme d'habitude :
rcctl enable nsd rcctl start nsd
Pensez à ouvrir et rediriger le port 53 (domain) en UDP et TCP, c'est celui utilisé par nsd.
Lorsque la configuration de nsd est correcte, vous pouvez alors ajouter dans le registre les adresses publiques de votre serveur (ipv4 et/ou ipv6) à la liste des serveurs autoritaires pour votre zone.
Un exemple de configuration complet est disponible à la fin du présent document.
DNSSEC utilise deux sortes de clés : ZSK (Zone Signing Key), légères et de courte durée et KSK (Key Signing Key) plus lourdes et de longue durée d'utilisation.
Pourquoi la différence ?
Il est recommandé que les clés qui signent les zones soient renouvelées régulièrement (approximativement tous les mois, certains le font toutes les semaines). Mais d'un autre côté, on peut difficilement mettre ça à jour tous les mois dans le registre.
On a donc créé en plus d'autres clés qui vont signer les premières, mais qu'on n'utilisera que pour cela, pas pour signer les zones en elles-mêmes. Ces clés seront plus solides, plus lourdes (on peut se permettre, puisqu'elles sont peu utilisées) et d'une plus longue durée de vie. Ce sont ces clés qui seront enregistrées dans le registre.
En fait, on ne va pas les enregistrer, mais mettre un condensat, une empreinte cryptographique, dans la zone supérieure. C'est le même principe que pour les serveurs de noms : chaque zone publie ses serveurs de noms (NS) dans la zone supérieure.
Il est important aussi que vous réalisiez ici les notions de temps. Entre le TTL, la durée de vie et de validité des clés et des signatures, vous ne pouvez plus faire des changements et regarder le truc marcher immédiatement.
En particulier, vous devez publier à l'avance les clés qui seront utilisées prochainement. Ceci amène de nombreux administrateurs à avoir en permanence deux ZSK : une qui est utilisée actuellement et une autre qui sera utilisée à la fin de la période de validité de la clé actuelle. C'est d'ailleurs cette solution qui est présentée en dessous. Les clés KSK sont elles aussi publiées à l'avance (quoique rarement en double).
Comme décrit plus tôt, signer votre domaine DNS vous permet de préserver son intégrité.
Cette opération doit être renouvelée régulièrement (les signatures DNSSEC ont une date de fraîcheur limite). Ceci requiert l'installation d'un "signeur" ainsi qu'un peu d'automatisation.
On va décrire ici la solution ldnscripts qui est un script simple réalisé par 22decembre.
https://www.22decembre.eu/en/2017/11/01/ldnscripts/
Notez qu'il existe des outils plus complets/complexes comme OpenDNSSEC (beaucoup plus complexe à installer et administrer) ou KNOT.
ldnscripts ne nécessite pas d'ajouter d'outils particuliers mis à part ldns-utils :
# pkg_add ldns-utils
Le reste sera géré en utilisant les outils déjà présents de base dans OpenBSD, à savoir les scripts /etc/weekly, /etc/monthly...
Nous allons suivre la méthode proposée par l'auteur de ce script et installer ldnscripts à partir de l'archive que l'on décompresse :
$ cd /tmp $ ftp https://framagit.org/22decembre/ldnscripts/-/archive/master/ldnscripts-master.tar.gz $ tar xvzf ldnscripts-master.tar.gz $ cd ldnscripts-master* # make install
La configuration se déroule dans le fichier /etc/ns/ldnscripts.conf. Vous avez un modèle dans l'archive téléchargée précédemment qui ressemble à ça :
# repository where to find unsigned zone file and specific conf NS_REP=/etc/ns # serial : unixtime SERIAL=unixtime # algorithm to use. They are listed : ldns-keygen -a list ALG=ECDSAP384SHA384 # length of the zsk ZSK_BITS=1024 KSK_BITS=2048 # validity of signatures in days VALIDITY=9 #NSEC3 NSEC3_ALG=SHA-384 RUN=24 # Verbose - set to 1 if needed VERBOSE=1
Les paramètres sont les suivants :
Si vous souhaitez utiliser une configuration par domaine, c'est tout à fait possible en créant un fichier de configuration portant le nom /etc/ns/domaine.com.conf.
C'est tout pour la configuration 😊
Pour commencer à utiliser ldnscript, on lance l'action init qui va créer tout le nécessaire: structure, premières clés... La commande à lancer est :
# ldnscript init chezmoi.tld
Vous verrez alors des messages ressemblant à ceci (le VERBOSE est actif ci-dessous) :
This script will initialize your zone chezmoi.tld with the general configuration or the one set at /etc/ns/chezmoi.tld.conf. If you are not happy with it, modify your configuration (by copying the conf file to /etc/ns/chezmoi.tld.conf and then editing it) and run this script again. The script will create one KSK and two ZSK and finally sign the zone (which will triger a reload of your nsd server on the chezmoi.tld zone). The key Kchezmoi.tld.+010+25115 has been generated with these arguments : -a RSASHA512 -b 1024 chezmoi.tld The key Kchezmoi.tld.+010+34655 has been generated with these arguments : -a RSASHA512 -b 1024 chezmoi.tld The key Kchezmoi.tld.+010+12321 has been generated with these arguments : -k -a RSASHA512 -b 2048 chezmoi.tld A new KSK key has been generated. Make sure to update the DS record in your registrar quickly. The key is Kchezmoi.tld.+010+12321 DS content : chezmoi.tld. IN DS 12321 10 2 f6f91afd522680a3c459e1956e75f8eda078f99b8cf07114f0d299161bff0145 create a complete zone file for chezmoi.tld with the current time as SOA Signing zone Zone is verified and complete
Un dossier /var/ldnscripts/chezmoi.tld/ est créé, il contient les clés ZSK et KSK.
Le fichier de zone signé est présent dans /var/nsd/zones/signed/chezmoi.tld. Adaptez donc la configuration de nsd pour l'utiliser :
server:
zonesdir: "/var/nsd/zones"
...
# master zones
zone:
name: "chezmoi.tld"
zonefile: "signed/chezmoi.tld"
À noter que nsd est un serveur statique. Heureusement, ldnscript le relance après chaque signature.
Attention, vous devez publier chez votre registre les clés publiques que vous trouverez dans les fichiers portant l'extension ".key" disponibles dans /var/ldnscript/chezmoi.tld/ksk. Selon votre registre, il faut aussi publier les enregistrements DS qui sont dans le fichier .ds.
Nous n'avons pas fini, il faut maintenant mettre en place une routine de signature avec renouvellement des clés lorsque c'est nécessaire. Tout est prévu, rassurez-vous 😊.
Parmi les actions proposées par ldnscript, on trouvera :
Concrètement, voici ce que vous allez faire. Éditez le fichier /etc/monthly.local pour y ajouter :
/usr/local/sbin/ldnscript rollover all
Ensuite, nous devons nous assurer que les signatures sont renouvelées avant la fin du paramètre VALIDITY du fichier de configuration. On a mis 9 jours auparavant, afin de lancer la signature chaque semaine avec 2 jours d'avance. Éditez le fichier /etc/weekly.local :
/usr/local/sbin/ldnscript sign all
Enfin, tous les ans, vous créerez une nouvelle KSK ainsi :
/usr/local/sbin/ldnscript ksk chezmoi.tld
Si vous avez peur d'oublier, ajoutez un crontab pour vous envoyer un message le 2 mai (c'est une date importante 😜):
# crontab -e 0 0 2 5 * echo 'renew ksk' | mail -s "ALERT KSK" root
N'oubliez pas de publier cette clé chez votre registre. Le script rollover se chargera de supprimer l'ancienne automatiquement. Vous pourrez à ce moment-là retirer son enregistrement chez le serveur.
Et voilà, ça suffit, tout le reste est géré par ldnscript. C'est finalement long seulement la première fois. Notez que dans l'exemple, on gère toutes les zones.
Lorsque vous renouvelez les KSK, vous devez publier la clé publique dans votre registre. Il faut le faire assez tôt pour qu'elle soit bien répandue avant que la précédente soit révoquée.
Lors de la création de la clé, ldnscript vous indiquera le numéro de la nouvelle clé (keytag) ainsi que son condensat (DS) qui vous servira pour la publication dans le registre.
La clé publique se situe dans le fichier /var/ldnscripts/zones/chezmoi.tld/ksk/Kchezmoi.tld*.key.
On présente comment ajouter cette clé si votre registre est infomaniak:
Pour ce dernier, c'est assez simple puisqu'il suffit d'indiquer seulement le ds. Il s'agit d'un fichier créé par ldnscript que vous trouverez dans /var/ldnscript/chezmoi.tld/ds :
$ cat /var/ldnscript/chezmoi.tld/ds chezmoi.tld. IN DS 4333 14 4 14da0e9e3ff4fa75c035aaaaa0f9e2ce7c485a...e52
Les 4 derniers champs indiquent respectivement :
Depuis votre tableau de bord infomaniak, cherchez votre nom de domaine et ouvrez la page de gestion.
Vous verrez dans le cadre de gestion une entrée "DNSSEC" :
Une fenêtre s'ouvre et vous permet de recopier les champs trouvés dans l'enregistrement DS :
On présente comment ajouter cette clé dans le système du bureau d'enregistrement Gandi.
Dirigez-vous dans votre tableau de bord :
On voit ici la page d'entrée de Gandi pour le domaine si3t.ch. Vous avez un onglet vers la gestion DNSSEC.
Ici on voit la clé KSK enregistrée par Gandi. Ceci correspond au contenu du fichier /var/ldnscripts/zones/si3t.ch/ksk/Ksi3t.ch.*.key. On voit le numéro de l'algorithme et le keytag qui correspondent avec le numéro du fichier.)
Pour enregistrer une nouvelle clé chez Gandi, cliquez sur "Ajouter une clé". Vous devez copier la clé publique dans la grande zone de texte Clé publique. Vérifiez aussi la correspondance avec l'algorithme.
À la fin du processus, Gandi aura calculé le DS (Condensat) de votre clé. Vous devriez vérifier qu'il correspond bien avec celui qui se trouve sur votre serveur, dans le fichier /var/ldnscripts/zones/chezmoi.tld/ksk/Kchezmoi.tld.*.ds.
Certains bureaux d'enregistrements vont également vous proposer de récupérer automatiquement les clés et vous demander de valider qu'il s'agit bien **de celle-ci**. Cette méthode est assez sûre (pas de risque d'erreur lors d'un copier-collé de votre part) mais requiert que vous soyez très attentif à ce que le bureau ne vous propose pas une autre clé (ce qui constituerait un cas d'empoisonnement du DNS). C'est par contre une méthode très sûre dans le cadre du renouvellement des clés. En effet la zone, une fois signée, est sûre et on peut récupérer et enregistrer sereinement les nouvelles clés.
Quelle que soit la méthode utilisée pour enregistrer les clés sur les registres, il est fréquent que le bureau d'enregistrement vérifie automatiquement la clé avec celles qui sont publiées par votre serveur. Vous devez donc vous assurer que vos clés soient effectivement publiques avant cette étape.
Une fois qu'une clé est révoquée, l'enregistrement DS de la clé précédente peut être enlevé.
Que signifie ajouter un serveur DNS esclave ? Il n'y a pas là de racisme ou autre référence à une période bien sombre de l'histoire.
Il s'agit d'ajouter un serveur de nom (NS) dans votre domaine (chez le registre et dans votre zone) et le configurer pour qu'il serve lui aussi votre zone (qu'il fournisse les informations à propos de votre domaine). Il est un esclave (il obéit), mais il n'en est pas moins autoritaire (les informations qu'il délivre sont toutes aussi valables que celles que délivrerait votre premier serveur).
On parle aussi de serveur secondaire.
Ceci permet, si votre serveur principal (serveur maître) est inaccessible (coupure de réseau, le démon nsd est planté, pluie de météorites, pénurie de crêpes...), à votre zone d'être toujours annoncée.
Vous pouvez donc demander à un ami qui aurait un serveur de nom déjà installé (pas forcément OpenBSD, et pas forcément nsd non plus, bien que ce soit cette solution qui sera décrite) de se mettre en esclave sur votre domaine. Ou vous pouvez installer vous-même ce serveur, sur une machine virtuelle louée à openbsd.amsterdam par exemple 😊. L'important étant qu'ils ne soient pas dans le même réseau, voire d'une manière générale, assez éloignés l'un de l'autre : quelques centaines de km constituent une bonne protection contre les coupures de réseau/d'électricité simultanées 😉.
Notez qu'il est tout à fait possible d'être maître et esclave l'un de l'autre, en échange de bons procédés.
On va décrire ici les deux côtés du système. Vous pouvez donc être l'administrateur du serveur maître, du serveur esclave, ou bien des deux à la fois. Ceci étant assez standard, il est possible d'utiliser d'autres logiciels, il suffit de lire la documentation relative et d'adapter (monter un serveur Bind secondaire, etc).
Commençons par prévoir un peu d'authentification.
Oui, je sais, c'est laborieux. En même temps, on veut faire les choses bien, non ? 😉 En l'occurrence l'authentification va permettre de garantir à nouveau que notre zone est mise à jour par le bon serveur.
Il s'agit de créer un secret partagé et identique sur les deux serveurs (maître et secondaire). Cette opération peut-être réalisée sur l'un ou l'autre serveur, voire sur un autre ordinateur.
Nous allons utiliser la commande ldns-keygen disponible dans le paquet ldns-utils que vous devriez déjà avoir installé si vous avez suivi la partie précédente. Il va nous permettre de créer une paire de clés qui contiendra un code "secret".
$ cd /tmp $ ldns-keygen -a hmac-sha256 -b 160 chezmoi.tld
Vous avez deux fichiers créés. Vous pouvez afficher le contenu de la clé privée :
$ cat Kchezmoi.tld.+159+54791.private Private-key-format: v1.2 Algorithm: 159 (HMAC_SHA256) Key: H8D/Ka9RerEtmC0jN5hSQeATxNI=
Copiez la chaîne de caractère "Key" dans la configuration de nsd pour le maître et l'esclave dans la partie "secret". N'oubliez pas de préciser le bon algorithme :
key:
name: "transfert"
algorithm: hmac-sha256
secret: "H8D/Ka9RerEtmC0jN5hSQeATxNI="
Le nom de la clé (transfert ici) n'est pas important en soi, c'est juste pour se repérer.
Vous pouvez infomaniak-dnssec1.png supprimer les fichiers de clé situés dans /tmp sans problème.
Dans la configuration du serveur de nom, on rajoute deux lignes pour informer le serveur esclave qu'il doit récupérer la zone du domaine. Pour ça, on rajoute les instructions notify et provide-xfr.
# master zone
zone:
name: "chezmoi.tld"
zonefile: "signed/chezmoi.tld"
notify: 192.0.2.1 transfert
provide-xfr: 192.0.2.1 transfert
key:
name: "transfert"
algorithm: hmac-sha256
secret: "H8D/Ka9RerEtmC0jN5hSQeATxNI="
À chaque fois que la zone sera mise à jour sur votre serveur de nom primaire, celui-ci informera le serveur à l'adresse 192.0.2.1 et la zone sera mise à jour sur ce dernier.
De nombreux services en ligne (bureau d'enregistrement notamment) vous proposent d'héberger gratuitement votre zone en esclave. Mais dans ce cas, ça ne sert à rien de les notifier : les serveurs pêchent la zone à intervalle régulier. Conservez juste le provide, sans authentification : NOKEY à la place du nom de la clé.
Pour utiliser le serveur secondaire de gandi.net, suivez le lien suivant.
https://docs.gandi.net/en/domain_names/advanced_users/secondary_nameserver.html
Reste plus qu'à indiquer dans votre zone et dans le registre (voir plus haut) que les serveurs secondaires sont bien là et fourniront l'info. (NS)
$ORIGIN chezmoi.tld.
$TTL 86400
@ IN SOA maitre.chezmoi.tld. hostmaster.chezmoi.tld. (
2014110502 ;
86400 ; refresh
7200 ; retry
3600000 ; expire
172800 ) ; negative
@ IN NS maitre.chezmoi.tld.
@ IN NS secondaire.chezmoi.tld.
@ IN NS autre.domaine.tld. ; on a un autre ami
; qui nous aide !
maitre IN A 192.0.2.2
maitre IN AAAA 2001:db8:1:1::2
secondaire IN A 192.0.2.3
Il s'agit juste d'un peu de configuration:
# slave zone
zone:
name: "chezmoi.tld"
zonefile: "slave/chezmoi.tld"
allow-notify: 192.0.2.2 transfert
request-xfr: 192.0.2.2 transfert
key:
name: "transfert"
algorithm: hmac-sha256
secret: "H8D/Ka9RerEtmC0jN5hSQeATxNI="
Remarquez bien que les clés de transfert ont une configuration rigoureusement identique sur les deux serveurs.
Les fichiers de zones ne doivent pas être édités ou manipulés sur le secondaire. Ils seront mis à jour tout seuls. Si vous voulez les faire changer de place dans le système de fichiers, éditez la configuration et relancez nsd. Ce dernier va re-télécharger la zone depuis le serveur maître et créer les nouveaux fichiers tout seul.
Vous pouvez tester la synchronisation des zones avec dig :
$ dig -q @maitre.chezmoi.tld chezmoi.tld $ 192.0.2.10 … $ dig -q @secondaire.chezmoi.tld chezmoi.tld $ 192.0.2.10
N'oubliez pas d'ajouter le serveur secondaire dans la liste des serveurs de noms chez le registre.
Vous pouvez utiliser les sites suivants pour vérifier que votre zone se propage correctement, ne génère pas d'erreurs et que la mise en place de DNSSEC est correcte :
Vérification de la propagation et la validité de la zone:
Vérifications DNSSEC:
https://dnssec-debugger.verisignlabs.com
nic.eu.org propose depuis 1996 des noms de domaines gratuits terminant par eu.org.
Nous allons voir ici la mise en place d'une zone avec ce registre.
Tout d'abord, consultez la liste des domaines ouverts à l'enregistrement, puis choisissez-en un qui vous plaît.
https://nic.eu.org/opendomains.html
Pour l'exemple, nous prendrons "chezmoi.tld.fr.eu.org"
Créez la zone de ce domaine. Puisque par la suite, nous utiliserons ldnscripts décrit plus tôt pour activer DNSSEC, on crée directement le fichier /etc/ns/chezmoi.tld.fr.eu.org :
$TTL 1D
$ORIGIN chezmoi.fr.eu.org.
@ IN SOA ns1.chezmoi.fr.eu.org. batman.chezmoi.tld. (
2017111301
1D
2H
2W
2D )
@ IN NS ns1.chezmoi.fr.eu.org.
@ IN A 192.0.2.2
@ IN AAAA 2001:db8:1:1::2
ns1 IN A 192.0.2.2
ns1 IN AAAA 2001:db8:1:1::2
ns2 IN A 192.0.2.3
La zone est basique, on ne précise pour l'instant que deux serveurs de noms, "ns1" et "ns2", dont le second est uniquement accessible en IPV4.
On ajoute une section pour nsd sur "ns1" :
# cat /var/nsd/etc/nsd.conf
key:
name: "transfert"
algorithm: hmac-sha256
secret: "Hsd/Ka9RerEtmC0jsd5d5eATxNI="
zone:
name: "chezmoi.tld.fr.eu.org"
zonefile: "signed/chezmoi.tld.fr.eu.org"
provide-xfr: 192.0.2.3 transfert
notify: 192.0.2.3 transfert
Faites de même sur le serveur secondaire "ns2" :
# cat /var/nsd/etc/nsd.conf key: name: "transfert" algorithm: hmac-sha256 secret: "Hsd/Ka9RerEtmC0jsd5d5eATxNI=" zone: name: "chezmoi.tld.fr.eu.org" zonefile: "slave/chezmoi.tld.fr.eu.org" allow-notify: 192.0.2.3 transfert request-xfr: 192.0.2.3 transfert
On recharge nsd :
# rcctl reload nsd
On active la zone avec ldnscripts tout en préparant pour DNSSEC.
# ldnscript init chezmoi.tld.fr.eu.org
Et voilà, c'est prêt. On peut maintenant enregistrer le domaine puisqu'il est géré.
Créez un compte puis connectez-vous après avoir validé le mail d'inscription.
Choisissez ensuite de créer un Nouveau domaine.
Il vous est alors demandé le nom de domaine complet souhaité ainsi que des informations sur votre personne.
Ensuite, vous devez remplir la section "Serveurs de noms". Il s'agit ici d'associer le nom de domaine et l'IP des serveurs de noms gérant la zone du domaine souhaité. Il est important que la zone soit déjà gérée par ces serveurs quand vous remplissez ce champ. Vous pouvez préciser des IPV4 et IPV6.
Plus simplement dit, il faut préciser les enregistrements "NS" qui sont dans votre zone.
Finalement, validez. Vous verrez apparaître si tout va bien un message de la sorte :
---- Servers and domain names check Accepted IP for NS1.CHEZMOI.FR.EU.ORG: 2001:db8:1:1::2 192.0.2.2 Accepted IP for NS2.CHEZMOI.FR.EU.ORG: 192.0.2.3 ---- Checking SOA records for chezmoi.fr.eu.org SOA from NS1.CHEZMOI.FR.EU.ORG at 2001:db8:1:1::2: serial 2019100702 (21.005 ms) SOA from NS1.CHEZMOI.FR.EU.ORG at 192.0.2.2: serial 2019100702 (6.006 ms) SOA from NS2.CHEZMOI.FR.EU.ORG at 192.0.2.3: serial 2019100702 (73.715 ms) ---- Checking NS records for chezmoi.fr.eu.org NS from NS1.CHEZMOI.FR.EU.ORG at 2001:db8:1:1::2: ok (20.674 ms) NS from NS1.CHEZMOI.FR.EU.ORG at 192.0.2.2: ok (5.953 ms) NS from NS2.CHEZMOI.FR.EU.ORG at 192.0.2.3: ok (65.559 ms) No error, storing for validation... Saved as request 20191007195509-arf-42318 Done
Surveillez votre boîte mail. Vous allez bientôt recevoir un message confirmant la création de votre zone.
Une fois que cela est fait, vous pouvez activer DNSSEC. Dirigez-vous dans l'interface de gestion puis sélectionnez votre domaine fraîchement créé. Cliquez alors sur "DNSSEC"
Vous voyez un champ vous permettant de coller l'enregistrement DS. Avec ldnscripts présenté plus tôt, c'est très simple.
cat /var/ldnscript/chezmoi.tld.fr.eu.org/ds
Copiez le contenu de ce fichier dans le champ puis validez.
Vous pouvez maintenant vérifier que DNSSEC est bien activé sur votre zone.
https://dnssec-analyzer.verisignlabs.com/