DNS — L'annuaire d'Internet

Pourquoi DNS existe-t-il ?

Imaginons un monde sans DNS. Pour accéder à Google, vous devriez mémoriser 142.250.74.46. Pour Amazon : 205.251.242.103. Pour votre banque en ligne : une autre suite de chiffres incompréhensible. Et si Google change d'infrastructure et modifie ses adresses IP ? Vous devriez mettre à jour votre carnet d'adresses.

DNS (Domain Name System) est le système distribué qui traduit des noms humainement lisibles (comme www.google.com) en adresses IP machines (142.250.74.46). Conçu par Paul Mockapetris en 1983 (RFC 882 et 883, révisés par RFC 1034 et 1035 en 1987), DNS est l'une des infrastructures les plus critiques d'Internet.

DNS est aussi appelé "l'annuaire d'Internet", mais c'est un annuaire décentralisé, distribué sur des millions de serveurs dans le monde entier.

Hiérarchie DNS

DNS est organisé en une hiérarchie arborescente. La racine est représentée par un point (.), souvent implicite.

               .  (racine)
              / \
            com   fr
           /   \   \
       google amazon  orange
         |       |       |
        www     www     www

Les serveurs racines

À la racine se trouvent les 13 clusters de serveurs racines (désignés A à M), gérés par 12 organisations différentes (ICANN, VeriSign, NASA, etc.). Contrairement à ce que le "13" laisse entendre, chaque lettre représente un cluster avec des centaines de serveurs physiques via anycast.

# Liste des serveurs racines
dig . NS

# Sortie :
# .   518400  IN  NS  a.root-servers.net.
# .   518400  IN  NS  b.root-servers.net.
# .   518400  IN  NS  c.root-servers.net.
# ... jusqu'à m.root-servers.net

Les TLD (Top-Level Domains)

Juste sous la racine : les TLD (Top-Level Domains) gérés par des registres spécialisés.

Les serveurs autoritatifs

Les serveurs autoritatifs sont les serveurs qui font autorité pour un domaine donné. Ils contiennent les enregistrements DNS réels (A, AAAA, MX, etc.) du domaine.

Quand vous achetez un domaine chez OVH ou Gandi, vous configurez leurs serveurs de noms (NS) comme autoritatifs pour votre domaine.

Processus de résolution DNS étape par étape

Quand vous tapez www.google.com dans votre navigateur :

Les acteurs

Le processus complet (requête récursive)

Navigateur          Résolveur          Racine         .com TLD      Google NS
    │                   │                │               │               │
    │─ "www.google.com?" │                │               │               │
    │                   │─ "www.google.com?" (itérative) │               │
    │                   │                │               │               │
    │                   │   ◄── "Je ne sais pas, demandez │               │
    │                   │         a.gtld-servers.net"     │               │
    │                   │                                 │               │
    │                   │─ "www.google.com?" ────────────►│               │
    │                   │                                 │               │
    │                   │   ◄── "Je ne sais pas, demandez │               │
    │                   │         ns1.google.com"         │               │
    │                   │                                                 │
    │                   │─ "www.google.com?" ────────────────────────────►│
    │                   │                                                 │
    │                   │   ◄── "www.google.com = 142.250.74.46" ─────────│
    │                   │                                                 │
    │   ◄── 142.250.74.46 │                               │               │
    │                   │  (mise en cache TTL 300s)

Types de requêtes

Types d'enregistrements DNS (Resource Records)

Un enregistrement DNS (Resource Record ou RR) a le format :

nom  TTL  classe  type  données
www  300  IN      A     142.250.74.46

Les types fondamentaux

Exemples concrets

# Enregistrement A
www.ayinedjimi-consultants.fr.  300  IN  A  185.199.108.153

# Enregistrement AAAA
ipv6.google.com.  300  IN  AAAA  2a00:1450:4007:818::200e

# Enregistrement CNAME
mail.example.com.  3600  IN  CNAME  ghs.google.com.

# Enregistrements MX (priorité la plus basse = préféré)
example.com.  3600  IN  MX  10  mx1.example.com.
example.com.  3600  IN  MX  20  mx2.example.com.

# Enregistrement TXT (SPF)
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

# Enregistrement SOA
example.com.  86400  IN  SOA  ns1.example.com. admin.example.com. (
                               2026061201  ; serial
                               3600        ; refresh
                               900         ; retry
                               604800      ; expire
                               300 )       ; minimum TTL

TTL et cache DNS

Le TTL (Time To Live) d'un enregistrement DNS indique combien de temps (en secondes) les résolveurs peuvent le mettre en cache avant de redemander au serveur autoritatif.

Impact du TTL

Règle pratique : Réduire le TTL à 300s avant une migration (pour propager le changement rapidement), puis revenir à 3600s après.

Cache local et /etc/hosts

La résolution DNS suit cette priorité sur Linux :

# 1. Cache local (systemd-resolved, nscd, dnsmasq)
# 2. /etc/hosts (résolution statique locale)
# 3. Serveurs DNS dans /etc/resolv.conf

cat /etc/hosts
# 127.0.0.1   localhost
# 192.168.1.50  mon-serveur mon-serveur.local

cat /etc/resolv.conf
# nameserver 8.8.8.8
# nameserver 8.8.4.4
# search local.lan

# L'ordre est défini dans /etc/nsswitch.conf
cat /etc/nsswitch.conf | grep hosts
# hosts: files dns  ← files (hosts) avant dns

La commande dig — DNS Investigation Group

dig est l'outil de référence pour interroger les serveurs DNS. Bien plus puissant que nslookup, il affiche les réponses brutes avec tous les détails.

Requêtes dig de base

# Requête A standard (résolution IPv4)
dig google.com

# Requête AAAA (résolution IPv6)
dig AAAA google.com

# Requête MX (serveurs de messagerie)
dig MX gmail.com

# Requête NS (serveurs de noms)
dig NS google.com

# Requête TXT (SPF, DKIM, vérifications)
dig TXT google.com

# Requête PTR (résolution inverse IP → nom)
dig -x 8.8.8.8
# ou équivalent
dig PTR 8.8.8.8.in-addr.arpa.

# Requête SOA (info de zone)
dig SOA google.com

dig avancé

# Utiliser un serveur DNS spécifique (@)
dig @8.8.8.8 google.com
dig @1.1.1.1 google.com      # Cloudflare
dig @208.67.222.222 google.com  # OpenDNS

# Trace la résolution complète (mode itératif)
dig +trace google.com
# Montre chaque étape : racine → .com → google.com → réponse

# Sortie courte (juste l'IP)
dig +short google.com
# → 142.250.74.46

# Requête pour toutes les informations de zone
dig ANY google.com

# Désactiver la récursion (requête directement au serveur autoritatif)
dig +norecurse @ns1.google.com google.com A

# Afficher le RTT de la requête DNS
dig +stats google.com | grep "Query time"
# ;; Query time: 8 msec

# Format compact, sans commentaires
dig +nocomments +noquestion +noauthority +noadditional google.com

# Test DNSSEC
dig +dnssec google.com

Décoder la sortie de dig

dig google.com

# ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
#    → status: NOERROR (succès), NXDOMAIN (domaine inexistant), SERVFAIL
#
# ;; QUESTION SECTION:
# ;google.com.        IN  A
#   → Ce qu'on a demandé
#
# ;; ANSWER SECTION:
# google.com. 300  IN  A  142.250.74.46
#   → La réponse (TTL=300, A, IP)
#
# ;; Query time: 8 msec
# ;; SERVER: 8.8.8.8#53(8.8.8.8)  ← serveur qui a répondu
# ;; WHEN: Thu Jun 12 22:00:00 2026
# ;; MSG SIZE rcvd: 55             ← taille de la réponse UDP

nslookup — L'outil historique

nslookup est plus ancien que dig, moins puissant, mais disponible sur Windows et tous les systèmes.

# Résolution simple
nslookup google.com

# Utiliser un serveur DNS spécifique
nslookup google.com 8.8.8.8

# Résolution inverse
nslookup 8.8.8.8

# Mode interactif
nslookup
> server 1.1.1.1
> google.com
> exit

DNS : UDP vs TCP

DNS utilise principalement UDP sur le port 53 pour les requêtes standard. TCP est utilisé dans des cas spécifiques :

EDNS0 — Extension DNS

EDNS0 (RFC 2671) étend la capacité UDP de DNS de 512 octets à jusqu'à 4096 octets, permettant des réponses DNSSEC volumineuses sans passer par TCP.

# Vérifier le support EDNS0 d'un serveur
dig +bufsize=4096 @8.8.8.8 google.com

# Forcer TCP
dig +tcp google.com

DNSSEC — Security Extensions

DNSSEC (RFC 4033-4035) ajoute des signatures cryptographiques aux enregistrements DNS pour garantir leur authenticité et leur intégrité. Sans DNSSEC, un attaquant peut empoisonner le cache DNS d'un résolveur (DNS Cache Poisoning) et rediriger le trafic vers un site malveillant.

Comment DNSSEC fonctionne

Zone DNS signée :
  google.com.  A  142.250.74.46
  google.com.  RRSIG  (signature de l'enregistrement A)
  google.com.  DNSKEY (clé publique de la zone)
  google.com.  DS     (hash de DNSKEY, signé par le parent)

Chaîne de confiance :
  Racine (.) → .com → google.com
  Chaque niveau signe le DNSKEY du niveau suivant

Vérifier DNSSEC

# Vérifier si un domaine est signé DNSSEC
dig DNSKEY google.com +dnssec

# Validation DNSSEC complète
dig +dnssec +sigchase google.com A  # (nécessite BIND avec dnssec-tools)

# Tester avec Verisign DNSSEC Analyzer
# https://dnssec-analyzer.verisignlabs.com/

# dig avec validation DNSSEC explicite
dig +dnssec @8.8.8.8 dnssec-failed.org A
# → SERVFAIL si la validation DNSSEC échoue

Pour aller plus loin sur le durcissement DNS dans un contexte professionnel, consultez notre checklist DNSSEC et durcissement DNS 2026.

DNS over TLS (DoT) et DNS over HTTPS (DoH)

Le DNS traditionnel envoie les requêtes en clair sur le réseau. Cela permet à votre FAI, ou à tout intermédiaire, de voir tous les domaines que vous visitez.

DNS over TLS (DoT) — Port 853

Les requêtes DNS sont chiffrées via TLS. Configurable au niveau OS et résolveur.

# Tester une requête DoT avec kdig (knot-dns)
kdig -d @1.1.1.1 +tls google.com

# Configurer systemd-resolved pour DoT
cat /etc/systemd/resolved.conf
# [Resolve]
# DNS=1.1.1.1
# DNSOverTLS=yes
# DNSSEC=yes

sudo systemctl restart systemd-resolved

DNS over HTTPS (DoH) — Port 443

Les requêtes DNS passent dans des requêtes HTTPS standard. Avantage : indiscernable du trafic web normal.

# Test DoH avec curl
curl -s "https://cloudflare-dns.com/dns-query?name=google.com&type=A" \
  -H "Accept: application/dns-json" | python3 -m json.tool

# ou avec dig (via proxy DoH)
dog --https @https://1.1.1.1/dns-query google.com A

Comparatif des modes DNS

Débogage DNS : cas pratiques

Problème 1 : "Name not resolved"

# Vérifier la configuration du résolveur
cat /etc/resolv.conf
resolvectl status  # si systemd-resolved

# Le serveur DNS répond-il ?
dig @127.0.0.53 google.com   # résolveur local systemd
dig @8.8.8.8 google.com      # bypass le résolveur local

# Comparer les résultats
diff <(dig +short @8.8.8.8 google.com) <(dig +short google.com)

Problème 2 : Réponse DNS lente

# Mesurer le temps de résolution
time dig google.com > /dev/null

# Comparer plusieurs serveurs DNS
for server in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo -n "$server: "
  dig @$server google.com +stats 2>/dev/null | grep "Query time"
done

# Résultat :
# 8.8.8.8: ;; Query time: 8 msec
# 1.1.1.1: ;; Query time: 5 msec  ← gagnant
# 9.9.9.9: ;; Query time: 12 msec

Problème 3 : Suspicion d'empoisonnement DNS

# Comparer la réponse de plusieurs serveurs DNS indépendants
dig +short @8.8.8.8 example.com A
dig +short @1.1.1.1 example.com A
dig +short @9.9.9.9 example.com A

# Si les réponses diffèrent → possible empoisonnement ou hijacking

# Trace complète depuis les racines (contourne le cache)
dig +trace example.com A

Problème 4 : Propagation d'un changement DNS

# Vérifier si le nouveau A record a propagé
dig @ns1.registraire.com example.com A  # serveur autoritatif direct

# Vérifier depuis différents points de présence
# Utiliser https://whatsmydns.net/ ou depuis CLI :
for server in 8.8.8.8 1.1.1.1 208.67.222.222 9.9.9.9; do
  echo -n "$server: "
  dig +short @$server example.com A
done

Résumé de la résolution DNS

Navigateur
    │ frappe "www.google.com"
    ▼
Stub resolver (OS)
    │ vérifie /etc/hosts → pas de résultat
    │ vérifie cache local → pas de résultat
    ▼
Résolveur récursif (8.8.8.8)
    │ cache ? non
    │ demande aux serveurs racine (.)
    │ → "demandez a.gtld-servers.net pour .com"
    │ demande au TLD .com
    │ → "demandez ns1.google.com pour google.com"
    │ demande au serveur autoritatif google.com
    │ → "www.google.com A 142.250.74.46 TTL 300"
    │ met en cache 300 secondes
    ▼
Stub resolver → 142.250.74.46
    ▼
Navigateur établit connexion TCP:443 vers 142.250.74.46

Récapitulatif

Félicitations ! Vous avez terminé la formation Introduction à TCP/IP. Vous maîtrisez maintenant les fondements du protocole qui fait fonctionner Internet : du modèle OSI à la résolution DNS, en passant par TCP, UDP, ARP, IPv4 et IPv6.

Retour à l'introduction pour revoir le plan du cours.