bitlvl
ES

Consulta DNS y comprobación de correo

Escribe un dominio. La página pregunta a Cloudflare (1.1.1.1) y a Google (8.8.8.8) por DNS sobre HTTPS directamente desde tu navegador, muestra cada registro con su TTL y, para dominios de correo, sigue toda la cadena de include de SPF y lee DMARC y DKIM. Nada pasa por nuestro servidor.

 

Las consultas van directamente desde tu navegador a cloudflare-dns.com y dns.google; esos resolutores ven los nombres consultados, como en cualquier consulta DNS, y nadie más.

Los resultados y mensajes de esta herramienta se muestran en inglés.

Qué estás viendo

Cada consulta va a un resolutor recursivo público, que responde desde su caché (la TTL mostrada es el tiempo que le queda en esa caché) o pregunta a los servidores autoritativos de la zona. Por eso dos resolutores pueden discrepar tras un cambio: uno conserva el registro antiguo hasta que expira su TTL. La comparación de resolutores lo hace visible; cuando ambos coinciden con lo esperado, el cambio ha llegado a la mayor parte de internet. La propagación completa significa simplemente «todas las cachés han expirado», por eso bajar la TTL un día antes de un cambio es la única forma de que sea rápido.

Tipos de registro en breve

TipoContieneComprobación típica
A / AAAAdirección IPv4 / IPv6apunta el sitio al servidor correcto
CNAMEalias de otro nombreno puede coexistir con otros registros en el mismo nombre; nunca en el ápice de la zona
MXservidores de correo con prioridadse prueba primero el número más bajo; el destino necesita A/AAAA, no CNAME
TXTtexto libre: SPF, DMARC, DKIM, verificación de sitioexactamente un registro SPF
NSservidores de nombres autoritativosdeben coincidir con la delegación de la zona padre
SOAparámetros de la zona: serial, refresh, retry, expire, minimumel serial aumenta con cada cambio; minimum es la TTL de caché negativa
CAAqué autoridades de certificación pueden emitirLet's Encrypt necesita issue "letsencrypt.org" o ningún CAA
SRVubicación de un servicio: prioridad, peso, puerto, destino_sip._tcp, _xmpp-client._tcp, _minecraft._tcp
DS / DNSKEYcadena de confianza DNSSECel DS en la zona padre debe coincidir con una KSK de la zona; el indicador AD muestra validación correcta
HTTPS / SVCBvinculación de servicio: ALPN (h2, h3), ECH, pistas de IPlo que publica Cloudflare para HTTP/3 y Encrypted Client Hello
TLSAanclaje de certificados DANEsobre todo para SMTP entre servidores de correo

SPF y el límite de 10 consultas

Un registro SPF enumera quién puede enviar correo del dominio. Cada término include:, a, mx, ptr, exists y redirect= cuesta una consulta DNS al servidor receptor, y el RFC 7208 limita el total a diez, contados a través de todos los include anidados. Superarlo da permerror en los receptores, que DMARC trata como fallo; el correo de un dominio con demasiados include acaba en spam el día en que un proveedor añade otro include a su propio registro. La vista de cadena resuelve cada include y muestra el total acumulado; la solución habitual es sustituir include: por los rangos ip4: del proveedor o eliminar remitentes que ya no se usan. Los include que no resuelven a un registro SPF cuentan como «void lookups», de los que se permiten dos.

DMARC y DKIM

DMARC está en _dmarc.dominio y dice qué hacer cuando ni SPF ni DKIM coinciden con la dirección From: p=none observar, p=quarantine carpeta de spam, p=reject rechazar. Las claves públicas DKIM están en selector._domainkey.dominio; el selector está en la etiqueta s= de la cabecera DKIM-Signature de cualquier mensaje enviado, ahí lo encuentras si no lo conoces. Selectores habituales: google (Google Workspace), selector1/selector2 (Microsoft 365), k1 (Mailchimp), default, mail, dkim.

Preguntas

¿Por qué Cloudflare y Google dan respuestas distintas?

Caché. Un resolutor obtuvo el registro antes de tu cambio y lo conserva hasta que expire su TTL; el otro lo obtuvo después. Espera a que expire la TTL antigua, o baja la TTL antes del próximo cambio. Si después siguen discrepando, puede que tus servidores autoritativos no estén sincronizados entre sí (compara el serial del SOA en cada uno).

¿Por qué no hay registro aunque sé que existe?

Comprueba el nombre exacto: www.example.com y example.com son nombres distintos. Un CNAME en el nombre oculta los demás tipos. Si el estado es NXDOMAIN, el nombre no existe; NOERROR sin respuestas significa que el nombre existe pero no tiene registros de ese tipo.

¿Qué significa el indicador DNSSEC (AD)?

El resolutor validó la respuesta contra la cadena de confianza DNSSEC y era correcta. Si la zona está firmada y el indicador falta en ambos resolutores, puede que el registro DS de la zona padre no coincida con la clave de la zona (clásico tras cambiar de proveedor DNS), lo que hace el dominio inalcanzable para los resolutores que validan.

¿Es lo mismo que dig o nslookup?

Casi. dig +dnssec example.com MX @1.1.1.1 hace la misma pregunta al mismo resolutor. Esta página usa los puntos de acceso DNS sobre HTTPS de los resolutores para poder ejecutarse en el navegador; no puede preguntar directamente a tus propios servidores de nombres, así que para respuestas autoritativas usa dig @ns1.tudns.com.

¿Por qué el recuento de consultas SPF difiere del de otra herramienta?

Las herramientas difieren en si cuentan el modificador redirect=, los include anidados y los términos a/mx con argumentos explícitos. Esta página sigue el RFC 7208 sección 4.6.4: include, a, mx, ptr, exists y redirect cuentan todos, en cualquier nivel de anidamiento; ip4, ip6 y all son gratis.