Resolución DNS vs registro NS TTL

Question

Cuando un solucionador de DNS busca un dominio/zona para un servidor de nombres autorizado, ¿toma los 6 registros y los recorre?

Sí, un servidor de nombres recursivo adecuado tiene en cuenta todos los servidores de nombres e intentará consultar cada vez el más rápido.

Un algoritmo aproximado es algo así como:

desde un inicio en frío (sin caché), pruébelos todos al azar, registre qué tan rápido responden (es posible que deba separar el caso UDP del caso TCP allí)
Después de un tiempo, comience a usar con más frecuencia el más rápido según las respuestas anteriores.
pero tenga en cuenta que debe asegurarse de no quedarse indefinidamente con ningún servidor de nombres determinado, sino que también debe probar "de vez en cuando" los demás. ¿Por qué? Porque la topología de la red puede cambiar, al igual que los propios servidores de nombres. ns3podría ser el más rápido hoy para su punto de vista específico, pero tal vez mañana lo sea ns5; así que tienes que usar el más rápido, pero no siempre, solo para asegurarte de poder descubrir automáticamente cualquier otro más rápido que el que crees que es el más rápido en este momento.

Si un solucionador utiliza el primer servidor NS

Deténgase aquí. Los registros vienen en un conjunto, no en una lista. Es decir, no existe un orden inherente en el DNS. Por supuesto, hay un orden en la representación del cable o de la pantalla, pero no proviene del protocolo.

Los conjuntos de discos son bolsas: obtienes discos, sin pedidos. De hecho, puede ver que muchos servidores de nombres, para exactamente la misma consulta, si hay varios registros en la respuesta, ordenarán los registros de manera diferente cada vez que realice la consulta, exactamente para combatir los sistemas cliente que solo tomarían en cuenta el primer elemento y ignorar a los demás.

cuando ese servidor de nombres autorizado no responde

Consulte el algoritmo anterior: si uno de los servidores de nombres del NSconjunto no responde, puede considerar que es lo mismo que "responder más lento desde cualquier otro". El DNS del cliente tiene tiempos de espera, por lo que no esperará infinitamente, pero marque que este servidor de nombres específico es demasiado lento y cambiará a otros. Entonces, la primera vez incurres en una penalización porque el sistema tiene que intentar contactar con ese servidor de nombres, esperar un poco (unos segundos), volver a intentarlo y en algún momento dejar de usar ese servidor de nombres. Después de esa rampa, utilizará los otros servidores de nombres y las cosas serán rápidas. Pero la primera vez que descubres que un servidor de nombres determinado es lento o no responde al intentar contactarlo, no puedes inferir el problema sin intentarlo.

¿Eso significa que necesito establecer un TTL corto para los registros NS?

Quizás, pero en su mayor parte es irrelevante. ¿Por qué? Porque sus NSregistros se publican en la zona principal de su dominio, para garantizar la delegación de DNS. Por supuesto, se publican allí con un TTL, ya que todos los registros tienen un TTL adjunto, pero se publican en una zona que usted no controla, por lo que NO puede elegir sus valores TTL.

(Hay una discusión complicada/no completamente terminada aquí sobre esos registros, NSque existen en dos partes: el padre y el niño, con la pregunta "¿cuál tiene realmente autoridad"? Si el padre tiene un TTL de 1 semana en NSlos registros y usted en su zona los mismos NSregistros tienen un TTL de 1 segundo, ¿qué debería hacer el servidor de nombres recursivo? Se podría llegar a la conclusión de que normalmente la parte secundaria de la delegación TIENE autoridad, por lo que 1 segundo gana aquí en la práctica en múltiples implementaciones de DNS; están "centrados en los padres", es decir, utilizan los datos del lado de los padres, por lo que 1 semana gana allí)

Los TTL son siempre una compensación. Una vez que lo saben, algunas personas inmediatamente llegan a la conclusión de que las cosas funcionan mejor con TTL muy bajos... lo cual es cierto en algunos casos y no tanto en otros. Los cachés son buenos, si no estuvieran allí (también conocido como: no usar TTL lo suficientemente grandes), no eres resistente a cualquier problema pequeño, eso haría que todo desapareciera porque los cachés ya habrían caducado los nombres.

Además, el valor TTL no tiene (o tiene poco) impacto para el algoritmo anterior al recorrer todos los servidores de nombres, intentarlo con el tiempo de espera y converger en el más rápido.

Entonces, si observa lo que sucede en los servidores de nombres de TLD (que alojan NSregistros para todos los dominios bajo ese TLD) o en varias recomendaciones, a menudo verá NSregistros con un TTL de 1 o 2 días.

¿Algún consejo sobre cómo funciona el DNS de resolución con NS que no responde y su TTL?

Cada solucionador hace lo suyo :-) Esto no está realmente especificado por el protocolo, es un detalle de implementación. Puede estudiar el código fuente del que puede instalar, pero probablemente no podrá recopilar detalles al respecto de los grandes proveedores públicos de DNS recursivos.

Aunque puedes encontrar más detalles aquí:

RFC 1034 §5.3.3 también proporciona cierta información (tenga en cuenta también que tiene en cuenta un caso que olvidó: un servidor de nombres determinado puede tener varias direcciones IP; hoy en día, incluso debería ser así siempre, con una IPv4 y una IPv6, y no hay garantía de que obtenga resultados en la misma cantidad de tiempo con cada uno):

Además de los nombres y direcciones de los servidores, la estructura de datos SLIST se puede ordenar para utilizar primero los mejores servidores y garantizar que todas las direcciones de todos los servidores se utilicen en forma circular. La clasificación puede ser una simple función de preferir direcciones en la red local sobre otras, o puede involucrar estadísticas de eventos pasados, como tiempos de respuesta anteriores y promedios de acierto.

El paso 3 envía consultas hasta que se recibe una respuesta. La estrategia consiste en recorrer todas las direcciones de todos los servidores con un tiempo de espera entre cada transmisión. En la práctica, es importante utilizar todas las direcciones de un host multitarjeta, y una política de retransmisión demasiado agresiva en realidad ralentiza la respuesta cuando la utilizan varios solucionadores que compiten por el mismo servidor de nombres e incluso ocasionalmente por un único solucionador. SLIST normalmente contiene valores de datos para controlar los tiempos de espera y realizar un seguimiento de las transmisiones anteriores.

RFC 1035 §7.2 tiene esto que decir:

Para completar la inicialización de SLIST, el solucionador adjunta cualquier información histórica que tenga a cada dirección en SLIST. Esto generalmente consistirá en algún tipo de promedios ponderados para el tiempo de respuesta de la dirección y el promedio de acierto de la dirección (es decir, con qué frecuencia la dirección respondió a la solicitud). Tenga en cuenta que esta información debe mantenerse por dirección, en lugar de por servidor de nombres, porque el tiempo de respuesta y el promedio de acierto de un servidor en particular pueden variar considerablemente de una dirección a otra. Tenga en cuenta también que esta información es en realidad específica de un par de dirección de resolución/dirección de servidor, por lo que es posible que un solucionador con varias direcciones desee mantener historiales separados para cada una de sus direcciones. Parte de este paso debe abordar direcciones que no tienen ese historial; en este caso, un tiempo de ida y vuelta esperado de 5 a 10 segundos debería ser el peor de los casos, con estimaciones más bajas para la misma red local, etc.

Tenga en cuenta que cada vez que se sigue una delegación, el algoritmo de resolución reinicializa SLIST.

La información establece una clasificación parcial de las direcciones de servidores de nombres disponibles. Cada vez que se elige una dirección, se debe modificar el estado para evitar su selección nuevamente hasta que se hayan probado todas las demás direcciones. El tiempo de espera para cada transmisión debe ser entre un 50% y un 100% mayor que el valor promedio previsto para permitir variaciones en la respuesta.

También para terminar y más concretamente sobre esto:

Como se ilustra en este artículo de imperva

Este artículo al que hace referencia habla sobre el problema que les ocurrió a las personas que usaban servidores de nombres Dyn, cuando hubo una interrupción. Entonces, sí, si usas solo servidores de nombres Dyn tienes un problema. Incluso si cambias tu zona para usar otras, los NSregistros TTL significan que tu cambio no se verá inmediatamente. Pero eso en realidad no dice mucho sobre los TTL, sino que dice mucho sobre la gestión de DNS: si desea ser resistente, para zonas importantes, no utilice un único proveedor de DNS, sino varios (lo que, por supuesto, exige cierta coordinación entre ellos no se pueden mezclar y combinar arbitrariamente los proveedores X e Y, y es aún más complicado si se introduce DNSSEC en la mezcla, pero es posible). De esa manera, exactamente debido al algoritmo redactado rápidamente anteriormente, incluso si 2 de cada 5 servidores de nombres no responden por completo porque este proveedor específico tiene un problema, el otro tomará la carga y hará que su dominio funcione. Puede haber un retraso adicional en cada nueva consulta para los visitantes (porque todos los servidores de nombres recursivos no pueden entender inmediatamente que tienen que cambiar a servidores de nombres específicos porque 2 de 5 están caídos), y también más retrasos porque los otros 3 están abrumados con más consultas de lo normal (el DNS equilibra la carga de forma predeterminada, por lo que, en teoría, cada servidor de nombres recibe aproximadamente el mismo volumen de consultas), pero aún así se dará una respuesta.

PD: no se solicita, pero como a veces no está claro, todos los registros de un conjunto de registros determinado deben tener el mismo TTL. El TTL es por registro, pero debe ser el mismo en un conjunto de registros determinado, lo que significa que para una tupla determinada de (nombre, tipo de registro) [y clase, pero nadie usa nada más que INclase]

Answer 1

Cuando un solucionador de DNS busca un dominio/zona para un servidor de nombres autorizado, ¿toma los 6 registros y los recorre?

Sí, un servidor de nombres recursivo adecuado tiene en cuenta todos los servidores de nombres e intentará consultar cada vez el más rápido.

Un algoritmo aproximado es algo así como:

desde un inicio en frío (sin caché), pruébelos todos al azar, registre qué tan rápido responden (es posible que deba separar el caso UDP del caso TCP allí)
Después de un tiempo, comience a usar con más frecuencia el más rápido según las respuestas anteriores.
pero tenga en cuenta que debe asegurarse de no quedarse indefinidamente con ningún servidor de nombres determinado, sino que también debe probar "de vez en cuando" los demás. ¿Por qué? Porque la topología de la red puede cambiar, al igual que los propios servidores de nombres. ns3podría ser el más rápido hoy para su punto de vista específico, pero tal vez mañana lo sea ns5; así que tienes que usar el más rápido, pero no siempre, solo para asegurarte de poder descubrir automáticamente cualquier otro más rápido que el que crees que es el más rápido en este momento.

Si un solucionador utiliza el primer servidor NS

Deténgase aquí. Los registros vienen en un conjunto, no en una lista. Es decir, no existe un orden inherente en el DNS. Por supuesto, hay un orden en la representación del cable o de la pantalla, pero no proviene del protocolo.

Los conjuntos de discos son bolsas: obtienes discos, sin pedidos. De hecho, puede ver que muchos servidores de nombres, para exactamente la misma consulta, si hay varios registros en la respuesta, ordenarán los registros de manera diferente cada vez que realice la consulta, exactamente para combatir los sistemas cliente que solo tomarían en cuenta el primer elemento y ignorar a los demás.

cuando ese servidor de nombres autorizado no responde

Consulte el algoritmo anterior: si uno de los servidores de nombres del NSconjunto no responde, puede considerar que es lo mismo que "responder más lento desde cualquier otro". El DNS del cliente tiene tiempos de espera, por lo que no esperará infinitamente, pero marque que este servidor de nombres específico es demasiado lento y cambiará a otros. Entonces, la primera vez incurres en una penalización porque el sistema tiene que intentar contactar con ese servidor de nombres, esperar un poco (unos segundos), volver a intentarlo y en algún momento dejar de usar ese servidor de nombres. Después de esa rampa, utilizará los otros servidores de nombres y las cosas serán rápidas. Pero la primera vez que descubres que un servidor de nombres determinado es lento o no responde al intentar contactarlo, no puedes inferir el problema sin intentarlo.

¿Eso significa que necesito establecer un TTL corto para los registros NS?

Quizás, pero en su mayor parte es irrelevante. ¿Por qué? Porque sus NSregistros se publican en la zona principal de su dominio, para garantizar la delegación de DNS. Por supuesto, se publican allí con un TTL, ya que todos los registros tienen un TTL adjunto, pero se publican en una zona que usted no controla, por lo que NO puede elegir sus valores TTL.

(Hay una discusión complicada/no completamente terminada aquí sobre esos registros, NSque existen en dos partes: el padre y el niño, con la pregunta "¿cuál tiene realmente autoridad"? Si el padre tiene un TTL de 1 semana en NSlos registros y usted en su zona los mismos NSregistros tienen un TTL de 1 segundo, ¿qué debería hacer el servidor de nombres recursivo? Se podría llegar a la conclusión de que normalmente la parte secundaria de la delegación TIENE autoridad, por lo que 1 segundo gana aquí en la práctica en múltiples implementaciones de DNS; están "centrados en los padres", es decir, utilizan los datos del lado de los padres, por lo que 1 semana gana allí)

Los TTL son siempre una compensación. Una vez que lo saben, algunas personas inmediatamente llegan a la conclusión de que las cosas funcionan mejor con TTL muy bajos... lo cual es cierto en algunos casos y no tanto en otros. Los cachés son buenos, si no estuvieran allí (también conocido como: no usar TTL lo suficientemente grandes), no eres resistente a cualquier problema pequeño, eso haría que todo desapareciera porque los cachés ya habrían caducado los nombres.

Además, el valor TTL no tiene (o tiene poco) impacto para el algoritmo anterior al recorrer todos los servidores de nombres, intentarlo con el tiempo de espera y converger en el más rápido.

Entonces, si observa lo que sucede en los servidores de nombres de TLD (que alojan NSregistros para todos los dominios bajo ese TLD) o en varias recomendaciones, a menudo verá NSregistros con un TTL de 1 o 2 días.

¿Algún consejo sobre cómo funciona el DNS de resolución con NS que no responde y su TTL?

Cada solucionador hace lo suyo :-) Esto no está realmente especificado por el protocolo, es un detalle de implementación. Puede estudiar el código fuente del que puede instalar, pero probablemente no podrá recopilar detalles al respecto de los grandes proveedores públicos de DNS recursivos.

Aunque puedes encontrar más detalles aquí:

RFC 1034 §5.3.3 también proporciona cierta información (tenga en cuenta también que tiene en cuenta un caso que olvidó: un servidor de nombres determinado puede tener varias direcciones IP; hoy en día, incluso debería ser así siempre, con una IPv4 y una IPv6, y no hay garantía de que obtenga resultados en la misma cantidad de tiempo con cada uno):

Además de los nombres y direcciones de los servidores, la estructura de datos SLIST se puede ordenar para utilizar primero los mejores servidores y garantizar que todas las direcciones de todos los servidores se utilicen en forma circular. La clasificación puede ser una simple función de preferir direcciones en la red local sobre otras, o puede involucrar estadísticas de eventos pasados, como tiempos de respuesta anteriores y promedios de acierto.

El paso 3 envía consultas hasta que se recibe una respuesta. La estrategia consiste en recorrer todas las direcciones de todos los servidores con un tiempo de espera entre cada transmisión. En la práctica, es importante utilizar todas las direcciones de un host multitarjeta, y una política de retransmisión demasiado agresiva en realidad ralentiza la respuesta cuando la utilizan varios solucionadores que compiten por el mismo servidor de nombres e incluso ocasionalmente por un único solucionador. SLIST normalmente contiene valores de datos para controlar los tiempos de espera y realizar un seguimiento de las transmisiones anteriores.

RFC 1035 §7.2 tiene esto que decir:

Para completar la inicialización de SLIST, el solucionador adjunta cualquier información histórica que tenga a cada dirección en SLIST. Esto generalmente consistirá en algún tipo de promedios ponderados para el tiempo de respuesta de la dirección y el promedio de acierto de la dirección (es decir, con qué frecuencia la dirección respondió a la solicitud). Tenga en cuenta que esta información debe mantenerse por dirección, en lugar de por servidor de nombres, porque el tiempo de respuesta y el promedio de acierto de un servidor en particular pueden variar considerablemente de una dirección a otra. Tenga en cuenta también que esta información es en realidad específica de un par de dirección de resolución/dirección de servidor, por lo que es posible que un solucionador con varias direcciones desee mantener historiales separados para cada una de sus direcciones. Parte de este paso debe abordar direcciones que no tienen ese historial; en este caso, un tiempo de ida y vuelta esperado de 5 a 10 segundos debería ser el peor de los casos, con estimaciones más bajas para la misma red local, etc.

Tenga en cuenta que cada vez que se sigue una delegación, el algoritmo de resolución reinicializa SLIST.

La información establece una clasificación parcial de las direcciones de servidores de nombres disponibles. Cada vez que se elige una dirección, se debe modificar el estado para evitar su selección nuevamente hasta que se hayan probado todas las demás direcciones. El tiempo de espera para cada transmisión debe ser entre un 50% y un 100% mayor que el valor promedio previsto para permitir variaciones en la respuesta.

También para terminar y más concretamente sobre esto:

Como se ilustra en este artículo de imperva

Este artículo al que hace referencia habla sobre el problema que les ocurrió a las personas que usaban servidores de nombres Dyn, cuando hubo una interrupción. Entonces, sí, si usas solo servidores de nombres Dyn tienes un problema. Incluso si cambias tu zona para usar otras, los NSregistros TTL significan que tu cambio no se verá inmediatamente. Pero eso en realidad no dice mucho sobre los TTL, sino que dice mucho sobre la gestión de DNS: si desea ser resistente, para zonas importantes, no utilice un único proveedor de DNS, sino varios (lo que, por supuesto, exige cierta coordinación entre ellos no se pueden mezclar y combinar arbitrariamente los proveedores X e Y, y es aún más complicado si se introduce DNSSEC en la mezcla, pero es posible). De esa manera, exactamente debido al algoritmo redactado rápidamente anteriormente, incluso si 2 de cada 5 servidores de nombres no responden por completo porque este proveedor específico tiene un problema, el otro tomará la carga y hará que su dominio funcione. Puede haber un retraso adicional en cada nueva consulta para los visitantes (porque todos los servidores de nombres recursivos no pueden entender inmediatamente que tienen que cambiar a servidores de nombres específicos porque 2 de 5 están caídos), y también más retrasos porque los otros 3 están abrumados con más consultas de lo normal (el DNS equilibra la carga de forma predeterminada, por lo que, en teoría, cada servidor de nombres recibe aproximadamente el mismo volumen de consultas), pero aún así se dará una respuesta.

PD: no se solicita, pero como a veces no está claro, todos los registros de un conjunto de registros determinado deben tener el mismo TTL. El TTL es por registro, pero debe ser el mismo en un conjunto de registros determinado, lo que significa que para una tupla determinada de (nombre, tipo de registro) [y clase, pero nadie usa nada más que INclase]

Resolución DNS vs registro NS TTL

Respuesta1

información relacionada