IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

L'Internet Rapide et Permanent

La résolution de noms DNS

Vous disposez d'une connexion permanente et rapide… et maintenant, vous êtes perdu dans la technique…

Cette série « L'Internet Rapide et Permanent », que Christian Caleca nous a aimablement autorisés à reproduire, est là pour répondre à quelques-unes de ces questions. Cet article parlera du système de résolution de noms DNS.

N'hésitez pas à commenter cet article ! Commentez Donner une note à l´article (5)

Article lu   fois.

L'auteur

L'article

Publié le - Mis à jour le 29 mars 2020 

Public visé : tout le monde

Version PDF Version hors-ligne

ePub, Azw et Mobi

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction▲

I-A. La résolution des noms▲

Tous les internautes vous le diront, l'URL est le gouvernail de la navigation sur le Net.

  • URL : Uniform Resource Locator. C'est la méthode d'accès à un document distant. Un lien hypertexte avec une syntaxe de la forme : <Type de connexion>://<FQDN>/[<sous-répertoire>]/…/<nom du document>. Le RFC 1034 définit les concepts de ce système ;
  • FQDN : Full Qualified Domain Name. Le nom complet d'un hôte, sur l'Internet, c'est-à-dire de la machine jusqu'au domaine, en passant par les sous-domaines.

I-B. Les serveurs DNS▲

Ils sont en place pour permettre la résolution de FQDN en adresses IP (et réciproquement, si nécessaire). En utilisation courante, nous exploitons un serveur DNS « récursif » dont l'adresse IP est généralement fournie par DHCP ou RADIUS, suivant le cas. Ces serveurs ne gèrent pas obligatoirement de zones particulières, mais savent effectuer les recherches nécessaires dans une architecture arborescente que nous allons voir en détail, pour résoudre n'importe quel nom d'hôte.

Cette architecture arborescente est construite au niveau mondial et nous verrons que c'est une petite merveille d'organisation.

I-C. Objectifs de ce chapitre▲

L'objectif avoué est double :

  • fournir aux internautes « non spécialistes » les informations de base nécessaires à la compréhension de la résolution des noms ;
  • donner des informations approfondies sur les mécanismes utilisés à ceux qui souhaitent comprendre plus en profondeur le fonctionnement de DNS.

II. Notions de base▲

II-A. Découverte du serveur DNS utilisé▲

Donc, notre fournisseur d'accès nous propose une ou plusieurs adresses de serveurs DNS récursifs, et notre système va les récupérer lors de sa configuration IP. Pour connaître ces adresses, il faut savoir retrouver sa configuration. La façon de faire varie suivant le système d'exploitation utilisé.

Windows propose quelques chemins plus ou moins détournés. Le plus simple est sans doute d'utiliser la commande dans une invite de commande :

 
Sélectionnez
C:\Documents and Settings\chris>nslookup
Serveur par défaut :  dns1.proxad.net
Address:  212.27.40.240

Nous sommes ici dans le cas d'une machine sous Windows XP, connectée à une FreeBox en mode pont Ethernet (nous n'exploitons pas les fonctions de routage). Il est également possible de récupérer l'information avec la commande :

 
Sélectionnez
C:\Documents and Settings\chris>ipconfig /all

Configuration IP de Windows
        ...
Carte Ethernet Connexion au réseau local:
        ...
        Serveurs DNS . . . . . . . . . .  : 212.27.40.240
                                            212.27.40.241

Pour les distributions GNU/Linux, l'information se trouve généralement dans le fichier /etc/resolv.conf :

 
Sélectionnez
# cat /etc/resolv.conf
nameserver 212.27.40.240
nameserver 212.27.40.241

II-B. Test de résolution▲

Windows XP propose la commande nslookup, qui permet d'effectuer une résolution manuellement. Exemple :

 
Sélectionnez
C:\Documents and Settings\caleca>nslookup irp.nain-t.net
Serveur par défaut :  dns1.proxad.net
Address:  212.27.40.240

Réponse ne faisant pas autorité :
Nom :    irp.nain-t.net
Address:  213.186.40.149

Ça fonctionne et le texte « Réponse ne faisant pas autorité » est à se mettre sous le coude, nous comprendrons plus tard ce que cela veut dire.

Dans les systèmes GNU/Linux, la commande nslookup n'est plus maintenue. Les outils à retenir sont host et dig.

 
Sélectionnez
# host irp.nain-t.net
irp.nain-t.net has address 213.186.40.149

Quel que soit le service que nous utilisons sur un réseau, navigateur Web, client de messagerie, IRC, dès lors que nous identifions le serveur interrogé par son nom, le système devra effectuer une résolution de ce nom, de manière à trouver l'adresse IP correspondante, et exploitera les services du serveur DNS, comme nous l'avons fait avec nslookup ou host.

II-C. Analyse d'un FQDN▲

Prenons un exemple un peu compliqué, comme www.education.gouv.fr ; en toute rigueur, il serait plus correct d'écrire www.education.gouv.fr. (avec un point final, subtile différence).

  • la partie la plus à gauche représente toujours un hôte ;
  • la partie la plus à droite représente toujours un domaine générique (TLD) ;
  • entre les deux, les éventuels sous-domaines et le domaine déposé de l'entité concernée.

Ainsi, un serveur (un hôte), ici www appartiendrait à un sous-domaine (education) du domaine gouv, lui-même étant un élément du domaine générique fr (la réalité n'est hélas pas si simple, comme l'avenir va le montrer). Notons qu'il serait plus judicieux de parler d'un nœud ; en effet, un hôte peut disposer de plusieurs interfaces réseau et donc disposer de plusieurs adresses IP.

Nous avons donc une structure arborescente dont l'origine est le fameux point final, que l'on omet généralement, mais qui existe bel et bien et qui représente la racine de l'arbre. Nous pouvons d'ailleurs utiliser la commande host comme ceci :

 
Sélectionnez
$ host www.education.gouv.fr.
www.education.gouv.fr is an alias for front.webedu.men.aw.atosorigin.com.
front.webedu.men.aw.atosorigin.com has address 160.92.130.142

Tiens, voilà autre chose…

www.education.gouv.fr ne serait pas un « vrai nom », mais simplement un synonyme de front.webedu.men.aw.atosorigin.com ? Encore une remarque à se mettre sous le coude. En effet, DNS prévoit qu'un hôte (un nœud) puisse s'appeler de diverses manières, parfois très différentes comme c'est le cas ici. L'éclaircissement viendra sans doute dans la suite de ce chapitre.

II-D. Pourquoi « serveur récursif » ?▲

Dans la suite de ce chapitre, nous allons voir d'un peu plus près comment un serveur DNS est structuré et comment l'architecture arborescente d'un FQDN est en fait l'image d'une arborescence de serveurs DNS spécialisés.

A priori, un serveur DNS récursif n'a par lui-même aucune réponse, du moins aucune réponse « qui fait autorité », en revanche il sait exactement rechercher qui est dans quel ordre il faut interroger pour obtenir une réponse « qui fait autorité ». Comme en informatique, la paresse et la mémoire sont deux qualités fondamentales, notre serveur DNS récursif va conserver dans sa mémoire pendant « un certain temps » les résultats de recherche qu'il a obtenus et s'en servira en priorité, pour avoir moins de travail. Nous étudierons tout ceci plus loin, mais cette fonctionnalité explique déjà la réponse « ne faisant pas autorité » vue plus haut. En effet, lorsqu'un serveur DNS sert une réponse issue de son cache, il signale de cette manière qu'elle ne vient pas d'un serveur de référence.

III. Notions avancées▲

III-A. Considérations générales▲

Par la pratique, nous savons que la partie la plus à droite d'un FQDN est régie par des usages stricts. En effet, cette partie représente un « Top Level Domain », Domaine de premier niveau en français. Il en existe un certain nombre, ils sont définis par l'ICANN (Internet Corporation for Assigned Names and Numbers). Un article bien documenté sur Wikipédia vous donnera plus de détails.

À l'intérieur de chaque TLD, il est possible pour toute entreprise, association, personne morale ou physique, d'enregistrer un nom de domaine. Il suffit d'en faire la demande auprès d'un « registar », bureau d'enregistrement en français. Voir encore Wikipédia pour plus de détails. Le registar vérifiera l'unicité du domaine demandé, les éventuelles conditions d'obtention et se chargera des démarches pour l'enregistrement du domaine. Le coût de l'opération varie beaucoup en fonction du registar choisi.

Nous allons voir l'influence qu'a cette opération sur la structure du DNS.

III-B. La structure de DNS▲

III-B-1. Root-Servers▲

Nous avons au départ une série de serveurs DNS appelés root-servers. Nous en trouvons la liste et leur implantation dans le monde sur le site root-servers.org.

Ces serveurs ne sont pas récursifs, ne savent pas résoudre les FQDN, mais savent dire quels serveurs sont spécialisés dans les divers TLD.

III-B-2. Serveurs TLD▲

Ces serveurs DNS ne sont pas non plus récursifs, mais pour un TLD donné, savent dire quels sont les serveurs DNS qui gèrent un domaine appartenant à ce TLD.

C'est à ce niveau que le registrar intervient techniquement. Une fois le nom de domaine enregistré, le demandeur doit fournir l'adresse d'au moins un serveur DNS qui saura résoudre les noms dans le domaine en question et ce DNS doit être enregistré sur les serveurs du TLD choisi.

III-B-3. Manipulations▲

Mais une petite expérience vaut mieux qu'un long discours. Nous allons utiliser notre outil host pour chercher à résoudre le FQDN www.education.gouv.fr, non plus en posant la question à notre serveur DNS récursif, mais en partant de la source, à savoir un root-server : 192.58.128.30, en utilisant la commande comme ceci :

 
Sélectionnez
host -v www.education.gouv.fr 192.58.128.30
  • le -v indique que l'on veut des détails (verbose) ;
  • l'adresse IP en dernier argument indique quel serveur DNS nous voulons interroger.
 
Sélectionnez
$ host -v www.education.gouv.fr 192.58.128.30
Server: j.root-servers.net
Address: 192.58.128.30

Query about www.education.gouv.fr for record types A
Trying www.education.gouv.fr ...
Query failed, 0 answers, status: no error
Authority information:
fr                      172800    IN    NS    E.EXT.NIC.fr
fr                      172800    IN    NS    C.NIC.fr
fr                      172800    IN    NS    B.EXT.NIC.fr
fr                      172800    IN    NS    F.EXT.NIC.fr
fr                      172800    IN    NS    A.NIC.fr
fr                      172800    IN    NS    E.NIC.fr
fr                      172800    IN    NS    D.EXT.NIC.fr
fr                      172800    IN    NS    G.EXT.NIC.fr
Additional information:
A.NIC.fr                172800    IN    A    192.93.0.129
A.NIC.fr                172800    IN    AAAA    2001:660:3005:3:0:0:1:1
B.EXT.NIC.fr            172800    IN    A    192.228.90.21
C.NIC.fr                172800    IN    A    192.134.0.129
C.NIC.fr                172800    IN    AAAA    2001:660:3006:4:0:0:1:1
D.EXT.NIC.fr            172800    IN    A    204.152.184.85
D.EXT.NIC.fr            172800    IN    AAAA    2001:4F8:0:2:0:0:0:8
E.EXT.NIC.fr            172800    IN    A    193.176.144.6
E.NIC.fr                172800    IN    A    194.57.253.1
F.EXT.NIC.fr            172800    IN    A    194.146.106.46
G.EXT.NIC.fr            172800    IN    A    204.61.216.39
www.education.gouv.fr A record currently not present at j.root-servers.net

J-root-servers.net ne répond pas directement, comme nous pouvions nous en douter. En revanche, il nous envoie la liste des serveurs DNS compétents dans le TLD fr. Reposons donc la question au premier de la liste : a.nic.fr :

 
Sélectionnez
$ host -v www.education.gouv.fr 192.93.0.129
Server: a.nic.fr
Address: 192.93.0.129

Query about www.education.gouv.fr for record types A
Trying www.education.gouv.fr ...
Query failed, 0 answers, status: no error
Authority information:
education.gouv.fr       172800    IN    NS    ns4.atos.net
education.gouv.fr       172800    IN    NS    ns3.atos.net
www.education.gouv.fr A record currently not present at a.nic.fr

Cette réponse nous apprend deux choses :

  • pour résoudre des noms dans le domaine education.gouv.fr, il faut poser la question à ns4.atos.net ou à ns3.atos.net.

Malheureusement, nous ne disposons pas cette fois-ci des « Additionnal information » et n'avons pas l'adresse IP de ces serveurs. Il nous reste à repartir du début avec une nouvelle requête :

 
Sélectionnez
$ host -v ns4.atos.net 192.58.128.30
Server: j.root-servers.net
Address: 192.58.128.30

Query about ns4.atos.net for record types A
Trying ns4.atos.net ...
Query failed, 0 answers, status: no error
Authority information:
net                     172800    IN    NS    J.GTLD-SERVERS.net
net                     172800    IN    NS    K.GTLD-SERVERS.net
net                     172800    IN    NS    G.GTLD-SERVERS.net
net                     172800    IN    NS    M.GTLD-SERVERS.net
net                     172800    IN    NS    C.GTLD-SERVERS.net
net                     172800    IN    NS    H.GTLD-SERVERS.net
net                     172800    IN    NS    D.GTLD-SERVERS.net
net                     172800    IN    NS    B.GTLD-SERVERS.net
net                     172800    IN    NS    L.GTLD-SERVERS.net
net                     172800    IN    NS    A.GTLD-SERVERS.net
net                     172800    IN    NS    F.GTLD-SERVERS.net
net                     172800    IN    NS    E.GTLD-SERVERS.net
net                     172800    IN    NS    I.GTLD-SERVERS.net
Additional information:
A.GTLD-SERVERS.net      172800    IN    A    192.5.6.30
A.GTLD-SERVERS.net      172800    IN    AAAA    2001:503:A83E:0:0:0:2:30
B.GTLD-SERVERS.net      172800    IN    A    192.33.14.30
B.GTLD-SERVERS.net      172800    IN    AAAA    2001:503:231D:0:0:0:2:30
C.GTLD-SERVERS.net      172800    IN    A    192.26.92.30
D.GTLD-SERVERS.net      172800    IN    A    192.31.80.30
E.GTLD-SERVERS.net      172800    IN    A    192.12.94.30
F.GTLD-SERVERS.net      172800    IN    A    192.35.51.30http://www.google.fr/
G.GTLD-SERVERS.net      172800    IN    A    192.42.93.30
H.GTLD-SERVERS.net      172800    IN    A    192.54.112.30
I.GTLD-SERVERS.net      172800    IN    A    192.43.172.30
J.GTLD-SERVERS.net      172800    IN    A    192.48.79.30
K.GTLD-SERVERS.net      172800    IN    A    192.52.178.30
L.GTLD-SERVERS.net      172800    IN    A    192.41.162.30
ns4.atos.net A record currently not present at j.root-servers.net

À peine plus avancés, interrogeons alors a.gtld-servers.net :

 
Sélectionnez
$ host -v ns4.atos.net 192.5.6.30
Server: a.gtld-servers.net
Address: 192.5.6.30

Query about ns4.atos.net for record types A
Trying ns4.atos.net ...
Query done, 1 answer, status: no error
The following answer is not authoritative:
ns4.atos.net            172800    IN    A    193.56.46.248
Authority information:
atos.net                172800    IN    NS    ns3.atos.net
atos.net                172800    IN    NS    ns4.atos.net
Additional information:
ns3.atos.net            172800    IN    A    160.92.121.6
ns4.atos.net            172800    IN    A    193.56.46.248

Nous n'avons jamais été aussi proches de la solution finale. Une dernière question à ns4.atos.net dont nous connaissons désormais l'adresse IP :

 
Sélectionnez
$ host  www.education.gouv.fr 193.56.46.248
www.education.gouv.fr    CNAME    front.webedu.men.aw.atosorigin.com
front.webedu.men.aw.atosorigin.com    A    160.92.130.142

Et voilà le travail. Nous pouvons constater à quel point il peut être fastidieux et nous nous félicitons de disposer d'un bon gros serveur DNS récursif, qui fait tout ce travail à notre place. Car c'est exactement de cette manière qu'il s'y prend pour nous obtenir la réponse.

Les renseignements qu'il glane en effectuant cette recherche, il va les garder en mémoire et s'en resservira pour d'éventuelles résolutions futures. Nous verrons que pour cette raison, les serveurs « qui font autorité » indiquent une durée de validité pour les informations qu'ils donnent. Ainsi, les serveurs récursifs devront rafraîchir le contenu de leur cache en fonction de cette durée de validité.

IV. Construire un serveur DNS▲

Pourquoi faire :

  • pour comprendre mieux comment ça fonctionne ;
  • pour disposer d'une solution de secours si le(s) serveur(s) DNS de notre fournisseur d'accès montre(nt) des signes de faiblesse ;
  • pour se créer un petit intranet sympa, même avec un nom de domaine « en bois » qui ne sera fonctionnel que sur notre LAN.

Les raisons sont-elles suffisantes ? Oui, alors allons-y. Nous avons bien un vieux PC qui traîne dans un coin et qui ne demande qu'à reprendre du service. Nous y installons une Debian (Lenny dans ce qui suit), sans aucune fioriture, le strict minimum, quoi. Avec bind9 et quelques outils de base, nous ne dépasserons pas les 800 Mo sur le disque et 256 Mo de RAM pourront faire l'affaire, si notre réseau local ne dépasse pas 100 postes…

IV-A. Bon gros avertissement▲

Ce que nous allons faire ici est destiné à l'usage exclusif de notre LAN. Aucune considération de sécurité ne sera abordée. Si le principe reste le même pour la mise en place d'un serveur DNS public, il faudra prendre en compte tous les risques d'agression et ils sont nombreux.

 
Sélectionnez
aptitude install bind9 bind9-host

Qu'avons-nous ajouté sur notre machine ? Le très célèbre serveur DNS de chez ISC, nommé bind, dans sa version 9 et la commande host.

IV-B. Un simple cache▲

En l'état, notre bind est fonctionnel, c'est un serveur DNS récursif qui sait par lui-même répondre à toutes les demandes de résolution de FQDN de l'Internet. La preuve ?

 
Sélectionnez
# host -v www.altavista.fr 127.0.0.1
Trying "www.altavista.fr"
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29138
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.altavista.fr.        IN    A

;; ANSWER SECTION:
www.altavista.fr.    7200    IN    CNAME    rc.yahoo.com.
rc.yahoo.com.        1800    IN    CNAME    rc.fy.b.yahoo.com.
rc.fy.b.yahoo.com.    300    IN    A    206.190.60.37

;; AUTHORITY SECTION:
fy.b.yahoo.com.        300    IN    NS    yf1.yahoo.com.
fy.b.yahoo.com.        300    IN    NS    yf2.yahoo.com.

Received 134 bytes from 127.0.0.1#53 in 961 ms
Trying "rc.fy.b.yahoo.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15133
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;rc.fy.b.yahoo.com.        IN    AAAA

;; AUTHORITY SECTION:
fy.b.yahoo.com.        30    IN    SOA    yf1.yahoo.com. hostmaster.yahoo-inc.com. 1233237548 30 30 86400 1800

Received 96 bytes from 127.0.0.1#53 in 30 ms
Trying "rc.fy.b.yahoo.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45688
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;rc.fy.b.yahoo.com.        IN    MX

;; AUTHORITY SECTION:
fy.b.yahoo.com.        30    IN    SOA    yf1.yahoo.com. hostmaster.yahoo-inc.com. 1233237548 30 30 86400 1800

Received 96 bytes from 127.0.0.1#53 in 31 ms

L'emploi de l'option -v rend la réponse un peu indigeste, mais assez instructive.

Nous apprenons que www.altavista.fr. n'est qu'un alias de rc.yahoo.com., lui-même alias de rc.fy.b.yahoo.com. et que son adresse IP est 206.190.60.37.

En prime, nous apprenons que le domaine fy.b.yahoo.com. est géré par les serveurs DNS yf1.yahoo.com. et yf2.yahoo.com., que www.altavista.fr. ne dispose pas d'adresse IP v6, la réponse à la question ; rc.fy.b.yahoo.com. IN AAAA aurait eu une réponse et enfin, que le SOA pour ce domaine est yf1.yahoo.com.. C'est quoi un SOA ? Rappelez-moi d'en parler plus loin dans ce chapitre si jamais j'oubliais.

Toutes ces informations, c'est notre bind à nous qui les a trouvées en se débrouillant tout seul, et en 961 millisecondes seulement ! Nous n'aurions pas fait mieux.

Bien sûr nous pouvons lui poser une question plus simple (sans l'option -v) pour un nœud qui n'a rien à voir :

 
Sélectionnez
# host www.google.fr 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

www.google.fr is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.129.147
www.l.google.com has address 209.85.129.99
www.l.google.com has address 209.85.129.104

C'est plus lisible, il y a moins d'informations. Remarquez qu'un seul nom dispose ici de plusieurs adresses IP. C'est du « round-robin » (tourniquet en français). À quoi ça sert ? Rappelez-moi d'en parler plus loin dans ce chapitre si jamais j'oubliais…

Bref, notre bind sait parfaitement effectuer pour nous toute résolution de FQDN, nous pouvons désormais nous passer des serveurs DNS récursifs de notre fournisseur d'accès, à l'exception des clients d'Orange™ qui devront prendre quelques précautions et là encore, nous verrons pourquoi plus tard.

IV-B-1. Par quel prodige ?▲

Notre installation de bind9 a produit une configuration par défaut, minimaliste, qui permet au serveur de fonctionner en mode récursif. Sans entrer dans tous les détails, allons-y voir de plus près.

Tout se trouve (sur Debian) dans le répertoire /etc/bind.

 
Sélectionnez
# cd /etc/bind
debvirt:/etc/bind# ls -l
total 44
-rw-r--r-- 1 root root  237 jan  2 18:19 db.0
-rw-r--r-- 1 root root  271 jan  2 18:19 db.127
-rw-r--r-- 1 root root  237 jan  2 18:19 db.255
-rw-r--r-- 1 root root  353 jan  2 18:19 db.empty
-rw-r--r-- 1 root root  270 jan  2 18:19 db.local
-rw-r--r-- 1 root root 2878 jan  2 18:19 db.root
-rw-r--r-- 1 root bind  907 jan  2 18:19 named.conf
-rw-r--r-- 1 root bind  165 jan  2 18:19 named.conf.local
-rw-r--r-- 1 root bind  572 jan  2 18:19 named.conf.options
-rw-r----- 1 bind bind   77 jan 29 14:16 rndc.key
-rw-r--r-- 1 root root 1317 jan  2 18:19 zones.rfc1918

Nous n'en avons pas parlé jusqu'ici, mais il faut tout de même en dire quelques mots, de la résolution inverse, celle qui consiste à retrouver un nom d'hôte à partir de son adresse IP. Ce service est peu utilisé par le particulier (entendez par là l'internaute en général). Il l'est cependant parfois par des services sur l'Internet, par exemple SMTP, pour tenter de lutter contre le spam. Pour cette raison, nous n'en dirons pas plus sur la question.

Voyons sans plus tarder le contenu de named.conf qui, de toute évidence, constitue le fichier de configuration principal :

 
Sélectionnez
# cat named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the 
// structure of BIND configuration files in Debian, *BEFORE* you customize 
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

include "/etc/bind/named.conf.local";

Déjà, nous constatons que ce fichier fait lui-même appel à deux autres fichiers de configuration, named.conf.options et named.conf.local. Nous aurons à modifier au moins l'un d'entre eux. En revanche, named.conf ne devrait (sur Debian) jamais être modifié, sauf par les mises à jour futures de la distribution.

À part ceci, nous observons des déclarations de zones, presque toutes destinées à la résolution inverse, à l'exception de celles qui sont surlignées en vert (NDLR, les trois premières).

IV-B-1-a. La zone « localhost »▲

Pas bien utile en général, elle permet de résoudre localhost :

 
Sélectionnez
# cat db.local
;
; BIND data file for local loopback interface
;
$TTL    604800
@    IN    SOA    localhost. root.localhost. (
                  2        ; Serial
             604800        ; Refresh
              86400        ; Retry
            2419200        ; Expire
             604800 )    ; Negative Cache TTL
;
@    IN    NS    localhost.
@    IN    A    127.0.0.1
@    IN    AAAA    ::1

Le fichier db.local a une structure que nous aurons besoin de détailler plus tard. Nous y apprenons que localhost dispose des adresses 127.0.0.1 en IPv4 et ::1 en IPv6, ce que nous savions probablement déjà.

IV-B-1-b. La zone « . »▲

Plus intéressant est le fichier db.root :

 
Sélectionnez
# cat db.root
;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
;
;       last update:    Feb 04, 2008
;       related version of root zone:   2008020400
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:BA3E::2:30
;
; formerly NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201
;
; formerly C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; formerly TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; formerly NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; formerly NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
F.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2f::f
;
; formerly NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
H.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:1::803f:235
;
; formerly NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
;
; operated by VeriSign, Inc.
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
J.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:C27::2:30
;
; operated by RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
K.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fd::1
;
; operated by ICANN
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     199.7.83.42
;
; operated by WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
M.ROOT-SERVERS.NET.      3600000      AAAA  2001:dc3::35
; End of File

Il contient en effet toutes les informations sur les root-servers, sans quoi, notre bind n'aurait rien pu faire. Notez que le ; est un signe de commentaire.

Le contenu de ce fichier évolue peu dans le temps et les mises à jour de la distribution suffisent normalement à le maintenir dans un état satisfaisant. Notez que certains (mais peu encore) des root-servers disposent d'une adresse IPv6.

IV-C. Créer une zone▲

Tout ceci est bien, mais nous voudrions maintenant créer une zone pour notre intranet, avec un nom de domaine « en bois » par exemple maison.mrs. Le TLD n'existe pas, le domaine maison.mrs ne peut donc exister sur l'Internet, mais il peut parfaitement fonctionner sur notre LAN.

Pour ce faire, il nous faut tout de même entrer un peu plus dans le détail des informations que peut donner un serveur DNS.

IV-C-1. $TTL▲

Indique en secondes la durée de vie de l'information fournie. Les serveurs DNS récursifs conserveront en cache les informations récoltées pendant la durée indiquée dans ce paramètre. 0 devrait indiquer que les valeurs ne doivent pas être conservées en cache (utile pour les « dyn DNS », mais c'est une autre histoire).

IV-C-2. SOA▲

Start Of Authority. Si nous avons plusieurs serveurs DNS qui servent la même zone, nous avons vu l'exemple pour yahoo.com qui en a deux, mais il pourrait y en avoir plus, il y en a un qui est le serveur « maître », les autres n'étant que des « esclaves », c'est-à-dire de simples répliquas. L'administrateur met à jour le maître, qui notifiera ses esclaves (l'informaticien a une tendance à la paresse). Le champ SOA indique donc quel est le serveur « maître ».

Nous pouvons d'ailleurs, au moyen de la commande host savoir rapidement toutes ces choses :

 
Sélectionnez
# host -t ns yahoo.com
yahoo.com name server ns4.yahoo.com.
yahoo.com name server ns6.yahoo.com.
yahoo.com name server ns1.yahoo.com.
yahoo.com name server ns3.yahoo.com.
yahoo.com name server ns5.yahoo.com.
yahoo.com name server ns8.yahoo.com.
yahoo.com name server ns2.yahoo.com.

Tiens, il y a bien plus de deux Name Servers pour le domaine yahoo.com, finalement… Mais tous n'ont pas forcément besoin d'être référencés sur les serveurs du TLD com, deux suffisent.

Mais quel est dans cette liste le serveur « maître » ?

 
Sélectionnez
# host -t soa yahoo.com
yahoo.com has SOA record ns1.yahoo.com. hostmaster.yahoo-inc.com. 2009012906 3600 300 1814400 600

C'est ns1.yahoo.com. et nous disposons également d'autres informations, que nous allons retrouver lors de la construction de notre zone « maison ». Nous avons l'assurance que ce serveur fournira toujours la bonne information (sauf erreur de l'administrateur).

Comme nous allons le voir, le symbole @ n'a pas ici la signification habituelle « at ». Aussi, l'adresse e-mail du responsable de la zone est marquée : hostmaster.yahoo-inc.com.. Si nous avons une remarque à faire au responsable de la zone, nous adresserons le message à hostmaster@yahoo-inc.com.

IV-C-2-a. Serial▲

Numéro de série qu'il faut incrémenter à chaque modification de la zone. Il est d'usage de le construire à partir de la date de modification. Ainsi, dans l'exemple précédent, nous pouvons imaginer que le serveur a été mis à jour le 29 janvier 2009, peut être à 6h GMT, ou alors ce serait la sixième modification opérée ce jour. Cette façon de faire est une recommandation, mais pas une obligation. Un simple incrément suffit. Ce numéro de série permet aux serveurs « esclaves » de savoir s'il y a eu ou non une modification de la zone depuis leur dernière synchronisation.

IV-C-2-b. Refresh▲

Indique en seconde le temps au bout duquel les serveurs « esclaves », aussi appelés secondaires, devront demander à rafraîchir leurs données pour cette zone. 3600 secondes dans l'exemple, soit une heure.

IV-C-2-c. Retry▲

Indique en secondes au bout de combien de temps un serveur esclave doit réessayer de se synchroniser si la tentative a échoué après le temps refresh. Ici toutes les 300 secondes, soit toutes les 5 minutes.

IV-C-2-d. Expire▲

Si toutes les tentatives de synchronisation échouent, indique le temps (en secondes) au bout duquel les serveurs secondaires devront considérer qu'ils ne savent plus répondre aux requêtes concernant cette zone. Ici 1814400 secondes, soit 21 jours ! Mieux vaut donner une réponse peut-être fausse que de ne pas en donner du tout ?

IV-C-2-e. Negative Cache TTL▲

Paramètre dont la signification est assez floue. Pour bind9, indique le temps pendant lequel les caches (DNS récursifs) conserveraient l'information NXDOMAIN, « le domaine n'existe pas », lorsqu'un incident s'est produit.

IV-C-3. NS, A, AAAA, CNAME et les autres▲

Le champ NS (Name Server) indique le nom d'un serveur de noms. Pour une zone donnée, s'il y a plusieurs serveurs de noms, il y aura plusieurs champs NS.

Le champ A (Address) fait correspondre un nom à une adresse IPv4, alors que le champ AAAA fera correspondre un nom à une adresse IPv6.

Le champ CNAME (Common Name) fait correspondre un alias à un « vrai nom ». Le « vrai nom » doit disposer par ailleurs d'un champ A, dans la même zone ou dans une autre, sur le même serveur ou sur un autre (nous en avons vu un exemple avec www.education.gouv.fr).

Il existe encore d'autres champs comme MX (Mail eXchanger), utile pour le protocole SMTP ou TXT (utile surtout, hélas, pour « tunnelliser » n'importe quoi dans du protocole DNS, mais c'est une autre affaire).

IV-C-4. Le symbole « @ »▲

Dans un fichier de configuration de zone, ce symbole représente exactement le nom de domaine de la zone. Par exemple, lorsque nous allons créer notre zone maison.mrs, écrire :

 
Sélectionnez
maison.mrs.  IN SOA ...
Nous pourrons écrire : 
@            IN SOA ...

IV-C-5. La zone maison.mrs▲

Nous en savons assez pour créer notre zone « maison ». Notre serveur va s'appeler debvirt.maison.mrs et dispose de l'adresse IP 192.168.0.254 :

Créons d'abord dans /etc/bind/ un fichier nommé par exemple : db.maison.mrs qui contiendrait ceci :

 
Sélectionnez
$TTL    1600
@       IN      SOA     debvirt.maison.mrs. root.debvirt.maison.mrs. (
                        2009012901      ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          1600 )        ; Negative Cache TTL
;
@         IN    NS      debvirt.maison.mrs.
@         IN    A       192.168.0.254
debvirt   IN    A       192.168.0.254
test1     IN    A       192.168.0.1
test2     IN    CNAME   test1
test3     IN    CNAME   irp.nain-t.net.

Ceci devrait permettre de répondre aux requêtes de type NS pour le domaine maison.mrs, de répondre aussi aux requêtes de type A pour debvirt.maison.mrs et pour test1.maison.mrs, constater aussi que les alias fonctionnent dans et hors du domaine.

Il nous faut maintenant indiquer à bind que cette zone existe. Nous allons le faire dans le fichier /etc/bind/named.conf.local :

 
Sélectionnez
zone "maison.mrs" {
    type master;
    file "/etc/bind/db.maison.mrs";
};

Enfin, nous redémarrons bind avec un /etc/init.d/bind9 restart et nous contrôlons

 
Sélectionnez
# host -a maison.mrs
Trying "maison.mrs"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59474
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;maison.mrs.            IN    ANY

;; ANSWER SECTION:
maison.mrs.        1600    IN    SOA    debvirt.maison.mrs. root.debvirt.maison.mrs. 2009012901 604800 86400 2419200 1600
maison.mrs.        1600    IN    NS    debvirt.maison.mrs.
maison.mrs.        1600    IN    A    192.168.0.254

;; ADDITIONAL SECTION:
debvirt.maison.mrs.    1600    IN    A    192.168.0.254

Received 123 bytes from 127.0.0.1#53 in 1 ms


# host test1.maison.mrs
test1.maison.mrs has address 192.168.0.1


# host test2.maison.mrs
test2.maison.mrs is an alias for test1.maison.mrs.
test1.maison.mrs has address 192.168.0.1


# host test3.maison.mrs
test3.maison.mrs is an alias for irp.nain-t.net.
irp.nain-t.net has address 213.186.40.149

Tout va bien, notre serveur DNS fonctionne parfaitement.

IV-D. Conclusion▲

Encore une fois, cette configuration ne tient compte d'aucune considération sécuritaire. Cependant, nous avons un service récursif pour les résolutions sur l'Internet et qui pourra gérer les noms dans notre intranet.

IV-E. Note pour Orangeâ„¢▲

De longue date, ce petit problème existe. De nombreux clients utilisent les services de smtp.wanadoo.fr pour envoyer leurs e-mails. Faisons avec notre beau bind une résolution de smtp.wanadoo.fr :

 
Sélectionnez
# host smtp.wanadoo.fr
smtp.wanadoo.fr has address 80.12.242.148
smtp.wanadoo.fr has address 193.252.22.65
smtp.wanadoo.fr has address 193.252.22.78
smtp.wanadoo.fr has address 193.252.22.92
smtp.wanadoo.fr has address 193.252.23.67
smtp.wanadoo.fr has address 80.12.242.9
smtp.wanadoo.fr has address 80.12.242.15
smtp.wanadoo.fr has address 80.12.242.53
smtp.wanadoo.fr has address 80.12.242.62
smtp.wanadoo.fr has address 80.12.242.82
smtp.wanadoo.fr has address 80.12.242.142

Voyons maintenant depuis une connexion Orange™, qui utilise les serveurs DNS renseignés par la connexion PPPoE :

 
Sélectionnez
# host  smtp.wanadoo.fr
smtp.wanadoo.fr has address 193.252.22.74
smtp.wanadoo.fr has address 193.252.22.91
smtp.wanadoo.fr has address 193.252.23.66
smtp.wanadoo.fr has address 80.12.242.10
smtp.wanadoo.fr has address 80.12.242.16
smtp.wanadoo.fr has address 80.12.242.52
smtp.wanadoo.fr has address 80.12.242.61
smtp.wanadoo.fr has address 80.12.242.86
smtp.wanadoo.fr has address 80.12.242.141
smtp.wanadoo.fr has address 193.252.22.64

Ce ne sont pas les mêmes… Pourquoi ?

Il faut le demander aux administrateurs de wanadoo.fr. Toujours est-il que votre vaillant Firefox (ou équivalent), si vous êtes usagers de smtp.wanadoo.fr, ne parviendra pas à poster vos messages, la résolution faite par notre cache personnel ne donnant pas les bons serveurs. La solution est de créer sur notre bind une zone wanadoo.fr de type « forward » et d'y indiquer les adresses IP des serveurs DNS fournis par la connexion Orange™. La documentation de bind indique comment réaliser cette opération. Cette documentation complète se trouve sur le site d'ISC (124 pages en anglais, pour la version 9.4, fournie avec Lenny) dont la lecture est indispensable si l'on souhaite réaliser un serveur public ou simplement découvrir toutes les possibilités de l'outil.

IV-F. Psst ! le round-robin ?…▲

Comme nous l'avons vu, il arrive parfois qu'à un FQDN correspondent plusieurs adresses IP (parfois nombreuses, comme dans le cas de smtp.wanadoo.fr). Reprenons l'exemple plus simple de www.google.fr, en posant trois fois de suite la même question à notre serveur :

 
Sélectionnez
# host www.google.fr
www.google.fr is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.129.104
www.l.google.com has address 209.85.129.147
www.l.google.com has address 209.85.129.99

# host www.google.fr
www.google.fr is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.129.99
www.l.google.com has address 209.85.129.104
www.l.google.com has address 209.85.129.147

# host www.google.fr
www.google.fr is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.129.147
www.l.google.com has address 209.85.129.99
www.l.google.com has address 209.85.129.104

Nous observons une permutation circulaire dans l'ordre des réponses (tourniquet). Comme l'application demandeuse prendra la première réponse servie, si trois clients de notre serveur veulent accéder tour à tour à www.google.fr, ils utiliseront chacun une adresse IP différente et donc probablement aboutiront à un serveur différent. Ce système est très souvent utilisé pour répartir simplement la charge sur plusieurs hôtes.

V. Un peu d'espionnage▲

Pour les amateurs de sniff (de réseaux), voici ce que l'on peut capturer avec un Wireshark lorsque notre serveur DNS récursif effectue lorsqu'il cherche à résoudre www.education.gouv.fr alors qu'il vient juste de démarrer et que son cache est vide. Je vous laisse la joie d'analyser ceci par vous-même. Vous y découvrirez la suite de questions posées aux divers serveurs non récursifs, pour obtenir la réponse finale :

Capture wireshark
Cacher/Afficher le codeSélectionnez

VI. Remerciements Developpez▲

Vous pouvez retrouver l'article original ici : L'Internet Rapide et Permanent. Christian Caleca a aimablement autorisé l'équipe « Réseaux » de Developpez.com à reprendre son article. Retrouvez tous les articles de Christian Caleca sur cette page.

Nos remerciements à zoom61 et sevyc64 pour leur relecture orthographique.

N'hésitez pas à commenter cet article ! Commentez Donner une note à l´article (5)

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2012 Christian Caleca. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.