Architecture master/slave

Gérer les zones d’un unique DNS n’est pas bien compliqué. Cela demande juste un peu de rigueur afin de ne pas s’embrouiller dans les fichiers de configuration. En revanche quand il faut en gérer plusieurs dizaines ça peut vite devenir un cauchemar.

Logiquement ça voudrait dire qu’il faut modifier toutes les zones de tous les DNS une par une… Vive les erreurs !

Pour simplifier la vie des admin sys, une fonctionnalité existe : le transfert de zone ! L’idée est simple, nous allons modifier notre zone DNS sur un seul serveur (que l’on appellera le master) et nos autres serveurs viendront en copier le contenu (on appellera ces serveurs DNS des serveurs slave)

Donc pour la suite je vais utiliser une VM Ubuntu 18.04 sur laquelle je vais installer BIND9. Cette VM fera office de DNS slave tandis que mon hôte sera le DNS master.

  • Configuration du serveur DNS Master :

Bon la première chose à faire au niveau du master, ça va être d’ajouter un deuxième serveur DNS dans la configuration de notre zone (dans le fichier /var/cache/bind/site1.com.zone). Ce deuxième serveur, ça va tout simplement être notre serveur DNS Slave dont l’IP est 192.168.0.41 :

master1.png

Ensuite dans le fichier /etc/bind/named.conf.local nous allons devoir autoriser les transferts de zone depuis notre serveur master vers noter serveur slave. Pour cela il suffira d’ajouter la directive suivante :

allow-transfer { 192.168.0.41; }; // A modifier suivant l'IP de votre serveur DNS Slave

Vous devriez donc avoir ceci :

master2.png

En effet c’est via le mécanisme du transfert de zone qu’un serveur DNS slave pourra copier le contenu d’une zone DNS afin de mettre à jour sa propre zone.

Voilà, la configuration côté DNS master est finie. Passons à la partie DNS slave.

  • Configuration du serveur DNS Slave :

Côté DNS slave il va falloir ajouter ces lignes dans le fichier /etc/bind/named.conf.local :

zone "site1.com" IN {
    type slave;
    file "site1.com.zone";
    masters { 192.168.0.28; }; // A modifier suivant l'IP de votre serveur DNS Master
}

Puis on va redémarrer le service BIND :

systemctl restart bind9

Si tout c’est bien déroulé, au niveau du serveur DNS slave, le fichier /var/cache/bind/site1.com.zone sera créé et contiendra les mêmes informations que le fichier de zone de notre DNS master. D’ailleurs on pourra aussi vérifier que le transfert de zone se sera bien fait du côté de notre DNS master en affichant les logs contenus dans le fichier /var/log/syslog :

master3.png

Ainsi si on tente de résoudre le nom de domaine site1.com, on obtiendra la même valeur que ce soit du côté du DNS master :

master4.png

Que du côté du serveur DNS slave :

master5.png


Alors effectivement cette fonctionnalité est plutôt sympathique ! En revanche quand elle est mal configurée elle permet à un attaquant d’obtenir la cartographie d’un réseau interne (d’entreprise par exemple).

Imaginez un serveur DNS accessible depuis le réseau Internet responsable de la résolution DNS d’un réseau interne. Si le transfert de zone est possible depuis n’importe quelle IP, alors on pourra récupérer la totalité de la zone DNS et donc cartographier l’entièreté de l’intranet de l’entreprise pour un domaine spécifique : où sont les serveurs mail, les DC, les share etc…

Et ce très facilement puisque nous n’aurons qu’à nous servir de l’utilitaire dig :

dig AXFR @IP_du_serveur_DNS nom_domaine

Voici ce que ça donne en live :

master6.png

C’est pour empêcher ce comportement que nous avons spécifié une IP dans la directive « allow-transfert » dans le fichier /etc/bind/named.conf.local sur notre serveur master !