Le DNS : du concept à la mise en œuvre

Présentation générale

Le Domain Name System (DNS) est le système qui traduit les noms de domaine lisibles par l’humain (ex. example.com) en adresses IP numériques compréhensibles par les machines (ex. 93.184.216.34). Sans cette couche d’abstraction, chaque utilisateur devrait mémoriser des suites de chiffres pour accéder à un site web ou à tout autre service réseau, ce qui serait impraticable à grande échelle.

En pratique, le DNS fonctionne comme un annuaire distribué, hiérarchisé et résilient, capable de répondre à des milliards de requêtes chaque jour à travers le monde.

Historique : date de création et créateur

Ces documents ont posé les bases de l’architecture hiérarchique, du modèle de résolution itérative et des différents types d’enregistrements (records).

Pourquoi le DNS ?

1. Lisibilité – Les humains retiennent plus facilement des mots que des nombres.
2. Scalabilité – Un annuaire centralisé serait un point unique de défaillance ; le DNS répartit la charge sur des milliers de serveurs.
3. Flexibilité – Les enregistrements DNS permettent de pointer plusieurs services (site web, mail, services cloud…) vers différentes adresses IP, voire de changer de serveur sans toucher aux clients.
4. Redondance et tolérance aux pannes – La hiérarchie et la réplication assurent la continuité même en cas de perte d’un serveur ou d’une liaison.

Principes de base

Architecture hiérarchique

racine (.) → serveurs racines
      └─ TLD (com, org, net, fr, …) → serveurs de zone TLD
            └─ Domaine de second niveau (example.com) → serveurs autoritaires
                  └─ Sous‑domaines (www.example.com, mail.example.com)

• Serveur racine : 13 ensembles (a–m) de serveurs répartis mondialement, chacun utilisant le protocole Anycast pour offrir plusieurs instances physiques.
• Serveur TLD : gère les zones de premier niveau (ex. .com, .fr).
• Serveur autoritaire : détient les enregistrements définitifs d’un domaine (ex. example.com).

Résolution d’une requête

1. Le client (résolveur récursif) interroge son résolveur local (souvent fourni par l’opérateur ou le fournisseur DNS).
2. Si le résolveur ne possède pas la réponse en cache, il commence une résolution itérative :
   • Interroge un serveur racine → obtient les adresses des serveurs TLD.
   • Interroge le serveur TLD correspondant → obtient les serveurs autoritaires du domaine.
   • Interroge le serveur autoritaire → reçoit l’enregistrement demandé.
3. Le résolveur renvoie la réponse au client et la met en cache pendant la durée de vie (TTL) indiquée.

IPv4 et IPv6 dans le DNS

Le DNS a été conçu dès le départ pour supporter les deux familles d’adresses. Aujourd’hui, la plupart des zones publient simultanément les enregistrements A et AAAA afin d’assurer la compatibilité avec les clients IPv4 et IPv6.

Types de paquets (enregistrements DNS)

Ces enregistrements sont définis dans les RFC 1035 et leurs extensions ultérieures (ex. RFC 7208 pour SPF, RFC 8659 pour CAA).

Le rôle des serveurs racines

• Pourquoi ce choix ?
  • Robustesse – En limitant le nombre de points d’entrée (13 ensembles), le système minimise les risques de désynchronisation tout en offrant une redondance géographique massive grâce à l’Anycast.
  • Performance – Les serveurs racines sont situés dans des centres de données à très haut débit, garantissant des temps de réponse minimaux pour la première étape de la résolution.
  • Gestion centralisée – Le comité de gestion des racines (Root Server Management System, géré par l’ICANN) assure la cohérence et la mise à jour des adresses des serveurs TLD.
• Composition actuelle (au 2025) :
  • A‑M – 13 identifiants, chacun pouvant regrouper plusieurs instances physiques (plus de 1000 serveurs réels).
  • Opérateurs majeurs : Verisign, University of Maryland, NASA, RIPE NCC, JPRS, etc.

Registrars et registre (registry)

Le processus d’enregistrement se déroule ainsi : le propriétaire achète le domaine auprès d’un registrar, qui transmet les informations au registry du TLD concerné. Le registry met à jour la zone du TLD, incluant les enregistrements NS pointant vers les serveurs autoritaires du domaine.

Normes et RFC majeurs

Ces documents constituent la base normative du protocole et sont régulièrement mis à jour par l’IETF.

Synthèse du flux complet (exemple)

1. Utilisateur tape www.example.com dans son navigateur.
2. Résolveur local (ex. celui de l’opérateur) interroge son cache. Aucun résultat → il lance une résolution récursive.
3. Interrogation du serveur racine (.) → réponse contenant les adresses des serveurs TLD .com.
4. Interrogation d’un serveur TLD .com → réponse contenant les serveurs autoritaires de example.com.
5. Interrogation du serveur autoritaire → renvoie l’enregistrement A (ou AAAA) de www.example.com.
6. Résolveur renvoie l’adresse IP au client, la met en cache (TTL indiqué dans le SOA).
7. Navigateur ouvre une connexion TCP/HTTPS vers l’adresse IP reçue.

Références

1. Mockapetris, P. V. (1983). Domain Names – Concepts and Facilities, RFC 882.
2. Mockapetris, P. V. (1983). Domain Names – Implementation and Specification, RFC 883.
3. Mockapetris, P. V. (1987). Domain Names – Concepts and Facilities, RFC 1034.
4. Mockapetris, P. V. (1987). Domain Names – Implementation and Specification, RFC 1035.
5. Internet Engineering Task Force (IETF). (1995). DNS Security Extensions, RFC 1912.
6. IETF. (2005). DNS Extensions to Support IPv6, RFC 2671.
7. IETF. (2016). DNS over HTTPS (DoH), RFC 8484.
8. IETF. (2020). DNS over TLS (DoT), RFC 7858.
9. ICANN. Root Server System Overview. Disponible sur https://www.icann.org/resources/pages/root-servers-2012-02-25-en.
10. AFNIC. Gestion des domaines .fr. Disponible sur https://www.afnic.fr.