DNS para Testers

Cómo Funciona DNS #

El Sistema de Nombres de Dominio (DNS) es la guía telefónica de internet — traduce nombres de dominio legibles para humanos (como api.example.com) a direcciones IP (como 93.184.216.34) que las computadoras usan para comunicarse. Cada request de red que tu aplicación hace comienza con un lookup DNS, haciendo de DNS la base de toda la comunicación en red.

El Proceso de Resolución #

Cuando tu navegador o herramienta de test necesita resolver un nombre de dominio, ocurre una cascada de consultas:

1. Caché del navegador: El navegador revisa su propia caché DNS primero (típicamente 60 segundos)
2. Caché del SO: Se consulta la caché del resolver DNS del sistema operativo
3. Resolver recursivo: Se consulta el servidor DNS de tu ISP o el configurado (como Google 8.8.8.8 o Cloudflare 1.1.1.1)
4. Nameserver raíz: Si el resolver no tiene respuesta cacheada, pregunta a un nameserver raíz que dirige al servidor TLD
5. Nameserver TLD: El servidor .com, .org o .io dirige al nameserver autoritativo del dominio
6. Nameserver autoritativo: Devuelve el registro DNS real con la dirección IP

Todo este proceso típicamente toma 20-100ms pero puede cachearse en cada nivel, reduciendo consultas posteriores a casi cero.

Tipos de Registros DNS #

Herramientas de Diagnóstico DNS #

dig — La Navaja Suiza DNS del Ingeniero QA #

# Consulta básica
dig example.com

# Salida corta — solo la respuesta
dig +short example.com

# Consultar tipo de registro específico
dig example.com AAAA
dig example.com MX
dig example.com TXT

# Rastrear la ruta completa de resolución
dig +trace example.com

# Consultar un servidor DNS específico
dig @8.8.8.8 example.com

# Mostrar valores TTL
dig example.com | grep -A1 "ANSWER SECTION"

nslookup — Rápido y Multiplataforma #

# Consulta básica
nslookup example.com

# Consultar servidor específico
nslookup example.com 8.8.8.8

# Consultar tipo de registro específico
nslookup -type=MX example.com

Verificar Propagación Entre Resolvers #

# Comparar resultados entre múltiples servidores DNS públicos
dig @8.8.8.8 example.com +short      # Google
dig @1.1.1.1 example.com +short      # Cloudflare
dig @9.9.9.9 example.com +short      # Quad9
dig @208.67.222.222 example.com +short  # OpenDNS

Si diferentes resolvers devuelven diferentes direcciones IP, la propagación DNS aún está en progreso.

Escenarios de Testing DNS #

Enrutamiento de Entornos con Archivo Hosts #

El archivo /etc/hosts (o C:\Windows\System32\drivers\etc\hosts en Windows) sobreescribe la resolución DNS localmente. Es la técnica DNS más común que usan los ingenieros QA:

# Enrutar dominio de producción al servidor staging
# Agregar a /etc/hosts:
10.0.1.50  api.example.com
10.0.1.50  www.example.com

Esto permite testear el comportamiento del dominio de producción contra un servidor staging sin cambios de infraestructura DNS. El navegador y todas las herramientas se conectarán a la IP que especificaste.

Testing Relacionado con TTL #

Antes de cualquier migración DNS o despliegue que cambie registros DNS:

1. Verificar TTL actual: dig example.com | grep TTL — un TTL de 86400 (24 horas) significa que los registros viejos persisten un día completo
2. Bajar TTL antes de la migración: Reducir TTL a 300 (5 minutos) al menos 24 horas antes del cambio
3. Monitorear propagación: Después del cambio, verificar desde múltiples resolvers que los nuevos registros estén activos

Testing de DNS Failover #

Muchas aplicaciones usan failover basado en DNS — cuando un servidor primario falla, DNS enruta tráfico a un backup. Testea esto:

1. Verificando que existan registros de failover (múltiples registros A o DNS basado en health checks)
2. Simulando la falla del servidor primario y confirmando que DNS cambie al backup
3. Midiendo el tiempo de failover (depende del TTL e intervalos de health check)

Testing DNS Avanzado #

Descubrimiento de Servicios Basado en DNS #

En arquitecturas de microservicios, los servicios se encuentran entre sí a través de DNS (especialmente registros SRV en Kubernetes). El testing incluye:

• Verificar que los registros SRV devuelvan combinaciones host:puerto correctas
• Testear tiempos de registro/desregistro de servicios
• Verificar que los clientes manejen cambios de registros DNS correctamente

Testing de GeoDNS #

GeoDNS enruta usuarios al servidor más cercano basado en su ubicación geográfica. Para testear desde diferentes ubicaciones:

# Usar servidores DNS en diferentes regiones
dig @dns-server-in-europe.example.com api.example.com +short
dig @dns-server-in-asia.example.com api.example.com +short

# O usar herramientas online como DNS Checker, whatsmydns.net

Validación DNSSEC #

DNSSEC agrega firmas criptográficas a los registros DNS, previniendo manipulación:

# Verificar estado de DNSSEC
dig example.com +dnssec

# Verificar la cadena DNSSEC completa
dig +sigchase +trusted-key=. example.com

DNS over HTTPS (DoH) #

Los navegadores modernos usan DNS over HTTPS, cifrando las consultas DNS. Esto puede afectar el comportamiento de testing:

• DoH evita la configuración DNS local y el archivo hosts en algunas configuraciones
• Los proxies corporativos pueden no ver las consultas DNS, afectando el monitoreo
• Testea con DoH habilitado y deshabilitado para verificar comportamiento consistente

Testing de Takeover de Subdominios #

Cuando un CNAME apunta a un servicio que ya no existe (ej., un bucket S3 eliminado o app de Heroku), un atacante puede reclamar ese servicio y servir contenido malicioso:

# Verificar CNAMEs colgantes
dig subdomain.example.com CNAME +short
# Si el servicio destino devuelve NXDOMAIN, puede ser vulnerable

Ejercicio Práctico #

Investiga la configuración DNS de un sitio web de tu elección:

1. Consulta todos los tipos de registro (A, AAAA, CNAME, MX, TXT, NS)
2. Rastrea la ruta completa de resolución con dig +trace
3. Modifica tu archivo hosts para redirigir el dominio a 127.0.0.1 y verifica que funcione
4. Revisa el valor TTL y calcula cuánto tardaría en propagarse un cambio DNS
5. Compara resultados de resolución entre tres resolvers diferentes

# 1. Consultar todos los tipos de registro
DOMAIN="example.com"
for TYPE in A AAAA CNAME MX TXT NS; do
  echo "=== $TYPE ==="
  dig +short $DOMAIN $TYPE
done

# 2. Trace completo
dig +trace $DOMAIN

# 3. Redirección con hosts file (requiere sudo)
echo "127.0.0.1  $DOMAIN" | sudo tee -a /etc/hosts
curl $DOMAIN  # Debería fallar o conectarse a localhost
# ¡Recuerda eliminar la entrada después del testing!

# 4. Verificar TTL
dig $DOMAIN | grep -A5 "ANSWER SECTION"

# 5. Comparar resolvers
for DNS in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo "=== $DNS ==="
  dig @$DNS +short $DOMAIN
done

Pro Tips #

• Usa /etc/hosts para redirigir dominios a entornos de prueba sin cambios DNS — es el enfoque más seguro y rápido para QA
• Verifica el TTL de DNS antes de despliegues — un TTL alto significa cambio lento e inconsistencias potenciales en testing
• Testea desde múltiples resolvers DNS para detectar inconsistencias de propagación — diferentes usuarios pueden resolver a diferentes servidores durante transiciones
• El caching DNS puede hacer que los tests pasen localmente pero fallen en CI — limpia cachés DNS al depurar (sudo dscacheutil -flushcache en macOS)
• Monitorea el tiempo de resolución DNS — un DNS lento agrega latencia a cada request que tu aplicación hace

Puntos Clave #

1. DNS es el primer paso en cada request de red — las fallas DNS afectan todo lo que sigue
2. El archivo hosts es el mejor amigo de QA para enrutar tráfico de test sin cambios de infraestructura
3. La conciencia del TTL es crítica durante despliegues y migraciones de entornos
4. Las herramientas de diagnóstico DNS (dig, nslookup) deben estar en el toolkit de cada tester