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

9

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.

Lapsio
fuente
3
Lea sobre Anycast. En resumen: hay varios hosts con la misma dirección IP. Así es como funcionan CloudFlare, Google, YouTube y otras grandes redes.
GiantTree
google.com y cloudflare tienen múltiples IP. Se devuelven varias direcciones IP en la consulta DNS dependiendo de la ubicación, etc. Y no puede usar "múltiples registros A" u otra redundancia basada en DNS porque es el propio DNS. ¿Puedes tener múltiples sitios / hosts bajo una sola IP? ¿Usan algo como multi ISP BGP?
Lapsio
2
Es Anycast, como escribió GiantTree. Anycast no involucra DNS.
Daniel B
IPv4 no es compatible con anycast de forma nativa. Según Wikipedia, parece que se realiza utilizando BGP si lo entiendo correctamente. en.wikipedia.org/wiki/Anycast
Lapsio
Para los servicios de datagramas, no se necesita soporte especial para anycast , solo sucede como resultado de que cada enrutador realiza sus propios cálculos de ruta de ruta más corta. BGP tampoco "admite" cualquier difusión nativa (las ve como rutas de unidifusión) y, sin embargo, es una forma común de hacerlo en todo Internet.
user1686

Respuestas:

10

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 .

usuario1686
fuente
"Cómo hacer que se acepte tu respuesta en menos de 60 segundos con este truco extraño"
usuario1686
¿Qué son las "islas" a las que se refiere antes del último párrafo? ¿Solo sitios no conectados?
Lapsio
Sí, partes de su red que no están interconectadas entre sí o con el resto. (Aunque eso es solo un ejemplo. También es posible implementar anycast interno dentro de una gran red interconectada, nuevamente engañando a los protocolos de enrutamiento).
user1686
0

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]

phuclv
fuente
Sí, pero los equilibradores de carga no son un punto único de falla solo si utilizan alguna otra técnica de alta disponibilidad como, por ejemplo, VRRP, protocolos de enrutamiento, etc. Pero, de nuevo, VRRP o IGP son soluciones LAN. Quiero decir, digamos que falla la conexión WAN del proveedor de servicios de Internet al centro de datos. La compañía, por supuesto, tiene WAN múltiple, por lo que siempre que la puerta de enlace del sitio pueda cambiar a un enlace WAN diferente, está bien, pero mantener la misma IP sigue siendo un problema. En caso de que DNS esté disponible, está bien: múltiples A o AAAA recodifican y listo. Pero cuando se trata del servidor DNS en sí, la única solución es anycast / BGP entre múltiples ISP.
Lapsio
Me refería más bien a las soluciones de alta disponibilidad de WAN después de la puerta de enlace. Cuando el sitio de toda la empresa no es accesible desde el mundo debido a un desastre de ISP. 8.8.8.8 no puede asumir que ISP funcionará. No puede confiar en una sola compañía cuando literalmente todo el mundo depende de su servicio
Lapsio