¿Cómo se determina el orden de búsqueda de DNS?

Por ejemplo: hemos registrado el nombre de dominio domain.com y hemos agregado registros del servidor de nombres en el servidor de registradores:
ns1.domain.com.
ns2.domain.com.
ns3.domain.com.

Entonces buscamos domain.com . Obtenemos las 3 direcciones del servidor de nombres.
1. ¿Cuál de esos servidores se solicitará más y por qué?
2. ¿Importa el orden de los registros NS en el archivo de zona?
3. ¿Se determina en cualquier RFC ?

Lamentablemente, la respuesta aquí es "depende". Los factores de los que depende variarán según el dominio y la configuración de los servidores propietarios, así como la configuración de su propio DNS local.

Primero, por ejemplo, con respecto a los registros NS devueltos: está perfectamente permitido aleatorizar el orden en que se devuelven esos registros, por lo que el orden puede diferir cada vez que lo solicite. Por otro lado, eso no lo hacen todas las implementaciones de DNS, por lo que bien podría obtener una lista ordenada estáticamente. El punto es que no puedes estar seguro.

A continuación, algunas implementaciones de DNS consultarán cada NS en paralelo y usarán la que responda primero. Otros llegarán a cada uno, determinarán el más rápido sobre un número determinado de solicitudes y lo utilizarán. O simplemente podría ser un round robin.

Existen múltiples RFC para DNS, dos de los más útiles que he encontrado son:

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

Me doy cuenta de que esto es algo así como una falta de respuesta, sin nada definitivo que pueda quitar, pero dado lo anterior, la única forma verdadera de determinar el comportamiento de un dominio dado es probar.

La implementación más común que he visto a nivel del cliente, como los ISP en todo el mundo, es la siguiente:

1. Alguien (como un suscriptor de banda ancha) pide a los servidores DNS del ISP que resuelvan el registro A de foo.example.com.
2. El ISP verifica su propio caché, y si ese registro se almacena en caché y aún se considera "nuevo", se devuelve inmediatamente a través del caché. ( Así es como funcionan todos los cachés DNS, para que no forcen innecesariamente los servidores DNS del sitio en cuestión ) .
3. Si no tenían ese registro en caché, o si el caché se considera "obsoleto / obsoleto", el ISP sabe que necesita resolver el último registro nuevamente.
4. Ahora, el ISP necesita saber qué servidores de nombres consultar sobre el último registro.
5. El ISP comienza verificando su lista en caché de los servidores de nombres autorizados para el dominio (estos son ns1.example.com, ns2.example.com, etc. junto con sus IP). Si esos registros aún se consideran nuevos, salta al paso 8.
6. Si los registros del servidor de nombres en caché se consideraron caducados, o si no tenía ningún registro en caché para ese dominio, el ISP consulta a los servidores de nombres raíz del TLD (como el registro .com si es un dominio .com) para obtener el la mayoría de los pares de nombre / IP de servidor de nombres más actualizados, por ejemplo.com. ( Puede probarlo usted mismo a través de "dig @ b.gtld-servers.net example.com" para ver lo que los servidores de nombres raíz de su TLD saben sobre su dominio, si su dominio pertenece a los TLD com / net / etc habituales. Otros Los TLD tendrían que consultar sus respectivos servidores raíz ) .
7. Los servidores de nombres raíz para el TLD siempre devuelven los servidores de nombres en el orden exacto en que fueron especificados por usted; no continúa la aleatorización. También devuelven las IP para cada servidor de nombres; Esto se conoce como "PEGAMENTO" y es lo que permite que Internet resuelva el problema del "huevo y la gallina" de cómo resolver un nombre de host del servidor de nombres a una IP antes de saber algo sobre un dominio. Además, la mayoría de ellos (como los registros com / net / etc, que son los más grandes) usan un tiempo de caché de 2 días para que no se vean constantemente golpeados con "¿cuál es la lista de servidores de nombres para el dominio X?" peticiones. Esta es la fuente del conocimiento común de que DEBE esperar 2 días hasta que pueda decir con seguridad que sus nuevos servidores de nombres son conocidos en todo el mundo, después de que usted "
8. Cuando el ISP conoce los servidores de nombres de example.com y sus IP, como ns1.example.com, ns2.example.com, ns3.example.com, el ISP ahora selecciona un servidor aleatorio de esa lista y envía la consulta. ( Esto es bueno de su parte, no afectan innecesariamente a todos los servidores DNS del sitio en cuestión, y ayudan aún más con el equilibrio de carga al no consultar siempre el primer servidor de nombres listado ) .
9. Si el ISP no obtiene una respuesta de ese servidor de nombres dentro de un período de tiempo de espera especificado, consulta a otro en la lista.
10. Cuando tiene una respuesta, el ISP ahora lo almacena en su propio caché local. En cuanto a cuánto tiempo permanecerá en caché; cada registro devuelto por cualquier servidor DNS también tiene un tiempo de "vencimiento suave" (en segundos) asociado, que es el tiempo que el cliente que realiza la consulta (como el servidor DNS del ISP) puede almacenar en caché ese registro antes de que sea considerado " aún utilizable pero posiblemente desactualizado, ahora debe realizarse una nueva consulta SI ES POSIBLE solo para asegurarse de que no ha cambiado ". También hay un tiempo de "caducidad" que se especifica en el registro "SOA" (inicio de autoridad) de cada servidor de nombres individual (puede ver el suyo a través de "dig @ ns1.example.com example.com -t soa"), que especifica un "límite duro" global para todos los registros devueltos por ese servidor, después de lo cual cualquier caché DEBERÍA ELIMINAR su registro en caché INCLUSO SI los servidores de nombres están inactivos y es imposible volver a buscar los registros. Por lo general, la caducidad suave es de 30 minutos a 5 horas y la caducidad dura entre 1-3 semanas.
11. Después de ese trabajo exhaustivo, el ISP finalmente tiene el último registro de DNS y puede devolverlo al suscriptor de banda ancha que realiza la consulta, ¡quien no sabe qué gran trabajo ha tenido lugar detrás de escena!

Este proceso se repite para CADA búsqueda de registros. Sin embargo, solo la primera consulta hace todo el trabajo; las IP del servidor de nombres se almacenarán en caché después de eso y las consultas posteriores al servidor DNS de caché del ISP podrán saltar rápidamente al paso 8.

Ahora, en cuanto a la aleatorización del paso 8, funciona en un nivel de registro. Digamos que el suscriptor de banda ancha de ese ISP preguntó sobre los siguientes registros:

• A foo.example.com
• Un ejemplo.com
• Un www.ejemplo.com
• MX example.com (un cliente de ISP no debería pedir este registro, pero es solo un ejemplo)

Cada registro se manejará como su propia "entidad" separada, almacenada en caché y buscada de forma independiente. Entonces, digamos que el suscriptor y el ISP nunca antes han encontrado el dominio y ambos tienen registros en caché completamente cero. Las búsquedas pueden ser las siguientes:

• Un foo.example.com a través de ns1.example.com, luego almacenado en la caché del ISP
• Un ejemplo.com a través de ns3.example.com, luego almacenado en la caché del ISP
• Un www.example.com a través de ns2.example.com, luego almacenado en la caché del ISP
• MX example.com a través de ns3.example.com, luego almacenado en la caché del ISP

Cada vez que los registros en caché caducan, el proceso se repite, por lo que ni siquiera sabe que las solicitudes posteriores para ese registro volverán a utilizar el mismo servidor.

Por lo tanto, su mayor objetivo es asegurarse de que todos sus servidores DNS estén completamente sincronizados entre sí, reflejando perfectamente cada registro DNS en cada servidor. Usted nunca se sabe qué servidor de un cliente DNS estará llegando y no se puede confiar en absoluto en ningún orden. No existe tal cosa.

Además, como mencionó Adam C, los servidores DNS a nivel de servidor (example.com) podrían devolver registros NS y aleatorizar el orden de los mismos. Es muy común que los servidores DNS normales estén aleatorizando sus registros NS con la mínima posibilidad de que una implementación de DNS deficiente siempre elija el primer servidor de nam devuelto. Sin embargo, los servidores de nombres ROOT TLD (mencionados anteriormente) nunca aleatorizarán la lista, y su lista es lo que realmente importa a la hora de resolver el dominio. Es por eso que la mayoría de las implementaciones eligen un servidor aleatorio de las listas de servidores de nombres, para evitar golpear siempre el mismo servidor y sobrecargarlo.

Muy bien, ese es tu manual sobre cómo funciona DNS y lo que debes recordar.

• En resumen: trate a todos sus servidores DNS como si fueran solo un servidor, por lo que su objetivo más alto en la vida es asegurarse de que todos sean igualmente capaces de responder cualquier consulta que se les pueda lanzar.

Descargo de responsabilidad: los objetivos más altos en la vida que la administración de DNS pueden estar disponibles, pero se venden por separado, use su imaginación. ;-)