Où nous allons enfin voir de vrais fichiers de zone
Certains utilisateurs ont suggéré que je mette un vrai exemple d'un domaine qui marche dans la réalité car mon explication de la différence entre un vrai domaine et l'exemple bidon ci-dessus n'était pas très claire.
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.
Voici les deux zones pour les deux zones inversées nécessaires : le
réseau 127.0.0, ainsi que le sous réseau LAND-5 206.6.177. Et une
ligne primary pour la forward zone land-5.com. Notez aussi qu'au lieu
de mettre les fichiers dans le répertoire pz
comme dans ce
HowTo, il les a mis dans le répertoire zone
.
// 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"; };
Si vous mettez ça dans votre named.conf pour jouer avec, s'il
vous plaît mettez aussi le notify no;
dans les zones des
deux land-5.com pour éviter les accidents.
/var/named/root.hints
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 dig.
; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- 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
/var/named/zone/127.0.0
Nous y avons mit juste l'essentiel, le champ SOA obligatoire, et un
champ qui établit la correspondance entre 127.0.0.1 et
localhost
. Ils sont tous les deux indispensables. Rien
d'autre ne doit figurer dans ce fichier. Il ne sera probablement
jamais besoin de le mettre à jour, à moins que l'adresse du serveur de
noms ou de hostmaster ne change.
@ 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.
Nous trouvons ici le classique et obligatoire champ SOA ainsi que les champs NS. Nous pouvons voir qu'il a un serveur de noms secondaire ns2.psi.net. C'est comme ça que tout le monde devrait faire : toujours avoir un serveur secondaire sur un site distant pour faire des sauvegardes. Nous voyons également que le serveur primaire est land-5, qui assure tous les services, et que l'administrateur a utilisé des CNAME pour faire ça (il aurait pu utiliser des champs A).
Comme vous pouvez voir d'après le champ SOA, le fichier de zone a
son origine à land-5.com, la personne à contacter est
root@land-5.com
. hostmaster
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 obligatoirement augmenter de
manière monotone, 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. Envisagez d'utiliser
deux chiffres au lieu d'un seul.
@ 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 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 @ TXT "LAND-5 Corporation" ; ; 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 ; {Many repetitive definitions deleted - SNIP} 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
Si vous examinez le serveur de nom de land-5, vous allez voir que
les noms sont de la forme ws_
nombre. Depuis les
dernières version 4 de bind, named 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 substitué les '_' (souligné) par des
'-' (tiret).
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 peut causer des grognements de vos clients.
/var/named/zone/206.6.177
Les commentaires se trouvent après ce fichier
@ 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. ; {Many repetitive definitions deleted - SNIP} 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.
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 : 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 gethostbyaddr qui va rechercher le nom d'une machine connaissant son adresse IP. Gethostbyaddr 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 ws_177200.land-5.com. L'adresse IP que la bibliothèque C fournit au serveur IRC est 206.6.177.200. Pour retrouver le nom de cette machine, il nous faut trouver 200.177.6.206.in-addr.arpa. Le serveur de noms va donc d'abord trouver les serveurs arpa., puis les serveurs in-addr.arpa., poursuivre la recherche inverse par 206, puis 6 et finalement trouver le serveur pour la zone 177.6.206.in-addr.arpa à land-5. C'est ce dernier qui lui dira que pour 200.177.6.206.in-addr.arpa nous avons un champ 'PTR ws_177200.land-5.com', ce qui veut dire que le nom qui va avec 206.6.177.200 est ws_177200.land-5.com. Tout comme pour l'explication de la résolution de prep.ai.mit.edu, tout ceci est légèrement fictif.
Revenons à l'exemple du serveur IRC. Le serveur n'accepte que les connexions venant des pays scandinaves, c'est-à-dire *.no, *.se, *.dk. Le nom ws_177200.land-5.com ne correspond évidemment pas, et le serveur va donc refuser la connexion. Si il n'existait pas de résolution inverse de 206.2.177.200 au travers de la zone in-addr.arpa, le serveur aurait été tout à fait incapable de trouver le nom, et aurait dû se contenter de comparer 206.6.177.200 à *.no, *.se et *.dk, dont aucun ne correspond.
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 : beaucoup de serveurs ftp, news, irc ou même certains http (Web) n'acceptent pas 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 obligatoire.