titre informatique

Serveur DNS avec BIND

Détails
Catégorie : Services réseau

Le service DNS permet d'associer un nom de domaine avec une adresse IP. Les serveurs DNS fonctionnement en majorité avec BIND (Berkeley Internet Name Daemon), développé actuellement par l'ISC (Internet Systems Consorium) et tournant sur les systèmes Linux. Cet article présente la configuration d'un serveur BIND 9 sur une distribution Ubuntu Server :

  • Définition de zone de recherche directe et de recherche inversée ;
  • Redirection DNS ;
  • Serveur primaire et secondaire ;
  • Délégation de zone ;
  • DNSSEC ;
  • DNS over TLS et DNS over HTTPS

 

Configuration de base

Installation de BIND

Trois paquets sont nécessaires pour faire fonctionner BIND sur une machine Linux et tester son fonctionnement :

  • bind9
  • bind9utils
  • bind9-doc
Interface d'écoute des requêtes DNS

Il est préférable d'indiquer au serveur quelle interface doit écouter les requêtes DNS. Cela se configure grace à l'instruction listen-on-v6 du fichier /etc/bind/named.conf.options où vous indiquez le nom de l'interface recevant les requêtes DNS (à la place de any, qui permet d'écouter les requêtes DNS sur toutes les interfaces du serveur).

Définition des zones DNS

Les zones gérées par le serveur sont définies dans le fichier /etc/bind/named.conf.local selon le modèle suivant :

Zone de recherche directe Zone de recherche inversée
zone "domaine.tld" {
  type master;
  file "fichier";
};		 zone "X.X.X.X.in-addr.arpa" {
  type master;
  notify no;
  file "fichier";
};
domaine.tld : nom de la zone X.X.X.X.in-addr.arpa : domaine de recherche inverse
Remarque : on ne précise que le netid du réseau IP avant le domaine in-addr.arpa, et à l'envers
fichier : chemin absolu du fichier de configuration de la zone
Fichier de zone de recherche directe
Syntaxe du fichier de zone de recherche directe
$TTL 60480
@        IN SOA serveur.domaine.tld. admin.domaine.tld (A B C D E)
@        IN NS  serveur
serveur  IN A   X.X.X.X
machine1 IN A   Y.Y.Y.Y
  • serveur.domaine.tld (ou serveur) : serveur primaire de la zone
  • admin.domaine.tld : courriel de l'administrateur de la zone (avec un point remplaçant l'arobase)
  • A : numéro de série du fichier de zone
  • B : délais en seconde entre chaque mise à jour du fichier de zone depuis les serveurs secondaires
  • C : délais en seconde d'attente avant une nouvelle tentative de mise à jour du fichier zone depuis les serveurs seconadires, en cas d'échec de la mise à jour précédente
  • D : délais en seconde au terme duquel la zone est considérée comme invalide si le serveur secondaire ne peut joindre le serveur primaire
  • E : durée de vie en seconde des réponses en cache
  • X.X.X.X : adresse IP du serveur primaire de la zone
  • Y.Y.Y.Y : adresse IP de machine1.domaine.tld

Evidemment, vous pouvez ajouter autant d'enregistrements (A, CNAME, MX, etc) à la suite de votre fichier de zone

Fichier de zone de recherche inversée
Syntaxe du fichier de zone de recherche inversée
$TTL 60480
@        IN SOA serveur.domaine.tld. admin.domaine.tld (A B C D E)
@        IN NS  serveur
serveur  IN A   X.X.X.X
X        IN PTR serveur
Y        IN PTR machine1
  • serveur.domaine.tld (ou serveur) : serveur primaire de la zone
  • admin.domaine.tld : courriel de l'administrateur de la zone (avec un point remplaçant l'arobase)
  • A : numéro de série du fichier de zone
  • B : délais en seconde entre chaque mise à jour du fichier de zone depuis les serveurs secondaires
  • C : délais en seconde d'attente avant une nouvelle tentative de mise à jour du fichier zone depuis les serveurs seconadires, en cas d'échec de la mise à jour précédente
  • D : délais en seconde au terme duquel la zone est considérée comme invalide si le serveur secondaire ne peut joindre le serveur primaire
  • E : durée de vie en seconde des réponses en cache
  • X.X.X.X : adresse IP du serveur primaire de la zone
  • X : hostid de l'adresse IP du serveur primaire de la zone
  • Y : hostid de l'adresse IP de machine1.domaine.tld
Vérification du fichier de zone

Un fichier de zone peut être vérifier avec la commande named-checkzone suivi du nom du domaine et du nom du fichier.

Exemple pour le domaine domaine.tld dont la zone a été définie dans le fichier /etc/bind/domaine.tld : named-checkzone domaine.tld /etc/bind/domaine.tld

 

Redirection

Afin de permettre au serveur BIND d'interroger d'autres serveurs pour répondre aux requêtes concernant des zones sur lesquelles il n'est pas autoritaire, il faut activer la redirection en précisant les serveurs à interroger :

  • Ouvrir le fichier /etc/bind/named.conf.options ;
  • Décommenter les lignes correspondant à la section forwarders ;
  • Ajouter l'adresse IP du serveur DNS à interroger ;
  • Toujours la section option, ajouter les instructions allow-recursion { any; }; et allow-query-cache { any; }; (si vous souhaitez limiter les machines clientes, remplacer any par les adresses des machines) ;
  • Si vous n'avez pas de vérifications avec DNSSec, passer la valeur de l'instruction dnssec-validation (par défaut à auto) à no.

 

Serveur primaire et serveur secondaire

Un serveur secondaire récupère une copie du fichier de zone d'un serveur DNS (appelé du coup serveur primaire). Il peut être ensuite interroger par des clients afin de répondre aux requêtes DNS de la zone (lors de la mise en place d'un service de répartition de charge ou de tolérance aux pannes).

Préparation du serveur primaire

Afin d'autoriser un serveur secondaire à récupérer les données d'une zone d'un serveur DNS primaire, il faut ajouter l'instruction allow-transfer { X.X.X.X; }; (en remplaçant X.X.X.X par l'adresse IP du serveur secondaire) dans la déclaration de la zone (fichier /etc/bind/named.conf.local).

Configuration du serveur secondaire

La déclaration d'une zone secondaire sur un serveur BIND se fait dans le fichier /etc/bind/named.conf.local, comme pour une zone primaire :

Zone secondaire
zone "domaine.tld" {
  type slave;
  masters { X.X.X.X; };
  file "/var/lib/bind/fichier";
};		 domaine.tld : nom de la zone
X.X.X.X : adresse IP du serveur primaire
fichier : fichier où est enregistré le fichier de la zone

 Remarque : le fichier de de la zone secondaire doit se trouver dans un répertoire où le démon de Bind possède les droits d'écriture, comme /var/lib/bind.

 

Délégation de zone

La délégation de zone permet de déléguer la gestion d'un sous-domaine d'une zone à un autre serveur.

Configuration du serveur autoritaire de la zone

Dans le fichier de la zone principale, ajouter un enregistrement NS indiquant qu'un sous-domaine de la zone est géré par un serveur particulier (ne pas oublier l'enregistrement A associé à ce serveur) :

sous-domaine.domaine.tld.           IN NS  serveur.sous-domaine.domaine.tld.
serveur.sous-domaine.domaine.tld.   IN A   X.X.X.X
sous-domaine.domaine.tld. : domaine délégué
serveur.sous-domaine.domaine.tld. : nom du serveur gérant le domaine délégué
X.X.X.X : adresse IP du serveur gérant le domaine délégué

Remarque : n'oubliez pas le point après les noms du domaine délégué et du serveur autoriatire sur ce domaine indiquant que ce sont les noms complets (FQDN), donc à partir de la racine DNS.

Configuration du serveur délégué

Sur le serveur gérant la zone déléguée, il n'y a plus qu'à configurer le service DNS, définir la zone déléguée et créer le fichier de cette zone comme n'importe quelle zone DNS.

 

DNSSEC

Présentation

DNSSEC est un protocole permettant d'améliorer la sécurité des échanges DNS. Il permet d'ajouter des signatures aux enregistrements DNS afin de valider les associations entre nom de domaine et adresse IP (ce qui permet de lutter contre les usurpations DNS ou l'empoisonnement du cache DNS).

DNSSEC utilise de plus le principe de la chaîne de confiance : une zone DNS transmet sa signature au serveur de sa zone parente. Ainsi, les serveurs autoritaires peuvent valider la zone suivante lors des requêtes récursives effectuées par les serveurs résolveurs, empêchant un serveur pirate de prendre sa place.

Mise en place d'une zone validée par DNSSEC

Une zone validée par DNSSEC peut être déclarée ainsi :

Fichier /etc/bind/named.conf.local
zone "domaine.tld" {
  type master;
  file "/var/lib/bind/fichier";
  dnssec-policy default;
  inline-signing yes;
};		 type master : serveur autoritaire principal
domaine.tld : nom de la zone
fichier : fichier où est enregistré le fichier de la zone
dnssec-policy default : DNSSEC géré par la politique par défaut de BIND
inline-signing yes : zone signée dans un nouveau fichier

Les fichiers des clés et signatures sont gérées automatiquement avec la politique par défaut et créés dans le répertoire /var/cache/bind.

Création de la chaîne de confiance

Afin de créer la chaîne de confiance, la zone validée par DNSSEC doit transmettre un enregistrement DS ou DNSKEY au serveur autoritaire de sa zone parente.

Un enregistrement DS se créé avec la commande dnssec-dsfromkey suivie du fichier contenant la clé publique de la zone (fichier .key généré par BIND).

Un enregistrement DNSKEY n'a pas besoin d'être créé, il se trouve directement dans le fichier contenant la clé publique de la zone.

Cas d'une zone privée

Dans le cas d'une zone privée, il n'est pas toujours possible de transmettre un enregistrement DS ou DNSKEY à un serveur parent de la zone. Afin qu'un serveur résolveur accepte les réponses d'un serveur autoritaire d'une zone signée, il faut ajouter les instructions suivantes dans la configuration BIND du serveur résolveur (avant le bloc d'instructions options, dans le fichier /etc/bind/named.conf.options) :

trust-anchors {
  domaine.tld. static-key 257 3 13 "...";
}

La valeur dans le bloc trust-anchors est construite à partir de l'enregistrement DNSKEY se trouvant dans le fichier de la clé publique de la zone :

  • En remplaçant 3600 IN DNSKEY par static-key ;
  • En mettant entre guillemets la valeur de la clé (les caractères se trouvant après le 13 et jusqu'à la fin de la ligne) ;
  • En mettant un point virgule à la fin de la ligne.

 

DNS over TLS et DNS over HTTPS

Présentation

DNS over TLS (DoT) et DNS over HTTPS (DoH) permettant de chiffrer les requêtes DNS entre un client et un serveur résolveur afin d'éviter l'interception de ces requêtes par un attaquant. Ces deux standards utilisent la bibliothèque TLS pour chiffrer les requêtes, DoT utilisant le port 853 pour les échanges tandis que DoH utilise le port 443.

Certificats de chiffrement

Un serveur DNS a besoin d'un certificat et d'une clé privée pour chiffrer les requêtes DNS avec DoT et DoH.

Pour un serveur DNS privé (zone non déclarée dans l'arborescence DNS d'Internet), il est possible de créer la clé et le certificat avec la commande openssl (par exemple : openssl req -x509 -newkey rsa:4096 -keyout cle.pem -out certificat.pem -sha256 -days 365).

Pour un serveur DNS public (zone déclarée dans l'arborescence DNS d'Internet), il est possible de passer par Let's Encrypt et son outil en ligne de commande Certbot (par exemple : certbot certonly --standalone --preferred-challenges http --agree-tos --email Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. -d serveur.domaine.tld).

Configuration du service BIND

Afin de configurer DoT ou DoH sur un serveur résolveur, il faut déjà indiquer les fichiers de la clé et du certificat dans le fichier /etc/bind/named.options, avant le bloc options, avec un bloc tls :

tls local-tls {
   key-file "/chemin/vers/la/cle-privee.pem";
   cert-file "/chemin/vers/le/certificat.pem";
};

L'instruction listen-on doit être ensuite insérée dans le bloc options du même fichier :

  • Pour DoT : listen-on port 853 tls local-tls { any; };
  • Pour DoH : listen-on port 443 tls local-tls http default {any;};

Si vous utilisez IPv6, utilisez l'instruction listen-on-v6 avec les mêmes paramètres.

 

Liens