Los servidores DNS ya usan anycast. ¿Agregar más IP mejorará la escalabilidad?


9

RFC 1034 requiere que asignemos al menos dos direcciones IP para servidores DNS. Sin embargo, la redundancia ya se puede lograr con una sola dirección IP si usamos direccionamiento anycast. BGP anycast parece escalar bien en cientos o incluso miles de servidores.

Si es así, ¿por qué todavía necesitamos múltiples direcciones IP para servidores DNS? ¿Realmente mejora la redundancia (contribuye a la disponibilidad) si ya tenemos alguna transmisión, o es solo un mito?

¿Qué problemas y errores podemos esperar enfrentar si solo usamos una sola dirección IP?

Con eso, me refiero a omitir totalmente las direcciones DNS secundarias, o usar una IP falsa (por ejemplo 1.2.3.4) para la segunda dirección cuando algunas configuraciones requieren al menos dos.

Respuestas:


16

Una sola dirección IP de difusión ilimitada no le brinda la misma redundancia que dos direcciones IP de unidifusión en distintos prefijos IP.

A menudo, el problema más difícil para la redundancia no es cuando algo falla por completo, sino más bien cuando se está comportando mal lo suficiente como para pasar los controles de salud, pero en realidad no funciona.

He visto una configuración de DNS en cualquier caso en la que un servidor DNS se cayó, pero los paquetes aún se enrutarían a ese servidor DNS. Cualquier cosa que se encargara de anunciar el prefijo podría simplemente no ser consciente de que el servidor DNS se había caído.

Se vuelve aún más complicado si el servidor DNS en cuestión no es un servidor DNS autorizado, sino más bien un solucionador recursivo.

Tal solucionador recursivo necesitaría tener la dirección anycast para recibir consultas de clientes y direcciones unicast para consultar servidores DNS autorizados. Pero si las direcciones de unidifusión caen, podría verse fácilmente lo suficientemente saludable como para seguir siendo consultas enrutadas.

Anycast es una gran herramienta para la escalabilidad y la reducción de la latencia. Pero para la redundancia no debería estar solo.

Sin embargo, varios grupos redundantes de difusión ilimitada son una buena solución para la disponibilidad. Un ejemplo bien conocido es 8.8.8.8 y 8.8.4.4. Ambas son direcciones de difusión ilimitada, pero nunca deben enrutarse al mismo servidor DNS físico (suponiendo que Google hizo bien su trabajo).

Si tiene 10 servidores DNS físicos, puede configurarlos como 2 grupos con 5 servidores en cada grupo o 5 grupos con 2 en cada grupo. Desea evitar que un servidor DNS físico esté en varios grupos simultáneamente.

Entonces, ¿cuántas direcciones IP debe asignar? Necesita tener IPs que se puedan configurar como anycast independientemente uno del otro. Por lo general, eso significa que deberá asignar un / 24 completo de espacio de direcciones IPv4 o / 48 de espacio de direcciones IPv6 para cada grupo. Esto puede limitar la cantidad de grupos que puede tener.

Además, si estamos hablando de servidores autorizados, el DNS responde con todos sus registros NS y el pegamento A y AAAA debe caber en un solo paquete de 512 bytes. Para los servidores raíz, esto funcionó en 13 direcciones. Pero eso no incluía pegamento e IPv6, por lo que el número que alcanzaría sería menor.

Cada grupo debe estar lo más geográficamente distribuido posible. Si tiene 5 servidores en Europa y 5 en América del Norte y 2 IP de difusión ilimitada, no cree un grupo que abarque cada continente. Pones 2 de Europa en un grupo con 3 de América del Norte y los otros 5 en el otro grupo.

Si tiene más de 2 grupos de difusión ilimitada, puede permitir que un servidor físico esté temporalmente en más de un grupo. Pero nunca debe permitir que un servidor físico esté en todos los grupos al mismo tiempo.

Es posible combinar anycast y unicast, pero se debe tener cuidado. Si tiene IP para dos grupos, no los combinaría. Pero si solo tiene una única IP de difusión única para trabajar, puede tener sentido incluir también IP de unidifusión. El problema es que incluir IP de unidifusión no le proporcionará una buena latencia y equilibrio de carga.

Si tanto unicast como anycast ponen a disposición un servidor físico, puede arriesgarse a que los usuarios lleguen al mismo servidor que primario y secundario y pierdan acceso si se cae. Esto se puede evitar utilizando solo direcciones de unidifusión de servidores que no están en el grupo de difusión única o proporcionando siempre a los usuarios dos direcciones de unidifusión.

Cuantas más direcciones de unidifusión coloque en la mezcla, menos consultas se enviarán a la dirección de difusión ilimitada, y menos beneficios obtendrá de cualquier difusión en términos de latencia y escalabilidad.


¿Quiere decir que la mejor manera de lograr escalabilidad es emplear muchas direcciones de unidifusión secundarias (también conocido como la antigua forma de configurar ns1.domain, ns2.d, ns3.d ... ns300.d) en lugar de usar anycast?
Pacerier

@Pacerier No, eso no es lo que quiero decir. Lo aclararé en mi respuesta.
Kasperd

+1. Un error de enrutamiento puede incluso llevar tu unidifusión al infierno (callejón sin salida). Tener una segunda dirección separada significa que tiene más de un "boleto" para eso;)
TomTom

2
+1 Me gustaría agregar que agregar una dirección IP falsa como segunda dirección suena como una idea horrenda
llega

1
@Pacerier obtienes equilibrio de carga al usar múltiples direcciones de unidifusión. El problema es la latencia, los clientes simplemente no saben qué IP están cerca y cuáles están lejos. Tampoco puede escalar tan lejos. Solo puede usar unos 5 servidores, si desea que los registros de cola A y AAAA quepan en 512 bytes. La combinación de una difusión única y difusión múltiple múltiple es problemática para el equilibrio de carga, ya que es probable que obtenga más carga en las direcciones de difusión única que en la dirección de difusión ilimitada.
Kasperd

4

La mejor práctica es usar al menos dos direcciones de prefijos diferentes y darles un nombre bajo dos TLD diferentes. Ambas direcciones se pueden emitir en cualquier caso si lo desea. Tener solo una dirección IP le dará un único punto de falla. Si el enrutamiento a esa dirección no funciona (error de configuración, una instancia de anycast no funciona correctamente, el prefijo está siendo secuestrado, etc.), entonces todo su dominio quedará inalcanzable.

Cada dirección anycast requerirá al menos un prefijo /24IPv4 o /48IPv6 para ser enrutable en BGP. Los prefijos más pequeños (más largos) generalmente no se aceptarán en la tabla de enrutamiento global en muchos lugares.

Nunca jamás poner en una dirección IP falsa como un servidor DNS. Causará retrasos severos para los resolutores.


Peor aún, esa dirección IP "falsa" es la dirección de otra persona. Estarían recibiendo las consultas. Si se molestan con todo ese tráfico, podrían enviar respuestas con un TTL alto para que desaparezca por un tiempo.
Kasperd

@kasperd, ¿Qué pasa con las direcciones IP reservadas especiales que no pertenecen a nadie?
Pacerier

1
@Pacerier El uso del espacio de direcciones RFC 1918, 4193 o 6598 limitaría el daño. Pero todavía causaría que la resolución se ralentizara o incluso fallara.
Kasperd

3

El RFC 1034 solo indica que necesita dos servidores DNS. Este no es un requisito obligatorio, sino una recomendación, así que haz lo que quieras. De todos modos, si desea HA, a sus 2 servidores DNS se les puede asignar la misma IP usando anycast, y lo único que sus usuarios finales notarían cuando fallara un servidor DNS es una falta momentánea de conectividad a medida que la red se vuelve a conectar.

En resumen, sí, usar anycast es suficiente para cumplir con RFC 1034.


Hmm, si una sola dirección IP es todo lo que se necesita, ¿por qué Google ofrece dos direcciones ( 8.8.8.8y 8.8.4.4) para sus servidores DNS? Ya tienen cualquier difusión en el lugar, entonces ¿por qué no simplemente ofrecer una dirección 8.8.8.8?
Pacerier

1
¿Supongo que diría que no interrumpa la conectividad durante la convergencia de la red? ¿Porque son un jugador global y quieren asegurarse de tener el mayor alcance posible para eliminar cualquier posible punto de falla? No estoy del todo seguro, pero sé que no todos podemos ser google :)
Recurre
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.