Introducción
La dependencia de servicios gestionados en AWS suele generar una inercia técnica difícil de romper, incluso cuando el costo supera ampliamente el beneficio operativo. Para un blog personal con siete nodos globales, la factura mensual de Route 53 combinada con CloudFront representaba un gasto desproporcionado por funcionalidades básicas: geolocalización DNS y entrega de assets estáticos. El cambio hacia BunnyCDN no fue solo una decisión financiera, sino una reevaluación de cómo el DNS puede ser programable sin depender de la infraestructura cerrada de Amazon.
El problema concreto que resuelve esta migración es la rigidez del enrutamiento geográfico tradicional frente a la necesidad de alta disponibilidad local. Al dejar Route 53, se pierde la integración nativa con healthchecks avanzados y la facilidad de gestión de IAM, pero se gana control total sobre la lógica de resolución mediante JavaScript. Este análisis desglosa las decisiones técnicas detrás de abandonar el ecosistema AWS por un proveedor europeo, enfocándose en los trade-offs reales de latencia, configuración de DNSSEC y compatibilidad con protocolos modernos como HTTP/3.
Qué ocurrió
El autor operaba su infraestructura bajo un modelo clásico: CloudFront para la entrega de contenido estático (activo desde 2011) y Route 53 para el enrutamiento geográfico consciente del cliente (desde diciembre de 2021). Los costos de Route 53 escalaban rápido; US$0.50 por zona mensual, más US$0.70 por millón de consultas de geolocalización y US$0.75 por healthcheck, hacían inviable monitorear múltiples dominios secundarios como los usados en haproxy.debian.net. La alternativa encontrada fue BunnyCDN, una empresa eslovena que ofrece DNS casi gratuito para hasta 500 dominios y permite ejecutar scripts JavaScript en cada consulta DNS.
La migración implicó reemplazar la lógica de enrutamiento inteligente de AWS por un script personalizado que evalúa la proximidad del cliente a siete servidores NixOS distribuidos (París, Núremberg, Ashburn, Singapur, San José, São Paulo y Sídney). El objetivo era devolver las IP de los dos servidores más cercanos para permitir fallback automático si el nodo prioritario falla. A diferencia de Route 53, donde la salud del endpoint se gestionaba mediante checks externos costosos, aquí la disponibilidad se verifica vía ping ICMP dentro de la lógica del script o mediante la API interna de Bunny, reduciendo la complejidad operativa pero introduciendo nuevas limitaciones en la resolución moderna.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de infraestructura, este caso ilustra el potencial de «DNS as Code» más allá de las herramientas tradicionales como Terraform o Route 53. La capacidad de ejecutar JavaScript en el borde del DNS permite lógicas de balanceo de carga basadas en latencia real y estado de salud, algo que antes requería appliances dedicados o configuraciones complejas de HAProxy en la capa de aplicación. Sin embargo, el impacto en seguridad es mixto: mientras Bunny simplifica la gestión de claves al eliminar la necesidad de KMS para firma DNSSEC (un ahorro directo de US$1/mes por clave), introduce riesgos si no se controlan adecuadamente los permisos de escritura en los registros dinámicos.
Desde la perspectiva de SRE, el cambio afecta directamente los indicadores de disponibilidad y latencia. La eliminación de healthchecks proactivos de AWS significa que la detección de fallos depende de la respuesta del script o de mecanismos externos más lentos. Además, la falta de soporte para HTTP/3 en BunnyCDN al momento de la migración limita las mejoras de rendimiento esperadas en conexiones móviles con alta latencia y pérdida de paquetes, un factor crítico para métricas de Core Web Vitals. Para equipos cloud nativos, esto sugiere que los proveedores alternativos pueden ser viables para cargas de trabajo estáticas o semi-estáticas, pero requieren validación exhaustiva de soporte de protocolos modernos antes de migrar servicios críticos.
Detalles técnicos
La implementación del enrutamiento geográfico utiliza la función RoutingEngine.getClosestServer() proporcionada por Bunny DNS. Esta API devuelve la IP del servidor vivo más cercano al usuario, determinado por la subred EDNS (Extension Mechanisms for DNS) expuesta por el resolver del cliente. El script original tenía una limitación crítica: solo soportaba IPv4. Para solventar esto, se desarrolló una versión mejorada que gestiona manualmente la resolución de IPv6 y valida la existencia de servidores vivos antes de devolver respuestas vacías o incompletas.
Un desafío técnico significativo surgió con el registro HTTPS definido en la RFC 9460. Este registro permite a los navegadores modernos obtener información adicional como puertos alternativos y protocolos de aplicación (HTTP/2, HTTP/3) junto con prioridades de fallback. La intención era usar este registro para indicar al navegador que intente primero el servidor más cercano y luego el segundo. Sin embargo, Chrome ignora cualquier registro HTTPS cuyo objetivo no sea el dominio raíz en ciertas configuraciones, y Bunny DNS no devuelve las direcciones IP adicionales en la sección additional del paquete DNS para los subdominios de preferencia (first.geo, second.geo). Esto obliga al resolver a realizar dos consultas: una para el registro HTTPS y otra para resolver el CNAME o A record asociado, incrementando la latencia inicial.
Para gestionar los desafíos ACME (Let’s Encrypt), se reemplazó Route 53 por Hickory, un servidor DNS escrito en Rust que soporta actualizaciones dinámicas y firma DNSSEC automática. Dado que Bunny DNS no permite publicar registros DS en una zona delegada, la zona raíz luffy.cx se aloja en deSEC (un servicio sin fines de lucro en Berlín) para gestionar la cadena de confianza DNSSEC. La configuración de Hickory es mínima y utiliza el protocolo DNS UPDATE para que Lego (el cliente ACME) inserte los tokens de validación.
Qué deberían hacer los administradores y equipos técnicos
Antes de migrar desde Route 53 o CloudFront, auditen sus costos actuales desglosados por concepto: consultas, healthchecks y claves KMS. Si el volumen de tráfico es bajo o medio, proveedores como Bunny pueden ofrecer ahorros superiores al 90%. Sin embargo, verifiquen la compatibilidad con HTTP/3 si su audiencia principal es móvil; la falta de soporte en BunnyCDN puede degradar las métricas de TTFB (Time to First Byte).
Implementen scripts DNS con lógica de fallback robusta. No confíen únicamente en el servidor más cercano si no tienen healthchecks externos rápidos. El código debe manejar explícitamente los casos donde getClosestServer devuelve null o donde hay pocos servidores vivos disponibles para evitar que el navegador reciba una respuesta vacía y falle silenciosamente. Utilicen herramientas como Doggo (un resolver DNS moderno escrito en Rust) para validar la propagación de registros A, AAAA y HTTPS desde diferentes ubicaciones geográficas simuladas.
# Ejemplo de validación con Doggo para verificar resolución geográfica
doggo bernat.ch a +local=ashburn +dns=bunny-dns-ipPara la gestión de infraestructura como código, exploren CDK Terrain o OpenTofu en lugar de depender exclusivamente del proveedor nativo. Esto permite definir el estado objetivo en TypeScript y desplegarlo mediante backends más flexibles, reduciendo el lock-in vendor. Asegúrense de que su cliente ACME sea compatible con servidores DNS autogestionados como Hickory antes de eliminar las integraciones IAM de AWS para los desafíos DNS-01.
Conclusión
La migración desde AWS a BunnyCDN demostró ser viable y rentable, pero no está exenta de fricciones técnicas. La capacidad de scriptar el DNS ofrece una flexibilidad que Route 53 no iguala sin costes adicionales significativos, permitiendo lógicas de enrutamiento personalizadas para topologías globales pequeñas. No obstante, la madurez de los protocolos modernos (HTTP/3 y registros HTTPS complejos) sigue siendo un talón de Aquiles para proveedores alternativos frente a los gigantes cloud. Para equipos con recursos limitados, el equilibrio entre costo y funcionalidad favorece esta dirección, siempre que se implementen estrategias de mitigación para las lagunas en soporte DNSSEC y resolución avanzada.
Fuentes
https://vincent.bernat.ch/en/blog/2026-bunny-geodns
https://research.google/blog/
https://linkerd.io/blog/