Anycast DNS explicado

Lo normal es que una dirección IP identifique a una máquina concreta, accesible por una ruta de red concreta. Anycast rompe esa suposición a propósito: la misma dirección IP se anuncia, a la vez, desde muchas ubicaciones físicamente separadas por todo el mundo. El enrutamiento de internet entrega entonces cada solicitud a la ubicación anunciante que esté topológicamente más cerca del remitente: no necesariamente la más cercana en distancia física, sino la más cercana por ruta de red.

Por qué la infraestructura DNS depende tanto de esto

Los resolvedores públicos como 1.1.1.1 y 8.8.8.8 son direcciones anycast. Cuando consultas 1.1.1.1 desde Tokio y otra persona consulta la misma dirección desde Berlín, en realidad cada uno llega a un servidor físico distinto (el más cercano en la red), aunque ambos escriben exactamente la misma IP en su configuración. Eso es lo que permite que una única IP fácil de recordar ofrezca una latencia baja y constante en todo el mundo, en lugar de que todos se enruten a un único centro de datos físico sin importar dónde estén.

• Resiliencia: si una ubicación anycast se cae, el enrutamiento simplemente pasa a la siguiente más cercana, a menudo sin que el cliente lo note.
• No es exclusivo del DNS: las CDN y otros servicios sensibles a la latencia usan la misma técnica de fondo.

La conclusión práctica

No hace falta configurar nada de otra manera para beneficiarte de anycast: ocurre por completo en la capa de enrutamiento de red, de forma invisible para la aplicación que hace la consulta. Merece la pena conocerlo sobre todo porque explica por qué un gran resolvedor público puede mantenerse rápido y disponible en todo el mundo sin que tengas que elegir un endpoint específico de una región, como sí harías con una base de datos en la nube o una instancia de cómputo.

BGP es el mecanismo que hay detrás de «topológicamente más cerca»

«Más cerca por ruta de red» no lo decide nada que mida la distancia física en tiempo real. Cada red que anuncia una dirección anycast lo hace mediante BGP, el protocolo de enrutamiento que une las redes individuales de internet, y cada router del camino elige la ruta hacia esa dirección que en ese momento parece más corta según las métricas propias de BGP: normalmente, la de menos saltos de red, no la de menos kilómetros. En la práctica esto suele coincidir con la proximidad física, pero no a la perfección: una solicitud puede acabar enrutada a una ubicación algo más lejana si esa ruta resulta más corta en términos de BGP, sobre todo en torno a caídas de red o acuerdos de peering poco habituales.

Por qué anycast no funciona bien para todo

Anycast encaja muy bien con intercambios cortos y sin estado, como una única consulta DNS y su respuesta: no se pierde nada si un paquete posterior acaba enrutado a un servidor físico distinto del primero. Encaja mal con conexiones de larga duración y con estado: si la ruta de red cambia a mitad de la conexión (una oscilación de rutas o un cambio de peering), una sesión TCP que pasa a otro endpoint físico distinto del que la inició simplemente se rompe, porque el nuevo servidor no sabe que esa conexión ha existido. Esto explica en parte por qué anycast se asocia tanto con el DNS y con otros protocolos de solicitud-respuesta basados en UDP, y se usa mucho menos para cosas como una conexión de base de datos de larga duración o una transmisión de vídeo.