DNS y sus registros: A, AAAA, CNAME, MX, NS y PTR — diagnóstico (4.4)

📋 En esta lección

"No funciona Internet" significa, la mitad de las veces, "no funciona el DNS". Aquí entiendes la resolución completa (recursiva, con jerarquía y cachés), los tipos de registro que importan (A, AAAA, CNAME, MX, NS, PTR), cómo se diagnostica con nslookup, y el papel del DNS en un router IOS — como cliente y como pequeño servidor.

Qué resuelve DNS

Las personas usan nombres (subnetacademy.com); los paquetes usan IPs. DNS (Domain Name System) es la base de datos distribuida y jerárquica que traduce entre ambos — y sobre UDP/TCP 53 (UDP para consultas normales; TCP para respuestas grandes y transferencias de zona — lección 1.6).

Ya viste el síntoma canónico (lección 4.6): ping 8.8.8.8 responde, ping google.com no → routing sano, resolución rota. Esta lección es todo lo que hay detrás de ese diagnóstico.

La resolución, paso a paso

Cuando tu navegador pide www.ejemplo.com:

1. Cachés locales primero: la del navegador, la del sistema operativo (ipconfig /displaydns), el archivo hosts. Si está, fin.
2. Pregunta al resolver configurado (el DNS de tu red, aprendido por DHCP — lección 8.1): una consulta recursiva — "dame la respuesta final, apáñatelas".
3. El resolver hace el trabajo iterativo si no lo tiene en caché: pregunta a un servidor raíz (te dirijo a los de .com) → a los TLD de .com (te dirijo a los autoritativos de ejemplo.com) → al autoritativo del dominio, que tiene la respuesta real.
4. La respuesta vuelve al cliente y se cachea en cada nivel durante su TTL — la próxima consulta muere en la caché.

Las cachés son la clave del rendimiento… y de las averías con retardo: cambias una IP en el DNS y el mundo tarda hasta el TTL en enterarse (por eso antes de una migración se baja el TTL con antelación).

Los registros que debes dominar

Matices de cada uno que caen en preguntas y en tickets:

• A y AAAA conviven: un nombre con ambos habilita dual stack — y el cliente probará IPv6 primero (el caso "lento pero funciona" de la lección 6.5 cuando el camino v6 está roto).
• CNAME encadena la resolución: el cliente que pide el alias recibe el CNAME y la resolución continúa con el nombre canónico. Un CNAME no puede convivir con otros registros para el mismo nombre (por eso la raíz del dominio no puede ser CNAME).
• MX lleva prioridad (menor = preferido): 10 mail1 y 20 mail2 = mail2 es el respaldo. El correo es el servicio más sensible al DNS — la mitad de los desastres de migración de correo son registros MX.
• PTR vive en zonas especiales (in-addr.arpa / ip6.arpa) gestionadas por quien posee el bloque IP (tu ISP, normalmente). Los servidores de correo ajenos comprueban tu PTR para aceptarte el correo — un servidor SMTP sin PTR coherente acaba en spam.

Diagnóstico con nslookup

La herramienta universal (Windows/Linux/macOS; en Linux además dig, más detallado):

C:\> nslookup www.ejemplo.com
Servidor:  dns.empresa.local          ← QUIÉN responde (tu resolver)
Address:  10.1.30.10

Respuesta no autoritativa:            ← vino de caché, no del autoritativo
Nombre:  www.ejemplo.com
Addresses:  203.0.113.10

! Preguntar por un tipo concreto:
C:\> nslookup -type=MX ejemplo.com
C:\> nslookup -type=AAAA www.ejemplo.com

! Saltarse el resolver local y preguntar a otro servidor (¡la prueba clave!):
C:\> nslookup www.ejemplo.com 8.8.8.8

La tercera forma es la que corta los diagnósticos por la mitad: si tu resolver falla pero 8.8.8.8 responde, el problema es tu servidor DNS (caído, sin salida, con la zona rota); si ninguno responde, mira la conectividad o el dominio mismo. "Respuesta no autoritativa" no es un error — significa respuesta cacheada.

El complemento local: ipconfig /flushdns (Windows) vacía la caché del sistema — el gesto tras corregir un registro, para no esperar al TTL local.

DNS en el router IOS

El router juega dos papeles menores pero examinables:

Cliente DNS — para que tus ping nombre y traceroute nombre funcionen desde el propio IOS:

R1(config)# ip domain-lookup             ← activado por defecto
R1(config)# ip name-server 10.1.30.10 8.8.8.8
R1(config)# ip domain-name subnetacademy.local

💡 💡 El clásico molesto: el typo que se queda pensando

Con ip domain-lookup activo y sin name-server alcanzable, cualquier comando mal tecleado en EXEC ("shw ip route") se interpreta como un nombre de host a resolver… y la CLI se congela un buen rato intentándolo. En labs sin DNS se desactiva (no ip domain-lookup) — y ahora ya sabes por qué media Internet lo lleva en sus plantillas de laboratorio. (Ctrl+Shift+6 aborta el intento.)

Servidor DNS básico (ip dns server + entradas ip host nombre ip) — suficiente para un lab o una red diminuta; en cualquier red real, el DNS es un servicio dedicado (Windows Server, BIND, o el propio proveedor).

Casos de uso y averías típicas

• La web migrada que "no cambia": moviste la web a otra IP, actualizaste el A… y media empresa sigue llegando a la vieja. TTL + cachés: paciencia o flush. Prevención: bajar TTL antes de migrar.
• Correo que no llega tras un cambio de proveedor: MX apuntando al proveedor viejo, o prioridades invertidas. nslookup -type=MX lo muestra en segundos.
• "Internet caído" en toda la oficina con routing perfecto: el resolver corporativo caído. Los clientes con DNS secundario configurado ni se enteran — la razón de que el DHCP reparta siempre dos servidores DNS.
• Un servicio interno resuelve distinto que desde fuera: split DNS (vistas interna/externa) — no es avería, es diseño; pero hay que saber que existe para no perseguir fantasmas.

Relación con otros conceptos

• El puerto 53 y el reparto UDP/TCP vienen de la lección 1.6; el DNS que reparte DHCP, de la 8.1 (y en IPv6, del RA con RDNSS — lección 6.3).
• El escalón "ping IP sí / ping nombre no" pertenece a la escalera de diagnóstico de las lecciones 4.5-4.6.
• Los AAAA y el dual stack conectan con el caso "lento pero funciona" de la lección 6.5.
• El filtrado del puerto 53 y la inspección DNS reaparecen en seguridad (Módulo 10).

Resumen

DNS traduce nombres ↔ IPs sobre el puerto 53 (UDP consultas, TCP zonas), con resolución recursiva del cliente al resolver e iterativa del resolver por la jerarquía (raíz → TLD → autoritativo), cacheando cada respuesta durante su TTL — la causa de que los cambios "tarden". Registros: A/AAAA (IPv4/IPv6), CNAME (alias), MX (correo, con prioridad — menor gana), NS (autoritativos), PTR (inverso — vital para el correo saliente). Diagnóstico: nslookup (tipo con -type=, y la prueba reina: preguntar a otro servidor — si 8.8.8.8 responde y tu resolver no, ya tienes culpable), ipconfig /flushdns tras cambios. En IOS: ip name-server para resolver desde el router, y no ip domain-lookup en labs para que los typos no congelen la CLI.

Fuentes oficiales

• RFC 1034 — Domain Names: Concepts and Facilities
• RFC 1035 — Domain Names: Implementation and Specification
• RFC 9499 — DNS Terminology (el glosario oficial, muy útil)