Description
Retrouvez ci-dessous la traduction EN → FR de l’article “How to build a name server with DNS over TLS (DoT)”, écrit par Bruno Flückiger.
Date : 2020-08-25
Introduction
Cet article est en rapport avec la configuration de nsd(8) en tant que serveur de noms public pour votre propre domaine, fournissant DNS-over-TLS (DOT). Tout ce qui faut pour cette tâche est inclus dans l’installation de base d’OpenBSD. Vous n’avez besoin d’installer aucun paquet additionnel pour cela.
Certificats
Tout fournisseur de certificats qui supporte le protocole ACME peut être utilisé. Personnellement, j’utilise le plus populaire actuellement : Let’s Encrypt.
Les challenges reçus du fournisseur de certificats seront utilisés par
httpd(8) en configurant /etc/httpd.conf,
similaire à ceci :
server "ns1.example.net" {
listen on egress port http
root "/"
location "/.well-known/acme-challenge/*" {
request strip 2
root "/acme"
}
}
types {
include "/usr/share/misc/mime.types"
}
Testez votre configuration, puis activez et démarrez httpd(8) :
$ doas httpd -n
$ doas rcctl enable httpd
$ doas rcctl start httpd
L’étape suivante est de configurer acme-client(1). Je vous suggère
d’utiliser /etc/examples/acme-client.conf en tant que source à
sauvegarder puis à modifier conséquemment. Le fichier acme-client.conf
résultant devrait être sauvegardé dans /etc et ressemblait à :
authority letsencrypt {
api url "https://acme-v02.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-privkey.pem"
}
authority letsencrypt-staging {
api url "https://acme-staging.api.letsencrypt.org/directory"
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}
domain ns1.bsdhowto.ch {
domain key "/etc/ssl/acme/private/ns1.bsdhowto.ch.key"
domain certificate "/etc/ssl/acme/ns1.bsdhowto.ch.crt"
domain full chain certificate "/etc/ssl/acme/ns1.bsdhowto.ch.fullchain.pem"
sign with letsencrypt
}
Avant d’avoir votre certificat, vous devriez vous assurer que pf(4) laisse passer les requêtes vers httpd(8). Ajoutez une règle similaire à la suivante dans votre fichier pf.conf(5) :
pass in on egress proto tcp from any to egress port http
Vérifiez la configuration dans /etc/pf.conf puis chargez-la dans pf(4)
en utilisant les commandes suivantes :
$ doas pfctl -nf /etc/pf.conf
$ doas pfctl -f /etc/pf.conf
Maintenant vous êtes prêt à récupérer le certificat pour nsd(8). N’oubliez pas de créer le fichier OCSP aussi :
$ dest=/etc/ssl/ns1.example.net
$ doas acme-client ns1.example.net
$ doas ocspcheck -No ${dest}.ocsp ${dest}.fullchain.pem
Vous devez vous assurer que le certificat soit valide, de même pour la
réponse OCSP, et qu’ils soient renouvelés avant leurs expirations. Je
vous suggère d’ajouter quelque chose comme ceci dans /etc/daily.local :
#!/bin/sh
dest=/etc/ssl/ns1.example.net
acme-client ns1.example.net
if [ $? -eq 0 ] ; then
ocspcheck -No ${dest}.ocsp ${dest}.fullchain.pem
rcctl restart nsd
fi
oscpcheck -i ${dest}.ocsp ${dest}.fullchain.pem
if [ $? -eq 1 ] ; then
ocspcheck -No ${dest}.ocsp ${dest}.fullchain.pem
rcctl restart nsd
fi
Le script vérifie en premier le certificat. S’il a été renouvelé , il récupère la réponse OCSP pour le nouveau certificat et redémarre nsd(8) afin de charger les nouveaux fichiers. À la seconde étape, le script vérifie si la réponse OCSP a expirée. Si c’est le cas, il récupère une nouvelle réponse OCSP et redémarre nsd(8) afin de charger la nouvelle réponse OCSP.
Configuration de nsd(8)
La configuration correcte de nsd(8) dépend du rôle de votre serveur : primaire ou secondaire. La plupart des fournisseurs de domaines requièrent que vous exécutiez au moins deux serveurs de noms, de préférence dans deux différents sous-réseaux. Je vous montre la configuration des deux.
Voici la première pour le primaire :
server:
hide-identity: yes
hide-version: yes
ip-address: 192.0.2.11
ip-address: 192.0.2.11@853
ip-address: 2001:db8:1::c000:020b
ip-address: 2001:db8:1::c000:020b@853
server-count: 1
statistics: 86400
tls-service-key: "/etc/ssl/ns1.example.net.key"
tls-service-pem: "/etc/ssl/ns1.example.net.fullchain.pem"
tls-service-ocsp: "/etc/ssl/ns1.example.net.ocsp"
remote-control:
control-enable: yes
key:
name: nskey.example.net
algorithm: sha256
secret: "IAmASecretKeyForDomainTransfers"
zone:
name: "example.net"
zonefile: "/var/nsd/zones/master/%s.dns"
notify: 198.51.100.12 nskey.example.net
notify: 2001:db8:2::c633:640c nskey.example.net
provide-xfr: 198.51.100.12 nskey.example.net
provide-xfr: 2001:db8:2::c633:640c nskey.example.net
outgoing-interface: 192.0.2.11
outgoing-interface: 2001:db8:1::c000:020b
Assurez vous que le serveur primaire et le secondaire utilise la même clé secrète pour le transfert de domaines, autrement cela ne fonctionnera pas. Vous pouvez générer le secret pour la clé de transfert de domaine en utilisant la commande suivante :
$ for i in $(jot -r -s " " 32 0 255) ; do
> echo ${i} | awk '{ printf "%c", $1 }'
> done | sha256 -b
La prochaine étape est de s’assurer que le fichier de votre zone contient certaines données valides. Soit vous avez déjà un fichier de zone valide, soit vous pouvez utiliser celui qui suit en tant que point de départ :
$ORIGIN .
$TTL 3600 ; 1 hour
example.net IN SOA ns1.example.net. hostmaster.example.net. (
1 ; serial
10800 ; refresh (3 hours)
600 ; retry (10 minutes)
241900 ; expire (4 weeks)
3600 ; minimum (1 hour)
)
NS ns1.example.net.
NS ns2.example.net.
$ORIGIN example.net.
ns1 A 192.0.2.11
AAAA 2001:db8:1::c000:020b
ns2 A 198.51.100.12
AAAA 2001:db8:2::c633:640c
La configuration du second serveur a besoin d’autres options légèrement différentes pour en faire un serveur secondaire, mais elle ressemble à celle du serveur primaire :
server:
hide-identity: yes
hide-version: yes
ip-address: 198.51.100.12
ip-address: 198.51.100.12@853
ip-address: 2001:db8:2::c633:640c
ip-address: 2001:db8:2::c633:640c@853
server-count: 1
statistics: 86400
tls-service-key: "/etc/ssl/ns2.example.net.key"
tls-service-pem: "/etc/ssl/ns2.example.net.fullchain.pem"
tls-service-ocsp: "/etc/ssl/ns2.example.net.ocsp"
remote-control:
control-enable: yes
key:
name: nskey.example.net
algorithm: sha256
secret: "IAmASecretKeyForDomainTransfers"
zone:
name: "example.net"
zonefile: "/var/nsd/zones/slave/%s.dns"
allow-notify: 192.0.2.11 nskey.example.net
allow-notify: 2001:db8:1::c000:020b nskey.example.net
request-xfr: 192.0.2.11 nskey.example.net
request-xfr: 2001:db8:1::c000:020b nskey.example.net
outgoing-interface: 198.51.100.12
outgoing-interface: 2001:db8:2::c633:640c
Sur les deux serveurs, vous devez exécuter la commande suivant pour
prendre le contrôle à distance pour que l’utilisation de nsd-control(8)
fonctionne :
$ doas nsd-control-setup
Maintenant, il faut vérifier votre configuration. Exécutez la commande
suivante sur chacun des serveurs afin de trouver des erreurs de
typographie :
$ doas nsd-checkconf /var/nsd/etc/nsd.conf
Si tout semble bon, vous êtes prêt pour activer et démarrer nsd(8) sur les deux serveurs :
$ doas rcctl enable nsd
$ doas rcctl start nsd
La dernière pièce du puzzle sont les règles pour pf(4) afin d’autoriser
l’accès externe à nsd(8). Ajoutez ces deux lignes à /etc/pf.conf :
pass in on egress proto { tcp udp } from any to egress port domain
pass in on egress proto { tcp udp } from any to egress port domain-s
Vérifiez puis chargez la configuration changée :
$ doas pfctl -nf /etc/pf.conf
$ doas pfctl -f /etc/pf.conf
Remerciements
Avec l’aimable autorisation de Bruno Flückiger !
Cette page est la traduction de la page How to build a name server with DNS over TLS (DoT) du site BSDHowto.ch.
Historique
J’ai écrit historiquement cette traduction sur le wiki de la communauté “OpenBSD Pour Tous”.