Bloqueo del registrador vs defensa en capas: cuál elegir

Imagina despertar y descubrir que todos los dominios de tu empresa (producción, staging, el que aloja tus registros MX) han sido suspendidos por tu registrador de dominios durante la noche. Ningún despliegue falló. Ningún servidor se cayó. Alguien del equipo de confianza y seguridad (o, lo más probable, una cadena automatizada de gestión de abusos) activó un interruptor, y toda tu presencia en internet desapareció. No es hipotético: ocurre con la frecuencia suficiente como para que los foros de sysadmins estén llenos de historias de terror sobre registradores que deshabilitan cuentas por denuncias de abuso sin verificar, tuits ambiguos o una sola imagen marcada entre millones de subidas de usuarios.

Llevo años trabajando en respuesta a incidentes para equipos de infraestructura, y el patrón siempre es el mismo. Los ingenieros diseñan redundancias elaboradas para el cómputo (multi-AZ, multi-región, runbooks de failover) y luego dejan el único activo que no se puede redesplegar, el propio nombre de dominio, en una sola cuenta protegida por una contraseña y, quizá, un código por SMS. Este artículo compara dos filosofías para gestionar ese riesgo: el enfoque tradicional de bloqueo del registrador (elige un registrador sólido, endurece la cuenta y confía en ellos) frente al enfoque de defensa en capas (asume que tu registrador te fallará y diseña alrededor de ese escenario). Spoiler: necesitas ambos, pero el segundo es el que realmente te salva a las 3 de la mañana.

Por qué tu registrador es un tipo distinto de punto único de fallo

La mayoría de los puntos únicos de fallo de tu stack son cosas que controlas. Un primario de base de datos, una puerta de enlace NAT, un broker de mensajes: puedes replicarlos, y tú mismo escribiste el plan de failover. Tu registrador es diferente por tres razones. Primero, es una dependencia del plano de control que no puedes replicar. No puedes tener dos registradores para el mismo dominio; el registro tiene exactamente un patrocinador oficial. Segundo, los modos de fallo del registrador son lentos. Una transferencia de dominio en condiciones normales tarda entre cinco y siete días, y si el registrador actual ha deshabilitado tu cuenta, ni siquiera puede que consigas el código de autorización para iniciarla. Tercero, el fallo suele ser adversarial de una forma curiosa: no es un atacante, es el propio proveedor actuando contra ti por una denuncia de abuso que nunca viste.

El radio de impacto también es peor de lo que la gente supone. Cuando un registrador suspende un dominio, normalmente apuntan los registros NS a una página de bloqueo o simplemente dejan de responder. Eso mata tu web, claro. Pero también mata tu correo (los registros MX viven en el DNS), tu SSO si los callbacks referencian tu dominio, tus clientes de API, tu página de estado si está en el mismo dominio y, mi favorita personal, la dirección de correo que usarías para recibir las instrucciones de recuperación. Si el correo de tu cuenta de registrador es admin@tudominio.com y tudominio.com está suspendido, ahora estás intentando demostrar tu identidad al soporte desde una dirección en la que ellos no confiarán. He visto cómo este bucle se comía un día entero de un incidente.

Y los incentivos económicos juegan en tu contra. Cuando un registrador es adquirido por un fondo de capital privado (como han hecho varios grandes), el guion es predecible: recortar el soporte humano, automatizar la gestión de abusos y subir precios. Los sistemas automáticos de abuso optimizan su riesgo, no el tuyo. Suspender un dominio que luego resulta inocente no les cuesta nada. Dejar activo un dominio que luego resulta culpable les cuesta problemas con el registro y mala prensa. Adivina en qué sentido se equivoca la automatización.

Primer enfoque: bloqueo del registrador (endurecer el punto único)

La filosofía del bloqueo dice: acepta que el registrador es un punto único de fallo y haz que ese punto sea lo más robusto posible. Es la estrategia que la mayoría de empresas aplica, lo hayan articulado o no. Bien hecha, se ve así:

• Elige el registrador por calidad de soporte, no por precio. Los 3 dólares al año que ahorras por dominio no significan nada frente a un día de caída. Quieres soporte telefónico, un representante de cuenta con nombre si tienes una cartera grande y una empresa a la que pudieras demandar en tu propia jurisdicción si llegara el caso.
• Activa el bloqueo de registrador (clientTransferProhibited) en todos los dominios, y el bloqueo de registro en los críticos. El bloqueo de registro exige verificación fuera de banda (normalmente una llamada telefónica con una frase de paso) antes de cualquier cambio de servidores de nombres o transferencias. Es molesto, y ese es el objetivo.
• Usa autenticación de dos factores con llave de hardware o TOTP, nunca SMS. Abundan las historias de agentes de soporte que quitan el 2FA tras una charla convincente; algunos registradores ya ofrecen políticas de «ningún cambio en la cuenta sin la llave de hardware». Acógete a ellas.
• Usa una dirección de correo dedicada y basada en roles para la cuenta de registrador, que NO esté en un dominio registrado en ese mismo registrador. Algo como dominios-admin@ejemplo.org, registrado en otro sitio completamente distinto.
• Restringe el acceso. Dos o tres personas concretas, credenciales en una bóveda corporativa, no un login compartido en una hoja de cálculo.
• Documenta todo: número de cuenta, PIN, rutas de escalado de soporte, los documentos de identidad exactos con los que está verificada la cuenta. Ponlo en tu runbook de incidentes.

El bloqueo tiene fortalezas reales. Previene el desastre más común con registradores, que no es la incautación, sino el secuestro. Las transferencias por ingeniería social y las tomas de cuenta han robado dominios de alto valor durante años, y el bloqueo de registro junto con el 2FA por hardware detiene casi todo. Además es barato y no requiere ingeniería continua.

Pero aquí está la incómoda verdad: el bloqueo te protege de los atacantes, no del propio registrador. Cada control de arriba es un control que opera el registrador. Si su automatización de abusos deshabilita tu cuenta, tu bloqueo de registrador te está bloqueando a ti, tu PIN de soporte está en un sistema al que no puedes llegar, y la persona que podría anularlo todo quizá ya no exista porque el soporte fue «optimizado» el trimestre pasado. Los profesionales reportan tiempos de restauración de más de seis horas incluso en casos sencillos de falso positivo, y sagas de varios días cuando la suspensión abarca un fin de semana. El bloqueo es necesario. No es suficiente.

Segundo enfoque: defensa en capas (asume que el registrador te traicionará)

La filosofía por capas parte de una premisa más oscura: algún día, por malicia, automatización o error, tu registrador derribará tus dominios, y tendrás que volver a estar en línea antes de que su cola de soporte llegue a ti. Es la misma mentalidad que hay detrás de la ingeniería defensiva frente a fallos catastróficos: no evitas el desastre, haces que sea sobrevivible.

La técnica central es separar las capas que normalmente vienen agrupadas. La mayoría de las empresas pequeñas compran el dominio, usan el DNS del registrador, alojan en su servicio de hosting y también contratan el correo ahí. Son cuatro puntos únicos de fallo apilados en una sola cuenta. Desagrúpalos:

• Registro: en el registrador A, elegido por estabilidad y soporte.
• DNS autoritativo: en un proveedor de DNS independiente B (o dos proveedores en configuración dual-primary), gestionado como código.
• Hosting: donde tenga sentido para la carga de trabajo, sin relación con ninguno de los anteriores.
• Correo: un proveedor dedicado, con las direcciones de recuperación de A y B viviendo en otro dominio distinto.
• Dominio de respaldo: un dominio de reserva preaprovisionado en un registrador diferente, con certificados TLS emitidos y una versión mínima de tus servicios críticos ya respondiendo en él.

El dominio de respaldo merece énfasis porque casi nadie lo hace, y es la jugada con más palanca. Cuando tus dominios principales están suspendidos, los TTL del DNS y las cachés de los resolvers hacen que no puedas simplemente «cambiar al respaldo»: el respaldo tiene que haber existido, haberse calentado y ser resoluble antes del incidente. Un dominio de reserva como example-status.net, registrado en otra parte, que aloje tu página de estado, tus comunicaciones de incidentes y un registro MX de emergencia, convierte una caída que podría hundir la empresa en un martes embarazoso.

DNS como código: la capa que todos se saltan

Aquí tienes un fallo que he visto dos veces en incidentes reales: el equipo recupera su dominio tras una suspensión del registrador, vuelve a encender todo y el DNS está mal, porque la «fuente de verdad» de su zona era la interfaz web del registrador, que estaba inaccesible durante el incidente y de todos modos se había desviado de lo que nadie recordaba. Reconstruir de memoria un archivo de zona de 200 registros durante una caída es una clase especial de sufrimiento. Como ya hemos escrito antes, los errores de configuración de DNS siguen rompiendo producción incluso en condiciones normales; durante un incidente con el registrador es catastrófico.

La solución es aburrida: gestiona la zona DNS como código, en control de versiones, desplegada por CI. Herramientas como dnscontrol o los proveedores DNS de Terraform te permiten describir la zona de forma declarativa y publicarla en varios proveedores. Así, el estado de tu DNS sobrevive a la pérdida del plano de control de cualquier proveedor, y «pasar al DNS del proveedor B» es un cambio de una línea y un despliegue, no una sesión heroica de copiar y pegar.

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

El DNS autoritativo dual está infravalorado. La mayoría de los resolvers prueban felizmente todos los servidores de nombres listados, así que si un proveedor tiene una caída (y los grandes proveedores de DNS las tienen), la resolución continúa. La trampa está en mantener ambos proveedores sincronizados, justo lo que te da gratis el DNS como código. Sin él, el DNS con doble proveedor es una generadora de desviaciones y, probablemente, peor que un único proveedor.

Una advertencia sobre los TTL: los equipos adoran subirlos a 86400 «por rendimiento» y luego descubren en un incidente que una cuarta parte de internet guarda en caché sus antiguos registros de servidores de nombres durante un día entero. Para los registros relacionados con servidores de nombres y cualquier cosa que cambiarías en una emergencia, mantén los TTL entre 300 y 900 segundos. El coste en volumen de consultas es insignificante comparado con la agilidad que ganas.

Cara a cara: cuándo gana cada enfoque

Seamos directos con el compromiso, porque las dos estrategias optimizan para amenazas y organizaciones distintas.

• Modelo de amenaza: El bloqueo gana frente al secuestro y la ingeniería social, que son los desastres estadísticamente comunes. La defensa en capas gana frente a los fallos del lado del registrador: automatización de abusos, incautación de cuenta, insolvencia o colapso del soporte.
• Coste: El bloqueo casi no cuesta nada: tarifas del bloqueo de registro, una llave de hardware y disciplina. La defensa en capas cuesta la factura de un segundo proveedor, un dominio de reserva, la infraestructura de CI y atención continua para evitar desviaciones.
• Tiempo de recuperación: En un escenario de incautación, los equipos que solo tienen bloqueo dependen de la cola de soporte (horas o días, según todas las historias que he escuchado). Los equipos con capas y un dominio de reserva caliente vuelven en minutos u horas.
• Carga operativa: El bloqueo se configura una vez y se olvida. La defensa en capas se pudre si no se mantiene: un dominio de respaldo sin probar con un certificado caducado es teatro de seguridad.
• Encaje organizativo: Una startup de cinco personas con un único producto SaaS debería aplicar el bloqueo completo más los dos movimientos de capas más baratos (DNS como código externo y correo de recuperación fuera del dominio). Una empresa cuyos ingresos mueren con su dominio necesita la pila completa por capas.

El bloqueo protege tus dominios de los atacantes. La defensa en capas protege tu negocio de tu registrador. Estás expuesto a ambos, así que necesitas ambos.

El runbook de recuperación que nadie escribe hasta que es demasiado tarde

Elijas la postura que elijas, escribe ya el runbook de incautación. Los incidentes que he visto salir bien tenían uno; los desastres estaban improvisados. El tuyo debería cubrir, en orden: confirmar el alcance (¿es un dominio o toda la cuenta? revisa los códigos de estado de whois como clientHold o serverHold), abrir el ticket de soporte con tus identificadores de cuenta documentados, activar el dominio de respaldo y actualizar tus comunicaciones de estado, notificar a los clientes por canales que no dependan del dominio caído, y empezar en paralelo el proceso de transferencia de salida: no esperes a que se resuelva para decidir que te vas.

Ensaya también las partes aburridas. ¿Puedes entrar en el registrador desde un dispositivo limpio, con la llave de hardware, sin el gestor de contraseñas que vive detrás del SSO en el dominio suspendido? ¿Está la frase de paso del bloqueo de registro donde la guardia de guardia puede encontrarla? Los equipos prueban el failover de bases de datos cada trimestre y la recuperación del registrador nunca. Dado que el fallo del registrador tumba el SSO que usas para llegar a todo lo demás, esa prioridad está al revés.

Mi recomendación

Aplica el bloqueo completo: es una tarde de trabajo y frena el ataque más probable. Después implementa exactamente tres piezas de defensa en capas, en este orden: mueve el DNS autoritativo fuera de tu registrador y gestiónalo como código; traslada el correo de recuperación de tu cuenta de registrador a un dominio de otro registrador distinto; y levanta un dominio de respaldo caliente con certificados, página de estado y MX de emergencia. Esas tres cubren los modos de fallo dominantes por unos pocos cientos de dólares al año. Reserva la arquitectura completa de doble registrador y doble DNS para organizaciones que puedan articular cuánto les cuesta un día de pérdida total de dominio; si esa cifra tiene seis cifras, ya sabes qué hacer.

Y si todavía eliges registrador principalmente por precio, para. El mercado de registradores baratos se está concentrando en propietarios cuyo incentivo es reemplazar el juicio humano por automatización que te suspenderá encantada ante un falso positivo y atenderá tu ticket el jueves. Tu dominio es la única pieza de infraestructura que no puedes redesplegar desde una imagen de contenedor. Trátalo como tal.