Qué es un dominio y qué pasa cuando alguien lo escribe
Publicado el 2026-09-12 por frfrand
Se lee al revés de como se escribe, y esa sola idea explica toda la jerarquía. El recorrido completo de la consulta DNS, qué es el TTL y por qué los cambios tardan.
Un dominio es un nombre que apunta a una dirección de red. Esa es la definición corta. Lo interesante es cómo está organizado y qué pasa entre que lo escribís y aparece el sitio.
Se lee al revés
Los dominios se leen de derecha a izquierda, y cada punto es un nivel de delegación.
En blog.miempresa.com:
- com es el dominio de primer nivel, administrado por un registro que tiene un contrato con ICANN.
- miempresa es lo que registraste. El registro de .com sabe qué servidores de nombres son responsables de ese dominio.
- blog es un subdominio. Este lo creás vos, sin pedirle permiso a nadie, porque vos administrás tu zona.
Hay un nivel más que casi nunca se escribe: la raíz, que es el punto final invisible después de "com". Existe, y es donde empieza todo.
Esa jerarquía resuelve un problema que de otro modo sería imposible: nadie necesita tener la lista completa de todos los nombres de Internet. Cada nivel sólo sabe a quién preguntarle por el siguiente.
El recorrido de una consulta
Cuando escribís el nombre, tu computadora no sabe la dirección. Pregunta a un servidor DNS recursivo (el de tu proveedor, o uno público), y ese servidor hace el trabajo:
- Le pregunta a un servidor raíz: "¿quién sabe de .com?". Le responde con los servidores del registro de .com.
- Le pregunta al registro de .com: "¿quién sabe de miempresa.com?". Le responde con los servidores de nombres que vos configuraste.
- Le pregunta a tus servidores: "¿cuál es la dirección de blog.miempresa.com?". Ahí sí obtiene la respuesta.
Parecen muchos pasos y en la práctica casi nunca se recorren todos, porque cada resultado queda en caché.
El TTL, que explica por qué los cambios tardan
Cada respuesta DNS viene con un TTL: cuántos segundos puede guardarse en caché antes de volver a preguntar.
Si tu registro tiene un TTL de 86400 (un día) y cambiás la dirección, los servidores que ya lo tenían cacheado van a seguir dando la respuesta vieja hasta un día entero. No es que "el DNS propaga lento": es que estás esperando a que expiren las cachés.
De ahí sale la costumbre más útil sobre DNS: antes de una migración, bajá el TTL a 300 segundos con un día de anticipación. El día del cambio, las cachés expiran en cinco minutos y la transición es casi inmediata. Después volvés a subirlo.
Los registros que vas a usar
A nombre -> dirección IPv4 AAAA nombre -> dirección IPv6 CNAME nombre -> otro nombre (un alias) MX a dónde va el correo de este dominio TXT texto libre: verificaciones, SPF, DKIM
Dos reglas sobre CNAME que causan problemas reales:
- No puede convivir con otros registros en el mismo nombre. Por eso no se puede poner un CNAME en la raíz del dominio si también tenés MX: el correo dejaría de funcionar.
- Encadena una consulta más. Un CNAME que apunta a otro CNAME suma latencia.
Cómo diagnosticar
dig blog.miempresa.com dig +trace blog.miempresa.com # el recorrido completo, paso a paso dig @8.8.8.8 blog.miempresa.com # qué responde otro servidor
El segundo es el más educativo: muestra el recorrido entero desde la raíz y hace visible toda la jerarquía.
Y una aclaración que ahorra confusión: si ves una respuesta correcta con dig pero tu navegador sigue yendo al lugar viejo, el problema es caché (del sistema, del navegador, o de tu router), no del DNS.
En ArduMaker los registros de un dominio se administran desde el panel, y al publicar un sitio se crean en pares A y AAAA para que no quede la mitad de la casa sin llave.