RTS/CTS

Desde hace más de un año, los bloqueos judiciales de LaLiga contra la piratería afectan a IPs enteras de proveedores CDN como Cloudflare, dejando fuera de juego a cientos de sitios legítimos que nada tienen que ver con el fútbol. Un estudio de OONI (junio 2026) encontró más de 554.000 dominios afectados por estos bloqueos.

Ha aparecido una herramienta pensada para paliar justo ese daño colateral: xdp.es, un servidor DNS público y gratuito que reescribe respuestas DNS para esquivar direcciones bloqueadas, sin necesidad de recurrir a una VPN.

¿Cómo funciona?

Detecta cuándo una IP dentro de los prefijos de Cloudflare (AS13335) está bloqueada.

Sustituye esa IP por otra del mismo prefijo que no esté afectada.

Funciona gracias a SNI (Server Name Indication, RFC 6066): el enrutamiento real al sitio lo decide el nombre de dominio enviado en el handshake TLS, no la IP de entrada.

Servicio opt-in: el usuario elige activamente cambiar de resolver.

¿Es esto “hacer trampas” con el protocolo DNS?

En el episodio analizamos la tensión entre:

RFC 1035 — el DNS nunca ha garantizado una única “respuesta verdadera” por dominio (GeoDNS y el propio anycast ya varían la respuesta).

RFC 3833 (Threat Analysis of the DNS) — describe este patrón de sustitución de respuestas como parte del modelo de amenazas contra el que se diseñó DNSSEC.

RFC 7754 y RFC 8890 (principios IETF sobre bloqueo de servicios y el usuario final) — el factor decisivo es el consentimiento: a diferencia de los bloqueos de los operadores, xdp.es es una elección voluntaria del usuario.

Enlaces:

xdp.es

Prueba de rendimiento (RedesZone)

Contexto OONI y cifras de uso (El Chapuzas Informático)

Servidor secundario de xdp.es (bandaancha.eu)

Implementación de referencia en Rust (GitHub)

Episodios relacionados: Ep. 43 (bloqueos de LaLiga), Ep. 93 (LaLiga contra los principios de Internet), Ep. 44 (proxies inversos con Cloudflare), Ep. 40 (DNS y DDNS)

Si te ha gustado el episodio, te agradecería que lo compartas con amigxs potencialmente interesadxs y que escribas una reseña en la plataforma de Podcast que utilices (si lo permite). Muchas gracias y nos escuchamos pronto.

Música de la entradilla de Iciar Ybarra (@gaudeamusica).

Apple ya controla casi todo el módem de sus iPhone: el nuevo C2 añade mmWave en EE. UU. y dejará a Qualcomm en un solo modelo. Y el iPhone Handoff permite mover tu número entre dos iPhone… si tu operador coopera. Repaso de conectividad del evento del 9 de septiembre.

Si te ha gustado el episodio, te agradecería que lo compartas con amigxs potencialmente interesadxs y que escribas una reseña en la plataforma de Podcast que utilices (si lo permite). Muchas gracias y nos escuchamos pronto.

Música de la entradilla de Iciar Ybarra (@gaudeamusica).

Un monoplaza de F1 transmite telemetría, vídeo, audio y GPS en tiempo real a más de 300 km/h, rodeado de otros veinte coches compitiendo por el mismo espectro. En este episodio abrimos el capó de la red, no del motor: por qué 4G/5G, DECT o Wi-Fi nunca fueron una opción; cómo se coordina la frecuencia de cada equipo (1.45-1.65 GHz) carrera a carrera en países distintos; y la arquitectura completa que lleva la señal desde el coche hasta tu televisor, pasando por el Event Technical Centre, 54 km de cable por circuito y dos enlaces de fibra de 10 Gbps hacia el centro de distribución global.

Si te ha gustado el episodio, te agradecería que lo compartas con amigxs potencialmente interesadxs y que escribas una reseña en la plataforma de Podcast que utilices (si lo permite). Muchas gracias y nos escuchamos pronto.

Música de la entradilla de Iciar Ybarra (@gaudeamusica).

El secreto del núcleo de red de Digi

Los 7,7 millones de líneas móviles de Digi consumen al mes casi tantos datos como los 20,4 millones de Telefónica, su socio de red. Un usuario de Digi mueve de media 18,8 GB al mes, frente a los 8,5 GB de Telefónica, 7,6 GB de Orange o 4,7 GB de Vodafone.

¿Cómo aguanta Digi ese nivel de consumo ofreciendo, además, la tarifa de datos ilimitados más barata del mercado (10€/mes, o 5€ empaquetada con fibra) y sin los límites ocultos que sí tienen otras “ilimitadas”?

El secreto: el packet core propio

La mayor parte del núcleo de red de Digi usa software de Nokia, Ericsson o Huawei, como el resto del sector. Pero hay una pieza que Digi ha decidido programar por su cuenta: el packet core, el componente que da salida a Internet a todo el tráfico de datos de sus usuarios.

Lo cuenta la propia Digi en su folleto de salida a bolsa: los proveedores tradicionales cobran en función del número de suscriptores y el tráfico que generan, así que cuanto más consumen los usuarios, más factura el operador. Programar el packet core internamente le permite pasar a un modelo de pago por capacidad, como en banda ancha fija, en vez de pagar por cada gigabyte extra.

¿Y el RAN de Movistar?

Digi también explica cómo esto convive con su acuerdo con Movistar: en las zonas sin antena propia usa roaming nacional (el core de Movistar gestiona la sesión), y en RAN sharing reutiliza el hierro de las antenas de Movistar pero mantiene su propio core. La clave para que esto funcione con un core casero: el 3GPP estandariza la interfaz entre antena y núcleo de red precisamente para que sea independiente del fabricante.

¿Y las caídas de servicio?

Desarrollar un componente tan crítico por tu cuenta tiene riesgos. En el episodio repaso las caídas de Digi de diciembre de 2025 y abril de 2026 y matizo hasta qué punto están realmente relacionadas con esta pieza (spoiler: no está tan claro como parece).

Relacionado en RTS/CTS

Ep. 111. ¿Qué es una OMV? — el extremo opuesto: un operador sin ninguna red propia.

Enlaces

Artículo original en bandaancha.eu

Folleto de salida a bolsa de Digi (CNMV), pág. 135

5G de Digi ya mueve más tráfico que Vodafone

Digi comparte frecuencias con Movistar

Se disparan las quejas por los fallos del móvil de Digi (CNMC)

Si te ha gustado el episodio, te agradecería que lo compartas con amigxs potencialmente interesadxs y que escribas una reseña en la plataforma de Podcast que utilices (si lo permite). Muchas gracias y nos escuchamos pronto.

Música de la entradilla de Iciar Ybarra (@gaudeamusica).

¡Primer episodio de la cuarta temporada del podcast!

Te vas de vacaciones tranquilo y, a los pocos días, se te cuelga el minipc que sostiene medio homelab. Sin acceso físico y sin forma de reiniciarlo… hasta que acabas llamando al vecino para que entre en casa a darle al botón. En este episodio cuento ese pequeño desastre y cómo me llevó a rediseñar el setup para no volver a depender de nadie: reinicio remoto del minipc, fiable y sin cloud obligatorio.

Lo que cuento en el episodio:

El incidente: minipc colgado en plenas vacaciones y por qué me dejó medio homelab tirado.

El favor incómodo: pedirle a un vecino que entrara en casa a reiniciarlo a mano.

Por qué las soluciones “obvias” no me valían: Zigbee/Thread (el coordinador vive en el propio minipc, así que dependería justo de lo que quiero reiniciar) y vPro/AMT (imposible en un Intel N100).

La decisión: un enchufe inteligente WiFi colgado del SAI, con requisitos muy claros — fiable, que no corte la corriente al actualizar el firmware, pequeño para que quepa en la regleta del SAI, y con control local y en la nube a la vez.

El elegido: Shelly Plug S MTR Gen3.

Si te ha gustado el episodio, te agradecería que lo compartas con amigxs potencialmente interesadxs y que escribas una reseña en la plataforma de Podcast que utilices (si lo permite). Muchas gracias y nos escuchamos pronto.

Música de la entradilla de Iciar Ybarra (@gaudeamusica).