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.

Outre le bonheur d'être indépendant, de contrôler ses données, sachez qu'un serveur autoritaire sait exactement qui demande à voir tel ou tel contenu. Si on se place dans le cas où un serveur est autoritaire pour des centaines de zones, ce dernier constitue alors un excellent moyen de collecter une liste de visiteurs pour des sites web. Autant laisser cette tâche à une personne de confiance : vous.

Si vous avez à coeur le respect de la vie privée de chacun, et souhaitez être totalement indépendant, il vous est possible d'utiliser NSD, le serveur de nom autoritaire par défaut d'OpenBSD, pour publier votre zone plutôt que de déléguer cette tâche à votre registre ou une autre entreprise privée. Il est conçu autour de l'idée d'une zone statique

Configuration simple de NSD

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: 2

## 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 mettre dans le registre les adresses publiques de votre serveur (ipv4 et/ou ipv6).

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 voyiez 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. 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 :

# 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=RSASHA512

# length of the zsk
ZSK_BITS=1024

KSK_BITS=2048

# validity of signatures in days
VALIDITY=9

#NSEC3
NSEC3_ALG=SHA-1
RUN=24

# Verbose - set to 1 if needed
VERBOSE=1

Les paramètres sont les suivants :

• NS_REP correspond au dossier où sont les zones à signer. Chaque fichier de zone doit porter le nom du domaine que vous voulez servir. Par exemple /etc/ns/chezmoi.tld. Vous devez créer cette zone.
• SERIAL : Le format du numéro de série de la zone. Ça peut être “unixtime” ou encore “date”. Dans le doute, ne changez rien.
• ALG : L'algorithme pour les clés. Vérifiez ce que votre registre supporte avant de changer ce paramètre.
• ZSK_BITS et KSK_BITS : la longueur des clés ZSK et KSK respectivement.
• VALIDITY : La durée de validité d'une signature en jours. Attention, ce paramètre doit être au moins aussi long que l'intervalle de ces mêmes signatures (voir la commande sign plus bas)
• NSEC3_ALG et RUN : L'algorithme de signature et le nombre de fois que l'algorithme doit tourner pour générer la signature.
• VERBOSE : À mettre à “1” si vous voulez des détails supplémentaires en utilisant ldnscripts.

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.

Sinon, le plus simple est d'avoir une seule configuration en copiant l'exemple de l'archive :

# cp ldnscript.conf /etc/ns/

C'est tout pour la configuration :)

Pour commencer, 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 de ce type (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 (pas pour GANDI). Lisez la partie qui montre comment ajouter des clés chez le registre pour plus d'informations.

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 :

• sign : Cette action signe la zone pour une durée égale à VALIDITY. On le lancera donc un peu avant la fin de validité d'une signature, mais aussi après chaque modification de la zone et la création / renouvellement d'une clé.
• rollover qui va renouveler les clés. Il y aura normalement 3 clés afin de pré-publier les clés qui seront utilisées par la suite pour qu'elles soient bien répandues :
  • La clé à la retraite
  • La clé en cours d'utilisation
  • La future clé.

Ce script s'occupe aussi de supprimer les clés qui ne sont plus utilisées. Il faudra le lancer tous les mois.

• zsk vous permet de créer de nouvelles clés ZSK manuellement. Elles seront mises en activité lors du prochain rollover. Lors de chaque rollover, une nouvelle clé zsk sera également automatiquement créée grâce à cette commande.
• ksk crée une clé KSK sur le même principe.

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

N'oubliez pas de publier cette clé. 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. Notez que dans l'exemple, on ne gère qu'une zone. Des scripts facilitant la gestion de plusieurs zones et leur vérification sont disponibles, regardez le site de l'auteur pour plus de détails.

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é 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 ouaf.xyz. En bas à gauche, vous avez le lien vers la gestion de DNSSEC.)

(Ici on voit la clé KSK enregistrée par Gandi. Ceci correspond au contenu du fichier /var/ldnscripts/zones/ouaf.xyz/ksk/Kouaf.xyz.+010+39369.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.

On présente ici la méthode du registre danois:

(On doit copier l'empreinte DS dans le champ Digest. Les autres champs doivent bien entendu correspondre.)

(Les algorithmes compatibles avec le registre danois.)

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.

Vous pouvez également envoyer vos clés publiques par courriel. Dans ce cas, prenez la précaution de signer votre courriel avec GPG ou TLS.

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 assurez 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 ou n'importe quelle autre raison), à votre zone d'être toujours annoncée.

Vous pouvez donc demander à un ami qui aurait un serveur de nom déjà installé (pas forcement OpenBSD, et pas forcement 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. 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 milliers 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…).

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, affichez 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 supprimer les fichiers de clé situés dans /tmp sans problème désormais.

Dans la configuration du serveur de nom, on rajoute deux lignes pour informer le serveur esclave qu'il doit récupérer le 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, 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, par exemple GANDI) 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, regardez cette page. Ça permet de retrouver l'IP du serveur secondaire de GANDI :

$ dig ns6.gandi.net +short
217.70.177.40

Reste plus qu'à l'indiquer dans votre zone et dans le registre (voir plus haut) que les serveurs secondaires sont bien là et fourniront l'info.

$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
                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. 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 comme ceci :

$ dig -q @maitre.chezmoi.tld chezmoi.tld
$ 192.0.2.10
…
$ dig -q @secondaire.chezmoi.tld chezmoi.tld
$ 192.0.2.10

Dans le registre, il faut inscrire le serveur secondaire dans la liste des serveurs de noms. C'est expliqué dans ce paragraphe.