Principe de fonctionnement détaillé du service DNS

Le service DNS signifiant Domain Name Services est né de la volonté de faciliter et de standardiser le processus d’identification des ressources connectées aux réseaux informatiques tels que l’Internet. Les machines ne sachant communiquer qu’à travers l’échange d’adresses IP difficiles à mémoriser pour l’homme, le DNS agit comme un annuaire téléphonique en fournissant la correspondance entre le nom de la machine et son adresse IP.

Ainsi, lorsque l’on veut se connecter à un ordinateur dont on connaît le nom d’hôte, on interroge un serveur DNS qui nous renvoie l’adresse IP correspondant à ce nom.

Le DNS est un modèle réparti hiérarchisé, sa mise en œuvre requiert plusieurs serveurs qui prennent en charge individuellement la traduction de parties complémentaires de l’espace des noms afin de rendre plus souple le traitement des sollicitations. Ces parties appelées zones sont en fait des domaines de noms dont l’administration est définie et attribuée à un ou plusieurs serveurs.

Le domaine source d’où découlent les domaines de noms est appelé domaine Racine. Le domaine Racine est géré par les 13 serveurs DNS nommés « <x>.root-servers.net », où <x> est une lettre comprise entre ‘a’ à ‘m’. Ces serveurs racines sont gérés par des organisations différentes nommées par l’ICANN (VeriSign, USC-ISI, Cogent, UMD, NASA-ARC, ISC, DOD-NIC, ARL, Autonomica, RIPE, ICANN et WIDE). Afin d’assurer le bon maintien du service, ces serveurs sont en réalité redondés, soit localement, soit de manière répartie. Dans ce dernier cas, la technique de routage Anycast est utilisée afin d’associer l’adresse IP d’un serveur racine à plusieurs machines éloignées géographiquement permettant de répartir la charge des requêtes en toute transparence. Par exemple, le serveur racine « c.root-servers.org » est géré par la société Cogent et est en réalité composé de 6 serveurs répartis sur la planète. Pour plus d’information sur les serveurs roots vous pouvez consulter le site http://root-servers.org/

Les domaines adjacents au domaine racine sont les domaines dits de premier niveau ou TLD (Top Level Domain). Ils définissent la nature des organisations et leur provenance géographique. Le TLD ‘com’, le plus répandu, est géré par la société Vérisign sur 13 serveurs DNS. L’AFNIC gère actuellement 3 TLD : ‘fr’, ‘re’ et ‘tf’. La liste des 295 TLD existants est connue de tous les serveurs racines.

Enfin, les domaines de second niveau (SLD) décrivent plus précisément leur nom ou leur titre. Au niveau des domaines de second niveau, des milliers d’autres serveurs sont sollicités pour répondre aux besoins de traduction en adresse IP.

Le niveau terminal (le plus éloigné de la racine) désigne le nom d’hôte de la machine. Ainsi, une machine sur Internet est facilement repérable grâce à son nom d’hôte et à la chaîne d’appartenance à laquelle elle est reliée. La concaténation de la racine, du TLD, du SLD, des sous-domaines et du nom d’hôte séparés par un point est appelée nom FQDN (Fully Qualified Domain Name). La taille limite d’un FQDN est de 255 caractères. Par exemple : la machine qui sert de serveur mail dans l’entreprise Oktey s’appelle mail au sein d’Oktey et « mail.oktey.fr. » sur Internet.

L’ICANN justifie la limitation du nombre des serveurs racines à 13 par un argument technique : utiliser plus de 13 serveurs racines entraînerait des réponses à certaines requêtes DNS de plus de 512 octets. Or le protocole applicatif DNS fonctionne au-dessus du protocole de transport UDP limité à 512 octets de données. La généralisation de l’utilisation de TCP au lieu d’UDP, utilisé pour la synchronisation entre serveurs DNS, entrainerait une surcharge des serveurs DNS.

Pour bien comprendre le mécanisme présenté, la figure suivante décrit le principe d’une requête DNS. Dans l’exemple, l’utilisateur symbolisé en haut à gauche, souhaite accéder au serveur web présent sur la machine : « mail.oktey.fr ». Nous n’analyserons que le trafic DNS dans cet exemple et considérons que le serveur DNS local, n’a pas l’information requise en cache (en mémoire), sans quoi ce dernier répond directement à la demande.

Les commandes utilisées pour requêter le service DNS sont ‘nslookup’ sous Windows et ‘dig’ ou ‘host’ sous Linux. A défaut de connaitre l’IP de la machine contactée via le fichier de nom « /etc/hosts », le resolver DNS utilise le ou les serveurs DNS mentionnés dans « /etc/resolv.conf » (ou la configuration réseau sous Windows) pour effectuer ses requêtes. Pour chacune des étapes, nous allons détailler les commandes sous Linux de la forme : #commande et l’équivalent sous Windows avec le formalisme : >commande. Les réponses seront produites pour les commandes sous Windows, pour éviter d’alourdir l’article inutilement.

1) Le poste de l’utilisateur est configuré pour utiliser le resolver qui orientera sa requête vers le « Serveur DNS local », correspondant généralement à l’IP du serveur DNS de l’entreprise.

# dig mail.oktey.com

> nslookup
> mail.oktey.com

Si le serveur DNS local, possède la réponse en cache, il répondra immédiatement le résultat, sinon il se chargera de poursuivre en interrogeant successivement tous les serveurs DNS, les phases décrites ci-dessous : (2) Racine, (3) DNS de FR, puis (4) DNS de oktey.fr.

2) Le serveur DNS local n’a pas la connaissance sur l’IP affecté au serveur « mail.oktey.fr ». Il doit donc retrouver l’information auprès des serveurs de « oktey.fr. ». Pour cela, il va d’abord contacter les serveurs racine pour savoir qui gère « fr ». La liste des serveurs racine est connue de tous les serveurs DNS, c’est la seule information configurée en dur sur les serveurs DNS.

Pour avoir la liste des serveurs racines :

# dig . NS

> nslookup
> set q=NS
> .
(root)  nameserver = g.root-servers.net
(root)  nameserver = l.root-servers.net
(root)  nameserver = b.root-servers.net
(root)  nameserver = c.root-servers.net
(root)  nameserver = j.root-servers.net
(root)  nameserver = h.root-servers.net
(root)  nameserver = a.root-servers.net
(root)  nameserver = f.root-servers.net
(root)  nameserver = d.root-servers.net
(root)  nameserver = e.root-servers.net
(root)  nameserver = m.root-servers.net
(root)  nameserver = k.root-servers.net
(root)  nameserver = i.root-servers.net
a.root-servers.net      internet address = 198.41.0.4
a.root-servers.net      AAAA IPv6 address = 2001:503:ba3e::2:30
b.root-servers.net      internet address = 192.228.79.201
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
f.root-servers.net      internet address = 192.5.5.241
f.root-servers.net      AAAA IPv6 address = 2001:500:2f::f
g.root-servers.net      internet address = 192.112.36.4
h.root-servers.net      internet address = 128.63.2.53
h.root-servers.net      AAAA IPv6 address = 2001:500:1::803f:235
i.root-servers.net      internet address = 192.36.148.17
i.root-servers.net      AAAA IPv6 address = 2001:7fe::53
j.root-servers.net      internet address = 192.58.128.30

Pour information, on voit apparaitre dans la réponse que 4 serveurs root sur 13 possèdent un adressage IPv6. Pour la prochaine requête un serveur root sera utilisé au hasard parmi les 13 disponibles, dans notre exemple nous utiliserons c.root-servers.net [192.33.4.12].

Requête auprès d’un serveur racine pour savoir qui gère ‘fr’ :

# dig @192.33.4.12 fr NS

> nslookup
> set q=NS
> server 192.33.4.12
> fr
fr      nameserver = d.ext.nic.fr
fr      nameserver = f.ext.nic.fr
fr      nameserver = e.ext.nic.fr
fr      nameserver = d.nic.fr
fr      nameserver = a.nic.fr
fr      nameserver = g.ext.nic.fr
fr      nameserver = c.nic.fr
a.nic.fr        internet address = 192.93.0.129
a.nic.fr        AAAA IPv6 address = 2001:660:3005:3::1:1
c.nic.fr        internet address = 192.134.0.129
c.nic.fr        AAAA IPv6 address = 2001:660:3006:4::1:1
d.ext.nic.fr    internet address = 192.5.4.2
d.ext.nic.fr    AAAA IPv6 address = 2001:500:2e::2
d.nic.fr        internet address = 194.0.9.1
d.nic.fr        AAAA IPv6 address = 2001:678:c:1::1
e.ext.nic.fr    internet address = 193.176.144.6
e.ext.nic.fr    AAAA IPv6 address = 2a00:d78:0:102:193:176:144:6
f.ext.nic.fr    internet address = 194.146.106.46
f.ext.nic.fr    AAAA IPv6 address = 2001:67c:1010:11::53
g.ext.nic.fr    internet address = 204.61.216.39
g.ext.nic.fr    AAAA IPv6 address = 2001:500:14:6039:ad::1

L’AFNIC utilise 7 serveurs DNS, 3 sont physiquement sur les réseaux de l’AFNIC en France, et 4 (les sous-domaine en ‘ext’) se trouvent à l’extérieur du réseau de l’AFNIC.

3) Une requête est ensuite envoyée auprès des serveurs DNS de l’AFNIC pour savoir quels sont les DNS de la zone : ‘oktey.fr’. Dans l’exemple, nous utiliserons au hasard le serveur d.nic.fr [194.0.9.1].

# dig @194.0.9.1 oktey.fr NS

> nslookup
> set q=ns
> server 194.0.9.1
> oktey.fr
oktey.fr        nameserver = dns.oktey.net
oktey.fr        nameserver = ns.oktey.net

4) Pour finir, la requête DNS finale est effectuée directement auprès d’un des serveurs DNS gérant le domaine ‘oktey.fr’, les DNS « faisant autorité ». Le type d’enregistrement qui nous intéresse n’est plus NS mais A (ou CNAME). L’adresse IP de : ‘dns.oktey.net’ est 213.251.128.136, d’où la requête ci-dessous.

# dig @213.251.128.136 mail.oktey.fr A

> nslookup
> set q=A
> server 213.251.128.136
> mail.oktey.fr
Nom : mail.oktey.fr
Address: 87.248.120.148

Pour effectuer cette dernière requête, il a été nécessaire de retrouver l’IP du serveur ‘dns.oktey.net’, si l’information n’était pas dans le cache cela a nécessité de contacter les DNS, racine pour savoir qui gère .net, puis oktey.net, puis dns.oktey.net soit 3 requêtes supplémentaires.

A chaque étape, un des serveurs DNS retourné était pris au hasard afin d’effectuer la requête suivante. Il est donc vital que tous les serveurs DNS renvoient systématiquement la même réponse à une requête identique. Les serveurs DNS d’une même zone doivent donc impérativement être synchronisés entre eux.

Le découpage en étapes que nous venons de décomposer peut être affiché directement via la commande dig suivante : #dig +trace +all mail.oktey.fr

Nous vous avons présenté le fonctionnement du service DNS dans cet article, car la messagerie (tout comme le web) utilise comme fondation le service DNS. Nous remarquons que très souvent les problèmes de messagerie électronique proviennent en réalité de soucis DNS. Une bonne compréhension du fonctionnement des DNS permet bien souvent d’appréhender un grand nombre de soucis de messagerie électronique.