Fenix de Takeda11
Muchas personas se confunden acerca de la actualización de los registros DNS cuando cambian la dirección IP de su sitio. ¿Por qué estos registros se actualizan lentamente? ¿Realmente necesitas esperar dos días para que todo se actualice? ¿Por qué algunos visitantes ven la nueva IP, mientras que otros ven la antigua?
El equipo de Mail.ru Cloud Solutions hatraducido un artículo del desarrollador y autor de artículos Julia Evans, donde responde a estas preguntas y cuenta popularmente lo que sucede durante una actualización de DNS desde una perspectiva de front-end.
Aquí hay una exploración rápida de lo que sucede detrás de escena cuando actualiza un registro DNS.
Cómo funciona el DNS: servidores DNS recursivos y autorizados
Primero, necesitamos explicar un poco sobre el sistema DNS. Hay dos tipos de servidores DNS: autorizados y recursivos .
Los servidores DNS autorizados (también conocidos como servidores de nombres ) mantienen una base de datos de direcciones IP para cada dominio del que son responsables. Por ejemplo, en este momento, el servidor DNS autorizado para github.com es
ns-421.awsdns-52.com. Puedes pedirle la dirección IP de github.com con esta solicitud:
dig @ns-421.awsdns-52.com github.com
Los propios servidores DNS recursivos no saben nada sobre quién posee qué dirección IP. Calculan la dirección IP de un dominio al consultarla desde los servidores DNS autorizados apropiados y luego almacenan en caché esa dirección IP en caso de que se les vuelva a solicitar. Entonces 8.8.8.8 es un servidor DNS recursivo.
Cuando las personas visitan su sitio web, probablemente estén realizando búsquedas de DNS en un servidor DNS recursivo. Entonces, ¿cómo funcionan los servidores DNS recursivos? ¡Echemos un vistazo!
Cómo un servidor DNS recursivo consulta la dirección IP de github.com
Veamos un ejemplo de lo que hace un servidor DNS recursivo (por ejemplo, 8.8.8.8) cuando le solicita la dirección IP (registro A) para github.com. Primero, si ya tiene un resultado en caché, lo emitirá. Pero, ¿y si todos los cachés están vencidos? Esto es lo que está pasando.
Paso 1 : Las direcciones IP de los servidores DNS raíz están codificadas en su código fuente. Puede ver esto en el código fuente independiente . Digamos que selecciona 198.41.0.4 para empezar. Aquí está la fuente oficial de estas direcciones IP codificadas, también conocidas como el "archivo de sugerencias de raíz".
Paso 2 : Pregunte a los servidores de nombres raíz sobre github.com.
Podemos reproducir aproximadamente lo que está sucediendo con el comando
dig... Nos da un nuevo servidor de nombres autorizado para consultar: un servidor de nombres .comcon una dirección IP 192.5.6.30.
$ dig @198.41.0.4 github.com
...
com. 172800 IN NS a.gtld-servers.net.
...
a.gtld-servers.net. 172800 IN A 192.5.6.30
...
Los detalles de la respuesta de DNS son un poco más complicados: en este caso, hay una sección de autoridad con algunos registros NS y una sección adicional con registros A, por lo que no es necesario realizar una búsqueda adicional para obtener las direcciones IP de esos servidores de nombres.
En la práctica, el 99,99% de las veces, ya habrá una dirección de servidor de nombres en caché
.com, pero pretendemos que realmente estamos empezando desde cero.
Paso 3 : Pregunte a los servidores
.comde nombres sobre github.com.
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
¡Tenemos una nueva dirección IP para enviar la solicitud! Este es uno de los servidores de nombres de github.com.
Paso 4 : Pida a los servidores de nombres de github.com la dirección de github.com.
¡Ya casi hemos terminado!
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Así que tenemos un registro A para github.com. El servidor recursivo ahora tiene la IP de github.com y puede devolvérsela. Y pudo realizar todo el proceso, comenzando con solo unas pocas direcciones IP codificadas: las direcciones de los servidores de nombres raíz.
Cómo ver todos los pasos de un servidor DNS recursivo: dig + trace
Para ver qué hará el servidor DNS recursivo para resolver el dominio, puede ejecutar:
$ dig @8.8.8.8 +trace github.com
Este comando muestra todos los registros DNS que solicita el servidor recursivo, comenzando con los servidores DNS raíz, que son los cuatro pasos que acabamos de seguir.
Actualizar registros DNS
Ahora que conocemos los conceptos básicos de cómo funciona el DNS, actualice algunos registros DNS y veamos qué sucede.
Al actualizar los registros DNS, hay dos opciones principales:
- mantener los mismos servidores de nombres;
- cambiar servidores de nombres.
Hablemos de TTL
Pero olvidamos algo importante. Esto es TTL. Como dijimos anteriormente, un servidor DNS recursivo almacenará en caché los registros hasta que expiren. Decide la caducidad de un registro en función de su TTL (tiempo de vida).
En este ejemplo, el servidor de nombres de GitHub devuelve un TTL de 60 para su registro DNS, lo que significa 60 segundos:
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Este es un TTL bastante corto. En teoría, si todas las implementaciones de DNS siguieran el estándar de DNS , eso significaría que si GitHub decidiera cambiar la dirección IP de github.com, todos recibirían una nueva dirección IP en 60 segundos. Veamos cómo sucede esto en la práctica.
Opción 1: actualice el registro DNS en los mismos servidores de nombres
Primero, actualicé mis servidores de nombres (Cloudflare) para obtener un nuevo registro DNS, el registro A, que se asigna
test.jvns.caa 1.2.3.4:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4
¡Funcionó de inmediato! No había necesidad de esperar en absoluto, porque antes de eso no había ningún registro DNS
test.jvns.caque pudiera almacenarse en caché. Excelente. Pero parece que el nuevo registro se almacena en caché durante unos cinco minutos (299 segundos).
Entonces, ¿qué pasa si intentamos cambiar esta dirección IP? Lo cambié a 5.6.7.8 y luego ejecuté la misma consulta de DNS:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
Parece que en este servidor DNS el registro 1.2.3.4 todavía se almacena en caché durante 144 segundos. Curiosamente, si consulta 8.8.8.8 varias veces, obtendrá resultados contradictorios: a veces le da una nueva IP y, a veces, una antigua. Probablemente 8.8.8.8 realmente distribuye la carga entre un montón de backends diferentes, cada uno con su propia caché.
Después de cinco minutos de espera, todas las cachés 8.8.8.8 se actualizaron y siempre devolvieron una nueva entrada 5.6.7.8. Asombroso. ¡Es bastante rápido!
No siempre puedes confiar en TTL
Como ocurre con la mayoría de los protocolos de Internet, no todo sigue la especificación de DNS. Algunos servidores DNS de ISP almacenarán en caché los registros durante más tiempo que el TTL especificado. Por ejemplo, dentro de dos días en lugar de cinco minutos. Y las personas siempre pueden codificar la antigua dirección IP en su archivo
/etc/hosts.
En la práctica, al actualizar un registro DNS con un TTL de cinco minutos, puede esperar que un gran porcentaje de clientes migren rápidamente a nuevas direcciones IP (por ejemplo, en 15 minutos), y luego habrá un montón de rezagados que se actualizarán lentamente durante los próximos días.
Opción 2: actualizar sus servidores de nombres
Entonces, hemos visto que cuando renueva una dirección IP sin cambiar sus servidores de nombres, muchos servidores DNS obtienen una nueva dirección IP con bastante rapidez. Excelente. Pero, ¿qué sucede si cambia sus servidores de nombres? ¡Intentemos!
No quería actualizar los servidores de nombres de mi blog, así que en su lugar tomé un dominio diferente mío y lo usé en los ejemplos para el registro HTTP , examplecat.com.
Anteriormente, mis servidores estaban configurados en
dns1.p01.nsone.net. Decidí cambiarlos a servidores de Google con direcciones, ns-cloud-b1.googledomains.cometc.
Cuando realicé el cambio, mi registrador de dominios mostró el mensaje de manera algo inquietante: “Se guardaron los cambios en examplecat.com. Entrarán en vigor en las próximas 48 horas ". Luego establezco un nuevo registro A para que el dominio apunte a 1.2.3.4.
Bien, veamos si algo ha cambiado:
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
Sin cambios. Si le pregunto a otro servidor DNS, conoce la nueva IP:
$ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4
Pero 8.8.8.8 todavía no sabe nada. La razón por la que 1.1.1.1 ve una nueva IP, aunque la cambié hace cinco minutos, es probablemente porque nadie ha preguntado antes 1.1.1.1 sobre este examplecat.com, por lo que no tiene nada en su caché. Era.
Los servidores de nombres tienen mucho más TTL
La razón por la que mi registrador dijo, "Tardará 48 horas", es porque el TTL en los registros NS (la información sobre a qué servidor de nombres debe acceder el servidor recursivo) es mucho mayor.
El nuevo servidor de nombres definitivamente devuelve una nueva dirección IP para examplecat.com:
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
Pero recuerde lo que sucedió cuando consultamos los servidores de nombres de github.com anteriormente:
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
¡172,800 segundos son 48 horas! Por tanto, la actualización del servidor de nombres suele tardar mucho más. Se necesita tiempo para que las cachés caduquen y propaguen la nueva dirección. Lleva mucho más tiempo que simplemente actualizar su dirección IP sin cambiar su servidor de nombres.
Cómo se actualizan sus servidores de nombres
Cuando actualizo los servidores de nombres para
examplecat.com, el servidor de nombres .comobtiene un nuevo registro NS con un nuevo dominio. Me gusta esto:
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
Pero, ¿cómo llega este nuevo récord NS? De hecho, le digo a mi registrador de dominios cómo quiero que se vean los nuevos servidores de nombres actualizándolos en el sitio web, y luego mi registrador de dominios les dice a los servidores
.comde nombres que hagan la actualización.
Porque
.comestas actualizaciones son bastante rápidas (en unos pocos minutos), pero creo que para algunas otras zonas de TLD, es posible que los servidores de nombres no apliquen las actualizaciones tan rápido.
La biblioteca de resolución de DNS de su programa también puede almacenar en caché registros DNS
Otra razón por la que el TTL podría no observarse en la práctica es que muchos programas deben resolver los nombres DNS y algunos programas también almacenarán en caché los registros DNS en la memoria de forma indefinida (hasta que se reinicie el programa).
Por ejemplo, hay un artículo sobre cómo configurar JVM TTL para la búsqueda de DNS . No he escrito mucho código JVM para búsquedas de DNS, pero una pequeña búsqueda en Internet sobre JVM y DNS da la impresión de que puede configurar la JVM para almacenar en caché cada búsqueda de DNS durante una cantidad infinita de tiempo (consulte este ticket de ElasticSearch, por ejemplo ). ...
¡Eso es todo!
Espero que esto te ayude a comprender qué sucede cuando actualizas tu DNS.
Haré una reserva de que todo el historial de distribución de DNS está determinado no solo por TTL. Algunos servidores DNS recursivos probablemente no respetan los TTL, incluso los principales servidores como 8.8.8.8. Entonces, incluso si solo actualiza el registro A con un TTL pequeño, es posible que en la práctica aún reciba solicitudes para la IP anterior dentro de uno o dos días.
Después de publicar este artículo, cambié los servidores de nombres de examplecat.com a sus valores anteriores.
Qué más leer: