MyTnyBx

My Tiny Box

Installer un serveur de cache DNS sur son réseau local

25/02/2009 à 12:14:23 - Aucun commentaire

Vous avez sur votre réseau local une machine allumée en permanence ? Pourquoi ne pas en profiter pour accélérer un petit peu votre navigation sur le net en y installant un serveur de cache DNS ?

Le principe est simple : lors d'une requête DNS, c'est le serveur local qui sera interrogé. S'il ne connaît pas la réponse, il ira interroger un autre serveur DNS (qui lui la connaît, ou connaît un autre serveur qui la connaît), et il mettra le résultat en cache. À la prochaine consultation, le serveur local pourra répondre lui-même, ce qui induira un gain de temps !

À noter cependant qu'il s'agit d'un cache mémoire, et que le cache sera perdu en cas de redémarrage du démon bind.

L'installation

L'installation en elle-même est excessivement simple :

aptitude install bind9

Et voilà, vous avez un serveur DNS qui tourne !

La configuration

Les machines clientes :

Il faut ensuite configurer votre serveur DHCP pour qu'il attribue aux machines clientes les serveurs de noms suivants :

1) En serveur primaire, votre serveur DNS (192.168.0.xx)
2) En serveur secondaire, le serveur DNS de votre FAI.

De cette manière, même si votre serveur DNS tombe en rade, vous pourrez toujours aller sur le net, puisque le serveur DNS de votre FAI prendra le relais.

Le serveur DNS :

Nous avons vu dans précédemment que lorsque notre serveur DNS local ne connaît pas la réponse à une requête DNS, il va interroger un autre serveur DNS. Oui, mais lequel ?

En réalité, en l'absence de configuration explicite, notre serveur DNS local va se comporter comme n'importe quel serveur DNS, il va essayer de résoudre le domaine lui-même, en utilisant le mécanisme en cascade des DNS : interroger un serveur racine, qui va renvoyer vers un serveur de plus bas niveau, qui va renvoyer vers un serveur de plus bas niveau, et ainsi de suite... Un certain nombre de requêtes vont être exécutées.

Il y a mieux à faire : lorsqu'il ne connaît pas la réponse à une requête, nous allons demander à notre serveur local, non pas de résoudre le nom lui-même, mais de demander au serveur DNS de notre FAI, qui lui, dispose d'un large cache lui permettant de répondre plus vite qu'une résolution complète.

C'est l'objet de l'option "forwarders", dans /etc/bind/named.conf.options, on décommente l'option, et on lui ajoute les IP des serveurs DNS de notre FAI :

forwarders {
xxx.xxx.xxx.xxx; // DNS primaire de notre FAI
xxx.xxx.xxx.xxx; // DNS secondaire de notre FAI
};

Si on veut s'assurer que notre serveur DNS s'adresse bien au serveur DNS de notre FAI au lieu de faire la résolution lui-même, on peut utiliser tcpdump :

tcpdump src host ip_dns_local and dst host ip_dns_fai and port 53 and udp

On doit y voir les requêtes de notre serveur vers le serveur du FAI lors de la première demande pour un domaine donné.

Les logs

Pour s'assurer du bon fonctionnement de bind, on peut vouloir activer les logs, dans /etc/bind/named.conf :

channel simple_log {
file "/var/log/named/bind.log" versions 3 size 5m;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};

channel query_log {
file "/var/log/named/query.log" versions 2 size 10m;
print-time yes;
severity info;
};

category default { simple_log; };
category queries { query_log; };

Dans cet exemple, on crée un fichier de log qui contient les requêtes DNS clientes (query.log, qui aura 2 rotations de 10Mo chacune), et un fichier de log qui contient tout le reste (bind.log, qui aura 3 rotations de 5Mo chacune).

Le monitoring

On peut ensuite vouloir surveiller l'activité de son serveur DNS avec Munin. Il existe deux plugins, bind9 et bind9_rndc, disponibles ici : http://munin.projects.linpro.no/browser/trunk/node/node.d

Le premier trace les demandes des clients, et le second la manière dont elles ont été traitées.

Par contre, bind9, contrairement à son prédécesseur bin8, ne gère pas les statistiques par domaine... On ne peut donc pas se faire un top-10 des domaines demandés.

Il serait également être intéressant de pouvoir grapher le ratio "cache hit / cache miss" (le taux de requêtes auxquelles le serveur répond en puisant dans son cache par rapport à celles pour lesquelles il doit interroger un autre serveur DNS) afin de juger du pourcentage de gain sur le réseau, et donc du degré de pertinence de l'usage d'un serveur DNS local.

dns