Consulta en directo · registros de un dominio
Escribe un dominio y consúltalo aquí mismo, en español: registros A, AAAA, MX, TXT, NS, CNAME, CAA y SOA, sus valores y el TTL con el que viajan. Es la vista de un resolver público en este momento, no la zona completa ni el DNS interno de nadie.
Consulta DNS
Introduce un dominio y elige el tipo de registro. «ALL» devuelve el inventario completo —A, AAAA, CNAME, MX, TXT, NS, CAA, SOA, DS y DNSKEY— y cualquier otra opción acota la respuesta a un solo tipo. Cada fila llega con su TTL.
Elige «ALL» para ver el inventario completo, o un tipo concreto para acotar la respuesta.
Usa la ruta /api/dns-lookup de MyIPScan, apoyada en un resolver público de DNS sobre HTTPS. Es la vista de un resolver: el resultado puede cambiar según la red, la caché y la propagación.
El formulario de arriba devuelve registros DNS públicos: A (IPv4), AAAA (IPv6), MX (correo), TXT (verificación y SPF), NS (servidores de nombres), CNAME (alias) y los demás tipos disponibles. El resto de la página explica qué significa cada uno de ellos.
No accede a registros DNS privados ni internos. Los resultados dependen de la propagación DNS y pueden diferir entre resolvers si hay cambios recientes.
Una consulta DNS le pregunta a un resolver qué registros publica un dominio y devuelve sus valores tal como están en ese instante: el A con la IPv4, el AAAA con la IPv6, el MX con los servidores de correo, el TXT con SPF, DKIM y tokens de verificación, y el NS con los servidores de nombres. Cada respuesta llega con su TTL. Es la vista de un resolver, no la zona completa del dominio.
Tu equipo hace esto cientos de veces al día sin enseñártelo. Escribes un dominio y, antes de abrir nada, tu navegador le pregunta a un servidor DNS —el resolver— a qué dirección IP tiene que conectarse. El resolver contesta, el navegador conecta, la página carga.
Una consulta DNS manual hace la misma pregunta, pero a propósito y enseñándote la respuesta entera. La diferencia está en el punto de salida: la pregunta la lanza el servidor de MyIPScan a un resolver público de DNS sobre HTTPS, no tu ordenador. Por eso el resultado no arrastra la caché de tu router ni depende del servidor que tenga fijado tu operador, y por eso sirve para comparar: si tu equipo ve una cosa y esta consulta ve otra, lo que falla no es el dominio, sino la caché que hay entre los dos.
Esta página mira qué publica un dominio. Qué resolver responde por ti cuando navegas es otra pregunta, y la contesta la prueba de fuga de DNS.
El formulario tiene dos campos y nada más. El primero es el dominio, que se escribe a secas —ejemplo.com—, sin protocolo y sin barra final. El segundo es un desplegable con el tipo de registro, donde «ALL» pide el inventario entero y cualquier otra opción acota la respuesta a un solo tipo. Un botón lanza la consulta.
La respuesta llega en forma de tabla y siempre trae las mismas cuatro columnas: el nombre por el que se preguntó, el tipo de registro, el TTL en segundos y el valor. Cuando un tipo devuelve varias entradas —lo normal en MX, NS y TXT— aparecen todas, una por fila, sin resumir ni ordenar por importancia.
Lo que no vas a encontrar ahí es un historial de cambios, un mapa de subdominios ni una puntuación de seguridad. La consulta hace una pregunta concreta y enseña la respuesta tal cual; interpretarla es justo lo que explica esta página.
Todo lo que viene a continuación —qué significa cada tipo, cómo se lee el TTL, qué hacer cuando el resultado no cuadra— sirve igual para esta consulta, para dig en una terminal o para el panel de tu proveedor de DNS. El vocabulario es el mismo en todas partes, así que lo que aprendas aquí no se queda en una herramienta.
«ALL» devuelve el inventario de una pasada; pedir un solo tipo deja el resultado más limpio.
Una respuesta DNS no es una frase, es una lista de registros, y cada registro se lee siempre en el mismo orden: nombre, tipo, TTL y valor. Con esas cuatro columnas se resuelve casi todo.
El nombre es el que preguntaste, devuelto tal cual. Conviene mirarlo, porque delata los despistes: si preguntaste por www.ejemplo.com y la respuesta habla de ejemplo.com, en medio hay un alias que te ha movido de sitio sin avisar.
El tipo confirma qué clase de registro es cada línea, y no siempre coincide con lo que pediste. Una consulta de tipo A sobre un nombre que en realidad es un alias devuelve primero el CNAME y después el A del destino: dos líneas de tipos distintos para una sola pregunta.
El TTL es el número de segundos que un resolver puede seguir sirviendo esa respuesta sin volver a preguntar. Si repites la consulta al cabo de un minuto verás que ha bajado: lo que estás leyendo es la cuenta atrás de la copia guardada en caché, no un valor fijo del registro. Cuando el TTL vuelve a su número original, esa copia ha caducado y el resolver ha preguntado de nuevo.
El valor cambia según el tipo. En un A es una dirección IPv4; en un MX, un número de prioridad seguido de un nombre de servidor; en un NS, el nombre de un servidor de nombres; en un TXT, una cadena entre comillas que a veces viene partida en trozos, porque el protocolo limita cada fragmento a 255 caracteres. Ese troceado es normal y no rompe nada: quien lee el registro vuelve a unir las piezas antes de interpretarlo.
Un detalle que ahorra confusiones: el orden en el que llegan las líneas no significa nada. Muchos resolvers rotan las respuestas a propósito para repartir el tráfico, así que dos consultas seguidas pueden devolver las mismas direcciones en distinto orden sin que haya cambiado ni un registro.
ejemplo.com, sin https:// y sin barra final. El DNS no entiende de URL, entiende de nombres._dmarc.ejemplo.com para DMARC, selector._domainkey.ejemplo.com para DKIM, www.ejemplo.com si sospechas que www apunta a un sitio distinto del dominio raíz.El formulario de consulta —dominio y tipo de registro— está al principio de esta página.
El registro MX dice a qué servidores hay que entregar los mensajes dirigidos al dominio. Suele haber varios con prioridades distintas: el remitente prueba primero el número más bajo y va bajando si no obtiene respuesta. Un dominio sin MX no recibe correo por mucho que su web cargue a la perfección. Si acabas de migrar de proveedor, comparar los MX antiguos con los nuevos es la primera comprobación que conviene hacer.
El registro TXT es el cajón donde se guarda casi todo lo demás. Ahí está el SPF, que empieza por v=spf1 y enumera qué servidores pueden enviar en nombre del dominio; la clave pública de DKIM, colgada de un subdominio con la forma selector._domainkey.ejemplo.com; y la política DMARC, que no se publica en el dominio raíz sino en _dmarc.ejemplo.com. Ese detalle explica por qué tanta gente da por hecho que un dominio «no tiene DMARC» cuando en realidad ha mirado en el sitio equivocado.
Si los mensajes salen pero no llegan, el DNS es solo la mitad del asunto: la otra mitad es la reputación de la dirección desde la que envías, y eso lo revisa el comprobador de lista negra de IP.
En la práctica, casi todas las consultas DNS nacen de una de estas tres situaciones. El orden en el que preguntas importa más que la herramienta con la que preguntes.
Empieza por el MX del dominio del destinatario y confirma que existe y que apunta a los servidores de su proveedor. Sigue por el TXT del dominio desde el que envías, para leer el SPF entero y comprobar que incluye al servicio que estás usando de verdad. Termina en _dmarc.ejemplo.com, que es donde vive la política DMARC, y en selector._domainkey.ejemplo.com, donde está la clave pública de DKIM. Con cuatro consultas sabrás si el problema está en el DNS o hay que buscarlo en otro sitio.
Consulta el A y el AAAA actuales y apunta sus TTL antes de tocar nada. Si son largos, bájalos a 300 y espera a que caduque el valor anterior; solo entonces cambia la dirección. Después del cambio, vuelve a consultar cada pocos minutos: la respuesta nueva aparecerá antes en unos resolvers que en otros, y eso es exactamente lo que tiene que pasar. Cuando el TTL viejo haya expirado en todas partes, sube el valor otra vez para no cargar de preguntas a tus servidores de nombres.
Consulta el CAA del dominio. Si publica una lista de autoridades y la tuya no está en ella, la emisión se rechaza por diseño y sin más explicación. Un dominio sin CAA no restringe nada, así que la ausencia de ese registro nunca es la causa. Comprueba además que el nombre exacto del certificado resuelve: muchas validaciones fallan porque www no existe como registro, no porque el certificado esté mal pedido.
El TTL, del inglés time to live, es un número en segundos que acompaña a cada respuesta y dice cuánto puede guardarla un resolver en caché antes de volver a preguntar. Un TTL de 300 son cinco minutos; uno de 86400, un día entero.
De ahí viene lo que todo el mundo llama «propagación», que en realidad no propaga nada: es caducidad de cachés. Cuando cambias un registro, el valor nuevo queda publicado en la zona de inmediato, pero cada resolver sigue sirviendo el viejo hasta que expira el TTL que guardó. Por eso dos personas en dos redes distintas pueden ver respuestas distintas y tener las dos razón.
La consecuencia práctica es de orden: antes de una migración, baja el TTL a 300, espera a que caduque el TTL anterior y solo entonces cambia el registro. Con registros recién creados, da un margen de hasta 48 horas.
Hay tres resultados que desconciertan y casi nunca significan lo que parecen.
No aparece ningún registro A. El nombre no resuelve a ninguna IP y el navegador no tiene adónde ir. Puede ser que el registro se borrara, que nunca se creara, o que el dominio funcione solo por IPv6. En un dominio nuevo, apunta el A a la IP del servidor y vuelve a consultar en quince o treinta minutos.
Sale un CNAME donde esperabas un A. Es lo normal en subdominios que apuntan a un servicio externo: el que manda es el alias, y la dirección final la publica el nombre al que apunta. Sigue la cadena consultando ese destino.
La IP no es la de tu servidor. Si el dominio pasa por un CDN o un proxy inverso, el registro A publica la dirección del proxy y no la del origen. Es el comportamiento esperado, y el motivo por el que una consulta DNS no localiza el servidor de origen.
Para saber de quién es esa dirección, la búsqueda ASN traduce el número de red en una organización y la geolocalización de IP da la ubicación aproximada que publican las bases de datos. La búsqueda WHOIS añade registrador, fechas y estado del dominio: datos del registro, no del DNS.
Cuando una consulta no devuelve lo que esperabas, la explicación suele estar en el código de respuesta. Hay tres que conviene distinguir, porque se parecen en pantalla y significan cosas muy distintas.
NXDOMAIN quiere decir que el nombre no existe en la zona. No es que le falte ese tipo de registro: es que no hay nada publicado con ese nombre. En un dominio recién comprado o recién delegado es lo normal durante un rato; en un dominio que funcionaba ayer apunta a un registro borrado o a un dominio caducado, y eso lo aclara la búsqueda WHOIS mejor que ninguna consulta DNS.
Respuesta correcta pero vacía es la que más confunde. El nombre existe, la pregunta se ha contestado sin error y aun así la lista viene sin registros: significa que ese nombre no publica ese tipo concreto. Un dominio con web pero sin correo devuelve exactamente eso cuando le preguntas por MX, y no hay nada roto.
SERVFAIL no habla del dominio, habla de la resolución. El resolver intentó contestar y no pudo: servidores de nombres que no responden, una delegación rota entre el registro y la zona, o una firma DNSSEC que no valida. Si un dominio devuelve SERVFAIL en un resolver y responde con normalidad en otro, la firma o la delegación son los primeros sospechosos.
Queda un cuarto caso que no tiene código propio: la respuesta llega, es correcta y el valor es viejo. Ahí no falla nada. Es la caché haciendo su trabajo, y se arregla esperando a que venza el TTL.
Nada de esto es exclusivo de una web. Cualquier sistema operativo trae una herramienta que hace la misma pregunta, y merece la pena conocerla porque contesta desde tu red y no desde un servidor remoto.
En macOS y en Linux, dig ejemplo.com MX devuelve los registros de correo con su TTL. Añadir +short deja solo los valores, sin cabeceras ni secciones. Y para preguntar a un resolver concreto basta con anteponer su dirección: dig @1.1.1.1 ejemplo.com A le pregunta a ese servidor y no al que tengas configurado en el sistema.
En Windows, nslookup -type=MX ejemplo.com hace lo equivalente, y nslookup -type=TXT _dmarc.ejemplo.com saca la política DMARC. También acepta un servidor al final de la línea si quieres saltarte el resolver de tu red.
La diferencia con la consulta de esta página es justo el punto de salida, y por eso conviene tener las dos a mano. Tu terminal pregunta a través del resolver de tu red, con la caché de tu red incluida; una consulta remota pregunta desde otro sitio y con otra caché. Si las dos coinciden, el dato está propagado; si no, ya sabes de qué lado está la copia vieja.
La consulta pregunta por el nombre y el tipo que tú escribes y devuelve lo que un resolver público responde en ese momento. Ese es su alcance y su límite.
No enumera subdominios: lo que no preguntes, no aparece. No ve el DNS interno de una empresa, que puede responder otra cosa dentro de la red corporativa. No demuestra quién es el dueño del dominio ni certifica que su configuración sea segura, y que un registro exista no significa que el servicio que hay detrás funcione.
Además, la respuesta puede venir de caché, estar delegada o pasar por un proxy: es una señal pública y repetible, no una verdad definitiva sobre la infraestructura. La metodología en español explica cómo se etiqueta cada señal y dónde se detiene. La misma consulta, con la interfaz en inglés, está en DNS Lookup.
Escribe el dominio sin «https://» ni barra final, elige «ALL» para ver el inventario completo y lanza la consulta desde el formulario de esta misma página. La pregunta sale desde el servidor de MyIPScan hacia un resolver público de DNS sobre HTTPS, así que la respuesta no depende de la caché de tu equipo ni de tu router. Para un subdominio, escríbelo entero.
El registro MX indica a qué servidores hay que entregar el correo dirigido a ese dominio. Normalmente hay varios con un número de prioridad: el remitente intenta primero el más bajo y baja por la lista si no responde. Un dominio sin registros MX no puede recibir correo, aunque su web cargue con normalidad.
Es un registro de texto libre sobre el que se apoya casi toda la autenticación del correo. Ahí van el SPF, que empieza por v=spf1 y enumera quién puede enviar en nombre del dominio, la clave pública de DKIM, en un subdominio del tipo selector._domainkey.ejemplo.com, y los tokens de verificación de propiedad. La política DMARC se publica aparte, en _dmarc.ejemplo.com.
Casi siempre es caché. Cada respuesta DNS lleva un TTL y los resolvers guardan el valor hasta que ese tiempo expira. Si tu ordenador, tu router o el resolver de tu operador guardaron el valor anterior, seguirán sirviéndolo aunque el dominio ya publique otro. Espera a que caduque el TTL antes de suponer que hay un error.
Lo que marque el TTL del registro anterior, no el del nuevo. Si el valor viejo se publicó con un TTL de 86400, habrá resolvers sirviéndolo hasta 24 horas después del cambio. Por eso conviene bajar el TTL a 300 antes de una migración, esperar a que expire el largo y cambiar el registro solo entonces.
Significa que ese nombre no resuelve a ninguna dirección IPv4, así que el navegador no sabe adónde conectarse y la web no carga. Puede ser que el registro se borrara, que nunca se creara, o que el dominio publique solo AAAA y funcione por IPv6. En un dominio nuevo, añade el registro A con la IP del servidor y vuelve a consultar al cabo de quince o treinta minutos.
No. La consulta solo responde por el nombre exacto que escribes, así que un subdominio que no preguntes no aparece por ningún lado. Enumerar subdominios queda fuera de lo que hace esta consulta, por diseño y no por un fallo. Si conoces el nombre, escríbelo entero y consúltalo aparte.
Estas son las rutas españolas aprobadas. No enlazan a guías futuras, rankings, afiliados ni borradores.