Aller au contenu

DNS

Le Domain Name System (DNS) est un service fondamental d'Internet qui permet de traduire des noms de domaine conviviaux (lisibles par les humains) en adresses IP numériques (comprises par les ordinateurs).

Sans DNS, les utilisateurs devraient retenir et saisir directement les adresses IP pour accéder aux sites web.

Source : Internet Society - Happy 30th Birthday, DNS!

Traduction des noms de domaine

Hiérarchie des domaines

  • Le DNS est organisé de manière hiérarchique et arborescente :
    • Serveurs racines → point d'entrée du système.
    • Domaines de premier niveau (TLD) : .com, .org, .net, mais aussi des TLD nationaux comme .ch (Suisse) ou .fr (France).
    • Domaines secondaires : exemple.com.
    • Sous-domaines : blog.exemple.com.

dns-hierarchy.png

Source

Serveurs DNS

  • Les serveurs DNS sont des systèmes spécialisés qui conservent les informations liant noms de domaine et adresses IP.
  • Différents rôles existent :
    • Serveurs racines → gèrent la liste des TLD.
    • Serveurs TLD → connaissent les serveurs responsables d'un domaine particulier (serveurs autoritaires).
    • Serveurs autoritaires → contiennent les enregistrements DNS définitifs d'un domaine donné.
  • À titre d'illustration : il existe 13 noms de serveurs racines logiques (de a.root-servers.net à m.root-servers.net), gérés par 12 organisations indépendantes. Grâce à la technique de l'anycast, chaque nom correspond en réalité à plusieurs centaines d'instances physiques réparties dans le monde.
  • Source : IANA - Root Servers

dns-server.png

Source

Résolution DNS

  • Quand vous saisissez une URL dans un navigateur, votre ordinateur interroge un résolveur DNS local (souvent fourni par le fournisseur d'accès à Internet ou configuré manuellement, ex. Google DNS 8.8.8.8).
  • Si le serveur local ne connaît pas la réponse, il contacte successivement les serveurs racines, les serveurs TLD puis les serveurs autoritaires jusqu'à trouver l'adresse IP correcte.

Mise en cache

  • Les réponses DNS sont mises en cache par les systèmes d'exploitation et navigateurs.
  • Cela accélère les requêtes futures vers un même domaine et réduit la charge sur les serveurs DNS supérieurs (racine et TLD).

TTL (Time to Live)

  • Chaque enregistrement DNS possède un TTL (durée de vie).
  • Tant que le TTL n'est pas expiré, l'information reste en cache.
  • Une fois le TTL dépassé, une nouvelle résolution est nécessaire pour obtenir une réponse actualisée.

Sécurité DNS

  • Le DNS peut être la cible d'attaques telles que :
    • DNS spoofing (empoisonnement de cache, redirection vers de faux sites).
    • Attaques DDoS (déni de service distribué) contre des serveurs critiques.
  • Des mécanismes comme DNSSEC (DNS Security Extensions) permettent de renforcer la sécurité en garantissant l'authenticité et l'intégrité des réponses DNS mais pas leur confidentialité (une requête DNSSEC reste lisible en clair sur le réseau).
  • Pour protéger la confidentialité des requêtes (empêcher un intermédiaire réseau de voir quels sites sont consultés), des protocoles complémentaires ont été développés : DNS over HTTPS (DoH) et DNS over TLS (DoT), qui chiffrent les échanges entre le client et le résolveur. Ces protocoles sont aujourd'hui largement déployés par défaut dans les navigateurs modernes (Firefox, Chrome) et par des résolveurs publics comme Cloudflare (1.1.1.1) ou Google (8.8.8.8).

Le processus DNS, étape par étape

  1. Requête depuis le client

    • Le processus commence lorsqu'un client (par ex. un navigateur web) souhaite accéder à un site comme google.com.
    • Le client cherche d'abord l'adresse IP dans son cache local (ordinateur ou navigateur).
    • Si l'adresse est déjà connue et valide, elle est utilisée directement et le processus s'arrête.
    • Sinon, la requête est envoyée à un serveur DNS récursif (souvent fourni par le FAI ou configuré manuellement, ex. Google DNS 8.8.8.8).

  2. Serveur DNS racine

    • Si le serveur récursif ne possède pas l'information en cache, il interroge un serveur racine (root server).
    • Les serveurs racines ne donnent pas l'adresse IP finale, mais renvoient l'adresse du serveur TLD (Top-Level Domain) correspondant (ex. .com, .org, .ch).

  3. Serveur TLD

    • Le serveur récursif interroge le serveur TLD approprié (par ex. le TLD .com pour google.com).
    • Le serveur TLD répond avec l'adresse du serveur DNS autoritaire du domaine demandé.

  4. Serveur DNS autoritaire

    • Ce serveur contient les enregistrements officiels du domaine.
    • Il renvoie l'adresse IP exacte au serveur récursif. À titre indicatif : une des adresses IP publiques de google.com (Google utilisant de nombreuses adresses réparties par anycast selon la localisation, la valeur exacte varie).
    • Le serveur récursif met en cache cette information pour accélérer les futures requêtes.

  5. Réponse au client

    • Le serveur récursif renvoie l'adresse IP au client.
    • Le navigateur dispose désormais de l'adresse pour contacter le serveur web du domaine.

  6. Connexion au serveur

    • Enfin, le client utilise l'adresse IP pour établir une connexion réseau (généralement via TCP/IP et HTTP/HTTPS).
    • Le contenu du site web peut alors être chargé et affiché.

dns-lookup.png

Source image

Note

Avant l'introduction du DNS, la résolution des noms de domaine en adresses IP reposait sur un fichier texte centralisé appelé hosts.txt.

  • Ce fichier était mis à jour manuellement par les administrateurs système et distribué à tous les ordinateurs connectés à ARPANET.
  • Lorsqu'un utilisateur souhaitait se connecter à une machine via son nom de domaine, le système local consultait d'abord hosts.txt.
  • Si une correspondance était trouvée, l'adresse IP associée était utilisée pour établir la connexion.
  • Le principal inconvénient de ce système était la difficulté de mise à jour à mesure que le réseau grandissait.

Au début des années 1980, la croissance rapide d'ARPANET et sa transition vers le protocole TCP/IP rendirent ce mécanisme impraticable. Le DNS fut formellement défini en novembre 1983 par Paul Mockapetris dans les RFC 882 et 883 (remplacées depuis par les RFC 1034 et 1035, toujours en vigueur aujourd'hui).

Tip

Le fichier hosts.txt existe encore aujourd'hui sur les systèmes d'exploitation modernes, notamment :

  • Windows : %SystemRoot%\system32\drivers\etc\hosts
  • Unix / macOS : /etc/hosts

Lorsqu'un nom de domaine doit être résolu, le système consulte encore ce fichier en premier. Si aucune correspondance n'est trouvée, la requête est ensuite transmise au système DNS.