Conceptos Básicos de DNS que Todo Desarrollador Debería Conocer
Has desplegado tu aplicación, pero los usuarios reportan que no pueden acceder a ella. Tu primer instinto podría ser revisar el servidor, pero el verdadero culpable suele ser el DNS. Comprender los conceptos básicos de DNS no es opcional—es esencial para depurar problemas en producción y razonar sobre cómo tus aplicaciones web realmente llegan a los usuarios.
Este artículo cubre el flujo de resolución DNS, tipos de registros comunes, comportamiento de caché y desarrollos modernos de DNS que afectan el rendimiento y la seguridad.
Puntos Clave
- La resolución DNS involucra tres capas: resolvedores stub, resolvedores recursivos y servidores de nombres autoritativos—las fallas pueden ocurrir en cualquier punto
- Los valores TTL determinan el tiempo de propagación; redúcelos antes de las migraciones, no durante
- Los registros HTTPS (SVCB) proporcionan indicaciones de conexión para conexiones de navegador más rápidas y seguras
- DNSSEC autentica registros mientras que DoH/DoT/DoQ cifra consultas—resuelven problemas diferentes
- Usa
digonslookuppara depurar problemas de DNS consultando diferentes resolvedores
Cómo Funciona la Resolución DNS
Cuando un navegador necesita conectarse a api.example.com, no conoce mágicamente la dirección IP. El proceso de resolución involucra tres capas:
Resolvedor stub: El cliente DNS integrado de tu sistema operativo. No resuelve nombres por sí mismo—reenvía consultas a un resolvedor recursivo configurado y almacena respuestas en caché localmente.
Resolvedor recursivo: Típicamente operado por tu ISP o un servicio público como Cloudflare (1.1.1.1) o Google (8.8.8.8). Este servidor hace el trabajo pesado, consultando otros servidores en tu nombre.
Servidores de nombres autoritativos: La fuente de verdad para los registros DNS de un dominio. El resolvedor recursivo recorre la jerarquía DNS—servidores raíz, luego servidores TLD (.com, .io), luego los servidores autoritativos del dominio—para encontrar la respuesta.
Para los desarrolladores, la clave es que las fallas de DNS pueden ocurrir en cualquier capa. Un resolvedor stub mal configurado, un resolvedor recursivo inalcanzable o registros autoritativos obsoletos pueden romper tu aplicación.
Tipos de Registros DNS Comunes
Encontrarás estos registros regularmente:
- A / AAAA: Mapean un nombre de host a una dirección IPv4 o IPv6
- CNAME: Crea un alias de un nombre de host a otro (no puede usarse en el ápice de zona—
example.comen sí requiere un registro A o AAAA) - MX: Especifica servidores de correo para el dominio
- TXT: Almacena texto arbitrario, comúnmente usado para verificación de dominio y autenticación de correo electrónico (SPF, DKIM)
- NS: Delega una zona a servidores de nombres específicos
Comprender estos ayuda al configurar CDNs, servicios de correo electrónico o depurar por qué un subdominio no está resolviendo.
Caché DNS y TTL
El caché DNS y el TTL (Time To Live) impactan directamente tu estrategia de despliegue. Cada registro DNS incluye un valor TTL en segundos. Una vez que un resolvedor almacena un registro en caché, no consultará nuevamente hasta que expire el TTL.
Implicaciones prácticas:
- Un TTL de 3600 segundos (1 hora) significa que los cambios DNS tardan hasta una hora en propagarse
- Antes de migraciones, reduce los TTL con anticipación—no durante el cambio
- Los navegadores y sistemas operativos mantienen sus propias cachés, añadiendo otra capa
El mito de que “la propagación DNS tarda 24-48 horas” es engañoso. El tiempo de propagación depende del valor TTL anterior. Si tu TTL antiguo era de 86400 segundos (24 horas), ese es tu tiempo de espera en el peor caso.
Discover how at OpenReplay.com.
DNS Moderno: Registros HTTPS y Transporte Cifrado
DNS ha evolucionado significativamente en los últimos años. Dos desarrollos importan más para los desarrolladores web.
El Registro DNS HTTPS (SVCB)
El registro HTTPS (un tipo específico de registro SVCB) proporciona indicaciones de conexión antes de que el navegador siquiera contacte tu servidor. Puede anunciar:
- Soporte HTTP/3 y QUIC
- Puertos alternativos
- Claves de Encrypted Client Hello (ECH)
Esto permite a los navegadores establecer conexiones más rápidas y seguras. Sin embargo, el soporte para registros HTTPS aún no es universal—no todos los proveedores DNS lo soportan, y algunos resolvedores no consultan por él.
Nota: Los registros HTTPS ofrecen capacidades limitadas de alias en el ápice, pero no son una solución completa de CNAME-en-ápice.
DNS sobre HTTPS (DoH) y DNS Cifrado
Las consultas DNS tradicionales viajan en texto plano sobre el puerto UDP 53. DNS sobre HTTPS (DoH), DNS sobre TLS (DoT) y DNS sobre QUIC (DoQ) cifran estas consultas, previniendo espionaje y manipulación.
El DNS cifrado ahora está ampliamente desplegado—Firefox y Chrome usan DoH por defecto en muchas configuraciones—pero no es universal. Las redes corporativas y algunos ISPs todavía interceptan o bloquean DNS cifrado.
DNSSEC vs Cifrado: Conoce la Diferencia
Una confusión común: DNSSEC no es cifrado.
DNSSEC proporciona autenticación. Firma criptográficamente los registros DNS para que los resolvedores puedan verificar que las respuestas no han sido manipuladas. No oculta tus consultas.
DNS cifrado (DoH/DoT/DoQ) proporciona privacidad. Cifra la capa de transporte para que los observadores no puedan ver qué dominios estás consultando.
Resuelven problemas diferentes y pueden usarse juntos.
Cómo se Manifiestan las Fallas de DNS en tus Aplicaciones
Cuando DNS falla, típicamente verás:
- Errores
NXDOMAIN(el dominio no existe) - Tiempos de espera de conexión agotados (resolvedor inalcanzable)
- Respuestas
SERVFAIL(problemas del servidor upstream)
En navegadores, estos aparecen como “DNS_PROBE_FINISHED_NXDOMAIN” o errores similares. En Node.js u otros entornos de ejecución, obtendrás excepciones ENOTFOUND o equivalentes.
Usa dig o nslookup para depurar. Consulta diferentes resolvedores para aislar si el problema es caché local, tu resolvedor o los servidores autoritativos.
Conclusión
DNS se sitúa entre tus usuarios y tus servidores. Comprender el flujo de resolución, el comportamiento del TTL y protocolos modernos como registros HTTPS y DoH te ayuda a desplegar de manera más confiable y depurar más rápido. Cuando algo se rompe, DNS debería ser uno de tus primeros sospechosos—no el último.
Preguntas Frecuentes
Usa el comando dig en tu terminal, como dig example.com A para verificar registros A o dig example.com ANY para ver todos los registros. También puedes especificar un resolvedor como dig @8.8.8.8 example.com para consultar directamente el DNS de Google. En Windows, usa nslookup example.com en su lugar.
Los cambios DNS parecen retrasados porque los resolvedores almacenan registros en caché según su valor TTL. Si tu TTL anterior era de 3600 segundos, los resolvedores no verificarán actualizaciones hasta que pase esa hora. Para acelerar cambios futuros, reduce tu TTL mucho antes de hacer actualizaciones, luego restáuralo después.
Un registro A mapea un nombre de host directamente a una dirección IP. Un CNAME crea un alias que apunta un nombre de host a otro, que luego resuelve a una IP. Los CNAMEs son útiles para subdominios que apuntan a servicios externos, pero no pueden usarse en el ápice de zona donde tu dominio raíz requiere un registro A o AAAA.
DoH cifra las consultas DNS, previniendo que observadores de red vean qué dominios resuelves. Para la privacidad del usuario final, es beneficioso. Sin embargo, para aplicaciones de servidor, el DNS tradicional suele ser suficiente ya que tu infraestructura ya es conocida. Considera DoH cuando la privacidad frente a intermediarios de red sea importante para tu caso de uso.
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
