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.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.
�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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:34