Construire un DNS

[ Accueil ] [ Notions de base ] [ Notions avancées ] [ Construire un DNS ] [ Préceptes ] [ sniff ]

Pourquoi pas...

Vous pouvez souhaiter monter un DNS local pour plusieurs raisons :

• Vous disposez sur votre LAN de services Intranet du genre serveur web,  ftp, messagerie. Dans ce cas, il vous faut un système de résolution de noms.
• Vous  ne voulez pas vous embêter avec la configuration des clients de votre LAN, vous préférez leur indiquer comme DNS votre propre système de résolution.
• Vous voulez juste vous amuser avec Bind, pour la beauté du geste.

Il existe un moyen rudimentaire de fournir à chaque hôte du réseau un système de résolution de noms à partir du fichier "hosts" (ne confondez pas avec la commande de Linux). Chaque hôte doit disposer d'un tel fichier, à jour. C'est relativement simple à faire si le fichier ne contient que quelques références et que les postes sont peu nombreux, c'est autre chose si le réseau local prend de l'ampleur. Et ça ne résoudra pas le problème de la résolution sur Internet.

Et puis, c'est tellement simple à monter, un DNS :)

Un DNS?

Fixons les esprits. Nous sommes dans la configuration suivante : celle qui intéresse la majorité des galériens du haut débit, le réseau local pouvant aller d'un à un certain nombre d'hôtes, 6 dans mon cas, chacun le (ou les) sien(s), c'est le meilleur moyen d'être tranquille...

Dans ce type de configuration, un DNS monté sur la passerelle Linux peut présenter un intérêt s'il sert à la fois:

• A résoudre les noms sur le réseau local, évitant ainsi d'avoir à maintenir des fichiers hosts sur chaque poste .

• A résoudre aussi les noms sur l'Internet, ce qui permet de configurer les clients du réseau local avec cet unique DNS pour toutes les résolutions de noms. Seul petit problème, les méthodes de travail de Wanadoo qui perturbent... Mais nous verrons comment détourner cet inconvénient.

Il est clair que si votre installation est réduite à un poste directement connecté au modem, construire un DNS dessus n'a plus aucune utilité.

Mode opératoire.

Dans un premier temps, nous allons construire un simple cache pour l'Internet. Ce DNS ne résoudra pas les noms des hôtes du réseau privé, mais il le fera pour les noms Internet.

Dans un second temps, nous ajouterons une zone qui permettra de résoudre les noms dans le réseau local. Il faudra alors déclarer un domaine "bidon", avec tous les risques que ça comporte, à cause d'éventuelles interférences avec un domaine déclaré d'Internet.

Construction du cache.

Nous allons utiliser BIND qui est fait pour çà. Nous partons également du principe que BIND a été installé correctement. Ce n'est pas une chose compliquée, toutes les distributions fournissent les paquetages nécessaires (bind et bind-utils pour Mandrake).

Le mode opératoire décrit ici est testé sur une distribution MANDRAKE 7.0, mais les versions suivantes le supportent également.

Configuration avec linuxconf.

linuxconf est fait pour RedHat. Il fonctionne sur Mandrake, mais vous risquez d'avoir quelques sueurs au moment de la mise à jour des configurations. En effet, des messages parfois incohérents risquent d'apparaître.  Nous verrons alors ce qu'il y a lieu de faire.

Assurez-vous d'abord que linuxconf est correctement configuré. Le fichier /etc/conf.linuxconf doit contenir au paragraphe [base] la ligne :

module.list 1 dnsconf

Si ce n'est pas le cas, ajoutez-la et redémarrez linuxconf.

	En mode graphique (à la rigueur en mode texte) démarrez linuxconf et choisissez le bouton "Réseau". Sur l'onglet "Tâches serveur" doit apparaître la fonction "Domain Name Server". Cliquez dessus. Elle n'y est pas? assurez-vous que: BIND est bien installé  Le fichier /etc/conf.linuxconf contient la ligne: "module.list 1 dnsconf" dans le paragraphe [base]. Cette ligne peut ne pas être présents si vous avez installé bind après linuxconf. Il suffit alors de l'ajouter à la main.
	Pour l'instant, nous construisons juste un cache. Seul le bouton "fonctionnalités" nous intéresse.
	Ne cédez pas à la tentation... Aucun bouton n'a besoin d'être enfoncé.
	Nous allons tout de suite régler quelques problèmes de sécurité. Choisissez l'onglet du même nom, cliquez sur "Contrôle d'accès"...
	Nous supposons que le réseau privé est de la classe 192.168.0.0. Nous indiquons ici que les transferts ne seront autorisés que pour les machines dont l'IP est de cette classe.
	Même chose pour Autoriser les requêtes...

Quittez linuxconf . 

C'est ici que de curieux messages risquent d'apparaître. Si linuxconf vous signale que certains services ne tournent pas et qu'il faut les démarrer, à priori, c'est faux. Vous n'avez manipulé que Bind et il n'y a aucune raison que le reste du système ait été altéré. Vérifiez à la main si le coeur vous en dit... (ps aux, par exemple). Dans un tel cas, dites à linuxconf de ne rien faire, puis rechargez named avec un :

/etc/init.d/named reload

Autres moyens.

Linuxconf n'est pas forcément très pratique à manipuler, principalement sur les distributions Mandrake. De plus, cet outil semble abandonné dans les dernières distributions. Essayez plutôt :

• Webmin, un utilitaire à tout faire via HTTP (ou, encore mieux, HTTPS). Il dispose d'un module pour Bind 8 qui suffit à réaliser ce que l'on veut faire ici, même si nous utilisons un bind 9. Webmin est suffisamment intuitif.
• de configurer les fichiers de bind avec un éditeur de texte. Ce n'est pas très compliqué, ça l'est tout de même un peu plus que d'utiliser linuxconf ou webmin, à cause de la syntaxe très stricte à utiliser.

Contrôle des fichiers de configuration.

Voilà. C'est presque fini, juste quelques vérifications. Pour les faire, on va mettre les mains dans le cambouis, (entendez par là que l'on va aller voir dans les fichiers de configuration)...

BIND utilise quelques fichiers de configuration en mode texte, qui sont mis à jour par linuxconf (ou Webmin).

named.conf

Ce fichier est le premier que BIND va lire. Nous y trouvons déjà des informations intéressantes...

options {
	directory "/var/named";
	notify no;
	allow-transfer{
		192.168.0.0/24;
	};
	allow-query{
		192.168.0.0/24;
	};
};

zone "." {
	type hint;
	file "root.cache";
};

zone "0.0.127.IN-ADDR.ARPA"{
	type master;
	file "127.0.0";
};

root.cache

Si vous avez bien suivi, vous savez qu'il se trouve dans /var/named. Une version est installée avec BIND, vous avez tout de même intérêt à vous assurer qu'elle est à jour en allant voir à ftp://ftp.rs.internic.net/domain/named.root

vous pouvez télécharger ce fichier et le placer directement dans le répertoire /var/named après, bien entendu, avoir renommé votre copie de "root.cache", par exemple en "root.cache.old".

Le daemon named.

Vérifiez que le Daemon "named" est en service, mieux encore, vérifiez qu'il est lancé à chaque démarrage. Un outil pratique est l'éditeur de Sys V Init. La photo est un peu grande mais elle vaut le coup d'œil:

Les puristes me pardonneront, c'est certainement un outil qu'ils n'aiment pas... Mais je ne suis pas un puriste LINUX (ça viendra peut-être un jour). Si vous ne disposez pas de cet outil, pas de panique, il y en a d'autres comme tksysv par exemple.

Vérifiez d'une part que "named" figure dans la colonne "services", ce doit être le cas si BIND est correctement installé.

Vérifiez ensuite qu'il figure également au moins dans la colonne du "runlevel" que vous utilisez (3 par défaut) au chapitre "Démarrer". Si ce n'est pas le cas, mettez-le  (drag and drop), sauvez le fichier et ça ira mieux au prochain démarrage. En attendant, vous pouvez le démarrer manuellement, soit depuis l'outil graphique, soit par la ligne de commande:

/etc/rc.d/init.d/named start

Un autre moyen pour effectuer la vérification en mode texte, est d'utiliser une commande qui doit fonctionner si BIND est installé, c'est la commande "ndc". en étant "root", tapez  dans une console "ndc help", mieux encore (ou en complément), tapez  "man ndc" et voyez ce que vous pouvez faire avec. Entre autres choses, vous pouvez démarrer BIND avec la commande "ndc start"

Est-ce que ça marche?

Il suffit, sur l'un de vos postes clients du réseau privé, de configurer le DNS par défaut avec l'adresse de votre DNS et d'effectuer une résolution de nom sur Internet. Normalement, ça doit fonctionner.

La galère Wanadoo.

Tous les abonnés Wanadoo y ont droit.

Identification du problème.

Wanadoo  propose à ses abonnés deux DNS qui sont 193.252.19.3 et 193.252.19.4. Mais ces DNS ne sont pas publics. Si, au moyen de nslookup (ou autre), vous recherchez les DNS publics du domaine wanadoo.fr, vous trouvez par exemple:

ns.wanadoo.fr internet address = 193.252.19.10
ns2.wanadoo.fr internet address = 193.252.19.11
ns.wanadoo.com internet address = 194.51.238.1
ns2.wanadoo.com internet address = 194.51.238.2

Il se trouve que les DNS des abonnés wanadoo ne donnent pas les mêmes adresses que les DNS publics pour, au moins, les serveurs smtp.wanadoo.fr et news.wanadoo.fr. Pourquoi? Je n'en sais fichtre rien...

Bien entendu, les adresses fournies par les DNS publics ne sont pas utilisables par les abonnés. La conclusion de tout ceci est que votre magnifique cache ne vous permettra pas:

• Ni d'envoyer votre courrier par smtp.wanadoo.fr

• Ni de vous connecter aux news par news.wanadoo.fr

(Cette particularité m'a fait chercher longtemps...)

Depuis (courant avril/mai 2003), Wanadoo a remanié considérablement ses structures? Aujourd'hui (1 juin 2003), vous n'obtiendrez pas tout à fait les mêmes choses, mais la curiosité décrite plus haut est toujours visible.

Contournement du problème: Ajouter une zone de redirection.

Nous allons créer sur notre serveur de noms une zone "wanadoo.fr" pour laquelle nous transmettrons toutes les requêtes au DNS de Wanadoo Câble. Ce type de zone est appelé: "zone de redirection". Voici l'opération:

	Après avoir démarré linuxconf, Tâches, serveur, DNS; choisissez le bouton "zones de redirection".
	Cliquez sur "Ajouter"...
	Et pour le domaine "wanadoo.fr", on va rediriger les requêtes sur le serveur de notre irremplaçable FAI (L'adresse du vôtre n'est certainement pas celle qui est écrite ici).

Que va-t-il se passer maintenant? A chaque requête concernant le domaine "wanadoo.fr", votre DNS, au lieu d'effectuer une recherche récursive à partir des root-servers comme on l'a vu par ailleurs, transmettra directement au DNS du FAI qui, lui, répondra avec la bonne adresse pour nous. C'est la solution la moins sale que j'ai trouvée, mais nous restons tributaires de Wanadoo pour son domaine.

Pour ceux qui souhaitent utiliser le service DNS de Windows NT ou 2000, tout ce qui est dit dans ce chapitre est réalisable à l'exception de la redirection d'une zone (du moins à ma connaissance).

Contrôle.

Voyons maintenant l'allure de notre fichier "named.conf":

options {
	directory "/var/named";
	notify no;
	allow-transfer{
		192.168.0.0/24;
	};
	allow-query{
		192.168.0.0/24;
	};
};
zone "." {
	type hint;
	file "root.cache";
};
zone "0.0.127.IN-ADDR.ARPA"{
	type master;
	file "127.0.0";
};

zone "wanadoo.fr."{
	type forward;
	forward only;
	forwarders{
		62.161.120.11;
	};
};

Ajouter une zone d'autorité.

Qu'est-ce que c'est?

Une zone d'autorité est un domaine ou un sous-domaine que le DNS sait traiter avec sa propre base de données. Nous pouvons en créer une pour résoudre les noms des hôtes de notre réseau privé. Ceci ne présente, encore une fois, pas un intérêt capital mais tant qu'on y est, pourquoi nous en priver? (surtout si vous montez par exemple un petit serveur apache pour réaliser votre intranet :-)

Préparation du travail.

Vous avez en tête, bien entendu, l' adresse de chacun de vos postes privés ainsi que leur nom "NetBIOS", si ces postes sont sous Windows. Par ailleurs, vous connaissez également l'adresse et le nom de votre passerelle Linux.

Fixons les idées par un exemple:

• Quatre hôtes Windows:

chris	192.168.0.100
daniel	192.168.0.101
michele	192.168.0.102
remi	192.168.0.103

• Un serveur Linux (Pas la passerelle). Il pourra par exemple héberger votre site Intranet et partager de l'espace disque pour vos hôtes WIndows avec SAMBA

Server1

192.168.0.200

• La passerelle Linux qui supporte le DNS. Ce poste dispose de deux interfaces réseau, nous nous intéressons ici à celle qui est connectée au réseau privé. (L'autre recevant une adresse IP dynamique par le DNS de Wanadoo Câble).

gateway1

192.168.0.250

Nous allons nous choisir un joli nom de domaine:

• Soit on va choisir un nom dans un TLD existant, comme  "maison.fr", mais ce nom est déposé. Le fait de le choisir pour votre domaine privé vous interdira d'aller visiter le "vrai" site www.maison.fr. parce que votre DNS n'ira pas chercher plus loin que dans sa base tout hôte appartenant au domaine maison.fr. Si vous choisissez cette option, allez d'abord visiter le site "officiel" et voyez si ça peut vous poser un problème de ne plus pouvoir y avoir accès... Vous pouvez bien entendu choisir un autre nom, mais le problème risque de se reproduire ailleurs.
• Vous pouvez également pour la circonstance créer un TLD "en bois" comme  mrs. par exemple. C'est pas tous les jours que de "vrais" TLD sont créés et de cette manière, vous risquez moins d'accidents.

Pour notre exemple, nous allons choisir maison.mrs. 

Création de la zone.

	Après avoir démarré linuxconf, option "réseau", onglet "Tâches serveurs", bouton DNS, on clique sur le bouton "domaines"...
	Pour l'instant, il n'y en a pas, nous allons en ajouter un...
	Comme c'est indiqué sur l'illustration. L'image a été coupée parce que la partie de droite ne nous intéresse pas. Vérifiez sur l'onglet" serveurs de mail" qu'il n'y a aucune indication écrite, il ne nous sert à rien ici. Une fois les champs renseignés, acceptez.
	Maintenant, nous allons éditer la liste des hôtes pour le domaine...
	Il n'y en a qu'un, celui que l'on vient de créer.
	Ajoutons...
	Le nom de la machine...
	Son adresse, sur l'onglet "adrs.IP" et acceptons. Il faut recommencer cette opération pour tous les hôtes de votre domaine privé.
	Une fois l'hôte "server1" saisi, il sera même possible de créer un alias en ajoutant un enregistrement comme suit:

Et voilà le travail. Normalement, votre zone privée est définie.

Vérifications.

Les fichiers de config.

/etc/named.conf

options {
	directory "/var/named";
	notify no;
	allow-transfer{
		192.168.0.0/24;
	};
	allow-query{
		192.168.0.0/24;
	};
};
zone "." {
	type hint;
	file "root.cache";
};
zone "0.0.127.IN-ADDR.ARPA"{
	type master;
	file "127.0.0";
};
zone "wanadoo.fr"{
	type forward;
	forwarders{
		62.161.120.11;
	};
};

zone "maison.mrs"{
	type master;
	file "maison.mrs";
};
zone "0.168.192.IN-ADDR.ARPA"{
	type master;
	file "192.168.0";
};

/var/maison.mrs

@		IN	SOA	gateway1.maison.mrs.	hostmaster.gateway1.maison.mrs. (
			2000042701 ; serial
			3600 ; refresh
			900 ; retry
			1209600 ; expire
			43200 ; default_ttl
			)
gateway1	IN	A	192.168.0.250
chris		IN	A	192.168.0.100
daniel		IN	A	192.168.0.101
remi		IN	A	192.168.0.103
michele		IN	A	192.168.0.102
server1		IN	A	192.168.0.200
www		IN	CNAME	server1.maison.mrs.
@		IN	NS	gateway1.maison.mrs.

Le @ signifie qu'il est fait référence au serveur lui-même.

Notez le Start Of Authority (SOA) et le CNAME www de server1

/var/192.168.0

@		IN	SOA	gateway1.maison.mrs.	2000042701 (
			2000042702 ; serial
			0 ; refresh
			0 ; retry
			0 ; expire
			0 ; default_ttl
			)
100		IN	PTR	chris.maison.mrs.
101		IN	PTR	daniel.maison.mrs.
103		IN	PTR	remi.maison.mrs.
102		IN	PTR	michele.maison.mrs.
@		IN	NS	gateway1.maison.mrs.
250		IN	PTR	gateway1.maison.mrs.
200		IN	PTR	server1.maison.mrs.

Pas grand chose à dire, de plus, si ce n'est que seul le dernier octet de l'adresse est signalé, c'est normal, nous sommes dans une classe C, les trois autres octets sont ceux du réseau.

Un coup de NSLOOKUP.

Depuis un hôte quelconque du réseau:

D:\>nslookup chris.maison.mrs
Serveur: gateway1.maison.mrs
Address: 192.168.0.250

Nom : chris.maison.mrs
Address: 192.168.0.100

Si ça marche pour un, ça doit marcher pour tous. Le travail est terminé.

Conclusion.

Le DNS que nous avons construit dispose de quelques fonctionnalités intéressantes:

• Il résout les noms du réseau privé, comme le fait un DNS d'entreprise.
• Il contourne le problème FTI en transmettant les requêtes sur le domaine wanadoo.fr et seulement sur lui, au DNS de notre FAI
• Il résout les noms de tous les autres domaines en effectuant des recherches itératives sur les serveurs de noms publics, comme le fait tout bon DNS.

Pour ceux qui voudraient en savoir un peu plus, il y a le DNS-HOWTO en français, dont je me suis largement inspiré pour mener cette étude. A la fin ce ce HOWTO, il y a une série de liens sur des sites plus pointus, mais ils ne sont pas en français...

Comme nous pouvons le constater, le mécanisme de la résolution des noms est très logique, mais nécessite une organisation sans failles.

Beaucoup de choses n'ont pas été dites ici, comme la notion de serveur maître et de serveur esclave, le système des notifications qui permet, lorsque l'on met à jour un DNS de répercuter cette mise à jour sur d'autres serveurs etc. Mais le but de ce chapitre était plus de décortiquer le fonctionnement que de donner un cours d'administration d'inter réseaux.

Ce qui a été développé ici vous aura aidé, du moins je l'espère:

• à comprendre comment un DNS récursif travaille
• à voir la différence entre un serveur récursif (celui que l'on a construit en exemple) et un serveur qui ne l'est pas (la plupart des root-servers et des serveurs des NICS)
• à comprendre le rôle des principaux enregistrements SOA, NS, A,  CNAME, PTR.
• à comprendre enfin pourquoi il il faut être prudent dans le choix de son DNS par défaut.

Liens divers.