Check de registro DNS

Qué verifica

Un monitor DNS resuelve un tipo de registro de un nombre desde cada una de sus regiones en cada intervalo. Por defecto responde el resolver propio de la sonda, así que el check ve la zona en su conjunto. Si la configuración indica un servidor de nombres, la sonda le pregunta directamente, sin caché de por medio. Así se ve cuándo un servidor de un grupo falla o responde distinto. La respuesta se evalúa frente a tus aserciones y, si pasa, se valida contra DNSSEC. También puede cotejarse con el último conjunto de respuestas de otro monitor de la organización, de modo que 2 nombres que deben coincidir hacen fallar el check cuando divergen.

Úsalo cuando

• Un nombre debe seguir resolviendo a una dirección, un intercambiador de correo o un alias conocidos, como el host web, el registro MX o un CNAME a un proveedor.
• Cada servidor de un grupo de servidores de nombres debe responder, y responder lo mismo. Crea un monitor por servidor, cada uno con server apuntando a ese servidor.
• Dos nombres deben coincidir, por ejemplo el apex y www, o el mismo registro en 2 zonas. Una referencia cruzada al otro monitor convierte una divergencia en un check fallido.

Compara un tipo de registro de un nombre. Para la coherencia de NS y SOA entre los servidores autoritativos, la caducidad del dominio registrado y el estado DNSSEC de un dominio entero, usa el check de dominio. Usa el check de higiene DNS para SPF, DMARC y CAA como postura, y el check HTTP(S) o TCP para saber si responde el servicio que hay detrás de la dirección.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Configuración

Objetivo. El campo de configuración name contiene el nombre a consultar, y el formulario lo etiqueta como Dominio. Al guardar solo se comprueba el formato, sin resolver el nombre. Se acepta un nombre de host sin esquema, ruta ni espacios, un literal IP o una etiqueta única, con etiquetas de hasta 63 caracteres y 253 en total.

Cómo se ejecuta un check

1. Cada región a la que le toca el intervalo compila primero la expresión regular y resuelve el tipo de registro. Un patrón inválido o un tipo no admitido terminan el check como error antes de enviar ninguna consulta.
2. Se elige el resolver: el resolver de medición propio del nodo o el servidor de nombres indicado en server. Su nombre de host se resuelve con el resolver del nodo y se valida contra los rangos bloqueados, que incluyen direcciones de loopback, privadas, link-local y de metadatos de nube.
3. La consulta se ejecuta y se cronometra, y el tiempo de consulta es la latencia del check. El motor DNS no aplica a la propia consulta el límite fijo de 10 s del monitor, y el nodo detiene cualquier ejecución a los 120 s.
4. Una respuesta vacía hace fallar el check. En otro caso, expected, expected_regex y expected_all se combinan con AND.
5. A una respuesta que pasa le sigue la comprobación DNSSEC sobre DS, DNSKEY y la caducidad de las RRSIG. Una cadena bogus o una firma caducada hacen fallar el check, y cualquier otro resultado deja el veredicto como está.
6. El control plane aplica la referencia cruzada cuando registra un resultado superado con un conjunto de respuestas no vacío. Un modo desconocido actúa como identical, y una discrepancia hace fallar el check con gravedad critical. Un veredicto fallido entra entonces en la evaluación de incidentes, y la política de alertas (regiones y checks consecutivos) decide cuándo se abre un incidente.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Qué contiene un resultado

Respuesta

La línea de detalle lista los registros de la respuesta, separados por comas. Con un servidor de nombres concreto, le sigue la dirección que respondió como (via IP).

Tiempo de consulta

El tiempo de la consulta por región es la latencia del resultado.

Conjunto de respuestas

El control plane conserva el conjunto de respuestas normalizado de cada check superado: en minúsculas, ordenado y sin duplicados. Una referencia cruzada compara este conjunto. No forma parte del resultado del check por API.

Capa de causa

Un fallo en el objetivo se atribuye a la capa target_dns. Las evidencias del incidente lo muestran, así que un registro ausente no se clasifica como fallo de red.

Región

Cada resultado lleva la región que lo midió. No hay subresultados por familia IP ni por dirección.

Estados y gravedad

• okLa respuesta contiene al menos un registro y todas las aserciones coinciden. DNSSEC no es bogus, ninguna firma ha caducado y la referencia cruzada, si está definida, coincide.
• caídoLa respuesta no contiene registros, una aserción no coincide o la referencia cruzada diverge. El check también falla con una cadena DNSSEC bogus o una RRSIG caducada. También lo hace fallar un error de consulta distinto de NXDOMAIN o un servidor de nombres indicado que no se puede resolver.
• errorEl nombre no existe (NXDOMAIN), la regex es inválida, el tipo de registro no se admite o el servidor de nombres indicado está en una dirección privada o interna. 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 motor no devuelve estado degradado para este tipo, solo superado, fallido o error. 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. Los 11 tipos de check de sonda comparten este cupo.

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": "Apex A record",
  "type": "dns",
  "interval_seconds": 60,
  "config": {
    "name": "example.com",
    "record_type": "A",
    "expected": "203.0.113.10"
  }
}

Cada interfaz, con su límite

Límites

• Un tipo de registro por monitor. Un nombre con un registro A y otro AAAA necesita 2 monitores.
• No hay comparación de SOA, serial ni delegación entre los servidores autoritativos. Eso lo cubre el check de dominio.
• Los registros TXT se comparan como texto, no se analizan.
• Con server apuntando a una dirección anycast, cada región llega a su instancia más cercana. La línea de detalle muestra la dirección a la que se preguntó realmente.
• Este tipo no admite address_families y no devuelve subresultados por dirección. Ejecuta una consulta por región, a través del resolver del nodo o del servidor de nombres indicado.
• Un nombre que no existe (NXDOMAIN) es un error, no una aserción fallida. Ambos abren un incidente cuando el quórum lo confirma.
• La referencia cruzada necesita un monitor de la misma organización con al menos un conjunto de respuestas registrado: un monitor DNS o un monitor de dominio con su conjunto NS. Un objetivo sin conjunto de respuestas deja la referencia cruzada inactiva, así que el resultado queda como se midió. API y MCP solo aceptan el id público del monitor, y el formulario ofrece un selector con todos los monitores del proyecto.

Tipos de check relacionados

• Check de dominioDelegación en cada servidor de nombres autoritativo, caducidad del dominio y DNSSEC de un dominio registrable.
• Check de higiene DNSSPF, DMARC con su política y CAA de un dominio, calificados como postura y nunca como caída.
• Check HTTP(S)Disponibilidad y respuesta de una URL, con aserciones sobre estado, cuerpo y TLS.
• Check de puerto TCPSi un puerto acepta conexiones, opcionalmente con el certificado que sirve.

Todos los tipos de check