# El sistema de nombres de dominio - Sitio: Ikusmira — enciclopedia en castellano de ciencias sociales y humanidades - URL canónica: https://ikusmira.org/p/el-sistema-de-nombres-de-dominio/ - Categoría: Informática - Publicado: 2026-07-28 - Autoría: Josemari Sarasola Ledesma — Editor coordinador; Profesor titular de escuela universitaria, Universidad del País Vasco/Euskal Herriko Unibertsitatea - Perfiles del autor: https://ekoizpen-zientifikoa.ehu.eus/investigadores/127490/detalle, https://dialnet.unirioja.es/servlet/autor?codigo=333202 - Política editorial (autoría, revisión, correcciones, financiación): https://ikusmira.org/politica-editorial/ El **sistema de nombres de dominio** (en inglés, *Domain Name System*, DNS) es la guía telefónica de internet: traduce un nombre que una persona puede recordar, como ikusmira.org, en la dirección numérica del ordenador que sirve esa página, una ristra de cuatro números como 203.0.113.12, que es la de ejemplo de la figura. Los ordenadores solo saben conectarse a direcciones, que es lo que usa el [protocolo TCP/IP](https://ikusmira.org/p/el-protocolo-tcp-ip/) para llevar cada paquete a su destino. Sin el DNS habría que apuntarse los números de cada web, y cualquier cambio de servidor obligaría a todo el mundo a aprenderse uno nuevo. Antes de que existiera, la guía era literalmente un fichero. En la ARPANET de los años setenta, un centro del Instituto de Investigación de Stanford mantenía una lista con el nombre y la dirección de cada ordenador de la red, llamada HOSTS.TXT, y cada máquina se la descargaba de vez en cuando. Funcionaba con unos cientos de ordenadores. Con miles, la lista cambiaba más deprisa de lo que se podía distribuir, dos máquinas querían el mismo nombre y el servidor que la repartía no daba abasto. Paul Mockapetris, del Instituto de Ciencias de la Información de la Universidad del Sur de California, propuso en 1983 sustituirla por una base de datos repartida, y en 1987 publicó las dos normas, RFC 1034 y RFC 1035, que todavía la definen. La idea central es que nadie tiene la lista entera. Los nombres se leen de derecha a izquierda como una jerarquía: en es.wikipedia.org, arriba está la raíz, invisible; debajo, el dominio de primer nivel (*top-level domain*) .org; debajo, wikipedia.org, y debajo, es.wikipedia.org. Cada nivel solo sabe quién responde del nivel siguiente. La raíz no sabe dónde está Wikipedia, pero sabe quién lleva .org; los servidores de .org no saben la dirección de la versión en español, pero saben qué servidor responde por wikipedia.org, y ese sí la sabe, porque lo gestiona la propia fundación. La figura de esta página recorre esa cadena pregunta a pregunta. El que hace el recorrido no es el navegador sino un intermediario, el resolutor (*resolver*), que suele poner el proveedor de internet y que el ordenador recibe al conectarse a la red. El navegador le hace una sola pregunta y espera. El resolutor va preguntando por él y, lo que es más importante, se queda con cada respuesta. La segunda vez que alguien de la misma red pide la misma web, la figura lo enseña: dos mensajes en lugar de ocho. Y como los servidores de .org se recuerdan durante dos días, la visita a otro dominio .org ya se salta la raíz. Esa caché (*cache*) es la razón de que el sistema aguante: la inmensa mayoría de las preguntas no pasa nunca de su resolutor. Hay una sola raíz y trece nombres para ella, de a.root-servers.net a m.root-servers.net, que llevan doce organizaciones distintas, entre ellas la NASA, el ejército estadounidense, universidades y empresas de varios países. El número trece salió de un límite técnico de los años ochenta, lo que cabía en un paquete de respuesta de 512 bytes. Pero cada nombre no es un ordenador, sino muchas copias idénticas repartidas por el mundo que responden en la misma dirección, y la red envía cada pregunta a la más cercana. Según el registro de sus operadores, en 2026 funcionan unas dos mil, varias de ellas en España. Cada respuesta lleva un tiempo de vida (*time to live*, TTL), en segundos, que dice cuánto puede guardarla el resolutor antes de volver a preguntar. Eso explica una frase que repiten todas las empresas de alojamiento web: los cambios de DNS «tardan hasta 48 horas en propagarse». No se propaga nada. El cambio está hecho en el servidor del dominio desde el primer segundo, pero cada resolutor del mundo tiene guardada la respuesta antigua y no preguntará de nuevo hasta que caduque. Quien vaya a mudar una web de servidor puede bajar el TTL a unos minutos un par de días antes, esperar a que caduquen las copias largas y hacer entonces el cambio, que se verá casi al instante. En la figura, «Esperar diez minutos» adelanta ese reloj. Del mismo diseño salen varias cosas prácticas. Si una web no carga en un ordenador y sí en el móvil con datos, a menudo es que el resolutor de la red de casa guarda una respuesta vieja o no responde, y se arregla cambiando de resolutor en los ajustes de red por uno público. Los bloqueos de páginas ordenados por un juez se aplican con frecuencia en los resolutores de los proveedores, y por eso se esquivan cambiando de resolutor. Y la guía antigua sigue ahí: todos los sistemas operativos conservan un fichero, llamado hosts, que se consulta antes que el DNS, y apuntar en él un nombre a una dirección falsa es una de las maneras más simples de bloquear una web en un ordenador. También sale la fragilidad. El 4 de octubre de 2021, Facebook, Instagram y WhatsApp desaparecieron de internet durante unas seis horas. Según contó Santosh Janardhan, de la propia empresa, una orden de mantenimiento desconectó por error toda su red troncal. Sus servidores de DNS estaban programados para retirarse de internet si dejaban de ver los centros de datos, porque eso suele indicar una conexión estropeada, y se retiraron todos a la vez. Los servidores de las aplicaciones seguían encendidos, pero ningún resolutor del mundo podía averiguar dónde estaban. Para miles de millones de personas, un nombre que no se puede traducir es lo mismo que una web que no existe. [El protocolo TCP/IP](https://ikusmira.org/p/el-protocolo-tcp-ip/) – [La caché LRU](https://ikusmira.org/p/la-cache-lru/) – [Las latencias de un ordenador](https://ikusmira.org/p/las-latencias-de-un-ordenador/) – [La tabla hash](https://ikusmira.org/p/la-tabla-hash/) – [La fuerza de una contraseña](https://ikusmira.org/p/la-fuerza-de-una-contrasena/) – [La búsqueda binaria](https://ikusmira.org/p/la-busqueda-binaria/) ## Fuentes - Paul Mockapetris — *Domain names: concepts and facilities (RFC 1034)*, Internet Engineering Task Force (1987) — https://doi.org/10.17487/RFC1034 - Paul Mockapetris — *Domain names: implementation and specification (RFC 1035)*, Internet Engineering Task Force (1987) — https://doi.org/10.17487/RFC1035 - Paul Mockapetris y Kevin J. Dunlap — *Development of the Domain Name System*, SIGCOMM '88: Symposium proceedings on Communications architectures and protocols (1988) — https://doi.org/10.1145/52324.52338 - Root Server Technical Operations Association — *Root Servers*, root-servers.org (2026) — https://root-servers.org/ - Santosh Janardhan — *More details about the October 4 outage*, Engineering at Meta (2021) — https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/ --- Cómo citar: Sarasola, Josemari (2026). «El sistema de nombres de dominio». Ikusmira. https://ikusmira.org/p/el-sistema-de-nombres-de-dominio/ Índice del sitio para modelos: https://ikusmira.org/llms.txt