Bunny DNS: GeoDNS con JavaScript por US$1 al mes

La factura bajó de US$5 a US$1 al mes

Un blog técnico migró su capa de entrega y DNS desde Amazon CloudFront y Route 53 hacia Bunny CDN y Bunny DNS, y su factura mensual pasó de US$5 a US$1. El ahorro no es la parte interesante: lo relevante es que el reemplazo incluye una función que AWS no ofrece, el DNS scriptable, que ejecuta un script de JavaScript en cada consulta para decidir qué direcciones IP devolver.

Para un founder, la señal es clara: la capa más aburrida del stack dejó de ser un commodity sin alternativas, y hoy se puede personalizar con código propio.

Cuánto cuesta Route 53 y qué ofrece Bunny DNS

El autor del análisis detalla el costo de mantener el DNS geográfico en AWS: US$0.50 por zona al mes, US$0.70 por millón de consultas de geolocalización, US$0.75 por healthcheck al mes y US$1 adicional al mes por la clave KMS necesaria para firmar las zonas con DNSSEC.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Del otro lado, Bunny DNS es prácticamente gratis para hasta 500 dominios y permite respuestas scriptables. La empresa detrás, bunny.net, es europea y tiene su sede en Eslovenia. Su CDN arrancó en 2015 como BunnyCDN y sumó soporte de IPv6 en 2017; la oferta de DNS llegó en 2022 y recientemente bajó su costo a casi cero.

¿Cómo funciona el GeoDNS scriptable en la práctica?

El blog corre sobre siete máquinas virtuales NixOS distribuidas en París, Núremberg, Ashburn, Singapur, San José, São Paulo y Sídney. El script devuelve las IP de los dos servidores más cercanos al usuario y deja que el navegador use el segundo si el primero no responde. La lógica se apoya en un helper del proveedor, RoutingEngine.getClosestServer(), que devuelve el servidor vivo más próximo.

El problema de devolver dos servidores: el caso de Buenos Aires

Un usuario en Buenos Aires recibe São Paulo (1000 millas, 30 ms de RTT) y Ashburn (5200 millas, 140 ms de RTT). Como la mayoría de los resolvers aleatorizan el orden de las respuestas, ese usuario puede terminar descargando la página desde Ashburn.

Devolver solo el servidor más cercano resuelve la latencia, pero abre otro problema: si ese servidor cae, el navegador no tiene alternativa hasta que expire la caché DNS. Es una ventana corta de indisponibilidad, incluso con un TTL bajo.

HTTPS records: la solución ideal que los navegadores todavía no soportan

Los registros HTTPS (definidos en el RFC 9460) permiten indicar prioridades, puerto alternativo y protocolo de aplicación, HTTP/2 o HTTP/3, para que el navegador contacte primero el servidor más cercano y haga fallback al siguiente si el primero no está disponible. En teoría, resuelve latencia y disponibilidad al mismo tiempo.

En la práctica, Chrome ignora cualquier registro cuyo target no sea un punto, y Bunny DNS no devuelve las IP de los registros intermedios en la sección adicional, lo que obliga a una segunda consulta del resolver. El autor concluye que la tecnología sigue siendo demasiado nueva para este caso de uso.

La solución híbrida: dos IP o una, según la distancia

Como compromiso, el script devuelve los dos servidores más cercanos solo si están a una distancia similar. Si el segundo está al doble de distancia y a más de 1000 millas del primero, devuelve únicamente el más cercano con un TTL de 2 minutos; en caso contrario, devuelve ambos con un TTL de 1 hora.

La verificación con la herramienta Doggo lo confirma: desde Chicago la respuesta trae solo el servidor de Ashburn con un TTL de 120 segundos, mientras que desde México llegan Ashburn y San José con un TTL de 3600 segundos.

¿Qué pasa con los certificados? Ahí Bunny DNS no alcanza

Route 53 también servía la zona acme.luffy.cx, usada para resolver los desafíos DNS-01 de ACME con Let’s Encrypt. Bunny DNS no permite restringir el acceso a una sola zona con una política granular, así que esa parte se migró a Hickory DNS, un servidor DNS escrito en Rust que soporta firmas DNSSEC automáticas y actualizaciones dinámicas.

Como Bunny DNS tampoco puede publicar registros DS, la zona padre se aloja en deSEC, un servicio gratuito operado por una organización sin fines de lucro con sede en Berlín. La lección es que el reemplazo no fue un proveedor por otro, sino un rediseño por capas.

Lo que todavía no cierra

HTTP/3: el CDN de bunny.net no lo soporta. Soporte respondió que están trabajando en ello, sin fecha estimada.
Registros DS: no se pueden publicar, lo que complica cerrar la cadena de DNSSEC.
Helper solo IPv4: RoutingEngine.getClosestServer() no cubre IPv6, un detalle que el código completo del autor tiene que sortear.
Privacidad: el autor desactiva el logging para no recolectar información personal, aunque señala que no queda claro qué guarda CloudFront en sus propios logs cuando el logging está apagado.
Rendimiento: según las métricas de CrUX, el desempeño está a la par de AWS, pero la configuración final, incluido el servidor de Sídney, se terminó a finales de octubre y todavía falta más data para confirmarlo.

¿Qué significa esto para tu startup?

1. Revisa cuánto pagas por funciones que hoy son casi gratis. Si tu stack usa Route 53 con geo-routing y varios healthchecks, la suma de zona, consultas de geolocalización, healthchecks y clave KMS puede pesar más de lo que parece. El ejercicio de este blog, de US$5 a US$1 al mes, se hace en una tarde de análisis de costos.

2. Inventaría las funciones de las que dependes antes de migrar. El caso muestra que un proveedor barato puede fallar en detalles críticos: no publicar registros DS rompe la cadena de DNSSEC, la ausencia de HTTP/3 afecta la latencia en redes móviles y un helper limitado a IPv4 deja fuera a los usuarios de IPv6. Revisa esos tres puntos antes de mover zonas en producción.

3. Divide el problema en lugar de buscar un único proveedor. El autor no reemplazó todo con Bunny: dejó el DNS de producción en Bunny, movió las zonas de certificados a un DNS propio y delegó la zona padre a un tercero. Para una startup, esa separación reduce el riesgo de depender de una sola pieza para todo.

4. Lleva la lógica de routing a tu infraestructura como código. Bunny tiene un provider de Terraform, y el autor gestiona el estado con CDK Terrain y OpenTofu. Así el geo-routing queda versionado en el repositorio en lugar de vivir en el panel de un proveedor.

5. Mide antes de cantar victoria. El TTL corto resuelve el failover, pero multiplica la cantidad de consultas y puede encarecer el servicio si el proveedor cobra por query. Y un cambio de proveedor de DNS tarda en estabilizarse: el propio autor advierte que necesita más tiempo de datos.

Conclusión

La migración de este blog no es una anécdota de ahorro: es un ejemplo de cómo la capa de DNS pasó de ser un costo fijo intocable a un componente programable. El DNS scriptable permite resolver con unas pocas líneas de JavaScript lo que antes exigía un balanceador o un servicio gestionado caro. Para una startup, la jugada inteligente no es copiar el stack del vecino, sino auditar qué funciones usas de verdad y cuánto pagas por cada una. Si el geo-routing es una de ellas, hoy tienes alternativas más baratas y más flexibles que hace tres años.