Herramientas populares

Tema

Verificación de salud DNS

Validación de dominio para comprobar DNS de punta a punta: la delegación del registro, cada servidor de nombres consultado directamente, el SOA, DNSSEC y los registros de correo. 40 comprobaciones, cada una con su solución.

Niveles de Zonemaster y de las RFC · cada servidor de nombres consultado por TCP · Google Public DNS · RDAP

Recorre desde un servidor raíz hasta el registro .nl y luego consulta directamente cada servidor de nombres de sidn.nl · 40 comprobaciones · unos 3 sregistro .nl → cada servidor de nombres · 40 comprobaciones

Pruebe
EjemploRegistrado el 23 oct 2026 · desde nuestro servidor.nl3 NSCon firma DNSSEC

sidn.nl supera todas las comprobaciones que se ejecutaron, DNSSEC incluido

registrado en SIDN·2,9 s

40 correctas

A+: nada por encima de info. Todos los servidores de nombres respondieron con autoridad y coincidieron entre sí, los temporizadores están dentro del rango de Zonemaster y Google Public DNS valida la cadena DNSSEC desde la raíz.

Primero los problemas

Consultado por TCP desde nuestro servidor en el borde de Cloudflare: la raíz, el registro .nl y cada servidor de nombres directamente; Google Public DNS y Cloudflare para los registros de correo y la validación. No guardamos ningún registro de lo que usted comprueba.

¿Qué comprueba una verificación de salud DNS?

Una verificación de salud DNS sigue un dominio como lo encuentra un resolutor y prueba cada paso: la delegación del registro, cada servidor de nombres consultado directamente, si esos servidores coinciden, el registro SOA, DNSSEC y los registros de correo. Esta ejecuta 40 comprobaciones en siete grupos y califica cada una con el nivel que fija su autoridad.

La mayoría de los verificadores consultan a un resolutor y califican lo que devuelve. Eso oculta los servidores que hay detrás: un resolutor responde desde el servidor de nombres que funcione, así que uno averiado sigue invisible hasta que los demás también fallan. Aquí cada servidor de nombres se consulta por TCP con la recursión desactivada, la copia de los registros NS que tiene el registro se compara con la de la propia zona, y la cadena DNSSEC se verifica desde el DS en el registro hasta las firmas de la zona.

Úsela como auditoría DNS después de cualquier cambio: comprueba los registros DNS de los que depende un dominio, no solo si carga su sitio web (para eso, el Comprobador de Páginas Caídas revisa el sitio en sí). Copiar informe convierte el resultado en un informe DNS de texto plano que puede pegar en un ticket.

Raízh.root-servers.net
.comRegistro .comh.gtld-servers.net
8 servidores de nombresRoute 53 + NS1
La zonagithub.com
  • DNSSEC7 comprobacionesla cadena de confianza desde la raíz: github.com: la cadena se detiene en .com (sin DS)
  • Zona superior y delegación6 comprobacionesla referencia del registro: 8 nombres · 295 bytes · no necesita glue
  • Servidores de nombres14 comprobacionescada servidor consultado directamente: 8 de 8 autoritativos · por TCP · EDNS · sin recursión
  • Coherencia3 comprobacionessi los servidores coinciden: 2 números de serie SOA, uno por proveedor de DNS · los mismos MX y SPF
  • SOA4 comprobacionestemporizadores bajo los límites de Zonemaster: avisos
  • CAA1 comprobación7 registros · 4 CA permitidas
  • DNS de correo5 comprobacionesMX en Microsoft 365 · SPF 10 de 10 consultas · DMARC quarantine
Dónde mira cada grupo de comprobaciones, en la ruta real de github.com (23 de octubre de 2026): desde la raíz, pasando por el registro .com, hasta los servidores de nombres de la zona en Route 53 y NS1.
Verificación de salud DNS de github.com: calificación A, 40 comprobaciones en 7 grupos y la ruta de la raíz a 8 servidoresVerificación de salud DNS de github.com: calificación A, 40 comprobaciones en 7 grupos y la ruta de la raíz a 8 servidoresLa calificaciónSolo a partir de los niveles: sin críticos, sin errores y dos advertencias dan una A. El anillo muestra la puntuación, 90 de 100.40 comprobaciones, una celda cada unaAgrupadas como las lista la página. Las celdas ámbar y azules son las advertencias y los avisos; las rayadas no se pudieron ejecutar.Primero los problemasLos grupos con algo que corregir se abren arriba, cada fila con su autoridad y su solución.La rutaUn servidor raíz, el registro .com que opera Verisign y luego cada servidor de nombres consultado directamente: su respuesta, su número de serie y EDNS.Cadena de confianzaEl riel de DNSSEC junto a la ruta: verde donde se sostiene, discontinuo donde se detiene, rojo donde se rompe.
Una verificación de salud DNS de github.com. Seleccione un número para ver qué muestra cada parte.

¿Cómo se calcula la calificación?

La letra sale solo de los niveles de lo que falló, nunca de una tabla de puntos: cualquier problema crítico es una F, dos o más errores una D, un error o cinco o más advertencias una C, tres o cuatro advertencias una B, una o dos advertencias (o solo avisos) una A, y nada por encima de info una A+.

Los niveles son los de la propia autoridad citada: el perfil predeterminado de Zonemaster donde define la prueba, el MUST o SHOULD de la RFC donde no lo hace. El número sobre 100 solo ordena los dominios dentro de una misma letra (100 − 30 por crítico, 12 por error, 4 por advertencia, 1 por aviso). Las comprobaciones que nuestro servidor no puede ejecutar nunca cuentan en contra de un dominio; cuando no se puede ejecutar una cuarta parte o más, la calificación indica parcial.

  1. A+100nada por encima de infoINFO “definitivamente no indica un problema”sidn.nl100
  2. A90–991–2 advertencias, o solo avisosNOTICE “debería conocerlo el administrador de la zona, pero no tiene por qué ser un problema en absoluto”github.com90example.com95bücher.de90
  3. B75–893–4 advertenciasWARNING “en algunas circunstancias será un problema, pero es poco probable que lo note un usuario ocasional”cloudflare.com87google.com83
  4. C60–741 error, o 5 advertencias o másERROR “muy probablemente (o quizá con certeza) afectará de forma negativa al funcionamiento de la zona”ninguno en la muestra
  5. D45–592 errores o másdnssec-failed.org55
  6. F0–44cualquier problema críticoCRITICAL “puede decirse razonablemente que no existe”un dominio .com44

puntuación = 100 − 30 × crítico − 12 × error − 4 × advertencia − 1 × aviso, dentro de la franja de la letra

parcialuna cuarta parte o más de las comprobaciones no se pudo ejecutar desde nuestro servidor, y la calificación lo indica

La escala, con los dominios que comprobamos el 23 de octubre de 2026 ubicados según su calificación registrada. Niveles citados de las definiciones de gravedad de Zonemaster.

¿Coinciden los registros NS de la zona superior y de la zona hija?

Deberían: el registro (la zona superior) y la zona (la hija) publican cada uno un conjunto NS, y la RFC 1912 §2.8 pide mantenerlos iguales. Cuando el registro apunta a un servidor que no responde por la zona, se trata de una delegación defectuosa (lame): el servidor responde REFUSED, o responde sin la bandera de respuesta autoritativa (AA).

Los resolutores pasan al siguiente servidor, así que un servidor defectuoso cuesta tiempo; cuando todos los servidores listados son defectuosos, el dominio deja de resolverse. Zonemaster califica como error los nombres que solo lista el registro (EXTRA_NAME_PARENT), como aviso los que solo lista la zona, y como crítico que no haya ningún servidor que funcione.

github.comcoinciden

Registro .com
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
La zona
  • los mismos 8

8 de 8 responden con AA

un dominio .netno coinciden

Registro .net
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
La zona
  • ns1.hover.com
  • ns2.hover.com

ningún nombre en común · ns2.domaindirect.com REFUSED · 2 errores

un dominio .comdelegación defectuosa

Registro .com
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
La zona
  • nadie respondeSERVFAIL

todos los servidores responden REFUSED · los resolutores responden SERVFAIL · CRITICAL

Tres delegaciones registradas el 23 de octubre de 2026. Se omiten los nombres de las dos defectuosas; sus servidores de nombres y sus respuestas son reales.

¿Cuántos servidores de nombres necesita un dominio?

Al menos dos, y se recomiendan tres. La RFC 1034 §4.1 exige que toda zona esté disponible en al menos dos servidores, y la RFC 2182 §5 recomienda tres para la mayoría de las zonas de nivel organizacional. Un solo servidor de nombres es un error en Zonemaster; dos pasan con una nota informativa.

Dónde están importa más que cuántos son, así que la comprobación de servidores de nombres también revisa sus redes. Los servidores de una misma red fallan juntos: Zonemaster advierte cuando todas las direcciones están en un mismo sistema autónomo (IPV4_ONE_ASN), incluso con hosts anycast como Google, Cloudflare o Akamai, cuyas direcciones responden cada una desde muchos sitios. Anycast reparte la carga; sigue siendo un solo operador.

  • google.com4 NS · 1 reduna sola red
  • github.com8 NS · 2 redesrepartidos
  • sidn.nl3 NS · 2 redesrepartidos
  • cloudflare.com5 NS · 1 reduna sola red
  • nasa.gov6 NS · 1 reduna sola red
  • example.com2 NS · 1 reduna sola red

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

“Se recomienda proporcionar tres servidores para la mayoría de las zonas de nivel organizacional, con al menos uno que debe estar bien alejado de los demás.” RFC 2182 §5
Un punto por servidor de nombres, coloreado según la red (AS) desde la que se anuncia su dirección, en las ejecuciones registradas el 23 de octubre de 2026. Una sola red es la advertencia IPV4_ONE_ASN de Zonemaster, con anycast o sin él.

¿Son correctos los valores de su registro SOA?

Si los fijó un gran proveedor de DNS, casi con seguridad están bien, aunque un verificador los marque. Refresh (actualización), retry (reintento) y expire (caducidad) solo controlan a los servidores secundarios que copian la zona por transferencia de zona. Minimum (mínimo) es el TTL de la caché negativa (RFC 2308): cuánto tiempo recuerdan los resolutores que un nombre no existe.

RIPE-203 (1999) recomienda refresh 86400, retry 7200, expire 3600000 y minimum 172800, este último de antes de la RFC 2308. Zonemaster fija límites inferiores más bajos: refresh 14400 y retry 3600 (avisos), expire 604800 (la única advertencia), minimum entre 300 y 86400 (un aviso). Los valores predeterminados de Cloudflare, Route 53 y Azure quedan por debajo de los límites de refresh y retry; el expire de 3 días de Google Cloud DNS es la única advertencia entre los grandes proveedores.

actualizaciónZonemaster ≥ 4 h · ◆ 1 dreintentoZonemaster ≥ 1 h · ◆ 2 hcaducidadZonemaster ≥ 7 d · ◆ 41,7 dmínimoZonemaster 5 min – 1 d · ◆ 2 d
Cloudflare2,8 h40 min7 d30 min2 avisos
Amazon Route 532 h15 min14 d1 d2 avisos
Google Cloud DNS6 h1 h3 d5 min1 advertencia
Azure DNS1 h5 min28 d5 min2 avisos
GoDaddy8 h2 h7 d1 hcorrecto
Namecheap BasicDNS12 h1 h7 d1 hcorrecto
google.com (DNS propio)15 min15 min30 min1 min1 advertencia · 3 avisos

bajo el límite de ZonemastercorrectoavisoadvertenciaRIPE-203 (1999)

Los valores de cada proveedor tal como los servían sus zonas por dig el 23 de octubre de 2026: Cloudflare, Route 53 y Google Cloud DNS coinciden con su documentación; la página de ayuda de GoDaddy indica un mínimo de 600, pero sus zonas de ejemplo sirven 3600; no encontramos valores predeterminados publicados para Azure DNS ni Namecheap BasicDNS, así que los suyos son los valores de sus zonas. Escala logarítmica de 1 minuto a 6 semanas.

Comprobación DNSSEC (DNSSEC check): DS, DNSKEY y firmas

Una comprobación DNSSEC recorre la cadena de confianza: el DS publicado en el registro debe ser el digest de una clave (DNSKEY) de la zona, esa clave debe firmar el conjunto de claves de la zona, y cada firma (RRSIG) debe verificarse y estar dentro de su periodo de validez. Esta comprobación calcula el digest y verifica cada firma por sí misma, y luego pregunta a Google Public DNS si la valida.

Si se rompe cualquier eslabón, los resolutores que validan responden SERVFAIL: el dominio desaparece para todos los que dependen de ellos. dnssec-failed.org, una zona de prueba rota a propósito, muestra dos rupturas a la vez. Los algoritmos se juzgan según el registro de la IANA (RFC 9904): se recomiendan el 8, el 13 y el 15, mientras que el 5 y el 7, que firman con SHA-1, ya no deben usarse (RFC 9905) y Zonemaster los califica como error.

cloudflare.comsegura

  1. DS 2371 en .comalgoritmo 13 · SHA-256 · 329968…26F2B9
  2. el digest coincide con la clave 2371
  3. DNSKEY 2371 · KSKbanderas 257 · ECDSA P-256 (13)
  4. firma el conjunto de claves · restan 50,8 días de 61 días
  5. DNSKEY 34505 · ZSKbanderas 256 · ECDSA P-256 (13)
  6. firma los registros · SOA: restan 1 día de 2 días
  7. Google Public DNSbandera AD activada: segura

dnssec-failed.orginválida

  1. DS 42069 en .orgalgoritmo 13 · SHA-256
  2. no hay clave 42069 en la zona
  3. DNSKEY 50719 · KSKla clave de firma de claves real de la zona
  4. su firma del conjunto de claves caducó hace 112 días
  5. DNSKEY 32784 · ZSKfirma el SOA: válida, restan 5,7 días de 7 días
  6. no le llega nada de confianza
  7. Google Public DNSSERVFAIL; responde al activar CD: inválida

Algoritmos de firma (registro de la IANA, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519use estos
  • MAY14 ECDSAP384SHA384 · 16 ED448permitidos
  • NOT RECOMMENDED10 RSASHA512Zonemaster WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster ERROR

las dos cadenas de arriba firman con el 13

Dos cadenas registradas el 23 de octubre de 2026: la de cloudflare.com se sostiene; la de dnssec-failed.org se rompe en el DS y otra vez en una firma caducada.

DNS de correo: MX, SPF y DMARC

Las comprobaciones de correo leen lo mismo que leen los servidores receptores: los registros MX (o un MX nulo que indica que el dominio no recibe correo, RFC 7505), un único registro SPF dentro del límite de 10 consultas DNS de la RFC 7208, y una política DMARC (RFC 9989, que reemplazó a la RFC 7489 en mayo de 2026).

El SPF se evalúa, no solo se encuentra: cada include se sigue y se cuenta. El registro de github.com necesita exactamente 10 consultas más una consulta vacía (void lookup): válido, sin margen. Un dominio que nunca envía correo debería decirlo: example.com publica el conjunto de dominio estacionado, un MX nulo, v=spf1 -all y p=reject. Para los detalles, el Verificador SPF y el Verificador DMARC van más allá.

github.comenvía y recibe

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 1 host · no es un alias
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all10 de 10 consultas DNS1 de 2 consultas vacías · válido, sin margen
DMARC
p=quarantine; sp=rejectinformes a 1 dirección · subdominios: reject

example.comconjunto de dominio estacionado

MX
0 .MX nulo: no recibe correo (RFC 7505)
SPF
v=spf1 -allno envía correo · 0 consultas
DMARC
p=reject; sp=rejectse rechaza todo lo que diga ser example.com
github.com y example.com, tal como estaban publicados el 23 de octubre de 2026.

Comprobar DNS desde la línea de comandos (dig)

Cuatro pasos con dig y delv repiten lo esencial de esta comprobación: seguir la delegación desde la raíz, consultar un servidor de nombres directamente con la recursión desactivada, comparar el DS en el registro con las claves de la zona y dejar que un resolutor que valida juzgue la cadena.

Agregue +tcp para ver lo que ve nuestro servidor; omítalo para probar UDP, algo que una herramienta web en la red de Cloudflare no puede hacer. En la cabecera de la respuesta, aa marca una respuesta autoritativa; REFUSED, o la falta de la bandera aa en un servidor que lista el registro, es una delegación defectuosa.

Terminal · dig 9.20

$ dig +trace +tcp github.com NS
;; (abreviado)
com.          172800 IN NS a.gtld-servers.net.   ;; desde h.root-servers.net 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; desde h.gtld-servers.net: 8 NS 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; sin DS: sin firmar 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. La raíz remite .com a sus 13 servidores
  2. El conjunto NS de github.com en el registro, conservado 2 días
  3. aa: una respuesta autoritativa, no una caché
  4. SOA: número de serie 1, luego actualización, reintento, caducidad y mínimo
  5. Sin DS en .com: nada que verificar para DNSSEC
  6. delv validó la cadena desde la raíz
Respuestas reales para github.com y cloudflare.com (23 de octubre de 2026), abreviadas. Las marcas numeradas corresponden a las notas.

¿Por qué distintas herramientas para verificar DNS no coinciden?

Porque califican con números distintos. Los verificadores clásicos marcan los valores predeterminados de los proveedores: intoDNS llama “NOT OK” al expire de 1800 segundos de google.com y da error por los dos números de serie de github.com, que son normales con dos proveedores de DNS. Zonemaster califica los números de serie como advertencia y reconoce un MX nulo; nuestra propia primera versión no acertó en ninguno de los dos.

Y ven la red desde lugares distintos. Zonemaster (AFNIC y la Fundación Sueca de Internet) consulta por UDP y TCP, en IPv4 e IPv6. Esta comprobación se ejecuta en el borde de Cloudflare: consulta solo por TCP, no se conecta por IPv6 y no puede conectarse a las direcciones propias de Cloudflare, así que esos servidores se leen mediante 1.1.1.1 y sus comprobaciones se marcan como sin probar, nunca como fallidas. Como alternativa a intoDNS, muestra la autoridad detrás de cada nivel en lugar de un simple OK o NOT OK.

CasointoDNSZonemasterDNS Robot v1Esta comprobación
github.comdos números de serie SOA (dos proveedores de DNS)error“Looks like your nameservers do not agree on the SOA serial.”advertenciaMULTIPLE_SOA_SERIALSfalla“Serial mismatch detected: 1656468023 vs 1.”advertenciaexplicado: un número de serie por proveedor de DNS
google.comcaducidad (expire) del SOA 1800 sno OK“Your SOA EXPIRE number is: 1800. That is NOT OK”advertenciaEXPIRE_MINIMUM_VALUE_LOWERfalla“too low (min recommended: 14 days)”advertenciacon lo que afecta la caducidad
example.comMX nulo (0 .)error“0 No A Record (no glue either)”infoZ09_VALID_NULL_MXcorrecto“Found 1 MX record(s)”correctoMX nulo reconocido
cloudflare.comreintento (retry) del SOA 2400 s—sin citaavisoRETRY_MINIMUM_VALUE_LOWERfalla“too high (max recommended: 15min)”avisoel valor predeterminado de Cloudflare
cloudflare.comfirmado con DNSSECsin comprobarsin prueba de DNSSECcorrectoDNSSEC02 · 05 · 08: cadena verificadaalerta“DNSSEC does not appear to be enabled for this domain.”correctoDS → KSK → RRSIG verificados, Google valida
Los mismos dominios en cuatro verificadores. Resultados de intoDNS y v1 citados de sus páginas y respuestas del 22–23 de octubre de 2026; los niveles de Zonemaster, de sus especificaciones de prueba. La última columna es esta comprobación: una alternativa a intoDNS que califica cada hallazgo con el nivel que fija su autoridad.

Verificación de salud DNS: preguntas frecuentes

¿Qué es una verificación de salud DNS?

Una verificación de salud DNS, o validación de registros DNS, comprueba si el DNS de un dominio está configurado para que todo internet pueda llegar a él: la delegación del registro, cada servidor de nombres, el registro SOA, DNSSEC y los registros de correo. Cada hallazgo se califica según cuánto daño puede causar, de info a crítico, y este validador DNS muestra la regla que aplica (una prueba de Zonemaster o una sección de una RFC) y la solución.

¿La validación de dominio es lo mismo que una verificación de salud DNS?

No siempre. “Validación de dominio” también nombra la comprobación que hace una autoridad de certificación antes de emitir un certificado DV, y el registro TXT que piden Google Workspace o Microsoft 365 para demostrar que un dominio es suyo. Este validador de dominios comprueba el DNS del dominio: delegación, servidores de nombres, SOA, DNSSEC y registros de correo. Para un certificado, consulte el Verificador SSL.

¿Qué es una delegación defectuosa (lame) y cómo se corrige?

Una delegación defectuosa es un servidor de nombres que el registro lista pero que no responde por su dominio: contesta REFUSED o responde sin autoridad. Corríjala donde está la diferencia: agregue la zona en ese proveedor de DNS, o cambie los servidores de nombres en su registrador por los que tienen la zona. Si todos los servidores listados son defectuosos, el dominio no se resuelve en absoluto.

Mi proveedor de DNS usa anycast. ¿Por qué la advertencia de una sola red?

Porque un operador es un solo dominio de fallo. Anycast permite que cada dirección responda desde muchos sitios, lo que protege contra la caída de un sitio, no contra una caída del propio proveedor ni un error en su configuración. Por eso Zonemaster mantiene IPV4_ONE_ASN como advertencia, y la RFC 2182 pide servidores en redes diversas. Un segundo proveedor de DNS en otra red la elimina.

Mis temporizadores SOA aparecen marcados. ¿Debo cambiarlos?

Normalmente no. Refresh, retry y expire solo importan a los servidores secundarios que copian su zona por transferencia de zona; grandes proveedores como Cloudflare y Route 53 no los usan para su zona, y sus valores predeterminados están bien. Un expire de menos de una semana es lo único que Zonemaster considera una advertencia. Cambie los valores solo si opera su propio servidor primario y sus secundarios.

¿Por qué algunas comprobaciones aparecen como “sin probar”?

Porque nuestro servidor no pudo ejecutarlas, no porque algo esté mal. Funciona en la red de Cloudflare, que no puede abrir conexiones a las direcciones propias de Cloudflare, y consulta solo por TCP, sin conectarse por IPv6. Esos servidores se leen en cambio mediante el resolutor 1.1.1.1 de Cloudflare. Las comprobaciones sin probar nunca bajan la calificación; una cuarta parte o más la marca como parcial.

¿Por qué mis servidores de nombres muestran números de serie SOA distintos?

O bien un secundario aún no se ha puesto al día con un cambio, o su dominio usa dos proveedores de DNS que no se transfieren la zona entre sí, así que cada uno lleva su propio número de serie. Lo segundo es normal: los servidores de Route 53 de github.com dicen 1 y los de NS1, 1656468023. Zonemaster marca cualquier diferencia como advertencia; nosotros explicamos de qué caso se trata.

¿Sirve como DNSSEC check? ¿Baja la calificación si no hay DNSSEC?

Sí: compara el DS en el registro con las claves de la zona y verifica cada firma, y luego consulta a Google Public DNS. Una zona sin firmar es una advertencia de Zonemaster (DS07_NOT_SIGNED), así que la calificación queda en A como máximo. Una cadena rota es mucho peor que no tener ninguna: los resolutores que validan rechazan el dominio, un error que baja la calificación a C o menos.

¿Cada cuánto debo verificar el DNS de mi dominio?

Después de cada cambio de servidores de nombres, DNSSEC o registros de correo, y antes y después de pasar a un nuevo proveedor de DNS o registrador. Fuera de eso, una vez al mes basta para detectar una firma a punto de caducar, un servidor de nombres que dejó de responder o un cambio en el registro que usted no hizo. Cada resultado tiene su propio enlace, así que puede comparar ejecuciones.

¿Guardan los dominios que compruebo?

No. La comprobación se ejecuta en nuestro servidor, en el borde de Cloudflare, y consulta a la raíz, al registro, a sus servidores de nombres, a Google Public DNS y al resolutor de Cloudflare; no se guarda nada asociado a su dirección. Una ejecución terminada se conserva 10 minutos para que una repetición o un enlace compartido respondan al instante, y luego se descarta. Sus servidores de nombres reciben unas 20 preguntas de nuestro servidor por ejecución.

Herramientas relacionadas