Check de dominio · Perstat

En esta página

Qué verifica
Configuración
Cómo se ejecuta un check
Qué contiene un resultado
Estados y gravedad
Planes y límites
Desde la pipeline o un agente
Límites
Tipos de check relacionados

Qué verifica

Un monitor de dominio lee el conjunto NS del apex de un dominio registrable desde cada una de sus regiones en cada intervalo. Pide el SOA de la zona directamente a cada servidor de nombres autoritativo y compara los seriales. Así revela un desfase de replicación, un servidor de nombres inalcanzable o uno que no sirve la zona. Después lee la caducidad del dominio en el WHOIS y valida DNSSEC, con el registro DS en el padre, la DNSKEY y la RRSIG que caduca antes.

Úsalo cuando

Un dominio lleva tráfico o correo de producción, y su delegación debe seguir siendo coherente en todos los servidores de nombres, incluido un secundario que opera otra persona.
Un dominio no debe caducar sin que nadie lo vea. La fecha de caducidad debe convertirse en hallazgo 14 días antes por defecto, o en el umbral que fijes.
El dominio está firmado con DNSSEC, y una RRSIG caducada o una validación BOGUS deben abrir un incidente, no esperar a la primera queja.

Para registros individuales y conjuntos de respuestas, usa el check de registro DNS. Para SPF, DMARC y CAA, usa el check de higiene DNS. Una etiqueta única no es un dominio registrable y se rechaza al guardar el monitor.

El formulario de monitor con el tipo Dominio y el campo de dominio. También muestra el área de texto para los servidores de nombres esperados, uno por línea, y el umbral de aviso de caducidad del dominio en días. — El formulario de dominio con dominio, NS esperados y el umbral de aviso de caducidad del dominio. Interfaz real del producto, datos de ejemplo.

Configuración

Dominio. Un dominio registrable con al menos 2 etiquetas, como example.com, sin esquema, ruta ni espacios. El check lee el conjunto NS del apex de exactamente ese nombre.

Campo	Obligatorio	Valores y valor por defecto	Significado
`domain`Dominio	sí	Dominio registrable, al menos 2 etiquetas	El dominio cuya delegación, caducidad y estado DNSSEC se comprueban.
`expected_ns`NS esperados (opcional)	opcional	Lista de nombres de servidores de nombres. Formulario: uno por línea o separados por comas	Cada nombre listado debe aparecer en el conjunto NS del apex, sin distinguir mayúsculas y sin contar el punto final. Un nombre que falte pone el check en degraded, y los servidores de nombres de la zona que no estén listados no son un hallazgo.
`warn_days`Avisar cuando queden (días)	opcional	Días, por defecto 14	El check pasa a degraded cuando el dominio caduca dentro de este número de días. A diferencia de la ventana de aviso del certificado, este umbral cambia el estado del monitor.
`interval_seconds`Intervalo del check	opcional	Por defecto 300 s. Rango: del mínimo del plan a 24 h	Cada cuánto ejecuta el check cada región. Un valor fuera del rango se eleva al mínimo del plan o se limita a 24 h, no se rechaza.
`regions`Regiones	opcional	Subconjunto de na, eu, as, sa, af, oce. Por defecto: las regiones del plan	Qué continentes ejecutan el check. Si lo omites, el plan aplica su conjunto por defecto.

Cómo se ejecuta un check

Cada región a la que le toca el intervalo lee el conjunto NS del apex con el resolver propio del nodo. Una consulta fallida o un conjunto vacío hacen fallar el check ahí mismo.
Cada servidor de nombres se resuelve a sus direcciones, IPv4 primero e IPv6 como alternativa. Se le pide directamente el SOA de la zona, y el presupuesto de 10 s del check permite hasta 5 s por servidor de nombres. Cuenta la primera dirección que responde, y cada servidor de nombres recibe su propio subresultado con serial y dirección.
Después se evalúa el componente de zona. Si ningún servidor de nombres devuelve un SOA, el check falla. Un servidor de nombres esperado que falta, unos seriales divergentes o una respuesta de solo una parte de los servidores dan degraded.
La caducidad del dominio se lee en el WHOIS: IANA indica el servidor WHOIS del TLD, la sonda pregunta a ese servidor por el puerto TCP 43 y analiza la fecha de caducidad. La sonda guarda la respuesta 24 h en la caché de su proceso, así que cada nodo de sonda pregunta al registro de dominios una vez al día, no en cada intervalo. Cada una de las 2 consultas WHOIS, a IANA y al servidor del TLD, tiene un timeout de 8 s.
DNSSEC se valida con el resolver validador del nodo, con el registro DS en el padre, la DNSKEY y la RRSIG que caduca antes. Una RRSIG con 3 días o menos restantes da degraded, y una firma caducada o una validación BOGUS hacen fallar el check. Un dominio sin firmar supera este componente.
El peor componente fija el resultado, y la línea de detalle lleva los 3 componentes. El nodo termina con un error una ejecución que supera los 120 s. La región envía su resultado al control plane, donde la política de alertas decide si un fallo abre un incidente cuando el quórum lo confirma.

La vista del monitor de un check de dominio para perstat.io con uptime y el veredicto de la zona. También muestra una línea por servidor de nombres con su serial SOA y su dirección, la caducidad del dominio y el estado DNSSEC. — La vista del monitor con servidores de nombres y seriales SOA, caducidad del dominio y DNSSEC para perstat.io. Interfaz real del producto, datos de ejemplo.

Qué contiene un resultado

Zona y delegación: La línea indica cuántos servidores de nombres respondieron, si sus seriales SOA coinciden y qué serial lleva la zona. Si falta un servidor de nombres esperado en el conjunto NS, la línea lo nombra en su lugar.
Por servidor de nombres: Un subresultado por servidor de nombres autoritativo: SOA serial 2026091301 @ 203.0.113.53, NS IP not resolvable o ningún SOA con el último error que devolvió el servidor.
Caducidad del dominio: Días hasta que caduca el dominio. Dentro de la ventana de aviso, la línea dice registration expires in 12d. Sin una respuesta utilizable del registro de dominios, dice expiry unknown (WHOIS could not determine it).
DNSSEC: La línea dice DNSSEC valid (RRSIG 12d) o not DNSSEC signed, o nombra una firma que caduca dentro de 3 días. Informa de BOGUS cuando existe un registro DS pero la validación falla. El resultado DNSSEC not checkable (DNSKEY not resolvable) también pasa.
Tiempo de consulta: latency_ms lleva la duración de la consulta NS y de las consultas SOA. La consulta WHOIS y la validación DNSSEC no forman parte de él.
Servidores de nombres: values lleva el conjunto NS del apex tal como se leyó, en minúsculas y sin el punto final.
Capa de causa: Un componente fallido o degradado se atribuye al DNS del objetivo (target_dns). Una consulta NS fallida se clasifica por su error: NXDOMAIN o NODATA como target_dns, cualquier otro como unknown.
Región: Cada resultado lleva la región que lo midió. Este tipo no tiene subresultados por familia IP ni por dirección.

Estados y gravedad

okTodos los servidores de nombres responden con el mismo serial SOA, y todos los servidores esperados están presentes. El dominio caduca más allá de warn_days desde hoy, y DNSSEC valida o el dominio no está firmado. Una consulta WHOIS sin respuesta utilizable mantiene este estado e informa expiry unknown.
degradadoFalta un servidor de nombres esperado en el conjunto NS, los seriales SOA divergen o solo responde una parte de los servidores. El check también da degraded cuando el dominio caduca dentro de warn_days o una RRSIG caduca dentro de 3 días.
caídoLa consulta NS falla o no devuelve registros, o ningún servidor de nombres entrega un SOA. El check también falla cuando el dominio ha caducado, DNSSEC es BOGUS o una RRSIG ha caducado.
errorEl dominio está vacío o el resolver del nodo no se puede inicializar. Cuenta como caída con gravedad critical.

Confirmado por quórum: por defecto, 2 regiones deben informar del fallo antes de que se abra un incidente. El valor por defecto de la organización pide 2 regiones y 2 checks consecutivos. Un monitor puede llevar su propia regla (número o porcentaje, checks consecutivos y duración mínima).

Planes y límites

Intervalo mínimo: Free permite 300 s, Pulse 60 s y Sentinel 30 s. Command permite 15 s y Enterprise 10 s, ambos solo por MCP. El formulario web ofrece 30 s, 1 min, 5 min, 15 min y 1 h.
Regiones: Free ejecuta 2 de 6 regiones y Pulse 3 de 6. Las 6 están disponibles desde Sentinel.
Monitores: Free incluye 10 monitores de sonda, Pulse 50, Sentinel 150 y Command 500. Los cupos de Enterprise son a medida. La cuenta abarca los 11 tipos de check regionales.

Comparar todos los límites

Desde la pipeline o un agente

La misma config sirve en el paso de despliegue, en un cliente MCP como Claude Code y en el formulario de arriba. create_monitor necesita una clave de API válida para toda la organización. Si omites regions, el plan aplica su valor por defecto.

{
  "name": "Company domain",
  "type": "domain",
  "interval_seconds": 300,
  "config": {
    "domain": "example.com",
    "expected_ns": ["ns1.example.net", "ns2.example.net"],
    "warn_days": 30
  }
}

Cada interfaz, con su límite

Límites

La caducidad viene del WHOIS y puede no estar disponible. No hay RDAP. Un TLD sin referencia en IANA, o con una respuesta que el analizador no entiende, informa expiry unknown y sigue en ok.
No se leen el bloqueo de registrador ni el estado de transferencia.
El umbral de aviso de RRSIG está fijado en 3 días. warn_days se aplica solo a la caducidad del dominio.
No hay familias de direcciones ni subresultados por dirección. A los servidores de nombres se les pregunta primero por IPv4 y por IPv6 solo como alternativa.
No se comprueban registros individuales, ni tampoco SPF, DMARC y CAA. El check de registro DNS cubre los registros, y el check de higiene DNS cubre SPF, DMARC y CAA.
El conjunto NS de la delegación en el padre no se compara con el conjunto NS del apex.

Todos los tipos de check