¿Cómo se mantiene 8.8.8.8 * siempre * vivo?

Sé cómo puede administrar la redundancia del centro de datos si hay un servidor DNS en funcionamiento que puede apuntar a cualquier sitio de trabajo de su empresa: hay VRRP, WAN múltiple, etc., etc. ¿Pero cómo se mantienen en línea los servidores DNS? Es el primer golpe cuando alguien se conecta al servicio y realmente no se puede aprovisionar. Me refiero por ejemplo 8.8.8.8o 8.8.4.4. No puedo recordar que estén deprimidos. Siempre. ¿Cómo logran los ISP mantener tales IP siempre en línea?

Sé que probablemente sea una pregunta muy amplia, pero me gustaría escuchar solo los nombres de protocolos / técnicas que se pueden usar para eso. Puedo leer detalles sobre ellos por mi cuenta.

En primer lugar, VRRP no depende del DNS de ninguna manera. Para la redundancia dentro de un solo sitio, puede ejecutar servidores DNS en una dirección VRRP compartida muy bien.

Pero como otros han mencionado en los comentarios, los servicios también usan enrutamiento anycast , lo que esencialmente significa que la misma dirección IP existe en varios lugares del mundo. Cuando un sitio entero se cae, las rutas en todo el mundo se recalculan para que sus paquetes terminen yendo a otro sitio de trabajo.

Un ejemplo mejor que el DNS público de Google sería la raíz de los servidores DNS - aquellos que sirven a los .punteros de la zona y mantenga presionado para com, org, eu, y así sucesivamente - porque tienen un mapa de todos los casos de las 13 direcciones lógicas. ¡La "L" de ICANN cuenta con 160 sitios diferentes!

Tenga en cuenta que anycast no tiene nada que ver con los round-robins basados ​​en DNS (donde el mismo nombre tiene varias direcciones). Anycast se realiza esencialmente mintiendo al protocolo de enrutamiento.

Internet usa BGP para intercambiar información de enrutamiento entre organizaciones.

BGP admite de forma inherente seleccionar lo mejor de varias rutas hacia la misma red, según varios criterios. Por ejemplo, el mismo cliente podría tener enlaces ascendentes redundantes al mismo ISP (anunciando dos rutas que difieren solo en peso / preferencia). O el cliente puede tener enlaces ascendentes a través de varios ISP, y todos seleccionarán su ruta preferida (principalmente la ruta AS más corta), esa es la esencia de la "WAN" verdadera "múltiple".

Multihoming

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter--+            │
             ¦    │             ¦--DNSserver │
client 2 ---ISP---│--BGProuter--+            │
                  └──────────────────────────┘

Sin embargo, BGP solo dirige el tráfico a las puertas de entrada, pero no le importa lo que suceda más allá de eso. Entonces, si configuras internamente ambas rutas hacia el mismo servidor, obtienes multihoming. Pero si cada "entrada" conduce a un servidor diferente (configurado para la misma IP), obtendrá cualquier difusión.

Anycast... kind of?

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    │                          │
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

Es importante destacar que esto también significa que a BGP no le importa si el AS no es contiguo en absoluto. Para obtener redundancia en todo el mundo, simplemente anuncie la misma red desde múltiples ubicaciones físicas: si conecta esas ubicaciones juntas (para que enruten esa red a un solo lugar), obtendrá múltiples conexiones; si son islas, obtienes anycast.

Anycast

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    └──────────────────────────┘
             ¦
             ¦    ┌────────[AS 65535]────────┐
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

(Para el caso, ni siquiera necesita ser el mismo AS, por ejemplo, los relés 6to4 son ejecutados por múltiples organizaciones independientes, cada una de ellas anunciando su propia ruta hacia 192.88.99.0/24).

Advertencias:

• Anycast proporciona redundancia, pero no balanceo de carga. Una vez que BGP converge, cada enrutador habrá elegido una única ruta preferida (u ocasionalmente algunas) y continuará usándola hasta que cambie la red.

• Sin embargo, no puede predecir cuánto tiempo las rutas permanecerán estables, por lo que cualquier servicio con estado de difusión puede ser complicado. DNS se sale con la suya debido a que no tiene estado y utiliza principalmente UDP (EDNS redujo la necesidad de conexiones TCP).

• Debe haber coordinación entre el servicio real y el enrutador BGP, de modo que la ruta se retire si el servicio falla.

Ver también "Historia de 4.2.2.2. ¿Cuál es la historia?" en la lista de correo NANOG: post 1 , post 2 .

Una forma de lograr eso es usar equilibradores del lado del servidor . Cuando se conecta a la puerta de enlace en la IP 8.8.8.8, distribuirá la solicitud a un servidor gratuito dentro del sistema. Como resultado, cuando un servidor muere, no derriba todo el sistema.

Para los servicios de Internet, el equilibrador de carga del lado del servidor suele ser un programa de software que escucha en el puerto donde los clientes externos se conectan para acceder a los servicios. El equilibrador de carga reenvía las solicitudes a uno de los servidores "de fondo", que generalmente responde al equilibrador de carga. Esto permite que el equilibrador de carga responda al cliente sin que el cliente sepa nunca sobre la separación interna de funciones. También evita que los clientes se pongan en contacto directamente con los servidores de fondo, lo que puede tener beneficios de seguridad al ocultar la estructura de la red interna y evitar ataques en la pila de red del núcleo o servicios no relacionados que se ejecutan en otros puertos.

Algunos equilibradores de carga proporcionan un mecanismo para hacer algo especial en caso de que todos los servidores de fondo no estén disponibles. Esto puede incluir el reenvío a un equilibrador de carga de respaldo o mostrar un mensaje sobre la interrupción.

También es importante que el equilibrador de carga en sí no se convierta en un solo punto de falla. Por lo general, los equilibradores de carga se implementan en pares de alta disponibilidad que también pueden replicar datos de persistencia de sesión si la aplicación específica lo requiere. [5]