¿Qué es DNS? Cómo los nombres de dominio se convierten en direcciones IP

DNS (Domain Name System) asocia nombres como example.com con los datos que el cliente necesita a continuación, casi siempre una dirección IP. Las aplicaciones piden un nombre, y DNS devuelve registros. DNS no es un servidor web, un navegador ni una capa de cifrado. Responde consultas de nombres y nada más.

#La versión corta

Cuando escribes un nombre en el navegador, el sistema operativo o el propio navegador revisa primero su caché. Si no hay una respuesta utilizable, el cliente envía una consulta a un resolver recursivo. Ese resolver suele estar a cargo de tu proveedor de internet, de tu empresa o de un servicio público como 8.8.8.8.

El resolver responde desde su caché cuando puede. Si no puede, recorre la jerarquía de DNS. Pregunta a un servidor raíz qué servidores atienden el dominio de nivel superior (como .com), pregunta a ese servidor qué nameservers usa el dominio y, por último, pregunta por el registro a uno de esos nameservers autoritativos. El servidor autoritativo guarda los datos reales. El resolver guarda la respuesta durante el tiempo que permita el TTL del registro y luego la devuelve al cliente.

El tráfico real añade más pasos: cadenas de CNAME, validación DNSSEC, entradas en un archivo hosts local, transportes de DNS cifrados y varias capas de caché. Cuando DNS termina, el navegador todavía tiene que abrir una conexión, negociar TLS y esperar la respuesta del servidor.

#Registros que verás primero

#Prueba con un dominio que puedas documentar

Usa un dominio que poseas o administres. Si solo quieres practicar, example.com es uno de los nombres reservados para documentación (RFC 2606). Limita tus consultas a nombres que tengas permiso de consultar y no escanees hosts que no tengas permiso para probar.

En Linux o macOS, con dig instalado:

dig example.com A
dig example.com AAAA
dig example.com MX

En Windows, nslookup viene incluido con el sistema operativo:

nslookup example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com

La salida siguiente se capturó en una máquina Windows el 8 de noviembre de 2026 con nslookup, usando el resolver predeterminado de la máquina (dns.google, 8.8.8.8). La respuesta vino de ese resolver, no del servidor autoritativo del dominio. La máquina mostró sus etiquetas en portugués. Aquí aparecen en inglés. Los valores son una fotografía del momento y cambiarán en tu máquina y en ejecuciones posteriores.

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

Name:    example.com
Addresses:  2606:4700:10::ac42:93f3
	  2606:4700:10::6814:179a
	  172.66.147.243
	  104.20.23.154

El mismo resolver devolvió un registro MX para el dominio:

example.com	MX preference = 0, mail exchanger = (root)

Un mail exchanger (root) significa que el destino es un único punto. Es un MX nulo, que indica a los remitentes que el dominio no acepta correo (RFC 7505).

Por último, una consulta TXT para el mismo nombre:

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

example.com	text =

	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
example.com	text =

	"v=spf1 -all"

La segunda cadena es una política SPF. -all dice que ningún servidor está autorizado a enviar correo por este dominio, lo que concuerda con el MX nulo de arriba. La primera cadena es un valor opaco; cadenas así suelen servir para demostrar a un servicio que controlas el dominio. Como dice la tabla, un registro TXT solo muestra lo que el propietario publicó y no prueba nada más.

Dos detalles de esta ejecución. La línea Non-authoritative answer confirma que la respuesta vino de un resolver (de su caché o de una consulta suya), no del servidor del propio dominio. Y las direcciones IPv6 llegaron primero, pero no conviene depender de ese orden: una ejecución posterior puede listarlas distinto o devolver otras direcciones.

Para observar la caché, usa dig. Imprime un número de TTL antes de cada registro. Repite la misma consulta dentro de la ventana del TTL. Si el resolver guardó la respuesta, el segundo número será menor que el primero.

#Caché y por qué cambian las respuestas

Cada registro lleva un TTL, un tiempo en segundos que indica a los resolvers cuánto pueden guardar la respuesta. Un TTL corto permite al propietario mover un servicio rápidamente, pero también hace que más consultas lleguen a los servidores autoritativos. Un TTL largo reduce la carga, pero significa que las respuestas viejas pueden seguir circulando un tiempo después de un cambio.

Por eso, una respuesta es una fotografía del momento. Dos resolvers pueden discrepar durante un cambio, y ambos pueden tener razón para su propia caché. Cuando necesites saber qué publicó el propietario, pregunta directamente a un nameserver autoritativo, por ejemplo con dig example.com A @<nameserver>, usando un servidor de los registros NS del dominio, o sigue la cadena con dig +trace example.com A.

#DNS, OSINT y seguridad

Consultar registros DNS públicos de un dominio es un primer paso habitual en un inventario de activos. Una empresa puede revisar sus propios nombres, sus registros de correo y las direcciones detrás de ellos. Los investigadores suelen cruzar estos datos con registros de certificate transparency e información de propiedad.

Dos cosas no se deducen de una respuesta DNS. Primero, un registro que aparece en un resultado de búsqueda no es permiso para escanear el host al que apunta. Segundo, una dirección IP no identifica a quien opera la máquina. Los proveedores de hosting, las CDN y los servidores compartidos hacen que una misma dirección sirva a muchos sitios sin relación entre sí.

Un registro sospechoso tampoco es prueba de un ataque. Las configuraciones erróneas, los servicios vencidos y los nombres abandonados son comunes. Verifica la respuesta autoritativa, el historial de cambios y al propietario del dominio antes de sacar conclusiones. El envenenamiento de caché y el spoofing son problemas distintos, con evidencias distintas.

#Errores comunes

• Tratar una sola respuesta como permanente. Revisa el TTL y vuelve a consultar después.
• Leer un CNAME como si fuera una dirección IP. Sigue el alias hasta llegar a un registro A o AAAA.
• Suponer que el resolver que usaste es el servidor autoritativo. La salida indica qué servidor respondió.
• Leer un registro TXT como prueba de que un control de seguridad funciona.
• Escanear un host solo porque DNS apuntaba a él. Consultar y escanear son acciones distintas, con permisos distintos.

#Qué estudiar después

DNS es un paso dentro de una solicitud web. Después, estudia cómo HTTP y TLS manejan lo que ocurre cuando el nombre se convierte en dirección, usando las RFC y la documentación listadas en las fuentes. Luego lee el siguiente artículo de esta ruta, sobre OSINT, antes de hacer cualquier consulta como parte de un reconocimiento. Limita tu práctica a dominios y sistemas que poseas o para los que tengas permiso por escrito.