Más allá del contrato inteligente: seguridad operativa de dominios y DNS en Web3

1. El punto de entrada fuera de la cadena: donde comienza la seguridad operativa web3

El límite de seguridad de un proyecto web3 se ha extendido, desde hace tiempo, más allá de sus contratos inteligentes. Claves de servidor filtradas, frontends manipulados, resolución de DNS secuestrada: todo esto ocurre fuera del contrato, pero cambia directamente qué página carga un usuario y qué transacción firma ese usuario. Desde el punto de vista del usuario, apenas importa si el ataque ocurrió en la cadena o fuera de ella. Lo que importa es si fue dirigido al punto de entrada incorrecto.

Las auditorías de contratos son relativamente maduras. La seguridad operativa fuera de la cadena no lo es: durante mucho tiempo ha carecido de un marco compartido que los equipos de proyecto puedan aplicar de forma continua y que un tercero pueda verificar. SEAL Certifications [1], el marco abierto de certificación de seguridad operativa publicado por Security Alliance, se construye precisamente en torno a esa brecha. Divide la seguridad operativa en seis módulos: operaciones multisig, operaciones de tesorería, respuesta a incidentes, DevOps e infraestructura, DNS y registrador, y gestión de identidad y cuentas.

Este artículo sigue ese hilo hacia uno de los seis: DNS y registrador. Se sitúa en la parte más frontal del camino que recorren los usuarios para llegar a un proyecto, lo que lo convierte en la forma más directa que tiene un atacante de eludir las defensas a nivel de contrato. No intentamos realizar una evaluación exhaustiva de la seguridad operativa. Adoptamos un punto de vista externo y planteamos una pregunta más acotada: ¿qué tan bien configurados están los puntos de entrada públicos que los principales proyectos ponen frente a sus usuarios?

Para responderla, desarrollamos el BlockSec DNS Security Scanner (BDSS) basado en el módulo de DNS y registrador de SEAL [2], y luego lo ejecutamos contra 100 dominios únicos pertenecientes al Top 100 de TVL de DefiLlama, con ocho verificaciones estandarizadas cada uno, 800 verificaciones en total. Tras la confirmación manual, las brechas de referencia resultaron ser tanto generalizadas como concentradas en un puñado de controles: solo el 1 % de la muestra superó todas las verificaciones, y más de nueve de cada diez dominios generaron al menos una señal de riesgo en el punto de entrada. El 72 % no tenía registro CAA y el 47 % presentó defectos de validación DNSSEC, y la autenticación de correo electrónico y el bloqueo de dominio también mostraron carencias claras.

2. DNS y registrador: el límite de seguridad frente al usuario

El DNS convierte un dominio legible por humanos en una dirección de servicio accesible. Es el punto de entrada fuera de la cadena a través del cual los usuarios llegan al sitio web de un proyecto, su frontend de trading, su documentación, sus API de negocio y su correo electrónico oficial. Una vez comprometida la ruta de resolución o el control del dominio, un usuario puede ser dirigido a una página falsificada sin notarlo, y cada conexión de wallet, firma y transacción que le sigue pierde su fundamento. Por lo tanto, el DNS y el registrador no deben tratarse como una configuración de infraestructura ordinaria; pertenecen dentro del límite de seguridad operativa del proyecto.

Los incidentes públicos ya han hecho que este riesgo sea concreto. Curve Finance sufrió un secuestro de DNS en 2022 y de nuevo en 2025 [3][4]. En octubre de 2023, un atacante de ingeniería social tomó control de la cuenta de registrador de Galxe y redirigió a los visitantes hacia un frontend malicioso; el proyecto reveló que se vieron afectados aproximadamente 1120 usuarios [5]. En 2025, el dominio principal de Aerodrome Finance sufrió un ataque de frontend [6]. En abril de 2026, un atacante obtuvo el control del dominio de CoW Swap y dirigió a los usuarios a una página de phishing, con pérdidas estimadas en alrededor de 1,2 millones de dólares [7]. El anterior secuestro de rutas BGP de cBridge deja claro un punto adicional: los usuarios no siempre pueden confiar en que una advertencia del navegador les indique que el punto de entrada ha fallado [8]. En cada uno de estos casos, el contrato en cadena no necesariamente estaba comprometido, y sin embargo los fondos de los usuarios seguían en riesgo porque se había perdido la ruta de acceso.

Las causas difieren, pero se reducen a cuatro rutas de ataque que afectan directamente el punto de entrada del usuario. Primero, un atacante altera los registros DNS o la ruta de resolución y dirige a los visitantes hacia un frontend malicioso. Segundo, se eluden o se configuran mal los controles de emisión de certificados, lo que permite que un sitio falsificado obtenga un certificado TLS de confianza para el navegador. Tercero, se toma control de una cuenta de registrador o del dominio, lo que permite la transferencia del dominio o cambios en los registros NS y otros registros críticos. Cuarto, un atacante se hace pasar por la marca o el correo electrónico del proyecto para atraer a los usuarios hacia una página de phishing. Los cuatro pueden terminar de la misma manera: el usuario llega a la interfaz incorrecta y es inducido a completar la firma, aprobación o transacción equivocada.

El punto de fondo es este: un punto de entrada del usuario no es una página web independiente, sino una cadena de confianza compuesta por el control del dominio, la resolución DNS, los certificados TLS y la comunicación oficial. Incluso con un contrato en cadena impecable, la falla de un solo eslabón permite que un atacante use el propio dominio o marca del proyecto para guiar a los usuarios hacia la página equivocada y el flujo de transacción equivocado. Para un equipo de proyecto, el objetivo no es corregir una configuración de forma aislada, sino asegurarse de que el dominio no pueda transferirse sin autorización, de que la resolución no pueda alterarse silenciosamente, de que la emisión de certificados esté debidamente restringida y de que el correo oficial sea difícil de suplantar. El escaneo externo que sigue cubre la parte de esa cadena observable desde internet público.

3. BDSS: diseño y alcance

Para convertir estos riesgos del punto de entrada en trabajo sobre el que un equipo pueda actuar realmente, construimos BDSS en torno a los controles observables externamente del módulo de DNS y registrador de SEAL [2]. No pretende reemplazar la revisión interna de un proyecto. Establece una línea base para sacar a la luz brechas de configuración pública sin tocar ningún material operativo sensible.

El módulo de DNS y registrador de SEAL [2] establece un marco de evaluación completo, que abarca tanto controles técnicos (resolución, certificados, correo electrónico, control del dominio) como requisitos operativos como la gestión de activos de dominio, el control de acceso a cuentas, la gestión de cambios, el monitoreo y las alertas, y la respuesta a incidentes.

BDSS acota esto a los controles que pueden observarse y verificarse externamente, de modo que las señales de riesgo de configuración pública en resolución, certificados, correo electrónico y el lado del registrador puedan identificarse a escala. Cubre ocho verificaciones estandarizadas.

BDSS no equivale a una certificación de seguridad completa del DNS de un proyecto. Los controles que no pueden verificarse desde internet público —bloqueo de registro, aprobación de cambios, procedimientos de recuperación— aún requieren revisión frente a la propia documentación y procesos del proyecto.

4. Resultados del escaneo externo en el Top 100 de DefiLlama

La evaluación se completó el 17 de agosto de 2026, utilizando el Top 100 de TVL de DefiLlama vigente en esa fecha. Los dominios principales se identificaron a partir de los puntos de entrada públicos presentados a los usuarios. Los candidatos duplicados, los sitios no oficiales y los dominios cuyo propósito no pudo determinarse fueron excluidos tras la confirmación manual, quedando 100 dominios únicos. Cada uno se sometió a las ocho verificaciones estandarizadas frente a la línea base de riesgo del punto de entrada del usuario. Los resultados describen solo el estado de configuración observable desde internet público; no sustituyen una evaluación de los procesos internos ni una certificación formal. Cada verificación se resuelve en uno de tres estados. PASS significa que la configuración visible públicamente cumplió el criterio observable externamente que implementa la verificación individual, derivado del módulo de DNS y registrador de SEAL. WARN marca señales que merecen atención: un certificado o dominio cercano al vencimiento, un número elevado de CA autorizadas por CAA, un TTL demasiado largo. FAIL significa que no se cumplió un requisito explícito de un control de SEAL (por ejemplo, DMARC no configurado en p=reject), o que no se cumplió la implementación de seguridad correspondiente (por ejemplo, más de diez búsquedas DNS de SPF).

4.1 Resultados generales

El escaneo abarcó 100 dominios, cada uno sujeto a las ocho verificaciones estandarizadas, produciendo 800 resultados: 232 FAIL y 119 WARN. Contando por dominio, 86 generaron al menos un FAIL, 13 no tuvieron ningún FAIL pero sí al menos un WARN, y solo 1 superó todas las verificaciones. Entre los puntos de entrada públicos observados, dicho de otro modo, la cobertura completa de los controles de seguridad operativa de DNS de referencia sigue siendo la excepción.

Según el tipo de verificación, los resultados FAIL se concentran en tres áreas: CAA, DNSSEC y autenticación de correo electrónico, mientras que los resultados WARN aparecen con mayor frecuencia en el alcance de autorización de CAA y en el estado de vencimiento del dominio. La siguiente tabla muestra la distribución de PASS, WARN y FAIL para cada verificación, junto con la principal fuente de cada resultado.

4.2 Principales brechas de configuración

En conjunto, la línea base de configuración de DNS pública entre los principales proyectos sigue siendo insuficiente, y las brechas no se concentran en un único control técnico. La ausencia de CAA, las cadenas de confianza DNSSEC incompletas, la política de autenticación de correo electrónico permisiva y las protecciones del lado del registrador que aún requieren verificación afectan, respectivamente, la emisión de certificados, la confiabilidad de la resolución, la comunicación de marca y el control del dominio. Juntas constituyen las condiciones en las que un usuario confía implícitamente al llegar a un punto de entrada oficial. A continuación, cuatro brechas representativas.

1. Las restricciones de emisión de CAA están ampliamente ausentes: 72 dominios no tenían CAA configurado. Un registro CAA limita qué CA pueden emitir certificados TLS para un dominio [9]. Su ausencia no le entrega un certificado a un atacante directamente, pero sí significa que el proyecto no ha establecido ningún límite adicional de emisión a través del DNS. Si se subvierte la validación de dominio o un plano de control relacionado, el conjunto de CA capaces de aceptar una solicitud de certificado es mucho más difícil de contener. Para los frontends web3, el CAA importa principalmente en escenarios de ataque compuestos: un atacante que interfiere simultáneamente con la validación de dominio, la resolución DNS o el reenvío de tráfico no enfrenta ninguna restricción adicional en el alcance de CA, lo que aumenta la probabilidad de que un frontend falsificado pueda presentar un certificado de confianza para el navegador.

2. Las cadenas de confianza DNSSEC están incompletas: 47 dominios fallaron la validación. Las fallas se manifestaron principalmente como un DNSKEY faltante (34 dominios) o un DS de zona padre faltante (40 dominios), con superposición entre ambos. Sin estos registros, un resolutor de validación externo no puede establecer una cadena de confianza DNSSEC completa [10]. DNSSEC no evitará una toma de control de la cuenta de registrador ni la manipulación del código del frontend, pero sí ayuda a verificar si un resultado de resolución ha sido falsificado o envenenado en caché. Para protocolos que piden a los usuarios conectar una wallet y firmar transacciones, la ausencia de esa capa de verificación significa que un usuario puede ser dirigido a la dirección, servidor o contrato equivocado mientras la interfaz luce prácticamente sin cambios.

3. La política de autenticación de correo electrónico es débil: 38 verificaciones fallaron. Algunos dominios presentaron varios problemas a la vez: 35 no habían elevado la política DMARC a p=reject [11], 6 no tenían configurada una dirección de reporte agregado rua, y 4 tenían una cadena de autorización SPF demasiado larga [12]. Una política DMARC permisiva debilita la aplicación contra correo suplantado, la ausencia de rua compromete el monitoreo continuo, y superar el límite de búsquedas SPF puede causar errores de validación. Dado que el correo del proyecto suele transportar avisos de seguridad, instrucciones de airdrop y notificaciones de migración, estas brechas convierten al correo suplantado en una rampa de entrada más eficaz hacia un frontend falsificado o un flujo de phishing.

4. Las protecciones de control del dominio aún requieren verificación: 3 dominios no mostraron bloqueo de transferencia, y el estado de bloqueo de registro fue indeterminado para otros 90. En el estado RDAP público, solo 7 dominios mostraron un conjunto razonablemente completo de señales de bloqueo; para la mayoría del resto, solo pudo confirmarse el bloqueo de transferencia, y si el bloqueo de registro está habilitado debe verificarse a través de la consola del registrador o la documentación del registro. El bloqueo de transferencia es la medida de referencia contra la transferencia no autorizada; el bloqueo de registro es más adecuado para dominios de alto valor que alojan el frontend principal, la documentación y las API. La gestión de renovación también incide en la continuidad del control: el escaneo encontró 2 certificados TLS dentro de la ventana de alerta de 30 días y 10 dominios dentro de la ventana de recordatorio de vencimiento de 90 días. Para los dominios que alojan puntos de entrada críticos, controles como la renovación automática, los recordatorios escalonados y los propietarios primario y de respaldo designados pueden evitar que un certificado o dominio próximo a vencer se convierta en una interrupción del servicio o en una pérdida de control del punto de entrada.

5. Qué dicen los resultados sobre la seguridad de DNS en web3 hoy

El escaneo muestra que la línea base de configuración de DNS pública en los principales proyectos DeFi sigue teniendo una cobertura inadecuada. De 100 dominios, solo 1 superó todas las verificaciones y 86 generaron al menos un FAIL. Las principales brechas involucran a CAA, DNSSEC, autenticación de correo electrónico y bloqueos de dominio, afectando las restricciones de emisión de certificados, la validación de la resolución, la comunicación de marca y el control del propio dominio.

Estas brechas no se limitan a la capa de resolución ni a un único control técnico. Se distribuyen entre el dominio, la resolución, el certificado y el correo electrónico: varios eslabones distintos en el camino de entrada del usuario. La escasa cobertura de CAA y DNSSEC en particular muestra que estos controles del punto de entrada aún no se despliegan de forma consistente en toda la muestra, aunque el control del dominio, los certificados y la ruta de resolución se sitúan directamente frente a los usuarios. Ninguna de estas señales externas indica que un proyecto haya sido vulnerado. Pero cuando un atacante interfiere con la resolución DNS, obtiene un certificado válido mediante un proceso irregular, toma el control de una cuenta de registrador o suplanta el correo oficial, los controles faltantes debilitan las defensas ya existentes y facilitan que los usuarios sean conducidos hacia una página falsificada o un flujo de phishing. Una gestión inadecuada de la renovación de certificados y dominios también puede interrumpir los puntos de entrada oficiales.

BDSS puede identificar brechas de configuración desde internet público y establecer una línea base de seguridad externa comparable. Sin embargo, no puede demostrar de manera adecuada controles operativos como el bloqueo de registro, la autenticación multifactor de la cuenta de registrador, la confirmación de cambios críticos, el monitoreo y las alertas, o la respuesta a incidentes; ninguno de estos puede establecerse solo a partir de registros públicos. Las señales públicas son, por lo tanto, adecuadas para describir el estado de la industria e identificar áreas que requieren mayor verificación, pero no deben interpretarse como un juicio final sobre la capacidad operativa real de ningún proyecto. Trabajando dentro de ese límite, el escaneo externo y SEAL Certifications se complementan: el primero hace que las brechas de configuración pública sean observables y comparables de forma continua, mientras que el segundo se apoya en documentación operativa y procesos reales para verificar los controles internos sobre activos de dominio, control de acceso del registrador, gestión de cambios y respuesta a incidentes. Como auditor acreditado de SEAL Certifications de la primera cohorte —y el único en Asia—, BlockSec puede ayudar a los proyectos a evaluar su seguridad operativa de manera sistemática dentro de este marco.

Referencias

[1] Security Alliance. SEAL Certifications Overview. https://frameworks.securityalliance.org/certs/overview/

[2] Security Alliance. SEAL Certification Framework: DNS Registrar. https://frameworks.securityalliance.org/certs/sfc-dns-registrar/

[3] Curve Finance. 2022 DNS incident statement. https://x.com/CurveFinance/status/1557505570533478403

[4] Curve Finance. 2025 domain incident statement. https://news.curve.finance/curve-domain-incident/

[5] Galxe. October 6th DNS Security Incident Statement & Guide. https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide

[6] Aerodrome Finance. Domain incident statement. https://x.com/AerodromeFi/status/1992097133869375783

[7] CoW Swap. Domain incident statement. https://x.com/CoWSwap/status/2044924940886163780

[8] Celer Network. cBridge routing incident statement. https://x.com/CelerNetwork/status/1560022871564775424

[9] Hallam-Baker and Stradling. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. https://www.rfc-editor.org/rfc/rfc8659.html

[10] Arends et al. RFC 4033: DNS Security Introduction and Requirements. https://www.rfc-editor.org/rfc/rfc4033.html

[11] Kucherawy and Zwicky. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://www.rfc-editor.org/rfc/rfc7489.html

[12] Kitterman. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. https://www.rfc-editor.org/rfc/rfc7208.html