Búsqueda DNS

Cómo funciona

1. Introduce un dominio: escribe un nombre de dominio (incluidos subdominios) en el campo.
2. Selecciona los tipos de registro: elige qué tipos de registros DNS consultar: A, AAAA, MX, CNAME, TXT, NS, SOA o todos.
3. Consulta los resultados: los resultados se obtienen de un proveedor público de DNS-over-HTTPS y se muestran con los valores TTL y los datos.
4. Diagnostica: compara los resultados entre tipos de registro para identificar una mala configuración, retrasos de propagación o registros faltantes.

¿Por qué usar la búsqueda DNS?

Los problemas DNS están entre las causas más frecuentes de indisponibilidad de sitios web, fallos de entrega de correo y problemas de migración de dominio. Poder consultar los registros DNS directamente desde el navegador, sin recurrir a herramientas de línea de comandos como dig o nslookup: es valioso para desarrolladores, DevOps y administradores de sistemas. Esta herramienta consulta los registros mediante DNS-over-HTTPS para privacidad y evitar firewalls. Úsala para verificar los registros MX tras un cambio de proveedor de correo, confirmar los registros A/CNAME tras una migración DNS, verificar los registros TXT para la autenticación SPF/DKIM y diagnosticar retrasos de propagación.

Tipos de registros DNS

• A: dirección IPv4 de un dominio
• AAAA: dirección IPv6 de un dominio
• MX: registros de servidores de correo para el enrutamiento del correo
• CNAME: alias de nombre canónico que apunta a otro dominio
• TXT: registros de texto para SPF, DKIM, verificación de dominio
• NS: servidores de nombres autorizados para el dominio

40 años de DNS: de RFC 882 a DNS sobre QUIC

El Domain Name System fue diseñado por Paul Mockapetris en USC/ISI y especificado en RFC 882 y RFC 883 (noviembre de 1983), reemplazando el archivo plano HOSTS.TXT que ARPANET había superado. El sistema fue revisado y formalizado en RFC 1034 y RFC 1035 (noviembre de 1987), los documentos aún citados hoy. Jon Postel coordinó la asignación de los 13 servidores raíz originales, etiquetados a.root-servers.net a m.root-servers.net, un número fijado no por capacidad sino por el límite de tamaño de paquete UDP de 512 bytes de la época. Dos grandes choques remodelaron el DNS en este siglo. En julio de 2008, Dan Kaminsky reveló un ataque de envenenamiento de caché que permitía a los atacantes inyectar registros falsificados en los resolvers en segundos. La industria respondió con un parche coordinado (aleatorización del puerto fuente) y renovado interés en DNSSEC (RFC 4033-4035, marzo de 2005), que firma los registros criptográficamente. El segundo choque fue la privacidad: las consultas viajaban en texto plano por el puerto UDP 53 durante 35 años. DNS sobre TLS (DoT, RFC 7858, mayo de 2016) envuelve las consultas en TLS por el puerto 853. DNS sobre HTTPS (DoH, RFC 8484, octubre de 2018) tuneliza las consultas a través de HTTPS por el puerto 443, ocultando incluso el hecho de que está ocurriendo DNS. DNS sobre QUIC (RFC 9250, mayo de 2022) es el más reciente, usando el mismo transporte que impulsa HTTP/3. Los resolvers públicos 1.1.1.1 (Cloudflare, lanzado el 1 de abril de 2018), 8.8.8.8 (Google Public DNS, diciembre de 2009) y 9.9.9.9 (Quad9, noviembre de 2017) todos soportan DoH y DoT hoy.

Tipos de registros en profundidad

• A (RFC 1035). Dirección IPv4 de 32 bits. Un dominio puede tener muchos registros A para balanceo de carga; los resolvers rotan entre ellos (DNS round-robin).
• AAAA (RFC 3596, 2003). Dirección IPv6 de 128 bits. Pronunciado «quad-A». A 2024, alrededor del 45% del tráfico de Google es IPv6.
• CNAME (RFC 1035). Alias: «sigue este nombre y busca sus registros en su lugar». No puede coexistir con ningún otro registro en el mismo nombre. Por eso example.com no puede tener tanto un CNAME como un MX o A en el ápice; las alternativas modernas usan ALIAS o ANAME (específicos del proveedor) o registros HTTPS (RFC 9460, 2023).
• MX (RFC 1035, actualizado por RFC 7505 «null MX»). Servidor de intercambio de correo con un valor de prioridad. Menor prioridad es preferida; los empates se aleatorizan. 0 . (RFC 7505, junio de 2015) dice explícitamente «este dominio no recibe correo», bloqueando spam a dominios sin buzón.
• TXT (RFC 1035). Cadenas de texto libre. Ahora lleva autenticación crítica: SPF (RFC 7208, 2014), DKIM (RFC 6376, 2011), DMARC (RFC 7489, 2015), y verificación de propiedad para Google Search Console, Microsoft 365, desafíos ACME (Let's Encrypt) DNS-01.
• NS (RFC 1035). Nombres de los servidores de nombres autoritativos. Siempre al menos dos para redundancia. Los «glue records» en la zona padre proporcionan IPs para que un resolver recursivo pueda alcanzar el servidor de nombres sin búsquedas circulares.
• SOA (RFC 1035). Start of Authority. Un único registro por zona listando el servidor de nombres primario, email admin (con el primer . reemplazado por @), número de serie (incrementado en cambios), refresh, retry, expire y TTL mínimo.
• CAA (RFC 8659, 2019; originalmente RFC 6844, 2013). Certificate Authority Authorisation. Lista qué CAs están autorizadas a emitir certificados para el dominio. Verificación obligatoria por los requisitos de línea base del CA/Browser Forum desde septiembre de 2017.
• SRV (RFC 2782, 2000). Localización de servicio: protocolo, prioridad, peso, puerto, host destino. Microsoft Active Directory, XMPP, SIP, federación Matrix todos usan registros SRV para descubrimiento de servicio.
• PTR (RFC 1035). DNS inverso. Mapea una IP de vuelta a un dominio. Vive en las zonas in-addr.arpa (IPv4) o ip6.arpa (IPv6). Requerido por muchos servidores de correo para aceptar email; PTR faltante es una señal común de spam.
• DNSKEY / DS / RRSIG (RFC 4034-4035). Plomería DNSSEC. El DNSKEY publica las claves de firma de la zona; DS en la zona padre es el puntero criptográfico «aquí está el siguiente enlace en la cadena»; RRSIG lleva la firma real para cada conjunto de registros.

Donde la búsqueda DNS realmente ayuda

• Configurar email en un dominio nuevo. Verifica que los registros MX apunten al proveedor correcto (Google Workspace aspmx.l.google.com, Microsoft 365 example-com.mail.protection.outlook.com, Fastmail, ProtonMail). Verifica SPF (v=spf1 include:_spf.google.com ~all), DKIM (selector._domainkey), DMARC (_dmarc TXT).
• Migración de dominio y propagación. Después de actualizar servidores de nombres en el registrador, consulta tanto los servidores autoritativos antiguos como nuevos para confirmar que el cambio se ha propagado globalmente. Diferentes resolvers cachean por diferentes duraciones (el TTL es pista, no contrato).
• Resolución de problemas de certificado TLS / SSL. El desafío ACME DNS-01 usado por Let's Encrypt y similares requiere colocar un registro TXT en _acme-challenge.example.com. Verifica el valor antes de disparar la emisión de certificado para evitar intentos desperdiciados de límite de tasa.
• Detectar riesgo de toma de subdominio. Un CNAME apuntando a un servicio no registrado (app Heroku eliminada, bucket S3 liberado) permite a los atacantes registrarlo y servir contenido en tu subdominio. Una auditoría rápida de CNAME atrapa los punteros colgantes.
• Verificación de CDN y balanceador de carga. Confirma que un dominio CNAMEa al endpoint correcto de Cloudflare, Fastly, Akamai, CloudFront o Vercel después del despliegue. Detecta cuando staging apunta accidentalmente a producción.
• Comparación DNS geográfica. Algunos sitios sirven diferentes registros A por región (GeoDNS). Consultar desde diferentes endpoints DoH (Cloudflare 1.1.1.1 vs Google 8.8.8.8) sugiere cómo un usuario en Frankfurt vs Mumbai ve el sitio.
• Seguridad y respuesta a incidentes. Busca registros NS inesperados (secuestro de registrador), registros TXT sospechosos o registros MX recientemente agregados. Usa el número de serie SOA para rastrear cuándo cambió por última vez una zona.

Errores DNS que rompen sitios y email

• CNAME en el ápice. RFC 1034 prohíbe poner un CNAME en example.com mismo (solo en subdominios como www.example.com). Cloudflare, Route 53, DNSimple lo resuelven con CNAME flattening o registros ALIAS; Vercel, Netlify usan registros de enlace de servicio HTTPS (RFC 9460). Intentarlo en el panel DNS básico de un registrador rompe silenciosamente el email.
• Olvidar bajar el TTL antes de una migración. Si tu registro A tiene TTL 86400 (24 horas) y lo cambias la mañana del cambio, los resolvers en todo el mundo seguirán entregando la IP antigua hasta por un día. Baja TTLs a 300 segundos unos días antes del cambio.
• Registro SPF con demasiadas búsquedas DNS. RFC 7208 limita SPF a 10 búsquedas DNS por evaluación. Encadena demasiadas directivas include: y tu registro SPF falla con permerror, que DMARC trata como falla. Aplana o consolida con herramientas como SPF Surveyor.
• CNAME colgante tras desmontaje de servicio. ¿Eliminaste la app Heroku pero el CNAME app.example.com aún apunta a example.herokuapp.com? Cualquiera puede registrar ese nombre de app y hospedar su contenido en tu subdominio. Audita y elimina CNAMEs huérfanos.
• Sin registro CAA. Sin un registro CAA, cualquier CA en el WebPKI (~50 mundialmente) puede emitir un certificado para tu dominio. Bloquéalo a una o dos CAs de confianza: 0 issue "letsencrypt.org". Verificación CA obligatoria desde septiembre de 2017.
• Registros wildcard enmascarando entradas faltantes. Un registro A *.example.com hace que cada subdominio con error tipográfico se resuelva, ocultando errores reales de configuración. Combina cuidadosamente con reglas MX explícitas para evitar spam a direcciones con tipo.
• Mezclar DNSSEC y zonas sin firmar durante la transición. Habilitar DNSSEC en el registrador antes de que los nuevos servidores de nombres sirvan registros firmados produce SERVFAIL para cada resolver validador (Cloudflare 1.1.1.1, Quad9). Firma siempre primero, luego publica el registro DS.

Más preguntas frecuentes

Herramientas relacionadas