« Le site ne répond pas » ne veut pas dire « le serveur est en panne ». Le DNS est la première brique à vérifier, car il est en amont de tout.
Étape 1 : le nom se résout-il ?
dig example.com +short
nslookup example.com
Depuis le navigateur, le DNS Lookup affiche le même résultat sans rien installer.
Trois cas possibles :
| Symptôme | Cause probable |
|---|---|
| NXDOMAIN | nom inexistant, mauvaise orthographe, zone non publiée |
| SERVFAIL | serveurs autoritaires injoignables, DNSSEC cassé |
| Réponse sans A/AAAA | enregistrement manquant ou mal saisi |
Étape 2 : comparer les résolveurs
Un changement récent peut être encore en cache. Le test de réponse DNS interroge le résolveur local, Cloudflare et Quad9 :
- Tous répondent la même chose : DNS sain.
- Seul le résolveur local échoue : problème de cache ou de configuration réseau locale.
- Les réponses diffèrent : propagation en cours, attendez le TTL.
Étape 3 : vérifier la zone
dig +trace example.com # suivre la délégation complète
dig NS example.com # serveurs autoritaires
dig MX example.com
dig TXT example.com
Le NS Lookup confirme que la délégation pointe vers les bons serveurs. Une délégation modifiée chez le registrar peut prendre jusqu'à 48 heures selon le TLD.
Étape 4 : la messagerie ne fonctionne pas
L'ordre de vérification est presque toujours le même :
- MX : le domaine reçoit-il du courrier ?
- TXT : SPF et DMARC sont-ils valides ?
- Selecteur DKIM :
dig TXT google._domainkey.example.com.
Un SPF dépassant 10 lookups DNS est ignoré par les serveurs mail, d'où des rejets difficiles à comprendre.
Étape 5 : mesurer la performance
Une résolution lente (> 100 ms) ralentit chaque première visite. Vérifiez :
dig example.com | grep -i "Query time"
Si la latence est élevée avec tous les résolveurs, le problème est côté serveur DNS ou réseau, pas côté client.
Le réflexe final
Avant d'incriminer l'application : DNS → TCP → HTTP. Réservez et testez dans cet ordre, vous gagnerez la moitié des incidents en quelques minutes.