Page suivante Page précédente Table des matières

4. Un domaine simple

Comment mettre en place votre propre domaine

4.1 Mais avant tout, un brin de théorie

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.

4.2 Notre propre domaine

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.

4.3 La zone inversée

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.


Page suivante Page précédente Table des matières