Ataque NXDOMAIN en Cloud DNS: migración de zona

Tráfico Anómalo NXDOMAIN en Cloud DNS: Análisis, Migración y Lecciones Aprendidas

En marzo de 2026, una zona DNS pública en Cloud DNS experimentó tráfico anómalo: las consultas con respuestas NXDOMAIN aumentaron de 0,57 consultas/seg a 2720 consultas/seg. La carga total saltó a 2951 consultas/seg, lo que provocó un fuerte incremento en la facturación. El soporte no proporcionó un análisis técnico oportuno, forzando una migración urgente de la zona a un alojamiento externo.

Las métricas mostraron que NXDOMAIN dominaba sobre las consultas NOERROR. El tráfico se consideró ilegítimo debido a la ausencia de eventos empresariales, su repetibilidad y la falta de explicaciones del proveedor.

Detalles de la Anomalía

Línea base normal el 22 de marzo:

• A noerror: 9,38 consultas/seg
• A nxdomain: 0,57 consultas/seg
• Total: 9,96 consultas/seg

Anomalía el 25 de marzo:

• A nxdomain: 2720,29 consultas/seg
• A noerror: 231,14 consultas/seg
• Total: 2951,43 consultas/seg

La zona contenía registros estándar: A, CNAME, MX, TXT, NS y registros de servicio para DKIM, DMARC, ACME. La primera alerta ocurrió del 7 al 10 de marzo, con el incidente principal del 24 al 31 de marzo.

El tráfico se clasificó como anómalo según su perfil: predominancia de NXDOMAIN sin motivos legítimos, recurrencia del episodio y falta de respuesta del soporte.

Respuesta del Soporte e Impacto Financiero

Contactar al soporte no dio resultados: en lugar de analizar el tráfico, recibimos una respuesta genérica sobre esperar a colegas. Los costos aumentaron proporcionalmente a las consultas de nombres inexistentes.

Solución: presentar una reclamación en paralelo mientras se preparaba la migración. Elegimos un alojamiento DNS externo con importación de archivo de zona.

Pasos de Migración

• Exportar registros:

yc dns zone list-records example-zone --format json > zone-records.json

Estructura JSON:

{
  "record_sets": [
    {
      "name": "*.service.example-company.ru.",
      "type": "A",
      "ttl": "300",
      "data": [
        "203.0.113.10"
      ]
    },
    {
      "name": "_dmarc.example-company.ru.",
      "type": "TXT",
      "ttl": "300",
      "data": [
        "\"v=DMARC1; p=none; sp=none; rua=mailto:[email protected]\""
      ]
    }
  ]
}

• Convertir JSON a archivo de zona BIND:
• Usar @ para el origen
• Eliminar registros NS del proveedor anterior
• Desenvolver registros TXT múltiples
• Verificar registros CNAME, ACME, DMARC
• Excluir SOA

Ejemplo de archivo de zona:

$TTL 1d
example-company.ru. IN SOA ns1.provider.example. hostmaster.ns1.provider.example. (
        1
        14400
        3600
        604800
        10800
)

@       A       203.0.113.10
app     A       203.0.113.20
www     CNAME   infra.example-company.ru.

Recomendaciones de Monitoreo y Preparación

Para DevOps y SRE de nivel medio/senior:

• Monitorear métricas por códigos de respuesta: noerror, nxdomain, picos de carga.
• Preparar un script para exportar/conversión de zona.
• Revisar registros antes de migrar: NS, TXT (ACME/DKIM), IP privadas.

Tickets separados: análisis técnico por separado de reclamaciones financieras.

En caso de anomalía sin respuesta—activar plan B: exportar, migrar, registrar todo.

Conclusiones Clave

• Monitorear NXDOMAIN evita sorpresas en facturación.
• Exportar mediante yc dns zone list-records --format json es un paso clave de migración.
• Excluir registros NS del proveedor del archivo de zona para evitar conflictos.
• Revisar registros TXT/ACME: eliminar los obsoletos.
• Tickets paralelos aceleran la resolución.

— Editorial Team