BIND cache DNS

DNS BIND 1^re partie : serveur "cache DNS"

DNS BIND 1^re partie : serveur "cache DNS"

Par Serge

---

Pour cette rubrique, des connaissances sur TCP/IP sont nécessaires, ainsi qu'un minimum de savoir-faire sur la configuration des paramètres TCP/IP d'une machine Linux/Unix (bien que j'essaye d'expliquer au maximum toutes les étapes).

Introduction

Qu'est-ce donc qu'un serveur DNS?

C'est tout simplement ce qui sert à convertir des adresses noms en adresses IP. Par exemple, quand vous tapez dans votre navigateur préféré l'adresse :
http://lea-linux.org
celui-ci va tout d'abord faire une requête à un serveur DNS (généralement le serveur DNS que vous avez configuré pour votre connexion à l'Internet, donc les serveurs DNS de votre fournisseur d'accès) en lui demandant :
C'est quoi l'adresse IP de lea-linux.org ?
Et le serveur DNS lui donne l'adresse IP et le navigateur va alors se connecter à cette adresse IP et afficher le site.
Ceci est valable pour toute autre application qui manipule des noms DNS (ftp, telnet, mail...)

Dans quel cas installer un serveur DNS qui fait cache?

Tout d'abord, il faut savoir que l'on peut remplir à la main un fichier, qui s'appelle /etc/hosts, avec les correspondances « adresse IP et nom DNS des machines ». Donc si l'on a un petit réseau local de quelques machines, on peut remplir ce fichier à la main. Mais dans le cas d'un réseau beaucoup plus conséquent, il vaut mieux installer un serveur DNS.
Là où un serveur DNS peut être utile aussi, c'est si vous partagez une connexion internet sur votre réseau local. Vous installez sur la machine qui partage la connexion internet un serveur DNS qui fait cache. De ce fait, toutes les machines qui vont se connecter via ce serveur à l'internet vont demander la résolution d'adresse à votre serveur en interne plutôt qu'aux serveurs DNS externes, ce qui va permettre de réduire le traffic réseau sortant. Bon, en fait pour les premières connexions cela ne va servir à rien, car comme votre serveur DNS sera presque vide, celui-ci va demander aux serveurs externes les réponses afin de remplir sa base DNS. Mais comme votre serveur va stocker les réponses, au bout d'un moment, cela va accélérer les réponses DNS, car c'est votre serveur local et non pas les serveurs externes qui vont répondre à ces requêtes DNS.
Même dans le cas où vous n'avez qu'une machine « poste de travail » sous linux et que vous vous connectez très souvent à l'internet, le fait d'installer là aussi un serveur DNS sur votre poste va accélérer votre connexion, ce qui est assez agréable, surtout si vous êtes en RTC (connexion via le téléphone). De plus, mon FAI avait fréquemment des problèmes de serveurs DNS, ce qui m'empêchait régulièrement d'atteindre certains sites, alors je me suis décidé à installer un serveur DNS qui fait cache des serveurs DNS de référence de l'internet. Depuis je n'ai plus aucun probléme.

Pré-requis

Bon, avant de configurer le tout, il faut vérifier que vous avez sur votre machine ce qu'il faut pour faire votre serveur DNS, c'est-à-dire le package bind. Vérifiez donc que ce package est installé sur la machine qui va faire serveur DNS, dans le cas d'une Mandrake ou Red Hat, vérifiez avec un utilitaire pour les RPM, dans le cas d'une Slackware, vérifiez avec pkgtool, ou dans tous les cas rechercher un fichier nommer named qui se trouve dans la plupart des cas dans /usr/sbin/named. Si vous ne trouvez pas de paquet Bind ou si vous ne trouvez aucun fichier named, installez alors le paquet Bind, qui doit sûrement se trouver sur le CD d'installation de votre distribution.

Théorie : fonctionnement du service DNS.

Pour comprendre la configuration d'un serveur DNS, un minimum de théorie sur le fonctionnement de celui-ci est nécessaire. Tout d'abord, il faut savoir que les noms DNS sont organisés de façon hiérarchique. Le haut de la hiérarchie est le root (la racine), désigné par « . » (un point), puis viennent les Top Level Domains (TLD) que vous connaissez : .com, .net, .fr, .org... En fait, quand un nom est recherché, par exemple lea-linux.org, la question est posée dans l'ordre hiérarchique, tout d'abord on demande à un serveur racine (un serveur connu sur internet et déclaré comme étant un serveur racine) la liste des serveurs pouvant répondre au TLD « .org », puis on descend d'une hiérarchie et on recommence. Donc à partir de la liste de serveurs obtenue, on demande ceux qui répondent à « lea-linux.org », puis de même pour lea-linux.org. C'est en gros le fonctionnement du service DNS.

Un serveur DNS qui fait cache

Le fichier /etc/named

On va voir ici une première configuration possible, un serveur DNS qui fait cache. Vous avez besoin de ce type de serveur si votre serveur DNS ne vous sert que pour accélérer votre connexion internet (très utile si vous étes connecté via un modem RTC), ou si vous partagez une connexion internet via votre machine.

Tout d'abord, éditons le fichier /etc/named.conf (créez ce fichier s'il n'existe pas) :

// Fichier /etc/named.conf

// pour serveur DNS cache
options {
		// Répertoire des fichiers de configuration

		directory "/var/named";

		// Si vous traversez un firewall
		// et que vous avez des problèmes DNS
		// décommentez la ligne ci-dessous

		// query-source port 53;

                version "SECRET";
                //permet de masquer la version de Bind - voir précisions ci-dessous
	};

controls {
          inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
	  };

key "rndc_key" {
	          algorithm hmac-md5;
        	  secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
	       };

//Zone racine (root)

zone "."
		{ 
		type hint; 
		file "root"; 
		};
//Zone locale

zone "0.0.127.in-adr.arpa" 
		{
		type master;
		file "zone/127.0.0";

};

Explication de ce fichier

Toutes les lignes qui débutent par "//" sont des lignes de commentaires, elles ne sont là que pour documenter le fichier.

La ligne "directory" indique à named où il doit trouver tous ses fichiers de configurations. Tous les autres fichiers auront donc un chemin relatif à celui-ci.

On a ensuite la déclaration de la zone ".", la zone racine (root en anglais), avec son fichier de description que l'on va voir plus bas. Ensuite, on a la zone qui peut vous paraître bizarre, la zone "0.0.127.in-adr.arpa". En fait la zone "in.adr.arpa" est une zone "spéciale" qui nous permet de faire des recherches inverses, c'est-à-dire trouver le nom d'une machine à partir de son adresse IP cette fois-ci. Ce fonctionnement est identique à celui qui permet de trouver les noms. Pour trouver une machine d'adresse IP 192.168.1.1 par exemple, la requête va être de trouver en premier in-adr.arpa (en quelque sorte le root) , puis 192.in-adr.arpa, puis 168.192.in-adr.arpa, etc... En fait, dans notre fichier, on déclare ici la zone de recherche inverse sur le domaine 127.0.0 qui est la zone de notre domaine local (rappelez-vous que les adresses IP 127.0.0.x sont des adresses IP spéciales, 127.0.0.1 est l'adresse de loopback d'une machine), ce fichier est détaillé aussi plus bas.

version "SECRET"; : permet de masquer la version de Bind utilisée et de limiter ainsi l'exploitation de failles de sécurité.

Exemple :

[root admin]# dig @digital-connexion.info version.bind txt chaos

; <<>> DiG X.x <<>> @digital-connexion.info version.bind txt chaos 
; (1 server found)
 ;; res options: init recurs defnam dnsrch
 ;; got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 ;; QUERY SECTION:
 ;; version.bind, type = TXT, class = CHAOS

;; ANSWER SECTION:
 VERSION.BIND. 0S CHAOS TXT "SECURED"

;; Total query time: 1 msec
 ;; FROM: ns1.cfdpublications.com to SERVER: digital-connexion.info 213.186.35.124
 ;; WHEN: Sun Mar 2 20:12:56 2003

 ;; MSG SIZE sent: 30 rcvd: 62

Les fichiers de zones

Comme nous avons vu au-dessus, il nous faut d'autres fichiers, qui sont /var/named/root et /var/named/zone/127.0.0

/var/named/root :

 ; Fichier de zone des serveurs root

; A vérifier et à maintenir réguliérement

.		6D IN NS	A.ROOT-SERVERS.NET.
.		6D IN NS	B.ROOT-SERVERS.NET.
.		6D IN NS	C.ROOT.SERVERS.NET.
.		6D IN NS	D.ROOT-SERVERS.NET.
.		6D IN NS	E.ROOT-SERVERS.NET.
.		6D IN NS	F.ROOT.SERVERS.NET.
.		6D IN NS	G.ROOT-SERVERS.NET.
.		6D IN NS	H.ROOT-SERVERS.NET.
.		6D IN NS	I.ROOT.SERVERS.NET.
.		6D IN NS	J.ROOT-SERVERS.NET.
.		6D IN NS	K.ROOT-SERVERS.NET.
.		6D IN NS	L.ROOT.SERVERS.NET.
.		6D IN NS	M.ROOT.SERVERS.NET.

A.ROOT-SERVERS.NET.	5w6d16h	IN	A	198.41.0.4
B.ROOT-SERVERS.NET.	5w6d16h	IN	A	128.9.0.107
C.ROOT-SERVERS.NET.	5w6d16h	IN	A	192.33.4.12
D.ROOT-SERVERS.NET.	5w6d16h	IN	A	128.8.10.90
E.ROOT-SERVERS.NET.	5w6d16h	IN	A	192.203.230.10
F.ROOT-SERVERS.NET.	5w6d16h	IN	A	192.5.5.241
G.ROOT-SERVERS.NET.	5w6d16h	IN	A	192.112.36.4
H.ROOT-SERVERS.NET.	5w6d16h	IN	A	128.63.2.53
I.ROOT-SERVERS.NET.	5w6d16h	IN	A	192.36.148.17
J.ROOT-SERVERS.NET.	5w6d16h	IN	A	198.41.0.10
K.ROOT-SERVERS.NET.	5w6d16h	IN	A	193.0.14.129
L.ROOT-SERVERS.NET.	5w6d16h	IN	A	198.32.64.12
M.ROOT-SERVERS.NET.	5w6d16h	IN	A	202.12.27.33	

Comme décrit précédemment, ce fichier contient la liste des serveurs DNS root (racine).

/var/named/zone/127.0.0 :

$TTL 3D

@	IN	SOA		nom_machine.votre_domaine.votre_TLD. (
				1	; Serial
				8H	; Refresh
				2H	; Retry
				1W  ; Expire
				1D)	; Minimum TTL
		NS		nom_machine.votre_domaine.votre_TLD.
1		PTR		localhost.

Remplacez bien sûr "nom_machine.votre_domaine.votre_TLD" par les valeurs réelles de votre machine (par exemple azizlinux.icebox.org). Les "." après les noms de domaines ne sont pas une erreur et doivent être présents. J'insiste bien sur ce fait, car l'erreur typique du débutant et de ne pas mettre le "." (j'avoue que ça m'arrive encore parfois...).

Configuration de l'utilitaire de controle rndc

Si vous regardez à nouveau le fichier named.conf que l'on a fait précédemment, vous avez vu deux sections appelées "controls" et "key". Ces deux directives permettent le contrôle de votre serveur de nom via le programme "rndc". La ligne "controls" définit les adresses IP des machines autorisées à contrôler le serveur de nom (dans notre exemple il s'agit de la machine 127.0.0.1), et la ligne "keys" définit un couple algorithme/clef qui est en fait une sorte de mot de passe pour autoriser là aussi le contrôle à distance. Pour que la machine puisse alors s'identifier, il faut qu'elle envoie ce mot de passe. Pour cela, il faut créer un fichier /etc/rndc.conf contenant la clef :

/etc/rndc.conf :

key rndc_key {

      algorithm "hmac-md5";
      secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
  };

  options {
      default-server localhost;
      default-key    rndc_key;

};

Faites bien attention à ce que les informations entres les fichiers named.conf et rncd.conf soient cohérents, c'est à dire que "algorithm", "secret", "default-key" aient exactement les mêmes valeurs, autrement l'identification entre le serveur et rndc échouera.
Pour la valeur de "default-server" dans le fichier rndc.conf, vous mettez là l'adresse ou le nom de la machine que vous voulez contrôler à distance (dans notre exemple c'est la même machine).
Changez au moins la valeur de la key que je donne ici, elle est issue du fichier exemple de Bind, c'est à dire que tout le monde possède cette clef par défaut, donc si vous ne voulez pas que quelqu'un contrôle votre serveur à votre insu, modifiez la!

rndc permet de stopper, démarrer, recharger la configuration du serveur Bind à distance. Voir la documentation de rndc, ou les autres parties de ce document.

Configuration des fichiers systèmes

Bon maintenant que votre DNS est configuré en tant que serveur cache, il reste encore deux fichiers systèmes à configurer pour indiquer à notre machine que nous avons un serveur DNS et que nous pouvons nous en servir. Commençons par /etc/resolv.conf :

search  votre_domaine.votre_TLD

nameserver 127.0.0.1

Remplacez votre_domaine.votre_TLD par les valeurs de votre machine bien sûr (par exemple icebox.org). Ne pas mettre que votre TLD sans spécifier le domaine.
En fait, à quoi sert ce fichier ? Lorsqu'une application va lancer une requête DNS, elle ne fait pas appel directement à votre serveur DNS mais au "résolveur". Celui-ci lit ce fichier et regarde la ligne search pour savoir dans quel domaine chercher en premier. Cela peut paraître stupide, mais quand vous lancez une requête sur "www.netscape.com", via le résolveur vous allez chercher en premier "www.netscape.com.votre_domaine.votre_TLD". Pourquoi ? me demanderez-vous. Tout simplement parce que les personnes qui ont inventé cela pensaient que la plupart des requêtes de noms seraient en interne sur un réseau et rarement vers l'extérieur, donc par défaut, il cherche en premier dans votre nom de domaine.
La ligne nameserver indique l'adresse à laquelle on peut contacter un serveur de nom.

Aussi bien pour search que pour nameserver, on peut spécifier plusieurs entrées de cette façon :

search domaine1.tld1 domaine2.tld2 (...)

nameserver adresse1
nameserver adresse2
nameserver adresse3

(...)

Attention tout de même à ne pas surcharger en nombre d'entrées dans la ligne search car cela va prendre du temps à chercher dans tous les domaines spécifiés. Différentes entrées sur cette ligne ne servent que si vous êtes sur un réseau local avec plusieurs noms de domaines et que vous avez l'habitude d'appeler les machines juste par leurs noms d'hôte. Dans le cas d'une machine reliée au net, mettre juste le nom de domaine de votre machine et rien de plus.

Il reste encore un fichier à configurer, le fichier /etc/host.conf, éditez ce fichier et vérifiez que la première ligne de ce fichier comporte :

order hosts,bind

Cette ligne oblige le résolveur à regarder en premier les entrées du fichier /etc/hosts puis de faire appel au serveur de nom qui est spécifié dans /etc/resolv.conf.

Test de la configuration

Nous allons tester maintenant que la configuration fonctionne. Lancez votre connexion à l'internet. Vérifiez que le serveur DNS n'est pas déjà démarré par un :

ps -aux | grep named

Si la seule ligne que vous renvoie cette commande est "grep named", c'est que named n'est pas lancé. Sinon relevez le numéro de PID de named et killez-le (kill numéro_du_PID). Relancez ou lancez named par la commande :

/usr/sbin/ndc start

(remplacez /usr/sbin par le répertoire où ndc est installé, si vous ne le trouvez pas, lancez alors named par la commande "named&" ).

Exécutez alors la commande "nslookup" et vous devriez voir apparaître :

olio@azizlinux:~$ nslookup
Default Server:  localhost

Address: 127.0.0.1

Ceci veut dire que tout marche bien, du moins que le serveur named est lancé et est prêt à répondre aux requêtes DNS (allez voir plus bas si ce que vous obtenez n'est pas la même chose que ce qui est affiché ci-dessus).

On va tester que le cache marche vraiment en tapant maintenant:

> lea-linux.org

Server: localhost
Address: 127.0.0.1
Name: lea-linux.org
Address: 212.73.209.252

> lea-linux.org
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
Name:    lea-linux.org
Address:  212.73.209.252

>

La ligne "Non-authoritative answer" signale justement que l'information a été récupérée via le cache du serveur DNS, et nous avertit donc que cette adresse peut être fausse si l'adresse a changé depuis, ce qui est très improbable. Quittez alors l'utilitaire nslookup par "exit".
Voilà, votre serveur "DNS cache" est opérationnel. Il ne vous reste qu'à ajouter le "/usr/sbin/ndc start" dans un script de démarrage (par exemple /etc/rc.local).

Ça ne marche pas!

Bon, soit c'est votre serveur DNS qui n'est pas lancé, soit vos fichiers systèmes sont mal configurés. Pour le savoir, lancez la commande suivante pour voir si named tourne en tâche de fond :

ps -aux | grep named

Si named ne tourne pas en tâche de fond, lancez la commande

grep named /var/log/messages

, les lignes retournées devraient vous indiquez les erreurs de configuration que vous avez fait (fichier de zone non trouvé, etc...).

Si named tourne, vérifiez alors que le résolveur se connecte bien à votre serveur DNS et pas sur un autre. Pour cela, quand vous lancez nslookup, celui-ci doit vous répondre que le serveur par défaut est bien localhost, avec comme adresse "127.0.0.1". Si ce n'est pas le cas, vérifiez les fichiers /etc/resolv.conf et /etc/host.conf. Vérifiez aussi le fichier de zone 127.0.0.

Remarques sur un serveur DNS cache

• Un serveur DNS cache n'écrit pas dans un fichier les différentes adresses qu'il récupère, il les stocke en mémoire, ce qui veut dire qu'à partir du moment où vous éteignez votre machine (ou que vous stoppez le service named), vous perdez toutes les adresses en mémoire. Donc si vous utilisez votre serveur DNS juste pour accélérer votre connexion internet, ne stoppez pas votre serveur DNS et ne rebootez pas votre machine, où vous n'utiliserez en fait jamais votre cache. Le seul bénéfice dans ce cas est que vous utilisez votre serveur DNS qui fait cache avec les serveurs "root" d'internet, ce qui vous garantit des réponses fiables.
• Dans le cas où vous partagez votre connexion internet (modem cable, adsl, ou même simple modem) il est très utile d'utiliser un serveur DNS cache. Par contre, pour que vos stations qui utilisent cette connexion partagée se servent de ce serveur cache DNS, n'oubliez surtout pas de configurer toutes les stations pour qu'elles utilisent comme serveur DNS votre serveur et pas un autre. Pour cela, donnez comme adresse de serveur DNS l'adresse interne (côté LAN donc) de votre serveur.

@ Retour à la rubrique Réseau et sécurité

Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter.

Copyright

Vous avez l'autorisation de copier, distribuer et/ou modifier ce document suivant les termes de la Licence pour documents libres, Version 1.1 publiée par la La Guilde des Doctorants. Pour plus d'informations consulter la LDL sur le site de La Guilde des Doctorants.