DNS Configuration · 9 min read · Oct 02, 2025
Serveur DNS tout-en-un avec BIND9
Ce tutoriel vous montre comment configurer le serveur DNS BIND9 pour servir un réseau interne et un réseau externe en même temps avec un ensemble d’informations différent. Pour atteindre cet objectif, une nouvelle fonctionnalité de BIND9 appelée vue est utilisée. En tant que tutoriel, il vous guidera à travers l’ensemble de la configuration, mais une connaissance initiale de BIND et DNS est requise, il existe de nombreux documents qui couvrent ces informations sur Internet.
Continuez à lire sur le site d’origine ou téléchargez le PDF.
Contenu
- 1 Le problème
- 2 Configuration initiale
- 3 Internes et externes
- 4 Sécurité
- 5 Fichiers de configuration - 5.1 /etc/bind/named.conf.local
- 5.2 /etc/bind/externals/db.example.com
- 5.3 /etc/bind/internals/db.example.com
- Bibliographie
1 Le problème
C’est un problème typique dans les organisations en croissance qu’elles doivent résoudre deux problèmes à la fois :
- Avoir un serveur DNS pour le réseau interne de l’entreprise car il y a longtemps, il y avait déjà trop d’ordinateurs à se souvenir de leurs IP 1 et même trop d’ordinateurs pour maintenir un ensemble de fichiers hôtes 2.
- Avoir un serveur DNS pour les serveurs externes, pour les clients externes, etc.
Résoudre ces problèmes devient un plus grand problème lorsque l’organisation en croissance ne peut pas fournir plus de ressources qu’un seul serveur DNS 3. C’est un plus grand problème car si vous configurez simplement votre serveur avec tous vos noms, publics et privés, vous finirez par polluer Internet avec des adresses privées, ce qui est très mauvais, et également montrer au monde une partie de la topologie de votre réseau interne. Quelque chose que vous ne voulez pas qu’un attaquant/cracker potentiel ait.
L’autre partie du problème est qu’en termes d’efficacité, vous voudrez peut-être résoudre des IP internes lorsque vous êtes à l’intérieur et des IP externes lorsque vous êtes à l’extérieur. Ici, je parle d’ordinateurs qui ont des connexions publiques et privées.
Il existe de nombreuses solutions différentes à ce problème et je me souviens l’avoir résolu même avec BIND4, mais maintenant je vais utiliser BIND9 pour faire une solution très propre. Cela a été déployé sur un serveur Debian GNU/Linux 3.1, mais cela devrait également fonctionner pour d’autres systèmes d’exploitation qui exécutent BIND9, assurez-vous simplement de changer vos chemins en conséquence.
2 Configuration initiale
Imaginons que l’organisation pour laquelle je travaille fait des exemples… de quoi ? Je ne sais pas, mais vous pouvez les commander sur example.com. La société Examples a reçu le réseau 192.0.2.0/24 et en interne, nous utilisons 10.0.0.0/24.
Commençons à servir les noms et IP externes, nous éditons /etc/bind/named.conf.local 4 et ajoutons :
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};et ensuite nous créons /etc/bind/db.example.com avec le contenu suivant :
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Nous avons notre serveur de messagerie ailleurs.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Nous nous connectons très souvent à client1.Comme vous pouvez le voir, notre démarrage a un ordinateur pour servir tout, sauf le mail, il gère même le transfert d’IP et quelques bases de données.
Maintenant, une bonne configuration DNS a au moins un serveur secondaire et en fait, certains registraires (où vous enregistrez des noms de domaine) l’imposent. Comme nous n’avons pas un deuxième ordinateur, nous allons sur XName, ouvrons un compte et enregistrons example.com comme secondaire avec 192.0.2.1 comme IP à transférer. Nous devons maintenant laisser l’IP de XName faire le transfert ; nous sommes une petite organisation mais comme nous voulons être une start-up réussie, nous essayons de faire tout aussi intelligemment que possible. Donc, nous utilisons la directive de configuration BIND9 acl pour définir un identifiant qui fait référence aux adresses IP de XName ; au début de /etc/bind/named.conf.local, nous ajoutons :
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};et nous changeons la déclaration de zone en :
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { slaves; };
};Nous aurions pu simplement taper les IP là où nous avons tapé “slaves”.
3 Internes et externes
Maintenant que nous avons une base solide, nous pouvons commencer à penser à servir différents contenus au réseau interne et externe, mais d’abord, nous devons définir ce qui est interne et ce qui est externe.
Dans /etc/bind/named.conf.local, nous ajoutons la définition suivante (en haut ou en dessous de la définition des esclaves) :
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};Si nous avions plus de réseaux internes, nous pourrions simplement les ajouter là. Nous ne définissons pas les externes car tout ce qui n’est pas interne est externe. Vous pouvez, si vous le souhaitez, définir des ensembles d’externes différents si vous souhaitez servir différents contenus à différents segments d’Internet.
Nous allons utiliser une nouvelle fonctionnalité de BIND9 appelée vues. Une vue nous permet de mettre un morceau de configuration à l’intérieur d’une condition qui peut dépendre d’un certain nombre de choses, dans ce cas, nous allons simplement dépendre des internes. Nous remplaçons la déclaration de zone dans /etc/bind/named.conf.local par :
view "internal" {
match-clients { internals; };
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};La directive de configuration match clients nous permet d’afficher conditionnellement cette vue en fonction d’un ensemble d’IP, “any” signifie n’importe quelle IP. Les IP internes seront mises en cache par la vue interne et le reste sera rejeté sur la vue externe. Le monde extérieur ne peut pas voir la vue interne, et cela inclut XName, notre fournisseur DNS secondaire, mais nous avons retiré l’allow-transfer de la vue interne car nous ne voulons pas que quiconque puisse transférer sous aucune circonstance le contenu de la vue interne.
Nous avons également changé le chemin, nous devrons créer le répertoire /etc/bind/externals et /etc/bind/internals et déplacer /etc/bind/db.example.com vers /etc/bind/externals/.
Dans /etc/bind/internals/db.example.com, nous mettons un fichier de zone similaire à celui de l’externe mais contenant les IP internes :
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Génial, nous pouvons maintenant pinger l’ordinateur de notre patron avec
ping boss.example.commais essayer d’atteindre mail.example.com nous décevra, que s’est-il passé ? Il n’y a pas de référence à mail.example.com dans le fichier de zone interne et comme nous sommes dans le réseau interne, nous pouvons résoudre mail.example.com. Bien, copions simplement le contenu du fichier de zone externe dans le fichier de zone interne. Cela fonctionnera.
Mais nous sommes une petite start-up intelligente, nous pouvons faire mieux que de copier-coller chaque modification dans le fichier de zone, de plus, cela est très sujet aux erreurs (vous vous souviendrez toujours de modifier le fichier de zone interne lorsque vous modifiez l’externe, ou oublierez-vous et passerez quelques jours à déboguer des problèmes de réseau ?).
Ce que nous allons faire, c’est inclure le fichier de zone externe dans le fichier interne de cette manière :
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103et voilà ! Trouver la directive $include dans la documentation actuelle était difficile… N’oubliez pas de changer le numéro de série du fichier de zone externe chaque fois que vous changez celui interne, mais ce n’est pas un gros problème, si vous oubliez, rien de grave ne se produira puisque vous n’êtes pas susceptible d’avoir des serveurs de cache à l’intérieur de votre propre petit réseau.
4 Sécurité
Il n’est pas recommandé d’utiliser le même serveur DNS comme principal pour un domaine (dans notre cas example.com) et comme serveur DNS de cache, mais dans notre cas, nous sommes contraints de le faire. Du monde extérieur, 192.0.2.1 est le serveur DNS principal pour example.com, de notre propre réseau interne, 192.0.2.1 (ou son adresse privée, 10.0.0.1) est notre serveur de noms de cache qui doit être configuré comme le serveur de noms à utiliser sur chaque poste de travail que nous avons.
Un des problèmes est que quelqu’un pourrait commencer à utiliser notre serveur de noms de cache depuis l’extérieur, il existe une attaque appelée empoisonnement de cache et de nombreuses autres choses désagréables qui peuvent être faites et sont documentées sur SINS (y compris comment les éviter).
Pour améliorer un peu notre sécurité, nous allons ajouter quelques directives au fichier de configuration :
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};Cela empêchera quiconque sur l’Internet dangereux d’utiliser notre serveur de manière récursive tandis que nous, sur notre propre réseau, pouvons toujours le faire.
5 Fichiers de configuration
5.1 /etc/bind/named.conf.local
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};5.2 /etc/bind/externals/db.example.com
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Nous avons notre serveur de messagerie ailleurs.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Nous nous connectons très souvent à client1.5.3 /etc/bind/internals/db.example.com
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Bibliographie
SINS
Sécuriser un serveur de noms Internet
Notes de bas de page
… IPs
1
Pour moi, deux ordinateurs qualifient déjà trop d’ordinateurs à se souvenir de leurs IPs.
… fichiers
2
Le fichier hôte se trouve sur /etc/hosts et est un simple mappage pour l’ordinateur local des noms aux IP. C’était la première façon de résoudre les noms en IP et il y a longtemps, un grand fichier hôtes central était maintenu, ensuite distribué par FTP ou similaire. Cela a rapidement évolué en un problème qui a été résolu par l’invention de DNS. Essayez de ne pas laisser votre fichier hôtes devenir un problème avant de le transformer en DNS, apprenez des pionniers !
… serveur
3
Ou lorsque vous êtes perfectionniste et croyez que cela devrait être réalisable avec un seul serveur.
…/etc/bind/named.conf.local
4
Cela peut être juste /etc/bind/named.conf dans votre système d’exploitation s’il n’est pas Debian.
Recevez de nouveaux articles dans votre boîte de réception.
Aucun spam. Désabonnez-vous à tout moment.