Une panne DNS intermittente se mesure avant de se corriger

Quand une application fonctionne une minute et échoue la suivante, vider le cache masque souvent la preuve. Comparez le même nom, depuis le même client, avec chaque serveur DNS, en conservant heure, latence, code de réponse et réponse.

Ce guide cible Windows 11 et Windows Server 2016 à 2025. Les commandes sont en lecture seule, sauf celles marquées comme changements. Les domaines et adresses d’exemple sont fictifs.

1. Définir exactement le symptôme

Une connexion qui échoue après une réponse DNS correcte n’est pas une panne DNS. Testez ensuite l’adresse et le port applicatif séparément.

Nom court ou FQDN; type A, AAAA, CNAME, SRV ou PTR.
Client, sous-réseau, VPN ou site touché; heure et fréquence.
NXDOMAIN, SERVFAIL, délai, mauvaise adresse ou échec applicatif après une réponse correcte.
Résolution interne, externe ou split DNS; serveur réellement interrogé.

2. Relever la configuration du client

Commencez par les serveurs configurés sur l’interface et la connectivité vers eux. Relevez les cartes virtuelles, VPN et suffixes de recherche : plusieurs interfaces peuvent expliquer des résultats différents.

Dans Active Directory, les membres utilisent normalement les DNS internes capables de résoudre les zones AD. Ne remplacez pas un DNS interne par un résolveur public comme correction.

Lecture seule — interfaces et DNS

Get-DnsClientServerAddress -AddressFamily IPv4 |
  Where-Object ServerAddresses |
  Format-Table InterfaceAlias, InterfaceIndex, ServerAddresses -Auto

Get-NetIPConfiguration |
  Select-Object InterfaceAlias, InterfaceIndex, NetProfile,
    @{n='IPv4';e={$_.IPv4Address.IPAddress}}

3. Interroger chaque serveur directement et répéter

Resolve-DnsName permet de choisir le serveur. -DnsOnly évite LLMNR et NetBIOS; -NoHostsFile écarte hosts. Comparez la même requête et conservez les échecs.

192.0.2.0/24 est réservé aux exemples. Remplacez ces adresses par vos DNS autorisés. Une seule réponse lente ne suffit pas : cherchez une corrélation par serveur, site, type ou période.

Lecture seule — série chronométrée

$Name = 'app.example.internal'
$Servers = '192.0.2.10','192.0.2.11' # fictional TEST-NET
foreach ($Server in $Servers) {
  1..10 | ForEach-Object {
    $sw = [Diagnostics.Stopwatch]::StartNew()
    try {
      $r = Resolve-DnsName -Name $Name -Server $Server -Type A -DnsOnly -NoHostsFile -ErrorAction Stop
      [pscustomobject]@{ Time=Get-Date; Server=$Server; Ms=$sw.ElapsedMilliseconds; Status='OK'; Answer=($r.IPAddress -join ',') }
    } catch {
      [pscustomobject]@{ Time=Get-Date; Server=$Server; Ms=$sw.ElapsedMilliseconds; Status='FAIL'; Answer=$_.Exception.Message }
    }
    Start-Sleep -Seconds 2
  }
}

4. Comparer cache, TTL et réponse

Le cache peut conserver une ancienne adresse. Un TTL bas augmente les requêtes; un TTL élevé prolonge une donnée erronée. Les réponses négatives peuvent aussi être mises en cache.

Vider le cache change l’état et détruit une preuve. Capturez d’abord les entrées. Une amélioration après nettoyage oriente vers le cache ou le TTL, sans prouver la cause.

Cache et changement contrôlé

Get-DnsClientCache |
  Where-Object Entry -eq 'app.example.internal' |
  Format-List Entry, RecordName, RecordType, Data, TimeToLive, Status

# CHANGE: clears the whole client cache after evidence is saved.
# Clear-DnsClientCache

Microsoft: Get-DnsClientCache ↗

5. Distinguer zone interne, redirecteur et Internet

Pour un nom interne, interrogez les DNS hébergeant la zone et comparez les données répliquées. Pour Internet, comparez le résolveur interne et ses redirecteurs. En split DNS, des réponses différentes peuvent être intentionnelles.

NXDOMAIN signifie que le nom n’existe pas dans la vue consultée. SERVFAIL indique que le serveur n’a pas produit de réponse : examinez redirecteurs, DNSSEC, délégations et accès réseau. Un délai peut venir du serveur, du réseau ou du pare-feu.

6. Examiner le serveur sans le modifier

Le module DnsServer vient avec le rôle ou RSAT et exige des droits de lecture suffisants. Documentez zones et redirecteurs avant toute hypothèse.

Un redirecteur conditionnel peut manquer sur un seul DNS. Comparez serveurs maîtres, portée de réplication et joignabilité, sans modifier délais ou root hints durant la collecte.

Lecture seule — zones et redirecteurs

# Authorized Windows DNS server; read-only.
Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated
Get-DnsServerForwarder | Select-Object IPAddress, Timeout, UseRootHint
Get-DnsServerConditionalForwarderZone |
  Select-Object Name, MasterServers, ReplicationScope

Microsoft: DnsServer module ↗

7. Vérifier enregistrements, délégations et réplication

Comparez la même donnée sur chaque serveur faisant autorité : A/AAAA, CNAME, SRV, PTR, TTL et horodatage. Nettoyage automatique, mise à jour dynamique retardée ou enregistrements contradictoires peuvent rendre le résultat variable.

Pour une zone intégrée à AD, le symptôme DNS peut venir de la réplication AD. Utilisez les outils de santé existants; ne forcez pas une réplication globale comme premier geste.

Lecture seule — données et délégations

$Zone = 'example.internal'
Get-DnsServerResourceRecord -ZoneName $Zone -Name 'app' |
  Select-Object HostName, RecordType, Timestamp, TimeToLive, RecordData
Get-DnsServerZoneDelegation -Name $Zone

8. Capturer la panne avec une portée minimale

Les journaux DNS Server Audit et Analytical peuvent fournir client, question, réponse et code. Le journal analytique est masqué par défaut; son activation ajoute de la télémétrie. Pilotez, dimensionnez la rétention et revenez à l’état précédent après la collecte.

Pktmon est intégré aux versions Windows récentes. La capture ci-dessous est un changement temporaire et nécessite une console administrative. Elle peut contenir des noms sensibles; limitez durée, accès et conservation. Le filtre 53 ne voit pas nécessairement DNS over HTTPS.

Changement temporaire — capture filtrée

# CHANGE: elevated shell; brief incident window only.
pktmon filter remove
pktmon filter add DNS-UDP -p 53
pktmon start --capture --pkt-size 0 --file-name C:\Temp\dns.etl
# Reproduce briefly, then:
pktmon stop
pktmon etl2pcap C:\Temp\dns.etl --out C:\Temp\dns.pcapng

9. Interpréter sans sauter aux conclusions

Observation	Cause possible	Validation
Requête sans réponse	Perte, pare-feu, serveur	Comparer client/réseau/serveur
Réponses différentes	Données ou réplication	Interroger chaque autorité
UDP tronqué, TCP absent	TCP 53 bloqué	Tester selon la politique
SERVFAIL rapide	Redirecteur ou DNSSEC	Voir journaux serveur
NXDOMAIN variable	Split DNS ou cache négatif	Comparer vue, TTL, autorités
DNS correct, port échoue	Incident hors DNS	Tester réseau et service

10. Corriger par pilote et prévoir le retour arrière

Formulez la correction minimale : réparer un redirecteur précis, un enregistrement, une délégation ou la réplication. Exportez la configuration concernée et consignez la valeur précédente.

Pilotez sur un serveur ou une portée contrôlée. Validez noms internes et externes, SRV Active Directory, VPN et applications critiques pendant au moins le TTL concerné. Le retour arrière restaure la configuration documentée.

Évitez les actions larges : vidage massif des caches, réduction universelle des TTL, ajout d’un DNS public ou redémarrage simultané.

Checklist réutilisable

Une analyse d’infrastructure peut relier ces preuves aux dépendances Active Directory, aux sites réseau et aux applications critiques, sans remplacer un audit complet.

Heure, client, réseau, nom et type sont consignés.
Chaque DNS est interrogé directement et plusieurs fois.
Cache, split DNS, redirecteurs et autorités sont distingués.
Les données sont comparées entre serveurs.
La capture est courte, protégée et supprimée selon la politique.
Pilote, tests applicatifs et retour arrière sont documentés.

À propos de l’auteur

Marc-Antoine Lambert

Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.

Discuter de votre environnement →