DNS paso a paso: de un nombre a una IP

Antes de que tu navegador hable con un servidor, tiene que resolver una duda básica: ¿a qué IP me conecto? Esa respuesta para example.com la obtiene mediante DNS y puede cambiar con el tiempo. Entender la cadena de consultas explica muchos “en mi máquina anda”.

La cadena, en un dibujo

flowchart TD
A[Tu máquina] -->|example.com?| B[Resolver / recursivo]
B -->|.com?| C[Root server]
C -->|andá al TLD .com| B
B -->|example.com?| D[Servidor TLD .com]
D -->|andá al autoritativo| B
B -->|example.com?| E[Servidor autoritativo]
E -->|IP actual| B
B -->|IP actual| A

El resolver (normalmente el de tu ISP o uno como 1.1.1.1) hace el trabajo sucio: pregunta al root, después al servidor del TLD (.com, .ar…), y por último al autoritativo del dominio, que tiene la respuesta real. Cada nivel solo sabe a quién derivarte.

Verlo con dig

La respuesta corta, para confirmar a qué IP resuelve:

dig +short example.com

Y la cadena completa, salto por salto:

# +trace realiza la resolución iterativa directamente desde los root servers
dig +trace example.com

En una respuesta normal de dig mirás ANSWER (la respuesta), AUTHORITY (datos de autoridad, si aparecen) y el TTL, la segunda columna de cada registro. Esta salida es ilustrativa; consultá el valor actual con el comando anterior:

;; ANSWER SECTION:
example.com.        3600    IN    A    <IPv4 observada>
;;                  ^TTL          ^tipo  ^valor

Los registros que más vas a ver

Estos ejemplos son esquemáticos, no una consulta actual a example.com:

A       nombre → IPv4             example.com → <IPv4 actual>
AAAA    nombre → IPv6             example.com → <IPv6 actual>
CNAME   alias → otro nombre       www → example.com
MX      a dónde va el mail        example.com → mail.example.com
NS      quién es autoritativo     example.com → ns1.example.com
TXT     texto (SPF, verificación) "v=spf1 include:..."

# Pedir un tipo puntual
dig example.com MX +short
dig example.com NS +short

El criterio

Cuando un dominio “no anda”, DNS es la primera parada:

1. dig +short nombre      → ¿resuelve a algo? ¿a la IP correcta?
2. dig +trace nombre      → ¿en qué salto se rompe la cadena?
3. miro el TTL            → ¿un cambio reciente todavía está cacheado?
4. comparo resolvers      → dig @1.1.1.1 nombre vs el de mi ISP

Evidencia esperada

Para completar este lab y registrar tu aprendizaje técnico, guardá tu writeup con este formato:

[1] Saltos observados con dig +trace (ejemplo sintetizado):
- Salto 1: . (Root Servers)           → deriva a los servidores de .com (a.gtld-servers.net)
- Salto 2: .com (TLD Servers)         → deriva a los autoritativos del dominio (a.iana-servers.net)
- Salto 3: example.com (Autoritativo) → devuelve el registro A vigente

[2] Tabla de registros clave consultados:
- A:     IPv4 del host final
- AAAA:  IPv6 del host final
- MX:    Servidor de intercambio de correo y prioridad
- NS:    Servidor autoritativo delegado para la zona

[3] Writeup de propagación y caché:
Un resolver que guardó la respuesta anterior puede seguir entregándola hasta
que venza el TTL con el que la recibió. El TTL que consulto ahora no revela
cuánto le queda a cada caché ni garantiza un tiempo global de actualización.