Explications et démonstrations de l’arbre DNS

Accéder à son site web favori est une tâche assez simple, il suffit d’aller sur le navigateur et celui-ci s’occupe de tout. En général, cela prend moins de 3 secondes. C’est simple a priori pour l’utilisateur mais en réalité se cachent des actions plus complexes pour trouver le bon serveur et la bonne IP qui vont nous permettre d’accéder à notre site.

Ces actions plus complexes sont en fait des résolutions DNS faites sur un serveur pour un domaine donné. Afin d’obtenir des informations non erronées, il est essentiel de requêter les DNS qui font autorité sur le domaine recherché. C’est pourquoi le requêteur va parcourir l’arbre DNS pour trouver les serveurs DNS qui font autorité.

Dans cet article, nous allons expliquer chaque étape de l’arbre DNS : Il représente la hiérarchie du système des noms de domaine en partant des serveurs racines.

Comprendre le protocole DNS

Lorsque nous faisons une requête de résolution DNS, divers éléments sont à prendre en compte dans la question et dans la réponse DNS.
Une requête est formée de divers éléments, nous regarderons 2 sections dans le message envoyé et reçu.

1- Les flags :

Ils font partie de la section Header ou Entête en Français, celle-ci est structurée sur 12 octets et peut intégrer jusqu’à 13 flags, chacun codé sur un certain nombre de bits. Nous nous intéresserons principalement aux 4 flags suivants :

• RD : si le bit est à 1 alors la récursivité est demandée.
• AA : si le bit est à 1 c’est que le serveur interrogé fait autorité sur le domaine recherché
• TC : si le bit est à 1 c’est que le message reçu est tronqué et une requête de type EDNS devra être utilisée pour recevoir l’intégralité du message
• RCODE : Compris entre 0 et 65534. Seules les valeurs entre 0 et 5 nous importent réellement :

– 0 : Aucune erreur
– 1 : Le format de la requête n’est pas valide (Passage en EDNS obligatoire)
– 2 : Le serveur ne répond pas
– 3 : Le domaine n’existe pas
– 4 : Le serveur de nom ne supporte pas ce genre de requête
– 5 : le serveur refuse de répondre

Il est à noter que nous allons utiliser la commande DIG pour effectuer les démonstrations. De ce fait, le terme RCODE n’apparaît pas. Ce dernier est remplacé par « status » suivi non pas du bit mais du nom de l’erreur ou « NOERROR » s’il n’y en a pas.

2 – Les types de réponses :

La section réponse se compose en 3 parties. Contrairement au Header où les flags doivent obligatoirement être transmis pour envoyer un message correct, les parties de la section réponse peuvent être vides s’il n’y a pas de réponse à donner ou si la requête est tronquée (TC à 1). Voici les différents types de réponse :

Answer : Le serveur fait autorité et nous répond ce que l’on cherche.
Authority : Le serveur ne fait pas autorité sur le domaine mais nous renvoie vers celui ou ceux qui pourraient nous permettre d’avancer dans la résolution DNS.
Additional : Cette section contient des éléments additionnels tels que les adresses IPs pour les serveurs.

Vous pouvez retrouver les différents paramètres que peut avoir une requête DNS à cette adresse : https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

Démonstration et parcours de l’arbre

Maintenant que vous en connaissez un peu plus sur le protocole DNS, nous allons voir à travers plusieurs étapes la descente de l’arbre DNS afin d’obtenir les serveurs faisant autorité du domaine altospam.com.

1ère étape :

Cette étape a pour but de récupérer les noms des serveurs racines.
En utilisant la commande DIG :

dig NS .

Nous obtenons la réponse suivante :

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19633
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 446196 IN NS a.root-servers.net.
. 446196 IN NS b.root-servers.net.
. 446196 IN NS c.root-servers.net.
. 446196 IN NS d.root-servers.net.
. 446196 IN NS e.root-servers.net.
. 446196 IN NS f.root-servers.net.
. 446196 IN NS g.root-servers.net.
. 446196 IN NS h.root-servers.net.
. 446196 IN NS i.root-servers.net.
. 446196 IN NS j.root-servers.net.
. 446196 IN NS k.root-servers.net.
. 446196 IN NS l.root-servers.net.
. 446196 IN NS m.root-servers.net.

A cette étape, nous avons la liste des serveurs racines, on en dénombre 13 chacun portant une lettre allant de « A » à « M » suivie de « .root-servers.net ». En réalité il n’y a pas 13 serveurs mais beaucoup plus ! En effet, il existe 11 organisations à travers le monde qui gèrent ces « serveurs » : 8 sont américaines, 2 sont européennes et la dernière est japonaise. Ces organisations ont réparti leurs serveurs sur plus de 189 sites aujourd’hui et chaque site héberge des centaines de machines. On ne connait donc pas le nombre réel de serveurs racines, le but est d’avoir une disponibilité de 100% à tout moment.

2ème étape :

Nous effectuerons à partir de maintenant des requêtes non récursives, cela signifie que nous ne voulons pas que le serveur interrogé effectue la résolution de l’arbre à notre place. Le Flag RD de la requête doit avoir un bit à 0, sur DIG c’est l’option « +norecurse ». Quand on utilise DIG, RD n’apparait plus dans les flags si celui-ci est à 0. Nous allons maintenant interroger un serveur racine au hasard dans le but de récupérer les serveurs qui font autorité sur altospam.com. En utilisant la commande DIG :

dig +norecurse NS altospam.com @e.root-servers.net

Nous obtenons la réponse suivante :

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26357
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;altospam.com. IN NS

;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
[…]
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30

La réponse retournée est de type Authority, nous n’avons obtenu aucun serveur faisant autorité sur notre domaine mais sur le domaine de premier niveau « .com ». La réponse contient aussi des adresses IPv4 et IPv6 dans la section Additional. Il faut savoir que DIG permet d’interroger directement le nom du serveur mais il est préférable d’utiliser son IP en l’absence d’enregistrement GLUE.

Que signifie le terme GLUE ? Il s’agit tout simplement d’une adresse IP d’un serveur de nom. Cet enregistrement devient obligatoire lorsque le serveur de nom est un sous domaine du domaine recherché. Prenons l’exemple suivant : Si ns1.domaine.tld est un serveur DNS de domaine.tld, alors comme ns1.domaine.tld est contenu dans domaine.tld, pour éviter les références circulaires, il faudra obligatoirement créer une GLUE auprès des DNS de .tld c’est-à-dire leur transmettre l’ip de ns1. domaine.tld.

Vous trouverez des informations supplémentaires ainsi qu’une vidéo explicative sur le site de l’AFNIC https://www.afnic.fr/ext/dns/html/cours245.html#619

En sachant ceci, nous utiliserons les adresses IPv4 et IPv6 fournies en Additional. Si aucune n’est fournie, dans ce cas nous utiliserons une IP obtenue par une nouvelle requête DNS.

3ème étape :

Ceci est la dernière étape de l’arbre DNS, nous allons interroger au hasard un des serveurs gérant le .COM en utilisant une IPv4 obtenue dans la section Additionnal de l’étape 2. En utilisant la commande DIG :

dig +norecurse NS altospam.com @192.48.79.30

L’IP 192.48.79.30 est celle du serveur j.gtld-servers.net.

Nous obtenons la réponse suivante :

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37590
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;altospam.com. IN NS

;; AUTHORITY SECTION:
altospam.com. 172800 IN NS ns-725.awsdns-26.net.
altospam.com. 172800 IN NS ns-343.awsdns-42.com.
altospam.com. 172800 IN NS ns-1607.awsdns-08.co.uk.
altospam.com. 172800 IN NS ns-1454.awsdns-53.org.

;; ADDITIONAL SECTION:
ns-725.awsdns-26.net. 172800 IN A 205.251.194.213
ns-343.awsdns-42.com. 172800 IN A 205.251.193.87

Tous les serveurs NS de .COM nous répondent le même résultat soit 4 serveurs dans la section Authority. Il s’agit bien des serveurs AWS Route 53 qui gèrent notre domaine. Ce sont ces serveurs qui forment notre SLIST (dénomination utilisée dans la RFC N° 1035), c’est-à-dire les serveurs de noms qui font autorité sur le domaine recherché et que l’on devra interroger lorsque l’on souhaitera connaître les enregistrements MX, A, TXT…

Les vérifications de la SLIST

L’objectif de ce point est de vérifier qu’il y ait une cohérence entre les réponses des DNS de notre SLIST comme le ferait un outil de diagnostic, mais en temps normal cette étape n’est pas faite par un requêteur standard. Récupérer ces 4 serveurs ne suffit pas, il faut vérifier que ces DNS soient correctement configurés pour le domaine altospam.com. Il faut s’assurer qu’ils nous répondent en UDP (ou TCP) sur le port 53, qu’ils soient synchronisés avec les bonnes informations et aussi qu’ils retournent cette liste de serveurs lorsqu’on les interroge. Nous allons donc requêter ces 4 serveurs avec leurs IPv4 :

dig +norecurse NS altospam.com @205.251.194.213

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42511
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;altospam.com. IN NS

;; ANSWER SECTION:
altospam.com. 172800 IN NS ns-1454.awsdns-53.org.
altospam.com. 172800 IN NS ns-1607.awsdns-08.co.uk.
altospam.com. 172800 IN NS ns-343.awsdns-42.com.
altospam.com. 172800 IN NS ns-725.awsdns-26.net.

La première chose que l’on voit est que nous obtenons une réponse de type Answer ainsi que les 4 serveurs présents dans notre SLIST. Il faut ensuite vérifier le SOA renvoyé par chacun des serveurs. Les informations doivent être identiques, notamment le Serial. En effectuant un :

dig +norecurse SOA altospam.com @205.251.194.213

Nous obtenons la réponse suivante :

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18579
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;altospam.com. IN SOA

;; ANSWER SECTION:
altospam.com. 172800 IN SOA ns-1454.awsdns-53.org. awsdns-hostmaster.amazon.com. 2014070403 7200 900 1209600 86400

Tous les serveurs nous répondent le même SOA. Ceux-ci nous permettent d’obtenir le serveur DNS maître qui fait autorité sur le domaine : ns-1454.awsdns-53.org. C’est via celui-ci que les 3 autres serveurs secondaires vont récupérer leurs informations DNS. On en déduit qu’il est extrêmement important d’avoir au moins 2 serveurs DNS pour un domaine afin d’augmenter le taux de disponibilité, c’est d’ailleurs ce que recommande la RFC 2182 dans la section 5. De plus, pour chaque serveur, il faut que son ou ses IPs soient sur des classes d’adresses différentes et de préférence sur des AS (https://fr.wikipedia.org/wiki/Autonomous_System) différents.

Dans notre exemple, les serveurs ns-1454.awsdns-53.org (205.251.197.174), ns-1607.awsdns-08.co.uk (205.251.198.71), ns-343.awsdns-42.com (205.251.193.87) et ns-725.awsdns-26.net (205.251.194.213) possèdent tous des IP sur des classes C différentes.

Absence de DNS pour le domaine recherché

Il est possible que le domaine que l’on cherche ne possède pas de DNS, c’est le cas par exemple pour fr.wikipedia.org. Le domaine wikipedia.org possède 3 serveurs DNS qui font autorité, nous utiliserons ns0.wikipedia.org pour nos tests. En effectuant un dig :

dig +norecurse NS fr.wikipedia.org @ns0.wikimedia.org

Nous obtenons la réponse suivante :

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60224
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
;; QUESTION SECTION:
;fr.wikipedia.org. IN NS

;; AUTHORITY SECTION:
wikipedia.org. 3600 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2017080414 43200 7200 1209600 3600

Le SOA du domaine wikipedia.org nous est renvoyé, cela signifie que le sous domaine n’a pas de DNS propre et qu’il faut requêter le serveur ns0.wikimedia.org pour avoir nos réponses. Faisons le test avec:

 dig +norecurse A fr.wikipedia.org @ns0.wikimedia.org

Nous obtenons la réponse suivante :

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26696
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
;; QUESTION SECTION:
;fr.wikipedia.org. IN A

;; ANSWER SECTION:
fr.wikipedia.org. 600 IN A 91.198.174.192

;; ADDITIONAL SECTION:
fr.wikipedia.org. 600 IN AAAA 2620:0:862:ed1a::1

Le serveur ns0.wikimedia.org fait bien autorité sur fr.wikipedia.org et nous donne une réponse de type Answer, ainsi qu’un Additional.

Conclusion

Pour terminer, on trouve assez rapidement les DNS d’un domaine quand celui-ci est correctement configuré. Il est extrêmement important de se référer aux DNS qui font autorité sur le domaine recherché plutôt que d’interroger un DNS en mode récursif et obtenir une réponse du cache. En effet, celui-ci peut ne pas être à jour et on obtiendrait des informations obsolètes. Un autre point important est de vérifier que tous les serveurs DNS de la zone soient bien synchronisés et renvoient les mêmes informations. Si ce n’est pas le cas, il deviendra impossible de savoir quel serveur répond la bonne information. Si vous avez 2 serveurs DNS pour votre domaine et qu’ils renvoient 2 informations différentes, vous aurez une erreur une fois sur 2.