Las principales operadoras españolas han vuelto a bloquear el acceso a un servicio legítimo y masivo: el DNS dinámico de No-IP, concreto el dominio ddns.net, utilizado desde hace más de dos décadas por hogares y pequeñas empresas para acceder a sus cámaras, domótica, NAS o servidores cuando la dirección IP pública cambia. El corte, según los indicios recabados por usuarios y medios especializados, no responde a una caída técnica: Digi redirige cualquier subdominio bajo ddns.net a 127.0.0.1 mediante sus DNS oficiales; Movistar devuelve el código 451 —Unavailable for Legal Reasons; MásOrange muestra un mensaje explícito de “contenido bloqueado por requerimiento de la Autoridad Competente”, y Vodafone informa de indisponibilidad por “causas ajenas”.

El resultado práctico es el mismo: miles de subdominios como micasa.ddns.net quedan inaccesibles desde conexiones fijas y móviles en España, aunque el servicio global de No-IP siga funcionando fuera de la red del usuario. No-IP no es un sitio de descargas ni un repositorio de contenidos: es un intermediario técnico que resuelve un problema cotidiano en el acceso residencial, donde la IP dinámica puede cambiar en cualquier momento y hace inviable memorizar números. El servicio vincula un nombre fácil de recordar con la IP vigente, de forma automática y en tiempo real.

Un bloqueo “de dominio” en un servicio compartido por miles

No-IP opera con dominios de primer nivel (por ejemplo, ddns.net) bajo los que concede subdominios gratuitos a cada usuario (casa-paco.ddns.net, tienda-xyz.ddns.net, etc.). Este diseño tiene una implicación crítica: si se bloquea el dominio principal, caen todos los subdominios, del mismo modo que bloquear una IP de CDN tumbaría a los miles de sitios web que comparten esa dirección. Es, en la práctica, lo que está ocurriendo en España.

Lo preocupante, señalan expertos consultados por este medio, no es solo el impacto puntual, sino la normalización del sobrebloqueo. En 2025 se han multiplicado los casos en los que, al tratar de impedir el acceso a un objetivo concreto, termina vetándose el servicio entero. Tiempo atrás esos episodios se atribuían a errores de configuración —como cuando Telefónica bloqueó “rt.com” y acabó filtrando todo el TLD “.rt.com”—, pero en los últimos meses el bloqueo “amplio” por mandato legal se ha convertido en tónica, con poca transparencia sobre quién ordena la medida, por qué y por cuánto tiempo.

Quién puede ordenar un bloqueo: un mosaico sin transparencia

En España, diversos organismos y titulares pueden promover u ordenar bloqueos: Ministerio de Cultura, Consumo, y entes privados con capacidad para activar procedimientos (operadoras como Movistar, la Liga o la MPA en el marco de la lucha contra la piratería, entre otros). El problema es que, de cara al usuario final, el proceso es opaco: no hay un registro público accesible, se ofrecen mensajes genéricos (“451 legal reasons”, “contenido bloqueado por autoridad competente”), no se detalla el alcance (subdominio concreto o dominio entero) y no siempre se informa de mecanismos de revisión.

Ese vacío facilita errores de proporcionalidad. Si el bloqueo pretendía impedir un subdominio infractor, cerrar todo ddns.net provoca daños colaterales desproporcionados: miles de hogares y equipos de teletrabajo pierden conectividad remota, pequeñas tiendas quedan “ciegas” en sus cámaras o no pueden abrir un túnel de mantenimiento, y pymes con un NAS de respaldo remoto ven interrumpidas sus tareas de sincronización.

Qué están viendo los clientes y por qué

• Digi: manipulación de DNS a nivel de red. Sus resolutores responden 127.0.0.1 para xxx.ddns.net. El navegador cree que el destino es “uno mismo” (loopback) y el acceso falla.
• Movistar: HTTP 451 (“indisponible por razones legales”). Es el código estándar que indica restricción por orden o marco legal.
• MásOrange: aviso textual de bloqueo por requerimiento de la autoridad competente.
• Vodafone: mensaje de indisponibilidad “por causas ajenas”.

Aunque la sintaxis técnica varíe, el patrón es coherente: filtrado a nivel de resolución (DNS) o intercepción en capa HTTP con página de bloqueo. Para la mayoría de clientes no expertos, el efecto es indistinguible de una caída del servicio o de un fallo en su propio equipo.

No-IP y el enigma español de la IP pública

El caso ilumina una realidad local: España sigue dependiendo masivamente de IPv4, y muchas conexiones residenciales no incluyen (o dejan de incluir) IP pública dedicada debido al CG-NAT. Para esos usuarios, No-IP y servicios análogos son una válvula de escape: permiten llegar a dispositivos domésticos sin contratar extras, sin pagar por IP fija y sin reconfigurar manualmente el DNS cada vez que cambia la IP. La popularidad es tal que routers de múltiples marcas —y kits suministrados por operadoras— ya incluyen integraciones nativas con No-IP para avisar a la plataforma cuando se asigna una IP nueva.

Por eso, el bloqueo de ddns.net no es un detalle menor. Cortar el dominio rompe una función cotidiana para miles de abonados legítimos, desde aficionados a la domótica hasta autónomos que acceden a un PC de sobremesa del taller o la tienda.

“Saltar” el bloqueo: lo que están haciendo los usuarios (y sus riesgos)

En Digi, al ser un bloqueo DNS, bastaría con cambiar los DNS del router o del dispositivo por resolutores públicos para evitar que la respuesta apunte a 127.0.0.1. En los demás casos, muchos usuarios están recurriendo a VPN para “sacar” el tráfico por otra red. Son parches funcionales, pero no están exentos de fricciones: un cambio de DNS puede romper servicios de la operadora (televisión, telefonía IP, portales cautivos) y una VPN añade latencia, costes y complejidad.

Alternativas técnicas razonables —siempre que el usuario tenga control sobre su red— incluyen:

• Dominios propios con actualización dinámica (RFC 2136) o con API de proveedor DNS para automación del registro A/AAAA.
• Túneles salientes y reverse proxy (por ejemplo, montar un WireGuard o OpenVPN desde casa hacia un VPS con IP pública y publicar servicios a través de ese servidor).
• Soluciones de acceso seguro tipo “Zero-Trust” (túneles autenticados que evitan abrir puertos en el router).

Aun así, ninguna de estas alternativas justifica bloquear de forma indiscriminada un servicio neutral usado por una comunidad tan amplia.

¿Combate a la piratería o puntería gruesa?

Las operadoras españolas ejecutan bloqueos judiciales y administrativos contra webs con contenido ilícito. La experiencia demuestra, sin embargo, que los mandatos amplios o las implementaciones toscas tienden a sobreincluir —y a veces silenciar— servicios que nada tienen que ver con la infracción. La proporcionalidad y el “mínimo daño” deberían ser la guía: si el problema es un subdominio en ddns.net, aplicar un bloqueo quirúrgico —no el veto total— es el camino compatible con la libertad de empresa, la innovación y los derechos del consumidor.

Aquí sale a relucir otra carencia: la falta de transparencia. En ausencia de una lista pública que documente qué se bloquea, quién lo ordena, por cuánto tiempo y cómo recurrir, los usuarios quedan a expensas de ensayo-error y foros. Y los operadores acumulan malestar —y costes— por peticiones de soporte que no provocan ellos.

Qué deberían hacer reguladores y operadoras para evitar el próximo “apagón” inocente

1. Publicar (o habilitar un tercero independiente que publique) un registro de bloqueos con motivo, alcance y duración.
2. Privilegiar los bloqueos granulares (host/subdominio) frente a los bloqueos de dominio completo, sobre todo cuando el dominio alberga miles de usuarios legítimos.
3. Establecer procedimientos de revisión rápida y desbloqueo cuando se demuestre daño colateral.
4. Notificar a los proveedores afectados para que puedan cooperar (por ejemplo, congelando o actuando contra el subdominio infractor).
5. Comunicar a los clientes, con mensajes claros, por qué ven un error 451, quién lo ha ordenado y cómo reclamar o solicitar excepción.

El trasfondo: España, entre la escasez de IPv4 y una transición a IPv6 que no despega

Este episodio vuelve a poner foco en la singularidad española: solo el 10,85 % del tráfico nacional circula sobre IPv6, una de las cuotas más bajas de Europa. Mientras tanto, IPv4 es un bien escaso y caro; los operadores con reservas —como Vodafone España— venden bloques en el mercado secundario para capitalizar el activo. En ese contexto, proliferan CG-NAT y parches que, sumados a bloqueos discutibles, hacen la vida difícil a quien intenta auto-hospedar servicios sencillos.

Impulsar IPv6 es parte de la solución estructural: más direcciones, menos NAT, menos fricción para el acceso remoto. Pero el buen gobierno del bloqueo de contenidos es igual de urgente si no se quiere romper la Internet cotidiana con decisiones desproporcionadas.

Lo importante, en una frase

Bloquear ddns.net es apagar de un golpe miles de timbres digitales que no son el problema. Si hay un subdominio infractor, que se bloquee ese subdominio. Lo demás es daño colateral evitable.

---

Preguntas frecuentes

¿Cómo saber si mi línea está afectada por el bloqueo a ddns.net y qué puedo hacer sin “romper” nada?
Si al entrar a micasa.ddns.net ves un 451 (Movistar) o un mensaje de “contenido bloqueado” (MásOrange/Vodafone), o directamente no abre (Digi), es buena pista. En Digi, probar otros DNS públicos puede restaurar el acceso; en otros casos, una VPN o túnel desde casa hacia un VPS con IP pública puede servir. Ojo: cambiar DNS puede afectar servicios de la operadora (TV, VoIP). Lo ideal es exigir un bloqueo granular y transparencia.

¿Por qué es problemático bloquear un dominio “paraguas” como ddns.net?
Porque alberga miles de subdominios legítimos. Es como cortar una IP de CDN: te llevas por delante miles de webs inocentes. Si el objetivo es un subdominio, debe bloquearse solo ese host. Lo contrario es desproporcionado y genera daños colaterales.

¿Hay alternativas a No-IP para conexiones con IP dinámica o CG-NAT?
Sí: usar un dominio propio con actualización dinámica; montar túneles salientes (WireGuard/OpenVPN) a un VPS con IP pública; o adoptar acceso “zero-trust” (túneles autenticados sin puertos abiertos). Son soluciones eficaces, pero no justifican bloqueos indiscriminados de servicios neutros.

¿Qué responsabilidad tienen operadoras y reguladores cuando se produce un sobrebloqueo?
Deben asegurar proporcionalidad, publicar información mínima (motivo, alcance, duración), habilitar vías de revisión y desbloqueo ágiles, y coordinarse con el proveedor afectado. La transparencia reduce errores, costes de soporte y perjuicios a clientes que no tienen nada que ver con la infracción.

vía: bandaancha