El DNS —sistema de nombres de dominio— traduce nombres legibles en las direcciones que las máquinas necesitan para conectarse. Funciona como una jerarquía distribuida: un resolutor recursivo pregunta primero a un servidor raíz —hay trece autoridades nombradas, de la a a la m, según IANA—, después al servidor de la extensión, y por último al servidor autoritativo del dominio, que da la respuesta real. Cada respuesta viaja con un TTL: los segundos que puede guardarse en caché. Por eso la «propagación» no existe como tal: lo que hay son cachés venciendo, y su duración la elegiste vos al configurar el registro.
Ver índice de contenidos
Qué problema resuelve
Las máquinas se conectan usando direcciones numéricas; las personas recuerdan nombres. El DNS es la capa que traduce entre las dos cosas, y es tan central que cuando falla parece que «se cayó internet», aunque los servidores estén perfectos.
Pero traducir no es todo lo que hace. El DNS también permite cambiar de servidor sin cambiar de nombre, repartir tráfico entre varias máquinas, dirigir el correo a un proveedor distinto del sitio web y publicar información verificable sobre el dominio, como qué servidores pueden mandar correo en su nombre.
La propiedad que lo hace difícil de entender
El DNS es una base de datos distribuida y con caché en todos lados. No hay un lugar único al que consultar ni un botón de «actualizar ya». Cada respuesta se guarda temporalmente en decenas de puntos intermedios, y esa es a la vez la razón de que sea rápido y de que los cambios no sean instantáneos.
El recorrido de una consulta
Cuando alguien escribe un nombre y nadie tiene la respuesta guardada, pasa esto:
- El navegador pregunta al resolutor recursivoNormalmente el del proveedor de internet, o uno público configurado a mano. Es el que hace todo el trabajo.
- El resolutor pregunta a un servidor raízIANA describe trece autoridades nombradas, de
a.root-servers.netam.root-servers.net. La raíz no conoce tu sitio: responde quién atiende la extensión. - Pregunta al servidor de la extensiónEse tampoco conoce tu dirección: responde cuáles son los servidores autoritativos de tu dominio.
- Pregunta al servidor autoritativoEste sí tiene la respuesta real, y la entrega junto con su tiempo de vida.
- El resolutor guarda y respondeCachea la respuesta el tiempo indicado y se la devuelve al navegador.
La parte que sorprende es que la raíz y la extensión no saben dónde está tu sitio. Su función es derivar la pregunta un escalón más abajo. Ese diseño es el que permite que el sistema escale a cientos de millones de nombres sin que nadie tenga una lista completa.
Un detalle sobre los trece: no son trece máquinas. Cada letra es una autoridad operada por una organización distinta —Verisign, ICANN, RIPE NCC, NASA y universidades, entre otras— y detrás de cada una hay cientos de servidores repartidos por el mundo.
Quién guarda qué
Entre el navegador y el servidor autoritativo hay más cachés de las que uno imagina, y saber cuáles son es la mitad del diagnóstico:
| Dónde | Qué guarda | Cómo se limpia |
|---|---|---|
| El navegador | Su propia caché, a veces con reglas propias | Cerrarlo, o su página interna de caché de red |
| El sistema operativo | Las consultas recientes de todo el equipo | Un comando por sistema; se reinicia el servicio |
| El router de casa | Suele hacer de resolutor para la red local | Reiniciarlo |
| El resolutor recursivo | Lo consultado por todos sus usuarios | No lo controlás. Vence solo, según el TTL |
| El servidor autoritativo | La verdad: la zona con todos tus registros | Lo editás vos. Es el único origen |
La fila que importa es la cuarta. Sobre el resolutor de otra persona no tenés ningún control, y ahí está la respuesta a por qué a vos ya te funciona el cambio y a tu cliente todavía no.
Los tipos de registro
Una zona DNS es una lista de registros. Con estos siete se resuelve casi todo:
| Tipo | Para qué | Detalle importante |
|---|---|---|
| A | Apunta un nombre a una dirección IPv4 | El más usado. Puede haber varios para repartir tráfico |
| AAAA | Lo mismo, con IPv6 | Conviene tenerlo: cada vez más redes son solo IPv6 |
| CNAME | Convierte un nombre en alias de otro nombre | No puede convivir con otros registros del mismo nombre, ni usarse en la raíz del dominio |
| MX | A qué servidores va el correo del dominio | Lleva una prioridad: el número más bajo se intenta primero |
| TXT | Texto libre | Verificaciones de propiedad y políticas de correo (SPF, DKIM, DMARC) |
| NS | Qué servidores son autoritativos para la zona | Se configuran en el registrador, no en la zona misma |
| CAA | Qué autoridades pueden emitir certificados para el dominio | Poco usado y muy recomendable: limita quién puede emitir un certificado a tu nombre |
Un CNAME no puede coexistir con ningún otro registro para el mismo nombre. Como en la raíz del dominio siempre hay registros NS y SOA, poner un CNAME ahí es inválido, y algunos paneles lo aceptan igual con consecuencias raras: la más típica es que deja de llegar el correo, porque el MX queda invalidado. Para apuntar la raíz a un nombre, muchos proveedores ofrecen un mecanismo propio de alias que sí es válido.
El TTL, el campo que importa
Cada registro lleva un TTL —tiempo de vida— en segundos: cuánto puede guardarse esa respuesta en caché antes de volver a preguntar. Es el campo que casi nadie toca y el que explica casi todos los problemas de tiempo.
| TTL | Ventaja | Costo |
|---|---|---|
| Corto (300 s = 5 min) | Los cambios se ven rápido | Más consultas; si el servidor DNS falla, se nota enseguida |
| Medio (3600 s = 1 h) | Equilibrio razonable para el día a día | Una hora de espera al cambiar algo |
| Largo (86400 s = 1 día) | Menos consultas, más resistencia a caídas | Un día entero para que un cambio llegue a todos |
La estrategia que resuelve el conflicto es no elegir un valor fijo, sino bajarlo antes de un cambio y subirlo después. Eso está en la sección de mudanza.
La «propagación» no existe
Se dice todo el tiempo que un cambio de DNS «tarda en propagarse hasta 48 horas», y la imagen es engañosa: sugiere que hay algo viajando por el mundo, servidor a servidor, y que solo queda esperar.
Lo que pasa en realidad es más simple y más controlable: tu cambio está aplicado en el servidor autoritativo en el momento en que lo guardás. Lo que tarda es que venzan las cachés que todavía tienen la respuesta vieja, y ese plazo lo definiste vos con el TTL que tenía el registro antes del cambio.
De ahí tres consecuencias prácticas:
- El TTL que manda es el viejo. Si el registro tenía 86400 y lo cambiás a 300, la espera sigue siendo de hasta un día para quien ya lo tenía cacheado.
- No hay forma de forzarlo. Ninguna herramienta «acelera la propagación»: no se puede vaciar la caché de resolutores ajenos.
- Que a vos te funcione no significa nada. Tu equipo consultó de nuevo antes que el de la otra persona, nada más.
Mudarse sin cortes
Con lo anterior, la receta para cambiar de servidor sin que nadie vea el sitio caído se vuelve evidente:
- Bajar el TTL con anticipaciónA 300 segundos, al menos un día antes —o el TTL viejo completo—. Este paso es el que hace que todo lo demás funcione.
- Esperar a que venza el valor anteriorRecién ahí el mundo tiene el TTL corto. Saltearse esta espera anula la estrategia.
- Preparar el destinoEl sitio andando en el servidor nuevo, con su certificado, probado por dirección IP directa.
- Cambiar el registroAhora la ventana de inconsistencia es de cinco minutos, no de un día.
- Verificar desde afueraCon varios resolutores públicos, no solo desde tu equipo.
- Volver a subir el TTLA una hora o más, una vez confirmado. Y no apagar el servidor viejo por unos días.
El paso seis tiene una razón concreta: mientras conviven las dos respuestas, parte del tráfico sigue yendo al servidor anterior. Apagarlo el mismo día es la forma más común de tener el sitio caído para la mitad de la gente.
Diagnóstico
La herramienta estándar es dig, disponible en Linux y macOS. En Windows hay equivalentes en PowerShell.
# Lo básico: la dirección y el TTL que queda de caché
dig underc0de.org A +noall +answer
# Preguntarle DIRECTO al autoritativo, salteando toda caché.
# Si acá se ve el cambio y en otro lado no, es caché: solo queda esperar.
dig @ns1.miproveedor.com underc0de.org A
# Comparar contra resolutores públicos distintos
dig @8.8.8.8 underc0de.org A +short
dig @1.1.1.1 underc0de.org A +short
# Otros tipos
dig underc0de.org MX +short # correo
dig underc0de.org NS +short # quién es autoritativo
dig underc0de.org TXT +short # verificaciones y política de correo
dig underc0de.org CAA +short # quién puede emitirte certificados
# El recorrido completo desde la raíz: muy útil para entender qué pasa
dig +trace underc0de.orgEl comando que resuelve la discusión es el segundo. Si al preguntarle directo al servidor autoritativo el valor es el nuevo, tu configuración está bien y lo que falta es tiempo. Si ahí todavía aparece el viejo, el problema es de configuración y no de espera.
Errores frecuentes
- Cambiar el registro sin bajar el TTL antes. Convierte una mudanza de cinco minutos en una de un día.
- Poner un
CNAMEen la raíz del dominio. Es inválido y suele romper el correo. - Apagar el servidor viejo el mismo día. Parte del tráfico todavía va para allá.
- Verificar solo desde tu equipo. Tu caché no representa al mundo.
- Confundir los
NSdel registrador con los de la zona. Si el registrador apunta a otro proveedor, la zona que estás editando no es la que se usa. - Olvidar el registro
AAAA. Cada vez más redes móviles son solo IPv6. - Buscar herramientas para «forzar la propagación». No existen: no se puede vaciar la caché de un resolutor ajeno.
- No configurar las políticas de correo. Sin SPF, DKIM y DMARC en registros
TXT, tus mensajes caen en no deseado y cualquiera puede escribir en tu nombre.
Preguntas frecuentes
¿Por qué mi cambio de DNS todavía no se ve?
Casi siempre porque hay cachés con la respuesta anterior que todavía no vencieron. El cambio se aplica en tu servidor autoritativo en el momento en que lo guardás, pero cada resolutor que ya había consultado guarda el valor viejo durante el TTL que tenía ese registro antes del cambio. Si tenía un día, la espera puede ser de un día. La forma de comprobarlo es preguntarle directo al servidor autoritativo: si ahí ya aparece el valor nuevo, la configuración está bien y lo único que falta es tiempo.
¿Qué es el TTL y qué valor conviene poner?
Es la cantidad de segundos que una respuesta puede quedar guardada en caché antes de volver a consultarse. Un valor corto, del orden de cinco minutos, hace que los cambios se vean rápido a costa de más consultas; uno largo, de un día, reduce las consultas pero obliga a esperar mucho ante cualquier cambio. La estrategia que funciona no es elegir un valor fijo sino moverlo: bajarlo a unos minutos al menos un día antes de una mudanza, hacer el cambio, verificar y volver a subirlo cuando todo esté estable.
¿Cuál es la diferencia entre un registro A y un CNAME?
Un registro A apunta un nombre directamente a una dirección numérica. Un CNAME dice que ese nombre es un alias de otro nombre, así que la consulta continúa resolviendo el segundo. El CNAME es cómodo cuando el destino puede cambiar de dirección, porque no hay que actualizar nada. Tiene una restricción que se olvida seguido: no puede convivir con otros registros para el mismo nombre y no se puede usar en la raíz del dominio, donde siempre hay registros NS y SOA.
¿Por qué no llega el correo si el sitio funciona bien?
Porque el sitio y el correo se controlan con registros distintos e independientes. La web se resuelve con registros A o AAAA, y el correo con registros MX, que pueden apuntar a un proveedor completamente distinto. Si migraste el sitio copiando solo los registros de la web, el correo queda sin MX y deja de llegar. La otra causa habitual es haber puesto un CNAME en la raíz del dominio, que invalida el MX. Y si el correo llega pero cae en no deseado, el problema suele estar en SPF, DKIM o DMARC.
¿Dónde configuro los servidores de nombres?
En el panel del registrador donde tenés el dominio, no en la zona DNS. Es un punto de confusión frecuente: los registros NS que definen qué servidores son autoritativos se declaran en el registrador, y recién después se editan los registros dentro de esa zona. Si el registrador apunta a los servidores del proveedor A y vos estás editando la zona en el proveedor B, tus cambios no tienen ningún efecto porque nadie consulta esa zona. Ante cualquier duda, consultar los NS del dominio aclara cuál es la zona que se está usando de verdad.
¿Para qué sirve un registro CAA?
Para declarar qué autoridades de certificación tienen permitido emitir certificados para tu dominio. Sin él, cualquier autoridad pública puede emitir un certificado válido para tu nombre si logra pasar una validación, lo que amplía la superficie de un ataque de suplantación. Con un CAA que nombre solo a la autoridad que usás, las demás están obligadas a rechazar el pedido. Es un registro de texto corto, se configura una vez y casi nadie lo pone, aunque el costo de agregarlo sea prácticamente cero.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, foro. Sección Hosting y dominios. Consultas de la comunidad sobre configuración de zonas, migraciones y correo.
- Underc0de, foro. Sección Redes. Diagnóstico de conectividad y resolución de nombres.
Documentación oficial
- IANA. Root Servers. Los trece servidores raíz, sus operadores y su función, citados en esta guía.
- IETF. RFC 1034: Domain Names — Concepts and Facilities. La especificación fundacional del sistema de nombres.
- IETF. RFC 1035: Domain Names — Implementation and Specification. El formato de los mensajes y los tipos de registro.
- IETF. RFC 8659: DNS Certification Authority Authorization (CAA). El registro que limita qué autoridades pueden emitir certificados para tu dominio.
- IANA. DNS Parameters. El registro oficial de todos los tipos de registro existentes.