Comment mettre en place votre propre domaine
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é.
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.bogus
doit 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.
Ç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.
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.
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 :
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.
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.