Hands-on Lab

Qué es el DNS y cómo funciona (en la práctica, con dig)

19 de octubre de 2026 2 min 5

0 / 9

Chuleta

¿Te ha servido? No te pierdas el próximo lab

El vídeo tiene subtítulos y transcripción. Todo lo que se ve está escrito, paso a paso, más abajo. Chuleta con todos los comandos

0:00 / 0:00

Empezamos por lo más básico: ¿a quién le pregunta este equipo cuando quiere resolver un nombre? /etc/resolv.conf lista el 'nameserver' al que envía cada consulta —aquí 1.1.1.1, el servidor DNS público de Cloudflare—. La máquina no recorre el árbol DNS por sí misma: delega ese trabajo en ese servidor DNS recursivo.

cat /etc/resolv.conf

Lo hice yo

La consulta más común: un nombre a una dirección IPv4 (registro A). dig +noall +answer nos deja solo la respuesta limpia. La segunda columna es el TTL en segundos: cuánto tiempo puede cachearse este registro antes de volver a preguntar. Esto es 'resolver un nombre' en una sola línea.

dig +noall +answer jacar.es A

Lo hice yo

Aquí se ve CÓMO funciona el DNS por dentro. +trace no confía en el servidor DNS: parte de los servidores raíz (.) y sigue las delegaciones paso a paso —raíz → servidores de .es (h.nic.es) → servidores autoritativos de jacar.es (Cloudflare)— hasta la respuesta final. Cada bloque es una pregunta a un nivel distinto de la jerarquía. Así se resuelve realmente un nombre en Internet.

dig +trace +nodnssec jacar.es

Lo hice yo

El DNS no solo mapea nombres a IPs. Cada dominio tiene varios tipos de registro: A (IPv4), AAAA (IPv6), MX (a qué servidor va el correo), NS (qué servidores son autoritativos del dominio) y TXT (texto libre: SPF, verificaciones, DKIM…). Una sola zona DNS describe muchos aspectos del dominio a la vez.

for t in A AAAA MX NS TXT; do echo "== $t =="; dig +short "$t" jacar.es; done

Lo hice yo

Preguntamos directamente al servidor autoritativo del dominio con +norecurse (sin recursión). Ese servidor es la 'fuente de la verdad' de la zona jacar.es: su respuesta no viene de ninguna caché intermedia, es el dato original. Comparar esto con la consulta recursiva del principio deja claro el reparto de papeles entre servidor recursivo y autoritativo.

NS=$(dig +short NS jacar.es | head -n1); echo "Authoritative NS: $NS"; dig +noall +answer +norecurse @"$NS" jacar.es A

Lo hice yo

El DNS también funciona al revés: de una IP a un nombre (registro PTR), lo que se llama DNS inverso. dig -x lo hace por nosotros consultando el árbol especial in-addr.arpa. Es lo que usan los servidores de correo y las herramientas de diagnóstico para saber 'quién es' una dirección.

dig +short -x 1.1.1.1

Lo hice yo

Hasta ahora hemos usado el servidor DNS de otro. Ahora levantamos el nuestro: unbound, un servidor DNS recursivo y validante en local (127.0.0.1). En lugar de reenviar a un tercero, hará él mismo el recorrido raíz → TLD → autoritativo que vimos con +trace, y cacheará las respuestas. Tener tu propio servidor DNS da privacidad y control.

unbound-checkconf >/dev/null && unbound && echo 'unbound started: recursive + DNSSEC-validating resolver, listening on 127.0.0.1:53'

Lo hice yo

Verificación: le preguntamos directamente a 127.0.0.1 (nuestro unbound) por example.com y nos devuelve la IP. El servidor DNS propio funciona de extremo a extremo: ha resuelto el nombre partiendo de la raíz, sin apoyarse en ningún tercero.

dig +noall +answer +time=5 @127.0.0.1 example.com A

unbound valida DNSSEC por defecto. Al consultar un dominio firmado (cloudflare.com), la línea de flags incluye 'ad' (Authenticated Data): el servidor DNS ha comprobado criptográficamente que la respuesta no fue manipulada, siguiendo la cadena de firmas RRSIG desde la raíz. Sin DNSSEC no habría forma de saber si alguien falseó el registro.

dig @127.0.0.1 +dnssec cloudflare.com A | grep -E 'flags:|RRSIG'

Lo hice yo

La última pieza: el caché. Pedimos wikipedia.org dos veces seguidas a nuestro unbound. En la segunda respuesta el TTL ha bajado ~2 segundos: no volvió a preguntar por Internet, sirvió el registro desde su caché y descontó el tiempo transcurrido. Ese caché es lo que hace que el DNS —miles de millones de consultas al día— sea rápido y no colapse a los servidores autoritativos.

dig +noall +answer +time=10 @127.0.0.1 wikipedia.org A; echo '--- same query again (served from cache) ---'; sleep 2; dig +noall +answer +time=10 @127.0.0.1 wikipedia.org A

Lo hice yo

5 vistas

¿Te ha sido útil este lab? Puntúalo:

Click to rate this post!

[Total: 0 Average: 0]

Transcripción del vídeo

0:00 Así funciona el DNS, con consultas reales.
0:06 Empezamos por lo básico:
0:07 este equipo envía cada consulta al servidor que lista el archivo resolv.conf.
0:13 Aquí es 1.1.1.1, el servidor DNS público de Cloudflare.
0:20 Entiende qué es el DNS y cómo funciona por dentro, ejecutando consultas reales con
0:25 dig.
0:27 DNS.
0:28 La agenda telefónica de Internet:
0:30 traduce nombres de dominio (jacar.es) en direcciones IP que las máquinas pueden
0:35 usar.
0:36 Cómo se resuelve un nombre.
0:39 Raíz, TLD (.es), Autoritativo, Respuesta.
0:44 En este lab.
0:45 Resolver nombres y ver los tipos de registro.
0:49 Trazar la resolución desde la raíz.
0:51 Levantar tu propio servidor DNS con unbound.
0:55 Validar con DNSSEC y ver la caché en acción.
0:59 La consulta más común:
1:01 de un nombre a una dirección IPv4, el registro A.
1:06 La segunda columna es el TTL, los segundos que esa respuesta puede quedarse en caché.
1:13 dig +trace.
1:14 No confía en el servidor DNS:
1:17 parte de los servidores raíz y sigue las delegaciones paso a paso hasta el
1:21 autoritativo.
1:23 Con la opción trace, dig no confía en el servidor DNS.
1:27 Empieza en los servidores raíz y sigue cada delegación:
1:31 la raíz, los servidores de .es y, al final, los autoritativos de jacar.es.
1:39 Un dominio tiene varios tipos de registro:
1:41 A y AAAA para las direcciones, MX para el correo, NS para sus servidores
1:47 autoritativos y TXT para texto libre.
1:52 Ahora preguntamos directamente al servidor autoritativo, sin recursión.
1:56 Su respuesta no sale de ninguna caché:
1:59 es el dato original de la zona.
2:02 El DNS también funciona al revés.
2:05 Con la opción x, dig pasa de una IP a un nombre:
2:09 es el registro PTR, el que consultan los servidores de correo.
2:15 Servidor DNS recursivo.
2:17 En lugar de reenviar a un tercero, unbound recorre él mismo la jerarquía (raíz a TLD
2:23 a autoritativo), valida y cachea las respuestas.
2:27 Hasta aquí usamos el servidor DNS de otro.
2:31 Ahora arrancamos el nuestro, unbound, en
2:34 127.0.0.1.
2:37 Recorre él mismo la jerarquía y guarda las respuestas en caché.
2:42 Comprobamos que funciona:
2:44 preguntamos a 127.0.0.1 por example.com y
2:50 unbound devuelve la IP, resuelta desde la raíz sin ningún tercero.
2:55 DNSSEC.
2:56 Una cadena de firmas criptográficas desde la raíz que demuestra que la respuesta no
3:01 fue manipulada.
3:02 El flag ad confirma la validación.
3:05 Unbound valida DNSSEC por defecto.
3:09 Al consultar cloudflare.com aparece el flag ad:
3:13 la firma de la respuesta se ha comprobado desde la raíz.
3:17 TTL y caché.
3:19 El TTL dice cuántos segundos puede guardarse un registro.
3:23 El servidor DNS lo sirve desde caché hasta que caduca, evitando repetir la consulta.
3:30 Por último, la caché.
3:32 Pedimos wikipedia.org dos veces seguidas.
3:36 En la segunda respuesta el TTL ha bajado:
3:39 unbound la sirve desde su caché sin volver a preguntar.

El DNS es una de esas piezas de infraestructura que solo notas cuando falla. En este laboratorio lo abrimos en canal con dig: verás una resolución real de nombre a IP, la traza completa desde los servidores raíz hasta el autoritativo, los tipos de registro que describen un dominio (A, AAAA, MX, NS, TXT) y, al final, tu propio servidor DNS recursivo validando DNSSEC y sirviendo desde caché.

Si trabajas con contenedores, el DNS aparece constantemente: por eso encaja con nuestro laboratorio de Portainer con Docker Compose , con las guías de la categoría Herramientas y con el resto de laboratorios prácticos. Para profundizar en la especificación original, la referencia canónica es el RFC 1035, para una introducción visual el centro de aprendizaje de Cloudflare, y la lista oficial de servidores raíz en IANA.

Preguntas frecuentes

¿Qué es el DNS?

El DNS (Sistema de Nombres de Dominio) es la agenda telefónica de Internet: traduce nombres de dominio legibles como jacar.es en las direcciones IP que las máquinas necesitan para conectarse. Sin él tendrías que memorizar direcciones numéricas para cada servicio.

¿Cuál es la diferencia entre un servidor DNS recursivo y un servidor autoritativo?

El servidor DNS recursivo (el de tu router, tu ISP o uno público como 1.1.1.1) hace el trabajo de recorrer la jerarquía por ti y cachea la respuesta. El servidor autoritativo es la fuente de la verdad de una zona: publica los registros originales del dominio y no depende de ninguna caché.

¿Para qué sirve DNSSEC?

DNSSEC añade una cadena de firmas criptográficas desde la raíz que prueba que una respuesta DNS no ha sido manipulada en el camino. Un servidor DNS validante como unbound comprueba esas firmas y marca la respuesta con el flag 'ad' (Authenticated Data) cuando son correctas.

Chuleta

```
cat /etc/resolv.conf
```
```
dig +noall +answer jacar.es A
```
```
dig +trace +nodnssec jacar.es
```

for t in A AAAA MX NS TXT; do echo "== $t =="; dig +short "$t" jacar.es; done

NS=$(dig +short NS jacar.es | head -n1); echo "Authoritative NS: $NS"; dig +noall +answer +norecurse @"$NS" jacar.es A

```
dig +short -x 1.1.1.1
```

unbound-checkconf >/dev/null && unbound && echo 'unbound started: recursive + DNSSEC-validating resolver, listening on 127.0.0.1:53'

dig @127.0.0.1 +dnssec cloudflare.com A | grep -E 'flags:|RRSIG'

dig +noall +answer +time=10 @127.0.0.1 wikipedia.org A; echo '--- same query again (served from cache) ---'; sleep 2; dig +noall +answer +time=10 @127.0.0.1 wikipedia.org A

¿Te ha servido? No te pierdas el próximo lab

Suscríbete a la newsletter

Preguntas frecuentes

¿Qué es el DNS?

¿Cuál es la diferencia entre un servidor DNS recursivo y un servidor autoritativo?

¿Para qué sirve DNSSEC?

Chuleta