2026-09-07 — Le protocole DNS

Contexte

Matière : _Reseaux · Type : cours · Source : support Chapitre 2 — La couche Application (Partie 3) Précédent : 2026-09-07 — Le protocole HTTP Suite : 2026-09-07 — Programmation par socket

🎯 Objectifs de la séance

• Comprendre pourquoi le DNS existe et quelle est sa fonction unique.
• Connaître la hiérarchie des serveurs DNS et qui gère quoi.
• Distinguer résolution récursive et itérative.
• Savoir lire les principaux enregistrements de ressources (RR) et utiliser nslookup.

---

Partie 1 — Pourquoi le DNS ?

Créé en 1983 par Paul Mockapetris et Jon Postel (RFC 1034 et 1035), enrichi depuis par de nombreuses RFC.

Fonction principale du DNS

Nom de domaine du site Web ⟹ adresse IP de la machine qui l’héberge.

Le raisonnement du cours part d’une analogie téléphonique : les adresses servent à localiser des objets, mais les noms sont plus faciles à retenir. Le DNS fait le pont entre les deux.

     PC1                                          Serveur
172.128.1.33  ── « Where is harvard.edu ? » ──▶     DNS
              ◀── « It is at 192.0.66.20 » ───
                                                harvard.edu
                                                192.0.66.20
                                                (Web Server)

Trois propriétés à citer

• Le DNS est un protocole de couche application.
• Il est totalement transparent pour l’utilisateur final.
• Il permet d’atteindre n’importe quel site public sans savoir quelle machine l’héberge.

---

Partie 2 — Architecture du système DNS

Le DNS n’est pas un serveur, c’est un groupe de serveurs qui collaborent, distribués mondialement avec une redondance suffisante.

Qui gère quoi

Niveau	Géré par
Serveurs racine (Root)	IANA — Internet Assigned Numbers Authority (autorité centrale)
TLD — Top Level Domain (.com, .edu, .net, .fr)	IANA (autorité centrale)
Serveurs DNS faisant autorité	Les organisations elles-mêmes
Sous-domaines	Le domaine parent

Chiffre à retenir

Il existe 13 serveurs DNS racine (13 identités racine, répliquées par anycast).

La hiérarchie parent-enfant

                        Root  « . »
                          │
        ┌─────────────────┼─────────────────┐
      com               edu               net
        │
   ┌────┴──────┐
 google    microsoft
                │
             support
                │
            customer  ← serveur Web (PAS un serveur DNS)

La propriété fondamentale de la hiérarchie

Un serveur supérieur ne sait que comment atteindre directement les serveurs immédiatement inférieurs. La racine ne connaît pas customer.support.microsoft.com : elle ne connaît que les TLD.

Exemple de contenu de tables :

Serveur Root			Serveur .com
.com	IP1		.google	8.8.8.8
.edu	IP2		.microsoft	121.1.1.1
.net	IP3		…	…

Lire un nom de domaine à l’envers

Un nom de site = un chemin dans l'arbre, en ordre inverse

www.customer.support.microsoft.com.

• Le . final = le serveur DNS racine
• .com = le TLD
• .microsoft = serveur DNS de Microsoft
• .support = serveur DNS du sous-domaine
• .customer = nom du serveur qui héberge le site — ce n’est pas un serveur DNS

Enregistrer un domaine

Pour héberger www.example.com et le rendre joignable mondialement, il faut faire insérer une entrée dans la base du TLD .com — via un bureau d’enregistrement, contre paiement à l’autorité centrale.

Le registrar insère deux enregistrements dans le serveur du TLD .com :

(example.com,      dns1.example.com,  NS)
(dns1.example.com, 212.212.212.1,     A)

Il reste ensuite à faire tourner le serveur Web, connecté à Internet avec l’IP publique attribuée au nom de domaine.

---

Partie 3 — Les mécanismes de résolution

Le résolveur — First Hop DNS Server

FHDNS / DNS Resolver

Le serveur First Hop DNS est l’interface entre vous et le système DNS — il joue le rôle de proxy DNS.

• Le PC reçoit l’adresse de son résolveur statiquement (configuration manuelle) ou dynamiquement via DHCP.
• Un résolveur est partagé par plusieurs utilisateurs (d’où l’efficacité de son cache).
• Le FHDNS est configuré pour connaître les IP des serveurs racine.

Les trois cas de figure

Cas 0 — le PC vérifie son cache DNS local
        ├── correspondance trouvée → résolution immédiate, terminé
        └── pas de correspondance  → requête DNS au FHDNS
                                        │
Cas 1 ──────────────────────────────────┤
        Le FHDNS a l'IP dans SON cache → il renvoie directement la réponse
                                        │
Cas 2 ──────────────────────────────────┘
        Le FHDNS n'a pas l'IP → il interroge le serveur DNS RACINE

Récursive vs itérative

	Requête récursive	Requête itérative
Qui fait le travail	Le résolveur DNS (FHDNS)	Le client DNS lui-même
Enchaînement	Le résolveur interroge le serveur suivant selon la réponse de référence	Le client interroge le serveur suivant selon la réponse de référence
Ce que reçoit le client	Uniquement la réponse définitive (résolution ou message d’erreur)	Les réponses de référence et la réponse définitive
Charge	Sur le résolveur DNS	Sur le client DNS

La question d'examen

« Qui supporte la charge ? » — récursive → le résolveur, itérative → le client. Tout le reste en découle.

Déroulé d’une requête récursive

Vous ──▶ FHDNS ──▶ Root       « où est microsoft.com ? »
                 ◀──          « refer to .microsoft.com server (IP) »
         FHDNS ──▶ .com
                 ◀──          référence vers le serveur Microsoft
         FHDNS ──▶ microsoft
                 ◀──          référence vers .support
         FHDNS ──▶ support
                 ◀──          .customer – 212.182.1.2   ← réponse définitive
         FHDNS   [Update Cache]
Vous  ◀── réponse définitive
[Update Cache côté client]

En itératif, c’est la machine hôte qui joue ce rôle : elle reçoit chaque réponse de référence et relance elle-même la requête au serveur suivant, jusqu’à interroger directement le serveur final.

Le cache est mis à jour aux deux bouts

À la fin d’une résolution, le FHDNS et le client mettent leur cache à jour. Sous Windows, ipconfig /displaydns affiche toutes les entrées DNS mises en cache par le service client DNS.

---

Partie 4 — Les enregistrements de ressources (RR)

Resource Record

La base de données d’un serveur DNS est constituée d’enregistrements de ressources (RR), répartis en classes. La seule classe usuellement employée est la classe Internet (IN).

Les champs d’un RR

Champ	Taille	Rôle
Nom	—	Domaine où se trouve le RR
Type	16 bits	Type de données du RR (A, AAAA, CNAME, MX, NS…)
Classe	16 bits	Famille de protocoles — en pratique IN
TTL	32 bits	Durée de vie en secondes — validité de l’info en cache
Longueur	16 bits	Longueur des données qui suivent
Données	variable	Contenu, dépendant du type de ressource

Les types de RR au programme

Type	Rôle	Exemple
A	Domaine → adresse IPv4 (enregistrement hôte)	esiea.fr → 149.62.158.57 (TTL 7200)
AAAA	Domaine → adresse IPv6	google.com → 2a00:1450:4007:80c0::200e
CNAME	Alias → nom canonique (jamais vers une IP)	www.esiea.fr → esiea.fr
MX	Dirige les e-mails vers les serveurs de messagerie, avec priorité	example.com → mail1.example.com (prio 10), mail2 (prio 20)
NS	Liste les serveurs DNS faisant autorité — où trouver les autres RR	example.com → ns1.example.com, ns2.example.com

Les deux pièges classiques

• Un CNAME pointe toujours vers un nom, jamais vers une adresse IP.
• Pour MX, la plus petite valeur de priorité gagne : mail1 (10) est essayé avant mail2 (20).

La commande nslookup

nslookup

Utilitaire permettant d’interroger manuellement les serveurs DNS configurés sur la machine pour résoudre un nom d’hôte donné.

Usages :

• Résoudre un nom d’hôte à la demande.
• Diagnostiquer des problèmes de résolution de noms.
• Vérifier l’état des serveurs de noms.
• Quand la commande est émise, le serveur DNS par défaut de l’hôte est affiché.

Requête inverse

Le résolveur demande le nom d’hôte associé à une IP connue. Utile surtout pour des questions de sécurité : savoir avec qui on échange.

Trouver l’IP de son serveur DNS

# Kali Linux
grep "nameserver" /etc/resolv.conf
 
# Windows
ipconfig /all
ipconfig /displaydns   # affiche le cache DNS

---

Partie 5 — Le format des messages DNS

Même format pour la requête et la réponse. L’en-tête fait 12 octets.

Les champs de l’en-tête

Champ	Taille	Rôle
Id	16 bits	Identifiant recopié dans la réponse → permet d’apparier requête et réponse
Qr	1 bit	0 = requête, 1 = réponse
Opcode	4 bits	Type de requête
Aa	1 bit	Authoritative Answer — réponse d’une entité faisant autorité
Tc	1 bit	Truncated — le message a été tronqué
Rd	1 bit	Recursion Desired — à 1 pour demander la récursivité
Ra	1 bit	Recursion Available — la récursivité est autorisée par le serveur
Z	3 bits	Réservé (à 0). Découpé depuis en : Z, AA (Authenticated Answer), NAD (Non-Authenticated Data)
Rcode	4 bits	Type de réponse / code d’erreur
Qdcount	16 bits	Nombre d’entrées section Question
Ancount	16 bits	Nombre d’entrées section Réponse
Nscount	16 bits	Nombre d’entrées section Autorité
Arcount	16 bits	Nombre d’entrées section Additionnel

Valeurs d’Opcode

Valeur	Type
0	Requête standard (Query)
1	Requête inverse (Iquery)
2	Status d’une requête serveur
3–15	Réservé

Valeurs de Rcode

Valeur	Signification
0	Pas d’erreur
1	Erreur de format dans la requête
2	Problème sur le serveur
3	Le nom n’existe pas
4	Non implémenté
5	Refus
6–15	Réservés

Les valeurs les plus probables en examen

Rcode 0 (succès) et Rcode 3 (nom inexistant) · Qr (0/1) · Rd et Ra (le couple récursivité).

⚠️ À retenir absolument (examen)

• DNS = nom de domaine → adresse IP, protocole de couche application, transparent pour l’utilisateur.
• 13 serveurs racine · Root et TLD gérés par l’IANA · serveurs faisant autorité gérés par les organisations.
• Un serveur DNS ne connaît que le niveau immédiatement inférieur.
• Dans www.customer.support.microsoft.com., le . final = la racine et customer n’est pas un serveur DNS.
• Récursive → charge sur le résolveur · Itérative → charge sur le client.
• Le FHDNS est obtenu manuellement ou par DHCP, et connaît les IP des serveurs racine.
• RR : A (IPv4) · AAAA (IPv6) · CNAME (alias → nom, jamais une IP) · MX (mail, avec priorité) · NS (serveurs faisant autorité).
• Le TTL est en secondes, sur 32 bits.
• En-tête DNS : Qr 0/1 · Rd demande la récursivité · Ra l’autorise · Rcode 3 = nom inexistant.

❓ Points flous / à revoir

• DNS utilise-t-il UDP ou TCP selon les cas ? (bit Tc = tronqué → bascule TCP ?)
• Différence entre serveur faisant autorité et serveur secondaire
• Refaire un nslookup complet sur esiea.fr et lire chaque champ
• Que se passe-t-il si le TTL expire pendant une navigation active ?

🔗 Liens

• Précédent : 2026-09-07 — Le protocole HTTP
• Suite : 2026-09-07 — Programmation par socket
• Révisions : Révisions — DNS et sockets
• Quiz : Quiz — DNS et sockets