Depuis un réseau d’entreprise Comcast, la résolution DNS interne renvoyait une mauvaise adresse IP (sinkhole) pour un site externe pourtant légitime. Voici une analyse terrain, le diagnostic reproductible et les correctifs durables côté Windows Server DNS et réseau.
Contexte et symptômes observés
Durant plusieurs jours, les utilisateurs constataient qu’un site externe de l’entreprise était injoignable depuis le réseau interne. Les points suivants ont rapidement émergé :
- Les contrôleurs de domaine (serveurs DNS internes) utilisaient des DNS Comcast comme forwarders.
nslookuplancé depuis l’interne retournait systématiquement une mauvaise IP (sinkhole), y compris lorsqu’un serveur DNS « neutre » ou « correct » était explicitement indiqué dans la commande.- Depuis un réseau externe (4G, domicile, autre FAI), la résolution donnait la bonne IP et l’accès fonctionnait.
- Hypothèses initiales : cache DNS à purger, problème chez l’ISP, ou filtrage DNS applicatif.
Comparatif des tests initiaux
| Scénario | Commande | Résultat | Lecture |
|---|---|---|---|
| Interne via DNS interne (forwarders Comcast) | nslookup www.exemple.com 10.0.0.10 | Renvoie IP de blocage/sinkhole | Réponse altérée par filtrage en amont |
| Interne en forçant un DNS public | nslookup www.exemple.com 1.1.1.1 | Renvoie toujours la mauvaise IP | Probable interception/forçage DNS réseau |
| Depuis un réseau externe (hors Comcast) | nslookup www.exemple.com 1.1.1.1 | Renvoie la bonne IP | Le domaine n’est pas en cause, l’ISP l’est |
Pourquoi « nslookup vers un serveur correct » renvoyait quand même la mauvaise IP ?
Sur certaines offres opérateur, dont Comcast Security Edge pour les entreprises, le trafic DNS (UDP/TCP 53) est redirigé à la volée vers les résolveurs filtrants de l’ISP. Cette politique de sécurité « edge » s’applique en amont de vos serveurs, parfois directement dans l’équipement opérateur (CPE) :
- Même si vous tapez
nslookup www.exemple.com 1.1.1.1, la requête DNS peut être proxyfiée et finalement résolue par le service filtrant de l’ISP. - Le résultat est une IP de sinkhole (ou une IP d’une page de blocage), au lieu de l’IP réelle de l’hôte.
- Du point de vue du poste, tout semble « normal » (réponse « Non-authoritative answer » avec une IP), mais l’IP n’est pas celle attendue.
Diagnostic reproductible pas à pas (runbook)
- Valider le FQDN (orthographe, dot final éventuel, sous-domaines). Test rapide :
nslookup www.exemple.com Resolve-DnsName www.exemple.com - Comparer interne vs externe avec des résolveurs publics :
nslookup www.exemple.com 1.1.1.1 nslookup www.exemple.com 8.8.8.8 # PowerShell Resolve-DnsName -Name [www.exemple.com](http://www.exemple.com) -Server 1.1.1.1 Resolve-DnsName -Name [www.exemple.com](http://www.exemple.com) -Server 8.8.8.8Si l’interne retourne une IP différente des mêmes tests réalisés depuis l’extérieur, suspectez un filtrage/écrasement de réponses. - Contrôler les forwarders sur Windows Server DNS :
# Inventaire Get-DnsServerForwarder # Supprimer temporairement un forwarder problématique Remove-DnsServerForwarder -IPAddress \ # (Option) Ajout de forwarders de confiance Add-DnsServerForwarder -IPAddress 1.1.1.1, 9.9.9.9 # Vérifier Root Hints Get-DnsServerRootHintAstuce : activez l’option « Utiliser les Root Hints si aucun serveur de transfert n’est disponible » dans la console DNS pour disposer d’un filet de sécurité en cas de panne/filtrage côté forwarders. - Purger les caches (poste et serveur) pour écarter un faux-positif lié au TTL :
# Poste Windows ipconfig /flushdns ipconfig /displaydns # Serveur DNS Windows dnscmd /clearcache # ou en PowerShell (exécuté sur le serveur DNS) Clear-DnsServerCache - Détecter un DNS forcé au niveau réseau :
- Wireshark sur le poste : filtre
udp.port == 53et vérifiez l’adresse IP de destination des requêtes. Si vous voyez partir les paquets vers une IP opérateur alors que vous ciblez un autre serveur, il y a interception. - Firewall/routeur : inspectez les règles NAT/ACL (« DNS redirect/inspect », « DNS proxy »). Certaines solutions renvoient tout port 53 vers un résolveur donné.
- Si vous disposez d’un hôte Linux, comparez :
dig @1.1.1.1 www.exemple.com +shortsur un réseau externe vs sur le réseau interne.
- Wireshark sur le poste : filtre
- Identifier une IP de sinkhole :
- La réponse A/AAAA renvoie une IP « contrôlée » par le service de sécurité (page de blocage, portail d’alerte).
- Des noms valides renvoient tous la même IP « universelle » au sein du réseau interne, quels que soient les domaines.
- Les réponses externes, elles, varient correctement selon le domaine et les TTL.
Cause racine confirmée
Comcast Security Edge bloquait le domaine et réécrivait la réponse DNS vers une IP de sinkhole, malgré une entrée supposée en liste autorisée. L’interception DNS opérateur expliquait pourquoi nslookup ciblant un résolveur « neutre » finissait tout de même avec la mauvaise IP : la requête était redirigée et résolue par le service filtrant.
Action corrective et résultat
- Purges des caches côté client (
ipconfig /flushdns) : aucun effet. - Intervention opérateur : désactivation de Security Edge sur le site impacté.
- Effet immédiat : la résolution DNS interne retrouve la bonne IP et l’accès au site est rétabli.
Recommandations pratiques et durables
Purger aussi le cache du serveur DNS
Ne vous limitez pas au poste utilisateur : les serveurs DNS Windows gardent leurs propres caches.
dnscmd /clearcache
# ou
Clear-DnsServerCache
Éviter les forwarders sous filtrage opérateur
- Si un ISP filtering est actif, ne forwardez pas vers ses résolveurs. Préférez les Root Hints ou des résolveurs publics conformes à vos politiques de sécurité.
- Documentez clairement qui résout quoi (forwarders primaires, secondaires, fallback Root Hints) et sous quels VLANs/segments.
Test A/B pour isoler le filtrage
# Comparaison directe
nslookup www.exemple.com <IP_DNS_interne>
nslookup www.exemple.com 1.1.1.1
# PowerShell pour détailler
Resolve-DnsName -Server \ -Name [www.exemple.com](http://www.exemple.com) -Type A
Resolve-DnsName -Server 1.1.1.1 -Name [www.exemple.com](http://www.exemple.com) -Type A Des divergences internes/externe pointent presque toujours une modification de réponse en amont.
Si Security Edge doit rester actif
- Demander une reclassification du domaine côté opérateur.
- Mettre en liste autorisée le FQDN exact, le domaine de second niveau et les sous-domaines concernés (
www,api,cdn, …), puis purger tous les caches. - Désactiver, si possible, la fonction de sinkholing ou de réécriture DNS pour les VLANs sensibles (infra, serveurs).
- Limiter la portée du filtrage (seulement les VLANs utilisateurs) et exclure les serveurs DNS internes.
Bonnes pratiques d’architecture DNS
- Split-horizon : assurez la cohérence des zones internes/externes pour éviter des chemins de résolution inattendus.
- Hiérarchie claire : postes → DNS internes (AD DS) → Root Hints/forwarders choisis. Évitez d’exposer directement les postes à des résolveurs externes quand un service de noms interne existe.
- Journalisation ciblée : activez les journaux Microsoft > Windows > DNS-Server (Analytical/Debug si nécessaire, temporairement) pour capturer les requêtes problématiques.
- Surveillance proactive : comparez périodiquement les réponses internes vs un panel de résolveurs publics ou un site d’observabilité interne.
Tableaux d’aide-mémoire
Commandes utiles (Windows)
| Objectif | Commande | Notes |
|---|---|---|
| Purger cache client | ipconfig /flushdns | Exécuter en admin, impacte seulement le poste |
| Visualiser cache client | ipconfig /displaydns | Vérifier le TTL restant |
| Purger cache serveur | dnscmd /clearcache ou Clear-DnsServerCache | Sur le serveur DNS Windows |
| Diagnostiquer une réponse | Resolve-DnsName <nom> -Server <IP> | Affiche CNAME/A/AAAA, TTL et détails |
| Lister les forwarders | Get-DnsServerForwarder | Vérifier la dépendance à l’ISP |
| Supprimer un forwarder | Remove-DnsServerForwarder -IPAddress <IP> | Retiré instantanément |
| Ajouter des forwarders | Add-DnsServerForwarder -IPAddress 1.1.1.1,9.9.9.9 | Respecter votre politique interne |
| Inspecter Root Hints | Get-DnsServerRootHint | Alternative aux forwarders |
Symptômes & interprétations rapides
| Symptôme | Probable cause | Action |
|---|---|---|
| IP identique (bloquante) pour des domaines différents en interne | Sinkhole/filtrage DNS opérateur | Vérifier Security Edge, interception DNS |
nslookup vers 1.1.1.1 rend la même mauvaise IP | DNS forcé/redirigé au niveau edge | Analyser via capture, firewall, CPE |
| Résolution correcte hors réseau Comcast | Problème spécifique à l’ISP | Escalade opérateur ou contournement |
Après flushdns client, toujours KO | Cache serveur ou réécriture amont | Purger serveur, vérifier forwarders |
Script PowerShell pour comparer plusieurs résolveurs
Ce petit script aide à comparer rapidement les réponses obtenues via votre DNS interne et quelques résolveurs externes. Il liste les IPs retournées et signale les divergences.
$Domain = "www.exemple.com"
$Servers = @("10.0.0.10","1.1.1.1","8.8.8.8")
\$resultats = foreach (\$s in \$Servers) {
try {
\$ans = Resolve-DnsName -Name \$Domain -Server \$s -Type A -ErrorAction Stop
\$ips = (\$ans | Where-Object {$\_.Type -eq "A"} | Select-Object -ExpandProperty IPAddress -Unique) -join ", "
\[PSCustomObject]@{ Serveur = \$s; IPs = \$ips; Etat = "OK" }
} catch {
\[PSCustomObject]@{ Serveur = \$s; IPs = ""; Etat = "ECHEC" }
}
}
\$resultats | Format-Table -Auto Lecture : si l’IP pour le serveur interne diffère des IPs renvoyées par les résolveurs publics et qu’un test externe confirme les IPs publiques, la piste « filtrage/rewriting opérateur » est fortement probable.
Checklist d’escalade opérateur (Comcast Security Edge)
- Fournir des horodatages et des captures d’écran/paquets montrant la divergence interne vs externe.
- Expliquer que la liste autorisée semble inefficace (ou non appliquée) et demander une revue de politique.
- Demander un bypass du filtrage pour les serveurs DNS internes et/ou la désactivation de la réécriture DNS (sinkhole) pour les VLANs d’administration.
- Demander une reclassification du domaine concerné, puis purger les caches côté opérateur si nécessaire.
Contournements temporaires (avec prudence)
- Root Hints uniquement sur les DNS internes pendant l’incident (si conforme à votre politique).
- Désactiver le forwarder vers l’ISP et basculer sur des résolveurs externes de confiance pour la durée du ticket.
- Exclure les serveurs DNS internes de l’interception DNS opérateur via des ACLs/règles sur le CPE.
- Éviter l’édition du fichier hosts au-delà d’un test ponctuel : cela masque le problème et peut créer des incohérences.
Post-mortem et prévention
- Documenter les dépendances DNS (forwarders, filtrage, interception) et les VLANs concernés.
- Mettre en place une surveillance automatisée : un job qui compare chaque heure la résolution interne d’une liste de FQDNs critiques avec un résolveur public et alerte en cas de divergence.
- Standardiser un plan de bascule (playbook) : suppression des forwarders ISP, repli Root Hints, purge de caches, vérification.
- Former les équipes : reconnaître les signatures d’un sinkhole (IP unique « bloquante », redirections, page d’interception).
FAQ
Pourquoi la purge du cache client n’a-t-elle rien changé ?
Parce que la réponse était réécrite en amont par le filtrage opérateur : même sans cache local, la requête arrivait au résolveur filtrant et recevait l’IP de sinkhole.
Pourquoi « nslookup <nom> 1.1.1.1 » ne permettait pas de contourner le problème ?
Le réseau forçait le trafic DNS vers le service de l’ISP (proxy/redirect port 53). Malgré la cible indiquée, la requête était interceptée et résolue ailleurs.
Faut-il bannir les forwarders vers l’ISP ?
Pas nécessairement, mais il est risqué de dépendre exclusivement d’un résolveur soumis à des politiques changeantes. Prévoyez des Root Hints en secours, voire des forwarders alternatifs conformes à vos exigences de sécurité.
Le split-horizon peut-il créer une « mauvaise IP » ?
Oui, si les zones internes/externes ne sont pas cohérentes. Toutefois, dans ce cas précis, la divergence interne/externe accompagnée d’une IP unique de blocage pointe plutôt un sinkhole opérateur qu’un problème de split-horizon.
Étude de cas — Résumé opérationnel
- Symptôme : le site externe est injoignable depuis l’interne, la résolution renvoie une IP erronée.
- Contexte : DNS internes en forwarders vers Comcast ;
nslookupinterne incohérent, externe OK. - Cause racine : Comcast Security Edge bloque et renvoie une IP de sinkhole malgré une liste autorisée.
- Correctif : désactivation de Security Edge par l’opérateur → rétablissement immédiat.
- Prévention : limiter l’usage des forwarders filtrés, surveiller les divergences, documenter et prévoir un repli Root Hints.
Annexe — Commandes de vérification rapide
# 1) Tester résolution interne puis publique
nslookup www.exemple.com 10.0.0.10
nslookup www.exemple.com 1.1.1.1
# 2) Inspecter les forwarders côté Windows Server DNS
Get-DnsServerForwarder
# 3) Purger les caches
ipconfig /flushdns
dnscmd /clearcache
Clear-DnsServerCache
# 4) Vérifier Root Hints
Get-DnsServerRootHint Conclusion
Ce cas illustre un piège fréquent : quand la résolution interne paraît « cassée », l’origine peut être à l’extérieur de votre AD/DNS. Les services de sécurité opérateur comme Comcast Security Edge peuvent intercepter et réécrire les réponses DNS, conduisant à une IP de sinkhole. La bonne approche : comparer méthodiquement interne/externe, vérifier les forwarders, purger les caches, détecter un DNS forcé au niveau edge et coordonner avec l’ISP. Une fois Security Edge désactivé ou ajusté, la résolution et l’accès ont été immédiatement rétablis.
Résultat : après désactivation de Comcast Security Edge, la résolution DNS et l’accès au site ont été rétablis depuis le réseau interne. Les contrôles préventifs (surveillance, documentation des dépendances, plan de bascule) minimisent désormais le risque de récurrence.