RFC 1034requiere que asignemos al menos dos direcciones IP para los servidores DNS. Sin embargo, la redundancia ya se puede lograr con una única dirección IP si utilizamos direcciones anycast. BGP anycast parece escalar bien a cientos o incluso miles de servidores.
Si es así, ¿por qué todavía necesitamos varias direcciones IP para los servidores DNS? ¿Realmente mejora la redundancia (contribuye a la disponibilidad) si ya tenemos anycast implementado, o es solo un mito?
¿Qué problemas y errores podemos esperar enfrentar?¿Si solo usamos una única dirección IP?
Con esto me refiero a omitir por completo 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.
Respuesta1
Una única dirección IP anycast no proporciona la misma redundancia que dos direcciones IP unicast con prefijos IP distintos.
A menudo, el problema más difícil de la redundancia no es cuando algo falla por completo, sino cuando se comporta mal lo suficiente como para pasar las comprobaciones de estado, pero en realidad no funciona.
He visto una configuración de DNS anycast en la que un servidor DNS fallaba, pero los paquetes aún se enrutaban a ese servidor DNS. Quienquiera que se encargara de anunciar el prefijo podría simplemente no darse cuenta de que el servidor DNS 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 un solucionador recursivo.
Un solucionador recursivo de este tipo necesitaría tener tanto la dirección anycast para recibir consultas de los clientes como direcciones unicast para consultar servidores DNS autorizados. Pero si las direcciones de unidifusión fallaran, fácilmente podría parecer 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 en lo que respecta a la redundancia, no debería ser el único.
Sin embargo, múltiples grupos anycast redundantes 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 anycast, pero nunca deben enrutarse al mismo servidor DNS físico (suponiendo que Google haya hecho 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 IP deberías asignar? Debe tener direcciones IP que se puedan configurar como anycast independientemente unas de otras. Por lo general, eso significa que deberá asignar un /24 completo de espacio de direcciones IPv4 o un /48 de espacio de direcciones IPv6 para cada grupo. Es muy posible que esto limite la cantidad de grupos que puede tener.
Además, si hablamos de servidores autorizados, la respuesta DNS con todos sus registros NS y el pegamento A y AAAA debería caber en un solo paquete de 512 bytes. Para los servidores raíz esto resultó en 13 direcciones. Pero eso no incluye pegamento ni IPv6, por lo que el número que alcanzarías sería menor.
Cada grupo debe estar lo más distribuido geográficamente posible. Si tiene 5 servidores en Europa y 5 en Norteamérica y 2 IP anycast, no crea 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 Anycast, puede permitir que un servidor físico esté temporalmente en más de un grupo. Pero nunca debes 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 las combinaría. Pero si solo tiene una IP de difusión única con la que trabajar, puede tener sentido incluir también IP de unidifusión. El problema es que incluir IP de unidifusión no le brindará una latencia ni un equilibrio de carga tan buenos.
Si un servidor físico está disponible mediante unidifusión y cualquier difusión, puede correr el riesgo de que los usuarios lleguen al mismo servidor como primario y secundario y perder el acceso si deja de funcionar. Esto se puede evitar utilizando únicamente direcciones de unidifusión de servidores que no estén en el grupo anycast o proporcionando siempre a los usuarios dos direcciones de unidifusión.
Cuantas más direcciones de unidifusión incluyas en la combinación, menos consultas se enviarán a la dirección de anycast y menos beneficios obtendrás de anycast en términos de latencia y escalabilidad.
Respuesta2
La mejor práctica es utilizar al menos dos direcciones con prefijos diferentes y darles un nombre bajo dos TLD diferentes. Ambas direcciones pueden ser anycast 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 que no funciona correctamente, el prefijo está secuestrado, etc.), entonces todo su dominio se vuelve inalcanzable.
Cada dirección anycast requerirá al menos un prefijo /24IPv4 o /48IPv6 para poder enrutarse en BGP. En muchos lugares, los prefijos más pequeños (más largos) generalmente no se aceptan en la tabla de enrutamiento global.
Nuncaalguna vezintroduzca una dirección IP falsa como servidor DNS. Causará graves retrasos para los resolutores.
Respuesta3
El RFC 1034 solo establece que se necesitan 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 falla un servidor DNS es una falta momentánea de conectividad a medida que la red vuelve a converger.
En resumen, sí, usar Anycast es suficiente para cumplir con RFC 1034.