Cuando un sitio web propio deja de resolver correctamente dentro de la red corporativa el golpe a la productividad es inmediato. En este caso de estudio aprenderás cómo aislar el origen de respuestas DNS erróneas que devolvían una dirección IP pública equivocada, aun cuando la infraestructura interna estaba aparentemente sana. Verás los pasos de diagnóstico, la intervención con el ISP y las buenas prácticas que evitarán que el problema se repita.

Contexto de la incidencia

La organización, con dos controladores de dominio Windows Server que también ejercen como servidores DNS internos, detectó que su dominio público midominio.com resolvía a una dirección IP externa que no les pertenecía. Este fallo:

• Afectaba exclusivamente a los equipos conectados a la LAN.
• No se reproducía al realizar la misma consulta desde redes externas (4G, hogares de empleados o VPNs de pruebas).
• Persistía incluso forzando la consulta a los servidores DNS autoritativos correctos desde nslookup.

Síntomas clave observados

Con el objetivo de caracterizar la anomalía se recopilaron las siguientes evidencias:

Prueba	Resultado	Conclusión preliminar
nslookup midominio.com (sin parámetros)	IP incorrecta (198.51.100.10)	El resolver empleado por el cliente no es fiable
nslookup midominio.com 10.0.0.2 (DC1)	IP incorrecta	El servidor DNS interno entrega datos contaminados
nslookup midominio.com 8.8.8.8	IP correcta (203.0.113.25)	La zona pública está configurada bien en Internet
Equipo externo (LTE)	IP correcta	El problema es exclusivo de la red corporativa

Análisis de primer nivel

Lo lógico era asumir un problema de caché, pues la mayoría de fallos de resolución recursiva se deben a registros caducados o envenenados localmente. Sin embargo, ejecutar ipconfig /flushdns en varios equipos y en los servidores DNS no cambió el resultado. La incógnita pasaba a una capa superior: ¿quién manipulaba las consultas salientes?

Descartando la caché y otros errores locales

Para evitar falsas pistas se siguió esta lista de verificación:

1. Reiniciar el servicio DNS (net stop dns && net start dns) en DC1 y DC2.
2. Confirmar que no existían zonas secundarias o registros hosts en conflictos.
3. Verificar que los reenviadores configurados (forwarders) apuntaban a los servidores de Comcast (75.75.75.75 y 75.75.76.76), sin direcciones obsoletas.
4. Ejecutar dnscmd /clearcache para eliminar cualquier rastro en la base de datos del servicio.

Tras cada acción se repetía la consulta con el mismo resultado erróneo. Quedaba claro que la fuente de la mala respuesta estaba fuera de la zona de control directa del equipo de TI.

Profundizando en el tráfico DNS

Con Wireshark se capturó tráfico en DC1 mientras se lanzaba nslookup midominio.com. El flujo fue revelador:

Client → DC1      Consulta A midominio.com
DC1    → 75.75.75.75 Consulta recursiva
75.75.75.75 → DC1    Respuesta A 198.51.100.10 (Incorrecta)

Los paquetes regresaban desde la IP del resolver de Comcast con la dirección indebida, es decir, la información se corrompía en la infraestructura del ISP. Curiosamente, el mismo servidor de Comcast desde una red externa no devolvía la IP incorrecta, por lo que el problema debía residir en un servicio de filtrado asociado exclusivamente al contrato empresarial.

Comcast Security Edge: la pieza que faltaba

Comcast incluye en muchos circuitos dedicados su plataforma Security Edge, la cual inspecciona el tráfico DNS y aplica reglas de filtrado basadas en reputación de dominios. Al entrar en el portal de administración se detectó que midominio.com aparecía marcado como “Malware/C&C”. Esa categorización provocaba que, en lugar de responder con la IP legítima, Security Edge entregara una IP de cobertura que redirigía a un portal de advertencia.

Aunque el dominio se hallaba en la allow‑list corporativa, un policy refresh automático la noche anterior había reinstaurado la regla de bloqueo por considerarse de “alto riesgo” tras un falso positivo de una lista de inteligencia. El equipo de seguridad no recibió alerta alguna porque el evento se clasificó como “informativo”.

Solución paso a paso

1. Apertura de ticket con Comcast Business Support, indicando número de circuito, dominio afectado y capturas de Wireshark.
2. Verificación por parte del NOC de Comcast, confirmando que Security Edge interceptaba la petición y devolvía la IP 198.51.100.10.
3. Desactivación temporal completa de Security Edge para el rango de IP corporativo.
4. Pruebas en vivo: a los 30 segundos los servidores DNS internos comenzaron a recibir la respuesta correcta (203.0.113.25).
5. Cierre del incidente tras 24 horas de monitoreo sin recurrencia.

Validación posterior a la corrección

Para garantizar que la solución era definitiva se implementaron las siguientes verificaciones automáticas:

• Script PowerShell que ejecuta cada 5 minutos Resolve-DnsName a los registros A y AAAA críticos y envía alerta si la respuesta no coincide con el patrón esperado.
• Dashboard en Grafana que consume los logs de dnsdebug de Windows y dibuja la tendencia de dominios bloqueados.
• Check de uptime externo (Pingdom) apuntando a la URL pública, asegurando que el tráfico de Internet siempre resuelve a la IP legítima.

Recomendaciones para prevenir futuros incidentes

Auditoría continua de políticas DNS

Documenta la lista de forwarders válidos y revisa trimestralmente que ningún equipo apunte fuera del rango permitido. Habilita registro de auditoría en el visor de eventos (Microsoft‑Windows‑DNS‑Server/Analytical) para capturar cambios de configuración.

Mantenimiento de listas de reputación

Si decides volver a activar Security Edge:

• Actualiza la allow‑list antes de cada policy refresh.
• Solicita a Comcast que tu dominio quede en la lista “Customer–Owned Safe Domains” que se replica con prioridad sobre los feeds de terceros.
• Habilita notificaciones en tiempo real para “reclasificaciones automáticas”.

Estrategia de caché inteligente

Configura TTL razonables (10 – 15 min) para registros esenciales. Un TTL muy alto prolonga los daños de un envenenamiento; uno demasiado bajo aumenta la dependencia de los resolvers externos.

Separación de roles y redundancia

Tener al menos dos forwarders —uno del ISP y otro público (por ejemplo, Google DNS)— permite comparar respuestas y detectar rápidamente divergencias. Herramientas como dnsdist pueden balancear y validar las respuestas antes de entregarlas al cliente.

Preguntas frecuentes (FAQ)

¿Por qué ipconfig /flushdns no solucionó nada?

Porque la respuesta incorrecta nunca estuvo en la caché del sistema operativo; surgía antes, en el resolver del ISP. Limpiar la caché local solo influye en la última milla.

¿Qué diferencia hay entre un envenenamiento DNS y una respuesta alterada por el ISP?

En un cache poisoning clásico el atacante hace pasar datos fraudulentos al servidor DNS. Aquí el propio proveedor reemplazaba intencionadamente la respuesta como parte de su política de filtrado; no existió compromiso de seguridad interno.

¿Es mejor desactivar para siempre el filtrado de Comcast?

Depende del perfil de riesgo. Si la empresa dispone de un stack de seguridad robusto (firewall de nueva generación, EDR, proxy SSL, filtrado de correo avanzado), Security Edge puede resultar redundante y generar falsos positivos. Para PYMES sin otros controles, mantenerlo activo —bien configurado— aporta una capa extra.

Conclusión

Un fallo de resolución DNS puede parecer un misterio interno, pero a veces la causa está más allá del perímetro. En este caso, Comcast Security Edge bloqueaba y redirigía el dominio corporativo sin que la caché local ni la zona autoritativa tuvieran culpa. La clave fue:

• Capturar tráfico para ver dónde cambiaba la respuesta.
• Escalar con datos objetivos al proveedor.
• Aplicar vigilancia proactiva post‑incidente.

Con estos pasos tu equipo podrá diagnosticar y resolver incidentes similares, reduciendo el tiempo de inactividad y blindando la reputación interna del servicio de TI.

Anexo 1 – script de comprobación periódica

# Requires : PowerShell 5+
$registro = "midominio.com"
$ipEsperada = "203.0.113.25"
while ($true) {
  $resultado = (Resolve-DnsName $registro -Server 127.0.0.1 -Type A -ErrorAction SilentlyContinue).IPAddress
  if ($resultado -ne $ipEsperada) {
    Send-MailMessage -To "noc@midominio.com" -Subject "Alerta DNS" `
                     -Body "Respuesta inesperada: $resultado" -SmtpServer "smtp.midominio.com"
  }
  Start-Sleep -Seconds 300
}

Anexo 2 – plantilla de ticket para ISP

Utiliza esta estructura para acelerar la respuesta de tu proveedor:

• Asunto : Security Edge bloquea dominio propio – IP incorrecta en resolución interna
• Cuenta / Circuito : 123456‑ACME‑Corp
• Descripción del impacto : imposibilidad de acceso a midominio.com desde LAN (300 usuarios), servicios críticos afectados (correo, CRM).
• Pruebas adjuntas : pcap de Wireshark, capturas de nslookup, registro de evento 7031 de DNS.
• Acción solicitada : Desactivar Security Edge o añadir midominio.com a lista segura con prioridad 1.

Anexo 3 – lista mínima de KPIs DNS

KPI	Objetivo	Frecuencia de medición
Tiempo medio de resolución interna	< 30 ms	Diaria
Porcentaje de fallos NXDOMAIN	< 1 %	Diaria
Divergencia entre forwarders	0 %	Semanal
Alertas de reputación de dominio	0 por mes	Mensual

Implementar y vigilar estos indicadores convierte la gestión DNS en un proceso predictivo y no reactivo, minimizando sorpresas desagradables.

Anexo 4 – cómo opera Security Edge

Security Edge intercepta todas las consultas DNS que se originan en la red del cliente mediante anycast hacia sus resolvers 75.75.75.75/76.76. Cada petición se coteja contra bases de datos de amenazas que se sincronizan en ciclos de 15 minutos. Si un dominio se clasifica como riesgoso, la plataforma devuelve una respuesta “sinkhole” que apunta a un servidor web de advertencia. A nivel técnico el paquete de respuesta sigue siendo legítimo, con su bit AA – Authoritative Answer a 0 para indicar que la respuesta no es autoritativa, pero la mayoría de clientes lo aceptan sin cuestionar.

En nuestro caso, la IP 198.51.100.10 era el sinkhole de la costa este. Otros clientes podrían ver 203.0.113.10 según la región. Este matiz es importante porque dos usuarios en diferentes sedes pueden obtener IPs distintas y confundir el diagnóstico si no se analizan pcaps en paralelo.

Anexo 5 – comparativa con otros filtros DNS

Servicio	Modelo de despliegue	Ventajas	Inconvenientes
Comcast Security Edge	Transparente, incluido en circuito	Sin costes extra, integración con portal Business	Control limitado por el cliente, falsos positivos difíciles de gestionar
Cisco Umbrella	API y agentes en endpoint	Gran visibilidad, panel granular por políticas	Coste de licencia, curva de aprendizaje
Cloudflare Gateway	Túnel DNS sobre HTTPS	Latencia baja, actualización de reglas en segundos	Necesario romper SSL para inspección profunda

Entender estas diferencias ayuda a seleccionar la mejor capa de defensa acorde a presupuesto y criticidad del negocio.