¿Cómo funciona la propagación de DNS?

La respuesta de Jonathan Wright es correcta y ofrece una muy buena visión general sobre cómo funcionan los resolvers de almacenamiento en caché.

Como servidor autorizado de DNS, no era mi primer pensamiento sobre cómo responder la pregunta, porque pienso en la “propagación” en términos de cómo la información de la zona llega desde su fuente final a las otras máquinas que albergan zona.

Los servidores de nombres autorizados son los responsables de responder directamente a las solicitudes sobre nombres en una zona. Puede ver una lista de ellos buscando los registros NS de la zona, como con la herramienta “cavar” en sistemas tipo Unix. Aquí hay un comando de muestra con un par de interruptores adicionales para recortar la salida:

El | $ dig + noall + ans ns example.com
El | ejemplo.com. 172800 IN NS a.iana-servers.net.
El | ejemplo.com. 172800 IN NS b.iana-servers.net.

Primero describiré el modelo DNS tradicional de la propagación de información de zona entre las autoridades, y abordaré más tarde que hay muchos sistemas que son excepciones. Sin embargo, el modelo tradicional todavía se usa ampliamente en Internet y lo será durante muchos años.

Dentro de un conjunto de servidores de nombres autorizados hay un servidor que es el servidor “primario”, a veces llamado “maestro”, y el resto son servidores “secundarios”, a veces llamados “esclavos”. (Puede ver por qué ha habido algún incentivo para usar la nomenclatura primaria / secundaria). Cuando mencioné la “fuente última” arriba, este es el servidor primario. Es donde comienzan las actualizaciones de la zona, y deben propagarse luego a los servidores secundarios.

El mundo en general no puede saber qué servidor del conjunto es el primario y cuáles son los secundarios, porque se trata de una configuración interna que no le importa a nadie más que a los administradores de la zona. De hecho, el servidor de nombres primario podría no estar incluido en el conjunto de registros NS para la zona y podría ser un “primario oculto”. Algunas organizaciones hacen esto para proteger a sus principales de los ataques.

Cuando la zona cambia en la primaria, hay dos formas para que las secundarias sepan esto. En la especificación del protocolo DNS original, el segundo campo numérico del registro SOA (Inicio de autoridad) define, en segundos, el “tiempo de actualización” de la zona. Este es el período después del cual un secundario debe preguntarle al primario si la zona ha cambiado, solicitando el mismo registro SOA y verificando si el “número de serie”, el primer campo numérico, ha aumentado. Aquí está el SOA por ejemplo.com:

El | ejemplo.com. 3600 EN SOA (
El | sns.dns.icann.org. noc.dns.icann.org.
El | 2014091867 7200 3600 1209600 3600)

Aquí, 7200 segundos (dos horas) es el tiempo de actualización, y la serie actual es 2014091867. Si la secundaria ve un cambio de serie a 2014091868 o superior, iniciará una “transferencia de zona”. Como nota al margen, se supone que el primer campo entre paréntesis representa el host que originó los datos de la zona, y que no es a.iana-servers.net ni b.iana-servers.net sugiere, pero no indica absolutamente, que un primario oculto está en uso.

La transferencia de zona utiliza un tipo de solicitud DNS especial, ya sea AXFR o IXFR. AXFR era de la especificación de protocolo original, y lo que hace es enviar todo el contenido de la zona, en “formato de archivo maestro”, al solicitante. IXFR apareció más tarde y solo envía diferencias incrementales en la zona: una lista de registros que se eliminaron y otra lista de los que se agregaron. Los datos modificados para un nombre dado se envían como una eliminación de los datos antiguos seguido de una adición de los datos nuevos.

AXFR e IXFR normalmente tienen una “lista de control de acceso” especificada para ellos, lo que limita las direcciones de Internet que un servidor permitirá usar el comando. Si intenta utilizar el comando de excavación anterior pero sustituye “axfr” por “ns”, verá que falla, a menos que realmente se encuentre en una de las máquinas altamente restringidas para las que está permitido.

Puede leer más detalles sobre las transferencias de zona en Wikipedia, https://en.wikipedia.org/wiki/DN…

Inmediatamente notará un problema con el uso del tiempo de actualización del SOA, que puede tomar mucho tiempo para que un secundario note un cambio. Claro, podría acortar drásticamente el tiempo de actualización, a costa de aumentar la cantidad de veces que la secundaria tiene que preguntarle a la primaria si algo ha cambiado. Si la zona rara vez cambia, es un gran esfuerzo desperdiciado.

Para abordar ese problema, se estableció el protocolo DNS NOTIFY. Permite que un servidor de nombres primario le diga a sus secundarios que la zona ha cambiado. Luego programan un AXFR / IXFR para actualizar sus propias copias.

¿Recuerdas lo que dije sobre las excepciones a este proceso? Si bien es razonablemente eficiente para el caso común, cuando se trata de un servidor autorizado, realmente solo necesita saber cuáles son las respuestas para una zona, y cómo ese conocimiento llegó a ella es irrelevante para el mundo exterior .

Muchas zonas que usa todos los días no obtienen sus respuestas de una zona almacenada en formato de archivo maestro, ni la propagación de esos datos se realiza a través de protocolos DNS. Se puede usar cualquier protocolo de transferencia de datos para obtener la información de un servidor al siguiente, y la fuente real de los datos podría no ser un servidor DNS.

Por ejemplo, una red de entrega de contenido (https://en.wikipedia.org/wiki/Co…) podría usar software especializado para recopilar información sobre qué máquinas en su red están disponibles y enviar regularmente un mensaje a cada servidor DNS. Los servidores DNS incorporan esto en su lógica de respuesta. En ese caso no existe un arreglo tradicional de primaria y secundaria.

Espero que entre la respuesta de Jonathan y la mía logremos abordar la pregunta que tenía en mente.

La propagación de DNS no es tanto una acción que deba tomarse, ya sea manual o automáticamente, sino que es realmente una consecuencia de una de las decisiones de diseño de DNS: el almacenamiento en caché.

Requerir que se contacte con un servidor DNS en cada solicitud se considera (con razón) una exageración y agregaría latencia innecesaria al funcionamiento general de Internet. Por lo tanto, se ha permitido que los servidores DNS puedan almacenar en caché los datos proporcionados por los servidores de nombres configurados con la premisa de que no cambian con tanta frecuencia. Este caché está a su vez controlado por el TTL (Time to Live) y se puede configurar en un nivel por zona (un dominio) o por registro, dependiendo de cómo configure su DNS.

Por ejemplo: si configuro mi nuevo dominio example.ext con un nuevo www. grabar y darle un TTL de 3600, luego Jane Smith hace una solicitud de su “SuperSpeedy” de su ISP para visitar http: //www.example.ext , los servidores DNS de los ISP realizarán un recorrido normal del sistema DNS y recogerán mi grabar. En ese registro, tendrá una nota que dice que solo puede guardar esto durante una hora. Los servidores DNS del ISP pasan esto a la computadora de Jane con la misma nota y ella se conecta a mi sitio web. Mientras continuaba navegando, su navegador, su computadora y el ISP almacenan el registro diciendo a qué dirección IP debe conectarse para ver http: //www.example.ext . Después de una hora, el proceso comienza nuevamente, se otorga otra hora, y así sucesivamente.

La próxima semana, decido actualizarme a un nuevo servidor. Todo está configurado, configurado y probado: todo lo que necesito hacer ahora es cambiar el DNS para mover el tráfico al nuevo servidor en su nueva dirección. Archivo de zona actualizado, guardado, verificado y el servidor DNS recargado. ¿Hecho?

No

John Doe comenzó a visitar el sitio hace cinco minutos, cinco minutos antes de que yo hiciera el cambio, y cuando solicitamos el registro de nuestro servidor DNS, enviamos un mensaje con el registro DNS diciendo que podían guardarlo durante una hora. Eso significa que durante los próximos 55 minutos, John Doe y su ISP (junto con cualquier otra persona que se conecte a través de ese ISP) continuarán conectándose al servidor anterior. Sin embargo, Jane Doe regresa 10 minutos después de que yo haga el cambio; ella y su ISP ahora tienen el nuevo récord. Por lo tanto, tengo algo de tráfico que va al servidor anterior y algo que va al nuevo servidor.

Para John, debe esperar 55 minutos para que los registros se actualicen para que podamos conectarnos a mi nuevo Super Server; Esto es propagación . Es el proceso por el cual los registros antiguos mueren en cachés DNS remotas obligando a los servidores a hacer nuevas solicitudes y recoger los nuevos registros.

El valor predeterminado para la mayoría de los DNS es 86400, o 24 horas. Esto puede ser desafortunado, pero como se mencionó anteriormente, puede controlarlo por zona o por registro, por lo que hay una manera de superar este efecto: podría configurar temporalmente http: //www.example.ext con un TTL de 120 segundos con al menos 24 horas de anticipación. En el momento en que cambie los registros DNS, solo pueden durar un máximo de dos minutos, lo que significa que dentro de los dos minutos posteriores a la modificación, cada servidor debe volver a solicitar el registro y obtendrá la nueva entrada. Vuelva a cambiar el TTL a 86400 y se reanudará el servicio normal.

Otra buena característica que ayuda con esto es que el TTL es un reloj de cuenta regresiva. Mi servidor DNS, como servidor maestro, siempre estará configurado para dar el TTL completo (por ejemplo, 3600). Por lo tanto, cuando el ISP lo almacena en caché, lo guardará durante una hora y no más, momento en el cual comienza el reloj de cuenta regresiva. (En cero, se puede eliminar). Sin embargo, si llego y le pido al ISP el registro que ya ha estado en su caché durante 30 minutos, su temporizador de cuenta regresiva dirá 1800. El TTL para el registro dado a yo será 1800. Sabe que este registro será válido solo por otros 30 minutos y, por lo tanto, me dice la validez actual, no la validez original. Como resultado, todos los miembros de un solo ISP o compañía se sincronizan: una vez que expira el registro original en el ISP, también lo harán todos los que consultaron en ese servidor (más o menos unos segundos) y, por lo tanto, evita la situación por la cual un registro puede existir por más tiempo de lo permitido.