Page suivantePage précédenteTable des matières

4. Un domaine simple

Comment mettre en place votre propre domaine

4.1 Mais avant tout, un brin de théorie

Avant d'entrer vraiment 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 named.conf.

Le service DNS est un système organisé de manière hiérarchique, sous forme d'arbre. La racine est désignée par ``.'' et s'appelle ``la racine''. En dessous de . se trouvent un certain nombre de TLD (Top Level Domains); les plus connus sont ORG, COM, EDU, NET et FR, 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.

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 prep.ai.mit.edu, votre DNS doit trouver un serveur de noms pour le domaine edu. Votre DNS demande d'abord à un serveur de noms de . (il possède déjà les adresses des serveurs pour ., elles sont dans le fichier root.hints), et le serveur pour . donne une liste des serveurs d'edu.

Voici un exemple :

$ nslookup
Default Server: localhost
Address: 127.0.0.1

Interrogeons un serveur situé à la racine.

> server c.root-servers.net.
Default Server: c.root-servers.net
Address: 192.33.4.12

Positionnons le type de requête (Query Type) à NS (Name Server records).

> set q=ns

Posons la question à propos de edu.

> edu.

Le . terminal est significatif, il indique à nslookup que nous interrogeons que edu se trouve juste sous . (et pas dans l'un de nos sous-domaines, ce qui accélère la recherche).

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

Nous apprenons ainsi que tous les serveurs ROOT-SERVERS.NET servent le domaine edu.; nous pouvons donc continuer en les interrogeant tous. Nous continuerons en interrogeant C. Maintenant, nous voulons savoir qui sert le niveau suivant du nom de domaine : mit.edu. :

> 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

strawb, w20ns et bitsy servent tous le domaine mit, prenons-en un au hasard et posons-lui la question au sujet d'un domaine encore plus précis : ai.mit.edu :

> server W20NS.mit.edu.

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.

Server:  W20NS.mit.edu
Address:  18.70.0.160> 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

Ainsi, muesli.ai.mit.edu est un serveur de noms pour le domaine ai.mit.edu :

> server MUESLI.AI.MIT.EDU
Default Server:  MUESLI.AI.MIT.EDU
Address:  128.52.39.7

Changeons le type de requête. Nous avons réussi à trouver le serveur de noms, nous allons maintenant demander tout ce que muesli sait sur le domaine prep.ai.mit.edu.

> set q=any> 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

En commençant à partir de ., 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 named aurait, bien sûr, caché toutes ces informations et il n'aurait plus eu besoin de les redemander pendant un certain temps.

Si l'on revient a l'analogie avec les arbres, chaque ``.'' dans le nom est un embranchement. Et chaque nom entre deux . est une branche de l'arbre.

Grimpons ensemble dans l'arbre en prenant le nom que nous voulons (prep.ai.mit.edu). On part de la racine (.), on regarde ensuite dans quelle branche grimper, dans notre cas, edu. 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 edu, on cherche la branche mit (le nom combiné est mit.edu), puis la branche ai.mit.edu. Maintenant, on est sur le bon serveur, au bon embranchement. La dernière partie est de trouver prep.ai.mit.edu, ce qui est très simple. En informatique fondamentale, on appelle prep une feuille de l'arbre.

Un domaine dont on parle beaucoup moins, mais qui n'en est pas moins important, est in-addr.arpa. Ce domaine trouve sa place dans la hiérarchie des noms de domaine comme un domaine ``normal''. in-addr.arpa 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 in-addr.arpa. Si vous avez l'adresse d'une machine : 192.128.52.43, named procède exactement comme dans l'exemple de prep.ai.mit.edu : il trouve les serveurs pour in-addr.arpa., trouve les serveurs pour 192.in-addr.arpa., trouve les serveurs pour 128.192.in-addr.arpa., et finalement trouve les serveurs pour 52.128.192.in-addr.arpa. . On obtient bien ainsi l'information liée à 43.52.128.192.in-addr.arpa. Malin, n'est ce pas ? (dites oui). En fait, la résolution de noms inverse est assez difficile à admettre les premières années.

À 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é.

4.2 Notre propre domaine

Maintenant, nous en sommes à définir notre propre domaine bien à nous. Nous allons créer le domaine linux.bogus 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.

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 pat.uio.no est identique à Pat.UiO.No.

En fait, nous avons déjà commencé à créer notre propre domaine avec cette ligne dans named.conf:


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

Notez bien l'absence de ``.'' à la fin des noms de domaine de ce fichier. Elle signifie que nous allons définir la zone 0.0.127.in-addr.arpa, que nous sommes son serveur principal et que tout est stocké dans un fichier appelé pz/127.0.0. On a déjà vu ce fichier, il se présente comme ceci :


@               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.

Notez bien le ``.'' à la fin de tous les noms de domaine complets de ce fichier, contrairement au fichier named.boot. Certaines personnes aiment commencer chaque fichier définissant une zone par une directive $ORIGIN, 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 named.conf. Dans notre cas, c'est 0.0.127.in-addr.arpa.

Ce ``fichier de zone'' (``zone file''), contient 3 ``resource records'' (RRs) : 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 0.0.127.in-addr.arpa, la première ligne signifie donc :

0.0.127.IN-ADDR.ARPA. IN SOA ...

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 :

0.0.127.in-addr.arpa.   IN      NS      ns.linux.bogus

Elle dit au service DNS quelle machine est le serveur de noms pour le domaine 0.0.127.in-addr.arpa, c'est ns.linux.bogus. ns est le nom habituel des serveurs de noms, tout comme www. pour les serveurs Web, mais c'est simplement une habitude, on peut choisir n'importe quel nom.

Et finalement le PTR dit que l'adresse 1 dans le sous réseau 0.0.127.in-addr.arpa, donc 127.0.0.1 est appelé localhost.

Le champ SOA est le préambule de tous 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 ns.linux.bogus), qui est responsable de son contenu (hostmaster@linux.bogus, vous devriez mettre votre adresse email à cet endroit), de quelle version du fichier de zone il s'agit (serial : 1), et quelques autres paramètres pour le cache et les serveurs DNS secondaires. Quant aux champs restants (refresh, retry, expire et minimum) utilisez les valeurs données dans ce HOWTO et tout se passera certainement très bien.

Maintenant, relancez votre named (avec la commande ndc restart) et utilisez nslookup pour regarder le résultat :

$ nslookup
Default Server:  localhost
Address:  127.0.0.1> 127.0.0.1
Server:  localhost
Address:  127.0.0.1
Name:    localhost
Address:  127.0.0.1

Tout va bien, on arrive à obtenir localhost à partir de 127.0.0.1. Maintenant, pour le sujet qui nous préoccupe, le domaine linux.bogus, insérez une nouvelle zone dans le fichier named.conf :


zone "linux.bogus" {
 notify no;
 type master;
 file "pz/linux.bogus";
};

Notez qu'encore une fois il n'y a pas de ``.'' à la fin des noms de domaine dans le fichier named.conf.

Dans le fichier de zone linux.bogus, nous allons mettre quelques données totalement factices :


;
; 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

Il y a deux choses à noter à propos du champ SOA. ns.linux.bogusdoit absolument ê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 hostmaster.linux.bogus doit se lire comme hostmaster@linux.bogus. 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.

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é à someone@linux.bogus, dans notre cas à mail.linux.bogus ou mail.friend.bogus. 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 mail.friend.bogus qui a une priorité de 20 dans notre cas.

Relancez named en tapant ndc restart. Examinons le résultat avec nslookup :

$ nslookup> set q=any> 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

Un examen approfondi vous montrera qu'il y a un bug. En effet, la ligne

 linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus

est entièrement fausse. Il devrait y avoir

 linux.bogus preference = 10, mail exchanger = mail.linux.bogus

J'ai fait cette erreur délibérément, pour voir si vous suiviez :-) En regardant dans le fichier de zone, nous trouvons que dans la ligne

@ MX 10 mail.linux.bogus ; Primary Mail Exchanger

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 :


 MX      10 mail.linux.bogus.    ; Primary Mail Exchanger

ou


 MX      10 mail                 ; Primary Mail Exchanger

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.

Il faut que j'insiste sur le point suivant : dans le fichier named.conf, il ne doit pas y avoir de ``.'' après les noms de domaines. Vous ne pouvez pas vous imaginer les ravages qui ont été causés pas des ``.'' en trop ou en moins.

Cela étant dit, voici le nouveau fichier de zone, avec quelques informations supplémentaires :


;
; 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"

Il y a un certain nombre de nouveaux RR que nous allons passer en revue : 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, www est un alias de ns.

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 jamais 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 :


foobar          CNAME   www                     ; NON !

En revanche, ceci est correct :


foobar          CNAME   ns                      ; Oui !

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. webmaster@www.linux.bogus 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 :


www             A       192.168.196.2

Un certain nombre de gourous-du-bind recommandent de ne pas utiliser de CNAME. Mais les discussions sur le pour et le contre sortent du cadre de ce HOWTO.

Mais comme vous le voyez, ce HowTo ainsi que beaucoup de serveurs ne suivent pas cette règle.

Chargez la nouvelle base de données en lançant ndc reload, ce qui forcera named à relire ses fichiers de configuration.

$ nslookup
Default Server:  localhost
Address:  127.0.0.1> ls -d linux.bogus

Ceci veut dire que l'on souhaite que tous les champs soient affichés.

[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"

Tout va bien. Regardons ce qu'il dit pour www tout seul :

> set q=any> 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

En d'autres termes, le vrai nom de www.linux.bogus est ns.linux.bogus, et vous avez en plus quelques informations à propos de ns, en fait, suffisamment pour vous y connecter si vous étiez un programme.

Bon, on a fait la moitié du boulot.

4.3 La zone inversée

Ça y est, les programmes peuvent convertir les noms de linux.bogus 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.

Mettez ça dans votre named.conf


zone "196.168.192.in-addr.arpa" {
 notify no;
 type master;
 file "pz/192.168.196";
};

C'est exactement comme pour le 0.0.127.in-addr.arpa et le contenu est similaire :


@       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.

Redémarrez votre named (ndc restart) et examinez votre travail avec nslookup :


> 192.168.196.4
Server:  localhost
Address:  127.0.0.1
Name:    mail.linux.bogus
Address:  192.168.196.4

On dirait que c'est bon, on va regarder en détails pour s'en assurer :


> 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

Pas mal ! 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.

4.4 Précautions d'usage

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 notify no;. Elle demande à named de ne pas informer ses serveur secondaires (les esclaves) quand l'un de ses fichiers de zone a été mis à jour. Depuis Bind-8 named 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 ?

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.

4.5 Pourquoi est-ce que les lookup inversés ne marchent pas ?

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.

Je parlerais des deux problèmes de lookups inversés qui sont vu de l'extérieur de votre réseau :

La zone inverse n'est pas déléguée.

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 NS 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 ? Si votre zone inversée ne marche pas, retournez y et lisez-le. Maintenant.

La zone inversée a elle aussi besoin d'être déléguée. Si vous avez le réseau 192.168.196 avec le domaine linux.bogus de votre fournisseur, il devra mettre des champs NS pour votre zone inversée aussi bien que pour votre zone directe. Si vous remontez la chaîne à partir de in-addr.arpa 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.

Vous avez un sous-réseau sans classe

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.

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 Ask Mr DNS (c'est en anglais) pour plus d'explications.

Vous l'avez lu ? Comme je ne vais pas l'expliquer, s'il vous plaît, allez le lire.

La première partie du problème est que votre FAI doit comprendre la technique décrite par Mr DNS. 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 ;-). Ils mettrons ensuite une jolie zone inversée sur leurs serveurs que vous pourrez examiner pour savoir si elle est correcte avec nslookup.

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 Mr DNS.

Il y a une autre difficulté qui pointe son nez ici. Les vieux résolveurs ne seront pas capable de suivre les champs CNAME 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 PTR dans ses fichiers de zone sans classe plutôt que des champs CNAME.

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.


Page suivantePage précédenteTable des matières