/usr/share/doc/HOWTO/fr-html/DNS-HOWTO.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>DNS HOWTO</title>
</head>
<body>
<h1>DNS HOWTO</h1>
<h2>Nicolai Langfeldt <code>&lt;janl@math.uio.no&gt;</code><br>
Traduction française par Mathieu Arnold
<code>&lt;arn_mat@club-internet.fr&gt;</code></h2>
Version 2.2, du 11 février 1999
<hr>
<em>Comment devenir un administrateur de DNS à la petite
semaine.</em>
<hr>
<h2><a name="s1">1. Préambule</a></h2>
<p>Mots-clés&nbsp;: DNS, bind, bind-4, bind-8, named, dialup, ppp,
slip, isdn, Internet, domain, name, hosts, resolving, caching</p>
<p>Ce document fait partie du <em>Linux Documentation
Project</em>.</p>
<h2><a name="ss1.1">1.1 Aspect juridique</a></h2>
<p>(C)opyright 1995-1999 Nicolai Langfeldt. Ne modifiez pas ce
document sans en modifier le message de copyright en conséquence.
Vous pouvez distribuer ce document librement sous réserve de
conserver le message de copyright.</p>
<h2><a name="ss1.2">1.2 Remerciements et appel aux bonnes
volontés</a></h2>
<p>J'aimerais remercier Arnt Gulbrandsen qui a tant souffert en
relisant les brouillons de ce document et qui a apporté nombre de
suggestions pertinentes. Merci également à tous ceux qui m'ont
envoyé leurs suggestions par courrier électronique. Merci
beaucoup&nbsp;! Vous m'aidez vraiment dans ce travail.</p>
<p>Ce document n'est pas destiné à atteindre un jour un état final,
alors faites-moi part de vos problèmes ainsi que de vos succès,
cela me permettra d'améliorer ce HOWTO. Merci d'envoyer les
commentaires et/ou les questions et même l'argent à
janl@math.uio.no. Si vous m'envoyez un courrier électronique, merci
de <em>vérifier</em> que votre adresse de retour est correcte car
je reçois <em>beaucoup</em> de courrier électronique. Essayez aussi
de lire le chapitre <a href="#qanda">FAQ</a> avant de m'envoyer un
mail. Autre chose je (l'auteur) ne parle qu'anglais et
norvégien.</p>
<p>Si vous ne parlez ni l'anglais ni le norvégien, vous pouvez
toujours envoyer vos commentaires en français au traducteur
(arn_mat@club-internet.fr) qui fera suivre.</p>
<p>Si vous voulez traduire ce HOWTO, prévenez-moi pour que je
puisse garder le compte de toutes les langues dans lesquelles il a
été traduit&nbsp;:-), de plus, cela me permettra de vous tenir au
courant des évolutions de ce HowTo.</p>
<h2><a name="ss1.3">1.3 Dédicace</a></h2>
<p>Ce HOWTO est dédié à Anne Line Norheim. Pourtant, elle ne le
lira sans doute jamais, ce n'est pas du tout son genre.</p>
<h2><a name="intro"></a> <a name="s2">2. Introduction.</a></h2>
<p><b>Ce que ce document est et ce qu'il n'est pas</b></p>
<p>Le DNS est le <em>Domain Name System</em>. C'est l'ensemble des
règles utilisées par les machines et les logiciels pour établir,
entre autres choses, la correspondance entre les noms de machines
et les adresses IP, dont chaque machine sur le net est pourvue. Ce
document explique comment définir de telles correspondances à
l'aide d'un système Linux. Une correspondance est tout simplement
une relation entre deux objets, dans notre cas un nom de machine,
comme <code>ftp.linux.org</code>, et l'adresse IP de cette machine,
<code>199.249.150.4</code>.</p>
<p>Le DNS constitue pour le non-initié (vous dans le cas
présent&nbsp;;-) une des parties les plus obscures de
l'administration de réseau. Le but de ce HOWTO est d'essayer d'en
éclaircir quelques aspects. Ce document explique comment configurer
un DNS <em>simple</em>. Nous allons commencer avec un serveur de
noms qui ne sert qu'à faire cache puis nous continuerons en
configurant un serveur DNS primaire pour un domaine. Pour des
configurations plus complexes, jetez un coup d'oeil à la section
<a href="#qanda">FAQ</a> de ce document. Si vous n'y trouvez pas ce
que vous cherchez, vous allez alors devoir <em>lire</em> la Vraie
Documentation. Je reviendrai sur ce en quoi consiste la Vraie
Documentation dans le chapitre <a href="#bigger">final</a>.</p>
<p>Avant de commencer, vous devez configurer votre machine pour
être capable de vous connecter par telnet sur d'autres machines
mais aussi pouvoir recevoir des connexions sur votre machine. Vous
devez aussi être en mesure de vous connecter au réseau par tous les
services possibles, et en particulier pouvoir faire <code>telnet
127.0.0.1</code>, ce qui revient à vous connecter à votre propre
machine (vérifiez tout de suite que ça marche&nbsp;!). Il est aussi
nécessaire, pour commencer, que les fichiers
<code>/etc/nnswitch.conf</code> (ou <code>/etc/host.conf</code>),
<code>/etc/resolv.conf</code> et <code>/etc/hosts</code> soient
correctement configurés car je n'expliquerai pas ici à quoi ils
servent. Si tout cela n'est pas déjà configuré et en état de
marche, lisez le NET-3-HOWTO.</p>
<p>Si vous utilisez une connexion SLIP ou PPP, il est indispensable
qu'elle fonctionne. Lisez le PPP HOWTO si ce n'est pas le cas.</p>
<p>Quand je dis ``votre machine'', j'entends la machine sur
laquelle vous aller essayer d'installer le DNS, et non pas une
autre machine dont vous pourriez vous servir pour accéder au
réseau.</p>
<p>Je supposerai par la suite que vous ne vous trouvez pas derrière
un firewall qui bloque les requêtes de résolution de nom. Si tel
est le cas, vous aurez besoin d'une configuration spéciale.
Reportez-vous alors au chapitre <a href="#qanda">FAQ</a>.</p>
<p>Le service de résolution de nom sous Unix est assuré par un
programme appelé <code>named</code>. Il fait partie du paquetage
``bind'', géré par Paul Vixie pour l'Internet Software Consortium.
<code>named</code> est inclus dans la plupart des distributions de
Linux et se trouve le plus souvent installé dans
<code>/usr/sbin/named</code>. Si vous disposez d'un
<code>named</code>, vous pouvez vraisemblablement l'utiliser. Si
vous n'en avez pas, chargez-en un à partir d'un site FTP Linux ou
allez chercher la dernière et meilleure version des sources du
programme depuis <a href=
"ftp://ftp.isc.org/isc/bind/src/cur/bind-8/">ftp.isc.org/isc/bind/src/cur/bind-8/</a>.
Ce HowTo parle de bind version 8. L'ancienne version de ce HowTo, a
propos de bind 4 est toujours disponible à <a href=
"http://www.math.uio.no/~janl/DNS/">www.math.uio.no/~janl/DNS/</a>
au cas ou vous auriez bind 4. Si la page man de <code>named</code>
parle de <code>named.conf</code> vous avec bind 8, si elle parle
(tout a la fin, dans la section FILES) de <code>named.boot</code>
vous avez bind 4. Si vous avez bind 4, et si la sécurité fait
partie de vos préoccupations, vous devriez vraiment passer à bind
8.</p>
<p>Le service DNS est une base de données à l'échelle du réseau
tout entier. Faites donc très attention à ce que vous y
introduisez. Si vous y mettez n'importe quoi, vous en retirerez
n'importe quoi, et les autres aussi. Conservez votre DNS bien
propre, à jour et cohérent et vous verrez qu'il vous offrira le
meilleur de lui-même. Apprenez a l'utiliser, l'administrer, le
débogger et vous ferez partie de ces administrateurs qui empêchent
que le réseau ne s'écroule sous le poids des systèmes mal
gérés.</p>
<p>Dans ce document, je dis des choses qui ne sont pas tout à fait
vraies (mais qui le sont toujours au moins à moitié). Si je le
fais, c'est toujours dans le but de rendre les choses plus simples.
Tout marchera (probablement&nbsp;;-) très bien si vous croyez ce
que je vous dis.</p>
<p><b>Astuce&nbsp;:</b> S'ils existent déjà, faites une copie de
sauvegarde de tous les fichiers que je vous demande de modifier.
Ainsi, si plus rien ne marche après ce que nous allons faire, vous
pourrez toujours revenir au bon vieux temps où tout marchait
bien.</p>
<h2><a name="caching"></a> <a name="s3">3. Un Serveur de Noms qui
ne sert que de cache.</a></h2>
<p><b>Un premier aperçu de la configuration d'un DNS, très utile
pour ceux qui utilisent une connexion en dialup.</b></p>
<p>Un serveur de noms qui ne sert que de cache trouve la réponse
aux requêtes de résolution de nom et se souvient de cette réponse
chaque fois qu'on lui posera la même question par la suite. Cela
réduira les temps de réponse, surtout si vous avez une connexion
plutôt lente.</p>
<p>Vous avez tout d'abord besoin du fichier
<code>/etc/named.conf</code>. Ce fichier est lu au lancement de
<code>named</code>. Pour le moment, il ne doit pas contenir autre
chose que&nbsp;:</p>
<hr>
<pre>
// Fichier de config pour un serveur de noms qui ne fait que du cache

options {
        directory "/var/named";

        // Enlever les commentaires peut vous aider si vous avez a passer a
        // travers un firewall et que ça ne marche pas :

        // query-source port 53;
};

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

zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};
</pre>
<hr>
<p><b>TRÈS IMPORTANT&nbsp;:</b> Dans certaines versions de ce
document, les fichiers listés comme ci-dessus présentent un certain
nombre de caractères espace ou tabulation avant le premier
caractère non blanc de la ligne. Ils ne sont pas supposés faire
partie du fichier. <b>Effacez donc tous les caractères blancs</b>
de début de ligne des fichiers que vous copiez-collez à partir de
ce HOWTO.</p>
<p>La ligne ``<code>directory</code>'' indique à <code>named</code>
l'endroit où il doit rechercher ses fichiers. Tous les fichiers
dont nous parlerons maintenant auront un chemin relatif relatifs à
ce répertoire. Ainsi, <code>pz</code> est un sous-répertoire de
<code>/var/named</code>, c'est a dire <code>/var/named/pz</code>.
D'après le <em>Linux Filesystem Standard</em>, ce répertoire doit
être <code>/var/named</code>.</p>
<p>On trouve à cet endroit le fichier
<code>/var/named/root.hints</code>, qui doit ressembler à
ceci&nbsp;:</p>
<hr>
<pre>
; Il se peut qu'il y ait quelques commentaires ici si vous avez déjà ce
; fichier. de toutes façon, ce sont des commentaires, ils ne sont pas
; important du tout.

.                       6D IN NS        G.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.
.                       6D IN NS        A.ROOT-SERVERS.NET.
.                       6D IN NS        H.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        I.ROOT-SERVERS.NET.
.                       6D IN NS        F.ROOT-SERVERS.NET.

G.ROOT-SERVERS.NET.     5w6d16h IN A    192.112.36.4
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
A.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.4
H.ROOT-SERVERS.NET.     5w6d16h IN A    128.63.2.53
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
I.ROOT-SERVERS.NET.     5w6d16h IN A    192.36.148.17
F.ROOT-SERVERS.NET.     5w6d16h IN A    192.5.5.241
</pre>
<hr>
<p><b>Souvenez-vous bien de ce que j'ai dit pour les caractères
blancs en tête de ligne&nbsp;!</b></p>
<p>Ce fichier donne une description de tous les serveurs de noms du
monde qui se trouvent à la racine (au plus haut niveau) de la
hiérarchie des serveurs de noms. Il arrive que cette liste change,
c'est pourquoi il est essentiel que ce fichier soit maintenu à
jour. Reportez-vous à la section <a href="#maint">maintenance</a>
pour savoir comment le garder à jour. Le contenu de ce fichier est
décrit dans la page de man de <code>named</code> mais cette
dernière s'adresse plus, à mon humble avis, à ceux qui savent déjà
comment fonctionne ce programme.</p>
<p>La section suivante de <code>named.conf</code> est la dernière
partie. Elle sera expliquée dans un chapitre suivant, pour
l'instant, créez un fichier appelé <code>127.0.0</code> dans le
sous répertoire <code>pz</code>&nbsp;:</p>
<hr>
<pre>
@               IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                                1       ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                1W      ; Expire
                                1D)     ; Minimum TTL
                        NS      ns.linux.bogus.
1                       PTR     localhost.
</pre>
<hr>
<p>Après ça, vous avez besoin d'un fichier
<code>/etc/resolv.conf</code> qui ressemble à peu près à
ça&nbsp;:</p>
<hr>
<pre>
search subdomain.your-domain.edu your-domain.edu
nameserver 127.0.0.1
</pre>
<hr>
<p>La ligne <code>search</code> spécifie dans quels domaines il
faudra chercher lorsque vous voudrez vous connecter sur une machine
de nom quelconque. La ligne ``<code>nameserver</code>'' indique à
quelle adresse votre machine peut contacter un serveur de noms. Si
vous voulez indiquer plusieurs serveurs de nom, mettez une ligne
``<code>nameserver</code>'' pour chacun. Dans notre cas, il s'agit
de notre propre machine puisque c'est elle qui fait tourner
<code>named</code>. (Note&nbsp;: <code>named</code> ne lit jamais
ce fichier, c'est le <em>résolveur</em> qui utilise
<code>named</code> qui le fait).</p>
<p>Voyons sur un exemple à quoi sert ce fichier&nbsp;: si un client
cherche à contacter <code>foo</code>, on essaye d'abord
<code>foo.subdomain.your-domain.edu</code> puis
<code>foo.your-domain.edu</code> et enfin <code>foo</code>. Si un
client essaye de contacter <code>sunsite.unc.edu</code>, on essaye
d'abord <code>sunsite.unc.edu.subdomain.your-domain.edu</code> (je
sais, c'est stupide, mais c'est comme ça) puis
<code>sunsite.unc.edu.your-domain.edu</code> et enfin
<code>sunsite.unc.edu</code>. Faites attention à ne pas mettre trop
de noms de domaine dans la ligne <code>search</code> car cela prend
du temps de tous les essayer.</p>
<p>Cet exemple suppose que vous appartenez au domaine
<code>subdomain.your-domain.edu</code>. Votre machine s'appelle
alors certainement
<code>your-machine.subdomain.your-domain.edu</code>. La ligne
search ne doit pas contenir votre TLD (Top Level Domain;
<code>edu</code> dans notre cas). Si vous vous connectez
fréquemment à des machines dans un autre domaine, vous pouvez
rajouter ce domaine dans la ligne search comme ceci&nbsp;:</p>
<hr>
<pre>
search subdomain.your-domain.edu your-domain.edu other-domain.com
</pre>
<hr>
<p>et ainsi de suite. Évidemment, il faut appliquer cet exemple à
de vrais noms de domaines. Remarquez qu'ici il n'y a pas de point à
la fin des noms de domaine. C'est important, notez l'absence de
points aux fins des noms de domaines.</p>
<p>Ensuite, suivant votre version de la libc, vous allez devoir
modifier soit <code>/etc/nsswitch.conf</code>, soit
<code>/etc/host.conf</code>. Si vous avez déjà
<code>nsswitch.conf</code>, c'est celui-là que nous allons
modifier, sinon ce sera <code>host.conf</code>.</p>
<p><b>/etc/nsswitch.conf</b></p>
<p>C'est un long fichier qui spécifie où trouver différentes sortes
de types de données, dans quel fichier ou quelle base de données.
Il contient généralement des commentaires précieux au début, que
vous auriez tout intérêt à lire. Ensuite, trouvez la ligne qui
commence par ``<code>hosts:</code>'', elle doit ressembler à
ceci:</p>
<hr>
<pre>
hosts: files dns
</pre>
<hr>
<p>Si il n'y a aucune ligne qui commence par
``<code>hosts:</code>'', mettez celle ci-dessus. Elle dit que les
programmes doivent d'abord regarder dans <code>/etc/hosts</code>
puis demander au DNS en suivant les indications de
<code>resolv.conf</code>.</p>
<p><b>/etc/host.conf</b></p>
<p>Ce fichier contient certainement plusieurs lignes, dont une doit
commencer par <code>order</code> et ressembler à ça&nbsp;:</p>
<hr>
<pre>
order hosts,bind
</pre>
<hr>
<p>Si il n'y a pas de ligne ``<code>order</code>'', il faut en
mettre une. Elle indique aux routines de résolution de nom de
regarder d'abord dans <code>/etc/hosts</code> puis de demander au
serveur de noms (que vous avez précisé dans
<code>resolv.conf</code> comme étant 127.0.0.1).</p>
<h2><a name="ss3.1">3.1 Démarrer named.</a></h2>
<p>Après tout ça, il est temps de démarrer <code>named</code>. Si
vous utilisez une connexion en dialup, commencez par vous
connecter. Tapez ``<code>ndc start</code>'' et appuyez sur la
touche entrée, sans donner d'options. Si ça ne marche pas, essayez
plutôt ``<code>/usr/sbin/ndc start</code>''. Si ça ne marche
toujours pas, jetez un coup d'oeil au chapitre <a href=
"#qanda">FAQ</a>. Si vous jetez un oeil à votre fichier de messages
syslog (souvent appelé <code>/var/adm/messages</code>, mais
regardez également dans le répertoire <code>/var/log</code> ou dans
le fichier <code>syslog</code>) tout en lançant <code>named</code>
(faites <code>tail -f /var/adm/messages</code>), vous devriez voir
quelque chose comme ça&nbsp;:</p>
<p>(les lignes se terminant par \ se continuent sur la ligne
suivante)</p>
<blockquote>
<pre><code>
Feb 15 01:26:17 roke named[6091]: starting.  named 8.1.1 Sat Feb 14 \
  00:18:20 MET 1998 ^Ijanl@roke.uio.no:/var/tmp/bind-8.1.1/src/bin/named
Feb 15 01:26:17 roke named[6091]: cache zone "" (IN) loaded (serial 0)
Feb 15 01:26:17 roke named[6091]: master zone "0.0.127.in-addr.arpa" \
  (IN) loaded (serial 1)
Feb 15 01:26:17 roke named[6091]: listening [127.0.0.1].53 (lo)
Feb 15 01:26:17 roke named[6091]: listening [129.240.230.92].53 (ippp0)
Feb 15 01:26:17 roke named[6091]: Forwarding source address is [0.0.0.0].1040
Feb 15 01:26:17 roke named[6092]: Ready to answer queries.
</code></pre></blockquote>
<p>Si il y a un quelconque message d'erreur, <code>named</code>
donnera le nom du fichier dans lequel se trouve l'erreur (soit
<code>named.conf</code>, soit root.hints, j'espère :-). Tuez le
processus <code>named</code> et re-vérifiez ce fichier.</p>
<p>Il est maintenant temps de vérifier votre configuration. Lancez
<code>nslookup</code> pour regarder le résultat de votre petit
travail.</p>
<blockquote>
<pre><code>
$ nslookup
Default Server: localhost
Address: 127.0.0.1

&gt;
</code></pre></blockquote>
<p>Si vous obtenez ce message, c'est que ça marche. Nous l'espérons
tous. Si vous obtenez quoi que ce soit d'autre, revenez en arrière
et vérifiez tout. Chaque fois que vous modifiez le fichier
<code>named.conf</code>, il vous faut relancer <code>named</code>
avec la commande <code>ndc restart</code>.</p>
<p>Maintenant, vous pouvez entrer une requête. Essayez de contacter
une machine proche de vous. <code>pat.uio.no</code> est proche de
moi, à l'Université d'Oslo&nbsp;:</p>
<blockquote>
<pre><code>
&gt; pat.uio.no
Server: localhost
Address: 127.0.0.1

Name:    pat.uio.no
Address: 129.240.2.50
</code></pre></blockquote>
<p>nslookup a demandé à votre <code>named</code> de rechercher la
machine <code>pat.uio.no</code>. Il a ensuite contacté un des
serveurs de noms mentionnés dans <code>root.cache</code> et a
demandé le chemin à suivre. Il peut s'écouler un certain temps
avant que vous obteniez le résultat puisqu'il se peut qu'il
recherche tous les domaines listés dans
<code>/etc/resolv.conf</code>.</p>
<p>Si vous réessayez, vous obtiendrez ceci&nbsp;:</p>
<blockquote>
<pre><code>
&gt; pat.uio.no
Server: localhost
Address: 127.0.0.1

Non-authoritative answer :
Name: pat.uio.no
Address: 129.240.2.50
</code></pre></blockquote>
<p>Notez cette fois ci l'apparition de la ligne
``<code>Non-authoritative answer :</code>''. Elle veut dire que
<code>named</code> n'a pas accédé au réseau pour obtenir la réponse
mais a trouvé l'information dans son cache. Cependant,
l'information cachée <em>pourrait</em> ne plus être à jour. C'est
pourquoi vous êtes informé de cette possibilité très improbable par
le message ``<code>Non-authoritative answer:</code>'' Quand
<code>nslookup</code> répond ceci la seconde fois qu'on lui demande
un certain hôte, c'est un signe certain que <code>named</code>
cache bien les informations et que tout marche. Pour sortir de
<code>nslookup</code>, utilisez la commande
``<code>exit</code>''.</p>
<h2><a name="ss3.2">3.2 Le rendre encore meilleur</a></h2>
<p>Dans les grands réseaux, bien administrés, des universités ou
FAI (Fournisseur d'Accès a Internet), vous remarquerez peut-être
que les administrateurs réseau ont mis en place une hiérarchie de
serveurs DNS ce qui permet de soulager le réseau interne ainsi que
le réseau vers l'extérieur. Il n'est pas facile de savoir si vous
êtes dans un réseau de ce type. Tout cela n'est pas très important,
mais en utilisant le serveur DNS de votre FAI comme ``forwarder''
vous pouvez rendre les réponses plus rapides et alléger la charge
de votre réseau. Avec un modem, la différence peut être sensible.
Pour améliorer encore notre exemple, supposons que votre FAI aie
deux serveurs de noms qu'il veux vous faire utiliser, ayant pour
adresses IP <code>10.0.0.1</code> et <code>10.1.0.1</code>. Alors,
dans votre fichier <code>named.conf</code>, dans la section appelée
``options'' insérez les lignes&nbsp;:</p>
<hr>
<pre>
           forward first;
           forwarders {
                10.0.0.1;
                10.1.0.1;
            };
</pre>
<hr>
<p>Redémarrez votre serveur de noms et testez avec
<code>nslookup</code>. Cela devrait marcher sans problèmes.</p>
<h2><a name="ss3.3">3.3 Félicitations&nbsp;!</a></h2>
<p>Maintenant, vous savez comment configurer un <code>named</code>
qui sert de cache. Servez-vous une bière, un verre de lait ou tout
ce que vous voudrez pour fêter l'événement.</p>
<h2><a name="simple"></a> <a name="s4">4. Un domaine
<em>simple</em></a></h2>
<p><b>Comment mettre en place votre propre domaine</b></p>
<h2><a name="ss4.1">4.1 Mais avant tout, un brin de
théorie</a></h2>
<p>Avant d'entrer <em>vraiment</em> dans le vif du sujet, il va
falloir que je fasse un brin de théorie avec quand même un petit
exemple sur le principe du service DNS. Et il faudra tout lire, car
c'est pour votre bien. Vous devriez au moins survoler rapidement
cette section. Arrêtez le survol quand vous arrivez à l'endroit où
j'explique le contenu du fichier <code>named.conf</code>.</p>
<p>Le service DNS est un système organisé de manière hiérarchique,
sous forme d'arbre. La racine est désignée par ``<code>.</code>''
et s'appelle ``la racine''. En dessous de <code>.</code> se
trouvent un certain nombre de TLD (<em>Top Level Domains</em>); les
plus connus sont <code>ORG</code>, <code>COM</code>,
<code>EDU</code>, <code>NET</code> et <code>FR</code>, mais il y en
a beaucoup d'autres. Tout comme un arbre, il a une racine avec des
branches qui en partent. Si vous avez des connaissances en
informatique fondamentale, vous reconnaîtrez dans le DNS un arbre
de recherche, avec des noeuds, des arrêtes et des feuilles.</p>
<p>Lorsque vous recherchez une machine, la question est posée
récursivement dans toute la hiérarchie depuis la racine. Lorsque
vous voulez trouver l'adresse IP de <code>prep.ai.mit.edu</code>,
votre DNS doit trouver un serveur de noms pour le domaine
<code>edu</code>. Votre DNS demande d'abord à un serveur de noms de
<code>.</code> (il possède déjà les adresses des serveurs pour
<code>.</code>, elles sont dans le fichier
<code>root.hints</code>), et le serveur pour <code>.</code> donne
une liste des serveurs d'<code>edu</code>.</p>
<p>Voici un exemple&nbsp;:</p>
<blockquote>
<pre><code>
$ nslookup 
Default Server: localhost
Address: 127.0.0.1
</code></pre></blockquote>
<p>Interrogeons un serveur situé à la racine.</p>
<blockquote>
<pre><code>
&gt; server c.root-servers.net.
Default Server: c.root-servers.net
Address: 192.33.4.12
</code></pre></blockquote>
<p>Positionnons le type de requête (Query Type) à NS (Name Server
records).</p>
<blockquote>
<pre><code>
&gt; set q=ns
</code></pre></blockquote>
<p>Posons la question à propos de <code>edu</code>.</p>
<blockquote>
<pre><code>
&gt; edu.
</code></pre></blockquote>
<p>Le <code>.</code> terminal est significatif, il indique à
<code>nslookup</code> que nous interrogeons que <code>edu</code> se
trouve juste sous <code>.</code> (et pas dans l'un de nos
sous-domaines, ce qui accélère la recherche).</p>
<blockquote>
<pre><code>
edu     nameserver = A.ROOT-SERVERS.NET
edu     nameserver = H.ROOT-SERVERS.NET
edu     nameserver = B.ROOT-SERVERS.NET
edu     nameserver = C.ROOT-SERVERS.NET
edu     nameserver = D.ROOT-SERVERS.NET
edu     nameserver = E.ROOT-SERVERS.NET
edu     nameserver = I.ROOT-SERVERS.NET
edu     nameserver = F.ROOT-SERVERS.NET
edu     nameserver = G.ROOT-SERVERS.NET
A.ROOT-SERVERS.NET      internet address = 198.41.0.4
H.ROOT-SERVERS.NET      internet address = 128.63.2.53
B.ROOT-SERVERS.NET      internet address = 128.9.0.107
C.ROOT-SERVERS.NET      internet address = 192.33.4.12
D.ROOT-SERVERS.NET      internet address = 128.8.10.90
E.ROOT-SERVERS.NET      internet address = 192.203.230.10
I.ROOT-SERVERS.NET      internet address = 192.36.148.17
F.ROOT-SERVERS.NET      internet address = 192.5.5.241
G.ROOT-SERVERS.NET      internet address = 192.112.36.4
</code></pre></blockquote>
<p>Nous apprenons ainsi que tous les serveurs
<code>ROOT-SERVERS.NET</code> servent le domaine <code>edu.</code>;
nous pouvons donc continuer en les interrogeant tous. Nous
continuerons en interrogeant <code>C</code>. Maintenant, nous
voulons savoir qui sert le niveau suivant du nom de domaine&nbsp;:
<code>mit.edu.</code>&nbsp;:</p>
<blockquote>
<pre><code>
&gt; mit.edu.
Server:  c.root-servers.net
Address:  192.33.4.12

Non-authoritative answer:
mit.edu nameserver = STRAWB.mit.edu
mit.edu nameserver = W20NS.mit.edu
mit.edu nameserver = BITSY.mit.edu

Authoritative answers can be found from:
STRAWB.mit.edu  internet address = 18.71.0.151
W20NS.mit.edu   internet address = 18.70.0.160
BITSY.mit.edu   internet address = 18.72.0.3
</code></pre></blockquote>
<p><code>strawb</code>, <code>w20ns</code> et <code>bitsy</code>
servent tous le domaine <code>mit</code>, prenons-en un au hasard
et posons-lui la question au sujet d'un domaine encore plus
précis&nbsp;: <code>ai.mit.edu</code>&nbsp;:</p>
<blockquote>
<pre><code>
&gt; server W20NS.mit.edu.
</code></pre></blockquote>
<p>On ne distingue pas majuscules et minuscules pour les noms de
domaine, et comme j'utilise ma souris pour faire du copier-coller,
vous lisez les choses dans ce document telles qu'elles apparaissent
sur mon écran.</p>
<blockquote>
<pre><code>
Server:  W20NS.mit.edu
Address:  18.70.0.160

&gt; ai.mit.edu.
Server:  W20NS.mit.edu
Address:  18.70.0.160

Non-authoritative answer:
ai.mit.edu      nameserver = ALPHA-BITS.AI.MIT.EDU
ai.mit.edu      nameserver = GRAPE-NUTS.AI.MIT.EDU
ai.mit.edu      nameserver = TRIX.AI.MIT.EDU
ai.mit.edu      nameserver = MUESLI.AI.MIT.EDU
ai.mit.edu      nameserver = LIFE.AI.MIT.EDU
ai.mit.edu      nameserver = BEET-CHEX.AI.MIT.EDU
ai.mit.edu      nameserver = MINI-WHEATS.AI.MIT.EDU
ai.mit.edu      nameserver = COUNT-CHOCULA.AI.MIT.EDU
ai.mit.edu      nameserver = MINTAKA.LCS.MIT.EDU

Authoritative answers can be found from:
AI.MIT.EDU      nameserver = ALPHA-BITS.AI.MIT.EDU
AI.MIT.EDU      nameserver = GRAPE-NUTS.AI.MIT.EDU
AI.MIT.EDU      nameserver = TRIX.AI.MIT.EDU
AI.MIT.EDU      nameserver = MUESLI.AI.MIT.EDU
AI.MIT.EDU      nameserver = LIFE.AI.MIT.EDU
AI.MIT.EDU      nameserver = BEET-CHEX.AI.MIT.EDU
AI.MIT.EDU      nameserver = MINI-WHEATS.AI.MIT.EDU
AI.MIT.EDU      nameserver = COUNT-CHOCULA.AI.MIT.EDU
AI.MIT.EDU      nameserver = MINTAKA.LCS.MIT.EDU
ALPHA-BITS.AI.MIT.EDU   internet address = 128.52.32.5
GRAPE-NUTS.AI.MIT.EDU   internet address = 128.52.36.4
TRIX.AI.MIT.EDU internet address = 128.52.37.6
MUESLI.AI.MIT.EDU       internet address = 128.52.39.7
LIFE.AI.MIT.EDU internet address = 128.52.32.80
BEET-CHEX.AI.MIT.EDU    internet address = 128.52.32.22
MINI-WHEATS.AI.MIT.EDU  internet address = 128.52.54.11
COUNT-CHOCULA.AI.MIT.EDU        internet address = 128.52.38.22
MINTAKA.LCS.MIT.EDU     internet address = 18.26.0.36
</code></pre></blockquote>
<p>Ainsi, <code>muesli.ai.mit.edu</code> est un serveur de noms
pour le domaine <code>ai.mit.edu</code>&nbsp;:</p>
<blockquote>
<pre><code>
&gt; server MUESLI.AI.MIT.EDU
Default Server:  MUESLI.AI.MIT.EDU
Address:  128.52.39.7
</code></pre></blockquote>
<p>Changeons le type de requête. Nous avons réussi à trouver le
serveur de noms, nous allons maintenant demander tout ce que
<code>muesli</code> sait sur le domaine
<code>prep.ai.mit.edu</code>.</p>
<blockquote>
<pre><code>
&gt; set q=any
&gt; prep.ai.mit.edu.
Server:  MUESLI.AI.MIT.EDU
Address:  128.52.39.7

prep.ai.mit.edu CPU = dec/decstation-5000.25    OS = unix
prep.ai.mit.edu
        inet address = 18.159.0.42, protocol = tcp
          ftp  telnet  smtp  finger
prep.ai.mit.edu preference = 1, mail exchanger = gnu-life.ai.mit.edu
prep.ai.mit.edu internet address = 18.159.0.42
ai.mit.edu      nameserver = beet-chex.ai.mit.edu
ai.mit.edu      nameserver = alpha-bits.ai.mit.edu
ai.mit.edu      nameserver = mini-wheats.ai.mit.edu
ai.mit.edu      nameserver = trix.ai.mit.edu
ai.mit.edu      nameserver = muesli.ai.mit.edu
ai.mit.edu      nameserver = count-chocula.ai.mit.edu
ai.mit.edu      nameserver = mintaka.lcs.mit.edu
ai.mit.edu      nameserver = life.ai.mit.edu
gnu-life.ai.mit.edu     internet address = 128.52.32.60
beet-chex.ai.mit.edu    internet address = 128.52.32.22
alpha-bits.ai.mit.edu   internet address = 128.52.32.5
mini-wheats.ai.mit.edu  internet address = 128.52.54.11
trix.ai.mit.edu internet address = 128.52.37.6
muesli.ai.mit.edu       internet address = 128.52.39.7
count-chocula.ai.mit.edu        internet address = 128.52.38.22
mintaka.lcs.mit.edu     internet address = 18.26.0.36
life.ai.mit.edu internet address = 128.52.32.80
</code></pre></blockquote>
<p>En commençant à partir de <code>.</code>, nous avons
successivement trouvé les serveurs de noms des différents niveaux
du nom de domaine. Si vous aviez utilisé votre propre serveur DNS à
la place de tous ces autres serveurs, votre <code>named</code>
aurait, bien sûr, caché toutes ces informations et il n'aurait plus
eu besoin de les redemander pendant un certain temps.</p>
<p>Si l'on revient a l'analogie avec les arbres, chaque
``<code>.</code>'' dans le nom est un embranchement. Et chaque nom
entre deux <code>.</code> est une branche de l'arbre.</p>
<p>Grimpons ensemble dans l'arbre en prenant le nom que nous
voulons (<code>prep.ai.mit.edu</code>). On part de la racine
(<code>.</code>), on regarde ensuite dans quelle branche grimper,
dans notre cas, <code>edu</code>. Dès qu'on l'a trouvée, on y
grimpe en passant par le serveur qui connaît cette partie du nom.
Ensuite, assis sur la branche <code>edu</code>, on cherche la
branche <code>mit</code> (le nom combiné est <code>mit.edu</code>),
puis la branche <code>ai.mit.edu</code>. Maintenant, on est sur le
bon serveur, au bon embranchement. La dernière partie est de
trouver <code>prep.ai.mit.edu</code>, ce qui est très simple. En
informatique fondamentale, on appelle <code>prep</code> une
<em>feuille</em> de l'arbre.</p>
<p>Un domaine dont on parle beaucoup moins, mais qui n'en est pas
moins important, est <code>in-addr.arpa</code>. Ce domaine trouve
sa place dans la hiérarchie des noms de domaine comme un domaine
``normal''. <code>in-addr.arpa</code> nous sert à obtenir le nom
d'hôte connaissant l'adresse IP d'une machine. Une chose très
importante ici est de bien remarquer que les adresses IP sont
notées en sens inverse à l'intérieur du domaine
<code>in-addr.arpa</code>. Si vous avez l'adresse d'une
machine&nbsp;: <code>192.128.52.43</code>, <code>named</code>
procède exactement comme dans l'exemple de
<code>prep.ai.mit.edu</code>&nbsp;: il trouve les serveurs pour
<code>in-addr.arpa.</code>, trouve les serveurs pour
<code>192.in-addr.arpa.</code>, trouve les serveurs pour
<code>128.192.in-addr.arpa.</code>, et finalement trouve les
serveurs pour <code>52.128.192.in-addr.arpa.</code> . On obtient
bien ainsi l'information liée à
<code>43.52.128.192.in-addr.arpa.</code> Malin, n'est ce pas&nbsp;?
(dites oui). En fait, la résolution de noms inverse est assez
difficile à admettre les premières années.</p>
<p>À vrai dire, je vous ai menti. Le service DNS ne marche pas
vraiment comme ça. Mais ce que je vous ai dit est suffisamment
proche de la réalité.</p>
<h2><a name="ss4.2">4.2 Notre propre domaine</a></h2>
<p>Maintenant, nous en sommes à définir notre propre domaine bien à
nous. Nous allons créer le domaine <code>linux.bogus</code> et y
déclarer quelques machines. C'est un nom de domaine totalement
factice, afin d'être sûr de ne déranger personne dans le Vaste
Monde.</p>
<p>Encore une chose avant de commencer. Tous les caractères ne sont
pas admis dans les noms de machines. On ne doit utiliser que les
caractères de l'alphabet anglais (a-z), les nombres (0-9) et le
tiret ``-''. Utilisez ces caractères, majuscules et minuscules sont
confondues, donc <code>pat.uio.no</code> est identique à
<code>Pat.UiO.No</code>.</p>
<p>En fait, nous avons déjà commencé à créer notre propre domaine
avec cette ligne dans <code>named.conf</code>:</p>
<hr>
<pre>
zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};
</pre>
<hr>
<p>Notez bien l'absence de ``<code>.</code>'' à la fin des noms de
domaine de ce fichier. Elle signifie que nous allons définir la
zone <code>0.0.127.in-addr.arpa</code>, que nous sommes son serveur
principal et que tout est stocké dans un fichier appelé
<code>pz/127.0.0</code>. On a déjà vu ce fichier, il se présente
comme ceci&nbsp;:</p>
<hr>
<pre>
@               IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                                1       ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                1W      ; Expire
                                1D)     ; Minimum TTL
                        NS      ns.linux.bogus.
1                       PTR     localhost.
</pre>
<hr>
<p>Notez bien le ``<code>.</code>'' à la fin de tous les noms de
domaine complets de ce fichier, contrairement au fichier
<code>named.boot</code>. Certaines personnes aiment commencer
chaque fichier définissant une zone par une directive
<code>$ORIGIN</code>, mais en fait c'est superflu. L'origine
(l'emplacement dans la hiérarchie du service DNS) d'un fichier de
zone est indiquée dans la zone section du fichier
<code>named.conf</code>. Dans notre cas, c'est
<code>0.0.127.in-addr.arpa</code>.</p>
<p>Ce ``fichier de zone'' (``zone file''), contient 3 ``resource
records'' (RRs)&nbsp;: un SOA RR, un NS RR et un PTR RR. SOA est
l'abréviation de ``Start Of Authority'' (Origine de l'Autorité). Le
``@'' est une notation spéciale qui désigne l'origine. Et comme la
colonne ``domain'' de ce fichier donne
<code>0.0.127.in-addr.arpa</code>, la première ligne signifie
donc&nbsp;:</p>
<blockquote>
<pre><code>
0.0.127.IN-ADDR.ARPA. IN SOA ...
</code></pre></blockquote>
<p>NS est le ``resource records'' pour le serveur de noms (NS =
Name Server), Il n'y a pas de @ au début de la ligne, il est
implicite, puisque la ligne d'avant commence avec un ``@''. Alors,
faites-vous une fleur en omettant ce caractère. Donc, la ligne NS
peut aussi s'écrire comme suit&nbsp;:</p>
<blockquote>
<pre><code>
0.0.127.in-addr.arpa.   IN      NS      ns.linux.bogus
</code></pre></blockquote>
<p>Elle dit au service DNS quelle machine est le serveur de noms
pour le domaine <code>0.0.127.in-addr.arpa</code>, c'est
<code>ns.linux.bogus</code>. <code>ns</code> est le nom habituel
des serveurs de noms, tout comme <code>www.</code> pour les
serveurs Web, mais c'est simplement une habitude, on peut choisir
n'importe quel nom.</p>
<p>Et finalement le PTR dit que l'adresse 1 dans le sous réseau
<code>0.0.127.in-addr.arpa</code>, donc 127.0.0.1 est appelé
<code>localhost</code>.</p>
<p>Le champ SOA est le préambule de <em>tous</em> les fichiers de
zone, et il doit y en avoir exactement un dans chaque fichier de
zone. Ce champ SOA décrit la zone, son origine (une machine appelée
<code>ns.linux.bogus</code>), qui est responsable de son contenu
(<code>hostmaster@linux.bogus</code>, vous devriez mettre votre
adresse email à cet endroit), de quelle version du fichier de zone
il s'agit (serial&nbsp;: 1), et quelques autres paramètres pour le
cache et les serveurs DNS secondaires. Quant aux champs restants
(<em>refresh</em>, <em>retry</em>, <em>expire</em> et
<em>minimum</em>) utilisez les valeurs données dans ce HOWTO et
tout se passera certainement très bien.</p>
<p>Maintenant, relancez votre <code>named</code> (avec la commande
<code>ndc restart</code>) et utilisez <code>nslookup</code> pour
regarder le résultat&nbsp;:</p>
<blockquote>
<pre><code>
$ nslookup

Default Server:  localhost
Address:  127.0.0.1

&gt; 127.0.0.1
Server:  localhost
Address:  127.0.0.1

Name:    localhost
Address:  127.0.0.1
</code></pre></blockquote>
<p>Tout va bien, on arrive à obtenir <code>localhost</code> à
partir de 127.0.0.1. Maintenant, pour le sujet qui nous préoccupe,
le domaine <code>linux.bogus</code>, insérez une nouvelle zone dans
le fichier <code>named.conf</code>&nbsp;:</p>
<hr>
<pre>
zone "linux.bogus" {
        notify no;
        type master;
        file "pz/linux.bogus";
};
</pre>
<hr>
<p>Notez qu'encore une fois il n'y a pas de ``<code>.</code>'' à la
fin des noms de domaine dans le fichier
<code>named.conf</code>.</p>
<p>Dans le fichier de zone <code>linux.bogus</code>, nous allons
mettre quelques données totalement factices&nbsp;:</p>
<hr>
<pre>
;
; Zone file for linux.bogus
;
; The full zone file
;
@       IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                        199802151       ; serial, todays date + todays serial #
                        8H              ; refresh, seconds
                        2H              ; retry, seconds
                        1W              ; expire, seconds
                        1D )            ; minimum, seconds
;
                NS      ns              ; Inet Address of name server
                MX      10 mail.linux.bogus     ; Primary Mail Exchanger
                MX      20 mail.friend.bogus.   ; Secondary Mail Exchanger
;
localhost       A       127.0.0.1
ns              A       192.168.196.2
mail            A       192.168.196.4
</pre>
<hr>
<p>Il y a deux choses à noter à propos du champ SOA.
<code>ns.linux.bogus</code> <em>doit absolument</em> être une vraie
machine possédant un champ A. Il n'est pas légal d'avoir un champ
CNAME pour la machine mentionnée dans le champ SOA. Il n'est pas
nécessaire que son nom soit ``ns'', ce peut être tout autre nom
valide. La deuxième chose à noter c'est que
<code>hostmaster.linux.bogus</code> doit se lire comme
<code>hostmaster@linux.bogus</code>. Ce doit être un alias de mail,
ou une véritable boîte aux lettres électronique, et la personne qui
maintient le DNS doit la lire régulièrement. Tous les mails
concernant l'administration du domaine seront envoyés à cette
adresse. Il n'est pas obligatoire que le nom soit ``hostmaster'',
vous pouvez mettre votre adresse e-mail personnelle, mais il serait
bon que l'adresse ``hostmaster'' fonctionne aussi.</p>
<p>Il y a un nouveau RR (Resource Record) dans ce fichier, c'est le
MX, pour Mail eXchanger. Il indique aux systèmes de gestion du
courrier électronique à quelle machine envoyer le mail adressé à
<code>someone@linux.bogus</code>, dans notre cas à
<code>mail.linux.bogus</code> ou <code>mail.friend.bogus</code>. Le
nombre devant chaque machine est sa priorité vis-à-vis du champ MX,
le RR avec le numéro le plus faible (10) correspond à la machine à
laquelle le courrier doit être adressé en priorité. En cas d'échec,
il peut être adressé à la machine qui a le numéro de priorité
immédiatement supérieur, c'est-à-dire
<code>mail.friend.bogus</code> qui a une priorité de 20 dans notre
cas.</p>
<p>Relancez <code>named</code> en tapant <code>ndc restart</code>.
Examinons le résultat avec nslookup&nbsp;:</p>
<blockquote>
<pre><code>
$ nslookup
&gt; set q=any
&gt; linux.bogus
Server:  localhost
Address:  127.0.0.1

linux.bogus
        origin = ns.linux.bogus
        mail addr = hostmaster.linux.bogus
        serial = 199802151
        refresh = 28800 (8 hours)
        retry   = 7200 (2 hours)
        expire  = 604800 (7 days)
        minimum ttl = 86400 (1 day)
linux.bogus     nameserver = ns.linux.bogus
linux.bogus     preference = 10, mail exchanger = mail.linux.bogus.linux.bogus
linux.bogus     preference = 20, mail exchanger = mail.friend.bogus
linux.bogus     nameserver = ns.linux.bogus
ns.linux.bogus  internet address = 192.168.196.2
mail.linux.bogus        internet address = 192.168.196.4
</code></pre></blockquote>
<p>Un examen approfondi vous montrera qu'il y a un bug. En effet,
la ligne</p>
<blockquote>
<pre><code>
  linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus
</code></pre></blockquote>
<p>est entièrement fausse. Il devrait y avoir</p>
<blockquote>
<pre><code>
  linux.bogus preference = 10, mail exchanger = mail.linux.bogus
</code></pre></blockquote>
<p>J'ai fait cette erreur délibérément, pour voir si vous
suiviez&nbsp;:-) En regardant dans le fichier de zone, nous
trouvons que dans la ligne</p>
<blockquote>
<pre><code>
@ MX 10 mail.linux.bogus ; Primary Mail Exchanger
</code></pre></blockquote>
<p>il manque un point. Ou il y a un ``linux.bogus'' de trop. Si,
dans un fichier de zone, un nom de machine ne se termine pas par un
point, l'origine est ajoutée au nom de la machine. Ainsi, une des
deux formes&nbsp;:</p>
<hr>
<pre>
                MX      10 mail.linux.bogus.    ; Primary Mail Exchanger
</pre>
<hr>
<p>ou</p>
<hr>
<pre>
                MX      10 mail                 ; Primary Mail Exchanger
</pre>
<hr>
<p>est correcte. Je préfère la deuxième forme parce qu'il y a moins
de caractères à taper. Certains approuveront, d'autres non. Dans un
fichier de zone, le nom de domaine doit ou bien être écrit et
terminé par un point, ou bien ne pas être inclus du tout. Dans le
dernier cas, le nom de domaine par défaut est l'origine.</p>
<p>Il faut que j'insiste sur le point suivant&nbsp;: dans le
fichier <code>named.conf</code>, il ne doit <em>pas</em> y avoir de
``<code>.</code>'' après les noms de domaines. Vous ne pouvez pas
vous imaginer les ravages qui ont été causés pas des
``<code>.</code>'' en trop ou en moins.</p>
<p>Cela étant dit, voici le nouveau fichier de zone, avec quelques
informations supplémentaires&nbsp;:</p>
<hr>
<pre>
;
; Zone file for linux.bogus
;
; The full zone file
;
@       IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                        199802151       ; serial, todays date + todays serial #
                        8H              ; refresh, seconds
                        2H              ; retry, seconds
                        1W              ; expire, seconds
                        1D )            ; minimum, seconds
;
                TXT     "Linux.Bogus, your DNS consultants"
                NS      ns              ; Inet Address of name server
                NS      ns.friend.bogus.
                MX      10 mail         ; Primary Mail Exchanger
                MX      20 mail.friend.bogus. ; Secondary Mail Exchanger

localhost       A       127.0.0.1

gw              A       192.168.196.1
                HINFO   "Cisco" "IOS"
                TXT     "The router"

ns              A       192.168.196.2
                MX      10 mail
                MX      20 mail.friend.bogus.
                HINFO   "Pentium" "Linux 2.0"
www             CNAME   ns

donald          A       192.168.196.3
                MX      10 mail
                MX      20 mail.friend.bogus.
                HINFO   "i486"  "Linux 2.0"
                TXT     "DEK"

mail            A       192.168.196.4
                MX      10 mail
                MX      20 mail.friend.bogus.
                HINFO   "386sx" "Linux 1.2"

ftp             A       192.168.196.5
                MX      10 mail
                MX      20 mail.friend.bogus.
                HINFO   "P6" "Linux 2.1.86"
</pre>
<hr>
<p>Il y a un certain nombre de nouveaux RR que nous allons passer
en revue&nbsp;: HINFO (Host INFOrmation), qui est en deux parties,
et c'est une bonne habitude à prendre que d'encadrer chacune de
guillemets. La première partie est la description matérielle ou le
type de processeur de la machine tandis que la deuxième partie
décrit le logiciel utilisé ou le système d'exploitation de la
machine. ns a pour processeur un Pentium et tourne sous Linux 2.0.
Le champ CNAME (Canonical NAME) sert à donner plusieurs noms à la
même machine. Par conséquent, <code>www</code> est un alias de
<code>ns</code>.</p>
<p>L'utilisation des champs CNAME est assez controversée. Mais il
est sage de suivre la règle selon laquelle un champ MX, CNAME ou
SOA ne doit <em>jamais</em> se référer à un champ CNAME, toujours
se référer à un champ A, il est donc préférable de ne pas
avoir&nbsp;:</p>
<hr>
<pre>
foobar          CNAME   www                     ; NON !
</pre>
<hr>
<p>En revanche, ceci est correct&nbsp;:</p>
<hr>
<pre>
foobar          CNAME   ns                      ; Oui !
</pre>
<hr>
<p>Il est aussi important de noter qu'un CNAME n'est pas un nom
d'hôte légal pour une adresse de courrier électronique.
<code>webmaster@www.linux.bogus</code> est une adresse de mail
illégale avec la configuration ci-dessus. Vous pouvez être sûrs
qu'il y a un certain nombre d'administrateurs système dans le Vaste
Monde qui sont très à cheval sur cette règle, même si avec un CNAME
ça marche pour vous. Une façon de contourner le problème est
d'utiliser des champs A (et peut-être d'autres, comme un champ MX
par exemple) à la place&nbsp;:</p>
<hr>
<pre>
www             A       192.168.196.2
</pre>
<hr>
<p>Un certain nombre de gourous-du-bind recommandent de ne
<em>pas</em> utiliser de CNAME. Mais les discussions sur le pour et
le contre sortent du cadre de ce HOWTO.</p>
<p>Mais comme vous le voyez, ce HowTo ainsi que beaucoup de
serveurs ne suivent pas cette règle.</p>
<p>Chargez la nouvelle base de données en lançant <code>ndc
reload</code>, ce qui forcera <code>named</code> à relire ses
fichiers de configuration.</p>
<blockquote>
<pre><code>
$ nslookup
Default Server:  localhost
Address:  127.0.0.1

&gt; ls -d linux.bogus
</code></pre></blockquote>
<p>Ceci veut dire que l'on souhaite que tous les champs soient
affichés.</p>
<blockquote>
<pre><code>
[localhost]
$ORIGIN linux.bogus.
@                       1D IN SOA       ns hostmaster (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        1W              ; expiry
                                        1D )            ; minimum

                        1D IN NS        ns
                        1D IN NS        ns.friend.bogus.
                        1D IN TXT       "Linux.Bogus, your DNS consultants"
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.bogus.
gw                      1D IN A         192.168.196.1
                        1D IN HINFO     "Cisco" "IOS"
                        1D IN TXT       "The router"
mail                    1D IN A         192.168.196.4
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.bogus.
                        1D IN HINFO     "386sx" "Linux 1.0.9"
localhost               1D IN A         127.0.0.1
www                     1D IN CNAME     ns
donald                  1D IN A         192.168.196.3
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.bogus.
                        1D IN HINFO     "i486" "Linux 1.2"
                        1D IN TXT       "DEK"
ftp                     1D IN A         192.168.196.5
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.bogus.
                        1D IN HINFO     "P6" "Linux 1.3.59"
ns                      1D IN A         192.168.196.2
                        1D IN MX        10 mail
                        1D IN MX        20 mail.friend.bogus.
                        1D IN HINFO     "Pentium" "Linux 1.2"
</code></pre></blockquote>
<p>Tout va bien. Regardons ce qu'il dit pour <code>www</code> tout
seul&nbsp;:</p>
<blockquote>
<pre><code>
&gt; set q=any  
&gt; www.linux.bogus.
Server:  localhost
Address:  127.0.0.1

www.linux.bogus canonical name = ns.linux.bogus
linux.bogus     nameserver = ns.linux.bogus
linux.bogus     nameserver = ns.friend.bogus
ns.linux.bogus  internet address = 192.168.196.2
</code></pre></blockquote>
<p>En d'autres termes, le vrai nom de <code>www.linux.bogus</code>
est <code>ns.linux.bogus</code>, et vous avez en plus quelques
informations à propos de ns, en fait, suffisamment pour vous y
connecter si vous étiez un programme.</p>
<p>Bon, on a fait la moitié du boulot.</p>
<h2><a name="ss4.3">4.3 La zone inversée</a></h2>
<p>Ça y est, les programmes peuvent convertir les noms de
<code>linux.bogus</code> en adresses auxquelles ils peuvent se
connecter. Maintenant, on a besoin d'une zone inversée pour que
l'on puisse retrouver le DNS à partir de l'adresse. Ce nom est
utilisé par différents types de serveurs (FTP, IRC, WWW et autres)
pour décider s'ils vont discuter avec vous ou non, et s'ils le
font, quelle priorité ils vont vous donner. Pour un accès complet
aux services sur Internet, la zone inversée est indispensable.</p>
<p>Mettez ça dans votre <code>named.conf</code></p>
<hr>
<pre>
zone "196.168.192.in-addr.arpa" {
        notify no;
        type master;
        file "pz/192.168.196";
};
</pre>
<hr>
<p>C'est exactement comme pour le <code>0.0.127.in-addr.arpa</code>
et le contenu est similaire&nbsp;:</p>
<hr>
<pre>
@       IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
                        199802151 ; Serial, todays date + todays serial
                        8H      ; Refresh
                        2H      ; Retry
                        1W      ; Expire
                        1D)     ; Minimum TTL
                NS      ns.linux.bogus.

1               PTR     gw.linux.bogus.
2               PTR     ns.linux.bogus.
3               PTR     donald.linux.bogus.
4               PTR     mail.linux.bogus.
5               PTR     ftp.linux.bogus.
</pre>
<hr>
<p>Redémarrez votre <code>named</code> (<code>ndc restart</code>)
et examinez votre travail avec nslookup&nbsp;:</p>
<hr>
<pre>
&gt; 192.168.196.4
Server:  localhost
Address:  127.0.0.1

Name:    mail.linux.bogus
Address:  192.168.196.4
</pre>
<hr>
<p>On dirait que c'est bon, on va regarder en détails pour s'en
assurer&nbsp;:</p>
<hr>
<pre>
&gt; ls -d 196.168.192.in-addr.arpa
[localhost]
$ORIGIN 196.168.192.in-addr.arpa.
@                       1D IN SOA       ns.linux.bogus. hostmaster.linux.bogus. (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        1W              ; expiry
                                        1D )            ; minimum

                        1D IN NS        ns.linux.bogus.
1                       1D IN PTR       gw.linux.bogus.
2                       1D IN PTR       ns.linux.bogus.
3                       1D IN PTR       donald.linux.bogus.
4                       1D IN PTR       mail.linux.bogus.
5                       1D IN PTR       ftp.linux.bogus.
@                       1D IN SOA       ns.linux.bogus. hostmaster.linux.bogus. (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        1W              ; expiry
                                        1D )            ; minimum
</pre>
<hr>
<p>Pas mal&nbsp;! Si ce que vous donne nslookup ne ressemble pas a
ça, allez a la pêche aux messages d'erreur dans votre syslog. J'ai
expliqué comment faire au tout début du chapitre.</p>
<h2><a name="ss4.4">4.4 Précautions d'usage</a></h2>
<p>Je devrais maintenant faire quelques remarques. Les adresses IP
utilisées dans les exemples précédents sont prises dans le bloc des
``réseaux privés'', c'est à dire des adresses qui ne doivent pas
être utilisées publiquement sur Internet. Donc, il est sage de les
avoir utilisées dans un exemple d'un HowTo. La deuxième chose est
la ligne <code>notify no;</code>. Elle demande à <code>named</code>
de ne pas informer ses serveur secondaires (les esclaves) quand
l'un de ses fichiers de zone a été mis à jour. Depuis Bind-8
<code>named</code> peut informer les autres serveurs listés dans
ses champs NS dans le fichier zone, quand une zone est mise a jour.
C'est pratique pour une utilisation normale, mais pour des
expériences privées cette fonctionnalité doit être mise hors
service, on ne va quand même pas polluer Internet avec nos
expériences, non&nbsp;?</p>
<p>Bien sûr, ce domaine est très factice, tout comme le sont ses
adresses. C'est peut-être un peu déroutant pour vous. Un vrai
exemple tiré d'un vrai domaine vous attend au grand chapitre
suivant.</p>
<h2><a name="ss4.5">4.5 Pourquoi est-ce que les lookup inversés ne
marchent pas&nbsp;?</a></h2>
<p>Il y a quelques trucs qui sont normalement évités avec les
lookups qui arrivent souvent quand on met en place des zones
inversés. Avant de continuer, vous avez besoin d'avoir des lookups
qui marchent sur vos propres serveurs de noms. Si ce n'est pas le
cas, revenez en arrière et réparez-le avant de continuer.</p>
<p>Je parlerais des deux problèmes de lookups inversés qui sont vu
de l'extérieur de votre réseau&nbsp;:</p>
<h3>La zone inverse n'est pas déléguée.</h3>
<p>Quand vous demandez à un fournisseur d'accès quelques adresses
IP ainsi qu'un nom de domaine, le nom de domaine vous est
normalement délégué. La délégation consiste en un champ
<code>NS</code> qui vous aide a passer d'un serveur à l'autre comme
je l'ai expliqué dans le brin de théorie qui précède. Vous l'avez
lu, n'est-ce pas&nbsp;? Si votre zone inversée ne marche pas,
retournez y et lisez-le. Maintenant.</p>
<p>La zone inversée a elle aussi besoin d'être déléguée. Si vous
avez le réseau <code>192.168.196</code> avec le domaine
<code>linux.bogus</code> de votre fournisseur, il devra mettre des
champs <code>NS</code> pour votre zone inversée aussi bien que pour
votre zone directe. Si vous remontez la chaîne à partir de
<code>in-addr.arpa</code> vous trouverez un trou quelque part. Très
certainement au niveau de votre fournisseur. Après avoir trouvé le
trou dans la chaîne, contactez votre fournisseur et demandez-lui de
corriger l'erreur.</p>
<h3>Vous avez un sous-réseau sans classe</h3>
<p>C'est un sujet plutôt pointu, mais les sous réseaux sans classe
sont très répandus de nos jours et vous en aurez très certainement
un si vous n'êtes pas une entreprise assez grande.</p>
<p>Un sous-réseau sans classe est ce qui sauve Internet de nos
jours. Il y a quelques années, il y avait vraiment beaucoup de
discussions sur la raréfaction des adresses IP. Les personnes
intelligentes de l'IETF (Internet Engineering Task Force, ceux qui
maintiennent Internet en état de marche) se sont penchées sur cet
épineux problème et ont trouvé une solution. A un certain prix. Le
prix est que vous aurez moins qu'un sous réseau de classe ``C'' et
que certaines choses ne marcheront certainement plus. Allez voir
<a href="http://www.acmebw.com/askmrdns/00007.htm">Ask Mr DNS</a>
(c'est en anglais) pour plus d'explications.</p>
<p>Vous l'avez lu&nbsp;? Comme je ne vais pas l'expliquer, s'il
vous plaît, allez le lire.</p>
<p>La première partie du problème est que votre FAI doit comprendre
la technique décrite par <em>Mr DNS</em>. Tous les petits FAI ne le
comprennent pas. S'ils n'ont pas bien compris, vous allez avoir à
leur expliquer et à insister. Mais assurez-vous de comprendre
vous-même en premier lieu&nbsp;;-). Ils mettrons ensuite une jolie
zone inversée sur leurs serveurs que vous pourrez examiner pour
savoir si elle est correcte avec <code>nslookup</code>.</p>
<p>La deuxième et dernière partie du problème est que vous devez en
comprendre la technique. Si vous n'êtes pas certain, revenez en
arrière et relisez ce document. Ensuite, vous pourrez mettre en
place une zone inversée sans classe comme le décrit <em>Mr
DNS</em>.</p>
<p>Il y a une autre difficulté qui pointe son nez ici. Les vieux
résolveurs <em>ne seront pas</em> capable de suivre les champs
<code>CNAME</code> dans la chaîne de résolution et n'arriveront pas
a résoudre l'IP de votre machine. Cela peut entraîner l'assignation
d'une mauvaise classe, la non-résolution ou quelque chose dans ce
goût-là. Si vous butez sur ce genre de problème, la seule solution
(que je connaisse) est de demander à votre FAI d'insérer vos champs
<code>PTR</code> dans ses fichiers de zone sans classe plutôt que
des champs <code>CNAME</code>.</p>
<p>Certains FAI vous proposeront d'autre méthodes pour gérer cela,
comme des formulaires web où vous pourrez entrer vos zones
inversées, ou d'autre systèmes automatisés.</p>
<h2><a name="real-example"></a> <a name="s5">5. Un exemple tiré
d'un domaine réel</a></h2>
<p><b>Où nous allons enfin voir de <em>vrais</em> fichiers de
zone</b></p>
<p>Certains utilisateurs ont suggéré que je mette un vrai exemple
d'un domaine qui marche dans la réalité car mon explication sur la
différence entre un vrai domaine et l'exemple bidon ci-dessus
n'était pas très claire.</p>
<p>J'utilise cet exemple avec la permission de David Bullock de
LAND-5. Ces fichiers étaient à jour le 24 Septembre 96, et ont été
modifiée pour être utilisés avec les restrictions de bind 8 et
quelques extensions de mon cru. Par conséquent, ils peuvent donc
différer de ce que vous pouvez trouver en questionnant les serveurs
de nom de LAND-5 aujourd'hui.</p>
<p>Voici les sections pour les deux zones inversées
nécessaires&nbsp;: le réseau <code>127.0.0</code>, ainsi que le
sous-réseau LAND-5 <code>206.6.177</code>. Et une ligne primary
pour la forward zone <code>land-5.com</code>. Notez aussi qu'au
lieu de mettre les fichiers dans le répertoire <code>pz</code>
comme dans ce HowTo, il les met dans le répertoire
<code>zone</code>.</p>
<h2><a name="ss5.1">5.1 /etc/named.conf (ou
/var/named/named.conf)</a></h2>
<hr>
<pre>
// Boot file for LAND-5 name server

options {
        directory "/var/named";
};

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

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

zone "land-5.com" {
        type master;
        file "zone/land-5.com";
};

zone "177.6.206.in-addr.arpa" {
        type master;
        file "zone/206.6.177";
};
</pre>
<hr>
<p>Si vous mettez ça dans votre <code>named.conf</code> pour jouer
avec, <b>PAR PITIÉ</b> mettez aussi le ``<code>notify no;</code>''
dans les zones des deux <code>land-5.com</code> pour éviter les
accidents.</p>
<h2><a name="ss5.2">5.2 /var/named/root.hints</a></h2>
<p>Souvenez-vous que le contenu de ce fichier peut changer, et
celui donné ici est assez vieux. Vous feriez mieux d'utiliser un
fichier plus récent, produit par le programme <code>dig</code>.</p>
<hr>
<pre>
; &lt;&lt;&gt;&gt; DiG 8.1 &lt;&lt;&gt;&gt; @A.ROOT-SERVERS.NET. 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;;      ., type = NS, class = IN

;; ANSWER SECTION:
.                       6D IN NS        G.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.
.                       6D IN NS        A.ROOT-SERVERS.NET.
.                       6D IN NS        H.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        I.ROOT-SERVERS.NET.
.                       6D IN NS        F.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
G.ROOT-SERVERS.NET.     5w6d16h IN A    192.112.36.4
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
A.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.4
H.ROOT-SERVERS.NET.     5w6d16h IN A    128.63.2.53
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
I.ROOT-SERVERS.NET.     5w6d16h IN A    192.36.148.17
F.ROOT-SERVERS.NET.     5w6d16h IN A    192.5.5.241

;; Total query time: 215 msec
;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET.  198.41.0.4
;; WHEN: Sun Feb 15 01:22:51 1998
;; MSG SIZE  sent: 17  rcvd: 436
</pre>
<hr>
<h2><a name="ss5.3">5.3 /var/named/zone/127.0.0</a></h2>
<p>Nous y avons mis juste l'essentiel, le champ SOA obligatoire, et
un champ qui établit la correspondance entre 127.0.0.1 et
<code>localhost</code>. Ils sont tous les deux indispensables. Rien
d'autre ne doit figurer dans ce fichier. Il ne sera probablement
jamais nécessaire de le mettre à jour, à moins que l'adresse du
serveur de noms ou de hostmaster ne change.</p>
<hr>
<pre>
@               IN      SOA     land-5.com. root.land-5.com. (
                                199609203       ; Serial
                                28800   ; Refresh
                                7200    ; Retry
                                604800  ; Expire
                                86400)  ; Minimum TTL
                        NS      land-5.com.
        
1                       PTR     localhost.
</pre>
<hr>
<h2><a name="ss5.4">5.4 /var/named/zone/land-5.com</a></h2>
<p>Nous trouvons ici le classique et obligatoire champ SOA ainsi
que les champs NS. Nous pouvons voir qu'il y a un serveur de noms
secondaire <code>ns2.psi.net</code>. C'est comme ça que tout le
monde devrait faire&nbsp;: <em>toujours</em> avoir un serveur
secondaire sur un site distant pour faire des sauvegardes. Nous
voyons également que le serveur primaire est <code>land-5</code>,
qui assure tous les services, et que l'administrateur a utilisé des
CNAME pour faire ça (il aurait pu utiliser des champs A).</p>
<p>Comme vous pouvez voir d'après le champ SOA, le fichier de zone
a son origine en <code>land-5.com</code>, la personne à contacter
est <code>root@land-5.com</code>. <code>hostmaster</code> est une
autre adresse souvent utilisée pour la personne à contacter. Le
numéro de série est au format obligatoire aaaammjj, avec le numéro
de série dans la journée ajouté à la fin; il s'agit certainement de
la sixième version du fichier de zone pour la journée du 20
septembre 1996. N'oubliez-pas que le numéro de série doit
<em>obligatoirement</em> augmenter avec le temps, ici il n'y a
qu'un chiffre pour le numéro de série dans la journée, si bien
qu'après 9 modifications il faudra attendre le lendemain pour
modifier le fichier à nouveau. On peut aussi utiliser deux chiffres
au lieu d'un seul.</p>
<hr>
<pre>
@       IN      SOA     land-5.com. root.land-5.com. (
                        199609206       ; serial, todays date + todays serial #
                        8H              ; refresh, seconds
                        2H              ; retry, seconds
                        1W              ; expire, seconds
                        1D )            ; minimum, seconds
                NS      land-5.com.
                NS      ns2.psi.net.
                MX      10 land-5.com.  ; Primary Mail Exchanger
                TXT     "LAND-5 Corporation"
 
localhost       A       127.0.0.1

router          A       206.6.177.1
        
land-5.com.     A       206.6.177.2
ns              A       206.6.177.3
www             A       207.159.141.192

ftp             CNAME   land-5.com.
mail            CNAME   land-5.com.
news            CNAME   land-5.com.

funn            A       206.6.177.2

;
;       Workstations
;
ws-177200       A       206.6.177.200
                MX      10 land-5.com.   ; Primary Mail Host
ws-177201       A       206.6.177.201
                MX      10 land-5.com.   ; Primary Mail Host
ws-177202       A       206.6.177.202
                MX      10 land-5.com.   ; Primary Mail Host
ws-177203       A       206.6.177.203
                MX      10 land-5.com.   ; Primary Mail Host
ws-177204       A       206.6.177.204
                MX      10 land-5.com.   ; Primary Mail Host
ws-177205       A       206.6.177.205
                MX      10 land-5.com.   ; Primary Mail Host
; {Ici 245 lignes ont été effacées}
ws-177250       A       206.6.177.250
                MX      10 land-5.com.   ; Primary Mail Host
ws-177251       A       206.6.177.251
                MX      10 land-5.com.   ; Primary Mail Host
ws-177252       A       206.6.177.252
                MX      10 land-5.com.   ; Primary Mail Host
ws-177253       A       206.6.177.253
                MX      10 land-5.com.   ; Primary Mail Host
ws-177254       A       206.6.177.254
                MX      10 land-5.com.   ; Primary Mail Host
</pre>
<hr>
<p>Si vous examinez le serveur de noms de land-5, vous allez voir
que les noms sont de la forme <code>ws_</code><em>nombre</em>.
Depuis les dernières versions de <code>bind 4</code>,
<code>named</code> fait plus attention aux caractères placés dans
les noms de domaines. Cela ne marcherait pas du tout avec bind-8,
c'est pour ça que j'ai remplacé les ``_'' (souligné) par des ``-''
(tiret) pour l'exemple dans ce HowTo.</p>
<p>Une autre chose qu'il faut noter est que les stations de travail
n'ont pas de nom personnel, mais plutôt un préfixe suivit des deux
derniers morceaux de leur adresse IP. Utiliser une telle convention
simplifie grandement la maintenance, mais c'est un peu impersonnel,
et ça peut agacer vos clients.</p>
<p>Nous voyons aussi que <code>funn.land-5.com</code> est un alias
pour <code>land-5.com</code>, mais en utilisant un enregistrement
<code>A</code>, pas un <code>CNAME</code>. C'est une bonne chose
comme on l'a noté plus haut.</p>
<h2><a name="ss5.5">5.5 /var/named/zone/206.6.177</a></h2>
<p>Les commentaires se trouvent juste après le fichier.</p>
<hr>
<pre>
@               IN      SOA     land-5.com. root.land-5.com. (
                                199609206       ; Serial
                                28800   ; Refresh
                                7200    ; Retry
                                604800  ; Expire
                                86400)  ; Minimum TTL
                        NS      land-5.com.
                        NS      ns2.psi.net.
;
;       Servers
;
1       PTR     router.land-5.com.
2       PTR     land-5.com.
2       PTR     funn.land-5.com.
;
;       Workstations
;
200     PTR     ws-177200.land-5.com.
201     PTR     ws-177201.land-5.com.
202     PTR     ws-177202.land-5.com.
203     PTR     ws-177203.land-5.com.
204     PTR     ws-177204.land-5.com.
205     PTR     ws-177205.land-5.com.
; {Ici 245 lignes ont été effacées}
250     PTR     ws-177250.land-5.com.
251     PTR     ws-177251.land-5.com.
252     PTR     ws-177252.land-5.com.
253     PTR     ws-177253.land-5.com.
254     PTR     ws-177254.land-5.com.
</pre>
<hr>
<p>La zone inverse est la partie de la configuration qui semble
poser le plus de problèmes. Elle est utilisée pour trouver le nom
d'hôte d'une machine, connaissant son adresse IP. Exemple&nbsp;:
vous êtes un serveur IRC et vous acceptez des connexions provenant
de clients IRC. Cependant, comme vous êtes un serveur IRC
norvégien, vous ne voulez accepter que les connexions venant de
Norvège ou des autres pays scandinaves. Ainsi, lorsqu'un client se
connecte chez vous, la bibliothèque C peut vous dire quelle est
l'adresse IP du client, puisque cette dernière se trouve dans tous
les paquets qui traversent le réseau. Ensuite, vous pouvez appeler
une fonction connue sous le nom de <code>gethostbyaddr</code> qui
va rechercher le nom d'une machine connaissant son adresse IP.
<code>gethostbyaddr</code> va poser la question à un serveur de
noms, qui va alors faire une recherche de la machine dans le DNS.
Supposons que la connexion du client se fasse depuis
<code>ws_177200.land-5.com.</code> L'adresse IP que la bibliothèque
C fournit au serveur IRC est <code>206.6.177.200.</code> Pour
retrouver le nom de cette machine, il nous faut trouver
<code>200.177.6.206.in-addr.arpa</code>. Le serveur de noms va donc
d'abord trouver les serveurs <code>arpa.</code>, puis les serveurs
<code>in-addr.arpa.</code>, poursuivre la recherche inverse par
206, puis 6 et finalement trouver le serveur pour la zone
<code>177.6.206.in-addr.arpa</code> à LAND-5. C'est ce dernier qui
lui dira que pour <code>200.177.6.206.in-addr.arpa</code> nous
avons un champ ``<code>PTR ws_177200.land-5.com</code>'', ce qui
veut dire que le nom qui va avec <code>206.6.177.200</code> est
<code>ws_177200.land-5.com</code>. Tout comme l'explication de la
résolution de <code>prep.ai.mit.edu</code>, ce scénario est un peu
idéalisé.</p>
<p>Revenons à l'exemple du serveur IRC. Le serveur n'accepte que
les connexions venant des pays scandinaves, c'est-à-dire
<code>*.no</code>, <code>*.se</code>, <code>*.dk</code>. Le nom
<code>ws_177200.land-5.com</code> ne correspond évidemment pas, et
le serveur va donc refuser la connexion. Si il n'existait
<em>pas</em> de résolution inverse de <code>206.2.177.200</code> au
travers de la zone <code>in-addr.arpa</code>, le serveur aurait été
tout à fait incapable de trouver le nom, et aurait dû se contenter
de comparer <code>206.6.177.200</code> à <code>*.no</code>,
<code>*.se</code> et <code>*.dk</code>, dont aucun ne
correspond.</p>
<p>Certaines personnes vous diront que la résolution de noms
inverse n'est importante que pour les serveurs, ou pas importante
du tout. Pas tant que ça&nbsp;: beaucoup de serveurs ftp, news, irc
ou même certains http (Web) n'acceptent <em>pas</em> les connexions
venant de machines dont ils ne peuvent retrouver le nom. C'est
pourquoi la résolution de noms inverse pour les machines est
<em>obligatoire</em>.</p>
<h2><a name="maint"></a> <a name="s6">6. Maintenance</a></h2>
<p><b>Garder votre DNS en état de marche</b></p>
<p>En plus des tâches normales, il y a une tâche de maintenance
spéciale à effectuer sur les serveurs de nom. Il s'agit de garder
le fichier <code>root.hints</code> à jour. La façon la plus simple
de le faire est d'utiliser dig. Lancez d'abord dig sans argument,
vous obtiendrez le fichier <code>root.cache</code> de votre propre
serveur. Posez alors la même question à un des serveurs de cette
liste avec la commande <code>dig @rootserver</code>. Vous
remarquerez que ce que vous obtenez ressemble énormément à un
fichier <code>root.hints</code>, avec quelques chiffres en plus.
Ces chiffres supplémentaires sont inoffensifs. Sauvez-le dans un
fichier (<code>dig . @e.root-servers.net &gt;root.hints.new</code>)
et remplacez l'ancien fichier <code>root.hints</code> avec.</p>
<p>N'oubliez pas de relancer <code>named</code> après avoir
remplacé ce fichier.</p>
<p>Al Longyear m'a envoyé ce script, qui peut être lancé
automatiquement pour mettre à jour <code>named.hints</code>.
Lancez-le automatiquement à partir de la crontab et vous pourrez
oublier qu'il existe. Ce script suppose que l'alias de mail
`hostmaster' existe. Il faudra sans doute modifier ce fichier pour
qu'il fonctionne chez vous.</p>
<hr>
<pre>
#!/bin/sh
#
# Met a jours les informations du cache du serveur de noms chaque mois.
# Ce script est lancé automatiquement par un cron.
#
# Original par Al Longyear
# Mis a jour pour Bind 8 par Nicolai Langfeldt
# Plusieurs erreurs découvertes par David A. Ranch
# Test avec un ping suggéré par Martin Foster
#
(
 echo "To: hostmaster &lt;hostmaster&gt;"
 echo "From: system &lt;root&gt;"
 echo "Subject: Mise a jour automatique du fichier root.hints"
 echo

 PATH=/sbin:/usr/sbin:/bin:/usr/bin:
 export PATH
 cd /var/named

 # Sommes nous connectés ? Pingons un serveur de notre FAI
 case `ping -qnc some.machine.net` in
   *'100% packet loss'*)
        echo "PAS de connexion réseau. root.hints NON mis à jour"
        echo
        exit 0
        ;;
 esac

 dig @rs.internic.net . ns &gt;root.hints.new 2&gt;&amp;1

 case `cat root.hints.new` in
   *NOERROR*)
        # Ca a marché
        :;;
   *)
        echo "La mise a jour de root.hints a ECHOUE."
        echo "Voici la sortie de dig :"
        echo
        cat root.hints.new
        exit 0
        ;;
 esac

 echo "Le fichier root.hints a été mis a jour et contient les informations suivantes :"
 echo
 cat root.hints.new

 chown root.root root.hints.new
 chmod 444 root.hints.new
 rm -f root.hints.old
 mv root.hints root.hints.old
 mv root.hints.new root.hints
 ndc restart
 echo
 echo "Le serveur de noms a été redémarré, de cette manière, la mise a jour est complète."
 echo "L'ancien root.hints s'appelle maintenant /var/named/root.hints.old."
) 2&gt;&amp;1 | /usr/lib/sendmail -t
exit 0
</pre>
<hr>
<p>Certains d'entre vous ont remarqués que le fichier
<code>root.hints</code> est aussi disponible via ftp depuis
l'Internic. S'il vous plaît, n'utilisez pas le ftp pour mettre à
jour le <code>root.hints</code>, la méthode ci dessus est bien
meilleur du point de vue de la nettiquette et de l'Internic.</p>
<h2><a name="bind8"></a> <a name="s7">7. Passer de la version 4 à
la version 8</a></h2>
<p>Cette section était au départ sur l'utilisation de bind-8 écrite
par David E. Smith (dave@bureau42.ml.org). Je l'ai éditée pour
refléter le nouveau nom de la section.</p>
<p>Il n'y a pas grand chose à faire, sinon, utiliser
<code>named.conf</code> au lieu du <code>named.boot</code>, or
bind-8 est distribué avec un script perl pour convertir un
<code>named.boot</code> en <code>named.conf</code>. Exemple de
<code>named.boot</code> (vieux) pour un serveur qui ne sert que de
cache&nbsp;:</p>
<hr>
<pre>
directory /var/named
cache   .                                       root.hints
primary 0.0.127.IN-ADDR.ARPA                    127.0.0.zone
primary localhost                               localhost.zone          
</pre>
<hr>
<p>Depuis la ligne de commande, et depuis le répertoire
<code>bind8/src/bin/named</code> (au cas où vous avez récupéré les
sources; si vous avez eu un paquetage binaire, le script se balade
certainement dans le coin), tapez&nbsp;:</p>
<hr>
<pre>
./named-bootconf.pl &lt; named.boot &gt; named.conf
</pre>
<hr>
<p>qui crée un nouveau <code>named.conf</code>&nbsp;:</p>
<hr>
<pre>
// generated by named-bootconf.pl

options {
        directory "/var/named";
};

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

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

zone "localhost" {
        type master;
        file "localhost.zone";
};
</pre>
<hr>
<p>Ça marche pour tout ce qui pouvait aller dans un
<code>named.boot</code>, mais, il ne met pas toutes les nouveautés
que bind-8 permet. Voici une version plus complète d'un
<code>named.conf</code> qui fait la même chose, mais d'une façon
plus efficace&nbsp;:</p>
<hr>
<pre>
// Voici le fichier de configuration de named (pour BIND 8.1 et ultérieur).
// Il devrait normalement être installé dans /etc/named.conf.
// Le seul changement fait dans le named.conf d'origine (a part ce commentaire
// :) est que la ligne directory a été décommentée, car j'ai déjà les fichiers
// de zone dans /var/named.

options {
        directory "/var/named";
        datasize 20M;
};

zone "localhost" IN {
        type master;
        file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "127.0.0.zone";
};

zone "." IN {
        type hint;
        file "root.hints";
};
</pre>
<hr>
<p>Dans le répertoire <code>bind8/src/bin/named/test</code> de la
distribution de bind8, vous trouverez tout ça, ainsi que des
fichiers de zone que la majorité peuvent prendre et utiliser
instantanément.</p>
<p>Les formats des fichiers de zone et du <code>root.hints</code>
sont les mêmes, tout comme les commandes qui les mettent à
jour.</p>
<h2><a name="qanda"></a> <a name="s8">8. Questions et
Réponses</a></h2>
<p>Dans cette section, je passe en revue quelques-unes des
questions les plus fréquemment posées à propos du DNS et de ce
HOWTO. Et je donne même les réponses&nbsp;;-) Merci de bien lire
cette section avant de m'écrire.</p>
<ol>
<li>Mon <code>named</code> me réclame un fichier
<code>named.boot</code>
<p>Vous vous êtes trompés de HowTo. allez voir l'ancienne version
de ce HowTo, celle qui parle de bind 4, à <a href=
"http://www.math.uio.no/~janl/DNS/">www.math.uio.no/~janl/DNS/</a></p>
</li>
<li>Question&nbsp;: Comment utiliser un DNS si l'on se trouve
derrière un firewall&nbsp;?
<p>Voici un indice&nbsp;: <code>forward only;</code>. Vous aurez
probablement aussi besoin de mettre&nbsp;:</p>
<hr>
<pre>
  query-source port 53;
  
</pre>
<hr>
<p>dans la partie ``options'' de votre <code>named.conf</code>
comme l'exemple 3 le suggère <a href="#caching">serveur qui ne fait
que du cache</a>.</p>
</li>
<li>Question&nbsp;: Comment dire à un DNS qu'il doit faire une
rotation entre un certain nombre d'adresses pour un service donné,
par exemple si l'on veut obtenir équilibrer la charge de
<code>www.busy.com</code> entre plusieurs machines&nbsp;?
<p>Créez plusieurs champs <b>A</b> pour www.busy.com et utilisez
bind 4.9.3 ou une version plus récente, qui supporte les réponses à
scrutation circulaire. Cela ne marchera <em>pas</em> avec des
versions de bind antérieures.</p>
</li>
<li>Je veux mettre en place un serveur DNS sur un Intranet (fermé).
Comment faire&nbsp;?
<p>Effacez rageusement le fichier <code>root.hints</code> et créez
seulement les fichiers de zone. Cela veut aussi dire que vous
n'aurez pas à créer des nouveaux fichiers hints tout le temps.</p>
</li>
<li>Comment mettre en place un serveur secondaire&nbsp;?
<p>Si le serveur primaire a pour adresse 127.0.0.1, mettez une
ligne comme celle-ci dans le fichier <code>named</code>.conf du
serveur secondaire&nbsp;:</p>
<hr>
<pre>
  zone "linux.bogus" {
        type slave;
        file "sz/linux.bogus";
        masters { 127.0.0.1; };
  };
  
</pre>
<hr>
<p>Vous pouvez mettre plusieurs serveurs maîtres, ajoutez les sur
la ligne masters en les séparant par un ``;'' (point-virgule)</p>
</li>
<li>Je veux faire tourner bind lorsque je suis déconnecté du réseau
<p>Il y a trois trucs a savoir&nbsp;:</p>
<ul>
<li>J'ai reçu le mail suivant de Ian Clark
&lt;ic@deakin.edu.au&gt;, où il explique comment il fait ça&nbsp;:
<blockquote>
<pre><code>

Ici, je fais tourner named sur la machine qui fait du "Masquerading". J'ai
deux fichiers root.cache, un qui s'appelle root.cache.real et qui contient les
vrais noms des serveurs root, et l'autre qui s'appelle root.cache.fake qui
contient ceci~:

--------------
; root.hints.fake
; Ce fichier ne contient pas d'informations
--------------

Quand je me déconnecte, je copie le fichier root.hints.fake vers root.hints et
je relance named.

Quand je me connecte, je copie root.hints.real et je relance named.

Ces deux manoeuvres sont faites, respectivement, à partir de ip-down et ip-up.

Lorsque je suis déconnecté, named rajoute ceci au fichier messages après la
première requête concernant un nom de domaine qu'il ne connaît pas~:

Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN

Ce qui n'est pas très gênant.

Ça marche très bien dans mon cas.  Je peux utiliser le serveur de noms pour
les machines locales lorsque je suis déconnecté du Net en évitant les délais
introduits par les timeout liés à la recherche des noms de domaine extérieurs.
Et lorsque je suis connecté au Net, les requêtes concernant les noms de
domaines extérieurs marchent normalement.
</code></pre></blockquote>
</li>
<li>J'ai aussi reçu des informations sur la façon dont bind
interagit avec NFS et le portmapper sur une machine qui est le plus
souvent déconnectée de la part de Karl-Max Wanger&nbsp;:
<blockquote>
<pre><code>

J'ai pris l'habitude d'utiliser named sur toutes mes machines qui sont
seulement connectées à Internet de façons occasionnelles grâce à un modem. Le
serveur de noms n'agit qu'en tant que cache, il n'a aucune zone d'autorité et
demande tout aux serveurs du fichier root.cache.  Comme d'habitude avec une
Slackware, named est démarré avant nfsd et mountd.

Avec l'une de mes machines (un portable Libretto 30), j'ai eu le problème
suivant~: de temps en temps, je pouvais monter ses disques depuis un autre
système connecté sur mon LAN local, mais la plupart du temps, ça ne marchait
pas. Il se passait la même chose que ce soit en utilisant PLIP, une carte
Ethernet PCMCIA ou PPP avec une interface série.

Après quelques temps de réflexions et d'expériences, j'ai découvert que named
empêchait nfsd et mountd de s'enregistrer avec portmapper au démarrage (Je
démarre ces démons au boot d'habitude).  Le fait de lancer named après nfsd
et mountd éliminait ce problème complètement

Comme il n'y a pas de désavantages à modifier ainsi la séquence de boot de
cette façon, j'encourage tout le monde à en faire de même pour éviter des
problèmes potentiels.
</code></pre></blockquote>
</li>
<li>Enfin, il y a quelques informations sur le sujet chez <a href=
"http://www.acmebw.com/askmrdns/#linux-ns">Ask Mr DNS</a>. C'est a
propos de bind 4, vous aurez donc à l'adapter pour que cela
fonctionne avec bind 8.</li>
</ul>
</li>
<li>Où le serveur de noms qui fait que du cache stocke-t-il son
cache&nbsp;? Puis-je contrôler la taille de ce cache&nbsp;?
<p>Le cache est entièrement stocké en mémoire, il n'est
<em>pas</em> écrit sur le disque. Chaque fois que vous tuez
<code>named</code>, le cache est perdu. Il n'y a <em>aucun</em>
moyen de contrôler le cache. <code>named</code> gère le cache selon
quelques règles simples, et c'est tout. Vous ne pouvez pas
contrôler le cache ou sa taille en aucune manière. Si vous voulez
vraiment le faire, vous pouvez le faire en bricolant le code de
<code>named</code>. Mais ce n'est pas recommandé.</p>
</li>
<li>Est-ce que <code>named</code> sauvegarde le contenu du cache
entre deux redémarrage&nbsp;? Puis-je le forcer à le faire&nbsp;?
<p>Non, <code>named</code> ne sauve <em>pas</em> la contenu du
cache lorsqu'il meurt. Cela signifie que le cache est reconstruit à
partir de zéro chaque fois que vous tuez puis relancez
<code>named</code>. Il n'y a <em>aucun</em> moyen de forcer
<code>named</code> à sauvegarder le contenu du cache dans un
fichier. Si vous voulez vraiment le faire, vous pouvez le faire en
bricolant le code de <code>named</code>. Mais, encore une fois, ce
n'est pas recommandé.</p>
</li>
<li>Comment je fais pour obtenir un domaine&nbsp;? Je veux mettre
en place mon domaine appelé (par exemple)
<code>linux-rulez.net</code>. Comment puis-je me faire assigner ce
domaine&nbsp;?
<p>Contactez votre FAI. Ils seront en mesure de vous aider pour
tout ça. Notez toutefois que vous aurez certainement à payer
quelque chose.</p>
</li>
</ol>
<h2><a name="bigger"></a> <a name="s9">9. Comment devenir un
administrateur DNS de haut vol</a></h2>
<p><b>Documentation et outils</b></p>
<p>La Vraie Documentation existe. En ligne et imprimée. Il faut
absolument la lire si vous voulez devenir un administrateur DNS du
plus haut niveau. Pour ce qui est de la documentation imprimée, le
livre standard est <em>DNS and BIND</em> de C. Liu et P. Albitz
chez O'Reilly &amp; Associates, Sebastopol, CA, ISBN 0-937175-82-X.
Je l'ai lu, c'est excellent, la deuxième édition est basée sur bind
4, la troisième sur bind 8. Il y a aussi un chapitre sur le DNS
dans <em>TCP/IP Network Administration</em>, de Craig Hunt chez
O'Reilly..., ISBN 0-937175-82-X. Un autre passage obligé pour une
Bonne administration de DNS (ou Bonne n'importe quoi, d'ailleurs)
est <em>Zen and the Art of Motorcycle Maintenance</em> by Robert M.
Pirsig&nbsp;:-) Disponible sous la référence ISBN 0688052304 entre
autres.</p>
<p>En ligne, vous trouverez des trucs sur <a href=
"http://www.dns.net/dnsrd/">DNS Resources Directory</a>, <a href=
"http://www.isc.org/bind.html">www.isc.org/bind.html</a>; Une FAQ,
un manuel de référence (BOG; Bind Operations Guide) aussi bien que
des papiers, des descriptions de protocoles et des trucs sur le
service DNS (ces documents, ainsi que la majorité, sinon la
totalité des RFC mentionnées ci-dessous font partie de la
distribution de bind). Je n'ai pas lu la plupart de ces trucs-là,
c'est pourquoi je ne suis pas un Grand Administrateur de DNS. Arnt
Gulbrandsen, à l'inverse, a lu le BOG et n'en dit que du
bien&nbsp;:-). Le newsgroup <a href=
"news:comp.protocols.tcp-ip.domains">comp.protocols.tcp-ip.domains</a>
parle de DNS. En complément, il y a un certain nombre de RFC sur le
DNS, les plus importantes sont certainement celles-ci&nbsp;:</p>
<dl>
<dt><b>RFC 2052</b></dt>
<dd>
<p>A. Gulbrandsen, P. Vixie, <em>A DNS RR for specifying the
location of services (DNS SRV)</em>, October 1996</p>
</dd>
<dt><b>RFC 1918</b></dt>
<dd>
<p>Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear,
<em>Address Allocation for Private Internets</em>, 02/29/1996.</p>
</dd>
<dt><b>RFC 1912</b></dt>
<dd>
<p>D. Barr, <em>Common DNS Operational and Configuration
Errors</em>, 02/28/1996.</p>
</dd>
<dt><b>RFC 1912 Errors</b></dt>
<dd>
<p>B. Barr <em>Errors in RFC 1912</em>, this is available at
<a href=
"http://www.cis.ohio-state.edu/~barr/rfc1912-errors.html">www.cis.ohio-state.edu/~barr/rfc1912-errors.html</a></p>
</dd>
<dt><b>RFC 1713</b></dt>
<dd>
<p>A. Romao, <em>Tools for DNS debugging</em>, 11/03/1994.</p>
</dd>
<dt><b>RFC 1712</b></dt>
<dd>
<p>C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, <em>DNS
Encoding of Geographical Location</em>, 11/01/1994.</p>
</dd>
<dt><b>RFC 1183</b></dt>
<dd>
<p>R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, <em>New DNS
RR Definitions</em>, 10/08/1990.</p>
</dd>
<dt><b>RFC 1035</b></dt>
<dd>
<p>P. Mockapetris, <em>Domain names - implementation and
specification</em>, 11/01/1987.</p>
</dd>
<dt><b>RFC 1034</b></dt>
<dd>
<p>P. Mockapetris, <em>Domain names - concepts and facilities</em>,
11/01/1987.</p>
</dd>
<dt><b>RFC 1033</b></dt>
<dd>
<p>M. Lottor, <em>Domain administrators operations guide</em>,
11/01/1987.</p>
</dd>
<dt><b>RFC 1032</b></dt>
<dd>
<p>M. Stahl, <em>Domain administrators guide</em>, 11/01/1987.</p>
</dd>
<dt><b>RFC 974</b></dt>
<dd>
<p>C. Partridge, <em>Mail routing and the domain system</em>,
01/01/1986.</p>
</dd>
</dl>
</body>
</html>
doc-linux-fr-html 2013.01-3ubuntu1 / usr / share / doc / HOWTO / fr-html / DNS-HOWTO.html
