#DNSCopier le lien

Résolution de noms, zones, enregistrements (A/AAAA/CNAME/TXT), récursif vs itératif. DNS traduit des noms en adresses et porte des métadonnées critiques (mail, politiques, clés).

Objectifs d'apprentissage

• Décrire la résolution itérative (racine, TLD, autoritatif) et le rôle du résolveur récursif.
• Choisir et configurer correctement les enregistrements (A/AAAA, CNAME, NS, TXT) et les TTL.
• Comprendre DNSSEC (chaîne de confiance, RRSIG/DNSKEY/DS) et le caching (positif/négatif).

#Requêtes et réponsesCopier le lien

Un message DNS contient un identifiant, des flags (QR, RD, RA, AA, RCODE), et jusqu'à quatre sections: Question, Answer, Authority, Additional. RD (Recursion Desired) indique que le client souhaite une résolution récursive; RA (Recursion Available) signale qu'un serveur la fournit.

Les réponses peuvent inclure des enregistrements de glue (A/AAAA pour des NS) dans la section Additional pour briser les dépendances.

#Diagramme: stub, résolveur, racine, TLD, autoritatifCopier le lien

Condensé en une ligne par étape:

• Le résolveur (récursiveur) interroge itérativement les serveurs (racine, puis TLD, puis autoritatif).
• Enregistrements: A/AAAA (adresse), CNAME (alias), NS (serveurs), TXT (infos).

#Récursif vs itératifCopier le lien

• Itératif: le résolveur suit les délégations étape par étape (racine puis TLD puis autoritatif).
• Récursif: le stub resolver (client) demande « résous pour moi », et le résolveur récursif fait les étapes ci-dessus puis répond.

#Trace réelle: lire une réponse digCopier le lien

1$ dig +noall +answer www.example.com A2www.example.com.   3600  IN  CNAME  example.com.3example.com.       3600  IN  A      93.184.216.34

Lecture: le nom demandé est d'abord un alias (CNAME), la résolution continue sur la cible, et le TTL affiché (secondes) est celui de chaque enregistrement, pas du nom. Recommencez la commande trente secondes plus tard: le TTL affiché a baissé d'autant si vous interrogez un résolveur qui a la réponse en cache.

Trace négative (nom inexistant):

1$ dig +noall +answer +authority sous-domaine-invalide.example.com2;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN3example.com.  3600  IN  SOA  ns.example.com. hostmaster.example.com. (4              2026090101 ; serial5              7200       ; refresh6              3600       ; retry7              1209600    ; expire8              300 )      ; minimum = TTL négatif

status: NXDOMAIN prouve que le nom n'existe pas (et pas seulement qu'il n'a pas d'adresse); la section Authority ramène le SOA dont le champ minimum borne la durée de cache de cette absence.

#Caching et TTLCopier le lien

• Les résolveurs mettent en cache réponses positives et négatives (NXDOMAIN) pendant le TTL.
• Baisser trop les TTL augmente la charge; trop longs retardent la propagation.

#DNSSEC (intégrité et authenticité)Copier le lien

• Objectif: empêcher l'empoisonnement de cache en signant les zones (RRSIG) et publiant clés (DNSKEY/DS).
• Chaîne de confiance: racine, TLD, zone. Le résolveur valide les signatures jusqu'à une ancre de confiance.

Exemples d'enregistrements liés:

1example.com.  3600  IN  DNSKEY 257 3 13 <clé_publique>2example.com.  3600  IN  RRSIG  A 13 2 3600 <signature>3com.          86400 IN  DS     <hash de la DNSKEY de example.com>

#DoH et DoTCopier le lien

• DoT (DNS over TLS): DNS chiffré sur TCP/TLS port 853.
• DoH (DNS over HTTPS): DNS dans HTTP/2/3, traversant mieux les middleboxes et partageant l'infra TLS.
• Vie privée améliorée, mais déplace la confiance vers un résolveur public; attention aux politiques et au split-DNS.

#Autres types utilesCopier le lien

• MX: serveurs mail avec priorités.
• SRV: services et ports (ex.: _sip._tcp.example.com vers host:port).
• CAA: autorise quelles AC peuvent émettre des certificats pour votre domaine.
• PTR: résolution inverse (adresse vers nom) dans les zones in-addr.arpa/ip6.arpa.

#E-mail: SPF, DKIM, DMARCCopier le lien

• SPF (TXT): déclare les hôtes autorisés à envoyer des emails pour le domaine.
• DKIM: signature cryptographique des messages; clé publique publiée en DNS.
• DMARC: politique d'alignement et de traitement (none/quarantine/reject) et reporting.

Exemples:

1example.com.     IN TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.provider.com -all"2selector._domainkey.example.com. IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."3_dmarc.example.com. IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.com; adkim=s; aspf=s"

#Pièges fréquentsCopier le lien

• CNAME au sommet (apex) d'une zone: non standard (le sommet doit porter SOA/NS). Utiliser des alias spécifiques au DNS provider (ALIAS/ANAME) si disponibles.
• Chaînes de CNAME trop longues: augmentent la latence et fragilisent la résolution; limiter et surveiller.
• TTL incohérents entre A/AAAA et CNAME d'un même service: propagation imprévisible.
• Filtrage ICMP cassant PMTUD en chemin vers les serveurs d'autorité: impacts indirects sur les services.

#Lab: résolution complète et propagation TTLCopier le lien

Observez la mise en cache et le TTL en conditions réelles (adaptez le domaine):

1# Requête simple et TTL2dig +nocmd example.com A +noall +answer3 4# Résolution itérative (suivre les délégations)5dig +trace example.com6 7# Observer la différence entre résolveurs (cache/TTL restants)8dig example.com @1.1.1.1 +noall +answer9dig example.com @8.8.8.8 +noall +answer10 11# CNAME vs A: notez que le TTL affiché est celui de chaque RR12dig www.github.com +noall +answer13 14# TTL négatif (NXDOMAIN) et durée de cache

Observations attendues: (1) +trace affiche successivement la racine, les NS du TLD puis la réponse finale, exactement le chemin du diagramme ci-dessus; (2) deux résolveurs publics renvoient souvent des TTL différents pour le même nom, preuve que chacun gère son cache; (3) le TTL d'un CNAME et celui du A cible peuvent différer.

Astuce: si vous préparez une bascule, réduisez le TTL en amont (heures/jours) puis remontez-le après le changement. Vérifiez la propagation avec plusieurs résolveurs publics.

#Outils: dig pour DNSSECCopier le lien

• Interroger avec validation et voir les signatures:

1dig +dnssec example.com A2dig +dnssec +multi example.com DNSKEY

• Vérifier l'AD bit (Authenticated Data) quand le résolveur valide:

1dig +dnssec example.com @1.1.1.1 | grep " flags "  # chercher ad

• Suivre la chaîne DS vers DNSKEY:

1dig +dnssec com. DS2dig +dnssec example.com DNSKEY

#Diagnostic: trois pannes DNS et leur signature digCopier le lien

• SERVFAIL (status: SERVFAIL): le résolveur n'obtient pas de réponse valide, souvent une validation DNSSEC qui échoue ou des serveurs autoritatifs injoignables. Testez directement l'autoritatif (dig @ns1.example.com example.com A) pour isoler: si lui répond, le problème est entre le résolveur et la chaîne.
• NXDOMAIN alors que le nom existe: cache négatif périmé ou faute de frappe côté config; vérifiez chez plusieurs résolveurs, puis sur l'autoritatif. Si l'autoritatif répond mais pas le résolveur, attendez le TTL négatif du SOA.
• Réponse tronquée, bascule en TCP (flags: ... tc ...): la réponse UDP dépasse la taille; un pare-feu qui bloque le TCP/53 casse alors les grosses réponses DNSSEC. dig +tcp confirme le diagnostic en une commande.

#QuizCopier le lien

Exercice écrit (corrigé): votre zone service.example.com est un CNAME vers app.cloudprovider.net, et vous devez basculer demain vers app2.cloudprovider.net avec un TTL courant de 86400. Décrivez la séquence. Correction: aujourd'hui, abaissez d'abord le TTL (par exemple 300) sur l'enregistrement lui-même, attendez l'ancien TTL complet (24 h ici) pour que les caches expirent, faites la bascule demain, vérifiez avec trois résolveurs publics, puis remontez le TTL. Basculer sans attendre l'ancien TTL laisse des clients sur l'ancienne cible jusqu'à 24 h.