Outils pour utilisateurs

Outils du site


trad:bsdhowto.ch:externaldns

Comment créer un serveur de noms avec DNS-over-TLS (DoT)

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 domain, fournissant DNS-over-TLS (DOT). Tout ce qui faut pour cette tâche est inclut 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 assurez 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 renouvellé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é renouvellé , 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

Avec l'aimable autorisation de Bruno Flückiger !

Cette page est la traduction de la page https://www.bsdhowto.ch/externaldns.html du site BSDHowto.ch.


trad/bsdhowto.ch/externaldns.txt · Dernière modification: 2020/08/29 17:07 de pengouinpdt