1. Por qué una sola tabla con todos los nombres de internet era un problema
Imagina que la dirección de todos los compañeros de clase está escrita en una sola hoja de papel que se reparte a todos. Cada vez que alguien se muda, hay que reescribir la hoja y volver a repartirla. Así se gestionaban los nombres en Internet antes del DNS. La correspondencia entre el nombre del host (el nombre asignado a la computadora) y su número estaba centralizada en un único archivo llamado "HOSTS.TXT", mantenido por el NIC (Centro de Información de Red)[1]. Esta forma de gestionar los datos se estableció oficialmente en el documento técnico RFC 952 en octubre de 1985, indicando que el archivo se publicaba desde una computadora del NIC ubicada en SRI International[2]. Sin embargo, la analogía de la hoja de papel es solo una comparación para facilitar la comprensión. En la realidad, el archivo era algo muy simple: una lista lineal que colocaba el nombre y el número de cada computadora una línea tras otra.
2. Por qué, al multiplicar los equipos por 10, el tráfico para repartir la tabla se multiplica por 100
¿Qué pasaría si la clase creciera de 10 a 100 alumnos? El esfuerzo para repartir las hojas aumentaría drásticamente, ya que tanto quienes reparten como quienes reciben serían 10 veces más, resultando en un esfuerzo total aproximadamente 100 veces mayor (10 x 10). En una red real, este "esfuerzo" equivale al volumen de datos necesario para distribuir la información. El RFC 1034 señala tres problemas principales de este sistema. El primero es que la cantidad de tráfico de red para distribuir la nueva versión a todos los hosts es proporcional al cuadrado del número de hosts[1]. La estimación de que si los hosts se multiplican por 10 el tráfico se multiplica por 100 no es un dato medido, sino un cálculo basado en el método de distribución. El segundo problema es que, aunque se añada un nombre nuevo, este no es visible en toda la Internet hasta que el NIC actualiza el archivo. El tercer problema es que el número de hosts estaba creciendo rápidamente[1]. Mantener todo en un solo lugar se vuelve difícil tanto para quien posee la información como para quien la distribuye a medida que la escala aumenta. Entonces, ¿qué diseño evita usar una sola tabla?
3. Cómo el DNS organiza los nombres en forma de árbol y reparte su gestión
La parte final de un nombre de sitio, como ".com" o ".jp", se denomina dominio de nivel superior. El DNS utiliza esta estructura como si fuera la ramificación de un árbol. El espacio de nombres tiene forma de árbol, con una "raíz" (root) sin nombre en la parte superior, bajo la cual se disponen los dominios de nivel superior[1]. Según el RFC 1591 de marzo de 1994, existían COM, EDU, NET, ORG e INT, además de GOV y MIL (limitados a Estados Unidos), y para los países se usaban códigos de dos letras según la norma ISO 3166[4]. Esta era la lista vigente en 1994; hoy en día hay muchos más. Lo crucial es que la gestión del contenido de cada dominio se delega a sus respectivos administradores[4]. Los nombres de Japón los decide la administración japonesa, y los nombres dentro de una empresa los decide la propia empresa. Esto elimina la necesidad de que todos esperen la actualización de una única tabla centralizada. Aunque los nombres y la gestión están separados, surge una duda: ¿cómo llega la computadora del usuario al número de destino al escribir un nombre?
4. Cómo se pregunta desde los servidores raíz hacia abajo hasta obtener el número de destino
Imagina buscar una casa en una ciudad desconocida: primero preguntas la dirección general en la estación, luego preguntas la calle en la oficina de información local y, finalmente, preguntas a alguien en la calle por la casa exacta. La búsqueda de nombres en el DNS es muy similar. Un programa llamado resolutor completo (full resolver), que actúa en nombre de la computadora del usuario, consulta primero a un servidor raíz. Los servidores raíz gestionan la información de los servidores DNS autorizados (los que tienen la información oficial) de todos los dominios de nivel superior, y le dicen al resolutor: "El responsable de la parte final de este nombre es este servidor"[5]. Luego, el resolutor consulta al servidor autorizado de ese dominio de nivel superior, que le indica cuál es el servidor autorizado para el dominio específico. Finalmente, ese servidor autorizado responde con la dirección IP de destino. A este método de seguir el rastro pidiendo al siguiente responsable se le llama consulta iterativa[5]. Es importante notar que la raíz no responde con el número final, sino que cumple la función de indicar la siguiente puerta de entrada. Sin embargo, esta es una explicación básica del camino; en la práctica, gracias a un sistema de "memoria" que veremos más adelante, no siempre se recorre todo este camino desde el principio. Entonces, ¿cuántos servidores raíz existen en el mundo, que son la primera puerta de entrada?
5. Por qué los 13 servidores raíz del DNS son 13 nombres y no 13 máquinas
Es posible que hayas oído que solo hay 13 servidores raíz en el mundo. Sin embargo, 13 no es el número de máquinas, sino el número de nombres. Los servidores raíz tienen 13 nombres, de la "A" a la "M", y son operados por 12 organizaciones independientes. Detrás de cada nombre hay muchas instalaciones (instancias) ubicadas en todo el mundo. Según root-servers.org, al 30 de septiembre de 2026, había 2.045 instalaciones operativas[6]. Este número cambia diariamente. Existe una explicación común sobre por qué son 13: se dice que al enviar mensajes de DNS por UDP, el tamaño está limitado a 512 bytes[3], y 13 era el número máximo que cabía en ese espacio. No obstante, el RFC 1035 no especifica esta razón como tal; es una explicación secundaria que aquí no se afirma como hecho definitivo. Al mantener los nombres en 13 pero aumentar las instalaciones en todo el mundo, se reduce la distancia a los servidores lejanos y permite que, si uno falla, otros puedan responder. Por cierto, ¿no parece agotador recorrer el camino desde la raíz cada vez? ¿Hay alguna forma de evitarlo?
6. Cómo el DNS recuerda las respuestas durante un tiempo limitado antes de que caduquen
Si visitas la misma casa muchas veces, basta con anotar las instrucciones una vez para no tener que preguntar a nadie la próxima vez. El resolutor de DNS también guarda las respuestas ya consultadas para no repetir la misma consulta[1]. Sin embargo, estas notas necesitan una fecha de caducidad. Si una tienda se muda pero sigues usando una nota vieja, irás al lugar equivocado. Por eso, los datos del DNS incluyen un TTL (Time to Live), que indica el tiempo durante el cual se puede guardar la información en caché. El RFC 1035 define el TTL como un entero con signo de 32 bits, estableciendo que, pasado ese intervalo, se debe volver a verificar la información con la fuente original[3]. El RFC 1034 de 1987 recomendaba un TTL de alrededor de un día para los hosts comunes[1]. Los valores actuales varían según el sitio y no existe un estándar universal para este número hoy en día. Así, se llega a un equilibrio entre la debilidad del sistema de una sola tabla ("actualizaciones lentas") y la debilidad del sistema distribuido ("pesado si se pregunta cada vez") mediante esta memoria con fecha de caducidad. Volviendo a la pregunta inicial: los sitios se abren al escribir el nombre porque el árbol, la delegación y la caché lo hacen posible.
Si quieres investigar por tu cuenta
Para entender mejor la estructura, mira la dirección de tu sitio web favorito y busca la parte más a la derecha, como ".jp" o ".com". Luego, escribe tu dirección postal de la unidad más grande a la más pequeña. La dirección postal va de grande a pequeño (prefectura -> ciudad -> pueblo), pero los nombres de los sitios están invertidos: la izquierda es la parte más específica y la derecha la más general. Si lees el nombre de derecha a izquierda, verás que hacia la derecha se sube de nivel, hasta la raíz sin nombre, lo que ayuda a visualizar la forma de árbol. Para profundizar, los materiales explicativos de JPRS describen el sistema DNS con diagramas en japonés. Puedes practicar dibujando en un papel nombres de sitios con ".jp" o ".com" y trazando flechas para indicar cuál es la división más grande a la derecha, para entender el camino que se recorre desde la raíz.