¡Bien! Querido ,
Creemos que el DNS rápido (Sistema de nombres de dominio) es tan importante como el contenido rápido. DNS es lo que traduce su nombre de dominio familiar (Google) en una dirección IP que su navegador puede usar (173.194.33.174). Este sistema es fundamental para el rendimiento de su página web, aunque la mayoría de las personas no entienden completamente cómo funciona. Por lo tanto, para ayudarlo a comprender mejor la disponibilidad y el rendimiento de su sitio, publicaremos una serie de artículos de blog para arrojar luz sobre el mundo a veces complejo del DNS, comenzando por lo básico.
En aras de la simplicidad, este artículo asume que no había DNS en caché en ninguna parte, por lo tanto, este es el peor de los casos. Abordaremos el almacenamiento en caché de DNS en futuros artículos.
- ¿Las direcciones IP se basan en la ubicación del centro de datos? Por ejemplo, ¿sería posible usar un bloque de IP de EE. UU. Para mi centro de datos en Francia?
- ¿Cómo fue conectarse a un BBS?
- ¿Qué profesión es más difícil, la programación o la creación de redes?
- ¿Cuál es el mejor dongle de internet en la India?
- ¿Dónde puedo descargar Cisco Packet Tracer?
Antes de cargar la página y cualquier recurso en la página, se debe resolver el DNS para que el navegador pueda establecer una conexión TCP para realizar la solicitud HTTP. Además, para cada recurso externo al que hace referencia una URL, la resolución de DNS debe completar los mismos pasos (por dominio único) antes de que la solicitud se realice a través de HTTP. El proceso de resolución de DNS comienza cuando el usuario escribe una dirección URL en el navegador y presiona Enter. En este punto, el navegador solicita al sistema operativo una página específica, en este caso Google.
Paso 1: Consulta recursiva del sistema operativo para resolver DNS
Como el sistema operativo no sabe dónde está “Google”, consulta un solucionador de DNS. La consulta que el sistema operativo envía al DNS Resolver tiene un indicador especial que indica que es una “consulta recursiva”. Esto significa que el resolutor debe completar la recursión y la respuesta debe ser una dirección IP o un error.
Para la mayoría de los usuarios, su proveedor de servicios de Internet (ISP) proporciona su dispositivo de resolución de DNS, o están utilizando una alternativa de código abierto como Google DNS (8.8.8.8) o OpenDNS (208.67.222.222). Esto se puede ver o cambiar en la configuración de su red o enrutador. En este punto, el solucionador pasa por un proceso llamado recursividad para convertir el nombre de dominio en una dirección IP.
Paso 2: Consulta iterativa de resolución de DNS al servidor raíz
La resolución comienza consultando en uno de los servidores DNS raíz la IP de “www.google.com”. Esta consulta no tiene el indicador recursivo y, por lo tanto, es una “consulta iterativa”, lo que significa que su respuesta debe ser una dirección, la ubicación de un servidor de nombres autorizado, o un error. La raíz se representa en el “.” Oculto al final del nombre de dominio. No es necesario escribir este “.” Adicional ya que su navegador lo agrega automáticamente.
Hay 13 clústeres de servidores raíz denominados AM con servidores en más de 380 ubicaciones. Son administrados por 12 organizaciones diferentes que informan a la Autoridad de Números Asignados de Internet (IANA), como Verisign, que controla los grupos A y J. Todos los servidores son copias de un servidor maestro ejecutado por IANA.
Paso 3: Respuesta del servidor raíz
Estos servidores raíz contienen las ubicaciones de todos los dominios de nivel superior (TLD) como .com, .de, .io y los TLD genéricos más nuevos como .camera.
La raíz no tiene la información de IP de “www.google.com”, pero sabe que .com podría saberlo, por lo que devuelve la ubicación de los servidores .com. La raíz responde con una lista de las 13 ubicaciones de los servidores de gTLD .com, listados como NS o registros de “servidor de nombres”.
Paso 4: Consulta iterativa de resolución de DNS al servidor TLD
A continuación, el resolutor consulta uno de los servidores de nombres .com para conocer la ubicación de google.com. Al igual que los servidores raíz, cada uno de los TLD tiene de 4 a 13 servidores de nombres agrupados en muchas ubicaciones. Hay dos tipos de TLD: códigos de país (ccTLD) administrados por organizaciones gubernamentales y genéricos (gTLD). Cada gTLD tiene una entidad comercial diferente responsable de ejecutar estos servidores. En este caso, utilizaremos los servidores de gTLD controlados por Verisign, que ejecuta los .com, .net, .edu y .gov entre los gTLD.
Paso 2: Consulta iterativa de resolución de DNS al servidor raíz
La resolución comienza consultando a uno de los servidores DNS raíz la IP de “www.google.com”. Esta consulta no tiene el indicador recursivo y, por lo tanto, es una “consulta iterativa”, lo que significa que su respuesta debe ser una dirección, la ubicación de un servidor de nombres autorizado, o un error. La raíz se representa en el “.” Oculto al final del nombre de dominio. No es necesario escribir este “.” Adicional ya que su navegador lo agrega automáticamente.
Hay 13 clústeres de servidores raíz denominados AM con servidores en más de 380 ubicaciones. Son administrados por 12 organizaciones diferentes que informan a la Autoridad de Números Asignados de Internet (IANA), como Verisign, que controla los grupos A y J. Todos los servidores son copias de un servidor maestro ejecutado por IANA.
Paso 3: Respuesta del servidor raíz
Estos servidores raíz contienen las ubicaciones de todos los dominios de nivel superior (TLD) como .com, .de, .io y los TLD genéricos más nuevos como .camera.
La raíz no tiene la información de IP para “Google”, pero sabe que .com podría saberlo, por lo que devuelve la ubicación de los servidores .com. La raíz responde con una lista de las 13 ubicaciones de los servidores de gTLD .com, listados como NS o registros de “servidor de nombres”.
Paso 4: Consulta iterativa de resolución de DNS al servidor TLD
Luego, el resolutor consulta a uno de los servidores de nombres .com la ubicación de Google. Al igual que los servidores raíz, cada uno de los TLD tiene de 4 a 13 servidores de nombres agrupados en muchas ubicaciones. Hay dos tipos de TLD: códigos de país (ccTLD) administrados por organizaciones gubernamentales y genéricos (gTLD). Cada gTLD tiene una entidad comercial diferente responsable de ejecutar estos servidores. En este caso, utilizaremos los servidores de gTLD controlados por Verisign, que ejecuta los .com, .net, .edu y .gov entre los gTLD.
Paso 5: Respuesta del servidor TLD
Cada servidor de TLD contiene una lista de todos los servidores de nombres autorizados para cada dominio en el TLD. Por ejemplo, cada uno de los 13 servidores .com gTLD tiene una lista con todos los servidores de nombres para cada dominio .com. El servidor de gTLD .com no tiene las direcciones IP de Google, pero conoce la ubicación de los servidores de nombres de Google. El servidor .com gTLD responde con una lista de todos los registros NS de Google. En este caso, Google tiene cuatro servidores de nombres, “http://ns1.google.com” a “http://ns4.google.com”.
Paso 6: Consulta iterativa de resolución de DNS a Google NS
Finalmente, el solucionador de DNS consulta a uno de los servidores de nombres de Google la IP de “Google”.
Paso 7: Respuesta de Google NS
Esta vez, el servidor de nombres consultado conoce las direcciones IP y responde con un registro de dirección A o AAAA (según el tipo de consulta) para IPv4 e IPv6, respectivamente.
Paso 8: Respuesta de resolución de DNS al sistema operativo
En este punto, el solucionador ha finalizado el proceso de recursión y puede responder al sistema operativo del usuario final con una dirección IP.
Paso 9: el navegador inicia TCP Handshake
En este punto, el sistema operativo, ahora en posesión de la dirección IP de Google, proporciona la IP a la aplicación (navegador), que inicia la conexión TCP para comenzar a cargar la página.
Como se mencionó anteriormente, este es el peor de los casos en términos de tiempo para completar la resolución. En la mayoría de los casos, si el usuario accedió recientemente a las URL del mismo dominio, u otros usuarios que confiaron en el mismo solucionador DNS han hecho tales solicitudes, no se requerirá una resolución DNS o se limitará a la consulta en el DNS local resolver Cubriremos esto en artículos posteriores.
En este caso de DNS no almacenado en caché, estaban involucrados cuatro conjuntos de servidores DNS, por lo tanto, mucho podría haber salido mal. El usuario final no tiene idea de lo que sucede detrás de escena; simplemente están esperando que se cargue la página y todas estas consultas DNS deben realizarse antes de que el navegador pueda solicitar la página web.
Es por eso que enfatizamos la importancia del DNS rápido. Puede tener un sitio rápido y bien construido, pero si su DNS es lento, su página web aún tendrá un tiempo de respuesta deficiente.
Canal de YouTube: Tech Guru
