Cómo consultar los registros DNS

El DNS es el sistema que traduce nombres de dominio a direcciones IP. Cuando algo va mal, un sitio que no carga, un correo que nunca llega, un certificado SSL que falla, comprobar los registros DNS es casi siempre el primer paso de depuración. Entender qué hace cada tipo de registro, cómo fluyen las consultas por el sistema y dónde mirar cuando los resultados no coinciden convierte cortes misteriosos en problemas resolubles.

Breve historia del DNS

Antes del DNS, cada ordenador en la internet temprana compartía un único archivo llamado HOSTS.TXT, mantenido en el Stanford Research Institute. Cada sitio descargaba el archivo periódicamente para aprender las direcciones IP de otras máquinas. El sistema funcionaba cuando la red tenía unos cientos de hosts. No escalaba.

En 1983, Paul Mockapetris publicó las RFC 882 y RFC 883, que describían un sistema de nombres jerárquico y distribuido: el Domain Name System. Las especificaciones se refinaron en 1987 en RFC 1034 (conceptos y funcionalidades) y RFC 1035 (implementación y especificación), que siguen siendo los documentos fundacionales hoy. En lugar de un único archivo gigante, el espacio de nombres se dividió en zonas, cada una gestionada por sus propios servidores autoritativos, con un pequeño conjunto de servidores raíz en lo alto del árbol.

El DNS se ha extendido de forma constante desde entonces. Los registros AAAA (RFC 3596, 2003) añadieron soporte para IPv6. DNSSEC (RFC 4033 a 4035, 2005) añadió firmas criptográficas para proteger contra la suplantación. DNS-over-TLS (RFC 7858, 2016) y DNS-over-HTTPS (RFC 8484, 2018) cifraron las consultas para que los espías y los equipos intermedios no pudieran verlas ni manipularlas. Cada capa del sistema mantiene compatibilidad hacia atrás, por eso un protocolo de cuarenta años sigue moviendo la web moderna.

Tipos de registros DNS

Hay docenas de tipos de registros DNS, pero un puñado cubre la gran mayoría de las consultas reales. Saber qué hace cada uno acelera el triaje.

A, AAAA, CNAME y MX responden a la mayoría de preguntas cotidianas. TXT, NS, SOA y CAA aparecen durante configuración y auditorías de seguridad. SRV y NAPTR importan en VoIP, XMPP y otros protocolos de descubrimiento de servicios. PTR importa para servidores de correo, ya que la mayoría de filtros antispam rechazan remitentes sin DNS inverso válido.

Cómo consultar registros DNS

1. Introduce un dominio: escribe cualquier nombre de dominio (por ejemplo, example.com) en la herramienta de consulta. También puedes introducir un subdominio como mail.example.com si quieres los registros específicos de esa etiqueta.
2. Selecciona un tipo de registro: elige A, AAAA, MX, TXT, CNAME, NS, SOA o CAA. La herramienta también permite consultar todos los tipos comunes a la vez para una visión rápida.
3. Revisa los resultados, la respuesta lista cada registro coincidente con su valor, TTL (cuánto tiempo los resolutores pueden cachearlo) y cualquier campo adicional como prioridad MX o números de serie SOA.
4. Compara con lo esperado: si acabas de cambiar un registro, verifica que aparece el nuevo valor. Si depuras un tercero, compara lo que ves con lo que dice haber configurado.

Depurar problemas reales con DNS

¿El sitio no carga? Comprueba los registros A y AAAA. Si faltan, el dominio no está conectado; si apuntan a una IP antigua, el tráfico llega a un servidor que ya no aloja el sitio. Confirma también que los registros NS coincidan con los servidores de nombres listados por el registrador, ya que un desajuste significa que toda la zona se sirve desde una fuente obsoleta.

¿El correo no llega? Comprueba primero los registros MX; MX faltantes o incorrectos significan que nada puede entregarse. Luego comprueba los registros TXT para SPF (v=spf1), DKIM (default._domainkey o similar) y DMARC (_dmarc.example.com). Los proveedores de correo modernos rechazan o ponen en cuarentena los mensajes que fallan estas comprobaciones, así que un registro faltante puede enviar silenciosamente tus mensajes a spam.

¿Errores de certificado SSL? Comprueba que el registro A apunte al servidor donde el certificado está instalado. Si el sitio está detrás de una CDN, el registro A debe resolver al borde de la CDN, no al origen. Comprueba también los registros CAA; un CAA que liste solo una autoridad certificadora bloqueará a todas las demás de emitir, incluso cuando el propietario del dominio espera que funcionen.

¿Falla la verificación de dominio? Google Workspace, Microsoft 365, Cloudflare y la mayoría de plataformas SaaS te piden añadir un registro TXT para demostrar propiedad. Consulta los registros TXT para confirmar que la cadena exacta está presente, incluyendo cualquier comilla o prefijo que la plataforma pidiera.

¿La propagación DNS parece lenta? Tras cambiar registros, los resolutores de todo el mundo siguen sirviendo valores cacheados hasta que el TTL expira. Bajar el TTL a 300 segundos el día antes de un cambio planificado hace que la migración sea mucho más rápida. La herramienta de consulta muestra el TTL actual junto a cada registro, así que puedes predecir cuánto tiempo persistirán los valores obsoletos.

SPF, DKIM y DMARC

Tres registros basados en TXT protegen el correo contra la suplantación. SPF lista qué servidores están autorizados a enviar correo por tu dominio. DKIM publica una clave pública que los destinatarios usan para verificar la firma criptográfica de cada mensaje. DMARC le dice a los destinatarios qué hacer cuando SPF o DKIM falla: nada, poner en cuarentena o rechazar. Los tres viven en DNS, los tres se consultan en cada mensaje entrante y una errata en cualquiera puede paralizar la entregabilidad. Una herramienta de consulta DNS es la forma más rápida de leer lo que está realmente publicado, separado de lo que afirme la interfaz de configuración.

Aprovisionamiento de certificados y CAA

Cuando solicitas un certificado TLS, la autoridad certificadora consulta DNS para verificar el control. La mayoría usa el desafío dns-01: te pide publicar un registro TXT específico bajo _acme-challenge, luego comprueba que apareció. Los registros CAA añaden otra capa; declaran qué autoridades pueden emitir certificados para el dominio. Un CAA mal configurado puede bloquear renovaciones legítimas, así que comprueba CAA siempre que un cron de Let's Encrypt deje de funcionar de repente.

Errores comunes

• Confundir respuestas recursivas con autoritativas, el resolutor de tu ISP puede servir una copia cacheada con horas de retraso respecto a la realidad. La herramienta de consulta usa el endpoint DNS-over-HTTPS de Cloudflare, que consulta servidores autoritativos directamente y omite las cachés de los ISP.
• Ignorar el TTL, si el TTL de un registro es 86400 segundos (24 horas), los cambios pueden tardar un día entero en ser visibles en todas partes. Planifica las reducciones de TTL un día antes de cualquier migración.
• CNAME en el ápice, los registros CNAME no se permiten en la raíz de una zona (example.com en sí). Los proveedores ofrecen registros ALIAS o ANAME como soluciones alternativas, pero no son DNS estándar, así que el comportamiento varía.
• Apilar varios registros SPF, SPF exige exactamente un registro TXT que empiece por v=spf1. Dos registros SPF hacen que los servidores receptores marquen el resultado como PermError, lo que hunde la entregabilidad.
• Olvidar el punto final, en archivos de zona, los nombres sin punto final se tratan como relativos a la zona, así que olvidar el punto convierte mail.example.com en mail.example.com.example.com.
• Mezclar registros A IPv4 y IPv6, A es solo para IPv4. Poner una dirección IPv6 en un registro A (en lugar de AAAA) es un error de configuración que algunas interfaces no detectan.
• Cadenas CNAME en bucle, un CNAME que apunta a otro CNAME que apunta de vuelta crea un bucle de resolución. Los resolutores limitan la cadena a unos ocho saltos antes de rendirse.
• Caché en varias capas, navegador, SO, router y resolutor cachean DNS de forma independiente. Vaciar solo uno raramente es suficiente; recurre a la herramienta de consulta para saltarte la cadena por completo.
• Comodines que enmascaran entradas faltantes, un registro A comodín (*.example.com) coincidirá con cualquier subdominio sin registro explícito, lo que puede ocultar configuraciones erróneas.
• Confiar en un solo resolutor, la propagación es desigual. Consulta varios resolutores (1.1.1.1, 8.8.8.8, 9.9.9.9) al verificar un cambio global.

Otras formas de consultar DNS

La herramienta de consulta en el navegador es el camino más rápido para la mayoría de comprobaciones, pero las herramientas de línea de comandos dan más detalle cuando lo necesitas.

Cada uno tiene compromisos. dig +trace recorre el árbol DNS desde las raíces y muestra cada paso, lo que es invaluable para probar dónde se rompe una cadena. nslookup está en todas partes y vale para comprobaciones rápidas. La herramienta web gana en velocidad y en no necesitar terminal en absoluto.

Privacidad y DNS

Las consultas DNS comunes viajan en texto plano, lo que significa que tu ISP y cualquiera en la red puede ver cada dominio que visitas. Dos variantes cifradas abordan esto: DNS-over-HTTPS (DoH) envuelve las consultas en HTTPS y DNS-over-TLS (DoT) las envuelve en TLS sobre un puerto dedicado. La herramienta de consulta usa el endpoint DoH de Cloudflare, así que tu consulta al resolutor está cifrada en tránsito. El dominio sobre el que preguntas sigue siendo observable por el propio resolutor; si eso te preocupa, ejecuta tu propio resolutor (Unbound, Pi-hole) o usa un servicio de pago centrado en privacidad que prometa no registrar.

Las consultas en el navegador nunca almacenan tus solicitudes en nuestros servidores. La petición va desde tu navegador directamente al resolutor DoH y la respuesta se renderiza del lado del cliente. No hay registro que citar, ni analíticas sobre qué dominios comprobaste, ni nada que filtrarse en una futura brecha. Para una tarea tan rutinaria como depurar DNS, ese es exactamente el nivel de privacidad que el trabajo merece.