Qu’est-ce que le DNS et comment fonctionne la résolution des noms ?

Le DNS, pour Domain Name System ou système de noms de domaine, est un système distribué qui associe des noms lisibles, comme afnic.fr, à des données techniques, notamment des adresses IP. Il permet aux applications de trouver les serveurs sans demander aux utilisateurs de mémoriser leurs adresses numériques.

À quoi sert le DNS ?

Une adresse IP identifie une destination réseau. Un nom de domaine fournit un repère stable, même si l’hébergement change. Le DNS assure cette correspondance, mais il ne transporte ni les pages web ni les messages électroniques.

Son rôle dépasse le Web : il indique aussi les serveurs de messagerie d’un domaine et publie des informations de validation. Un même nom peut correspondre à plusieurs adresses, notamment pour répartir les connexions.

Comment fonctionne une résolution DNS ?

Lorsqu’un navigateur a besoin d’une adresse, il peut consulter son cache et les mécanismes locaux du système. Si aucune réponse utilisable n’est disponible, une requête part vers un résolveur récursif, fourni par le FAI, l’entreprise ou un service tiers. Le navigateur peut aussi utiliser son propre service DNS configuré.

Sans réponse en cache, le résolveur suit la hiérarchie. Pour www.afnic.fr, il consulte un serveur racine, qui l’oriente vers les serveurs du .fr. Ceux-ci indiquent les serveurs faisant autorité pour afnic.fr. Ces derniers fournissent les données demandées, ou un alias à résoudre.

Le résolveur travaille pour le client. Le serveur faisant autorité publie les données d’une zone, une portion administrée de l’espace DNS. L’Afnic gère la zone .fr, pas nécessairement les enregistrements de chaque domaine enregistré sous cette extension.

La délégation repose sur les enregistrements NS. Lorsque l’adresse d’un serveur de noms dépend du domaine délégué lui-même, le parent fournit des adresses complémentaires, appelées enregistrements de colle, pour éviter une dépendance circulaire.

Quels sont les principaux enregistrements DNS ?

Une requête précise un nom et un type d’enregistrement. Demander l’adresse IPv4 d’un domaine n’est donc pas la même opération que rechercher ses serveurs de messagerie.

Un CNAME n’est pas une redirection HTTP : il ne change pas l’URL affichée. Les types SVCB et HTTPS peuvent également annoncer des paramètres de connexion, comme la prise en charge de certains protocoles applicatifs.

Pourquoi le cache et le TTL sont-ils importants ?

Le cache évite de parcourir toute la hiérarchie à chaque demande. Chaque enregistrement possède un TTL, une durée de conservation exprimée en secondes. Un TTL de 3600 permet normalement de conserver la donnée pendant une heure.

La « propagation DNS » n’est donc pas une diffusion instantanée vers tous les serveurs. Après une modification, certains caches conservent encore l’ancienne valeur. Un contrôle de propagation DNS permet de comparer les réponses observées depuis plusieurs points, sans prouver que tous les caches mondiaux sont à jour.

DNSSEC, DoH et DoT : quelles différences ?

Le DNS classique utilise UDP ou TCP sur le port 53, sans chiffrement. DNS over HTTPS, ou DoH, utilise HTTPS, généralement sur le port 443. DNS over TLS, ou DoT, emploie TLS sur le port 853. En France, FDN propose notamment des services de résolution chiffrée.

DNSSEC répond à un autre besoin : vérifier l’origine et l’intégrité des données grâce à des signatures et à une chaîne de confiance. Une zone non signée ne bénéficie pas de cette authentification.

DNSSEC ne chiffre pas les requêtes. DoH et DoT protègent le trajet jusqu’au résolveur, mais celui-ci peut toujours connaître les noms demandés.

Comment lire une réponse DNS avec dig ?

La commande suivante demande les serveurs de noms de example.com. L’extrait représente le format d’une réponse, avec un TTL indicatif qui peut varier.

dig example.com NS +noall +answer

example.com.  86400  IN  NS  a.iana-servers.net.
example.com.  86400  IN  NS  b.iana-servers.net.

Les colonnes indiquent le nom, le TTL, la classe Internet, le type et la valeur. Le point final marque un nom absolu. Sans terminal, un vérificateur DNS permet d’examiner les enregistrements publiés.

Pour une requête de base, précisez le résolveur après @ et le type d’enregistrement à la fin. Voici le format d’une réponse, avec une adresse de documentation :

# Interroger un enregistrement A via un résolveur précis
dig @1.1.1.1 example.com A

; SECTION RÉPONSE :
example.com.  300  IN  A  192.0.2.1

Comparer plusieurs résolveurs permet de repérer une incohérence de cache ou de propagation :

dig @1.1.1.1 example.com A   # Cloudflare
dig @8.8.8.8 example.com A     # Google
dig @9.9.9.9 example.com A     # Quad9

D’autres types d’enregistrements s’interrogent avec la même syntaxe :

dig @1.1.1.1 example.com MX    # Serveurs de messagerie
dig @1.1.1.1 example.com TXT   # SPF, DKIM, jetons de vérification
dig @1.1.1.1 example.com NS    # Serveurs faisant autorité
dig @1.1.1.1 example.com AAAA  # Adresse IPv6

L’option +trace affiche tout le chemin de résolution depuis la racine, comme le ferait un résolveur récursif. Si un domaine renvoie une mauvaise adresse, cette commande révèle quel serveur de la chaîne est mal configuré :

dig +trace example.com A

Sous Windows, où dig n’est pas disponible, nslookup couvre l’essentiel :

nslookup example.com 1.1.1.1

Enfin, pour vérifier DNSSEC, demandez les clés ou les signatures : une réponse contenant un enregistrement RRSIG confirme que la validation fonctionne.

dig example.com DNSKEY
dig +dnssec example.com A

Quelle place occupe le DNS dans un diagnostic réseau ?

Une résolution correcte ne garantit pas qu’un site fonctionne : routage, connexion TLS ou serveur web peuvent échouer ensuite. Comprendre les adresses IP et le fonctionnement de ping aide à distinguer ces couches.

Le DNS constitue ainsi une étape du diagnostic, pas un verdict sur toute la connexion.