~/docs/resources/dns-avant-https-parcours-requete-checklist.mdDerniere modification : maintenant

AUDIENCE:Équipes IT, support, ops, admin réseau, débutants en cybersécurité, toute personne qui doit diagnostiquer “le site ne s’ouvre pas”.

PROMESSE:En 15 minutes, vous pouvez expliquer le DNS avec un schéma simple, vérifier quel résolveur est utilisé, repérer des domaines anormaux, et identifier les preuves à collecter.

DNS avant HTTPS : suivre une requête et vérifier l’essentiel

Une ressource terrain pour comprendre “où est le site ?” et contrôler ce qui compte, sans confondre DNS et contenu web.

Objectif : suivre une requête DNS de bout en bout et en tirer une checklist de vérification réutilisable.

##Le mécanisme central (une seule idée)

Avant d’ouvrir un site, le navigateur doit d’abord trouver “où aller”. Le DNS sert à ça : transformer un nom lisible en information pour localiser le service demandé.

Pensez “annuaire distribué”. Le DNS indique une destination. Il ne transporte pas la page, ni son contenu applicatif.

Fait vérifié (Cloudflare Learning Center - DNS, https://www.cloudflare.com/learning/dns/what-is-dns/) : le résolveur consulte son cache puis interroge la hiérarchie DNS jusqu’à obtenir une réponse autoritative.

Conséquence pratique : si le DNS est lent, faux, ou détourné, la connexion HTTPS peut ne jamais démarrer, même si le site est en bonne santé.

##Les 7 vérifications rapides (sans outil imposé)

-Identifier quel résolveur DNS est réellement utilisé par le poste ou le serveur (et si c’est attendu).
-Vérifier si la réponse vient du cache (local/résolveur) ou d’une recherche complète (utile pour expliquer un “ça marche chez moi”).
-Repérer les domaines inhabituels ou récents dans les requêtes DNS (volume, fréquence, suffixes, typos).
-Contrôler qui peut modifier les zones DNS autoritatives (droits, comptes, processus de changement).
-Vérifier la cohérence “nom -> destination” pour les services critiques (environnements, sous-domaines, partenaires).
-S’assurer que la journalisation DNS utile existe quelque part (poste, résolveur, passerelle) et qu’elle est exploitable en incident.
-En cas de panne web, séparer clairement : “DNS résout ?” puis “HTTPS répond ?” (ne pas mélanger les deux étapes).

##Parcours d’une requête : de la barre d’adresse à la connexion

[01]L’utilisateur saisit example.com dans le navigateur

[02]Le poste interroge son résolveur DNS configuré

[03]Le résolveur vérifie d’abord son cache

[04]Sinon, il remonte la hiérarchie DNS jusqu’à une réponse autoritative

[05]Le poste reçoit la destination et démarre ensuite la connexion HTTPS

Fiche pédagogique 1/3 : La résolution DNS expliquée — Fiche 1/3 - débutant essentiel

##Checklist terrain : contrôles + preuves à collecter

Groupe 1 : A. Vérifier le résolveur utilisé

->Lister les résolveurs attendus (poste, serveurs, VPN, Wi‑Fi invité) et comparer au réel.
->Vérifier les chemins de configuration (DHCP, statique, profils MDM, configuration VPN).
->En cas d’écart : documenter “qui”, “où”, “depuis quand”, et “sur quel périmètre”.
->Preuve à collecter : configuration réseau du poste/serveur montrant le résolveur en usage.

Groupe 2 : B. Surveiller les domaines anormaux

->Définir ce qui est “anormal” pour votre contexte (domaines inconnus, pics, typos, TLD rares, nouveaux sous-domaines).
->Créer une routine simple : échantillon quotidien/hebdo des requêtes et recherche des écarts.
->En incident : isoler la liste des domaines contactés juste avant l’événement (chronologie).
->Preuve à collecter : extrait de logs DNS (horodatage, client, domaine demandé, réponse).

Groupe 3 : C. Protéger les zones autoritatives

->Lister vos zones critiques (public, interne, partenaires) et leurs propriétaires.
->Vérifier les droits de modification et l’authentification des comptes d’administration.
->Vérifier le processus de changement (demande, validation, trace, rollback).
->Preuve à collecter : historique des changements DNS (qui a modifié quoi, quand).

Fiche pédagogique 2/3 : La hiérarchie DNS expliquée — Fiche 2/3 - débutant guidé

##Plan opérationnel : où agir, quoi observer, quoi décider

Une carte simple pour trier “DNS” vs “HTTPS” et savoir quoi collecter avant de conclure.

1) Localiser (DNS)

├─Entrée : nom de domaine demandé
├─Sortie attendue : destination (réponse DNS)
└─Observation utile : cache vs recherche complète

2) Connecter (HTTPS ensuite)

├─Entrée : destination obtenue via DNS
├─Action : démarrage de la connexion HTTPS
└─Décision : si HTTPS échoue mais DNS est OK, diagnostiquer côté service/TLS/réseau

3) Contrôler (surveillance et gouvernance)

├─Contrôle : vérifier le résolveur utilisé (conformité)
├─Détection : surveiller les domaines anormaux (écarts)
└─Prévention : protéger les zones autoritatives (droits et changements)

4) Réagir (incident)

├─Triage : séparer “DNS ne résout pas” vs “résout mais ne se connecte pas”
├─Collecte : logs DNS + configuration résolveur + historique des changements
└─Action : corriger la source (résolveur, domaine anormal, zone autoritative)

Fiche pédagogique 3/3 : Le résolveur DNS expliqué — Fiche 3/3 - débutant enrichi

##Questions courtes (et erreurs fréquentes)

Le DNS transporte-t-il la page web ?

Non. Le DNS sert à localiser un service. La page arrive plus tard, pendant la connexion et les échanges applicatifs (ex. HTTPS). Gardez cette séparation en diagnostic.

Pourquoi parler de “réponse autoritative” ?

C’est le point où le résolveur obtient une réponse depuis la source qui fait autorité pour la zone. Si vous ne savez pas d’où vient la réponse, vous diagnostiquez à l’aveugle.

Quelles preuves minimales garder pour être efficace en incident ?

Configuration du résolveur réellement utilisé, extrait de requêtes DNS autour de l’événement, et historique des changements sur les zones autoritatives. Cela suffit souvent pour trier vite.

Test simple : pouvez-vous l’expliquer sans citer un produit ?

Essayez : “Mon navigateur demande un annuaire distribué pour trouver la destination du nom, puis seulement après il se connecte au service.” Si vous y arrivez, vos diagnostics seront plus propres.