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

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.

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.

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.

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.