A resolução de nomes é a bússola da rede corporativa: quando ela aponta para o lugar errado, ninguém chega ao destino. Foi exatamente o que ocorreu quando um domínio público do próprio cliente começou a devolver, de dentro da rede, um endereço IP que não lhe pertencia. O problema parecia local, mas tinha raízes em um serviço de segurança do provedor. Neste artigo, mostramos como localizar a falha, corrigi‑la e blindar seu ambiente contra armadilhas semelhantes.
Contexto do problema
Durante anos, o departamento de TI manteve dois controladores de domínio Windows Server que funcionavam também como servidores DNS internos. Ambos encaminhavam consultas recursivas para os encaminhadores upstream padrão do provedor. Repentinamente, porém, o FQDN www.empresa‑exemplo.com passou a resolver dentro da rede para um endereço IP de “bloqueio” (uma sinkhole) — efeito clássico de filtros antimalware que interceptam consultas DNS e apontam domínios suspeitos para um null route. Fora do escritório, o mesmo FQDN resolvia corretamente para o IP legítimo hospedado em nuvem.
Entendendo o sintoma
| Ferramenta | Interface | IP retornado | Resultado esperado? |
|---|---|---|---|
nslookup padrão | Rede interna | 198.51.100.42 | Não |
nslookup apontando para 8.8.8.8 | Rede interna | 198.51.100.42 | Não |
dig @1.1.1.1 | Rede interna | 198.51.100.42 | Não |
dig @1.1.1.1 | Notebook em 4 G | 203.0.113.17 | Sim |
O dado crítico é que até mesmo consultas direcionadas a servidores públicos confiáveis (Google, Cloudflare) recebiam a mesma resposta incorreta — prova de que o tráfego era interceptado antes de sair da LAN.
Investigação detalhada
- Cache local? Executamos
ipconfig /flushdnsnos dois controladores, sem efeito. - Arquivos
HOSTSadulterados? Nenhuma entrada local apontava o domínio para o IP errado. - Manipulação no firewall/roteador? Registros de NAT mostravam que todas as portas UDP/TCP 53 eram encaminhadas intactas para fora.
- Filtro no provedor? Ao testar a mesma consulta via VPN residencial, o resultado foi correto. Assim, o ponto de falha estava entre a borda da empresa e o backbone do ISP corporativo.
Causa raiz: Comcast Business Security Edge
Entramos em contato com o suporte de segunda linha da Comcast e descobrimos que o serviço Comcast Business Security Edge estava ativado por padrão no circuito MPLS, mesmo após solicitada a remoção meses antes. O filtro usa DNS‑over‑HTTPS transparente para inspecionar cada consulta de saída; se identificar o domínio como suspeito, retorna um IP de bloqueio. Embora o domínio já constasse em uma lista de permissões enviada anteriormente, a política não havia sido sincronizada.
Como o Security Edge intercepta o DNS
O Security Edge não altera apenas tráfego iniciado na porta 53. Ele realiza inspeção de camada 7 e encaminha qualquer tentativa de resolução — inclusive DNS‑over‑HTTPS ou TLS — para servidores internos que substituem a resposta final. Isso explica por que apontar diretamente um resolver de confiança não surtiu efeito: o pedido nunca alcançou o destino.
Procedimento de correção passo a passo
- Registrar evidências — Coletar capturas de pacote (tcpdump ou Wireshark) que mostrem a resposta adulterada.
- Abrir ticket nível 2 — Solicitar desativação total do Security Edge, informando o CID do contrato e anexando as evidências.
- Confirmar alteração — Pedir ao técnico para reiniciar as CPEs gerenciadas e aplicar nova política.
- Limpar caches — Após a mudança, executar
ipconfig /flushdnsnos controladores de domínio e reiniciar o serviço DNS (dnscmd /clearcache). - Executar testes externos — Usar
dig +tracecontra@1.1.1.1e@8.8.8.8para assegurar que o caminho chega às raízes sem alteração.
Tentativas infrutíferas e lições aprendidas
ipconfig /flushdnsisoladamente: inútil quando a adulteração ocorre fora da máquina.- Trocar de resolver sem alterar a topologia: ineficaz se o provedor captura todas as portas e protocolos.
- Permitir domínio na lista branca do provedor: não confiável; a política nem sempre replica em tempo real.
A principal lição é que algum grau de interceptação pode permanecer invisível em redes gerenciadas. A suposição de que consultas DNS são “simples” UDP 53 já não vale em infraestruturas modernas.
Boas práticas para prevenir falhas de resolução
Depois de corrigido o incidente, implementamos um pacote de salvaguardas.
Avaliar políticas de filtragem do ISP
Exija documentação detalhada das camadas de segurança aplicadas pelo provedor e aponte explicitamente quais devem ficar ativas ou não.
Isolar recursão DNS
Configure forwarders no Windows Server DNS apenas para resolvers de alta confiança (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). No edge, bloqueie saída UDP/TCP 53 exceto dos controladores, evitando que estações contornem a política.
Monitorar e registrar
Habilite o Debug Logging do serviço DNS no Windows Server ou use ferramentas como dnstap em BIND/Unbound. Logs permitirão detectar anomalias de TTL, NXDOMAIN ou IPs divergentes.
Split‑horizon ou zone stub
Se o domínio corporativo é hospedado fora mas usado internamente, crie uma zona “split‑horizon” com registros A e CNAME apontando diretamente para o IP correto. Assim, a produção não depende da resolução pública.
Rotina de fallback
Mantenha script que rode dig @1.1.1.1 domínio, dig +trace e ping, gerando relatório automático. Caso divergências sejam detectadas, abra chamado ao provedor imediatamente e desvie o tráfego via túnel emergencial.
Checklist rápido de resolução
| Item | Verificação | Status |
|---|---|---|
| Caches de servidor limpos | dnscmd /clearcache | ☑ |
| Interceptação de ISP removida | Ticket #123456 fechado | ☑ |
| Forwarders atualizados | 1.1.1.1 / 9.9.9.9 | ☑ |
| Logs de resolução habilitados | Debug Log 1 GB | ☑ |
| Zona interna split‑horizon | www.empresa‑exemplo.com → 203.0.113.17 | ☑ |
Conclusão
Falhas de DNS são, muitas vezes, sintomas de mudanças fora da sua esfera de controle — como um serviço de segurança ativado unilateralmente pelo ISP. O caso descrito ilustra que, mesmo quando todo o ferramental local parece em ordem, o elo externo pode corromper os resultados. Documentar cadeias de resolução, limitar pontos de saída e registrar todas as consultas dá visibilidade indispensável para reagir rápido. Ao adotar boas práticas como encaminhadores confiáveis, split‑horizon e auditoria contínua, sua equipe reduz drasticamente a chance de paradas por “IP errado” e assume o comando da bússola que guia todo o tráfego corporativo.