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.