Etude de l'application DNS

4 - L'application d'interrogation

4.1 - Schéma général

L'application DNS (Domain Name Service) livre des extraits de la base à des utilisateurs, en réponse à leurs interrogations.
La couche DNS est composée de 2 types d'entités-DNS, qui échangent des PDU-DNS en utilisant la couche UDP :

des clients-DNS, ou résolveurs, qui reçoivent les questions des utilisateurs installés dans le même système, dialoguent avec les serveurs-DNS (par des PDU-DNS) pour en obtenir des réponses qu'ils livrent aux utilisateurs.
(Par exemple, les processus host lancés dans les exercices précédents sont des utilisateurs du service-DNS.)

des serveurs-DNS, qui disposent de copies maîtres et/ou esclaves de zones, dont ils extraient les réponses aux questions reçues.
Dans le cas où un serveur-DNS ne trouve pas l'information cherchée dans les copies de zones dont il dispose, il peut demander à "son" résolveur de poser la question à d'autres serveurs-DNS (mode récursif).

4.2 - Les serveurs-DNS

Un serveur-DNS est lié au port UDP/53 dans le système où il est implanté.

Plusieurs implémentations existent, une des plus connues est BIND (Berkeley Internet Name Domain) est installée sur custsv.
La configuration du serveur-DNS BIND est définie par le fichier /etc/named/named.conf ou /etc/bind/named.conf (copie de custsv ou copie de sp.isima.fr), dont les paramètres sont expliqués dans le BIND Configuration File Guide.
Autres fichiers intéressants que l'on trouve dans le fichier named.conf de sp.isima.fr : isima.db, isima.rev, isima.local, isima.ca.

Exercice 4.2-1 :

Quelles sont les zones que maintient le serveur-DNS de sp ?

De quel type est chacune de ces zones ?

Examiner les fichiers correspondants.

Lorsque le serveur-DNS n'a pas l'information qu'un client-DNS lui demande, il peut propager la question

auprès d'un serveur-DNS qui possède une copie maître ou esclave de la zone dans laquelle se trouve la réponse, s'il connait un tel serveur-DNS,

ou bien auprès d'un serveur-DNS-racine (liste dans /etc/bind/db.root [copie]), qui lui renverra la liste des RR-NS de la zone.
Il pourra ensuite propager la question l'un de ces serveurs-DNS si le résolveur le demande (voir §4.3.2).

Après avoir obtenu une réponse, il la mémorise dans une zone-cache les informations reçues. Ainsi il enrichit sa propre connaissance, et ainsi peut répondre plus tard à partir de son cache. Cependant, s'il répond à une question à partir de ce cache, la réponse est dite "non autorisée" (non authoritative).

Exercice 4.2-2 : réponse autorisée et réponse non autorisée
(avec l'option -d, la commande host indique s'il la réponse vient d'une copie de zone ou d'un cache)

Examiner la différence entre les commandes
host -d -a www.isima.fr
et host -d -a --server=sp.isima.fr www.isima.fr

Les réponses données pour les questions suivantes sont-elles autorisées ou non ?

custsv.univ-bpclermont.fr

www.ifma.fr

etc...

Comment faut-il poser la question pour avoir une réponse autorisée ?

4.3 - Les résolveurs

4.3.1 - Configuration : à quel serveur-DNS s'adresser ?

Les résolveurs sont implantés dans les fonctions gethostbyname et gethostbyaddr, généralement installées dans une bibliothèque partagée (libc.so pour la plupart des Unix).

Un résolveur est configuré pour adresser les questions soumises par un utilisateur (par exemple host) à une liste d'au moins un serveur-DNS.
Chaque serveur-DNS de la liste est désigné par la seule adresse-IP du système dans lequel il est installé; cette adresse est complétée par UDP/53.

Unix : fichier /etc/resolv.conf

Microsoft : Paramètres, Panneau de configuration, Réseau, TCP, Propriétés, onglet DNS

Le résolveur s'adresse d'abord au 1^er serveur-DNS de la liste.
Si la réponse n'arrive dans l'échéance prévue (4 secondes), il s'adresse au 2^ème, s'il y en a un, puis au suivant...

Exercice 4.3.1

Quelle est la liste des serveurs-DNS du résolveur de fc.isima.fr ? de etud ?

4.3.2 - Et pour aller chercher l'information à la source...

Un résolveur peut laisser au serveur-DNS la totalité de la recherche (mode récursif) ou bien organiser lui-même la recherche de serveur en serveur (mode itératif ou non récursif).

Exercice 4.3.2 : et si le résolveur était inintelligent...
(l'option -r de la commande host indique au résolveur de demander au serveur-DNS de ne pas propager la question auprès des autres serveurs-DNS)

exemple : recherche de www.hexalis.fr

host -r www.hexalis.fr
ne donne pas de réponse (voir)

host -r -v www.hexalis.fr
donne la liste des serveurs-DNS susceptibles de connaître la réponse (voir)

On pose la question à un de ces serveurs, jusqu'à obtenir la liste des serveurs possédant une copie de la zone cherchée.
host -r -v --server=m.root-servers.net www.hexalis.fr (voir)
host -r -v --server=NS3.NIC.fr www.hexalis.fr (voir)
On obtient la liste des serveurs-DNS possédant une copie de la zone hexalis.fr, par exemple ns.sky.fr

On pose la question à un de ces serveur
host -r --server=ns.sky.fr www.hexalis.fr (voir)
On obtient enfin la réponse !

Effectuer cette opération pour les noms suivants

www.inetech.fr

www.ncd.com

www.tahiti-manava.pf

www.mazda.jp

etc...

Suite...