zone "example.com" {
type slave;
masters { 192.168.40.3; }; # IP du DNS principal
file "/var/named/example.com.zone";
};Un DNS secondaire offre redondance et résilience — si le primaire tombe, les requêtes continuent à être résolues. |
L’utilisation d’un DNS secondaire ou d’un serveur proxy DNS dans une DMZ est une pratique courante …
pour renforcer la sécurité et éviter d’exposer directement le serveur DNS principal lié à l’Active Directory (AD).
Le DNS principal lié à l’AD contient des informations sensibles sur l’infrastructure réseau.
En le mettant dans le réseau interne, il reste protégé contre les attaques provenant de la DMZ ou d’Internet.
Si un serveur DNS dans la DMZ est compromis, l’attaquant n’accède pas directement au DNS principal.
Le DNS secondaire ou proxy agit comme un intermédiaire, limitant l’accès aux données sensibles.
Les requêtes externes sont gérées directement par le DNS dans la DMZ, réduisant la charge sur le DNS principal.
Un serveur DNS secondaire est une copie en lecture seule de la base de données DNS principale.
Le serveur secondaire récupère les enregistrements DNS depuis le serveur principal via un transfert de zone (zone transfer).
Il peut répondre aux requêtes DNS sans avoir besoin de consulter le serveur principal.
Configurez un transfert de zone sécurisé entre le DNS principal (dans le réseau interne) et le DNS secondaire (dans la DMZ).
Limitez les transferts de zone à l’adresse IP du DNS secondaire.
Autorisez uniquement les requêtes publiques ou spécifiques à la DMZ.
Le DNS secondaire ne peut pas être modifié depuis l’extérieur.
En cas de panne du DNS principal, il continue de répondre aux requêtes.
Un proxy DNS agit comme un intermédiaire qui relaie les requêtes DNS vers le serveur principal.
Le proxy dans la DMZ reçoit les requêtes et les transmet au serveur DNS principal.
Les réponses sont renvoyées au client via le proxy.
Déployez un serveur DNS (ex. BIND, Unbound) dans la DMZ comme proxy.
Configurez-le pour transférer les requêtes DNS internes au serveur principal.
Filtrez les types de requêtes autorisées (ex. bloquer les requêtes AXFR pour éviter les transferts de zone non autorisés).
Le serveur DNS principal reste caché et inaccessible directement depuis la DMZ.
Vous pouvez appliquer des politiques de filtrage et de cache sur le proxy.
Pour que le DNS secondaire ou proxy puisse fonctionner correctement :
Port 53 (TCP/UDP) : Communication DNS.
Port 953 (si vous utilisez BIND avec RNDC pour le contrôle à distance).
Autorisez uniquement les transferts de zone depuis le DNS principal vers le DNS secondaire.
Limitez l’accès au proxy DNS aux IP spécifiques de la DMZ et d’Internet.
Interdisez toute tentative de communication directe avec le DNS principal depuis la DMZ.
Placez uniquement les enregistrements nécessaires dans le DNS secondaire ou proxy (ex. intranet.example.com, services exposés).
Ne dupliquez pas les informations sensibles liées à l’AD dans le DNS secondaire.
Créez une nouvelle zone pour le transfert.
Type : Zone principale.
Activez le transfert de zone et spécifiez l’IP du DNS secondaire.
Configurez les permissions pour le transfert de zone.
Limitez au serveur DNS secondaire.
Configurez le fichier named.conf pour accepter les transferts de zone :
zone "example.com" {
type slave;
masters { 192.168.40.3; }; # IP du DNS principal
file "/var/named/example.com.zone";
};systemctl restart namedInstallez Unbound dans la DMZ.
Configurez le fichier unbound.conf pour rediriger les requêtes :
forward-zone:
name: "."
forward-addr: 192.168.40.3 # IP du DNS principalsystemctl restart unboundDNSSEC signe les réponses DNS — protection contre le DNS spoofing. À activer sur les zones critiques. |
Voir aussi : DHCP · Routeurs · DMZ · UDP · Active Directory |