Dominios .de temporalmente inaccesibles: qué pueden aprender los responsables de sitios web de la interrupción de DNS

¿Qué ocurrió?

Normalmente la carga de un sitio web se realiza en segundo plano en varios pasos. Cuando un usuario introduce un dominio, el equipo o el router consulta a un resolutor DNS. Éste determina qué dirección IP pertenece al dominio. Solo entonces el navegador puede cargar el sitio web desde el servidor web.

En la incidencia de .de fue precisamente la resolución de nombres la que falló. Los servidores DNS recibieron mensajes de error al resolver muchos dominios .de. Especialmente relevante: el problema no se podía evitar inicialmente para los usuarios simplemente usando otro proveedor DNS como Google DNS o Cloudflare 1.1.1.1. Se vieron afectados, en general, todos los resolutores DNS que tenían activada la validación DNSSEC.

El incidente fue clasificado por la DENIC como que, a partir de aproximadamente las 22:00 del 5 de mayo de 2026, se publicaron firmas DNSSEC defectuosas para la zona .de. Los resolutores que realizaban la validación tuvieron que descartar estas respuestas y responder con SERVFAIL. Como consecuencia, muchos usuarios no pudieron resolver correctamente los dominios afectados.

Por qué esto es tan relevante para los responsables de sitios web

Para los responsables de sitios web el incidente es importante sobre todo porque demuestra: un sitio web puede dejar de funcionar aunque su propio servidor funcione correctamente.

Al enfrentarse a la inaccesibilidad, muchos piensan primero en causas clásicas como:

• Fallo del servidor en el proveedor de alojamiento web
• Sitio web con errores o actualización defectuosa del CMS
• Certificado SSL caducado
• Zona DNS mal configurada en el proveedor
• Problema en la conexión a Internet propia

Sin embargo, el incidente de .de muestra otro nivel: también puede verse afectada la infraestructura de dominios superior. En este caso, el problema no residía en la zona DNS individual de un dominio concreto, sino a nivel del dominio de primer nivel .de.

Esto complica considerablemente la búsqueda de errores. Desde la perspectiva del usuario todo parece igual: el sitio web no es accesible. Para un profano es difícil distinguir si detrás hay una caída del propio Alojamiento web, un problema DNS en el proveedor, un problema en la entidad registradora o un problema del resolutor local.

DNSSEC: función de seguridad con gran impacto

DNSSEC tiene por objetivo asegurar criptográficamente las respuestas DNS. En términos sencillos, un resolutor DNS comprueba si la respuesta pertenece realmente a la zona correspondiente y no ha sido manipulada en tránsito. DNSSEC no sirve para el cifrado, sino para la integridad. La respuesta DNS sigue siendo visible, pero su autenticidad puede verificarse mediante firmas digitales. Precisamente esa verificación de firmas fue el problema en la incidencia de .de: si las firmas eran erróneas, los resolutores que validan debían rechazar las respuestas.

Esto no significa, sin embargo, que DNSSEC haya fracasado en general. Más bien, el incidente muestra que los mecanismos de seguridad en el DNS deben gestionarse con mucha diligencia. Si se produce un error en un nivel alto de la jerarquía DNS, puede afectar a un gran número de dominios a la vez.

Consejo: a principios de año hablamos en el domain pulse 26 en St. Gallen con Tom Keller de DENIC, entre otros temas, sobre la operación de la infraestructura crítica.

Por qué algunas páginas seguían accesibles

También es interesante que la incidencia no se manifestó por igual en todas partes. Algunos usuarios pudieron acceder todavía a ciertos dominios .de, otros no.

Una razón de ello es el caché DNS. Los resolutores DNS almacenan respuestas durante un tiempo determinado. Si un dominio había sido consultado poco antes de la incidencia, la dirección IP aún podía permanecer en la caché. En esos casos, el sitio web podía seguir siendo accesible.

Además, aquí también puede entrar en juego el principio «Serve Stale». En este mecanismo, los resolutores pueden, en determinadas condiciones, devolver respuestas DNS caducadas pero previamente válidas cuando una consulta nueva falla. Con ello se atenuó parcialmente el impacto de la incidencia. Sin tales mecanismos, la caída habría sido aún más perceptible para muchos usuarios.

Por qué cambiar de proveedor de DNS no siempre ayuda

En muchos problemas DNS puede ayudar usar otro resolutor, por ejemplo Google DNS, Cloudflare o Quad9. En este incidente eso solo fue posible de forma limitada.

La razón: si la firma defectuosa proviene de la propia zona .de, distintos proveedores de DNS reciben esencialmente la misma base defectuosa. Los resolutores con validación DNSSEC activa deben rechazar esas respuestas.

El proveedor Cloudflare aplicó posteriormente una medida temporal. El proveedor trató .de durante un tiempo como si la zona no estuviera firmada con DNSSEC. Técnicamente, según Cloudflare, esto equivalía al efecto de un Negative Trust Anchors. Gracias a ello, 1.1.1.1 pudo resolver de nuevo dominios .de, aunque deliberadamente sin validación DNSSEC para la zona afectada. Cloudflare califica esta decisión como una ponderación entre disponibilidad y comprobación de seguridad.

¿Qué significa esto para los clientes de proveedores de hosting?

Para los clientes habituales de hosting, la conclusión más importante es: no toda inaccesibilidad es automáticamente un error del proveedor de hosting.

Un proveedor de hosting puede, en un escenario así, tener todo técnicamente en orden:

• El servidor web está en funcionamiento.
• Los archivos del sitio web son accesibles.
• El certificado SSL es válido.
• Los servidores de nombres del proveedor funcionan.
• La zona de dominio está configurada correctamente.

Sin embargo, el sitio web puede no estar accesible para muchos usuarios si la resolución falla a un nivel superior del DNS.

Para los equipos de soporte de los proveedores también resulta desafiante. Los clientes solo ven la caída y, comprensiblemente, se ponen en contacto con su proveedor. El proveedor debe poder distinguir rápidamente si el problema está dentro de su ámbito de responsabilidad o si afecta a una infraestructura externa.

Qué pueden aprender los responsables de sitios web

El incidente demuestra lo importante que es tener una comprensión básica de la cadena técnica detrás de un sitio web. Un dominio no es solo un nombre, sino parte de una infraestructura de varios niveles.

Para que un sitio web sea accesible se requieren, entre otros:

• Registro de dominio
• Servidores de nombres
• Zona DNS
• Configuración DNSSEC
• Infraestructura del registro de la TLD
• Resolvers DNS de los usuarios
• Servidor web
• Certificado SSL
• Aplicación o CMS

Si cualquiera de estas capas falla, el sitio web puede volverse inaccesible. Por eso es importante que los responsables no consideren las caídas simplemente como un «problema de hosting», sino que acoten la causa con más precisión.

La monitorización debería comprobar más que solo el servidor web

La monitorización clásica de disponibilidad suele comprobar si un sitio web es accesible por HTTP o HTTPS. Eso es importante, pero no siempre es suficiente.

Precisamente el incidente de .de demuestra que los aspectos DNS también son relevantes. Por eso son útiles soluciones de monitorización que no solo comprueben el servidor web, sino que también vigilen otras capas técnicas:

• Accesibilidad del sitio web
• Resolución DNS del dominio
• Certificados SSL y fechas de caducidad
• Respuestas de los servidores de nombres
• Códigos de estado HTTP
• Tiempos de carga
• Mensajes de estado externos de proveedores de infraestructura clave

Aún más importante es la correcta interpretación de la alerta. Si muchos dominios .de se ven afectados simultáneamente, la causa probablemente no esté en un único proveedor de hosting. Una buena monitorización ayuda en estas situaciones a distinguir más rápido entre un problema local, un problema de hosting y una interrupción DNS de mayor alcance.

En nota propia: Infórmate con hosttest Plus en cualquier momento y de forma gratuita sobre incidencias - por correo electrónico, SMS o llamada. 

También el correo electrónico puede verse afectado

El DNS no solo se necesita para sitios web. También los servicios de correo electrónico dependen de entradas DNS. Si un dominio no se puede resolver correctamente, también pueden verse afectados los servidores de correo, los registros MX u otros servicios relacionados con el dominio.

Para las empresas esto es especialmente crítico. Un sitio web inaccesible ya es problemático. Si además los correos electrónicos no se entregan de forma fiable, afecta a la comunicación con clientes, pedidos, solicitudes de soporte y procesos internos.

Por qué las páginas de estado y la comunicación transparente son importantes

En un problema de infraestructura generalizado, la comunicación rápida es decisiva. Los responsables de sitios web deben saber si tienen que actuar por su cuenta o si deben esperar a que lo solucione una entidad central.

Heise documentó el incidente muy pronto con indicaciones técnicas concretas y señaló, entre otras cosas, firmas DNSSEC defectuosas. Cloudflare ofreció más tarde un análisis técnico posterior con detalles sobre el comportamiento de los resolvers, el almacenamiento en caché, las respuestas SERVFAIL y medidas temporales. Para operadores, agencias y proveedores de hosting son importantes estas valoraciones porque ayudan a evaluar la situación correctamente.

Para los proveedores de hosting web se deriva una tarea clara: ante averías externas de mayor alcance, conviene informar a los clientes lo antes posible, incluso si la causa no está en el propio proveedor. Eso reduce las consultas al soporte y genera confianza.

Conclusión: la incidencia .de fue más que un fallo técnico

La inaccesibilidad temporal de muchos dominios .de no fue una caída de hosting habitual. Fue un ejemplo de cuánto dependen los sitios web de las estructuras DNS centrales.

Para los usuarios de dominios y de hosting, la lección más importante es: un sitio web no consiste solo en el espacio web. El dominio, el DNS, DNSSEC, los resolvers y la infraestructura del registro son igual de decisivos para la accesibilidad.

Los clientes de hosting web deberían por tanto fijarse no solo en el espacio, el precio y el soporte, sino también en cómo de profesionalmente maneja un proveedor el DNS, la monitorización, las páginas de estado y la comunicación técnica. Porque en caso de emergencia no solo importa que un proveedor controle su propia infraestructura. También es decisivo cuán rápido detecta las incidencias externas, las clasifica e informa a sus clientes.