Introduction
Bind (Berkeley Internet Name Domain) est un logiciel open source qui implémente les protocoles DNS (Domain Name System) pour Internet. C’est le logiciel DNS le plus largement utilisé sur Internet.
La configuration de Bind en tant que serveur DNS privé offre plusieurs avantages :
- Permet de résoudre les noms d’hôtes en adresses IP pour les machines de votre réseau privé sans dépendre d’un serveur DNS externe
- Donne plus de contrôle et de personnalisation sur votre espace de noms DNS privé
- Améliore la sécurité et la confidentialité en évitant les requêtes DNS vers des serveurs externes
- Augmente la fiabilité en réduisant la dépendance vis-à-vis de serveurs DNS externes
Dans ce guide, nous couvrirons les étapes nécessaires pour installer, configurer et paramétrer Bind comme serveur DNS récursif et faisant autorité sur un réseau privé.
Prérequis
Avant de commencer la configuration de Bind, nous devons vérifier que :
- Nous disposons d’un serveur Linux avec une distribution Linux fraîchement installée comme Ubuntu 20.04/22.04, Debian 11 /12, CentOS 7/8, etc.
- La machine Linux doit avoir une adresse IP statique et une connectivité réseau sur le réseau privé.
- Nous avons choisi un nom de domaine à utiliser pour notre réseau privé. Celui-ci constituera le domaine racine dans la configuration de Bind. Par exemple, si nous choisissons
domaineperso.frcomme domaine, notre serveur DNS sera responsable dedomaineperso.fret de tous ses sous-domaines commeserveur1.domaineperso.fr,imprimantes.domaineperso.fr, etc.
Installation de Bind
Bind est disponible dans les dépôts par défaut de la plupart des distributions Linux.
Ubuntu/Debian
Sur Ubuntu ou Debian, installer Bind avec apt :
$ sudo apt update
$ sudo apt install bind9 bind9utilsCela installera Bind 9 et quelques utilitaires comme dig, nslookup, etc.
CentOS/RHEL
Sur CentOS ou RHEL, installer Bind avec yum :
$ sudo yum update
$ sudo yum install bind bind-utilsCela installera également les paquets bind9 et les utilitaires.
Vérification de l’installation
Pour vérifier que Bind est bien installé :
$ dig -vCela doit afficher la version de Bind qui est maintenant installée :
;; BIND version: 9.11.3-1ubuntu1.2-UbuntuCela confirme que Bind est installé et prêt à être configuré.
La suite du guide peut ensuite plonger dans la configuration comme décrit. Faites-moi savoir si vous souhaitez ajouter d’autres détails à la section d’installation !
Configuration de base de Bind
Les principaux fichiers de configuration de Bind sont :
/etc/bind/named.conf– Le fichier de configuration principal Bind qui inclut tous les autres fichiers/etc/bind/named.conf.options– Les options globales pour Bind/etc/bind/named.conf.local– La configuration pour le serveur DNS local lui-même/etc/bind/db.root– Le fichier root hints pointant vers les serveurs DNS racine/var/cache/bind– Le répertoire de travail de Bind avec le cache et autres données
Regardons certaines options clés à configurer dans ces fichiers.
Dans named.conf.options :
options {
directory "/var/cache/bind";
forwarders {
8.8.8.8;
8.8.4.4;
};
allow-query { any; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};Cela définit le répertoire de travail de Bind, configure les serveurs DNS publics de Google comme forwarders pour la résolution de noms de domaine externes, autorise les requêtes depuis n’importe quelle adresse IP, active la validation DNSSEC et écoute sur les adresses IPv4 et IPv6.
Dans named.conf.local, configurez votre zone racine privée et les détails de votre serveur DNS local :
// Définir la zone racine
zone "domaineperso.fr" IN {
type master;
file "/etc/bind/db.domaineperso.fr";
};
// Déclarer le serveur DNS local lui-même
zone "dns1.domaineperso.fr" {
type master;
file "/etc/bind/db.dns1.domaineperso.fr";
};Cela définit domaineperso.fr comme la zone racine configurée en tant que zone principale, ce qui signifie que notre serveur DNS sera le serveur faisant autorité pour ce domaine. Les détails de la zone seront chargés depuis le fichier db.domaineperso.fr.
Nous ajoutons également une déclaration de zone pour le nom de notre serveur DNS local dns1.domaineperso.fr avec ses détails dans le fichier db.dns1.domaineperso.fr.
Configuration de la zone racine
Ensuite, nous devons définir les détails de notre zone racine domaineperso.fr dans le fichier db.domaineperso.fr :
$TTL 604800
@ IN SOA dns1.domaineperso.fr. admin.domaineperso.fr. (
3 ; Numéro de série
604800 ; Actualisation
86400 ; Nouvelle tentative
2419200 ; Expiration
604800 ) ; TTL du cache négatif
;
@ IN NS dns1.domaineperso.fr.
@ IN A 192.168.1.100Cela définit le TTL par défaut, l’enregistrement SOA définissant les propriétés de la zone, notre serveur DNS comme serveur de noms pour domaineperso.fr et son adresse IP.
Pour le serveur DNS local, le fichier db.dns1.domaineperso.fr :
$TTL 604800
@ IN SOA dns1.domaineperso.fr. admin.domaineperso.fr. (
3 ; Numéro de série
604800 ; Actualisation
86400 ; Nouvelle tentative
2419200 ; Expiration
604800 ) ; TTL du cache négatif
;
@ IN NS dns1
@ IN A 192.168.1.100Cela configure les enregistrements SOA et A pour notre serveur DNS local.
Configuration du transfert récursif
Dans un réseau privé, il est possible que le serveur DNS local ne puisse pas résoudre tous les noms d’hôtes en adresses IP par lui-même. Dans ce cas, nous devons configurer le transfert récursif pour envoyer les requêtes DNS externes à des résolveurs DNS publics.
Cela est défini dans named.conf.options plus tôt en utilisant l’instruction forwarders. Ici, nous configurons les serveurs DNS publics de Google 8.8.8.8 et 8.8.4.4 pour gérer les requêtes externes.
Ainsi, si notre serveur DNS reçoit une requête qu’il ne peut pas résoudre à partir de ses zones locales, il la transfèrera de manière récursive aux serveurs DNS externes pour trouver la réponse.
Sécurisation du serveur DNS
Étant donné que le serveur DNS fournit des services réseau cruciaux, nous devons le sécuriser comme n’importe quel autre serveur. Quelques étapes clés :
- Utiliser un compte utilisateur dédié non root pour le processus Bind
- Restreindre l’accès aux fichiers et dossiers de configuration Bind
- Configurer des règles de pare-feu pour n’autoriser que le trafic DNS sur le port 53 pour UDP et TCP
- Activer SELinux ou AppArmor pour une sécurité supplémentaire
- Utiliser TLS pour chiffrer le trafic DNS si nécessaire
- Configurer des mises à jour dynamiques sécurisées avec TSIG si les clients doivent mettre à jour dynamiquement des enregistrements DNS
- Activer la validation DNSSEC pour une sécurité renforcée des données DNS
- Configurer la limitation de débit dans
named.conf.optionspour prévenir les attaques d’amplification DNS
Voici quelques règles de pare-feu pour n’autoriser que le trafic DNS :
# Autoriser les requêtes DNS
$ iptables -A INPUT -p udp --dport 53 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 53 -j ACCEPT
# Autoriser les transferts de zone
$ iptables -A INPUT -p tcp --dport 53 -m state --state ESTABLISHED -j ACCEPT
# Autoriser les réponses
$ iptables -A OUTPUT -p udp --sport 53 -j ACCEPT
$ iptables -A OUTPUT -p tcp --sport 53 -j ACCEPTTester la configuration
Une fois Bind installé et la configuration de base effectuée, nous pouvons démarrer le service et vérifier qu’il fonctionne correctement.
Sur les systèmes Systemd, exécuter :
# systemctl start bind9
# systemctl enable bind9 Sur les systèmes init.d, exécuter :
# service bind9 start
# chkconfig bind9 onVérifier le status avec :
# systemctl status bind9
# service bind9 statusLe service Bind devrait être actif et en cours d’exécution.
Nous pouvons maintenant tester les lookups en utilisant les commandes dig, nslookup ou host :
# dig @192.168.1.100 domaineperso.fr
# nslookup dns1.domaineperso.fr 192.168.1.100
# host google.com 192.168.1.100La première requête doit renvoyer les enregistrements SOA et NS pour domaineperso.fr. La seconde doit afficher l’enregistrement A pour dns1.domaineperso.fr. La dernière est une requête récursive pour google.com qui doit renvoyer l’adresse IP externe après transfert vers le DNS Google.
Si tout fonctionne correctement, votre serveur DNS Bind est configuré de manière appropriée pour la résolution DNS de base et le transfert !
Configuration des zones pour les réseaux locaux
À ce stade, notre serveur DNS ne connaît que la zone racine domaineperso.fr avec les détails du serveur DNS local. Nous devons ajouter davantage de zones pour assurer la résolution de noms sur notre réseau privé.
Supposons que nous avons le réseau 192.168.1.0/24 avec quelques hôtes définis :
192.168.1.100– Notre serveur DNS lui-mêmedns1.domaineperso.fr192.168.1.101– Un serveur web nomméweb1.domaineperso.fr192.168.1.102– Un serveur de base de donnéesdb1.domaineperso.fr192.168.1.103– Un serveur de fichiersfichiers.domaineperso.fr
Nous pouvons ajouter chacun de ces serveurs en tant qu’enregistrement A au sein de la zone domaineperso.fr elle-même dans db.domaineperso.fr :
web1 IN A 192.168.1.101
db1 IN A 192.168.1.102
fichiers IN A 192.168.1.103 Après avoir rechargé le service Bind, nous pouvons maintenant faire des lookups sur ces hôtes pour récupérer leur adresse IP :
# dig @192.168.1.100 web1.domaineperso.fr
# nslookup db1.domaineperso.fr 192.168.1.100
# host fichiers.domaineperso.fr 192.168.1.100Au lieu d’ajouter tous les hôtes dans la zone racine, nous pouvons également configurer une nouvelle zone séparée pour notre réseau interne.
Ajoutez cette définition de zone dans named.conf.local :
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
};Ici, nous définissons une zone de lookup inversé pour les adresses IP sous 192.168.1.0/24 mappées au domaine .arpa.
Le fichier de zone /etc/bind/db.192 :
$TTL 604800
@ IN SOA domaineperso.fr. admin.domaineperso.fr. (
2 ; Numéro de série
604800 ; Actualisation
86400 ; Nouvelle tentative
2419200 ; Expiration
86400 ) ; TTL du cache négatif
;
@ IN NS dns1.
100 IN PTR dns1.domaineperso.fr.
101 IN PTR web1.domaineperso.fr.
102 IN PTR db1.domaineperso.fr.
103 IN PTR fichiers.domaineperso.fr.Cela définit le mapping inverse des adresses IP vers les noms pour les hôtes du réseau 192.168.1.0/24.
Après avoir rechargé Bind, les lookups inversés fonctionneront :
# dig -x 192.168.1.101 @192.168.1.100
# nslookup -query=PTR 192.168.1.102 192.168.1.100
# host 192.168.1.103 192.168.1.100Des fichiers de zone supplémentaires similaires peuvent être ajoutés pour tous les autres sous-réseaux privés et hôtes configurés sur le réseau.
Cela fournit un service DNS local faisant autorité sans dépendre d’aucun serveur DNS externe.
Mises à jour dynamiques de zone
Dans les grands environnements, la maintenance des enregistrements DNS pour une infrastructure changeante peut être difficile. Bind propose deux méthodes pour mettre à jour dynamiquement les zones DNS – DNS dynamique (DDNS) et mises à jour signées DNSSEC.
Avec le DDNS, les clients peuvent mettre à jour directement leurs enregistrements DNS au sein d’une zone en envoyant des requêtes UPDATE spéciales au serveur DNS. C’est plus simple à mettre en place mais non sécurisé.
Les mises à jour signées DNSSEC utilisent des signatures de transaction (TSIG) pour signer cryptographiquement les requêtes de mise à jour. Le serveur DNS n’accepte que les mises à jour avec une signature valide.
Voici un exemple pour activer les mises à jour DDNS pour les clients du sous-réseau 192.168.1.0/24 :
Dans named.conf.local :
zone "domaineperso.fr" {
type master;
allow-update { 192.168.1/24; };
file "/etc/bind/db.domaineperso.fr";
};L’option allow-update active les mises à jour depuis le sous-réseau.
Les machines clientes peuvent utiliser la commande nsupdate pour ajouter, modifier ou supprimer des enregistrements. Par exemple :
# nsupdate
> update add web2.domaineperso.fr 3600 A 192.168.1.105
> sendCela ajoutera un enregistrement A pour web2.domaineperso.fr. Les enregistrements peuvent être supprimés en spécifiant seulement leur nom et valeur TTL.
Pour les mises à jour signées TSIG, le serveur et les clients partagent une clé TSIG commune. La clé peut être générée avec dnssec-keygen. Les clients signent le paquet UPDATE avec la signature TSIG.
Sur le serveur, le named.conf spécifie la clé TSIG et active les mises à jour signées :
key "tsig-key" {
algorithm hmac-sha256;
secret "b3BlbnNlc2FtZTAwMA==";
};
zone "domaineperso.fr" {
type master;
allow-update { key tsig-key; };
...
}Les clients peuvent utiliser la même clé pour signer les requêtes de mise à jour. Cela garantit que seuls les hôtes autorisés peuvent mettre à jour dynamiquement leurs enregistrements DNS.
DNS Split-Horizon
Parfois, les serveurs DNS internes privés peuvent renvoyer des résultats différents des serveurs DNS publics externes pour fournir une configuration de DNS split-horizon.
Par exemple, serveurweb.societe.fr en interne pourrait résoudre vers l’IP privée 192.168.1.101 alors qu’en externe elle résout vers l’IP publique 1.2.3.4.
Nous pouvons réaliser cela avec Bind en définissant la zone societe.fr à la fois comme une zone directe pour les adresses IP publiques et comme une zone inverse séparée pour les adresses IP internes.
Dans named.conf.local :
// Zone directe
zone "societe.fr" {
type master;
file "/etc/bind/db.societe.fr.public";
}
// Zone inverse
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.societe.fr.prive";
}Cela permet de définir différents enregistrements A pour serveurweb.societe.fr dans les fichiers de zone publique et privée. Le serveur BIND peut être configuré pour écouter sur différentes interfaces réseau afin de servir les bonnes données.
Le DNS split-horizon est utile pour la sécurité, l’isolation et le contrôle de politique entre les données DNS publiques et privées.
Caching et pré-chargement
L’activation du cache et du pré-chargement sur le serveur DNS peut améliorer les performances. Par défaut, Bind met en cache les résultats des requêtes pour une meilleure vitesse de résolution.
Nous pouvons régler les valeurs de TTL du cache dans named.conf.options :
dnssec-validation auto;
recursion yes;
cache-size 500m;
cache-file "/var/cache/bind/db.cache";
prefetch 2;
prefetch-key no-edns;
dnssec-accept-expired yes;
max-cache-ttl 600; # 10 minutes
max-ncache-ttl 90; # 1.5 minutesCela active la mise en cache jusqu’à 500 Mo de données sur le disque, définit le niveau de pré-chargement, les limites de TTL du cache et autorise l’utilisation d’enregistrements expirés pendant l’actualisation des données DNSSEC.
Le pré-chargement améliore la résolution pour les domaines frères en interrogeant de manière proactive les enregistrements dépendants.
Journalisation et surveillance
Comme pour tout serveur, le serveur DNS doit être étroitement surveillé. Bind fournit de bonnes capacités de journalisation qui peuvent être envoyées à un serveur de logs centralisé.
Dans named.conf.options :
logging {
channel query_log {
file "/var/log/query.log" versions 3 size 20m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category queries { query_log; };
};Les mesures clés à surveiller sont :
- Taux de requêtes et temps de réponse
- Utilisation et taux de hits du cache
- Erreurs de validation DNSSEC
- Échecs de mises à jour ou transferts de zone
- Événements de limitation de débit ou violations d’accès
- Erreurs réseau et timeouts
L’intégration du serveur DNS à un système de surveillance fournit une visibilité importante sur les opérations et les performances DNS.
Test et validation
Une fois le serveur DNS configuré et déployé, nous devons le tester en profondeur pour détecter tout problème :
- Utiliser des outils de lookup DNS comme
dig,nslookupethostpour tester différentes recherches d’enregistrements - Effectuer des lookups inversés pour confirmer que les enregistrements PTR sont correctement définis
- Vérifier que les transferts de zone fonctionnent de manière sécurisée pour les serveurs secondaires
- Tester les mises à jour dynamiques en ajoutant/supprimant des enregistrements avec
nsupdate - Vérifier que les configurations split-horizon renvoient les bons résultats internes et externes
- Confirmer que la validation DNSSEC fonctionne pour les zones signées
- Faire des tests de charge du serveur DNS avec des outils comme
dnsperfetnamebench - Vérifier les logs et la surveillance pendant les tests pour détecter toute erreur
- Scanner la présence de problèmes de sécurité comme des versions de logiciels vulnérables, la solidité du chiffrement
- Réaliser un test d’intrusion pour identifier et corriger les vulnérabilités
Des tests et une validation approfondis du serveur DNS réduisent les risques et augmentent la confiance dans la disponibilité, les performances, la sécurité et la fiabilité de l’infrastructure DNS.
Résumé
Dans ce guide détaillé, nous avons vu comment installer, configurer et paramétrer Bind 9 comme serveur DNS local pour les réseaux privés.
Nous avons installé les packages Bind, configuré les fichiers de base named.conf, mis en place le transfert, les listes de contrôle d’accès et d’autres options. Nous avons ajouté des zones de lookup directes et inverses pour les domaines et hôtes du réseau interne. Les mises à jour dynamiques, le DNS Split-Horizon, le cache, la journalisation et la surveillance ont également été configurés.
Le déploiement de Bind en tant que serveur DNS local fournit des services de nommage centralisés pour votre environnement privé. Il offre un plus grand contrôle, personnalisation, confidentialité, sécurité et autonomie de votre infrastructure DNS privée par rapport à la dépendance unique vis-à-vis de fournisseurs externes.
Bien sûr, une sécurité renforcée, une surveillance solide, des tests, de la redondance et une maintenance appropriée sont nécessaires pour maintenir vos services DNS opérationnels de manière fiable. Mais avec ses configurations flexibles, Bind peut répondre aux besoins en DNS local même des grands réseaux privés et des déploiements sur mesure.
Français
English
العربية
Webhi.Technology
@WebHiTechnology