DNS — L'annuaire d'Internet — Introduction à TCP/IP

Table des matières

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.

Type	Exemples	Gestionnaire
ccTLD (pays)	.fr, .de, .uk, .jp	AFNIC (France), etc.
gTLD (générique)	.com, .net, .org, .edu	VeriSign, PIR, etc.
New gTLD	.app, .cloud, .security	Divers

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

Acteur	Rôle
Stub resolver	Client DNS de votre OS (lit /etc/resolv.conf)
Résolveur récursif	Serveur DNS de votre FAI ou 8.8.8.8
Serveur racine	Sait qui gère les TLD
Serveur TLD	Sait qui gère les domaines de 2e niveau
Serveur autoritatif	Connaît la réponse finale

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

Type	Description	Utilisé par
Récursive	"Trouve la réponse pour moi, je ne veux que la réponse finale"	Client → résolveur
Itérative	"Dis-moi qui peut répondre, je continue moi-même"	Résolveur → serveurs autoritatifs

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

Type	Nom	Description	Exemple
A	Address	IPv4 d'un hôte	`www.example.com → 93.184.216.34`
AAAA	IPv6 Address	IPv6 d'un hôte	`www.example.com → 2606:2800::1`
CNAME	Canonical Name	Alias vers un autre nom	`shop.ex.com → www.ex.com`
MX	Mail Exchange	Serveur de messagerie	`@ → 10 mail.example.com`
TXT	Text	Texte libre	SPF, DKIM, vérification propriété
NS	Name Server	Serveur autoritatif du domaine	`example.com → ns1.example.com`
PTR	Pointer	Résolution inverse (IP → nom)	`34.216.184.93.in-addr.arpa → www.example.com`
SOA	Start of Authority	Infos sur la zone DNS	Serveur primaire, e-mail admin, serials
SRV	Service	Port + priorité pour un service	`_sip._tcp → 10 5060 sip.example.com`
CAA	CA Authorization	Autorités de certification autorisées	`0 issue "letsencrypt.org"`

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

Abaissez le TTL à quelques minutes 24 à 48 heures avant une migration, puis remontez-le une fois la bascule validée. Changer l'enregistrement alors qu'il est encore mis en cache pour 24 heures condamne à attendre l'expiration chez chaque résolveur de la planète.

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

TTL	Effet
300s (5 min)	Propagation rapide des changements, plus de charge sur les serveurs
3600s (1h)	Bon équilibre charge/propagation
86400s (24h)	Charge minimale, mais changements propagés lentement
0	Pas de cache, chaque requête va au serveur autoritatif (déconseillé)

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 :

Protocole	Cas d'usage
UDP	Requêtes normales (< 512 octets historiquement, < 4096 avec EDNS0)
TCP	Réponses > MTU UDP, transferts de zone (AXFR/IXFR), DNSSEC

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

Mode	Port	Chiffrement	Vie privée	Support
DNS classique	53 UDP	Non	Aucune	Universel
DNS over TLS (DoT)	853 TCP	TLS	Bonne	Croissant
DNS over HTTPS (DoH)	443 TCP	TLS dans HTTPS	Très bonne	Firefox, Chrome
DNS over QUIC (DoQ)	853 UDP	TLS 1.3	Très bonne	Émergent

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

Concept	Détail
Hiérarchie	Racine → TLD → domaine → sous-domaine
13 serveurs racines	A à M, anycast, gérés par 12 organisations
Résolution récursive	Client → résolveur qui fait tout le travail
Types RR essentiels	A, AAAA, CNAME, MX, TXT, NS, SOA, PTR
TTL	Durée de mise en cache des enregistrements
UDP/TCP	UDP pour requêtes standard, TCP pour AXFR/DNSSEC
dig	Outil CLI de référence pour l'analyse DNS
DNSSEC	Signatures cryptographiques, chaîne de confiance
DoT/DoH	DNS chiffré pour la confidentialité

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.

Résolution DNS : de la racine au serveur faisant autorité, puis mise en cache pour la durée du TTL.

DNS = hiérarchie + cache. Autoritaire = vérité de zone ; récursif = chercheur/cache pour les clients.

Avant de toucher aux firewalls, validez le nom avec dig (réponse, TTL, serveur interrogé).

DNSSEC authentifie ; DoT/DoH chiffrent le canal vers le résolveur — rôles complémentaires.

DNS : dépendance critique invisible

Sans résolution, les humains et beaucoup d’apps « voient Internet mort » alors que les IP répondent. Séparez toujours : échec DNS vs échec connectivité IP. dig/nslookup sont vos premiers réflexes.

Récursion, cache, TTL

Le résolveur récursif fait le travail ; les autorités publient les zones. Les TTL gouvernent la durée de cache. Un TTL long ralentit les bascules ; un TTL court augmente la charge. En incident, flush cache local et vérifiez plusieurs résolveurs.

Enregistrements utiles

A/AAAA, CNAME, MX, TXT, NS, SRV. Les erreurs classiques : CNAME au sommet mal compris, AAAA cassé en dual-stack, MX pointant vers un CNAME, TXT SPF trop longs. Validez après chaque changement.

Avant de suspecter l’appli, demandez : « quelle IP dig renvoie, et depuis quel résolveur ? »

Sécurité DNS

Usurpation, cache poisoning, domaines lookalike, exfiltration DNS. DNSSEC, résolveurs fiables, filtrage, monitoring des requêtes anormales. Pour les sorties entreprise, un résolveur contrôlé bat le DNS « quelconque » du Wi-Fi café.

Gardez un historique des changements de zone (git ou export) : le DNS est du code d’infrastructure.

Débogage DNS en cinq commandes

dig +short example A, dig @8.8.8.8 example, dig example NS, dig example SOA, dig -x IP pour le reverse. Comparez résolveur interne et public. Vérifiez les TTL restants. Regardez les search domains du client qui suffixent des noms courts.

Les splits DNS (vue interne/externe) sont puissants et sources de tickets « ça marche chez moi ». Documentez quelle vue répond où.

Pour les migrations, baissez les TTL à l’avance, basculez, observez, remontez. Sans cette discipline, vous attendez des caches étrangers pendant des heures.

Zones, délégations et incidents de bascule

Une délégation NS incorrecte coupe une sous-zone entière. Vérifiez les glue records. Lors d’une bascule DNS de bascule de datacenter, surveillez les caches résolveurs majeurs et vos propres résolveurs récursifs. Gardez un TTL de secours documenté.

Les enregistrements CAA, SPF, DKIM, DMARC ne sont pas « hors sujet réseau » : ils lient DNS et sécurité messagerie. Un TXT mal formé casse des campagnes mail sans toucher un routeur.

En container/k8s, CoreDNS et search domains ajoutent des suffixes surprises. ndots mal réglé multiplie les requêtes. Regardez les captures DNS du pod avant d’accuser le cluster network.

DNS et résilience

Au moins deux autorités, monitoring des SOA/serial, alertes sur NXDOMAIN anormaux pour vos domaines, garde-fous sur les changements (revue à deux). Le DNS est un système critique : traitez-le comme une base de production, avec backups de zones et exercices de restauration.

Les clients caches (OS, navigateurs, stubs) ajoutent des couches. En incident, précisez « flush quel cache ». Sinon quatre personnes flushent quatre choses différentes et déclarent « ça marche chez moi » à des moments différents.

Pour le zero-trust et les ZTNA, le DNS décide souvent du split-tunneling. Une mauvaise zone split envoie le trafic corporate vers Internet ou l’inverse.

DNS malveillant et hygiène client

Les clients qui utilisent des résolveurs aléatoires contournent vos filtres DNS enterprise. Sur les postes gérés, imposez les résolveurs (GPO, MDM, DoH policies). Surveillez les tunnels DNS. Pour les noms internes, évitez les fuites vers Internet (split DNS correct).

Les typosquatting et homographes ciblent vos users : la formation aide, les protections DNS aussi. Traitez le DNS comme contrôle de sécurité, pas seulement comme confort de nommage.

En reprise d’activité, le DNS est souvent le premier levier de bascule et le premier point de panique. Exercice annuel : basculer un nom de test et mesurer le temps réel de propagation vu de plusieurs résolveurs.

DNS applicatif moderne

Service discovery (Consul, K8s DNS), noms courts, TTLs bas sur records volatils, et circuit breakers applicatifs quand le DNS bégaie : le DNS n’est plus seulement « un fichier hosts distribué ». Les apps doivent tolérer des renouvellements et des erreurs transitoires. Configurez des timeouts DNS côté runtime (JVM, glibc, musl) de façon consciente.

Lors d’incidents, demandez le résultat de résolution et le résolveur utilisé. Sans ces deux infos, vous déballez trop large.

Approfondissement terrain — dns-resolution

Dans le chapitre dns-resolution, ancrez chaque notion par un exemple vécu ou un lab de cinq minutes. Écrivez le symptôme, l’hypothèse, la commande, le résultat, la conclusion : ce journal personnel accélère votre progression plus que la relecture passive. Partagez ensuite une version anonymisée dans le wiki d’équipe pour capitaliser. Revenez sur ce texte après un incident réel : annotez ce qui manquait. La maîtrise réseau se construit par boucles courtes de pratique, pas par accumulation de slides. Fixez-vous un exercice hebdomadaire de trente minutes jusqu’à ce que les commandes deviennent des réflexes. Variez les contextes : LAN, Wi-Fi, VPN, cloud, conteneur — le même concept change de visage. Quand une explication vous semble floue, reformulez-la sans jargon à un collègue non réseau. Si vous ne pouvez pas la reformuler, la notion n’est pas encore opérationnelle. Fermez chaque session d’étude par une question ouverte que vous résoudrez la fois suivante. Gardez une liste de « myths » à déconstruire : port élevé = sécurité, ping OK = service OK, etc. Ces myths coûtent cher en production ; les tuer est un objectif pédagogique explicite. Mesurez votre temps moyen pour classer un ticket réseau simple : il doit baisser au fil des chapitres. Enfin, reliez toujours la théorie à un risque : disponibilité, confidentialité, ou intégrité. Cas 13: documentez une observation concrète liée à dns resolution dans votre environnement de lab ou de staging.

L'essentiel à retenir

Le DNS traduit les noms de domaine en adresses IP au moyen d'une hiérarchie qui part de la racine, passe par les TLD puis les serveurs faisant autorité. Le résolveur interroge chaque niveau successivement, puis met le résultat en cache pour la durée du TTL. Chaque type d'enregistrement remplit un rôle précis — A, AAAA, MX, CNAME, TXT — et DNSSEC authentifie les réponses par signature cryptographique.

Questions fréquentes

Quel est le rôle du DNS ?

Le DNS traduit des noms lisibles (www.example.com) en adresses IP et fournit d'autres enregistrements (MX, TXT, CNAME…). C'est l'annuaire distribué d'Internet.

Quelle différence entre résolveur récursif et serveur autoritaire ?

Le résolveur récursif cherche la réponse à votre place et la met en cache. Le serveur autoritaire détient la vérité pour une zone donnée.

À quoi sert le TTL DNS ?

Il indique combien de temps un enregistrement peut rester en cache. Un TTL bas accélère les bascules ; un TTL haut réduit la charge et la latence moyenne.

Pourquoi DNSSEC existe-t-il ?

Pour authentifier les réponses DNS et détecter les altérations. DNSSEC signe les enregistrements ; il ne chiffre pas le trafic de requête.

DoH et DoT changent-ils la résolution ?

Ils chiffrent le canal vers le résolveur (HTTPS ou TLS) pour limiter l'écoute et la modification sur le trajet. La hiérarchie DNS reste la même.

Quelle commande utiliser pour diagnostiquer un nom ?

`dig` (ou `nslookup`) permet d'interroger un type d'enregistrement, de voir le TTL et le serveur qui répond. C'est l'outil de base du dépannage DNS.

Progression sauvegardée dans votre navigateur.

Quiz de validation

Quiz indisponible (données invalides).

De la formation à l'action Nos experts peuvent auditer, tester ou certifier votre organisation.

Devis gratuit