ToolActToolAct

Consulta DNS

Consulta registros DNS de cualquier dominio (A/AAAA/MX/TXT/NS/CNAME/SOA) mediante DoH. Se ejecuta localmente en tu navegador para proteger tu privacidad

Introduce un dominio, elige un tipo de registro y pulsa Consultar

¿Qué es una consulta DNS?

DNS (Domain Name System) es la «guía telefónica» de Internet: traduce dominios legibles para las personas, como example.com, en las direcciones IP que usan las máquinas para comunicarse. Una consulta DNS pide a un servidor DNS un registro concreto de un dominio: un registro A devuelve una dirección IPv4, un registro MX devuelve los servidores de correo que reciben los mensajes, y un registro TXT se usa habitualmente para SPF/DKIM y para verificar la propiedad del dominio. Esta herramienta realiza la consulta directamente en tu navegador mediante el protocolo DoH (DNS over HTTPS). La petición viaja desde tu navegador hasta un resolutor DNS público y nunca pasa por nuestros servidores, por lo que lo que consultas y los resultados se quedan en local, protegiendo tu privacidad.

Cómo se usa

Pasos

  1. Escribe el dominio a consultar, por ejemplo example.com
  2. Selecciona el tipo de registro a consultar (p. ej. A, MX, TXT) en el desplegable
  3. Opcional: cambia el proveedor DoH (Cloudflare, Google o AliDNS)
  4. Pulsa el botón Consultar o presiona Enter
  5. Lee el nombre, tipo, TTL y valor en la tabla de resultados

Notas

  • El TTL (tiempo de vida) se expresa en segundos e indica cuánto tiempo un resolutor guarda el registro en caché; un valor menor implica que los cambios se propagan antes.
  • Un estado NXDOMAIN significa que el dominio no existe; NOERROR sin registros de respuesta suele indicar que ese tipo de registro no está configurado.
  • Un valor MX se parece a «10 mail.example.com»: el número inicial es la prioridad, y cuanto menor es, más preferente.
  • Los registros TXT pueden ser largos y contener comillas, lo cual es normal; se usan a menudo para SPF, DKIM, DMARC y verificación de dominio.

Casos de uso

Diagnosticar un sitio que no cargaConsulta los registros A/AAAA para confirmar que el dominio resuelve a la IP correcta del servidor. Si obtienes NXDOMAIN o una IP equivocada, el problema suele ser la configuración DNS y no el servidor. Junto con el TTL, puedes distinguir si hay caché obsoleta.
Verificar los registros MX antes de configurar el correoAntes de apuntar un dominio a un proveedor de correo (Exchange, Google Workspace, etc.), consulta los registros MX para confirmar que apuntan a los servidores correctos y que el orden de prioridad es el adecuado, evitando fallos de entrega o mensajes marcados como spam.
Validar las políticas de correo SPF/DKIM/DMARCConsulta los registros TXT para comprobar si SPF (v=spf1 ...), los selectores DKIM (p. ej. default._domainkey) y DMARC (_dmarc) están publicados correctamente, reduciendo el riesgo de correo rechazado o suplantado, algo habitual en la depuración de entregabilidad.
Confirmar la propagación global tras un cambio de DNSTras cambiar de proveedor DNS o editar registros, consulta a través de distintos proveedores DoH y compara los resultados para ver si los nuevos registros se han propagado. Con un TTL grande, los registros antiguos pueden seguir en caché; los resultados convergen cuando expira el TTL anterior.
Conocer los servidores de nombres autoritativosConsultar los registros NS revela qué servidores de nombres autoritativos gestionan un dominio, útil para confirmar que un cambio de alojamiento DNS se ha completado o para localizar al responsable ante anomalías de resolución, junto con el registro SOA para los tiempos de refresco.

Principio técnico

Las consultas DNS se realizan tradicionalmente sobre UDP en el puerto 53: el cliente envía un mensaje DNS con el nombre y el tipo de consulta a su resolutor recursivo configurado, que a su vez recorre los servidores raíz, de dominio de nivel superior y autoritativos de forma recursiva y devuelve la respuesta. Definido en la RFC 1035, el mensaje es un formato binario compacto, y los navegadores no pueden enviar ni recibir UDP 53 directamente por restricciones de seguridad, por lo que las herramientas DNS basadas en web suelen necesitar un proxy en el backend. DoH (DNS over HTTPS), definido en la RFC 8484, envuelve los mensajes DNS en peticiones HTTPS sobre el puerto 443. Admite dos formas de carga: el wireformat binario (application/dns-message) y una forma JSON (application/dns-json, proporcionada por Google fuera de la RFC 8484 y también soportada por Cloudflare). Esta herramienta usa la forma JSON: el navegador envía una petición GET con la cabecera `Accept: application/dns-json` a `https://cloudflare-dns.com/dns-query?name=example.com&type=A` y recibe el JSON estructurado directamente, sin backend. Campos clave del JSON devuelto: `Status` es el RCODE de DNS (0=NOERROR, 3=NXDOMAIN que significa que el dominio no existe, 2=SERVFAIL un fallo de servidor); cada entrada del array `Answer` contiene `name` (nombre del registro), `type` (un código numérico de tipo como 1=A, 28=AAAA, 15=MX, 16=TXT, 2=NS, 6=SOA, 5=CNAME), `TTL` (tiempo de vida de la caché en segundos) y `data` (el valor del registro). Los datos autoritativos también pueden aparecer en las secciones `Authority` (SOA, NS) y `Additional`. El valor esencial de DoH es la privacidad y la resistencia a manipulaciones: las consultas DNS se cifran con HTTPS, por lo que un intermediario no puede espiar ni alterar el contenido de la consulta como sí podría con UDP 53 en claro, ni secuestrar fácilmente el tráfico identificando el puerto. Esto es justo lo que permite que esta herramienta funcione íntegramente en el navegador: el tráfico va directo al proveedor DoH, sin ningún servidor intermedio.

  • DNS tradicional: RFC 1035, puerto UDP/TCP 53, mensajes binarios; los navegadores no pueden enviarlo/recibirlo directamente y necesitan un proxy de backend.
  • DoH: RFC 8484, DNS envuelto en HTTPS sobre el puerto 443, cifra el contenido de la consulta y resiste espionado y secuestro.
  • DoH JSON: las peticiones llevan `Accept: application/dns-json` y devuelven JSON estructurado; lo soportan tanto Cloudflare como Google con CORS abierto, por lo que el navegador puede llamarlos directamente.
  • RCODE: 0=NOERROR, 2=SERVFAIL, 3=NXDOMAIN (el dominio no existe), 5=REFUSED.
  • Códigos de tipo de registro: 1=A, 28=AAAA, 5=CNAME, 15=MX, 16=TXT, 2=NS, 6=SOA, 33=SRV, 257=CAA.
  • El TTL es el tiempo de vida de la caché en segundos; un resolutor recursivo devuelve el resultado en caché hasta que expira el TTL y entonces vuelve a consultar al servidor autoritativo.

Ejemplos

Consultar el registro A de example.com

Dominio:  example.com
Tipo:     A
Estado:   NOERROR

Answer:
  example.com.   300   A   93.184.216.34

# TTL 300s: este registro IPv4 se guardará en caché 5 minutos.

Consultar el registro MX de gmail.com

Dominio:  gmail.com
Tipo:     MX
Estado:   NOERROR

Answer:
  gmail.com.   3600   MX   5 gmail-smtp-in.l.google.com.
  gmail.com.   3600   MX   10 alt1.gmail-smtp-in.l.google.com.

# El número inicial es la prioridad, menor es preferente; el correo se entrega primero al servidor de prioridad 5.

Consultar el registro TXT de example.com (SPF)

Dominio:  example.com
Tipo:     TXT
Estado:   NOERROR

Answer:
  example.com.   3600   TXT   "v=spf1 -all"

# Esta política SPF significa que el dominio no envía correo y se rechazan todos los orígenes.

Consultar un dominio inexistente (NXDOMAIN)

Dominio:  this-domain-does-not-exist-12345.com
Tipo:     A
Estado:   NXDOMAIN

Answer: (ninguno)

# Status=3 significa que el dominio no existe en DNS, no es un fallo de servidor.

Preguntas frecuentes

¿Una consulta DNS compromete mi privacidad?

No. La petición va directa desde tu navegador al proveedor DoH que elijas (Cloudflare, Google o AliDNS), totalmente cifrada con HTTPS y sin pasar por nuestros servidores: no podemos ver lo que consultas. De hecho, es más seguro que una consulta UDP 53 tradicional en claro.

¿Por qué a veces distintos proveedores devuelven resultados diferentes?

Los resultados DNS se almacenan en caché en cada nivel del resolutor según el TTL. Los distintos proveedores tienen estados de caché y momentos de refresco diferentes, por lo que durante la ventana de propagación tras un cambio de registro pueden devolver el valor antiguo y el nuevo. Los resultados convergen cuando expira el TTL del registro antiguo.

¿Qué significa NOERROR sin registros de respuesta?

Significa que el dominio existe y la consulta tuvo éxito, pero el dominio no tiene ningún registro del tipo que consultaste. Por ejemplo, un resultado MX vacío suele indicar que el dominio no recibe correo. La sección Authority normalmente devuelve un registro SOA como base para la caché negativa.

¿Qué afecta el valor del TTL?

El TTL (segundos) determina cuánto tiempo un resolutor guarda el registro en caché. Un TTL mayor implica una resolución global más rápida y menor carga del servidor, pero una propagación más lenta de los cambios; un TTL menor hace que los cambios surtan efecto antes, pero con consultas más frecuentes. Suele bajarse el TTL antes de un cambio DNS planeado.

¿Se admite el DNS inverso (de IP a dominio)?

Sí. Para consultar un registro PTR, introduce la dirección IP en formato inverso: 8.8.8.8 pasa a ser 8.8.8.8.in-addr.arpa, y IPv6 usa el sufijo ip6.arpa. El registro PTR devuelto es el nombre de dominio al que resuelve la IP.

¿Por qué abrir la URL DoH directamente en el navegador devuelve 400?

El endpoint DoH JSON de Cloudflare exige la cabecera Accept: application/dns-json. La barra de direcciones envía por defecto una cabecera Accept HTML, por lo que devuelve 400. Es el comportamiento esperado; llamarlo con fetch y una cabecera personalizada funciona con normalidad.

¿Puedo consultar cualquier dominio de nivel superior?

Sí. Mientras el dominio esté registrado en DNS y tenga configurados los registros pertinentes —incluidos gTLD (.com, .org), ccTLD (.cn, .jp, .de) y nuevos gTLD— el proveedor DoH lo resolverá de forma recursiva y devolverá el resultado.