DNS

#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’à 4 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.

#Animation: résolution récursive (schéma)Copier le lien

#Flow: résolution récursive (résumé)Copier le lien

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

• Recurseur (résolveur) interroge itérativement les serveurs (racine → TLD → 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 → TLD → 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.

#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.

#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.

#QuizCopier le lien

#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>

#Autres types utilesCopier le lien

• MX: serveurs mail avec priorités.
• SRV: services et ports (ex.: _sip._tcp.example.com → host:port).
• CAA: autorise quelles AC peuvent émettre des certificats pour votre domaine.
• PTR: résolution inverse (adresse → 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) + 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.

#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 → DNSKEY:

1dig +dnssec com. DS | sed -n '1,80p'2dig +dnssec example.com DNSKEY | sed -n '1,80p'

#Quiz éclairCopier le lien

#Exercice : Simulation de résolution DNS récursiveCopier le lien

#Lab pratique: TTL et propagationCopier le lien

Observez la mise en cache et le TTL en conditions réelles (adapter 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.example.com CNAME +noall +answer13 14# TTL négatif (NXDOMAIN) et durée de cache

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.

Implémentez une simulation simplifiée du processus de résolution DNS récursive.

#InstructionsCopier le lien

1. Créez des structures de données pour représenter les différents types de serveurs DNS :
   • Serveurs racine
   • Serveurs TLD (Top Level Domain)
   • Serveurs autoritatifs
2. Implémentez une fonction resoudre_dns(nom_domaine) qui simule la résolution.
3. Le processus doit suivre le chemin : résolveur → racine → TLD → autoritatif.
4. Chaque serveur renvoie l'adresse du serveur suivant jusqu'à obtenir l'adresse IP.

#Exemple de codeCopier le lien

1# Simulation simplifiée de la résolution DNS2 3# Données des serveurs4serveurs_racine = {5    ".": "192.168.1.1"6}7 8serveurs_tld = {9    "com.": "192.168.2.1",10    "org.": "192.168.2.2",11    "fr.": "192.168.2.3"12}13 14serveurs_autoritatifs = {

#QuizCopier le lien