Los ordenadores se encuentran en internet por su dirección IP, un número como 3.151.169.32. Las personas preferimos nombres como decodigo.com. El DNS (Domain Name System, sistema de nombres de dominio) es lo que traduce unos a otros: la agenda de contactos de internet. Cada vez que abres una web, envías un correo o una app se conecta a su servidor, antes hay una consulta DNS. Esta guía explica cómo funciona, desde cero, con esquemas y consultas reales.
El DNS en tres ideas
- Traduce nombres a direcciones. Tú escribes
decodigo.com; el DNS responde «está en3.151.169.32» y el navegador se conecta a esa dirección. - Nadie tiene la agenda entera. Está repartida en millones de servidores organizados como un árbol: cada uno sabe una parte y sabe a quién preguntar por el resto.
- Las respuestas se recuerdan. Cada respuesta trae un tiempo de vida, el TTL, y mientras dura se guarda en caché. Por eso casi todas las consultas se responden en milisegundos.
Un nombre es un árbol
Los nombres de dominio se leen de derecha a izquierda, de lo general a lo concreto. Arriba del todo está la raíz; debajo, los dominios de primer nivel (.com, .org, .mx, .es…); debajo, cada dominio registrado, y su dueño puede crear dentro los nombres que quiera, como www.
Qué pasa cuando escribes una dirección
En la consulta intervienen dos tipos de servidores. El resolvedor es el que hace el trabajo por ti: normalmente el de tu proveedor de internet, o uno público como 1.1.1.1 (Cloudflare) u 8.8.8.8 (Google). Los servidores autoritativos son los que tienen la información oficial de cada nivel del árbol.
Ese recorrido se puede ver con dig +trace, que hace las preguntas una a una, como un resolvedor. Esta es la consulta real de decodigo.com, abreviada:
dig +trace decodigo.com
salida, abreviada: se han dejado dos servidores de cada lista. 510418 IN NS a.root-servers.net. . 510418 IN NS b.root-servers.net. … (13 servidores raíz, de la a a la m) ;; Received 239 bytes from 1.1.1.1#53(1.1.1.1) in 50 ms com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. … (13 servidores de .com) ;; Received 865 bytes from 192.33.4.12#53(c.root-servers.net) in 33 ms decodigo.com. 172800 IN NS ns1.dns-parking.com. decodigo.com. 172800 IN NS ns2.dns-parking.com. ;; Received 177 bytes from 192.26.92.30#53(c.gtld-servers.net) in 83 ms decodigo.com. 14400 IN A 3.151.169.32 ;; Received 57 bytes from 162.159.24.201#53(ns1.dns-parking.com) in 63 ms
Cuatro saltos: la raíz manda a los servidores de .com, estos a los de decodigo.com (dns-parking.com, los de su proveedor de alojamiento) y estos dan la dirección. Los servidores raíz tienen 13 nombres, de la a a la m, pero cada uno tiene muchísimas copias repartidas por el mundo.
dig: preguntar al DNS desde la terminal
dig es la herramienta de referencia. Viene en macOS y en Linux (en Debian y Ubuntu, en el paquete bind9-dnsutils). En Windows se usa nslookup, que verás más abajo. La forma básica es dig nombre; con @ eliges a qué resolvedor preguntas:
dig @1.1.1.1 decodigo.com
salida; <<>> DiG 9.20.29-1~deb13u1-Debian <<>> @1.1.1.1 decodigo.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16951 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;decodigo.com. IN A ;; ANSWER SECTION: decodigo.com. 14368 IN A 3.151.169.32 ;; Query time: 52 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Wed Oct 14 14:03:34 UTC 2026 ;; MSG SIZE rcvd: 57
Asusta un poco, pero solo hay tres cosas que mirar: status: NOERROR (ha ido bien), la ANSWER SECTION con la respuesta, y Query time, lo que tardó. La línea de respuesta se lee así:
| decodigo.com. | 14400 | IN | A | 3.151.169.32 |
|---|---|---|---|---|
| el nombre, con el punto de la raíz al final | el TTL: se puede guardar 14400 segundos (4 horas) | la clase: internet, siempre | el tipo de registro | el dato: la dirección IP |
Si solo quieres el dato, añade +short:
dig +short decodigo.com
salida3.151.169.32
Los tipos de registro que más verás
Un dominio no guarda solo su dirección. Cada dato es un registro de un tipo distinto, y se pide añadiendo el tipo al final: dig decodigo.com MX.
| Tipo | Para qué sirve | Ejemplo real |
|---|---|---|
A | La dirección IPv4 del nombre | decodigo.com → 3.151.169.32 |
AAAA | La dirección IPv6 (más larga, la del futuro) | decodigo.com no tiene: la consulta vuelve vacía |
CNAME | Un alias: «este nombre es otro nombre» | www.github.com → github.com |
MX | Qué servidores reciben el correo del dominio, por prioridad | 5 mx1.hostinger.com |
NS | Qué servidores son los autoritativos del dominio | ns1.dns-parking.com |
TXT | Texto libre: verificaciones y reglas antispam (SPF) | v=spf1 include:… |
PTR | La búsqueda inversa: de IP a nombre | 1.1.1.1 → one.one.one.one |
Así responden de verdad. +noall +answer deja solo la respuesta:
dig +noall +answer decodigo.com MX
salida: el número es la prioridad; el más bajo se intenta primerodecodigo.com. 14400 IN MX 5 mx1.hostinger.com. decodigo.com. 14400 IN MX 10 mx2.hostinger.com.
dig +noall +answer www.github.com
salida: primero el alias y después la dirección del nombre al que apuntawww.github.com. 3379 IN CNAME github.com. github.com. 22 IN A 140.82.114.4
dig +noall +answer decodigo.com TXT
salida, solo la línea SPF: qué servidores pueden enviar correo en nombre del dominiodecodigo.com. 14400 IN TXT "v=spf1 include:_spf.mail.hostinger.com ~all"
dig +noall +answer -x 1.1.1.1
salida: la búsqueda inversa1.1.1.1.in-addr.arpa. 1036 IN PTR one.one.one.one.
www.decodigo.com tiene su propio registro A con la misma dirección; en GitHub, www.github.com es un alias (CNAME) de github.com. Si una web funciona sin www pero no con él, o al revés, casi siempre es porque falta uno de los dos registros.nslookup y host: las alternativas
nslookup está en Windows, macOS y Linux, y host da respuestas más legibles. Las dos sirven para lo mismo: aquí, preguntando a 1.1.1.1.
nslookup decodigo.com 1.1.1.1
salidaServer: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: decodigo.com Address: 3.151.169.32
«Non-authoritative answer» no es un error: significa que la respuesta viene de un resolvedor (posiblemente de su caché), no del servidor oficial del dominio.
host decodigo.com 1.1.1.1
salidaUsing domain server: Name: 1.1.1.1 Address: 1.1.1.1#53 Aliases: decodigo.com has address 3.151.169.32 decodigo.com mail is handled by 5 mx1.hostinger.com. decodigo.com mail is handled by 10 mx2.hostinger.com.
La caché y el TTL: por qué los cambios «tardan en propagarse»
Para comprobarlo montamos un resolvedor propio y le preguntamos tres veces lo mismo, con unos segundos entre cada consulta:
dig @127.0.0.1 example.com
salida de las tres consultas, solo la respuesta y el tiempoexample.com. 300 IN A 104.20.23.154 example.com. 300 IN A 172.66.147.243 ;; Query time: 433 msec example.com. 297 IN A 172.66.147.243 example.com. 297 IN A 104.20.23.154 ;; Query time: 0 msec example.com. 292 IN A 104.20.23.154 example.com. 292 IN A 172.66.147.243 ;; Query time: 0 msec
La primera vez el resolvedor recorrió todo el árbol y tardó 433 ms; las siguientes las sacó de su caché en 0 ms, y el TTL fue bajando. Cuando llegue a cero, la olvidará y volverá a preguntar. Esto explica la famosa propagación: no es que el cambio viaje lentamente, es que cada resolvedor del mundo sigue usando el dato viejo hasta que le caduca. Con un TTL de 4 horas, como el de decodigo.com, un cambio de IP puede tardar hasta 4 horas en verse en todas partes; si lo que cambias son los servidores NS, los de .com los guardan dos días (172800 segundos, lo verás en el +trace).
Tu propio equipo y tu navegador también tienen caché. Si un cambio ya se ve con dig pero no en tu equipo, vacíala (estas órdenes no se ejecutaron en las pruebas, que eran en Linux sin escritorio):
| Sistema | Orden |
|---|---|
| Windows | ipconfig /flushdns |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Linux con systemd-resolved (Ubuntu y otros) | resolvectl flush-caches |
El archivo hosts: tu agenda particular
Antes de preguntar al DNS, el sistema mira el archivo hosts: /etc/hosts en Linux y macOS, y C:\Windows\System32\drivers\etc\hosts en Windows. Lo que pongas ahí manda sobre el DNS, solo en tu equipo. Es útil para dar nombre a máquinas de tu red o para probar una web nueva antes de cambiar el DNS. Para editarlo hacen falta permisos de administrador.
getent hosts miservidor.local, antes(sin respuesta)
echo "192.168.1.50 miservidor.local" | sudo tee -a /etc/hosts
getent hosts miservidor.local, después192.168.1.50 miservidor.local
getent hosts pregunta igual que lo hacen los programas, mirando primero el archivo hosts. dig y nslookup, en cambio, van directos al DNS y no lo ven: si alguna vez dan respuestas distintas de las del navegador, revisa este archivo.
Los errores que más vas a ver
NXDOMAIN: ese nombre no existe
El dominio o el subdominio no está registrado, o hay una errata. En el navegador aparece como DNS_PROBE_FINISHED_NXDOMAIN o «No se puede acceder a este sitio». La respuesta trae el registro SOA del dominio, que dice cuánto tiempo puede guardarse también ese «no existe» (aquí, 600 segundos).
dig no-existe-esta-pagina.decodigo.com
salida, extracto;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31073 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; AUTHORITY SECTION: decodigo.com. 600 IN SOA ns1.dns-parking.com. dns.hostinger.com. 2026100904 10000 2400 604800 600
SERVFAIL: el resolvedor no pudo responder
Algo falla en la cadena: los servidores del dominio no responden o, como aquí, su firma de seguridad (DNSSEC) no es válida y el resolvedor se niega a dar una respuesta que podría ser falsa. dnssec-failed.org es un dominio de prueba roto a propósito:
dig dnssec-failed.org
salida, extracto;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59470 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; Query time: 1139 msec
dig +cd +short dnssec-failed.org
salida con +cd, que desactiva la comprobación: la dirección existe, pero su firma no es válida96.99.227.255
«no servers could be reached»: no hay nadie al otro lado
No responde el resolvedor: no hay conexión, la IP del resolvedor está mal o un cortafuegos bloquea el puerto 53. Aquí preguntamos a una dirección reservada para documentación, donde no hay ningún servidor:
dig @192.0.2.1 decodigo.com
salida;; communications error to 192.0.2.1#53: timed out ; <<>> DiG 9.20.29-1~deb13u1-Debian <<>> @192.0.2.1 +tries=1 +time=2 decodigo.com ; (1 server found) ;; global options: +cmd ;; no servers could be reached
Seguridad y privacidad
- El DNS clásico viaja sin cifrar, por el puerto 53. Quien vea tu tráfico (el wifi, tu proveedor) puede ver qué nombres consultas, aunque luego la web vaya por HTTPS. Las versiones cifradas, DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT), lo evitan, y los navegadores y sistemas actuales permiten activarlas.
- DNSSEC firma las respuestas para que nadie pueda falsificarlas por el camino. Un resolvedor que lo comprueba marca las respuestas válidas con el indicador
ady rechaza las inválidas, como el SERVFAIL de antes. La firma depende de una clave maestra en la raíz, que acaba de cambiar: lo contamos en la noticia del cambio de la llave maestra del DNS. - Cambiar de resolvedor es fácil: en la configuración de red de tu equipo o de tu router puedes poner
1.1.1.1(Cloudflare),8.8.8.8(Google) o9.9.9.9(Quad9) en lugar del de tu proveedor.
dig +dnssec example.com
extracto: el indicador ad (authenticated data) dice que la firma es válida;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ; EDNS: version: 0, flags: do; udp: 1232
Resumen
| Quiero… | Orden |
|---|---|
| saber la IP de un nombre | dig +short decodigo.com |
| preguntar a un resolvedor concreto | dig @1.1.1.1 decodigo.com |
| ver un tipo de registro | dig decodigo.com MX (o NS, TXT, AAAA…) |
| ver solo la respuesta | dig +noall +answer decodigo.com |
| ver el camino desde la raíz | dig +trace decodigo.com |
| buscar el nombre de una IP | dig -x 1.1.1.1 |
| lo mismo en Windows | nslookup decodigo.com |
| saber qué ve mi sistema (con hosts) | getent hosts decodigo.com |
| olvidar lo guardado en mi equipo | ipconfig /flushdns · resolvectl flush-caches |
Esta guía forma serie con las de los métodos HTTP, HTTPS por dentro y SSH: el DNS es siempre el primer paso, antes de cualquier conexión.
Las consultas se ejecutaron el 14 de octubre de 2026 con dig 9.20 en un contenedor desechable de Debian 13, preguntando a 1.1.1.1 y a un resolvedor Unbound propio; las salidas están copiadas de esa ejecución, y los datos de decodigo.com, github.com o example.com pueden haber cambiado desde entonces. El funcionamiento del DNS está definido en los RFC 1034 y RFC 1035; la terminología, en el RFC 9499.
Fuente: IETF, RFC 1034, «Domain Names: Concepts and Facilities»