Comment mettre en place votre propre domaine
Avant d'entrer vraiment dans le vif du sujet, il va
falloir que je vous fasse un brin de théorie sur le principe du
service DNS. Et il va falloir que vous le lisiez, parce que c'est pour
votre bien. Si vous ne "voulez" pas, vous devriez au moins le survoler
rapidement. Arrêtez le survol quand vous en arrivez au point où
j'explique ce qu'il faut mettre dans le fichier named.conf
.
Le service DNS est un système organisé de manière hiérarchique. Le
sommet est désigné par ".
" et se prononce "root". En dessous
de . se trouvent un certain nombre de TLD (Top Level Domains), dont
les plus connus sont ORG, COM, EDU et NET, mais il y en a beaucoup
d'autres.
Lorsque vous recherchez une machine, la question se fait
récursivement dans toute la hiérarchie depuis le haut. Lorsque vous
voulez trouver l'adresse IP de prep.ai.mit.edu
, votre DNS
doit trouver un serveur de noms qui serve le domaine edu. Votre DNS
demande d'abord à un serveur de noms de .
(il possède déjà
les adresses des serveurs de .
, c'est ce à quoi sert le
fichier root.hints
), et le serveur de .
donne une
liste des serveurs d'edu.
En voici une illustration :
$ nslookup
Default Server: localhost
Address: 127.0.0.1
Interrogeons un serveur situé à la racine (root).
> 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 au serveur que nous interrogeons que edu se trouve juste sous . (ce qui permet de faciliter un peu 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
Ceci nous dit que les serveurs *.root-servers.net
servent
le domaine edu.
, nous pouvons donc continuer 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
steawb
, w20ns
et bitsy
servent le domaine
mit
, prenons-en un au hasard et posons-lui la question au
sujet de ai.mit.edu
:
> server W20NS.mit.edu.
Les noms de domaine ne sont pas sensibles à la différence entre lettres minuscules et majuscules, mais 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 chercher 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.
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 deux premières années.
Pour dire vrai, je viens de vous mentir. Le service DNS ne marche pas vraiment comme je vous l'ai exposé. Mais ça en est suffisamment proche.
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 un truc avant de commencer, tous les caractères ne sont pas
admis dans les noms de machines. Nous sommes restreints aux caractères
de l'alphabet anglais (a-z), aux nombres (0-9) et au caractère '-'
(tiret). Utilisez ces caractères, la casse n'importe pas du tout,
donc, pat.uio.no
et 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. Ça dit que nous allons définir la zone
0.0.127.in-addr.arpa
, que nous sommes son principal serveur
et que tout est stocké dans un fichier appelé pz/127.0.0
. On
a déjà écrit 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, au contraire du fichier named.boot
dont nous parlions un peu plus haut. 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 d'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 évitant de l'écrire. Donc, la ligne NS se lit comme il suit :
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
Il dit au service DNS quelle est la machine qui est serveur de noms
pour ce domaine 0.0.127.in-addr.arpa
, c'est
ns.linux.bogus
. 'ns' est le nom habituel des serveurs de
noms, tout comme les serveurs Web sont habituellement appelés
www.
quelque chose mais le nom peut être n'importe
quoi.
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,
et ce doit être le tout premier champ du fichier. 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
),
de quelle version du fichier de zone il s'agit (serial : 1), et
quelques autres choses qui ont à voir avec le cache et les serveurs
DNS secondaires. Pour les 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 (la commande est ndc
restart
) et utilisez nslookup pour regarder le résultat de ce que
vous avez fait :
$ 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', ce peut être toute autre adresse mail légale, mais il faut dans ce cas 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 vers
laquelle le courrier doit être adressé en priorité. En cas d'échec, le
courrier 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, c'était juste 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 ; Primary Mail Exchanger
est correcte. Je préfère la deuxième forme parce qu'il y a moins à taper. Il y en aura bien pour vous dire qu'ils ne sont pas d'accord, et d'autres qui le seront. Dans un fichier de zone, le nom de domaine doit soit être écrit et terminé par un point, ou ne pas être inclus du tout. Dans ce 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 combien de fois un
`.
' en trop ou en moins a tout fichu en l'air et a causé de
graves prises de tête aux gens.
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. CNAME (Canonical NAME) est la façon de donner à chaque machine plusieurs noms. par conséquent, www est un alias de ns.
L'utilisation des records CNAME est assez controversée. Mais il est sage de suivre la règle comme quoi un record MX, CNAME ou SOA ne doit jamais se référer à un record CNAME, toujours se référer à un record A, il serait donc mauvais d'avoir :
foobar CNAME www ; NO!
En revanche, ceci serait correct :
foobar CNAME ns ; Yes!
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 elle 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 grand nombre de gourous-du-bind recommandent de ne jamais utiliser de CNAME. Envisagez donc très sérieusement de ne pas en utiliser.
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]
linux.bogus. SOA ns.linux.bogus
hostmaster.linux.bogus. (199511301 28800 7200 604800 86400)
linux.bogus. NS ns.linux.bogus
linux.bogus. NS ns.friend.bogus
linux.bogus. MX 10 mail.linux.bogus
linux.bogus. MX 20 mail.friend.bogus
linux.bogus. TXT "Linux.Bogus, your DNS consultants"
localhost A 127.0.0.1
mail A 127.0.0.4
mail MX 10 mail.linux.bogus
mail MX 20 mail.friend.bogus
mail HINFO 386sx Linux 1.0.9
donald A 127.0.0.3
donald MX 10 mail.linux.bogus
donald MX 20 mail.friend.bogus
donald HINFO i486 Linux 1.2
donald TXT "DEK"
www CNAME ns.linux.bogus
richard CNAME ns.linux.bogus
ftp A 127.0.0.5
ftp MX 10 mail.linux.bogus
ftp MX 20 mail.friend.bogus
ftp HINFO P6 Linux 1.3.59
ns A 127.0.0.2
ns MX 10 mail.linux.bogus
ns MX 20 mail.friend.bogus
ns HINFO Pentium Linux 1.2
ns TXT "RMS"
linux.bogus. SOA ns.linux.bogus hostmaster.linux.bogus.
(199511301 28800 7200 604800 86400)
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.
Maintenant, 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 nécessaire.
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 !
Il y a quelques trucs que je devrais ajouter maintenant. 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;
. Ça dit à named de ne pas informer ses
serveur secondaires (les esclaves) quand il a eu une mise à jour de
l'un de ses fichiers de zone. Avec Bind-8 named peut notifier les
autres serveurs listés dans ses records 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é devrait ê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. Ce peut-être, malheureusement, un peu déroutant pour vous. Un vrai exemple tiré d'un vrai domaine vous attend au chapitre suivant.