Cómo elige nuestro DNS los servidores de nombres de su zona

Cuando añade un dominio a Yeap DNS, la consola le proporciona dos servidores de nombres (NS) que debe configurar en su registrador para delegarnos el dominio. Parece un paso sencillo, pero deben cumplirse varios requisitos a la vez. Este artículo explica cómo elegimos esos dos servidores de nombres.

Tres requisitos

1. Estables. Los servidores de nombres se escriben en los registros de delegación de su registrador y del registro del TLD. Si a una zona se le asignaran A y B hoy, y C y D mañana, tendría que modificar constantemente la configuración del registrador, y la resolución podría fallar durante la transición. Para una zona determinada, el resultado debe ser determinista.
2. Distribuidos. Si todas las zonas recibieran el mismo par, la carga se concentraría en unos pocos nodos y un problema con un servidor de nombres afectaría a todos. Las distintas zonas deben recibir combinaciones diferentes.
3. Con capacidad real de responder. Debe haber nodos en funcionamiento detrás de los servidores de nombres que se le asignan. Delegar una zona a un servidor de nombres sin nodos detrás envía las consultas al vacío.

El modelo de grupos

Como muchos servicios de DNS alojados, nuestro modelo tiene tres capas:

• Grupos: un conjunto de servidores de nombres. Cada plan apunta a un grupo, y los planes gratuitos y de pago utilizan grupos separados.
• Servidores de nombres: cada entrada de un grupo es un nombre de host NS, el nombre que finalmente introduce en su registrador.
• Nodos: las máquinas que ejecutan realmente el servicio DNS autoritativo. Varios nodos pueden atender un servidor de nombres, y sus registros de enlace (glue) apuntan a las direcciones de esos nodos.

Asignar servidores de nombres a una zona consiste en elegir dos servidores de nombres del grupo asociado al plan de la zona.

Aleatoriedad estable: ordenar por un hash con el nombre de zona como semilla

Para conseguir estabilidad y distribución a la vez, utilizamos una técnica clásica que, en esencia, es hashing de mayor peso aleatorio (hashing rendezvous, HRW):

1. Para cada servidor de nombres del grupo, calcular hash(zoneName + ":" + nameserverId);
2. ordenar por ese hash (usando el identificador en caso de empate, para que el orden sea siempre determinista);
3. seleccionar los dos primeros.

function pickNameservers(pool, zoneName, count = 2):
    if len(pool) <= count:
        return pool
    sort pool by (crc32(zoneName + ":" + ns.id), ns.id)
    return first count items of pool

Esto tiene varias propiedades útiles:

• Determinista: las únicas entradas son el nombre de la zona y el contenido del grupo. La misma zona obtiene la misma respuesta sin importar cuántas veces se calcule, sin depender de un estado aleatorio ni de la carga en el momento de la asignación.
• Distribución uniforme: las distintas zonas obtienen órdenes diferentes y aparentemente aleatorios, por lo que, en conjunto, se distribuyen de manera uniforme entre las combinaciones de servidores de nombres del grupo.
• Impacto reducido al ampliar: añadir un servidor de nombres a un grupo solo cambia el resultado de las zonas donde el nuevo servidor queda entre los dos primeros; el resultado de las demás zonas permanece igual. Esa es la principal ventaja de HRW frente al hashing simple basado en módulo.

Tenga en cuenta que el resultado se guarda al crear la zona. Los cambios posteriores en un grupo no modifican automáticamente los servidores de nombres de las zonas existentes, por lo que su delegación nunca cambia porque hayamos añadido capacidad. Donde el determinismo resulta especialmente útil es en que una zona creada por cualquier vía (la consola, la API o el aprovisionamiento automático después de comprar un plan) pasa por el mismo asignador y obtiene la misma respuesta.

Cuando no hay un nombre de zona que pueda usarse como semilla (en unas pocas rutas internas poco frecuentes), el asignador recurre a "primero los que alojan menos zonas", una forma determinista de balanceo de carga.

El estado es intención; el latido, un hecho

Antes de ordenar, hay un paso más importante: decidir qué servidores de nombres pueden formar parte del grupo de candidatos. Los llamamos aptos para prestar servicio, y cada servidor de nombres debe cumplir todas estas condiciones:

• el propio servidor de nombres está habilitado;
• tiene un nombre de host NS válido (no está vacío ni es un marcador de posición para pruebas);
• tiene al menos un nodo asociado cuyo estado es habilitado y que ha enviado un latido en los últimos 15 minutos.

La última condición merece una explicación más detallada. Un operador establece el campo de estado de un nodo en la base de datos; expresa "queremos que este nodo preste servicio". La intención no equivale a la realidad. Una máquina puede estar marcada como habilitada y, aun así, haber dejado de responder hace tiempo porque se reinstaló, cambió su red o sus credenciales dejaron de ser válidas. Un asignador que confiara solo en el campo de estado podría delegar zonas nuevas a un servicio que en realidad no existe.

Por eso nuestra regla es: el campo de estado es intención; la marca de tiempo del latido es un hecho. Cada nodo actualiza la hora de su última actividad cada vez que consulta la configuración, y los nodos que dejan de consultar se marcan automáticamente como desconectados al cabo de un tiempo. El asignador solo confía en los hechos.

Cómo obtienen los nodos los datos de su zona

Una vez hecha la asignación, los datos de la zona deben llegar a los nodos correctos. Nuestro plano de datos de DNS autoritativo es una compilación personalizada de CoreDNS que funciona mediante consultas periódicas:

• Cada zona tiene una versión de configuración, que también es el número de serie de su registro SOA. Cualquier cambio en un registro lo incrementa.
• Los nodos consultan periódicamente al plano de control, con autenticación, para obtener las versiones actuales. Cuando cambia una versión, descargan los nuevos datos de la zona, los escriben en un archivo de zona estándar y recargan.
• Cada nodo solo recibe las zonas asignadas a los servidores de nombres que atiende, no el conjunto completo de datos.
• Cuando se deshabilita o elimina una zona, el plano de control sigue enviando una señal de eliminación a los nodos durante un tiempo, y estos eliminan el archivo de zona local y dejan de responder por ella. Las zonas eliminadas no permanecen en algunos nodos.

Como el número de serie SOA es la versión de configuración, puede comprobar con dig si un servidor de nombres determinado tiene la última versión:

dig +short SOA example.com @your-nameserver-hostname

Si todos los servidores de nombres devuelven el mismo número de serie, todos tienen los datos más recientes.

Una lección sobre las zonas de infraestructura

Los propios nombres de host NS también deben resolverse, y sus registros de enlace y de dirección se encuentran en una zona de infraestructura dedicada, gestionada por el mismo sistema que las zonas de los clientes. Esto significa que su estado debe permanecer siempre habilitado: si se deshabilitara por error, la señal de eliminación haría que los nodos la eliminaran y afectaría a todas las zonas que dependen de esos servidores de nombres. Comprobamos expresamente este caso en las pruebas de extremo a extremo antes de activar las señales de eliminación, y ahora esas zonas están marcadas como residentes permanentes.

La lección se aplica a cualquier sistema que aloje sus propios componentes: cuando su plataforma aloja sus dependencias críticas, esas dependencias necesitan protección adicional.

Qué debe hacer

Como usuario, lo único que debe hacer después de añadir un dominio es configurar en su registrador los dos servidores de nombres que aparecen en la consola. La página de detalles de la zona muestra qué servidores de nombres tiene asignados y cuántos nodos activos tiene cada uno en ese momento, y la comprobación de NS de la consola le indica cuándo ha surtido efecto la delegación. El asignador y el flujo de sincronización se encargan del resto.