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, weaties.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
. 'ne' 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.