DNS y resolución de nombres en redes de computadoras

DNS como servicio crítico en servidores: nombre vs. dirección

DNS (Domain Name System) es el sistema que traduce nombres legibles (por ejemplo, app.empresa.local o www.ejemplo.com) a direcciones (por ejemplo, 192.0.2.10 o 2001:db8::10). En administración de servidores, DNS es crítico porque casi todo servicio moderno depende de él: balanceadores, proxies, correo, autenticación, monitoreo, automatización (scripts) y despliegues. Un servidor puede estar “arriba” y aun así parecer caído si el nombre no resuelve o resuelve a un destino incorrecto.

Ideas clave para operar DNS en entornos reales:

• El nombre es una etiqueta (cambia con facilidad); la dirección es el destino de red (puede cambiar por migraciones, HA, cloud, etc.).
• DNS no “comprueba” si el servidor responde: solo entrega registros. Si el registro apunta mal, el cliente irá al lugar equivocado.
• La consistencia y el tiempo importan: cachés y TTL determinan cuánto tarda en propagarse un cambio.

Cómo funciona la resolución: recursiva e iterativa

Componentes típicos

• Stub resolver: el cliente (SO/aplicación) que pregunta “¿cuál es la IP de este nombre?”.
• Resolver recursivo: servidor DNS que resuelve “por ti” (por ejemplo, un DNS corporativo, el del ISP o un servicio público). Mantiene caché.
• Servidores autoritativos: los que “saben la verdad” de una zona (por ejemplo, los NS de ejemplo.com).

Resolución recursiva (la más común para clientes)

El cliente pregunta a su resolver configurado: “Dame la respuesta final”. El resolver recursivo se encarga de consultar lo necesario y devuelve una respuesta completa (o un error).

Ventajas operativas: menos tráfico desde clientes, caché centralizada, control (filtrado, split-horizon, políticas internas).

Resolución iterativa (cómo consultan los resolvers)

Cuando el resolver recursivo no tiene la respuesta en caché, realiza consultas iterativas: pregunta a un servidor y recibe una “referencia” (por ejemplo, “pregunta a estos NS”). Repite hasta llegar al autoritativo correcto.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

En la práctica, el flujo típico es: raíz (.) → TLD (por ejemplo, .com) → autoritativos de ejemplo.com → respuesta final.

Caché y TTL: por qué los cambios no se ven “al instante”

El resolver recursivo guarda respuestas en caché para acelerar futuras consultas. Cada registro viene con un TTL (Time To Live) en segundos, que indica cuánto tiempo puede mantenerse en caché antes de volver a preguntar.

• TTL alto (p. ej., 86400): menos carga y consultas, pero cambios tardan más en reflejarse.
• TTL bajo (p. ej., 60–300): cambios rápidos, pero más consultas y mayor dependencia del DNS autoritativo.

Buenas prácticas operativas:

• Antes de una migración, baja el TTL con anticipación (horas o días antes, según el TTL vigente) para que el cambio de IP se propague rápido.
• Tras estabilizar, sube el TTL para reducir carga.
• Recuerda que existen cachés en múltiples capas: resolver corporativo, caché del SO, caché del navegador, y a veces caché en aplicaciones.

Registros DNS esenciales (y cuándo se usan)

Detalles importantes por tipo

• A/AAAA: un nombre puede tener múltiples A/AAAA (round-robin). No es balanceo real, pero distribuye consultas.
• CNAME: un nombre con CNAME no debe tener otros registros “directos” del mismo nombre (en la práctica, evita mezclar). Útil para apuntar a un destino que cambia.
• MX: la prioridad más baja (número menor) se intenta primero. Los MX deben apuntar a nombres que resuelvan (A/AAAA).
• TXT: crítico en correo (SPF/DKIM/DMARC) y en validaciones (por ejemplo, emisión de certificados o verificación de servicios). Un TXT mal formado puede romper entregabilidad.
• NS: define quién es autoritativo. Si la delegación está mal, el dominio “desaparece” para el mundo aunque tus servidores estén bien.
• PTR: muchos sistemas de correo verifican reverse DNS; ausencia o inconsistencia (PTR que no coincide con A/AAAA) puede afectar reputación.

Zonas directa e inversa: dos caras de la misma operación

Zona directa (forward)

Resuelve nombres a direcciones (A/AAAA) y otros metadatos (MX, TXT, etc.). Ejemplo conceptual: la zona ejemplo.com contiene registros para www, mail, vpn, etc.

Zona inversa (reverse)

Resuelve direcciones a nombres mediante PTR. Para IPv4 se usa in-addr.arpa; para IPv6, ip6.arpa. En entornos corporativos, la zona inversa suele estar bajo control del equipo de redes/infraestructura (o del proveedor si es IP pública).

Chequeo operativo típico: si 203.0.113.10 tiene PTR a mail.ejemplo.com, entonces mail.ejemplo.com debería resolver a 203.0.113.10 (consistencia forward-confirmed reverse DNS, aunque no siempre obligatorio).

Errores comunes de resolución y cómo se manifiestan

Fallas por configuración de resolvers (cliente o servidor)

• Resolver equivocado: el servidor apunta a un DNS que no conoce zonas internas (por ejemplo, usa DNS público para empresa.local).
• Orden de resolvers: si el primero falla o responde lento, todo “se siente” lento (timeouts). Muchos clientes esperan varios segundos antes de probar el siguiente.
• DNS sobre VPN: al conectarte a una VPN, el resolver puede cambiar; si no se enruta bien, se rompe acceso a recursos internos.
• Firewall/ACL: UDP/TCP 53 bloqueado. UDP es común, pero TCP se usa para respuestas grandes y transferencias; bloquear TCP puede causar fallas intermitentes.

Split-horizon (DNS interno vs externo)

Split-horizon (o split-brain DNS) significa que el mismo nombre puede resolver a distintas direcciones según el origen de la consulta (interna o externa). Ejemplo: app.ejemplo.com resuelve a una IP privada dentro de la red corporativa, y a una IP pública desde Internet.

Riesgos típicos:

• Clientes internos usando DNS externo: terminan yendo por Internet a un servicio que debería ser interno.
• Registros inconsistentes: el interno apunta a un backend nuevo y el externo al viejo (o viceversa), generando comportamientos “fantasma”.

Impacto de una mala resolución en servicios (casos reales)

Web y APIs

• Timeouts si el nombre resuelve a una IP inaccesible desde esa red.
• Errores TLS si el nombre apunta a un servidor con certificado distinto (por ejemplo, CNAME mal dirigido).
• Intermitencia si hay múltiples A/AAAA y uno está caído.

Correo

• No llega correo si MX apunta a un host que no resuelve o resuelve mal.
• Rechazos o spam por TXT (SPF/DKIM/DMARC) incorrectos o por falta de PTR en IPs de salida.

Autenticación y directorio

• Fallos de login si clientes no encuentran controladores/servicios por nombre.
• Latencia si el resolver tarda en responder y la app espera DNS antes de continuar.

Guía práctica: comprobar resolución con nslookup y dig

Objetivo del laboratorio

Aprender a diagnosticar: (1) si el nombre resuelve, (2) qué responde (A/AAAA/CNAME/MX/TXT/NS/PTR), (3) desde qué resolver, (4) si hay caché/TTL involucrado, y (5) si el problema es autoritativo o del resolver recursivo.

Paso a paso con nslookup (rápido y disponible en muchos sistemas)

1) Consultar A/AAAA básicos:

nslookup www.ejemplo.com

Observa: “Server” (resolver usado) y “Address” (IP del resolver). Si el resolver no es el esperado, ya tienes una pista.

2) Consultar un tipo específico (MX):

nslookup -type=MX ejemplo.com

3) Consultar TXT (SPF/validaciones):

nslookup -type=TXT ejemplo.com

4) Probar contra un resolver específico (útil para comparar interno vs externo):

nslookup www.ejemplo.com 1.1.1.1

Repite con tu DNS interno y compara resultados.

Paso a paso con dig (más completo)

1) Ver respuesta y TTL:

dig www.ejemplo.com

Busca en la sección ANSWER el TTL y el tipo de registro.

2) Consultar AAAA (IPv6):

dig AAAA www.ejemplo.com

3) Seguir la cadena de resolución (útil para ver delegaciones):

dig +trace www.ejemplo.com

Si el trace se rompe en algún punto (por ejemplo, no encuentra NS válidos), el problema suele ser de delegación/autoridad.

4) Consultar NS (autoridad de la zona):

dig NS ejemplo.com

5) Consultar MX y verificar que los hosts de MX resuelven:

dig MX ejemplo.com

Luego, por cada host devuelto:

dig A mail1.ejemplo.com; dig AAAA mail1.ejemplo.com

6) Reverse DNS (PTR) para una IP:

dig -x 203.0.113.10

7) Comparar split-horizon (interno vs externo):

dig @DNS_INTERNO app.ejemplo.com A; dig @DNS_PUBLICO app.ejemplo.com A

Si difieren, confirma que esa diferencia es intencional y documentada.

Laboratorio: identificar fallas por configuración de resolvers

Escenario

Un servidor no puede acceder a repo.empresa.local (servicio interno). El ping por IP funciona, pero por nombre falla.

Pasos

1) Ver qué resolvers usa el sistema (según SO). En Linux moderno, suele ser:

cat /etc/resolv.conf

Si ves un DNS público (o uno que no pertenece a tu red interna), es probable que no conozca empresa.local.

2) Probar resolución contra el resolver configurado:

dig repo.empresa.local

3) Probar contra el DNS interno correcto:

dig @10.0.0.53 repo.empresa.local

4) Interpretación:

• Si con el DNS interno resuelve y con el configurado no, el problema es configuración del resolver (o políticas de VPN/DHCP).
• Si no resuelve ni con el interno, el problema es zona/registro (o permisos/ACL DNS).

5) Validar si hay CNAME encadenado:

dig repo.empresa.local CNAME

Si hay CNAME, asegúrate de que el destino final tenga A/AAAA.

Laboratorio: split-horizon interno/externo sin sorpresas

Escenario

app.ejemplo.com debe resolver a IP privada dentro de la red y a IP pública fuera. Usuarios internos reportan lentitud y rutas extrañas.

Pasos

1) Consultar desde dentro contra DNS interno:

dig @10.0.0.53 app.ejemplo.com A

2) Consultar desde dentro contra DNS público:

dig @1.1.1.1 app.ejemplo.com A

3) Si el cliente interno está usando DNS público (por configuración local), corregir para que use el DNS interno (por política de red, DHCP o configuración del host).

4) Verificar consistencia de servicios asociados (por ejemplo, si hay api.app.ejemplo.com o auth.app.ejemplo.com) y documentar qué nombres son split-horizon y cuáles no.

Checklist de diagnóstico rápido (para incidentes)

• ¿Qué resolver está usando el cliente? (¿es el esperado?)
• ¿El nombre resuelve? ¿A/AAAA/CNAME? ¿Cuál es el TTL?
• ¿Resuelve igual desde otro resolver (interno vs externo)?
• ¿El problema es de autoridad (delegación/NS) o del recursivo (caché/timeout)?
• ¿Hay reverse DNS requerido (correo, auditoría)?
• ¿Hay bloqueo de UDP/TCP 53 o respuestas truncadas (necesidad de TCP)?