Réseau
50bvd … …
dns active-directory windows-server diagnostic réseau forwarders

Diagnostic DNS — Forwarders en REFUSED et pannes internet intermittentes

Résolution d'une panne internet intermittente causée par des forwarders DNS retournant REFUSED — diagnostic, identification et remplacement par DNS4EU et Cloudflare.

Table des matières

Des pannes internet aléatoires affectent tous les postes du réseau. Le ping fonctionne vers les IPs publiques mais pas vers les noms de domaine. C’est du DNS — voici comment diagnostiquer et résoudre.

Symptômes

  • ping 8.8.8.8 → succès ✅
  • ping google.com → échec ❌
  • Pages web inaccessibles de façon aléatoire
  • Problème intermittent, non reproductible à volonté
  • Tous les postes affectés simultanément

La distinction IP OK / Nom KO pointe immédiatement vers le DNS.

Architecture DNS

Postes Windows
    │ DNS configuré via DHCP : DC1, DC2
    ▼
Contrôleurs de domaine AD (Windows Server)
    │ Forwarders : FOURNISSEUR-DNS-A, FOURNISSEUR-DNS-B
    ▼
Internet

Diagnostic

Étape 1 — Tester la résolution locale

# Sur un poste affecté
nslookup google.com        # Utilise le DC comme DNS
nslookup google.com 8.8.8.8  # Bypass — utilise Google directement

Si le bypass fonctionne mais pas la résolution locale → problème sur les DCs ou leurs forwarders.

Étape 2 — Tester les forwarders depuis un DC

# Sur le DC
Resolve-DnsName google.com -Server 127.0.0.1    # Résolution locale
Resolve-DnsName google.com -Server FORWARDER-IP  # Tester le forwarder directement

# Avec dig depuis un poste Linux
dig @FORWARDER-IP google.com

Réponse observée :

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 12345
;; AUTHORITY SECTION: (vide)

REFUSED — le serveur DNS forwarder est joignable mais refuse de répondre à nos requêtes. Ce n’est pas une panne générale du fournisseur DNS, c’est un blocage ciblé sur notre IP publique.

Étape 3 — Confirmer le blocage

# Tester depuis une autre IP (mobile en partage de connexion)
dig @FORWARDER-IP google.com
# → Répond normalement depuis une autre IP → blocage ciblé confirmé

Pourquoi intermittent ?

Le comportement intermittent s’explique par :

  1. Plusieurs forwarders configurés en rotation — certains répondent, d’autres non
  2. Le blocage du fournisseur n’est pas permanent (TTL variable)
  3. Le cache DNS local masque temporairement le problème

Résolution

Remplacer les forwarders

# Sur chaque DC — supprimer les anciens forwarders
Set-DnsServerForwarder -IPAddress @() -PassThru

# Configurer les nouveaux forwarders diversifiés
Set-DnsServerForwarder -IPAddress @(
    "94.140.14.14",   # DNS4EU — anycast européen, RGPD
    "94.140.15.15",   # DNS4EU secondaire
    "1.1.1.1",        # Cloudflare
    "9.9.9.9"         # Quad9 — filtrage malware
) -PassThru

# Vérifier
Get-DnsServerForwarder

Vider le cache DNS

# Sur chaque DC
Clear-DnsServerCache -Force

# Sur les postes clients (si nécessaire)
ipconfig /flushdns

Valider

# Test de résolution post-changement
$domains = @("google.com", "microsoft.com", "github.com", "cloudflare.com")
foreach ($d in $domains) {
    $r = Resolve-DnsName $d -ErrorAction SilentlyContinue
    $status = if ($r) { "✅ $($r[0].IPAddress)" } else { "❌ ECHEC" }
    Write-Host "$d : $status"
}

Comparatif forwarders DNS publics

Fournisseur IP Notes
DNS4EU 94.140.14.14 / .15.15 Hébergé en Europe, RGPD, anycast
Cloudflare 1.1.1.1 / 1.0.0.1 Très rapide, privacy-focused
Quad9 9.9.9.9 / 149.112.112.112 Filtrage malware, nœuds européens
Google 8.8.8.8 / 8.8.4.4 Fiable, mais logs utilisés
DNS4EU

DNS4EU est le résolveur DNS public de l’Union Européenne — RGPD by design, anycast, gratuit. Particulièrement adapté aux environnements du secteur public ou de santé.

Monitoring DNS post-incident

Configurez une surveillance active de la résolution DNS :

# Script de monitoring — à planifier en tâche planifiée
$forwarders = @("94.140.14.14", "1.1.1.1", "9.9.9.9")
$testDomain  = "microsoft.com"

foreach ($fw in $forwarders) {
    $r = Resolve-DnsName $testDomain -Server $fw -ErrorAction SilentlyContinue
    if (-not $r) {
        # Envoyer alerte — exemple avec envoi d'email
        Send-MailMessage -To "admin@domaine.local" `
          -Subject "ALERTE DNS — Forwarder $fw ne répond pas" `
          -Body "Le forwarder $fw retourne REFUSED pour $testDomain" `
          -SmtpServer "smtp.domaine.local"
    }
}

Leçons retenues

  1. IP OK + Nom KO = DNS — toujours vérifier en premier
  2. REFUSED ≠ panne — le serveur répond, il refuse — c’est une politique, pas une coupure
  3. Diversifier les forwarders — ne jamais dépendre d’un seul fournisseur
  4. Tester les forwarders directement depuis les DCs, pas depuis les postes clients
  5. Ne pas utiliser un DNS filtrant (comme certains services de filtrage web) si vous n’avez pas de compte actif — les IPs inconnues sont souvent bloquées

Articles similaires

Comments