DNS interno risolve IP errato a causa di Comcast SecurityEdge: diagnosi completa, fix e best practice

Dal marzo 2024, in una rete Active Directory, le query DNS interne verso il dominio pubblico aziendale hanno iniziato a restituire un IP esterno errato. La causa: un filtro di rete lato ISP che riscriveva le risposte. Ecco diagnosi, fix e procedure per prevenire recidive.

Indice

Contesto e sintomi

Scenario tipico: workstation e server membri del dominio utilizzano i controller di dominio (DC) con ruolo DNS come resolver primari. A inizio marzo 2024 si osserva che:

dall’interno della LAN, il dominio pubblico dell’azienda viene risolto con un indirizzo IP esterno sbagliato;
da reti esterne (rete domestica, rete mobile, VPN disconnessa) la risoluzione è corretta;
forzare un server diverso con nslookup o svuotare la cache locale con ipconfig /flushdns sui DC non cambia l’esito;
il problema è coerente su più client e persistente nel tempo.

Architettura di riferimento

Il flusso di risoluzione in molte aziende è così strutturato:

Client AD → domanda DNS ai DC/DNS interni;
se il record non è autorevole internamente, i DC inoltrano verso i forwarder configurati (resolver esterni dell’ISP o pubblici);
il forwarder contatta i server autorevoli del dominio pubblico e restituisce l’IP;
il DC inoltra la risposta al client, applicando eventuali cache.

Nel caso reale, i DC inoltravano alle resolving farm di Comcast. Su tali resolver era attivo SecurityEdge, un servizio di filtraggio che può riscrivere le risposte DNS (tipicamente verso IP “sinkhole” o pagine di blocco) per domini giudicati rischiosi o soggetti a policy.

Problema osservato

Dal marzo 2024 i DC/DNS hanno iniziato a inoltrare sistematicamente a resolver Comcast con filtraggio attivo.
Il dominio pubblico aziendale risultava filtrato e riscritto, nonostante fosse stato inserito in whitelist.
Di conseguenza, solo dall’interno si otteneva un IP esterno sbagliato; all’esterno la risoluzione restituiva l’IP corretto.

Diagnosi tecnica: come è stata individuata la causa

La diagnosi ha seguito un percorso in più tappe, replicabile come runbook operativo.

Verifica dell’origine dell’errore

Test diretti dal client:
nslookup -type=A www.dominio-azienda.tld nslookup -type=A www.dominio-azienda.tld <IPDCINTERNO> nslookup -type=A www.dominio-azienda.tld 1.1.1.1 nslookup -type=A www.dominio-azienda.tld 8.8.8.8 Risultato tipico: IP errato quando si interroga il DC interno; IP corretto quando si interroga un resolver esterno non filtrato.
Test dal DC/DNS:
nslookup -type=A www.dominio-azienda.tld nslookup -type=A www.dominio-azienda.tld <IPFORWARDERISP> Resolve-DnsName www.dominio-azienda.tld -Server <IPFORWARDERISP> -Type A -DnsOnly -NoHostsFile Se il forwarder ISP risponde con un IP alterato, il DC propagherà quell’alterazione ai client.
Ispezione della catena di forwarder (sui DC Windows Server):
Get-DnsServerForwarder Get-DnsServerConditionalForwarderZone Get-DnsServerQueryResolutionPolicy Questo individua i resolver a cui il DC inoltra (forwarder globali, condizionali, o policy-based).
Analisi cache e TTL:
ipconfig /displaydns Clear-DnsServerCache # svuota la cache del servizio DNS sul DC ipconfig /flushdns # svuota la cache del resolver client Importante: ipconfig /flushdns agisce sulla cache del client. Per il servizio DNS del DC serve Clear-DnsServerCache. In ogni caso, se l’upstream riscrive, lo svuotamento non risolve in modo permanente.
Conferma del comportamento di riscrittura: abilitare debug in nslookup (set debug) o usare dig +trace da una macchina di test per osservare autoritativi e passaggi intermedi. La presenza di un IP “sinkhole” coerente con le policy dell’ISP conferma la manipolazione a monte.

Conclusione diagnostica

La causa radice è stata ricondotta a Comcast SecurityEdge che, pur con il dominio in whitelist, filtrava e riscriveva la risposta A/AAAA verso un IP alterato. Il comportamento si è verificato solo quando il percorso di risoluzione transitava dai forwarder Comcast; all’esterno, usando resolver diversi, la risposta era corretta.

Soluzioni testate e risultato

Passaggio	Esito
`ipconfig /flushdns` sui due controller/DNS	Nessun effetto
Contatto con il supporto Comcast e richiesta di disattivare completamente SecurityEdge	Problema risolto: il dominio torna a risolversi correttamente dall’interno

Perché lo svuotamento cache non ha aiutato

Cache client (ipconfig): non incide quando la risposta “sbagliata” arriva ogni volta dal resolver upstream.
Cache del servizio DNS (Clear-DnsServerCache): può rimuovere la risposta alterata, ma verrà subito riempita con la stessa risposta riscritta dal forwarder filtrante.
Browser / runtime: anche se si svuota la cache del sistema, applicazioni e browser possono avere cache proprie; non è la radice del problema.

Raccomandazioni operative

Controllo dei forwarder DNS

Audit periodico: inventaria i forwarder su tutti i DC/DNS (Get-DnsServerForwarder) e verifica che non puntino a resolver che applicano filtri o rewriting non desiderati.
Preferisci risoluzione autorevole o recursion locale: quando possibile, usa root hints o resolver interni non filtrati; riduci la dipendenza da resolver di ISP con policy mutabili.
Conditional forwarder per domini critici: instrada i domini aziendali pubblici direttamente verso i loro nameserver autorevoli (o verso resolver di fiducia) bypassando i filtri dell’ISP.
Add-DnsServerConditionalForwarderZone -Name "dominio-azienda.tld" -MasterServers 203.0.113.10,203.0.113.11 -ReplicationScope Forest

Gestione di SecurityEdge (se lo si vuole mantenere attivo)

Whitelisting effettivo: verifica che la whitelist copra dominio e sottodomini, e che non esistano policy di categoria o override globali che abbiano priorità (malware, phishing, newly-registered domains, ecc.).
Eccezioni mirate: valuta eccezioni solo per il traffico DNS aziendale (ad es. sorgenti: IP dei DC/DNS) anziché disattivare l’intero servizio.
Propagazione delle regole: dopo modifiche alle policy, pianifica un tempo di verifica tenendo conto di TTL e di eventuali cache nei resolver dell’ISP.

Monitoraggio continuo

Alert su record critici: monitora A/AAAA/CNAME/MX/TXT critici e genera alert se l’IP o il target cambia rispetto a un baseline atteso.
Confronto multi‑vantage: verifica i record da più punti (DC, un host esterno di test, resolver pubblici affidabili) per cogliere differenze dovute a filtri o georouting.
Log e telemetria: abilita log DNS sul DC per avere traccia delle query e delle risposte ricevute dai forwarder.

Procedure di fallback

Resolver alternativi pronti: mantieni una lista testata di resolver di backup o l’elenco degli autoritativi per i domini vitali per poterli impostare rapidamente.
Piano di rollback: documenta i comandi per sostituire i forwarder, applicare conditional forwarder o passare temporaneamente a root hints.

Runbook: verifica rapida in 10 minuti

Conferma del sintomo: nslookup www.dominio-azienda.tld <IP_DC> e annota l’IP ottenuto.
Confronto esterno: nslookup www.dominio-azienda.tld 1.1.1.1 e nslookup ... 8.8.8.8; se differisce, sospetta filtraggio.
Leggi i forwarder sul DC: Get-DnsServerForwarder.
Interroga direttamente il forwarder: Resolve-DnsName ... -Server <IPFORWARDERISP> per vedere se l’alterazione avviene lì.
Bypass temporaneo: imposta un conditional forwarder per il dominio verso i suoi autoritativi e riesegui i test.
Stabilizzazione: se confermata la causa, disabilita o escludi il traffico DNS dei DC da SecurityEdge; quindi ripristina la catena desiderata.

Script di monitoraggio (PowerShell) per record pubblici

Questo script controlla periodicamente che un set di record pubblici corrisponda ai valori attesi da più resolver; in caso di mismatch, esce con codice > 0 e scrive un log. Puoi schedularlo in Task Scheduler.

# Parametri
$Targets = @(
  @{ Name = "www.dominio-azienda.tld"; Type = "A"; Expected = @("198.51.100.20") },
  @{ Name = "api.dominio-azienda.tld"; Type = "A"; Expected = @("198.51.100.30") }
)
$Resolvers = @("127.0.0.1","<IPDC1>","<IPDC2>","1.1.1.1","8.8.8.8")
$LogFile = "C:\Logs\DnsHealth-$(Get-Date -Format yyyyMMdd).log"
$Errors = 0

foreach ($t in $Targets) {
foreach ($r in $Resolvers) {
try {
$res = Resolve-DnsName -Name $t.Name -Type $t.Type -Server $r -DnsOnly -ErrorAction Stop |
Where-Object { $*.Type -eq $t.Type } | Select-Object -ExpandProperty IPAddress
$diff1 = Compare-Object -ReferenceObject $t.Expected -DifferenceObject $res
$diff2 = Compare-Object -ReferenceObject $res -DifferenceObject $t.Expected
if ($diff1 -or $diff2) {
$msg = "[ALERT] $($t.Name) @$r atteso=[$($t.Expected -join ',')] ottenuto=[$($res -join ',')]"
$Errors++
} else {
$msg = "[OK] $($t.Name) @$r = $($res -join ',')"
}
$msg | Tee-Object -FilePath $LogFile -Append
} catch {
$err = "[ERR] $($t.Name) @$r - $($*.Exception.Message)"
$Errors++; $err | Tee-Object -FilePath $LogFile -Append
}
}
}
exit $Errors

Verifiche avanzate e trappole comuni

Split‑horizon o “split‑brain” DNS: se esiste una zona interna con lo stesso nome della zona pubblica, accertati che i record interni non stiano “oscurando” quelli esterni per determinati host.
Politiche DNS del DC: controlla eventuali Query Resolution Policy che applichino riscritture o routing a forwarder diversi per classi di client.
IPv6: se i client preferiscono AAAA, verifica che i forwarder non facciano rewrite su AAAA mentre A rimane corretto; testa entrambi i tipi.
Cache applicative: alcuni runtime (Java, .NET, Node.js) hanno proprie logiche di cache DNS; dopo il fix a livello di infrastruttura, riavvia servizi sensibili.
DNSSEC: un resolver che riscrive le risposte può invalidare la validazione DNSSEC. Se la tua infrastruttura valida le firme, verifica RRSIG/AD bit.

Piano di hardening consigliato

Standardizza i forwarder: usa resolver interni senza filtri indesiderati o root hints; documenta gli indirizzi e fai version control della configurazione.
Conditional forwarder per domini aziendali: evita di dipendere da terzi per i record pubblici mission‑critical.
Backup della configurazione DNS: esporta periodicamente le zone e le impostazioni dei DC (Export-DnsServerZone, Get-DnsServerForwarder → file).
Alerting: implementa lo script di monitoraggio e integra con il tuo sistema di notifiche (mail, webhook, SIEM).
Runbook e comunicazione: prepara un runbook per l’help desk con “test rapidi” e canale di escalation verso il team di rete o il provider.

Procedura di ripristino esemplificata

Se il problema si ripresenta e non puoi attendere il supporto del provider:

Applica un conditional forwarder verso i nameserver autorevoli del dominio pubblico aziendale.
Rimuovi temporaneamente i forwarder dell’ISP o spostali in coda, lasciando i DC in recursion con root hints.
Verifica con Resolve-DnsName da DC e client. Controlla TTL e coerenza su A/AAAA/CNAME.
Comunica internamente l’intervento e monitora i servizi dipendenti (web, API, SSO, posta).

Comandi utili (cheat‑sheet)

Obiettivo	Comando
Elenca forwarder	`Get-DnsServerForwarder`
Aggiungi forwarder	`Set-DnsServerForwarder -IPAddress 9.9.9.9,1.1.1.1`
Conditional forwarder	`Add-DnsServerConditionalForwarderZone -Name "dominio-azienda.tld" -MasterServers X.X.X.X`
Svuota cache servizio DNS	`Clear-DnsServerCache -ComputerName <DC>`
Test da resolver specifico	`Resolve-DnsName www.dominio-azienda.tld -Server <IP> -Type A`
nslookup verbose	`nslookup -type=A www.dominio-azienda.tld <IP_RESOLVER> & set debug`

Checklist di controllo qualità post‑fix

Record A/AAAA/CNAME del dominio pubblico corrispondono ai valori attesi da: DC interni, resolver pubblici, vantage esterno.
TTL e autoritativi coerenti con la configurazione della zona pubblica.
Monitor DNS attivo, alert generati in caso di cambiamento.
Documentazione aggiornata (forwarder, conditional, motivazione del change).

Lezione appresa

La catena di risoluzione contiene più punti in cui una risposta può essere alterata: cache locali, policy dei DC, forwarder e servizi di filtraggio dell’ISP. In questo incidente, l’alterazione è upstream (SecurityEdge) e dunque tutti i tentativi di “pulizia” locale non potevano produrre un risultato persistente. La disattivazione di Comcast SecurityEdge o, in alternativa, l’esclusione mirata del traffico DNS dei DC dal filtro, ha ristabilito la risoluzione corretta.

Conclusione

Il caso ha mostrato come un servizio di sicurezza a monte possa introdurre inconsistenze DNS interne difficili da diagnosticare. La soluzione è stata chiara: rimuovere o bypassare il punto di riscrittura (SecurityEdge) e indurire la configurazione DNS con forwarder affidabili e monitoraggio continuo. Così facendo, il dominio pubblico dell’azienda ha ricominciato a risolversi correttamente dall’interno senza ulteriori disservizi. Resta comunque fortemente consigliato mantenere un programma di monitoraggio e una revisione periodica delle policy DNS per prevenire recidive.

Riepilogo pratico

Sintomo: solo dall’interno il dominio pubblico risolve su un IP sbagliato.
Radice: riscrittura upstream del DNS (Comcast SecurityEdge) nonostante whitelist.
Fix: disattivazione/escussione SecurityEdge per i DC o conditional forwarder diretto agli autoritativi.
Prevenzione: audit periodico dei forwarder, monitor dei record critici, runbook di fallback.

Appendice – Modello di policy e baseline DNS

Per aziende con requisiti di governance, mantenere un file di baseline dei record pubblici critici aiuta ad automatizzare i controlli. Esempio JSON (archiviazione in repository):

{
  "records": [
    { "name": "www.dominio-azienda.tld", "type": "A", "expected": ["198.51.100.20"], "ttlMin": 300 },
    { "name": "api.dominio-azienda.tld", "type": "A", "expected": ["198.51.100.30"], "ttlMin": 300 },
    { "name": "login.dominio-azienda.tld", "type": "CNAME", "expected": ["idp.vendor.com."], "ttlMin": 300 }
  ],
  "authoritatives": ["ns1.provider.tld","ns2.provider.tld"],
  "contact": "netops@dominio-azienda.tld"
}

Il file funge da sorgente di verità; gli script lo leggono e confrontano il “visto” con l’“atteso”.

Domande frequenti

Perché dall’esterno tutto era corretto?
Perché le reti esterne usavano resolver diversi (non soggetti a SecurityEdge), ottenendo la risposta autorevole senza riscritture.

Basta cambiare i forwarder?
Spesso sì: puntare a resolver non filtrati o direttamente agli autoritativi risolve. Tuttavia, verifica impatti su logging, compliance e latenza.

Meglio root hints o forwarder?
Root hints aumentano autonomia e riducono dipendenza da terzi; forwarder affidabili possono offrire caching migliore. In ambienti regolati, scegli in base a policy e visibilità necessarie.

La whitelist perché non ha funzionato?
Possibili motivi: priorità di altre policy, whitelist non estesa ai sottodomini, tempi di propagazione, liste “globali” che prevalgono. Serve escalation al provider per chiarire l’ordine di valutazione delle regole.

Con la disattivazione di Comcast SecurityEdge il problema è stato definitivamente risolto; resta consigliabile un piano di monitoraggio e una revisione periodica delle policy DNS per prevenire recidive.