docs: add checker reference pages and update homepage feature list

Add individual reference pages for all domain health checkers (EN/FR),
update the homepage feature descriptions in both languages to highlight
monitoring, notifications, and domain availability checks.

content/_index.en.md

@@ -15,13 +15,15 @@ to have all the power of domain names, without having to read and learn all the
 Here's an overview of happyDomain's main features:
 
 - consolidate domain names from over 45 domain name providers or authoritative servers,
-- guide administrators with clear forms,
-- clearly visualize the changes that will be propagated,
-- keep a history of changes made to the zone,
-- return to a previous zone status with a single click,
-- group records by services/needs: email, delegation, server, load balancing, etc.
 - abstract all technical complexity into a logical view,
-- import/export the zone as a standard file,
+- group records by services/needs: email, website, delegation, load balancing, etc.
+- guide administrators with clear forms,
+- review the details of your changes before publishing, and pick exactly which ones to apply,
+- keep a history of changes and roll back to a previous zone state with a single click,
+- monitor your domains and services with automatic checks (expiration, DNSSEC, response time, etc.),
+- get notified as soon as a check changes state,
+- check whether a domain is available for registration and inspect any domain (WHOIS, DNS resolver),
+- import/export the zone as a standard file (BIND format),
 - keep track of actions for later auditing,
 - automate tasks via a REST API.
 

content/_index.fr.md

@@ -15,13 +15,15 @@ avoir toute la puissances des noms de domaines, sans devoir lire et apprendre to
 Voici un aperçu des principales fonctionnalités d'happyDomain :
 
 - regrouper les noms de domaines de plus de 45 prestataires de nom de domaine ou serveurs faisant autorité,
-- guider l'administrateur au moyen de formulaires clairs,
-- visualiser clairement les changements qui seront propagés,
-- garder un historique des changements effectués sur la zone,
-- pouvoir revenir à un état antérieur de la zone en un clic,
-- regrouper les enregistrements par services/besoins : emails, délégation, serveur, répartition de charge, ...
 - abstraire toute la complexité technique en une vue logique,
-- importer/exporter la zone sous forme d'un fichier standard,
+- regrouper les enregistrements par services/besoins : e-mails, site web, délégation, répartition de charge, ...
+- guider l'administrateur au moyen de formulaires clairs,
+- visualiser le détail des changements avant de les publier, et choisir précisément ceux à appliquer,
+- garder un historique des changements et revenir à un état antérieur de la zone en un clic,
+- surveiller vos domaines et services grâce à des vérifications automatiques (expiration, DNSSEC, temps de réponse, ...),
+- être alerté par notifications dès qu'une vérification change d'état,
+- vérifier la disponibilité d'un domaine à l'enregistrement et inspecter n'importe quel domaine (WHOIS, résolveur DNS),
+- importer/exporter la zone sous forme d'un fichier standard (format BIND),
 - garder une trace des actions pour les auditer plus tard,
 - automatiser des tâches via une API REST.
 

content/reference/checkers/_index.en.md

@@ -0,0 +1,36 @@
+---
+date: 2026-06-11T09:00:00+02:00
+title: Checkers
+author: nemunaire
+archetype: chapter
+weight: 35
+aliases:
+    checkers
+---
+
+Checkers are the building blocks of happyDomain's monitoring system. Each one collects data about a domain, a zone or a service, evaluates it against a set of rules, and reports a clear status (OK, Warning, Critical or Error).
+
+This chapter documents every checker shipped with happyDomain: what it verifies, the scope it applies to, the options you can tune, and the rules it evaluates. For the day-to-day workflow of configuring, scheduling and reading checks in the interface, see {{< relref "/pages/checks" >}}.
+
+## Scopes
+
+Every checker declares the scope it operates on:
+
+- **Domain-level** — concerns the domain itself, independent of its DNS records (registration status, expiry, transfer lock…).
+- **Zone-level** — needs the full zone content (DNSSEC validation, delegation consistency…).
+- **Service-level** — targets a specific service published on a subdomain (HTTP, TLS, ping…), and is configured from that service's own **Checks** tab.
+
+## Statuses
+
+Checkers report one of the following statuses, in order of severity:
+
+| Status | Meaning |
+|--------|---------|
+| **OK** | Everything is within acceptable parameters |
+| **Info** | Informational finding, no action needed |
+| **Warning** | A threshold is approaching; attention recommended |
+| **Critical** | A threshold has been exceeded; action required |
+| **Error** | The check itself failed (collection error, bad configuration) |
+| **Unknown** | The check could not determine a result |
+
+{{% children %}}

content/reference/checkers/_index.fr.md

@@ -0,0 +1,36 @@
+---
+date: 2026-06-11T09:00:00+02:00
+title: Vérificateurs
+author: nemunaire
+archetype: chapter
+weight: 35
+aliases:
+    checkers
+---
+
+Les vérificateurs sont les briques de base du système de surveillance de happyDomain. Chacun collecte des données sur un domaine, une zone ou un service, les évalue selon un ensemble de règles, puis rapporte un état clair (OK, Avertissement, Critique ou Erreur).
+
+Ce chapitre documente chaque vérificateur fourni avec happyDomain : ce qu'il contrôle, la portée à laquelle il s'applique, les options que vous pouvez régler et les règles qu'il évalue. Pour le fonctionnement au quotidien (configuration, planification et lecture des résultats dans l'interface), consultez {{< relref "/pages/checks" >}}.
+
+## Portées
+
+Chaque vérificateur déclare la portée sur laquelle il opère :
+
+- **Niveau domaine** : concerne le domaine lui-même, indépendamment de ses enregistrements DNS (statut d'enregistrement, expiration, verrou de transfert...).
+- **Niveau zone** : nécessite le contenu complet de la zone (validation DNSSEC, cohérence de la délégation...).
+- **Niveau service** : cible un service précis publié sur un sous-domaine (HTTP, TLS, ping...), et se configure depuis l'onglet **Vérifications** de ce service.
+
+## États
+
+Les vérificateurs rapportent l'un des états suivants, par ordre de gravité :
+
+| État | Signification |
+|------|---------------|
+| **OK** | Tout se situe dans les paramètres acceptables |
+| **Info** | Information utile, aucune action requise |
+| **Avertissement** | Un seuil est sur le point d'être atteint ; attention recommandée |
+| **Critique** | Un seuil a été dépassé ; action requise |
+| **Erreur** | La vérification elle-même a échoué (erreur de collecte, mauvaise configuration) |
+| **Inconnu** | La vérification n'a pas pu déterminer de résultat |
+
+{{% children %}}

content/reference/checkers/alias.en.md

@@ -0,0 +1,49 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Alias chain
+description: "Walks a CNAME/DNAME/ALIAS chain and validates hop count, TTLs, target resolvability, apex coexistence and DNSSEC signing."
+weight: 130
+---
+
+The **CNAME / DNAME / ALIAS chain** checker follows the alias chain of a name and verifies that it resolves cleanly: no loops, not too many hops, sane TTLs, a resolvable final target, no forbidden record coexistence, and a properly signed CNAME RRset when the zone uses DNSSEC.
+
+This is a **service-level** checker: it runs on a `CNAME` (or special CNAME) service and is configured from that service's own **Checks** tab. Starting from the queried name it locates the zone apex, walks each CNAME/DNAME hop, and finally resolves the chain's target to A/AAAA records.
+
+## What it checks
+
+Each rule emits a finding code. Some severities are softened by the options below.
+
+| Rule | What it verifies / flags | Severity |
+|------|--------------------------|----------|
+| `apex_lookup` | The zone apex (SOA) for the queried name can be located. | Critical |
+| `chain_loop` | A CNAME/DNAME cycle in the resolution chain. | Critical |
+| `chain_length` | The chain exceeds **Maximum chain length** hops. | Critical |
+| `chain_query_error` | A DNS query fails while walking the chain (network error, timeout). | Warning |
+| `chain_rcode` | A non-NOERROR response code mid-chain or on the final A/AAAA lookup. | Critical (mid-chain) / Warning (final) |
+| `hop_ttl` | A CNAME/DNAME hop has a TTL below **Minimum target TTL**. | Warning |
+| `cname_at_apex` | A CNAME exists at the zone apex, conflicting with SOA/NS (RFC 1912 §2.4). | Critical / Warning |
+| `apex_flattening` | A/AAAA coexist with SOA/NS at the apex without a CNAME (provider-side ALIAS/ANAME flattening). | Info |
+| `cname_coexistence` | Other RRsets (beyond A/AAAA) coexist at a CNAME owner, violating RFC 1034 §3.6.2 / RFC 2181 §10.1. | Critical / Warning at apex |
+| `cname_dnssec` | The zone is DNSSEC-signed but the CNAME RRset lacks an RRSIG. | Critical |
+| `target_resolvable` | The final target of the chain has no A or AAAA record. | Critical |
+| `multiple_records` | An owner in the chain carries more than one CNAME/DNAME record (malformed). | Critical |
+
+{{% notice style="info" title="Why a CNAME at the apex is a problem" %}}
+A CNAME owner may carry no other record type, but the zone apex must always hold SOA and NS records. The two requirements are mutually exclusive, so a CNAME at the apex is invalid (RFC 1912 §2.4). Some providers work around this with server-side ALIAS/ANAME "flattening" that publishes plain A/AAAA at the apex; the `apex_flattening` rule recognises that pattern as intentional when **Recognize ALIAS/ANAME flattening** is enabled.
+{{% /notice %}}
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Maximum chain length | Above this number of hops the chain is reported as critical. | `8` |
+| Minimum target TTL | Hops with a TTL below this threshold (seconds) are flagged as a warning. | `60` |
+| Allow CNAME at apex | When enabled, a CNAME at a zone apex and its coexistence violations are downgraded to warnings. RFC 1912 forbids this, so leaving it off is strongly recommended. | `false` |
+| Recognize ALIAS/ANAME flattening | When enabled, providers serving A/AAAA at the apex (ALIAS/ANAME pseudo-records) are recognised as intentional and excused from coexistence violations. | `true` |
+
+## In happyDomain
+
+Add the CNAME service to the subdomain, then enable this checker from that service's **Checks** tab. See {{< relref "/pages/checks" >}} for configuring and scheduling checks. The parent domain and subdomain are filled in automatically.
+
+Related checkers: {{< relref "/reference/checkers/dangling" >}} watches for alias targets that have become unregistered or NXDOMAIN, and {{< relref "/reference/checkers/ptr" >}} covers the reverse-DNS side.

content/reference/checkers/alias.fr.md

@@ -0,0 +1,49 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Chaîne d'alias
+description: "Parcourt une chaîne CNAME/DNAME/ALIAS et valide le nombre de sauts, les TTL, la résolvabilité de la cible, la coexistence à l'apex et la signature DNSSEC."
+weight: 130
+---
+
+Le vérificateur **Chaîne CNAME / DNAME / ALIAS** suit la chaîne d'alias d'un nom et vérifie qu'elle se résout proprement : pas de boucle, pas trop de sauts, des TTL raisonnables, une cible finale résolvable, aucune coexistence d'enregistrements interdite et un RRset CNAME correctement signé lorsque la zone utilise DNSSEC.
+
+Il s'agit d'un vérificateur de **niveau service** : il s'exécute sur un service `CNAME` (ou CNAME spécial) et se configure depuis l'onglet **Vérifications** de ce service. À partir du nom interrogé, il localise l'apex de la zone, parcourt chaque saut CNAME/DNAME, puis résout la cible de la chaîne vers des enregistrements A/AAAA.
+
+## Ce qui est vérifié
+
+Chaque règle émet un code de constat. Certaines sévérités sont atténuées par les options ci-dessous.
+
+| Règle | Ce qui est vérifié ou signalé | Sévérité |
+|-------|-------------------------------|----------|
+| `apex_lookup` | L'apex de la zone (SOA) du nom interrogé peut être localisé. | Critique |
+| `chain_loop` | Un cycle CNAME/DNAME dans la chaîne de résolution. | Critique |
+| `chain_length` | La chaîne dépasse le nombre de sauts de **Longueur maximale de chaîne**. | Critique |
+| `chain_query_error` | Une requête DNS échoue pendant le parcours de la chaîne (erreur réseau, délai dépassé). | Avertissement |
+| `chain_rcode` | Un code de réponse autre que NOERROR en milieu de chaîne ou sur la résolution A/AAAA finale. | Critique (milieu) / Avertissement (final) |
+| `hop_ttl` | Un saut CNAME/DNAME a un TTL inférieur à **TTL minimal de la cible**. | Avertissement |
+| `cname_at_apex` | Un CNAME existe à l'apex de la zone, en conflit avec SOA/NS (RFC 1912 §2.4). | Critique / Avertissement |
+| `apex_flattening` | Des A/AAAA coexistent avec SOA/NS à l'apex sans CNAME (aplatissement ALIAS/ANAME côté hébergeur). | Info |
+| `cname_coexistence` | D'autres RRset (au-delà de A/AAAA) coexistent chez un propriétaire CNAME, en violation des RFC 1034 §3.6.2 / RFC 2181 §10.1. | Critique / Avertissement à l'apex |
+| `cname_dnssec` | La zone est signée DNSSEC mais le RRset CNAME ne possède pas de RRSIG. | Critique |
+| `target_resolvable` | La cible finale de la chaîne n'a aucun enregistrement A ni AAAA. | Critique |
+| `multiple_records` | Un propriétaire de la chaîne porte plus d'un enregistrement CNAME/DNAME (malformé). | Critique |
+
+{{% notice style="info" title="Pourquoi un CNAME à l'apex pose problème" %}}
+Un propriétaire de CNAME ne peut porter aucun autre type d'enregistrement, mais l'apex de la zone doit toujours contenir des enregistrements SOA et NS. Ces deux exigences sont incompatibles : un CNAME à l'apex est donc invalide (RFC 1912 §2.4). Certains hébergeurs contournent cela par un aplatissement ALIAS/ANAME côté serveur qui publie de simples A/AAAA à l'apex ; la règle `apex_flattening` reconnaît ce motif comme intentionnel lorsque l'option **Reconnaître l'aplatissement ALIAS/ANAME** est activée.
+{{% /notice %}}
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Longueur maximale de chaîne | Au-delà de ce nombre de sauts, la chaîne est rapportée comme critique. | `8` |
+| TTL minimal de la cible | Les sauts dont le TTL est inférieur à ce seuil (en secondes) sont signalés comme avertissement. | `60` |
+| Autoriser un CNAME à l'apex | Lorsqu'activée, un CNAME à l'apex d'une zone et ses violations de coexistence sont rétrogradés en avertissements. La RFC 1912 l'interdit : il est fortement recommandé de laisser cette option désactivée. | `false` |
+| Reconnaître l'aplatissement ALIAS/ANAME | Lorsqu'activée, les hébergeurs servant des A/AAAA à l'apex (pseudo-enregistrements ALIAS/ANAME) sont reconnus comme intentionnels et dispensés des violations de coexistence. | `true` |
+
+## Dans happyDomain
+
+Ajoutez le service CNAME au sous-domaine, puis activez ce vérificateur depuis l'onglet **Vérifications** de ce service. Consultez {{< relref "/pages/checks" >}} pour configurer et planifier les vérifications. Le domaine parent et le sous-domaine sont renseignés automatiquement.
+
+Vérificateurs apparentés : {{< relref "/reference/checkers/dangling" >}} surveille les cibles d'alias devenues non enregistrées ou NXDOMAIN, et {{< relref "/reference/checkers/ptr" >}} couvre le versant DNS inverse.

content/reference/checkers/authoritative-consistency.en.md

@@ -0,0 +1,51 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Authoritative consistency
+description: "Probes every authoritative name server of a zone and verifies they agree with each other and with the parent on NS, SOA, reachability, EDNS0 and authoritativeness."
+weight: 80
+---
+
+The **Authoritative consistency** checker probes every authoritative name server of a zone and verifies that they agree — with one another and with the parent delegation. Where the {{< relref "/reference/checkers/delegation" >}} checker focuses on the parent/child hand-off, this checker concentrates on the *apex itself*: do all the servers serve the same `NS` and `SOA`, are they all reachable over UDP and TCP, do they support EDNS0, do they answer authoritatively, and how fast do they respond?
+
+This checker is **service-level**: it targets an *Origin* or *NS-only Origin* service (`abstract.Origin`, `abstract.NSOnlyOrigin`) and is configured from that service's **Checks** tab.
+
+## What it checks
+
+Each rule emits a finding code. Several severities depend on the options below.
+
+| Finding code | Default severity | Condition |
+|---|---|---|
+| `authoritative_consistency_no_ns` | Critical | No name servers could be discovered (declared list empty and parent query returned nothing). |
+| `authoritative_consistency_too_few_ns` | Warning | Fewer name servers declared than `minNameServers` (RFC 1034 recommends at least 2). |
+| `authoritative_consistency_parent_query_failed` | Warning | The parent delegation query failed (network error, REFUSED…). |
+| `authoritative_consistency_parent_drift` | Warning | The parent's `NS` RRset does not match the `NS` declared in the service. |
+| `authoritative_consistency_ns_unresolvable` | Critical | A declared name server has no `A` or `AAAA` record. |
+| `authoritative_consistency_ns_udp_failed` | Critical | A name server did not answer any SOA query over UDP/53. |
+| `authoritative_consistency_ns_tcp_failed` | Critical with `requireTCP`, else Warning | A name server did not answer over TCP/53 (required by RFC 7766 and DNSSEC). |
+| `authoritative_consistency_lame` | Critical | A name server answered without the AA bit for the zone (lame delegation). |
+| `authoritative_consistency_no_soa` | Critical | A name server is authoritative but returned no `SOA`. |
+| `authoritative_consistency_edns_unsupported` | Warning | A name server drops or mishandles EDNS0 queries (RFC 6891). |
+| `authoritative_consistency_slow_ns` | Info | A name server's response time exceeded `latencyThresholdMs`. |
+| `authoritative_consistency_serial_drift` | Warning | Authoritative servers disagree on the `SOA` serial (zone not fully propagated). |
+| `authoritative_consistency_serial_stale_vs_saved` | Warning | The serial saved in happyDomain is newer than what the servers publish (likely un-pushed change). |
+| `authoritative_consistency_serial_ahead_of_saved` | Info | The servers publish a serial newer than the saved one (out-of-band change). |
+| `authoritative_consistency_soa_fields_drift` | Warning | Servers disagree on `SOA` fields (MNAME, RNAME, refresh, retry, expire, minimum). |
+| `authoritative_consistency_ns_rrset_drift` | Warning | Servers disagree on the `NS` RRset they publish at the apex. |
+| `authoritative_consistency_ns_rrset_mismatch_config` | Warning | The published `NS` RRset does not match the `NS` declared in the service. |
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| `requireTCP` | When enabled, a server that fails over TCP is critical (otherwise warning). TCP/53 is required by RFC 7766 and DNSSEC. | `true` |
+| `checkEDNS` | Probe each name server for EDNS0 (RFC 6891). Servers that mishandle EDNS0 break DNSSEC and large answers. | `true` |
+| `checkLatency` | Measure response time of every name server and warn on slow responders. | `true` |
+| `latencyThresholdMs` | Response times above this value trigger a slow-server warning. | `500` |
+| `useParentNS` | Query the parent for the delegation `NS` RRset and compare it to the service's declared name servers. | `true` |
+| `warnOnStaleSaved` | Warn when the saved `SOA` serial is newer than what authoritative servers publish. | `true` |
+| `minNameServers` | Below this count, a warning is emitted (RFC 1034 recommends at least 2). | `2` |
+
+## In happyDomain
+
+Enable the Authoritative consistency checker from the **Checks** tab of an Origin service. See {{< relref "/pages/checks" >}} for the full workflow. To compare what *recursive resolvers around the world* see against the authoritative answer, pair it with {{< relref "/reference/checkers/resolver-propagation" >}}.

content/reference/checkers/authoritative-consistency.fr.md

@@ -0,0 +1,51 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Cohérence des serveurs faisant autorité
+description: "Sonde chaque serveur faisant autorité d'une zone et vérifie qu'ils s'accordent entre eux et avec le parent sur les NS, le SOA, la joignabilité, EDNS0 et l'autorité."
+weight: 80
+---
+
+Le vérificateur **Cohérence des serveurs faisant autorité** sonde chaque serveur faisant autorité d'une zone et vérifie qu'ils s'accordent, entre eux et avec la délégation parente. Là où le vérificateur {{< relref "/reference/checkers/delegation" >}} se concentre sur le passage de relais parent/enfant, celui-ci porte sur l'*apex lui-même* : tous les serveurs servent-ils les mêmes `NS` et `SOA`, sont-ils tous joignables en UDP et en TCP, prennent-ils en charge EDNS0, répondent-ils de façon autoritaire, et à quelle vitesse répondent-ils ?
+
+Ce vérificateur s'applique au niveau du **service** : il cible un service d'origine ou d'origine NS-seule (`abstract.Origin`, `abstract.NSOnlyOrigin`) et se configure depuis l'onglet **Vérifications** de ce service.
+
+## Ce qu'il vérifie
+
+Chaque règle émet un code de constat. Plusieurs sévérités dépendent des options ci-dessous.
+
+| Code de constat | Sévérité par défaut | Condition |
+|---|---|---|
+| `authoritative_consistency_no_ns` | Critique | Aucun serveur de noms n'a pu être découvert (liste déclarée vide et requête parente sans réponse). |
+| `authoritative_consistency_too_few_ns` | Avertissement | Moins de serveurs déclarés que `minNameServers` (la RFC 1034 recommande au moins 2). |
+| `authoritative_consistency_parent_query_failed` | Avertissement | La requête de délégation parente a échoué (erreur réseau, REFUSED, etc.). |
+| `authoritative_consistency_parent_drift` | Avertissement | Le RRset `NS` du parent ne correspond pas aux `NS` déclarés dans le service. |
+| `authoritative_consistency_ns_unresolvable` | Critique | Un serveur de noms déclaré n'a aucun enregistrement `A` ni `AAAA`. |
+| `authoritative_consistency_ns_udp_failed` | Critique | Un serveur de noms n'a répondu à aucune requête SOA en UDP/53. |
+| `authoritative_consistency_ns_tcp_failed` | Critique avec `requireTCP`, sinon avertissement | Un serveur de noms n'a pas répondu en TCP/53 (exigé par la RFC 7766 et par DNSSEC). |
+| `authoritative_consistency_lame` | Critique | Un serveur de noms a répondu sans le bit AA pour la zone (délégation boiteuse). |
+| `authoritative_consistency_no_soa` | Critique | Un serveur fait autorité mais n'a renvoyé aucun `SOA`. |
+| `authoritative_consistency_edns_unsupported` | Avertissement | Un serveur ignore ou gère mal les requêtes EDNS0 (RFC 6891). |
+| `authoritative_consistency_slow_ns` | Info | Le temps de réponse d'un serveur a dépassé `latencyThresholdMs`. |
+| `authoritative_consistency_serial_drift` | Avertissement | Les serveurs divergent sur le numéro de série `SOA` (zone non entièrement propagée). |
+| `authoritative_consistency_serial_stale_vs_saved` | Avertissement | Le numéro de série enregistré dans happyDomain est plus récent que celui publié (changement probablement non poussé). |
+| `authoritative_consistency_serial_ahead_of_saved` | Info | Les serveurs publient un numéro de série plus récent que celui enregistré (changement hors bande). |
+| `authoritative_consistency_soa_fields_drift` | Avertissement | Les serveurs divergent sur les champs `SOA` (MNAME, RNAME, refresh, retry, expire, minimum). |
+| `authoritative_consistency_ns_rrset_drift` | Avertissement | Les serveurs divergent sur le RRset `NS` qu'ils publient à l'apex. |
+| `authoritative_consistency_ns_rrset_mismatch_config` | Avertissement | Le RRset `NS` publié ne correspond pas aux `NS` déclarés dans le service. |
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| `requireTCP` | Si activé, un serveur défaillant en TCP est critique (sinon avertissement). TCP/53 est exigé par la RFC 7766 et par DNSSEC. | `true` |
+| `checkEDNS` | Sonde chaque serveur de noms pour EDNS0 (RFC 6891). Les serveurs qui gèrent mal EDNS0 cassent DNSSEC et les grandes réponses. | `true` |
+| `checkLatency` | Mesure le temps de réponse de chaque serveur et avertit en cas de lenteur. | `true` |
+| `latencyThresholdMs` | Les temps de réponse au-delà de cette valeur déclenchent un avertissement de lenteur. | `500` |
+| `useParentNS` | Interroge le parent pour le RRset `NS` de délégation et le compare aux serveurs de noms déclarés dans le service. | `true` |
+| `warnOnStaleSaved` | Avertit lorsque le numéro de série `SOA` enregistré est plus récent que celui publié par les serveurs faisant autorité. | `true` |
+| `minNameServers` | En dessous de ce nombre, un avertissement est émis (la RFC 1034 recommande au moins 2). | `2` |
+
+## Dans happyDomain
+
+Activez le vérificateur Cohérence des serveurs faisant autorité depuis l'onglet **Vérifications** d'un service d'origine. Consultez {{< relref "/pages/checks" >}} pour le déroulé complet. Pour comparer ce que voient les *résolveurs récursifs à travers le monde* à la réponse faisant autorité, associez-le à {{< relref "/reference/checkers/resolver-propagation" >}}.

content/reference/checkers/blacklist.en.md

@@ -0,0 +1,35 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Blacklist (DNSBL)
+description: "Checks whether a domain is currently listed on widely-used reputation systems: DNS-based domain blocklists, downloaded phishing/malware feeds, and threat-intelligence APIs."
+weight: 320
+---
+
+The **Blacklist & reputation** checker flags whether a domain is currently listed on widely-used reputation systems. It queries a range of sources in parallel and produces a diagnosis-first HTML report whose "Action required" section lists the most impactful listings with a per-operator removal procedure.
+
+**Scope:** domain-level. The check targets the domain name itself, independent of its DNS records, and is enabled from the domain's checks view.
+
+## What it checks
+
+Each configured source contributes its own per-source rule; a listing on any of them raises the domain's status. The sources fall into three families:
+
+- **DNS-based domain blocklists (DBL/RHSBL)** — queried over DNS, no API key required: Spamhaus DBL, SURBL multi, URIBL multi, NordSpam DBL, SpamEatingMonkey Fresh, Tiopan DBL, SORBS RHSBL, plus any extra DNSBL zones an administrator adds.
+- **Downloaded phishing/malware feeds** — fetched and cached in memory: OpenPhish public feed, PhishTank, Botvrij.eu, Disconnect.me, OISD, and a Quad9 secure-DNS comparison.
+- **Threat-intelligence HTTPS lookups** — requiring an API key configured by an administrator: Google Safe Browsing, abuse.ch URLhaus / ThreatFox / MalwareBazaar, VirusTotal v3, AlienVault OTX, Pulsedive, Criminal IP.
+
+When a DNSBL query is refused (many public resolvers are blocked by DBL operators) or an API quota is exhausted, the source is surfaced as a Warning so it does not pollute the OK status. A multi-vendor source such as VirusTotal reports Critical when at least one vendor flags the domain as malicious, and Warning when it is only suspicious.
+
+## Options
+
+The only domain-level option is the target itself:
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Domain name (`domain_name`) | The domain to look up. Auto-filled from the domain. | (from domain) |
+
+All source selection and credentials are configured per source. Most sources are toggled on or off (and API keys supplied) at the **administrator** level; a subset of the downloaded-feed sources default to on and can be toggled by the user. See the source's own documentation for which sources need an API key and how to obtain one.
+
+## In happyDomain
+
+This is a domain-level checker: enable it from the domain's checks view. Listings often reflect a compromise; treat a positive result as a signal to audit the host and rotate credentials, then follow the per-operator delisting links shown in the report. For the general workflow of configuring and reading checks, see {{< relref "/pages/checks" >}}.

content/reference/checkers/blacklist.fr.md

@@ -0,0 +1,35 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Liste noire (DNSBL)
+description: "Vérifie si un domaine est actuellement listé sur des systèmes de réputation répandus : listes noires de domaines basées sur le DNS, flux de phishing/malware téléchargés et API de renseignement sur les menaces."
+weight: 320
+---
+
+Le vérificateur **Liste noire et réputation** signale si un domaine est actuellement listé sur des systèmes de réputation répandus. Il interroge en parallèle une série de sources et produit un rapport HTML orienté diagnostic dont la section « Action requise » liste les inscriptions les plus impactantes avec une procédure de retrait propre à chaque opérateur.
+
+**Portée** : niveau domaine. La vérification cible le nom de domaine lui-même, indépendamment de ses enregistrements DNS, et s'active depuis la vue des vérifications du domaine.
+
+## Ce qu'il vérifie
+
+Chaque source configurée contribue à sa propre règle ; une inscription sur l'une d'elles élève le statut du domaine. Les sources se répartissent en trois familles :
+
+- **Listes noires de domaines basées sur le DNS (DBL/RHSBL)** : interrogées via DNS, sans clé d'API : Spamhaus DBL, SURBL multi, URIBL multi, NordSpam DBL, SpamEatingMonkey Fresh, Tiopan DBL, SORBS RHSBL, ainsi que toute zone DNSBL supplémentaire ajoutée par un administrateur.
+- **Flux de phishing/malware téléchargés** : récupérés et mis en cache en mémoire : flux public OpenPhish, PhishTank, Botvrij.eu, Disconnect.me, OISD et une comparaison avec le DNS sécurisé Quad9.
+- **Recherches HTTPS de renseignement sur les menaces** : nécessitant une clé d'API configurée par un administrateur : Google Safe Browsing, abuse.ch URLhaus / ThreatFox / MalwareBazaar, VirusTotal v3, AlienVault OTX, Pulsedive, Criminal IP.
+
+Lorsqu'une requête DNSBL est refusée (de nombreux résolveurs publics sont bloqués par les opérateurs de DBL) ou qu'un quota d'API est épuisé, la source est rapportée comme avertissement afin de ne pas polluer le statut OK. Une source multi-fournisseurs comme VirusTotal rapporte « critique » lorsqu'au moins un fournisseur signale le domaine comme malveillant, et « avertissement » lorsqu'il est seulement suspect.
+
+## Options
+
+La seule option de niveau domaine est la cible elle-même :
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Nom de domaine (`domain_name`) | Le domaine à rechercher. Rempli automatiquement depuis le domaine. | (depuis le domaine) |
+
+La sélection des sources et les identifiants se configurent source par source. La plupart des sources s'activent ou se désactivent (et leurs clés d'API se renseignent) au niveau **administrateur** ; un sous-ensemble des flux téléchargés est activé par défaut et peut être basculé par l'utilisateur. Voir la documentation de chaque source pour savoir lesquelles nécessitent une clé d'API et comment l'obtenir.
+
+## Dans happyDomain
+
+C'est un vérificateur de niveau domaine : activez-le depuis la vue des vérifications du domaine. Les inscriptions reflètent souvent une compromission ; traitez un résultat positif comme un signal pour auditer l'hôte et renouveler les identifiants, puis suivez les liens de retrait propres à chaque opérateur indiqués dans le rapport. Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir {{< relref "/pages/checks" >}}.

content/reference/checkers/caa.en.md

@@ -0,0 +1,42 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: CAA
+description: "Cross-references the TLS certificates observed on a domain against its CAA issue/issuewild policy to detect unauthorized issuance."
+weight: 150
+---
+
+The **CAA Compliance** checker verifies that the TLS certificates actually deployed on a domain were issued by a Certification Authority that the domain's `CAA` records authorize. A `CAA` (Certification Authority Authorization) record lets a domain declare which CAs may issue certificates for it; this checker confirms reality matches that policy.
+
+This is a **service-level** checker: it runs on a `CAA` policy service. It performs **no network probes of its own** — it reads the parsed CAA policy from the service body and the TLS certificates observed by the {{< relref "/reference/checkers/dane" >}} / `checker-tls` family, then maps each observed issuer to its CAA identifier domain using the Common CA Database (CCADB).
+
+## What it checks
+
+A single rule, `caa_compliance`, loads the zone's CAA `issue` / `issuewild` policy, gathers every TLS probe observed on the target, resolves each certificate's issuer (by Authority Key Identifier, falling back to the issuer Distinguished Name) against the embedded CCADB "CAA Identifiers" mapping, and compares the result against the allow list.
+
+| Outcome | Meaning | Status |
+|---------|---------|--------|
+| `caa_ok` | Every observed issuer is authorized by the CAA policy. | OK |
+| `caa_no_tls` | No TLS probes related to this target have been published yet. | Unknown |
+| `caa_not_authorized` | CCADB mapped an observed issuer to a domain the policy does not list. | Critical |
+| `caa_issuance_disallowed` | The policy contains `CAA 0 issue ";"` (issuance explicitly forbidden) but a certificate was still observed. | Critical |
+| `caa_issuer_unknown` | CCADB has no mapping for the observed issuer (AKI + DN). | Info |
+
+{{% notice style="info" title="Eventual consistency with TLS probes" %}}
+The `caa_no_tls` state is a normal steady state, not an error: until `checker-tls` has probed an endpoint on the target and published a certificate, the CAA checker has nothing to compare against and reports **Unknown**. Once probes arrive, the check resolves on its next run. The `caa_issuer_unknown` outcome means the CA simply isn't in the current CCADB snapshot; the fix is to file a CCADB update, not to change your zone.
+{{% /notice %}}
+
+The issuer-to-CAA-domain mapping comes from an embedded snapshot of CCADB's "CAA Identifiers (V2)" report. Refreshing it only requires re-embedding a newer CSV and recompiling — no code change and no network dependency at build time.
+
+## Options
+
+This checker has no user-tunable options. Both inputs are filled in automatically:
+
+| Option | Meaning |
+|--------|---------|
+| Domain | The domain being checked (auto-filled, required). |
+| Service | The CAA policy service body (auto-filled). |
+
+## In happyDomain
+
+Add the CAA policy service to the relevant subdomain (usually the apex), then enable this checker from that service's **Checks** tab. See {{< relref "/pages/checks" >}} for configuring and scheduling checks. For the comparison to produce a verdict, a TLS-probing checker such as {{< relref "/reference/checkers/dane" >}} (or the standalone `checker-tls`) must have observed certificates on the target.

content/reference/checkers/caa.fr.md

@@ -0,0 +1,42 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: CAA
+description: "Recoupe les certificats TLS observés sur un domaine avec sa politique CAA issue/issuewild pour détecter les émissions non autorisées."
+weight: 150
+---
+
+Le vérificateur **Conformité CAA** vérifie que les certificats TLS réellement déployés sur un domaine ont été émis par une autorité de certification que les enregistrements `CAA` du domaine autorisent. Un enregistrement `CAA` (Certification Authority Authorization) permet à un domaine de déclarer quelles autorités de certification peuvent émettre des certificats pour lui ; ce vérificateur confirme que la réalité correspond à cette politique.
+
+Il s'agit d'un vérificateur de **niveau service** : il s'exécute sur un service de politique `CAA`. Il n'effectue **aucune sonde réseau** : il lit la politique CAA déjà analysée dans le corps du service et les certificats TLS observés par la famille {{< relref "/reference/checkers/dane" >}} / `checker-tls`, puis associe chaque émetteur observé à son domaine d'identifiant CAA à l'aide de la base de données Common CA Database (CCADB).
+
+## Ce qui est vérifié
+
+Une seule règle, `caa_compliance`, charge la politique CAA `issue` / `issuewild` de la zone, rassemble chaque sonde TLS observée sur la cible, résout l'émetteur de chaque certificat (par Authority Key Identifier, avec repli sur le Distinguished Name de l'émetteur) à l'aide du mappage « CAA Identifiers » embarqué de CCADB, puis compare le résultat à la liste d'autorisations.
+
+| Résultat | Signification | Statut |
+|----------|---------------|--------|
+| `caa_ok` | Chaque émetteur observé est autorisé par la politique CAA. | OK |
+| `caa_no_tls` | Aucune sonde TLS liée à cette cible n'a encore été publiée. | Inconnu |
+| `caa_not_authorized` | CCADB a associé un émetteur observé à un domaine que la politique ne liste pas. | Critique |
+| `caa_issuance_disallowed` | La politique contient `CAA 0 issue ";"` (émission explicitement interdite) mais un certificat a tout de même été observé. | Critique |
+| `caa_issuer_unknown` | CCADB n'a aucun mappage pour l'émetteur observé (AKI + DN). | Info |
+
+{{% notice style="info" title="Cohérence à terme avec les sondes TLS" %}}
+L'état `caa_no_tls` est un état stable normal, pas une erreur : tant que `checker-tls` n'a pas sondé un point d'accès sur la cible ni publié de certificat, le vérificateur CAA n'a rien à comparer et rapporte **Inconnu**. Dès que les sondes arrivent, la vérification se résout à son exécution suivante. Le résultat `caa_issuer_unknown` signifie simplement que l'autorité n'est pas dans l'instantané CCADB courant ; le correctif consiste à soumettre une mise à jour à CCADB, pas à modifier votre zone.
+{{% /notice %}}
+
+Le mappage émetteur vers domaine CAA provient d'un instantané embarqué du rapport « CAA Identifiers (V2) » de CCADB. Le rafraîchir ne demande que de ré-embarquer un CSV plus récent et de recompiler : aucun changement de code ni dépendance réseau à la compilation.
+
+## Options
+
+Ce vérificateur n'a aucune option réglable par l'utilisateur. Ses deux entrées sont renseignées automatiquement :
+
+| Option | Signification |
+|--------|---------------|
+| Domaine | Le domaine vérifié (renseigné automatiquement, requis). |
+| Service | Le corps du service de politique CAA (renseigné automatiquement). |
+
+## Dans happyDomain
+
+Ajoutez le service de politique CAA au sous-domaine concerné (généralement l'apex), puis activez ce vérificateur depuis l'onglet **Vérifications** de ce service. Consultez {{< relref "/pages/checks" >}} pour configurer et planifier les vérifications. Pour que la comparaison produise un verdict, un vérificateur de sonde TLS comme {{< relref "/reference/checkers/dane" >}} (ou le `checker-tls` autonome) doit avoir observé des certificats sur la cible.

content/reference/checkers/dane.en.md

@@ -0,0 +1,48 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: DANE / TLSA
+description: "Matches a service's TLSA records against the certificate chain actually presented by each endpoint, per RFC 6698."
+weight: 160
+---
+
+The **DANE / TLSA** checker verifies that the `TLSA` records published for a service correctly pin the TLS certificate that the matching endpoint actually presents. DANE (DNS-based Authentication of Named Entities) lets a domain bind a certificate or public key to a name through DNS, secured by DNSSEC; this checker confirms the binding holds.
+
+This is a **service-level** checker: it runs on a `TLSAs` service. It groups the declared TLSA records by `(port, proto, base)`, publishes one TLS endpoint discovery entry per endpoint so `checker-tls` probes it, then matches each TLSA against the observed certificate chain following RFC 6698.
+
+## What it checks
+
+| Rule | What it verifies / flags | Severity |
+|------|--------------------------|----------|
+| `dane.has_records` | At least one TLSA record is declared on the service. | — |
+| `dane.dnssec_validated` | The TLSA records were fetched via a DNSSEC-validating resolver (AD bit set). | — |
+| `dane.probe_available` | A TLS probe is available for every DANE endpoint so the chain can be compared. | — |
+| `dane.handshake_ok` | The TLS handshake succeeds on every DANE endpoint. | — |
+| `dane.records_match_chain` | At least one TLSA record matches the certificate chain presented by each endpoint. | — |
+| `dane.pkix_chain_valid` | When usages 0 or 1 are published, the chain also validates against system trust roots. | — |
+| `dane.usage_coherent` | Flags TLSA records whose declared usage does not match the chain slot they actually hash (e.g. usage 3 matching an intermediate). | — |
+
+### How the TLSA fields are interpreted
+
+- **Usage 0 (PKIX-TA) / 1 (PKIX-EE)** — the TLSA must match *and* the chain must validate against the public PKIX trust roots.
+- **Usage 2 (DANE-TA) / 3 (DANE-EE)** — the TLSA itself acts as the trust anchor; PKIX validity is informational.
+- **Selector** 0 (full certificate) or 1 (Subject Public Key Info), and **matching type** 0 (full) / 1 (SHA-256) / 2 (SHA-512), are matched against the chain slot implied by the usage.
+
+{{% notice style="info" title="DANE relies on DNSSEC" %}}
+DANE is only trustworthy when the TLSA records are served from a DNSSEC-signed zone and validated by the resolver. The `dane.dnssec_validated` rule checks that the records arrived with the AD (Authenticated Data) bit set; without DNSSEC, a TLSA record could be forged and the whole binding is meaningless.
+{{% /notice %}}
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Probe timeout (ms) | Forwarded to `checker-tls` as the per-endpoint TLS probe timeout. | `checker-tls` default |
+| STARTTLS override | A map keyed by `"<port>/<proto>"` overriding the STARTTLS application used when probing. Common STARTTLS ports (25, 110, 143, 389, 587, 5222, 5269) are auto-mapped; set this only for non-standard ports. | (auto) |
+
+The domain, subdomain and TLSAs service are filled in automatically.
+
+## In happyDomain
+
+Add the TLSA service to the subdomain, then enable this checker from that service's **Checks** tab. See {{< relref "/pages/checks" >}} for configuring and scheduling checks. The checker publishes its endpoints for `checker-tls` to probe, so allow a probe cycle before the first match result appears.
+
+Related checker: {{< relref "/reference/checkers/caa" >}} verifies, on the same certificates, that the issuing CA was authorized by the domain's CAA policy.

content/reference/checkers/dane.fr.md

@@ -0,0 +1,48 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: DANE / TLSA
+description: "Compare les enregistrements TLSA d'un service à la chaîne de certificats réellement présentée par chaque point d'accès, selon la RFC 6698."
+weight: 160
+---
+
+Le vérificateur **DANE / TLSA** vérifie que les enregistrements `TLSA` publiés pour un service épinglent correctement le certificat TLS que le point d'accès correspondant présente réellement. DANE (DNS-based Authentication of Named Entities) permet à un domaine de lier un certificat ou une clé publique à un nom via le DNS, sécurisé par DNSSEC ; ce vérificateur confirme que la liaison tient.
+
+Il s'agit d'un vérificateur de **niveau service** : il s'exécute sur un service `TLSAs`. Il regroupe les enregistrements TLSA déclarés par `(port, proto, base)`, publie une entrée de découverte de point d'accès TLS par point d'accès afin que `checker-tls` le sonde, puis compare chaque TLSA à la chaîne de certificats observée selon la RFC 6698.
+
+## Ce qui est vérifié
+
+| Règle | Ce qui est vérifié ou signalé | Sévérité |
+|-------|-------------------------------|----------|
+| `dane.has_records` | Au moins un enregistrement TLSA est déclaré sur le service. | variable |
+| `dane.dnssec_validated` | Les enregistrements TLSA ont été récupérés via un résolveur validant DNSSEC (bit AD positionné). | variable |
+| `dane.probe_available` | Une sonde TLS est disponible pour chaque point d'accès DANE afin de comparer la chaîne. | variable |
+| `dane.handshake_ok` | La poignée de main TLS réussit sur chaque point d'accès DANE. | variable |
+| `dane.records_match_chain` | Au moins un enregistrement TLSA correspond à la chaîne de certificats présentée par chaque point d'accès. | variable |
+| `dane.pkix_chain_valid` | Lorsque les usages 0 ou 1 sont publiés, la chaîne se valide aussi face aux racines de confiance du système. | variable |
+| `dane.usage_coherent` | Signale les TLSA dont l'usage déclaré ne correspond pas à l'emplacement de chaîne qu'ils hachent réellement (par exemple un usage 3 correspondant à un intermédiaire). | variable |
+
+### Interprétation des champs TLSA
+
+- **Usage 0 (PKIX-TA) / 1 (PKIX-EE)** : le TLSA doit correspondre *et* la chaîne doit se valider face aux racines de confiance PKIX publiques.
+- **Usage 2 (DANE-TA) / 3 (DANE-EE)** : le TLSA fait lui-même office d'ancre de confiance ; la validité PKIX est informative.
+- Le **sélecteur** 0 (certificat complet) ou 1 (Subject Public Key Info), et le **type de correspondance** 0 (complet) / 1 (SHA-256) / 2 (SHA-512), sont comparés à l'emplacement de chaîne impliqué par l'usage.
+
+{{% notice style="info" title="DANE repose sur DNSSEC" %}}
+DANE n'est digne de confiance que si les enregistrements TLSA proviennent d'une zone signée DNSSEC et sont validés par le résolveur. La règle `dane.dnssec_validated` vérifie que les enregistrements sont arrivés avec le bit AD (Authenticated Data) positionné ; sans DNSSEC, un enregistrement TLSA pourrait être falsifié et toute la liaison perd son sens.
+{{% /notice %}}
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Délai de sonde (ms) | Transmis à `checker-tls` comme délai d'expiration de la sonde TLS par point d'accès. | défaut de `checker-tls` |
+| Surcharge STARTTLS | Une table indexée par `"<port>/<proto>"` surchargeant l'application STARTTLS utilisée lors de la sonde. Les ports STARTTLS courants (25, 110, 143, 389, 587, 5222, 5269) sont associés automatiquement ; ne renseignez ceci que pour des ports non standard. | (auto) |
+
+Le domaine, le sous-domaine et le service TLSAs sont renseignés automatiquement.
+
+## Dans happyDomain
+
+Ajoutez le service TLSA au sous-domaine, puis activez ce vérificateur depuis l'onglet **Vérifications** de ce service. Consultez {{< relref "/pages/checks" >}} pour configurer et planifier les vérifications. Le vérificateur publie ses points d'accès pour que `checker-tls` les sonde : laissez donc passer un cycle de sonde avant l'apparition du premier résultat de correspondance.
+
+Vérificateur apparenté : {{< relref "/reference/checkers/caa" >}} vérifie, sur les mêmes certificats, que l'autorité émettrice était bien autorisée par la politique CAA du domaine.

content/reference/checkers/dangling.en.md

@@ -0,0 +1,42 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Dangling records
+description: "Scans a zone for CNAME/MX/SRV/NS records whose targets resolve to NXDOMAIN or whose external domain has expired and could be re-registered."
+weight: 140
+---
+
+The **Dangling subdomains** checker scans a zone for pointer records (`CNAME`, `MX`, `SRV`, `NS`) whose targets have gone stale: they resolve to NXDOMAIN, or their external registrable domain has expired, is in `pendingDelete`, or was recently re-registered. This is the subdomain-takeover attack class popularised in 2017, where institutions ended up serving hostile content from CNAMEs pointing at decommissioned third-party services after attackers re-registered the lapsed targets.
+
+This is a **zone-level** checker: it needs the full zone content and runs a single pass over it, consolidating findings by owner rather than producing one result per record.
+
+## What it checks
+
+The checker walks every service in the working zone and extracts pointer records from `CNAME`, special CNAME, `MX`, unknown `SRV` and orphan (bare `NS`/`CNAME`/`MX`) bodies. For each `(owner, type, target)` triple it classifies the target as in-zone or external (relative to the zone's registrable domain), performs a single time-bounded DNS resolution to detect immediate breakage, and publishes a discovery entry so a companion `domain_expiry` checker can run RDAP/WHOIS on external targets.
+
+It emits one finding per impacted owner, ranked by descending severity:
+
+| Signal | Severity | Source |
+|--------|----------|--------|
+| Target NXDOMAIN | Critical | Local DNS resolution |
+| Target SERVFAIL | Warning | Local DNS resolution |
+| Target NOERROR with empty answer | Info | Local DNS resolution |
+| Registrable domain expired | Critical | `whois` related observation |
+| Registrable status `pendingDelete` / `redemptionPeriod` | Critical | `whois` related observation |
+| Registrable domain registered within the last 90 days | Warning | `whois` related observation |
+
+{{% notice style="info" title="WHOIS signals need a companion checker" %}}
+The DNS-resolution signals (NXDOMAIN, SERVFAIL, empty answer) work on their own. The WHOIS-driven signals (expired, `pendingDelete`, recently registered) only fire when the host's `domain_expiry` checker subscribes to this checker's external-target discovery entries and publishes a per-target `whois` observation. Without that wiring, the checker still works as a DNS-only dangling detector.
+{{% /notice %}}
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Skip live DNS resolution | When set, the checker only reports the static structure of pointer records (offline analysis), without resolving targets. | `false` |
+
+## In happyDomain
+
+Enable this checker on the domain from the {{< relref "/pages/checks" >}} view; the domain name and zone content are filled in automatically. Because it is zone-scoped, it runs over the whole zone in a single pass.
+
+Related checkers: {{< relref "/reference/checkers/alias" >}} validates the structure of individual alias chains, and {{< relref "/reference/checkers/domain-expiry" >}} watches your own domains' expiry — the same WHOIS machinery that powers this checker's external-target signals.

content/reference/checkers/dangling.fr.md

@@ -0,0 +1,42 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Enregistrements orphelins
+description: "Analyse une zone à la recherche d'enregistrements CNAME/MX/SRV/NS dont la cible renvoie NXDOMAIN ou dont le domaine externe a expiré et pourrait être ré-enregistré."
+weight: 140
+---
+
+Le vérificateur **Sous-domaines orphelins** analyse une zone à la recherche d'enregistrements pointeurs (`CNAME`, `MX`, `SRV`, `NS`) dont les cibles sont devenues obsolètes : elles renvoient NXDOMAIN, ou leur domaine enregistrable externe a expiré, est en `pendingDelete`, ou a été ré-enregistré récemment. C'est la classe d'attaques par prise de contrôle de sous-domaine popularisée en 2017, où des institutions ont fini par servir du contenu hostile depuis des CNAME pointant vers des services tiers désaffectés, après que des attaquants eurent ré-enregistré les cibles libérées.
+
+Il s'agit d'un vérificateur de **niveau zone** : il nécessite le contenu complet de la zone et la parcourt en une seule passe, consolidant les constats par propriétaire plutôt que de produire un résultat par enregistrement.
+
+## Ce qui est vérifié
+
+Le vérificateur parcourt chaque service de la zone de travail et extrait les enregistrements pointeurs des corps `CNAME`, CNAME spécial, `MX`, `SRV` inconnu et orphelin (enregistrements `NS`/`CNAME`/`MX` nus). Pour chaque triplet `(propriétaire, type, cible)`, il classe la cible comme interne ou externe à la zone (par rapport au domaine enregistrable de la zone), effectue une résolution DNS unique et bornée dans le temps pour détecter une rupture immédiate, et publie une entrée de découverte afin qu'un vérificateur `domain_expiry` compagnon puisse lancer une requête RDAP/WHOIS sur les cibles externes.
+
+Il émet un constat par propriétaire concerné, classé par sévérité décroissante :
+
+| Signal | Sévérité | Source |
+|--------|----------|--------|
+| Cible NXDOMAIN | Critique | Résolution DNS locale |
+| Cible SERVFAIL | Avertissement | Résolution DNS locale |
+| Cible NOERROR avec réponse vide | Info | Résolution DNS locale |
+| Domaine enregistrable expiré | Critique | Observation `whois` apparentée |
+| Statut enregistrable `pendingDelete` / `redemptionPeriod` | Critique | Observation `whois` apparentée |
+| Domaine enregistrable créé au cours des 90 derniers jours | Avertissement | Observation `whois` apparentée |
+
+{{% notice style="info" title="Les signaux WHOIS nécessitent un vérificateur compagnon" %}}
+Les signaux issus de la résolution DNS (NXDOMAIN, SERVFAIL, réponse vide) fonctionnent seuls. Les signaux issus du WHOIS (expiré, `pendingDelete`, créé récemment) ne se déclenchent que lorsque le vérificateur `domain_expiry` de l'hôte s'abonne aux entrées de découverte de cibles externes de ce vérificateur et publie une observation `whois` par cible. Sans ce câblage, le vérificateur fonctionne tout de même comme un détecteur d'orphelins basé uniquement sur le DNS.
+{{% /notice %}}
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Ignorer la résolution DNS en direct | Lorsqu'elle est activée, le vérificateur ne rapporte que la structure statique des enregistrements pointeurs (analyse hors ligne), sans résoudre les cibles. | `false` |
+
+## Dans happyDomain
+
+Activez ce vérificateur sur le domaine depuis la vue {{< relref "/pages/checks" >}} ; le nom de domaine et le contenu de la zone sont renseignés automatiquement. Étant de niveau zone, il s'exécute sur l'ensemble de la zone en une seule passe.
+
+Vérificateurs apparentés : {{< relref "/reference/checkers/alias" >}} valide la structure des chaînes d'alias individuelles, et {{< relref "/reference/checkers/domain-expiry" >}} surveille l'expiration de vos propres domaines, avec la même mécanique WHOIS qui alimente les signaux de cibles externes de ce vérificateur.

content/reference/checkers/dav.en.md

@@ -0,0 +1,48 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: CalDAV / CardDAV
+description: "Discovers and probes a domain's CalDAV and CardDAV servers: well-known/SRV discovery, HTTPS reachability, advertised DAV capabilities, and (with credentials) the authenticated principal, home-set, collections and REPORT flow."
+weight: 240
+---
+
+The **CalDAV** and **CardDAV** checkers verify that a domain's calendar (RFC 4791) and contacts (RFC 6352) servers are discoverable, reachable, and correctly advertise the WebDAV extensions that clients rely on. They are two distinct checkers sharing the same logic: `caldav` attaches to a *CalDAV* service (`abstract.CalDAV`), `carddav` to a *CardDAV* service (`abstract.CardDAV`). The only behavioural difference is the required DAV capability (`calendar-access` vs `addressbook`) and a CalDAV-only scheduling check.
+
+Both checkers are **service-level**: they target the corresponding service published on a subdomain and are configured from that service's own **Checks** tab. Discovery follows RFC 6764: the checker resolves a context URL from `/.well-known/{caldav,carddav}` and from `_caldavs._tcp` / `_carddavs._tcp` SRV records (with an optional `path=` TXT hint), then probes that endpoint.
+
+When no credentials are supplied, only the anonymous phase runs (discovery, transport, OPTIONS). Supplying a username and password unlocks the authenticated phase: principal discovery, home-set, collection enumeration and the REPORT probe.
+
+{{% notice style="info" title="TLS posture is out of scope" %}}
+These checkers confirm only that an HTTPS session can be established to the context URL. Certificate validation (chain, hostname, expiry, ciphers) is deliberately left to the dedicated TLS checker. See {{< relref "/reference/checkers/tls" >}}.
+{{% /notice %}}
+
+## What it checks
+
+| Rule | What it verifies | Conditions |
+|---|---|---|
+| `dav_discovery` | A context URL resolves via `/.well-known` or SRV. | **Critical** if no context URL can be resolved. **Warning** when `/.well-known` returns `200` instead of a `301`/`302` redirect (legal but many clients won't follow it). **Info** when the URL was resolved via SRV but `/.well-known` is broken. |
+| `dav_transport` | The HTTPS connection to the context URL is reachable. | **Critical** if the connection fails. |
+| `dav_options` | An HTTP `OPTIONS` request advertises the required DAV capability (`calendar-access` for CalDAV, `addressbook` for CardDAV) and the `PROPFIND`/`REPORT` methods. | **Critical** if OPTIONS fails or the capability is missing. **Warning** if the `Allow` header lacks `PROPFIND` or `REPORT`. |
+| `dav_principal` | The current-user principal URL is discovered via authenticated `PROPFIND`. | **Critical** on failure. **Unknown** when no credentials are supplied (phase skipped). |
+| `dav_home_set` | The calendar/addressbook home-set is discovered from the principal. | **Critical** on failure. **Unknown** when skipped. |
+| `dav_collections` | Calendar/addressbook collections enumerate and expose their properties (supported component set, supported address data, display name…). | **Critical** on failure. **Warning** if the home-set is empty. **Unknown** when skipped. |
+| `dav_report` | The server accepts a minimal `calendar-query` / `addressbook-query` `REPORT` against the first collection. | **Critical** on failure. **Warning** if the query returns an unexpected response. **Unknown** when skipped. |
+| `caldav_scheduling` | *(CalDAV only)* When `calendar-schedule` is advertised, the principal exposes `schedule-inbox-URL` and `schedule-outbox-URL`. | **Warning** if advertised but the URLs are missing or the probe fails. **Info** when scheduling is not advertised. **Unknown** when skipped. |
+
+The HTML report surfaces the most common misconfigurations as callouts: `/.well-known` returning `200`, no SRV and no well-known (service unreachable), a plaintext SRV record without a secure counterpart, a server not advertising the required DAV class, and the authenticated phase being skipped for lack of credentials.
+
+## Options
+
+Both checkers accept the same options.
+
+| Option | Meaning | Default |
+|---|---|---|
+| Username | Optional. Supplying credentials unlocks the authenticated checks (principal, home-set, collections, REPORT probe). | *(empty)* |
+| Password or token | Optional. Paired with the username for HTTP Basic authentication. | *(empty)* |
+| Explicit context URL | Optional. Bypasses `/.well-known` and SRV discovery; use for servers with a non-standard layout. | *(empty)* |
+| Domain name | The domain to probe (auto-filled from the service scope). | *(auto)* |
+| Timeout (seconds) | Per-request HTTP timeout. | `10` |
+
+## In happyDomain
+
+Enable the CalDAV or CardDAV checker from the **Checks** tab of a CalDAV or CardDAV service. The domain name is filled in automatically; add credentials only if you want the authenticated collection and REPORT checks to run. See {{< relref "/pages/checks" >}} for the full workflow, and {{< relref "/reference/checkers/tls" >}} for the certificate posture of the same endpoints.

content/reference/checkers/dav.fr.md

@@ -0,0 +1,48 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: CalDAV / CardDAV
+description: "Découvre et sonde les serveurs CalDAV et CardDAV d'un domaine : découverte via well-known/SRV, accessibilité HTTPS, capacités DAV annoncées et (avec des identifiants) le parcours authentifié principal, home-set, collections et REPORT."
+weight: 240
+---
+
+Les vérificateurs **CalDAV** et **CardDAV** vérifient que les serveurs de calendrier (RFC 4791) et de contacts (RFC 6352) d'un domaine sont découvrables, accessibles, et annoncent correctement les extensions WebDAV sur lesquelles s'appuient les clients. Il s'agit de deux vérificateurs distincts partageant la même logique : `caldav` s'attache à un service *CalDAV* (`abstract.CalDAV`), `carddav` à un service *CardDAV* (`abstract.CardDAV`). La seule différence de comportement porte sur la capacité DAV requise (`calendar-access` contre `addressbook`) et sur une vérification de planification propre à CalDAV.
+
+Les deux vérificateurs sont de **niveau service** : ils ciblent le service correspondant publié sur un sous-domaine et se configurent depuis l'onglet **Vérifications** de ce service. La découverte suit la RFC 6764 : le vérificateur résout une URL de contexte à partir de `/.well-known/{caldav,carddav}` et des enregistrements SRV `_caldavs._tcp` / `_carddavs._tcp` (avec un indice TXT `path=` facultatif), puis sonde ce point d'accès.
+
+Lorsqu'aucun identifiant n'est fourni, seule la phase anonyme s'exécute (découverte, transport, OPTIONS). Fournir un nom d'utilisateur et un mot de passe déverrouille la phase authentifiée : découverte du principal, home-set, énumération des collections et sonde REPORT.
+
+{{% notice style="info" title="La posture TLS est hors périmètre" %}}
+Ces vérificateurs confirment uniquement qu'une session HTTPS peut être établie vers l'URL de contexte. La validation du certificat (chaîne, nom d'hôte, expiration, algorithmes) est volontairement laissée au vérificateur TLS dédié. Consultez {{< relref "/reference/checkers/tls" >}}.
+{{% /notice %}}
+
+## Ce qui est vérifié
+
+| Règle | Ce qui est vérifié | Conditions |
+|---|---|---|
+| `dav_discovery` | Une URL de contexte se résout via `/.well-known` ou SRV. | **Critique** si aucune URL de contexte ne peut être résolue. **Avertissement** quand `/.well-known` renvoie `200` au lieu d'une redirection `301`/`302` (légal mais beaucoup de clients ne la suivent pas). **Info** quand l'URL a été résolue via SRV mais que `/.well-known` est cassé. |
+| `dav_transport` | La connexion HTTPS vers l'URL de contexte est accessible. | **Critique** si la connexion échoue. |
+| `dav_options` | Une requête HTTP `OPTIONS` annonce la capacité DAV requise (`calendar-access` pour CalDAV, `addressbook` pour CardDAV) et les méthodes `PROPFIND`/`REPORT`. | **Critique** si OPTIONS échoue ou si la capacité manque. **Avertissement** si l'en-tête `Allow` ne contient pas `PROPFIND` ou `REPORT`. |
+| `dav_principal` | L'URL du principal de l'utilisateur courant est découverte via un `PROPFIND` authentifié. | **Critique** en cas d'échec. **Inconnu** si aucun identifiant n'est fourni (phase ignorée). |
+| `dav_home_set` | Le home-set calendrier/carnet d'adresses est découvert depuis le principal. | **Critique** en cas d'échec. **Inconnu** si ignoré. |
+| `dav_collections` | Les collections calendrier/carnet d'adresses s'énumèrent et exposent leurs propriétés (jeu de composants pris en charge, données d'adresse prises en charge, nom affiché...). | **Critique** en cas d'échec. **Avertissement** si le home-set est vide. **Inconnu** si ignoré. |
+| `dav_report` | Le serveur accepte une requête `REPORT` minimale (`calendar-query` / `addressbook-query`) sur la première collection. | **Critique** en cas d'échec. **Avertissement** si la requête renvoie une réponse inattendue. **Inconnu** si ignoré. |
+| `caldav_scheduling` | *(CalDAV uniquement)* Lorsque `calendar-schedule` est annoncé, le principal expose `schedule-inbox-URL` et `schedule-outbox-URL`. | **Avertissement** si annoncé mais que les URL manquent ou que la sonde échoue. **Info** quand la planification n'est pas annoncée. **Inconnu** si ignoré. |
+
+Le rapport HTML met en avant les erreurs de configuration les plus courantes sous forme d'encarts : `/.well-known` renvoyant `200`, absence de SRV et de well-known (service inaccessible), un enregistrement SRV en clair sans équivalent sécurisé, un serveur n'annonçant pas la classe DAV requise, et la phase authentifiée ignorée faute d'identifiants.
+
+## Options
+
+Les deux vérificateurs acceptent les mêmes options.
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Nom d'utilisateur | Facultatif. Fournir des identifiants déverrouille les vérifications authentifiées (principal, home-set, collections, sonde REPORT). | *(vide)* |
+| Mot de passe ou jeton | Facultatif. Associé au nom d'utilisateur pour l'authentification HTTP Basic. | *(vide)* |
+| URL de contexte explicite | Facultatif. Contourne la découverte `/.well-known` et SRV ; à utiliser pour les serveurs à la disposition non standard. | *(vide)* |
+| Nom de domaine | Le domaine à sonder (renseigné automatiquement depuis la portée du service). | *(auto)* |
+| Délai d'attente (secondes) | Délai d'attente HTTP par requête. | `10` |
+
+## Dans happyDomain
+
+Activez le vérificateur CalDAV ou CardDAV depuis l'onglet **Vérifications** d'un service CalDAV ou CardDAV. Le nom de domaine est renseigné automatiquement ; ajoutez des identifiants uniquement si vous souhaitez exécuter les vérifications authentifiées des collections et de REPORT. Consultez {{< relref "/pages/checks" >}} pour le fonctionnement complet, et {{< relref "/reference/checkers/tls" >}} pour la posture des certificats de ces mêmes points d'accès.

content/reference/checkers/delegation.en.md

@@ -0,0 +1,69 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Delegation
+description: "Audits a zone's delegation: NS consistency between parent and child, glue correctness, DS/DNSKEY hand-off, reachability and authoritativeness of each delegated server."
+weight: 70
+---
+
+The **Delegation** checker audits how a zone is delegated from its parent. It cross-examines the parent zone and the child name servers to confirm that the hand-off is coherent: that the parent and child agree on the `NS` set, that glue records are correct, that the DNSSEC `DS`/`DNSKEY` chain lines up, and that every delegated server is reachable and actually authoritative for the zone.
+
+This checker is **service-level**: it targets a *Delegation* service (`abstract.Delegation`) published on a subdomain, and is configured from that service's own **Checks** tab.
+
+## What it checks
+
+Each rule emits a stable finding `code` so results can be matched deterministically.
+
+### Name-server count and parent discovery
+
+| Finding code | What it verifies |
+|---|---|
+| `delegation_too_few_ns` | The zone declares at least `minNameServers` `NS` records (RFC 1034 recommends ≥ 2). |
+| `delegation_no_parent_ns` | The parent zone and its authoritative name servers can be discovered. |
+| `delegation_parent_query_failed` | Each parent name server answers the `NS` query for the delegated zone. |
+| `delegation_parent_tcp_failed` | Each parent name server is reachable over TCP (RFC 7766). |
+
+### NS and glue at the parent
+
+| Finding code | What it verifies |
+|---|---|
+| `delegation_ns_mismatch` | The `NS` RRset at the parent matches the `NS` set declared by the service. |
+| `delegation_missing_glue` | In-bailiwick name servers have glue (`A`/`AAAA`) at the parent. |
+| `delegation_unnecessary_glue` | Out-of-bailiwick name servers do not carry unnecessary glue. |
+
+### DNSSEC hand-off
+
+| Finding code | What it verifies |
+|---|---|
+| `delegation_ds_query_failed` | The `DS` RRset can be queried from the parent name servers. |
+| `delegation_ds_mismatch` | The `DS` RRset at the parent matches the `DS` set declared by the service. |
+| `delegation_ds_missing` | `DS` records are present at the parent when DNSSEC is expected (gated by `requireDS`). |
+| `delegation_ds_rrsig_invalid` | The `DS` RRset is covered by a valid `RRSIG` at the parent. |
+| `delegation_dnskey_query_failed` | The `DNSKEY` RRset can be queried from each child name server. |
+| `delegation_dnskey_no_match` | At least one child `DNSKEY` matches a `DS` digest published at the parent. |
+
+### Child reachability and authoritativeness
+
+| Finding code | What it verifies |
+|---|---|
+| `delegation_ns_unresolvable` | Each declared name server name resolves to at least one address. |
+| `delegation_unreachable` | Each child name server answers DNS queries on its advertised addresses. |
+| `delegation_lame` | Each child name server is authoritative for the zone (no lame delegation). |
+| `delegation_no_authoritative_answer` | Each child name server sets the AA flag in its answers for the zone. |
+| `delegation_tcp_failed` | Each child name server answers over TCP (gated by `requireTCP`). |
+| `delegation_soa_serial_drift` | The `SOA` serial is consistent across all child name servers. |
+| `delegation_ns_drift` | The `NS` RRset returned by each child matches the `NS` RRset at the parent. |
+| `delegation_glue_mismatch` | Glue addresses at the child match those at the parent (gated by `allowGlueMismatch`). |
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| `requireDS` | When enabled, missing `DS` records at the parent are treated as critical (otherwise informational). | `false` |
+| `requireTCP` | When enabled, name servers that fail to answer over TCP are reported as critical (otherwise warning). | `true` |
+| `minNameServers` | Below this count, the delegation is reported as a warning (RFC 1034 recommends at least 2). | `2` |
+| `allowGlueMismatch` | When disabled, glue/address mismatches between parent and child are reported as critical. | `false` |
+
+## In happyDomain
+
+Enable the Delegation checker from the **Checks** tab of a Delegation service. See {{< relref "/pages/checks" >}} for the full workflow. For consistency *between* the authoritative servers of the apex itself (rather than the parent/child hand-off), see {{< relref "/reference/checkers/authoritative-consistency" >}}; for the DNSSEC hygiene of the signed zone, see {{< relref "/reference/checkers/dnssec" >}}.

content/reference/checkers/delegation.fr.md

@@ -0,0 +1,69 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Délégation
+description: "Audite la délégation d'une zone : cohérence des NS entre parent et enfant, exactitude des glue, passage de relais DS/DNSKEY, joignabilité et autorité de chaque serveur délégué."
+weight: 70
+---
+
+Le vérificateur **Délégation** audite la façon dont une zone est déléguée depuis son parent. Il confronte la zone parente et les serveurs de noms enfants pour confirmer la cohérence du passage de relais : le parent et l'enfant s'accordent sur l'ensemble des `NS`, les enregistrements de glue sont corrects, la chaîne DNSSEC `DS`/`DNSKEY` est alignée, et chaque serveur délégué est joignable et réellement faisant autorité pour la zone.
+
+Ce vérificateur s'applique au niveau du **service** : il cible un service de délégation (`abstract.Delegation`) publié sur un sous-domaine, et se configure depuis l'onglet **Vérifications** de ce service.
+
+## Ce qu'il vérifie
+
+Chaque règle émet un `code` de constat stable, afin que les résultats puissent être appariés de façon déterministe.
+
+### Nombre de serveurs de noms et découverte du parent
+
+| Code de constat | Ce qui est vérifié |
+|---|---|
+| `delegation_too_few_ns` | La zone déclare au moins `minNameServers` enregistrements `NS` (la RFC 1034 recommande ≥ 2). |
+| `delegation_no_parent_ns` | La zone parente et ses serveurs faisant autorité peuvent être découverts. |
+| `delegation_parent_query_failed` | Chaque serveur de noms parent répond à la requête `NS` pour la zone déléguée. |
+| `delegation_parent_tcp_failed` | Chaque serveur de noms parent est joignable en TCP (RFC 7766). |
+
+### NS et glue au parent
+
+| Code de constat | Ce qui est vérifié |
+|---|---|
+| `delegation_ns_mismatch` | Le RRset `NS` au parent correspond à l'ensemble `NS` déclaré par le service. |
+| `delegation_missing_glue` | Les serveurs de noms dans le bailliage disposent de glue (`A`/`AAAA`) au parent. |
+| `delegation_unnecessary_glue` | Les serveurs de noms hors bailliage ne portent pas de glue superflue. |
+
+### Passage de relais DNSSEC
+
+| Code de constat | Ce qui est vérifié |
+|---|---|
+| `delegation_ds_query_failed` | Le RRset `DS` peut être interrogé auprès des serveurs de noms parents. |
+| `delegation_ds_mismatch` | Le RRset `DS` au parent correspond à l'ensemble `DS` déclaré par le service. |
+| `delegation_ds_missing` | Des enregistrements `DS` sont présents au parent lorsque DNSSEC est attendu (conditionné par `requireDS`). |
+| `delegation_ds_rrsig_invalid` | Le RRset `DS` est couvert par un `RRSIG` valide au parent. |
+| `delegation_dnskey_query_failed` | Le RRset `DNSKEY` peut être interrogé auprès de chaque serveur de noms enfant. |
+| `delegation_dnskey_no_match` | Au moins un `DNSKEY` enfant correspond à un condensat `DS` publié au parent. |
+
+### Joignabilité et autorité des serveurs enfants
+
+| Code de constat | Ce qui est vérifié |
+|---|---|
+| `delegation_ns_unresolvable` | Chaque nom de serveur déclaré se résout en au moins une adresse. |
+| `delegation_unreachable` | Chaque serveur de noms enfant répond aux requêtes DNS sur ses adresses annoncées. |
+| `delegation_lame` | Chaque serveur de noms enfant fait autorité pour la zone (pas de délégation boiteuse). |
+| `delegation_no_authoritative_answer` | Chaque serveur de noms enfant positionne le drapeau AA dans ses réponses pour la zone. |
+| `delegation_tcp_failed` | Chaque serveur de noms enfant répond en TCP (conditionné par `requireTCP`). |
+| `delegation_soa_serial_drift` | Le numéro de série `SOA` est cohérent entre tous les serveurs de noms enfants. |
+| `delegation_ns_drift` | Le RRset `NS` renvoyé par chaque enfant correspond au RRset `NS` au parent. |
+| `delegation_glue_mismatch` | Les adresses de glue chez l'enfant correspondent à celles du parent (conditionné par `allowGlueMismatch`). |
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| `requireDS` | Si activé, l'absence de `DS` au parent est traitée comme critique (sinon informative). | `false` |
+| `requireTCP` | Si activé, les serveurs de noms qui ne répondent pas en TCP sont signalés comme critiques (sinon en avertissement). | `true` |
+| `minNameServers` | En dessous de ce nombre, la délégation est signalée en avertissement (la RFC 1034 recommande au moins 2). | `2` |
+| `allowGlueMismatch` | Si désactivé, les divergences de glue/adresses entre parent et enfant sont signalées comme critiques. | `false` |
+
+## Dans happyDomain
+
+Activez le vérificateur Délégation depuis l'onglet **Vérifications** d'un service de délégation. Consultez {{< relref "/pages/checks" >}} pour le déroulé complet. Pour la cohérence *entre* les serveurs faisant autorité de l'apex lui-même (plutôt que le passage de relais parent/enfant), voyez {{< relref "/reference/checkers/authoritative-consistency" >}} ; pour l'hygiène DNSSEC de la zone signée, voyez {{< relref "/reference/checkers/dnssec" >}}.

content/reference/checkers/dnssec.en.md

@@ -0,0 +1,80 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: DNSSEC validation
+description: "Audits the operational hygiene of a signed zone: algorithms, key sizes, signature freshness, NSEC/NSEC3 parameters and per-name-server consistency."
+weight: 60
+---
+
+The **DNSSEC** checker audits the *operational hygiene* of a signed zone. It does not re-validate the cryptographic chain of trust end to end (that work is delegated to a dedicated DNSViz-based checker); instead it focuses on the policy and day-to-day operational aspects of signing: which algorithms and key sizes are in use, whether signatures are fresh and valid, how negative answers are denied (NSEC vs NSEC3), and whether every authoritative server serves a consistent view.
+
+This checker is **domain-level**: it operates on the zone apex. From a bootstrap recursive resolver it discovers the apex name servers and looks up the parent `DS`, then queries each authoritative server directly.
+
+## What it checks
+
+The checker evaluates the following rules. Several of them are governed by the options described further down.
+
+### Chain and key material
+
+| Rule | Verifies | Severity |
+|---|---|---|
+| `dnssec_zone_signed` | The parent advertises a `DS` but the apex serves no `DNSKEY` (a broken signed zone). | Critical |
+| `dnssec_dnskey_consistent` | Every authoritative server returns the same `DNSKEY` RRset. | Critical |
+| `dnssec_dnskey_query_ok` | Every authoritative server answered the `DNSKEY` query. | Critical |
+| `dnssec_ksk_present` | At least one `DNSKEY` carries the SEP bit (a Key Signing Key). | Critical |
+| `dnssec_dnskey_count` | Warns when too many `DNSKEY`s are published, inflating responses and amplification potential. | Warning |
+
+### Algorithms and key strength
+
+| Rule | Verifies | Severity |
+|---|---|---|
+| `dnssec_algorithm_allowed` | No `DNSKEY` uses a forbidden algorithm or one outside the allowed list. | Critical |
+| `dnssec_algorithm_modern` | Recommends ECDSAP256SHA256 (13) or Ed25519 (15) over RSA. | Warning |
+| `dnssec_rsa_keysize` | RSA `DNSKEY`s reach the minimum modulus size. | Critical |
+
+### Signatures
+
+| Rule | Verifies | Severity |
+|---|---|---|
+| `dnssec_rrsig_present_dnskey` | The `DNSKEY` RRset is signed. | Critical |
+| `dnssec_rrsig_present_soa` | The `SOA` RRset is signed. | Critical |
+| `dnssec_rrsig_validity_window` | Every observed `RRSIG` is currently within its inception/expiration window. | Critical |
+| `dnssec_rrsig_freshness` | Pre-emptive alert when `RRSIG`s are close to expiring (catches stuck signers). | Critical |
+
+### Denial of existence (NSEC / NSEC3)
+
+| Rule | Verifies | Severity |
+|---|---|---|
+| `dnssec_denial_uses_nsec3` | Warns when the zone uses bare NSEC, which makes the zone walkable (RFC 5155 / RFC 7129). | Warning |
+| `dnssec_nsec3_iterations` | `NSEC3PARAM.Iterations` is at most the configured ceiling (RFC 9276 §3.1 recommends 0). | Critical |
+| `dnssec_nsec3_salt_empty` | `NSEC3PARAM.SaltLength` is 0 (RFC 9276 §3.1: a salt buys no measurable protection). | Warning |
+| `dnssec_nsec3_optout_only_when_signed_delegations` | Informational note when the OPT-OUT flag is set in a leaf zone. | Info |
+| `dnssec_denial_consistent` | Every authoritative server uses the same denial-of-existence scheme. | Warning |
+
+### TTL hygiene
+
+| Rule | Verifies | Severity |
+|---|---|---|
+| `dnssec_dnskey_ttl_min` | Warns when the `DNSKEY` TTL is too short to be useful for caching. | Warning |
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| `nsec3IterationsMax` | RFC 9276 §3.1 ceiling on `NSEC3PARAM.Iterations`. Raise only if your signer cannot publish 0 yet. | `0` |
+| `nsec3IterationsSeverity` | Severity when iterations exceed the ceiling. Set `crit` to enforce RFC 9276 strictly. | `warn` |
+| `signatureFreshness` | Warn when the closest `RRSIG` expires in fewer than this many days. | `7` |
+| `signatureFreshnessCrit` | Critical when the closest `RRSIG` expires in fewer than this many days. | `1` |
+| `minRSAKeySize` | Minimum acceptable RSA modulus size, in bits. | `2048` |
+| `requireSEP` | Require at least one `DNSKEY` with the SEP bit (KSK). | `true` |
+| `dnskeyTTLMin` | Minimum `DNSKEY` TTL, in seconds; shorter TTLs hurt cacheability. | `3600` |
+
+The administrator can also set a bootstrap `resolver` (`host:port`) used to discover the apex name servers and look up the parent `DS`; it defaults to `/etc/resolv.conf`.
+
+{{% notice style="info" title="What this checker does not do" %}}
+The DNSSEC checker does not verify the full cryptographic chain of trust from the root. For that end-to-end validation, use the DNSViz-based checker. This checker complements it by catching policy and operational problems (weak algorithms, expiring signatures, NSEC walkability) that a chain validation alone would not surface.
+{{% /notice %}}
+
+## In happyDomain
+
+Enable the DNSSEC checker on a domain from its **Checks** view. See {{< relref "/pages/checks" >}} for the full workflow of adding, scheduling and reading checks. For delegation-side `DS`/`DNSKEY` hand-off, see the {{< relref "/reference/checkers/delegation" >}} checker.

content/reference/checkers/dnssec.fr.md

@@ -0,0 +1,80 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Validation DNSSEC
+description: "Audite l'hygiène opérationnelle d'une zone signée : algorithmes, taille des clés, fraîcheur des signatures, paramètres NSEC/NSEC3 et cohérence entre serveurs."
+weight: 60
+---
+
+Le vérificateur **DNSSEC** audite l'*hygiène opérationnelle* d'une zone signée. Il ne revalide pas de bout en bout la chaîne de confiance cryptographique (cette tâche est confiée à un vérificateur dédié fondé sur DNSViz) : il se concentre sur les aspects de politique et d'exploitation au quotidien de la signature, à savoir les algorithmes et tailles de clés utilisés, la validité et la fraîcheur des signatures, le mode de déni d'existence (NSEC ou NSEC3) et la cohérence de la vue servie par chaque serveur faisant autorité.
+
+Ce vérificateur s'applique au niveau du **domaine** : il opère sur l'apex de la zone. À partir d'un résolveur récursif d'amorçage, il découvre les serveurs de noms de l'apex et interroge le `DS` parent, puis questionne directement chaque serveur faisant autorité.
+
+## Ce qu'il vérifie
+
+Le vérificateur évalue les règles suivantes. Plusieurs d'entre elles sont pilotées par les options décrites plus bas.
+
+### Chaîne et matériel de clés
+
+| Règle | Vérifie | Sévérité |
+|---|---|---|
+| `dnssec_zone_signed` | Le parent annonce un `DS` mais l'apex ne sert aucun `DNSKEY` (zone signée cassée). | Critique |
+| `dnssec_dnskey_consistent` | Tous les serveurs faisant autorité renvoient le même RRset `DNSKEY`. | Critique |
+| `dnssec_dnskey_query_ok` | Tous les serveurs faisant autorité ont répondu à la requête `DNSKEY`. | Critique |
+| `dnssec_ksk_present` | Au moins un `DNSKEY` porte le bit SEP (clé de signature de clé, KSK). | Critique |
+| `dnssec_dnskey_count` | Avertit lorsque trop de `DNSKEY` sont publiés, ce qui gonfle les réponses et le potentiel d'amplification. | Avertissement |
+
+### Algorithmes et robustesse des clés
+
+| Règle | Vérifie | Sévérité |
+|---|---|---|
+| `dnssec_algorithm_allowed` | Aucun `DNSKEY` n'utilise un algorithme interdit ou hors de la liste autorisée. | Critique |
+| `dnssec_algorithm_modern` | Recommande ECDSAP256SHA256 (13) ou Ed25519 (15) plutôt que RSA. | Avertissement |
+| `dnssec_rsa_keysize` | Les `DNSKEY` RSA atteignent la taille de module minimale. | Critique |
+
+### Signatures
+
+| Règle | Vérifie | Sévérité |
+|---|---|---|
+| `dnssec_rrsig_present_dnskey` | Le RRset `DNSKEY` est signé. | Critique |
+| `dnssec_rrsig_present_soa` | Le RRset `SOA` est signé. | Critique |
+| `dnssec_rrsig_validity_window` | Chaque `RRSIG` observé est dans sa fenêtre d'inception/expiration. | Critique |
+| `dnssec_rrsig_freshness` | Alerte anticipée lorsque les `RRSIG` approchent de l'expiration (détecte les signeurs bloqués). | Critique |
+
+### Déni d'existence (NSEC / NSEC3)
+
+| Règle | Vérifie | Sévérité |
+|---|---|---|
+| `dnssec_denial_uses_nsec3` | Avertit lorsque la zone utilise NSEC nu, ce qui la rend parcourable (RFC 5155 / RFC 7129). | Avertissement |
+| `dnssec_nsec3_iterations` | `NSEC3PARAM.Iterations` ne dépasse pas le plafond configuré (la RFC 9276 §3.1 recommande 0). | Critique |
+| `dnssec_nsec3_salt_empty` | `NSEC3PARAM.SaltLength` vaut 0 (RFC 9276 §3.1 : un sel n'apporte aucune protection mesurable). | Avertissement |
+| `dnssec_nsec3_optout_only_when_signed_delegations` | Note informative lorsque le drapeau OPT-OUT est positionné dans une zone feuille. | Info |
+| `dnssec_denial_consistent` | Tous les serveurs faisant autorité utilisent le même schéma de déni d'existence. | Avertissement |
+
+### Hygiène des TTL
+
+| Règle | Vérifie | Sévérité |
+|---|---|---|
+| `dnssec_dnskey_ttl_min` | Avertit lorsque le TTL des `DNSKEY` est trop court pour être utile au cache. | Avertissement |
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| `nsec3IterationsMax` | Plafond RFC 9276 §3.1 sur `NSEC3PARAM.Iterations`. À relever uniquement si votre signeur ne sait pas encore publier 0. | `0` |
+| `nsec3IterationsSeverity` | Sévérité lorsque les itérations dépassent le plafond. Mettre `crit` pour appliquer strictement la RFC 9276. | `warn` |
+| `signatureFreshness` | Avertit lorsque le `RRSIG` le plus proche expire dans moins de ce nombre de jours. | `7` |
+| `signatureFreshnessCrit` | Critique lorsque le `RRSIG` le plus proche expire dans moins de ce nombre de jours. | `1` |
+| `minRSAKeySize` | Taille de module RSA minimale acceptable, en bits. | `2048` |
+| `requireSEP` | Exige au moins un `DNSKEY` portant le bit SEP (KSK). | `true` |
+| `dnskeyTTLMin` | TTL minimal des `DNSKEY`, en secondes ; des TTL plus courts nuisent à la mise en cache. | `3600` |
+
+L'administrateur peut également définir un résolveur d'amorçage (`resolver`, au format `host:port`) servant à découvrir les serveurs de noms de l'apex et à interroger le `DS` parent ; sa valeur par défaut est `/etc/resolv.conf`.
+
+{{% notice style="info" title="Ce que ce vérificateur ne fait pas" %}}
+Le vérificateur DNSSEC ne vérifie pas l'intégralité de la chaîne de confiance cryptographique depuis la racine. Pour cette validation de bout en bout, utilisez le vérificateur fondé sur DNSViz. Le présent vérificateur le complète en détectant les problèmes de politique et d'exploitation (algorithmes faibles, signatures expirantes, NSEC parcourable) qu'une validation de chaîne seule ne révélerait pas.
+{{% /notice %}}
+
+## Dans happyDomain
+
+Activez le vérificateur DNSSEC sur un domaine depuis sa vue **Vérifications**. Consultez {{< relref "/pages/checks" >}} pour le déroulé complet de l'ajout, de la planification et de la lecture des vérifications. Pour le passage de relais `DS`/`DNSKEY` côté délégation, voyez le vérificateur {{< relref "/reference/checkers/delegation" >}}.

content/reference/checkers/dnsviz.en.md

@@ -0,0 +1,54 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: DNSViz
+description: "Run DNSViz against a domain and walk the whole DNSSEC chain from the root down to the leaf, surfacing every error and warning at the exact zone where it occurs."
+weight: 340
+---
+
+The **DNSViz** checker (named *DNSSEC (DNSViz)* in happyDomain) assesses a domain's DNSSEC validation chain by driving [DNSViz](https://github.com/dnsviz/dnsviz). It analyses the queried name **and every ancestor up to the root**, so a recursive DNSSEC failure can be located at the exact level, and the exact record, where it broke.
+
+This checker is **domain-level**: it concerns the domain and its delegation chain rather than a single service.
+
+## How it works
+
+DNSViz is run externally (a Python tool packaged alongside the checker), and happyDomain delegates collection to that endpoint. For each run it effectively performs:
+
+```
+dnsviz probe -A . <ancestors…> <domain> | dnsviz grok -t <root-trust-anchor>
+```
+
+Every link of the chain (root → TLD → intermediates → leaf) is listed explicitly so the full analysis appears in the report. `dnsviz grok` is given a BIND-format DNSKEY trust anchor for the root zone; without it, the root has no parent to chain against and stays classified at the DNS level (`NOERROR`) instead of DNSSEC `SECURE`.
+
+The output is parsed: per-zone errors and warnings are walked out of the nested record tree and turned into individual states tagged with the JSON path where they were found. A curated catalog of common DNSSEC failures (broken chain, expired RRSIG, DS digest mismatch, deprecated algorithm…) is matched against the findings to drive a "Fix these first" section in the HTML report.
+
+{{% notice style="info" title="Scope" %}}
+This checker reports exactly what DNSViz reports. NSEC/NSEC3 zone-walk hardening and NSEC3PARAM iteration policy (RFC 9276) are out of scope here and handled by the dedicated DNSSEC checker — see {{< relref "/reference/checkers/dnssec" >}}.
+{{% /notice %}}
+
+## What it checks
+
+| Rule | What it verifies |
+|---|---|
+| `dnsviz_overall_status` | DNSViz status of the queried domain (SECURE / INSECURE / BOGUS / INDETERMINATE). |
+| `dnsviz_per_zone_status` | One state per zone in the chain (root, TLD, intermediates, leaf). |
+| `dnsviz_zone_errors` | Every error reported by DNSViz, scoped to the zone where it was found. |
+| `dnsviz_zone_warnings` | Every warning reported by DNSViz, scoped to the zone where it was found. |
+| `dnsviz_common_failures` | Pattern-matches the findings against a catalog of common DNSSEC failures. |
+
+Statuses map as follows: `SECURE` → OK; `BOGUS` → Critical; `INDETERMINATE` → Warning; `INSECURE`, `NON_EXISTENT` and a plain `NOERROR` (resolves but unsigned) → Info.
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| Probe timeout (`probeTimeoutSeconds`, admin) | Hard timeout for the `dnsviz probe` invocation; the recursive walk can be slow on some zones. | 120 |
+| Domain name (`domain_name`) | Domain to analyse. | auto-filled |
+
+The DNSViz runtime itself requires `dnsviz` on the host's `PATH` and a BIND-format root DNSKEY trust anchor file (auto-detected from the system's `dnssec-root` / `dns-root-data` package, or pointed at explicitly). The packaged container image bundles these so the trust anchor is in place out of the box.
+
+## In happyDomain
+
+Enable this checker for the domain from the **Checks** view. See {{< relref "/pages/checks" >}} for scheduling and reading checks.
+
+DNSViz and {{< relref "/reference/checkers/dnssec" >}} are complementary: DNSViz validates the end-to-end chain, while the DNSSEC checker covers NSEC/NSEC3 hardening. A second opinion on the same chain is available from {{< relref "/reference/checkers/zonemaster" >}}.

content/reference/checkers/dnsviz.fr.md

@@ -0,0 +1,54 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: DNSViz
+description: "Lance DNSViz sur un domaine et parcourt toute la chaîne DNSSEC, de la racine jusqu'à la feuille, en faisant remonter chaque erreur et avertissement à la zone exacte où il survient."
+weight: 340
+---
+
+Le vérificateur **DNSViz** (nommé *DNSSEC (DNSViz)* dans happyDomain) évalue la chaîne de validation DNSSEC d'un domaine en pilotant [DNSViz](https://github.com/dnsviz/dnsviz). Il analyse le nom interrogé **et chacun de ses ancêtres jusqu'à la racine**, de sorte qu'un échec DNSSEC récursif peut être localisé au niveau exact, et à l'enregistrement exact, où il s'est produit.
+
+Ce vérificateur s'applique au **niveau domaine** : il concerne le domaine et sa chaîne de délégation plutôt qu'un service isolé.
+
+## Fonctionnement
+
+DNSViz est exécuté en externe (un outil Python empaqueté avec le vérificateur), et happyDomain délègue la collecte à ce point d'accès. Chaque exécution revient à effectuer :
+
+```
+dnsviz probe -A . <ancêtres…> <domaine> | dnsviz grok -t <ancre-de-confiance-racine>
+```
+
+Chaque maillon de la chaîne (racine, TLD, intermédiaires, feuille) est listé explicitement afin que l'analyse complète apparaisse dans le rapport. `dnsviz grok` reçoit une ancre de confiance DNSKEY au format BIND pour la zone racine ; sans elle, la racine n'a pas de parent auquel se rattacher et reste classée au niveau DNS (`NOERROR`) au lieu de `SECURE` au sens DNSSEC.
+
+La sortie est analysée : les erreurs et avertissements par zone sont extraits de l'arbre d'enregistrements imbriqués et transformés en états individuels, étiquetés du chemin JSON où ils ont été trouvés. Un catalogue d'échecs DNSSEC courants (chaîne rompue, RRSIG expirée, condensat DS incohérent, algorithme déprécié) est confronté aux constats pour alimenter une section « Fix these first » du rapport HTML.
+
+{{% notice style="info" title="Périmètre" %}}
+Ce vérificateur rapporte exactement ce que DNSViz rapporte. Le durcissement contre le parcours de zone NSEC/NSEC3 et la politique d'itérations NSEC3PARAM (RFC 9276) sont hors périmètre ici et traités par le vérificateur DNSSEC dédié : voir {{< relref "/reference/checkers/dnssec" >}}.
+{{% /notice %}}
+
+## Ce qui est vérifié
+
+| Règle | Ce qui est vérifié |
+|---|---|
+| `dnsviz_overall_status` | Statut DNSViz du domaine interrogé (SECURE / INSECURE / BOGUS / INDETERMINATE). |
+| `dnsviz_per_zone_status` | Un état par zone de la chaîne (racine, TLD, intermédiaires, feuille). |
+| `dnsviz_zone_errors` | Chaque erreur rapportée par DNSViz, rattachée à la zone où elle a été trouvée. |
+| `dnsviz_zone_warnings` | Chaque avertissement rapporté par DNSViz, rattaché à la zone où il a été trouvé. |
+| `dnsviz_common_failures` | Confronte les constats à un catalogue d'échecs DNSSEC courants. |
+
+Les statuts sont projetés ainsi : `SECURE` vers OK ; `BOGUS` vers Critique ; `INDETERMINATE` vers Avertissement ; `INSECURE`, `NON_EXISTENT` et un simple `NOERROR` (résout mais non signé) vers Info.
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Délai de sondage (`probeTimeoutSeconds`, admin) | Délai maximal pour l'appel à `dnsviz probe` ; le parcours récursif peut être lent sur certaines zones. | 120 |
+| Nom de domaine (`domain_name`) | Domaine à analyser. | prérempli |
+
+L'environnement d'exécution de DNSViz nécessite quant à lui la présence de `dnsviz` dans le `PATH` de l'hôte et un fichier d'ancre de confiance DNSKEY racine au format BIND (détecté automatiquement à partir du paquet système `dnssec-root` / `dns-root-data`, ou indiqué explicitement). L'image conteneur fournie embarque ces éléments, de sorte que l'ancre de confiance est en place d'emblée.
+
+## Dans happyDomain
+
+Activez ce vérificateur pour le domaine depuis la vue **Vérifications**. Voir {{< relref "/pages/checks" >}} pour la planification et la lecture des vérifications.
+
+DNSViz et {{< relref "/reference/checkers/dnssec" >}} sont complémentaires : DNSViz valide la chaîne de bout en bout, tandis que le vérificateur DNSSEC couvre le durcissement NSEC/NSEC3. Un second avis sur la même chaîne est disponible auprès de {{< relref "/reference/checkers/zonemaster" >}}.

content/reference/checkers/domain-availability.en.md

@@ -0,0 +1,33 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Domain availability
+description: "Notifies you when a watched domain name becomes available for registration."
+weight: 40
+---
+
+The **Domain availability** checker watches a domain name you do *not* own and notifies you the moment it becomes available for registration. It is the counterpart of {{< relref "/reference/checkers/domain-expiry" >}}: instead of protecting a domain you hold, it lets you grab one as soon as it lapses.
+
+This is a **domain-level** checker: registration status is determined from the registry through a WHOIS/RDAP lookup. A domain is considered available when the registry reports that it does not exist.
+
+## What it checks
+
+A single rule, `domain_availability_check`, reports whether the watched domain is still registered or has become free.
+
+| Status | Condition |
+|--------|-----------|
+| **Critical** | The domain is now available for registration |
+| **OK** | The domain is still registered (the registrar and expiry date are reported when known) |
+| **Error** | The availability lookup failed |
+
+{{% notice style="info" title="Why available is reported as Critical" %}}
+The status is intentionally inverted compared with the usual convention. Reporting *Critical* when the domain becomes available makes the registered → available transition cross the notification threshold, so you are alerted exactly once when the domain frees up.
+{{% /notice %}}
+
+## Options
+
+This checker has no user-tunable options. The watched domain name is supplied automatically.
+
+## In happyDomain
+
+Unlike the other domain-level checkers, **Domain availability** is not scheduled on the domains you manage. It is driven by the dedicated availability-watch list. See {{< relref "/pages/domain-availability" >}} for how to add a domain to watch, and {{< relref "/pages/checks" >}} for the general checks workflow.

content/reference/checkers/domain-availability.fr.md

@@ -0,0 +1,33 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Disponibilité du domaine
+description: "Vous notifie lorsqu'un nom de domaine surveillé devient disponible à l'enregistrement."
+weight: 40
+---
+
+Le vérificateur **Disponibilité du domaine** surveille un nom de domaine que vous ne possédez pas et vous notifie dès qu'il devient disponible à l'enregistrement. C'est le pendant de {{< relref "/reference/checkers/domain-expiry" >}} : au lieu de protéger un domaine que vous détenez, il vous permet d'en saisir un dès qu'il se libère.
+
+Il s'agit d'un vérificateur de **niveau domaine** : l'état d'enregistrement est déterminé auprès du registre via une requête WHOIS/RDAP. Un domaine est considéré comme disponible lorsque le registre indique qu'il n'existe pas.
+
+## Ce qui est vérifié
+
+Une seule règle, `domain_availability_check`, indique si le domaine surveillé est toujours enregistré ou s'il s'est libéré.
+
+| Statut | Condition |
+|--------|-----------|
+| **Critique** | Le domaine est désormais disponible à l'enregistrement |
+| **OK** | Le domaine est toujours enregistré (le bureau d'enregistrement et la date d'expiration sont rapportés lorsqu'ils sont connus) |
+| **Erreur** | La requête de disponibilité a échoué |
+
+{{% notice style="info" title="Pourquoi la disponibilité est rapportée comme Critique" %}}
+Le statut est volontairement inversé par rapport à la convention habituelle. Rapporter *Critique* lorsque le domaine devient disponible fait franchir le seuil de notification à la transition enregistré → disponible, de sorte que vous êtes alerté exactement une fois lorsque le domaine se libère.
+{{% /notice %}}
+
+## Options
+
+Ce vérificateur ne propose aucune option configurable. Le nom de domaine surveillé est fourni automatiquement.
+
+## Dans happyDomain
+
+Contrairement aux autres vérificateurs de niveau domaine, **Disponibilité du domaine** n'est pas planifié sur les domaines que vous gérez. Il est piloté par la liste dédiée de surveillance de disponibilité. Consultez {{< relref "/pages/domain-availability" >}} pour savoir comment ajouter un domaine à surveiller, et {{< relref "/pages/checks" >}} pour le fonctionnement général des vérifications.

content/reference/checkers/domain-contact.en.md

@@ -0,0 +1,44 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Domain contacts
+description: "Verifies that the registered domain contacts (registrant, admin, tech) match the values you expect, with detection of privacy-protected records."
+weight: 30
+---
+
+The **Domain contacts** checker compares the contact information registered for a domain (registrant, administrative and technical contacts) against the values you expect. An unexpected change to a contact, especially the registrant, can be an early sign of a hijack or of an administrative mistake.
+
+This is a **domain-level** checker: the contact data is read from the registry through a WHOIS/RDAP lookup. Many registries redact contact fields for privacy; this checker detects redaction and reports it rather than treating it as a mismatch.
+
+## What it checks
+
+A single rule, `domain_contact_check`, evaluates each contact role you selected and emits one result per role.
+
+| Status | Condition |
+|--------|-----------|
+| **OK** | The role's contact matches every expected value provided |
+| **Warning** | A field does not match the expected value, or the role is missing from the record |
+| **Info** | The contact is privacy-protected (redacted) so it cannot be compared |
+| **Unknown** | No expected value is configured, or no role is selected (nothing to check) |
+| **Error** | The WHOIS/RDAP lookup failed |
+
+Comparisons are case-insensitive and exact. Redaction is detected from common markers in the contact fields such as *redacted*, *privacy*, *withheld*, *not disclosed*, *data protected*, *contact privacy* and *whoisguard*.
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Expected registrant name | If set, the configured roles must report this exact name (case-insensitive). | *(empty)* |
+| Expected organization | If set, the configured roles must report this exact organization (case-insensitive). | *(empty)* |
+| Expected email | If set, the configured roles must report this exact email (case-insensitive). | *(empty)* |
+| Contact roles to check | Comma-separated list of roles among `registrant`, `admin`, `tech`. | `registrant` |
+
+{{% notice style="info" title="At least one expected value is required" %}}
+If none of the expected name, organization or email is set, the checker has nothing to compare and reports an *Unknown* status. Set at least one expected value for the check to be meaningful.
+{{% /notice %}}
+
+## In happyDomain
+
+Enable this checker from the domain's **Checks** view; see {{< relref "/pages/checks" >}} for how to configure and schedule checks. The domain name is filled in automatically.
+
+This checker complements {{< relref "/reference/checkers/domain-expiry" >}} and {{< relref "/reference/checkers/domain-lock" >}}, which together keep the registration of a domain under watch.

content/reference/checkers/domain-contact.fr.md

@@ -0,0 +1,44 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Contacts du domaine
+description: "Vérifie que les contacts enregistrés du domaine (titulaire, administratif, technique) correspondent aux valeurs attendues, avec détection des enregistrements protégés par confidentialité."
+weight: 30
+---
+
+Le vérificateur **Contacts du domaine** compare les informations de contact enregistrées pour un domaine (contacts titulaire, administratif et technique) aux valeurs que vous attendez. Une modification inattendue d'un contact, en particulier le titulaire, peut être un signe précoce de détournement ou d'une erreur administrative.
+
+Il s'agit d'un vérificateur de **niveau domaine** : les données de contact sont lues auprès du registre via une requête WHOIS/RDAP. De nombreux registres masquent les champs de contact pour des raisons de confidentialité ; ce vérificateur détecte ce masquage et le signale au lieu de le traiter comme une divergence.
+
+## Ce qui est vérifié
+
+Une seule règle, `domain_contact_check`, évalue chaque rôle de contact sélectionné et émet un résultat par rôle.
+
+| Statut | Condition |
+|--------|-----------|
+| **OK** | Le contact du rôle correspond à chaque valeur attendue fournie |
+| **Avertissement** | Un champ ne correspond pas à la valeur attendue, ou le rôle est absent de l'enregistrement |
+| **Info** | Le contact est protégé par confidentialité (masqué) et ne peut donc pas être comparé |
+| **Inconnu** | Aucune valeur attendue n'est configurée, ou aucun rôle n'est sélectionné (rien à vérifier) |
+| **Erreur** | La requête WHOIS/RDAP a échoué |
+
+Les comparaisons sont exactes et insensibles à la casse. Le masquage est détecté à partir de marqueurs courants dans les champs de contact comme *redacted*, *privacy*, *withheld*, *not disclosed*, *data protected*, *contact privacy* et *whoisguard*.
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Nom du titulaire attendu | Si renseigné, les rôles configurés doivent rapporter ce nom exact (insensible à la casse). | *(vide)* |
+| Organisation attendue | Si renseignée, les rôles configurés doivent rapporter cette organisation exacte (insensible à la casse). | *(vide)* |
+| Adresse e-mail attendue | Si renseignée, les rôles configurés doivent rapporter cette adresse exacte (insensible à la casse). | *(vide)* |
+| Rôles de contact à vérifier | Liste de rôles séparés par des virgules parmi `registrant`, `admin`, `tech`. | `registrant` |
+
+{{% notice style="info" title="Au moins une valeur attendue est nécessaire" %}}
+Si ni le nom, ni l'organisation, ni l'adresse e-mail attendus ne sont renseignés, le vérificateur n'a rien à comparer et rapporte un statut *Inconnu*. Renseignez au moins une valeur attendue pour que la vérification ait du sens.
+{{% /notice %}}
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis la vue **Vérifications** du domaine ; consultez {{< relref "/pages/checks" >}} pour savoir comment configurer et planifier les vérifications. Le nom de domaine est renseigné automatiquement.
+
+Ce vérificateur complète {{< relref "/reference/checkers/domain-expiry" >}} et {{< relref "/reference/checkers/domain-lock" >}}, qui ensemble gardent l'enregistrement d'un domaine sous surveillance.

content/reference/checkers/domain-expiry.en.md

@@ -0,0 +1,43 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Domain expiry
+description: "Warns when a domain name is approaching its registration expiry date."
+weight: 10
+---
+
+The **Domain expiry** checker watches the registration expiry date of a domain name and warns you before it lapses. Letting a domain expire can mean losing it to another registrant, so this is one of the most important domain-level checks.
+
+This is a **domain-level** checker: it concerns the domain registration itself, not its DNS records. The expiry date is obtained from the registry through a WHOIS/RDAP lookup, together with the registrar name.
+
+## What it checks
+
+A single rule, `domain_expiry_check`, compares the number of days remaining until expiry against two thresholds and reports the corresponding status.
+
+| Status | Condition |
+|--------|-----------|
+| **Critical** | Days remaining ≤ critical threshold |
+| **Warning** | Days remaining ≤ warning threshold (but above critical) |
+| **OK** | Days remaining above the warning threshold |
+| **Error** | The WHOIS/RDAP lookup failed or no expiry date is available |
+
+The message always reports how many days remain until expiry, regardless of status.
+
+The checker also exposes a metric, `domain_expiry_days_remaining`, labelled with the registrar, so the time left can be tracked over time.
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Warning threshold (days) | Days before expiry at which a warning is raised. Must be positive. | 30 |
+| Critical threshold (days) | Days before expiry at which a critical alert is raised. Must be positive. | 7 |
+
+{{% notice style="info" title="Critical must be lower than warning" %}}
+The critical threshold must be strictly smaller than the warning threshold. happyDomain rejects a configuration where `critical_days` is greater than or equal to `warning_days`.
+{{% /notice %}}
+
+## In happyDomain
+
+Enable this checker from the domain's **Checks** view; see {{< relref "/pages/checks" >}} for how to configure and schedule checks. The domain name is filled in automatically.
+
+For the inverse situation, watching a domain you do *not* yet own so you can register it once it lapses, see the {{< relref "/reference/checkers/domain-availability" >}} checker and {{< relref "/pages/domain-availability" >}}. Related domain-level checkers include {{< relref "/reference/checkers/domain-lock" >}} and {{< relref "/reference/checkers/domain-contact" >}}.

content/reference/checkers/domain-expiry.fr.md

@@ -0,0 +1,43 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Expiration du domaine
+description: "Avertit lorsqu'un nom de domaine approche de sa date d'expiration."
+weight: 10
+---
+
+Le vérificateur **Expiration du domaine** surveille la date d'expiration de l'enregistrement d'un nom de domaine et vous avertit avant qu'elle ne soit dépassée. Laisser un domaine expirer peut conduire à le perdre au profit d'un autre titulaire : c'est l'une des vérifications les plus importantes au niveau du domaine.
+
+Il s'agit d'un vérificateur de **niveau domaine** : il concerne l'enregistrement du domaine lui-même, et non ses enregistrements DNS. La date d'expiration est obtenue auprès du registre via une requête WHOIS/RDAP, en même temps que le nom du bureau d'enregistrement.
+
+## Ce qui est vérifié
+
+Une seule règle, `domain_expiry_check`, compare le nombre de jours restant avant l'expiration à deux seuils et rapporte le statut correspondant.
+
+| Statut | Condition |
+|--------|-----------|
+| **Critique** | Jours restants ≤ seuil critique |
+| **Avertissement** | Jours restants ≤ seuil d'avertissement (mais au-dessus du critique) |
+| **OK** | Jours restants au-dessus du seuil d'avertissement |
+| **Erreur** | La requête WHOIS/RDAP a échoué ou aucune date d'expiration n'est disponible |
+
+Le message indique toujours le nombre de jours restant avant l'expiration, quel que soit le statut.
+
+Le vérificateur expose également une métrique, `domain_expiry_days_remaining`, étiquetée avec le bureau d'enregistrement, afin de suivre l'évolution du temps restant.
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Seuil d'avertissement (jours) | Nombre de jours avant l'expiration déclenchant un avertissement. Doit être positif. | 30 |
+| Seuil critique (jours) | Nombre de jours avant l'expiration déclenchant une alerte critique. Doit être positif. | 7 |
+
+{{% notice style="info" title="Le critique doit être inférieur à l'avertissement" %}}
+Le seuil critique doit être strictement inférieur au seuil d'avertissement. happyDomain refuse une configuration où `critical_days` est supérieur ou égal à `warning_days`.
+{{% /notice %}}
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis la vue **Vérifications** du domaine ; consultez {{< relref "/pages/checks" >}} pour savoir comment configurer et planifier les vérifications. Le nom de domaine est renseigné automatiquement.
+
+Pour la situation inverse, surveiller un domaine que vous ne possédez pas encore afin de l'enregistrer dès qu'il se libère, consultez le vérificateur {{< relref "/reference/checkers/domain-availability" >}} et {{< relref "/pages/domain-availability" >}}. Les vérificateurs de niveau domaine apparentés incluent {{< relref "/reference/checkers/domain-lock" >}} et {{< relref "/reference/checkers/domain-contact" >}}.

content/reference/checkers/domain-lock.en.md

@@ -0,0 +1,36 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Domain transfer lock
+description: "Verifies that a domain carries the expected EPP lock statuses that protect it against unauthorized transfers or changes."
+weight: 20
+---
+
+The **Domain transfer lock** checker verifies that a domain carries the EPP status codes that protect it against unauthorized transfers, updates or deletions. A locked domain (for example one bearing `clientTransferProhibited`) cannot be transferred away without first removing the lock, which is a key defence against domain hijacking.
+
+This is a **domain-level** checker: the status codes are read from the registry through a WHOIS/RDAP lookup, not from the zone's DNS records.
+
+## What it checks
+
+A single rule, `domain_lock_check`, compares the EPP status codes reported by the registry against the list of statuses you require.
+
+| Status | Condition |
+|--------|-----------|
+| **OK** | Every required status is present on the domain |
+| **Critical** | One or more required statuses are missing (the missing codes are listed) |
+| **Unknown** | No required status is configured (nothing to check) |
+| **Error** | The WHOIS/RDAP lookup failed |
+
+Comparison is tolerant of formatting: spaces, dashes and underscores are ignored and case does not matter, so `clientTransferProhibited`, `client-transfer-prohibited` and `client transfer prohibited` are all treated as equal.
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Required lock statuses | Comma-separated list of EPP status codes that must be present on the domain (for example `clientTransferProhibited`, `clientUpdateProhibited`, `clientDeleteProhibited`). At least one code must be supplied. | `clientTransferProhibited` |
+
+## In happyDomain
+
+Enable this checker from the domain's **Checks** view; see {{< relref "/pages/checks" >}} for how to configure and schedule checks. The domain name is filled in automatically.
+
+This checker pairs naturally with {{< relref "/reference/checkers/domain-expiry" >}} and {{< relref "/reference/checkers/domain-contact" >}} to keep the registration of a domain under control.

content/reference/checkers/domain-lock.fr.md

@@ -0,0 +1,36 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Verrou de transfert du domaine
+description: "Vérifie qu'un domaine porte les statuts de verrouillage EPP attendus, qui le protègent contre les transferts ou modifications non autorisés."
+weight: 20
+---
+
+Le vérificateur **Verrou de transfert du domaine** vérifie qu'un domaine porte les codes de statut EPP qui le protègent contre les transferts, modifications ou suppressions non autorisés. Un domaine verrouillé (par exemple portant `clientTransferProhibited`) ne peut pas être transféré sans que le verrou soit d'abord retiré, ce qui constitue une défense essentielle contre le détournement de domaine.
+
+Il s'agit d'un vérificateur de **niveau domaine** : les codes de statut sont lus auprès du registre via une requête WHOIS/RDAP, et non dans les enregistrements DNS de la zone.
+
+## Ce qui est vérifié
+
+Une seule règle, `domain_lock_check`, compare les codes de statut EPP rapportés par le registre à la liste des statuts que vous exigez.
+
+| Statut | Condition |
+|--------|-----------|
+| **OK** | Tous les statuts requis sont présents sur le domaine |
+| **Critique** | Un ou plusieurs statuts requis sont absents (les codes manquants sont listés) |
+| **Inconnu** | Aucun statut requis n'est configuré (rien à vérifier) |
+| **Erreur** | La requête WHOIS/RDAP a échoué |
+
+La comparaison tolère les différences de format : les espaces, tirets et tirets bas sont ignorés et la casse n'a pas d'importance. Ainsi `clientTransferProhibited`, `client-transfer-prohibited` et `client transfer prohibited` sont tous considérés comme équivalents.
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Statuts de verrouillage requis | Liste de codes de statut EPP séparés par des virgules qui doivent être présents sur le domaine (par exemple `clientTransferProhibited`, `clientUpdateProhibited`, `clientDeleteProhibited`). Au moins un code doit être fourni. | `clientTransferProhibited` |
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis la vue **Vérifications** du domaine ; consultez {{< relref "/pages/checks" >}} pour savoir comment configurer et planifier les vérifications. Le nom de domaine est renseigné automatiquement.
+
+Ce vérificateur se combine naturellement avec {{< relref "/reference/checkers/domain-expiry" >}} et {{< relref "/reference/checkers/domain-contact" >}} pour garder la maîtrise de l'enregistrement d'un domaine.

content/reference/checkers/email-autoconfig.en.md

@@ -0,0 +1,57 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Mail autoconfiguration
+description: "Verify that a domain publishes discoverable mail-client configuration through Thunderbird autoconfig, Microsoft Autodiscover and RFC 6186 SRV records."
+weight: 220
+---
+
+The **Mail Autoconfiguration** checker verifies that mail clients can automatically discover how to connect to your mail servers. When autoconfiguration is published correctly, a user only types their email address and password, and their client (Thunderbird, Outlook, mobile mail apps…) finds the right IMAP/POP and SMTP hosts, ports and security settings on its own.
+
+This checker is **service-level**: it applies to the mail-autoconfiguration and RFC 6186 services of a domain. For each run it probes the discovery mechanisms used by real-world clients:
+
+- **Thunderbird autoconfig** (Bucksch draft): `https://autoconfig.<domain>/mail/config-v1.1.xml` as the primary URL, with the `https://<domain>/.well-known/autoconfig/...` apex fallback, an optional plain-HTTP variant, the Mozilla ISPDB fallback, and MX-parent fallbacks.
+- **Microsoft Autodiscover** (POX): `https://autodiscover.<domain>/autodiscover/autodiscover.xml`.
+- **RFC 6186 SRV records**: `_imaps`, `_imap`, `_pop3s`, `_pop3`, `_submissions`, `_submission`, `_autodiscover`.
+- **MX resolution**, for context and MX-based discovery.
+
+It parses every response, cross-checks the servers advertised by the different sources, and produces an HTML report with paste-ready remediation snippets for the most common failure modes.
+
+## What it checks
+
+| Rule | What it verifies | Severity on failure |
+|---|---|---|
+| `autoconfig_presence` | At least one autoconfiguration discovery method answers for the domain. | Critical |
+| `autoconfig_preferred_endpoint` | The primary URL `https://autoconfig.<domain>/mail/config-v1.1.xml` is reachable and serves a valid clientConfig. | Warning |
+| `autoconfig_tls` | Autoconfig endpoints are served over HTTPS with a valid TLS certificate. | Critical |
+| `autoconfig_server_encryption` | Servers advertised by autoconfig use SSL or STARTTLS and a non-cleartext authentication method. | Critical |
+| `autoconfig_consistency` | Hostnames and ports reported by autoconfig, Autodiscover and SRV records agree with each other. | Warning |
+| `autoconfig_srv_records` | RFC 6186 SRV records complement the autoconfig XML. | Warning |
+| `autoconfig_autodiscover` | Whether Microsoft Autodiscover (POX) responds on the domain. | Warning |
+
+When a check fails, the report's "Fix this first" section provides ready-to-copy snippets: a sample `config-v1.1.xml` and its canonical URLs when nothing is published, a nudge to add the `autoconfig.` subdomain when only `.well-known` answers, an HTTPS redirect hint, a certificate-coverage hint, a port cheat-sheet for plaintext servers (SSL 993/465, STARTTLS 143/587), and a ready-to-paste SRV zone excerpt.
+
+## Options
+
+### Per user
+
+| Option | Meaning | Default |
+|---|---|---|
+| Local-part used in probes (`probeEmail`) | Local part sent in the autoconfig URL query string (before `@`). Most servers ignore it. | `test` |
+| HTTP timeout (`httpTimeout`) | Per-request timeout, in seconds, when probing endpoints. | 8 |
+| Try Mozilla ISPDB fallback (`tryISPDB`) | When the domain publishes no autoconfig file, also query Mozilla's public Thunderbird ISPDB. | true |
+| Allow plain-HTTP fallback probe (`tryHTTPAutoconfig`) | Also probe the plain-HTTP variant of `autoconfig.<domain>` (optional in the draft); useful to spot HTTP-only providers. | false |
+| Probe Microsoft Autodiscover (`tryAutodiscoverPost`) | Probe the Exchange/Outlook Autodiscover endpoints. Disable to check only the Thunderbird flow. | true |
+
+### Admin
+
+| Option | Meaning | Default |
+|---|---|---|
+| Mozilla ISPDB base URL (`ispdbURL`) | Base URL of Mozilla's autoconfig fallback database. | `https://autoconfig.thunderbird.net/v1.1/` |
+| User-Agent used in probes (`userAgent`) | User-Agent announced in every probe request. | `happyDomain-autoconfig/1.0 (+https://happydomain.org)` |
+
+## In happyDomain
+
+Enable this checker from the **Checks** tab of the relevant mail-autoconfiguration service. See {{< relref "/pages/checks" >}} for scheduling and reading checks.
+
+This checker is the natural companion to a full mail setup: see {{< relref "/reference/services/email" >}} for the MX, SPF, DKIM and DMARC services that govern how mail is delivered and authenticated.

content/reference/checkers/email-autoconfig.fr.md

@@ -0,0 +1,57 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Autoconfiguration de la messagerie
+description: "Vérifie qu'un domaine publie une configuration de messagerie découvrable via l'autoconfig Thunderbird, l'Autodiscover Microsoft et les enregistrements SRV de la RFC 6186."
+weight: 220
+---
+
+Le vérificateur d'**autoconfiguration de la messagerie** s'assure que les clients de messagerie peuvent découvrir automatiquement comment se connecter à vos serveurs de courriel. Lorsque l'autoconfiguration est publiée correctement, l'utilisateur saisit seulement son adresse et son mot de passe, et son client (Thunderbird, Outlook, applications mobiles) trouve de lui-même les bons hôtes IMAP/POP et SMTP, les ports et les réglages de sécurité.
+
+Ce vérificateur s'applique au **niveau service** : il concerne les services d'autoconfiguration de messagerie et de RFC 6186 d'un domaine. À chaque exécution, il sonde les mécanismes de découverte utilisés par les clients réels :
+
+- **Autoconfig Thunderbird** (brouillon Bucksch) : `https://autoconfig.<domaine>/mail/config-v1.1.xml` comme URL primaire, avec le repli sur l'apex `https://<domaine>/.well-known/autoconfig/...`, une variante optionnelle en HTTP simple, le repli sur l'ISPDB de Mozilla et les replis via le parent MX.
+- **Autodiscover Microsoft** (POX) : `https://autodiscover.<domaine>/autodiscover/autodiscover.xml`.
+- **Enregistrements SRV de la RFC 6186** : `_imaps`, `_imap`, `_pop3s`, `_pop3`, `_submissions`, `_submission`, `_autodiscover`.
+- **Résolution MX**, pour le contexte et la découverte fondée sur les MX.
+
+Il analyse chaque réponse, recoupe les serveurs annoncés par les différentes sources et produit un rapport HTML accompagné d'extraits de correction prêts à coller pour les défauts les plus courants.
+
+## Ce qui est vérifié
+
+| Règle | Ce qui est vérifié | Sévérité en cas d'échec |
+|---|---|---|
+| `autoconfig_presence` | Au moins une méthode de découverte d'autoconfiguration répond pour le domaine. | Critique |
+| `autoconfig_preferred_endpoint` | L'URL primaire `https://autoconfig.<domaine>/mail/config-v1.1.xml` est joignable et sert un clientConfig valide. | Avertissement |
+| `autoconfig_tls` | Les points d'accès d'autoconfig sont servis en HTTPS avec un certificat TLS valide. | Critique |
+| `autoconfig_server_encryption` | Les serveurs annoncés par l'autoconfig utilisent SSL ou STARTTLS et une méthode d'authentification non en clair. | Critique |
+| `autoconfig_consistency` | Les noms d'hôtes et ports rapportés par l'autoconfig, l'Autodiscover et les SRV concordent entre eux. | Avertissement |
+| `autoconfig_srv_records` | Les enregistrements SRV de la RFC 6186 complètent le XML d'autoconfig. | Avertissement |
+| `autoconfig_autodiscover` | Si l'Autodiscover Microsoft (POX) répond sur le domaine. | Avertissement |
+
+En cas d'échec, la section « Fix this first » du rapport fournit des extraits prêts à copier : un exemple de `config-v1.1.xml` et ses URL canoniques lorsque rien n'est publié, une incitation à ajouter le sous-domaine `autoconfig.` lorsque seul `.well-known` répond, une redirection vers HTTPS, un rappel sur la couverture du certificat, un aide-mémoire de ports pour les serveurs en clair (SSL 993/465, STARTTLS 143/587) et un extrait de zone SRV prêt à coller.
+
+## Options
+
+### Par utilisateur
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Partie locale des sondes (`probeEmail`) | Partie locale envoyée dans la chaîne de requête de l'URL d'autoconfig (avant le `@`). La plupart des serveurs l'ignorent. | `test` |
+| Délai HTTP (`httpTimeout`) | Délai par requête, en secondes, lors du sondage des points d'accès. | 8 |
+| Tenter le repli ISPDB de Mozilla (`tryISPDB`) | Lorsque le domaine ne publie aucun fichier d'autoconfig, interroger aussi l'ISPDB public de Mozilla. | true |
+| Autoriser le repli HTTP simple (`tryHTTPAutoconfig`) | Sonder aussi la variante en HTTP simple de `autoconfig.<domaine>` (optionnelle dans le brouillon) ; utile pour repérer les fournisseurs encore en HTTP. | false |
+| Sonder l'Autodiscover Microsoft (`tryAutodiscoverPost`) | Sonder les points d'accès Autodiscover Exchange/Outlook. À désactiver pour ne vérifier que le flux Thunderbird. | true |
+
+### Admin
+
+| Option | Signification | Défaut |
+|---|---|---|
+| URL de base de l'ISPDB Mozilla (`ispdbURL`) | URL de base de la base de repli d'autoconfig de Mozilla. | `https://autoconfig.thunderbird.net/v1.1/` |
+| User-Agent des sondes (`userAgent`) | User-Agent annoncé dans chaque requête de sondage. | `happyDomain-autoconfig/1.0 (+https://happydomain.org)` |
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis l'onglet **Vérifications** du service d'autoconfiguration de messagerie concerné. Voir {{< relref "/pages/checks" >}} pour la planification et la lecture des vérifications.
+
+Ce vérificateur est le compagnon naturel d'une configuration de messagerie complète : voir {{< relref "/reference/services/email" >}} pour les services MX, SPF, DKIM et DMARC qui régissent la remise et l'authentification du courrier.

content/reference/checkers/email-keys.en.md

@@ -0,0 +1,86 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Mail keys (DKIM / OpenPGP)
+description: "Validate DNS-published OpenPGP keys (OPENPGPKEY) and S/MIME certificates (SMIMEA) used for end-to-end mail encryption, including their DNSSEC authentication."
+weight: 230
+---
+
+The **Mail keys** checker (named *OPENPGPKEY & SMIMEA* in happyDomain) validates the cryptographic keys a domain publishes in DNS so that correspondents can encrypt mail to its users. It covers two DANE-style record types:
+
+- **`OPENPGPKEY`** ([RFC 7929](https://www.rfc-editor.org/rfc/rfc7929)) — an individual user's OpenPGP public key, published under an owner-hashed name below `._openpgpkey.<zone>`.
+- **`SMIMEA`** ([RFC 8162](https://www.rfc-editor.org/rfc/rfc8162)) — a user's S/MIME certificate, published under an owner-hashed name below `._smimecert.<zone>`.
+
+This checker is **service-level**: it applies to the OpenPGP and S/MIME services of a subdomain and runs a comprehensive test suite, then renders an HTML report whose top block points to the fix for the most common failure scenarios.
+
+{{% notice style="info" title="Publication and structure, not cryptographic trust" %}}
+This checker validates DNS publication and the structure and metadata of the keys it finds. It does **not** cryptographically verify them: OpenPGP signatures (self-signatures, third-party certifications) are not verified, and S/MIME chains are not built or validated against any trust anchor (no CRL/OCSP). Authenticity of the records themselves is delegated to a validating resolver via the DNSSEC `AD` flag. Treat a green report as "the record is well-formed and DNSSEC-signed", not as "the key is trustworthy".
+{{% /notice %}}
+
+## What it checks
+
+### DNS and DNSSEC
+
+| Rule | What it verifies | Severity |
+|---|---|---|
+| `dns_query_failed` | The DNS lookup for the record succeeds. | Critical |
+| `dns_no_record` | A record is published at the expected owner name. | Critical |
+| `dns_record_mismatch` | The record returned by DNS matches the service-declared record. | Warning |
+| `dnssec_not_validated` | The record is authenticated by DNSSEC (`AD` flag set). | Critical (Warning if DNSSEC not required) |
+| `owner_hash_mismatch` | The owner-name first label equals `hex(sha256(username))[:28]`. | Critical |
+
+### OpenPGP (`OPENPGPKEY`)
+
+| Rule | What it verifies | Severity |
+|---|---|---|
+| `pgp_parse_error` | The record decodes as a valid OpenPGP key. | Critical |
+| `pgp_primary_revoked` | The primary key carries no revocation signature. | Critical |
+| `pgp_primary_expired` | The primary key has not passed its self-signature expiry. | Critical |
+| `pgp_primary_expiring_soon` | The primary key does not expire within the configured window. | Warning |
+| `pgp_weak_algorithm` | No legacy algorithm (DSA/ElGamal) is used. | Warning |
+| `pgp_weak_key_size` | RSA keys meet the minimum 2048-bit size (3072+ preferred). | Critical |
+| `pgp_no_encryption_subkey` | At least one active key advertises encryption capability. | Critical |
+| `pgp_no_identity` | The key carries at least one self-signed User ID. | Warning |
+| `pgp_uid_mismatch` | At least one UID references `<username@...>`. | Info |
+| `pgp_multiple_entities` | The record carries a single OpenPGP entity (RFC 7929). | Warning |
+| `pgp_record_too_large` | The record stays below 4 KiB to fit typical UDP answers. | Warning |
+
+### S/MIME (`SMIMEA`)
+
+| Rule | What it verifies | Severity |
+|---|---|---|
+| `smimea_bad_usage` | The usage field is 0, 1, 2 or 3. | Critical |
+| `smimea_bad_selector` | The selector field is 0 (Cert) or 1 (SPKI). | Critical |
+| `smimea_bad_match_type` | The matching type is 0 (Full), 1 (SHA-256) or 2 (SHA-512). | Critical |
+| `smimea_cert_parse_error` | The record decodes as a valid X.509 certificate or SPKI. | Critical |
+| `smimea_cert_not_yet_valid` | The certificate's `NotBefore` is in the past. | Critical |
+| `smimea_cert_expired` | The certificate's `NotAfter` is in the future. | Critical |
+| `smimea_cert_expiring_soon` | The certificate does not expire within the configured window. | Warning |
+| `smimea_no_email_protection_eku` | The certificate advertises the `emailProtection` EKU. | Critical (Warning if not required) |
+| `smimea_missing_key_usage` | The certificate carries `digitalSignature` and/or `keyEncipherment` key usage. | Warning |
+| `smimea_weak_signature_algorithm` | The certificate is not signed with a deprecated algorithm (MD2/MD5/SHA-1). | Critical |
+| `smimea_weak_key_size` | RSA keys meet the minimum 2048-bit size (3072+ preferred). | Critical |
+| `smimea_self_signed` | Flags self-signed certificates paired with PKIX-EE (usage 1). | Info |
+| `smimea_email_mismatch` | At least one email SAN begins with `<username>@`. | Info |
+| `smimea_hash_only` | Notes that matching types 1/2 transport only a digest, preventing certificate inspection. | Info |
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| DNS resolver (`resolver`) | Validating resolver to query (comma-separated list accepted). Empty uses the system resolver. | (system) |
+| `certExpiryWarnDays` | Window, in days, for the `expiring_soon` warnings (PGP and S/MIME). | 30 |
+| `requireDNSSEC` | When false, a missing `AD` flag is a Warning instead of Critical. | true |
+| `requireEmailProtection` | When false, a missing `emailProtection` EKU is a Warning instead of Critical. | true |
+
+The domain origin, subdomain, service and service type are auto-filled by happyDomain.
+
+{{% notice style="info" title="Query a validating resolver" %}}
+Because record authenticity is delegated to DNSSEC, run this checker against a resolver you trust to perform DNSSEC validation, so the `AD` flag reflects a real validation.
+{{% /notice %}}
+
+## In happyDomain
+
+Enable this checker from the **Checks** tab of the relevant OpenPGP or S/MIME service. See {{< relref "/pages/checks" >}} for the general workflow.
+
+These records share their security model with DNSSEC: to confirm your zone's signing chain is itself sound, see {{< relref "/reference/checkers/dnssec" >}}. For the surrounding mail configuration, see {{< relref "/reference/services/email" >}}.

content/reference/checkers/email-keys.fr.md

@@ -0,0 +1,86 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Clés de messagerie (DKIM / OpenPGP)
+description: "Valide les clés OpenPGP (OPENPGPKEY) et les certificats S/MIME (SMIMEA) publiés dans le DNS pour le chiffrement de bout en bout du courrier, ainsi que leur authentification DNSSEC."
+weight: 230
+---
+
+Le vérificateur de **clés de messagerie** (nommé *OPENPGPKEY & SMIMEA* dans happyDomain) valide les clés cryptographiques qu'un domaine publie dans le DNS afin que ses correspondants puissent chiffrer le courrier destiné à ses utilisateurs. Il couvre deux types d'enregistrements de style DANE :
+
+- **`OPENPGPKEY`** ([RFC 7929](https://www.rfc-editor.org/rfc/rfc7929)) : la clé publique OpenPGP d'un utilisateur, publiée sous un nom haché du propriétaire, sous `._openpgpkey.<zone>`.
+- **`SMIMEA`** ([RFC 8162](https://www.rfc-editor.org/rfc/rfc8162)) : le certificat S/MIME d'un utilisateur, publié sous un nom haché du propriétaire, sous `._smimecert.<zone>`.
+
+Ce vérificateur s'applique au **niveau service** : il concerne les services OpenPGP et S/MIME d'un sous-domaine, exécute une suite de tests complète, puis produit un rapport HTML dont le bloc supérieur pointe vers la correction des défauts les plus courants.
+
+{{% notice style="info" title="Publication et structure, pas confiance cryptographique" %}}
+Ce vérificateur valide la publication DNS ainsi que la structure et les métadonnées des clés qu'il trouve. Il ne les vérifie pas cryptographiquement : les signatures OpenPGP (auto-signatures, certifications par des tiers) ne sont pas vérifiées, et les chaînes S/MIME ne sont ni construites ni validées par rapport à une ancre de confiance (pas de CRL/OCSP). L'authenticité des enregistrements eux-mêmes est déléguée à un résolveur validant via le drapeau DNSSEC `AD`. Considérez un rapport vert comme « l'enregistrement est bien formé et signé par DNSSEC », et non comme « la clé est digne de confiance ».
+{{% /notice %}}
+
+## Ce qui est vérifié
+
+### DNS et DNSSEC
+
+| Règle | Ce qui est vérifié | Sévérité |
+|---|---|---|
+| `dns_query_failed` | La requête DNS de l'enregistrement aboutit. | Critique |
+| `dns_no_record` | Un enregistrement est publié au nom de propriétaire attendu. | Critique |
+| `dns_record_mismatch` | L'enregistrement renvoyé par le DNS correspond à celui déclaré par le service. | Avertissement |
+| `dnssec_not_validated` | L'enregistrement est authentifié par DNSSEC (drapeau `AD` posé). | Critique (Avertissement si DNSSEC non exigé) |
+| `owner_hash_mismatch` | Le premier label du nom de propriétaire vaut `hex(sha256(username))[:28]`. | Critique |
+
+### OpenPGP (`OPENPGPKEY`)
+
+| Règle | Ce qui est vérifié | Sévérité |
+|---|---|---|
+| `pgp_parse_error` | L'enregistrement se décode en une clé OpenPGP valide. | Critique |
+| `pgp_primary_revoked` | La clé primaire ne porte aucune signature de révocation. | Critique |
+| `pgp_primary_expired` | La clé primaire n'a pas dépassé l'expiration de son auto-signature. | Critique |
+| `pgp_primary_expiring_soon` | La clé primaire n'expire pas dans la fenêtre configurée. | Avertissement |
+| `pgp_weak_algorithm` | Aucun algorithme ancien (DSA/ElGamal) n'est employé. | Avertissement |
+| `pgp_weak_key_size` | Les clés RSA respectent la taille minimale de 2048 bits (3072+ préférée). | Critique |
+| `pgp_no_encryption_subkey` | Au moins une clé active annonce une capacité de chiffrement. | Critique |
+| `pgp_no_identity` | La clé porte au moins un identifiant utilisateur auto-signé. | Avertissement |
+| `pgp_uid_mismatch` | Au moins un UID référence `<username@...>`. | Info |
+| `pgp_multiple_entities` | L'enregistrement porte une seule entité OpenPGP (RFC 7929). | Avertissement |
+| `pgp_record_too_large` | L'enregistrement reste sous 4 Kio pour tenir dans une réponse UDP typique. | Avertissement |
+
+### S/MIME (`SMIMEA`)
+
+| Règle | Ce qui est vérifié | Sévérité |
+|---|---|---|
+| `smimea_bad_usage` | Le champ usage vaut 0, 1, 2 ou 3. | Critique |
+| `smimea_bad_selector` | Le champ sélecteur vaut 0 (Cert) ou 1 (SPKI). | Critique |
+| `smimea_bad_match_type` | Le type de correspondance vaut 0 (Full), 1 (SHA-256) ou 2 (SHA-512). | Critique |
+| `smimea_cert_parse_error` | L'enregistrement se décode en un certificat X.509 ou un SPKI valide. | Critique |
+| `smimea_cert_not_yet_valid` | Le `NotBefore` du certificat est dans le passé. | Critique |
+| `smimea_cert_expired` | Le `NotAfter` du certificat est dans le futur. | Critique |
+| `smimea_cert_expiring_soon` | Le certificat n'expire pas dans la fenêtre configurée. | Avertissement |
+| `smimea_no_email_protection_eku` | Le certificat annonce l'EKU `emailProtection`. | Critique (Avertissement si non exigé) |
+| `smimea_missing_key_usage` | Le certificat porte l'usage de clé `digitalSignature` et/ou `keyEncipherment`. | Avertissement |
+| `smimea_weak_signature_algorithm` | Le certificat n'est pas signé avec un algorithme déprécié (MD2/MD5/SHA-1). | Critique |
+| `smimea_weak_key_size` | Les clés RSA respectent la taille minimale de 2048 bits (3072+ préférée). | Critique |
+| `smimea_self_signed` | Signale les certificats auto-signés associés à PKIX-EE (usage 1). | Info |
+| `smimea_email_mismatch` | Au moins un SAN courriel commence par `<username>@`. | Info |
+| `smimea_hash_only` | Note que les types de correspondance 1/2 ne transportent qu'un condensat, empêchant l'inspection du certificat. | Info |
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Résolveur DNS (`resolver`) | Résolveur validant à interroger (liste séparée par des virgules acceptée). Vide : résolveur système. | (système) |
+| `certExpiryWarnDays` | Fenêtre, en jours, des avertissements `expiring_soon` (PGP et S/MIME). | 30 |
+| `requireDNSSEC` | Si faux, un drapeau `AD` absent devient un Avertissement plutôt qu'un Critique. | true |
+| `requireEmailProtection` | Si faux, une EKU `emailProtection` absente devient un Avertissement plutôt qu'un Critique. | true |
+
+L'origine de la zone, le sous-domaine, le service et le type de service sont préremplis par happyDomain.
+
+{{% notice style="info" title="Interrogez un résolveur validant" %}}
+L'authenticité des enregistrements étant déléguée au DNSSEC, exécutez ce vérificateur contre un résolveur en qui vous avez confiance pour effectuer la validation DNSSEC, afin que le drapeau `AD` reflète une validation réelle.
+{{% /notice %}}
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis l'onglet **Vérifications** du service OpenPGP ou S/MIME concerné. Voir {{< relref "/pages/checks" >}} pour le fonctionnement général.
+
+Ces enregistrements partagent leur modèle de sécurité avec le DNSSEC : pour confirmer que la chaîne de signature de votre zone est elle-même saine, voir {{< relref "/reference/checkers/dnssec" >}}. Pour la configuration de messagerie environnante, voir {{< relref "/reference/services/email" >}}.

content/reference/checkers/external-expiry.en.md

@@ -0,0 +1,38 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: External-reference expiry
+description: "Retrieves the WHOIS/RDAP registration facts for the external domains your zone points to, so their expiry can be evaluated."
+weight: 50
+---
+
+The **External-reference expiry** checker looks up the registration facts of the *external* domains your zone refers to. When a record points at a name you do not own (a `CNAME` to a third-party service, an `MX` to an external provider, an `NS` delegation…), the safety of your zone depends on that external domain staying registered. If it expires and is re-registered by someone else, the pointer can be hijacked.
+
+This is a **zone-level** checker: it enumerates the external targets discovered in the zone and performs one WHOIS/RDAP lookup per distinct registrable domain. Targets sharing the same registrable domain reuse a single lookup, and lookups run with a bounded concurrency so a large zone does not overwhelm the registry.
+
+## What it checks
+
+This checker is primarily a **collector**. It gathers per-target WHOIS facts (registrable name, expiry date, creation date, registrar, status) and publishes them for the *dangling-reference* checker, which is where the actionable verdicts about expiration, redemption or recent re-registration are emitted.
+
+Its own rule, `external_whois_collected`, reports only how the collection went:
+
+| Status | Condition |
+|--------|-----------|
+| **OK** | WHOIS was collected for every external target |
+| **Info** | Some lookups succeeded and some failed (a partial result), or no external target was reported at all |
+| **Warning** | The WHOIS lookup failed for *all* external targets |
+| **Error** | The external WHOIS observation could not be read |
+
+{{% notice style="info" title="Verdicts live in the dangling-reference checker" %}}
+This checker does not decide whether an external domain is dangerously close to expiry. It only retrieves the facts. The expiry, redemption and re-registration verdicts are surfaced by the companion dangling-reference checker, which consumes the facts collected here.
+{{% /notice %}}
+
+## Options
+
+This checker has no user-tunable options. The list of external targets is supplied automatically from the zone's discovered references.
+
+## In happyDomain
+
+Enable this checker from the zone's **Checks** view; see {{< relref "/pages/checks" >}} for how to configure and schedule checks. The discovery of external targets is automatic.
+
+For the registration of the domains you own directly, see {{< relref "/reference/checkers/domain-expiry" >}}.

content/reference/checkers/external-expiry.fr.md

@@ -0,0 +1,38 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Expiration des références externes
+description: "Récupère les informations d'enregistrement WHOIS/RDAP des domaines externes vers lesquels pointe votre zone, afin d'évaluer leur expiration."
+weight: 50
+---
+
+Le vérificateur **Expiration des références externes** récupère les informations d'enregistrement des domaines *externes* auxquels votre zone fait référence. Lorsqu'un enregistrement pointe vers un nom que vous ne possédez pas (un `CNAME` vers un service tiers, un `MX` vers un prestataire externe, une délégation `NS`, etc.), la sûreté de votre zone dépend du maintien de l'enregistrement de ce domaine externe. S'il expire et qu'il est ré-enregistré par quelqu'un d'autre, le pointeur peut être détourné.
+
+Il s'agit d'un vérificateur de **niveau zone** : il énumère les cibles externes découvertes dans la zone et effectue une requête WHOIS/RDAP par domaine enregistrable distinct. Les cibles partageant le même domaine enregistrable réutilisent une seule requête, et les requêtes s'exécutent avec une concurrence limitée afin qu'une zone volumineuse ne sature pas le registre.
+
+## Ce qui est vérifié
+
+Ce vérificateur est avant tout un **collecteur**. Il rassemble les informations WHOIS par cible (nom enregistrable, date d'expiration, date de création, bureau d'enregistrement, statuts) et les publie pour le vérificateur de *références orphelines*, où sont émis les verdicts exploitables sur l'expiration, la période de rédemption ou un ré-enregistrement récent.
+
+Sa propre règle, `external_whois_collected`, ne rapporte que le déroulement de la collecte :
+
+| Statut | Condition |
+|--------|-----------|
+| **OK** | Le WHOIS a été collecté pour toutes les cibles externes |
+| **Info** | Certaines requêtes ont réussi et d'autres ont échoué (résultat partiel), ou aucune cible externe n'a été signalée |
+| **Avertissement** | La requête WHOIS a échoué pour *toutes* les cibles externes |
+| **Erreur** | L'observation WHOIS externe n'a pas pu être lue |
+
+{{% notice style="info" title="Les verdicts se trouvent dans le vérificateur de références orphelines" %}}
+Ce vérificateur ne décide pas si un domaine externe est dangereusement proche de l'expiration. Il se contente d'en récupérer les informations. Les verdicts d'expiration, de rédemption et de ré-enregistrement sont produits par le vérificateur de références orphelines associé, qui consomme les informations collectées ici.
+{{% /notice %}}
+
+## Options
+
+Ce vérificateur ne propose aucune option configurable. La liste des cibles externes est fournie automatiquement à partir des références découvertes dans la zone.
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis la vue **Vérifications** de la zone ; consultez {{< relref "/pages/checks" >}} pour savoir comment configurer et planifier les vérifications. La découverte des cibles externes est automatique.
+
+Pour l'enregistrement des domaines que vous possédez directement, consultez {{< relref "/reference/checkers/domain-expiry" >}}.

content/reference/checkers/happydeliver.en.md

@@ -0,0 +1,85 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Outbound deliverability (happyDeliver)
+description: "Send a real test message from your domain to a happyDeliver instance and grade how well it would be delivered to a real inbox."
+weight: 210
+---
+
+The **Outbound deliverability** checker (named *Outbound deliverability (via happyDeliver)* in happyDomain) measures how a message sent **from your domain** would actually fare on its way to a recipient's inbox. Rather than inspecting DNS records in isolation, it drives an external [happyDeliver](https://git.nemunai.re/happyDomain/happyDeliver) instance to perform an end-to-end test.
+
+This checker is **service-level**: it is attached to a service (typically the mail configuration of a subdomain) and needs SMTP credentials to send the test message on your behalf.
+
+## How it works
+
+For each run, the checker:
+
+1. Allocates a fresh recipient address on the configured happyDeliver instance.
+2. Sends a **real test email** from the tested domain to that address, using the SMTP submission server and credentials you provide.
+3. Polls happyDeliver until the message has been received and analysed.
+4. Stores happyDeliver's report and exposes one score per section as a metric.
+
+happyDeliver grades the message across several sections (DNS, authentication, spam filters, blacklists, headers, content) and computes an overall score. The checker turns each section into a rule.
+
+{{% notice style="info" title="An external happyDeliver instance is required" %}}
+This checker does nothing on its own: it needs a reachable happyDeliver instance, identified by its API URL and bearer token. Those are usually configured once by the administrator and can be overridden per domain.
+{{% /notice %}}
+
+## What it checks
+
+Each section rule compares happyDeliver's score for that section against a configurable minimum. The check is **Critical** when the score falls below the minimum, otherwise **OK**.
+
+| Rule | What it verifies | Default minimum |
+|---|---|---|
+| `happydeliver.score.overall` | happyDeliver's Overall score | 70 |
+| `happydeliver.score.dns` | DNS configuration score | 70 |
+| `happydeliver.score.authentication` | Authentication score (SPF / DKIM / DMARC) | 80 |
+| `happydeliver.score.spam` | Spam-filter score | 70 |
+| `happydeliver.score.blacklist` | Blacklist score | 90 |
+| `happydeliver.score.header` | Header score | 70 |
+| `happydeliver.score.content` | Content score | 60 |
+
+A separate `happydeliver.lifecycle` rule reports the outcome of the run itself: **OK** when the message was analysed, **Critical** when the test address could not be allocated, the message could not be sent, or happyDeliver returned a wait/fetch/parse error, and **Warning** when the message was not analysed before the timeout elapsed.
+
+Each section minimum can be tuned through its own `min_score_<section>` rule option in the happyDomain interface.
+
+## Options
+
+### Sending (per domain)
+
+| Option | Meaning | Default |
+|---|---|---|
+| Sending SMTP host (`smtp_host`) | Hostname or IP of the submission server used to send the test email. **Required.** | (none) |
+| Sending SMTP port (`smtp_port`) | Submission port (587 for STARTTLS, 465 for implicit TLS, 25 for plain). | 587 |
+| SMTP username (`smtp_username`) | Username for the submission server (omit for anonymous submission). | (none) |
+| SMTP password (`smtp_password`) | Password for the submission server. | (none) |
+| TLS mode (`smtp_tls`) | How to negotiate TLS: `starttls`, `tls`, or `none`. | `starttls` |
+| From address (`from_address`) | Address used in the `From` header; must belong to the tested domain. | `no-reply@<domain>` |
+
+### Message content (per domain)
+
+| Option | Meaning | Default |
+|---|---|---|
+| Subject (`subject_override`) | Override the default test subject. | (built-in) |
+| Plain-text body (`body_text_override`) | Override the default plain-text body. | (built-in) |
+| HTML body (`body_html_override`) | Override the default HTML body. | (built-in) |
+
+### Timing (per domain)
+
+| Option | Meaning | Default |
+|---|---|---|
+| Wait timeout (`wait_timeout`) | Seconds to wait for happyDeliver to receive and analyse the message. | 900 |
+| Poll interval (`poll_interval`) | Seconds between status polls (clamped to the 2–60 range). | 5 |
+
+### Instance (admin, overridable per domain)
+
+| Option | Meaning | Default |
+|---|---|---|
+| happyDeliver instance URL (`happydeliver_url`) | Base URL of the happyDeliver API. | (admin) |
+| happyDeliver API token (`happydeliver_token`) | Bearer token for the happyDeliver API. | (admin) |
+
+## In happyDomain
+
+Enable this checker from the service's **Checks** tab and provide the SMTP submission details so happyDomain can send the test message. See {{< relref "/pages/checks" >}} for the general workflow of scheduling and reading checks.
+
+Because deliverability depends heavily on your anti-spoofing posture, pair this checker with a well-configured {{< relref "/reference/services/email" >}} setup (SPF, DKIM and DMARC). For the DNSSEC half of your domain's trust chain, see {{< relref "/reference/checkers/dnssec" >}}.

content/reference/checkers/happydeliver.fr.md

@@ -0,0 +1,85 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Délivrabilité sortante (happyDeliver)
+description: "Envoie un véritable message de test depuis votre domaine vers une instance happyDeliver et évalue la qualité de sa délivrabilité jusqu'à une boîte de réception réelle."
+weight: 210
+---
+
+Le vérificateur de **délivrabilité sortante** (nommé *Outbound deliverability (via happyDeliver)* dans happyDomain) mesure le sort que connaîtrait un message envoyé **depuis votre domaine** sur le chemin de la boîte de réception du destinataire. Au lieu d'examiner les enregistrements DNS isolément, il pilote une instance externe [happyDeliver](https://git.nemunai.re/happyDomain/happyDeliver) pour réaliser un test de bout en bout.
+
+Ce vérificateur s'applique au **niveau service** : il est rattaché à un service (typiquement la configuration de messagerie d'un sous-domaine) et a besoin d'identifiants SMTP pour envoyer le message de test en votre nom.
+
+## Fonctionnement
+
+À chaque exécution, le vérificateur :
+
+1. Alloue une adresse de réception neuve sur l'instance happyDeliver configurée.
+2. Envoie un **véritable courriel de test** depuis le domaine testé vers cette adresse, en utilisant le serveur de soumission SMTP et les identifiants que vous fournissez.
+3. Interroge happyDeliver jusqu'à ce que le message ait été reçu et analysé.
+4. Conserve le rapport de happyDeliver et expose le score de chaque section sous forme de métrique.
+
+happyDeliver note le message sur plusieurs sections (DNS, authentification, filtres anti-spam, listes noires, en-têtes, contenu) et calcule un score global. Le vérificateur transforme chaque section en une règle.
+
+{{% notice style="info" title="Une instance happyDeliver externe est requise" %}}
+Ce vérificateur ne fait rien seul : il lui faut une instance happyDeliver accessible, identifiée par l'URL de son API et un jeton d'authentification. Ceux-ci sont en général configurés une fois par l'administrateur et peuvent être redéfinis par domaine.
+{{% /notice %}}
+
+## Ce qui est vérifié
+
+Chaque règle de section compare le score happyDeliver de cette section à un minimum configurable. La vérification est **Critique** lorsque le score passe sous le minimum, sinon **OK**.
+
+| Règle | Ce qui est vérifié | Minimum par défaut |
+|---|---|---|
+| `happydeliver.score.overall` | Score global de happyDeliver | 70 |
+| `happydeliver.score.dns` | Score de configuration DNS | 70 |
+| `happydeliver.score.authentication` | Score d'authentification (SPF / DKIM / DMARC) | 80 |
+| `happydeliver.score.spam` | Score des filtres anti-spam | 70 |
+| `happydeliver.score.blacklist` | Score des listes noires | 90 |
+| `happydeliver.score.header` | Score des en-têtes | 70 |
+| `happydeliver.score.content` | Score du contenu | 60 |
+
+Une règle distincte, `happydeliver.lifecycle`, rapporte le déroulement de l'exécution elle-même : **OK** lorsque le message a été analysé, **Critique** lorsque l'adresse de test n'a pu être allouée, que le message n'a pu être envoyé, ou que happyDeliver a renvoyé une erreur d'attente, de récupération ou d'analyse, et **Avertissement** lorsque le message n'a pas été analysé avant l'expiration du délai.
+
+Chaque minimum de section se règle via son option de règle `min_score_<section>` dans l'interface de happyDomain.
+
+## Options
+
+### Envoi (par domaine)
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Serveur SMTP d'envoi (`smtp_host`) | Nom d'hôte ou IP du serveur de soumission utilisé pour envoyer le courriel de test. **Obligatoire.** | (aucun) |
+| Port SMTP d'envoi (`smtp_port`) | Port de soumission (587 pour STARTTLS, 465 pour TLS implicite, 25 pour le texte clair). | 587 |
+| Identifiant SMTP (`smtp_username`) | Identifiant du serveur de soumission (à omettre pour une soumission anonyme). | (aucun) |
+| Mot de passe SMTP (`smtp_password`) | Mot de passe du serveur de soumission. | (aucun) |
+| Mode TLS (`smtp_tls`) | Mode de négociation TLS : `starttls`, `tls` ou `none`. | `starttls` |
+| Adresse d'expéditeur (`from_address`) | Adresse utilisée dans l'en-tête `From` ; elle doit appartenir au domaine testé. | `no-reply@<domaine>` |
+
+### Contenu du message (par domaine)
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Sujet (`subject_override`) | Remplace le sujet de test par défaut. | (intégré) |
+| Corps texte (`body_text_override`) | Remplace le corps texte par défaut. | (intégré) |
+| Corps HTML (`body_html_override`) | Remplace le corps HTML par défaut. | (intégré) |
+
+### Temporisation (par domaine)
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Délai d'attente (`wait_timeout`) | Secondes d'attente pour que happyDeliver reçoive et analyse le message. | 900 |
+| Intervalle d'interrogation (`poll_interval`) | Secondes entre deux interrogations de statut (borné à la plage 2 à 60). | 5 |
+
+### Instance (admin, redéfinissable par domaine)
+
+| Option | Signification | Défaut |
+|---|---|---|
+| URL de l'instance happyDeliver (`happydeliver_url`) | URL de base de l'API happyDeliver. | (admin) |
+| Jeton d'API happyDeliver (`happydeliver_token`) | Jeton d'authentification de l'API happyDeliver. | (admin) |
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis l'onglet **Vérifications** du service et fournissez les détails de soumission SMTP afin que happyDomain puisse envoyer le message de test. Voir {{< relref "/pages/checks" >}} pour le fonctionnement général de la planification et de la lecture des vérifications.
+
+La délivrabilité dépendant fortement de votre posture anti-usurpation, associez ce vérificateur à une configuration {{< relref "/reference/services/email" >}} bien réglée (SPF, DKIM et DMARC). Pour la partie DNSSEC de la chaîne de confiance de votre domaine, voir {{< relref "/reference/checkers/dnssec" >}}.

content/reference/checkers/http.en.md

@@ -0,0 +1,54 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: HTTP / HTTPS
+description: "Probes a web server over HTTP and HTTPS and evaluates reachability, the redirect chain, and the full battery of HTTP security response headers and cookie hygiene rules."
+weight: 180
+---
+
+The **HTTP / HTTPS** checker probes the web server declared by a *Server* service over plain HTTP (port 80) and HTTPS (port 443), then evaluates a battery of independent rules on the responses: reachability, the HTTP→HTTPS redirect chain, and the modern set of HTTP security headers (HSTS, CSP, frame options, cross-origin isolation…) along with cookie hygiene.
+
+**Scope:** service-level. It attaches to services of type `abstract.Server` (a subdomain that publishes `A`/`AAAA` records) and is configured from that service's **Checks** tab.
+
+Deep TLS and certificate analysis is intentionally delegated to the {{< relref "/reference/checkers/tls" >}} checker; this checker relies on TLS only as a transport.
+
+## What it checks
+
+| Rule | Verifies | Severity |
+|------|----------|----------|
+| `http.tcp_reachable` | Every probed IP accepts an HTTP connection on port 80. | Critical |
+| `https.tcp_reachable` | Every probed IP accepts an HTTPS connection on port 443. | Critical |
+| `http.https_redirect` | Plain HTTP redirects to an HTTPS URL on the same host. | Warning |
+| `http.redirect_chain` | The redirect chain has no loops, excessive length, or scheme downgrades. | Warning |
+| `http.redirect_permanence` | HTTP→HTTPS upgrade uses 301 or 308 (permanent) rather than 302/307. | Warning |
+| `http.hsts` | Presence and quality of the Strict-Transport-Security header on HTTPS. | Warning |
+| `http.csp` | Presence and quality of the Content-Security-Policy header on HTTPS. | Warning |
+| `http.x_frame_options` | Responses set X-Frame-Options or a CSP `frame-ancestors` directive. | Warning |
+| `http.x_content_type_options` | Responses set `X-Content-Type-Options: nosniff`. | Warning |
+| `http.x_xss_protection` | Reports the legacy X-XSS-Protection header value (CSP is the proper replacement). | Info |
+| `http.referrer_policy` | Responses set a privacy-preserving Referrer-Policy header. | Warning |
+| `http.permissions_policy` | The Permissions-Policy header restricts powerful APIs (camera, microphone, geolocation…). | Warning |
+| `http.coop` | The Cross-Origin-Opener-Policy header is set for cross-origin process isolation. | Warning |
+| `http.coep` | The Cross-Origin-Embedder-Policy header is set (required with COOP for cross-origin isolation). | Warning |
+| `http.corp` | The Cross-Origin-Resource-Policy header restricts cross-origin embedding. | Warning |
+| `http.cookie_flags` | Cookies set over HTTPS use the Secure, HttpOnly and SameSite attributes. | Warning |
+| `http.cookie_prefixes` | Cookies using the `__Secure-` / `__Host-` prefixes meet the RFC 6265bis constraints. | Warning |
+| `http.cookie_size` | Flags Set-Cookie lines exceeding the 4096-byte minimum browsers must support. | Warning |
+| `http.sri` | Reports cross-origin script/style tags missing Subresource Integrity attributes. | Warning |
+| `http.security_txt` | Reports whether `/.well-known/security.txt` (RFC 9116) is published. | Warning |
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Per-request timeout (ms) (`probeTimeoutMs`) | Maximum time allowed for a single HTTP/HTTPS request. | 10000 |
+| Max redirects to follow (`maxRedirects`) | Stop following redirects after this many hops. | 5 |
+| User-Agent (`userAgent`) | User-Agent header sent with every request. | `happyDomain-checker-http/1.0` |
+| Require HTTPS (`requireHTTPS`) | Plain HTTP must redirect to HTTPS. | true |
+| Require HSTS (`requireHSTS`) | HTTPS responses must include a Strict-Transport-Security header. | true |
+| Min HSTS max-age (days) (`minHSTSMaxAgeDays`) | Minimum acceptable HSTS max-age, in days. | 180 |
+| Require Content-Security-Policy (`requireCSP`) | HTTPS responses must include a Content-Security-Policy header. | false |
+
+## In happyDomain
+
+This is a service-level checker: configure it from the **Checks** tab of the *Server* service on the relevant subdomain. For deep certificate posture, add the {{< relref "/reference/checkers/tls" >}} checker as well. For the general workflow of configuring and reading checks, see {{< relref "/pages/checks" >}}.

content/reference/checkers/http.fr.md

@@ -0,0 +1,54 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: HTTP / HTTPS
+description: "Sonde un serveur web en HTTP et HTTPS et évalue l'accessibilité, la chaîne de redirections, ainsi que l'ensemble des en-têtes de sécurité HTTP et des règles d'hygiène des cookies."
+weight: 180
+---
+
+Le vérificateur **HTTP / HTTPS** sonde le serveur web déclaré par un service « Serveur » en HTTP simple (port 80) et en HTTPS (port 443), puis évalue une série de règles indépendantes sur les réponses : accessibilité, chaîne de redirections HTTP vers HTTPS et ensemble moderne des en-têtes de sécurité HTTP (HSTS, CSP, options de cadre, isolation inter-origines, etc.), ainsi que l'hygiène des cookies.
+
+**Portée** : niveau service. Il s'attache aux services de type `abstract.Server` (un sous-domaine publiant des enregistrements `A`/`AAAA`) et se configure depuis l'onglet **Vérifications** de ce service.
+
+L'analyse approfondie du TLS et des certificats est volontairement déléguée au vérificateur {{< relref "/reference/checkers/tls" >}} ; ce vérificateur ne s'appuie sur TLS que comme transport.
+
+## Ce qu'il vérifie
+
+| Règle | Vérifie | Sévérité |
+|-------|---------|----------|
+| `http.tcp_reachable` | Chaque IP sondée accepte une connexion HTTP sur le port 80. | Critique |
+| `https.tcp_reachable` | Chaque IP sondée accepte une connexion HTTPS sur le port 443. | Critique |
+| `http.https_redirect` | Le HTTP simple redirige vers une URL HTTPS sur le même hôte. | Avertissement |
+| `http.redirect_chain` | La chaîne de redirections est sans boucle, sans longueur excessive ni rétrogradation de schéma. | Avertissement |
+| `http.redirect_permanence` | La bascule HTTP vers HTTPS utilise 301 ou 308 (permanent) plutôt que 302/307. | Avertissement |
+| `http.hsts` | Présence et qualité de l'en-tête Strict-Transport-Security en HTTPS. | Avertissement |
+| `http.csp` | Présence et qualité de l'en-tête Content-Security-Policy en HTTPS. | Avertissement |
+| `http.x_frame_options` | Les réponses définissent X-Frame-Options ou une directive CSP `frame-ancestors`. | Avertissement |
+| `http.x_content_type_options` | Les réponses définissent `X-Content-Type-Options: nosniff`. | Avertissement |
+| `http.x_xss_protection` | Rapporte la valeur de l'en-tête hérité X-XSS-Protection (CSP est le remplaçant adéquat). | Info |
+| `http.referrer_policy` | Les réponses définissent un en-tête Referrer-Policy respectueux de la vie privée. | Avertissement |
+| `http.permissions_policy` | L'en-tête Permissions-Policy restreint les API sensibles (caméra, microphone, géolocalisation, etc.). | Avertissement |
+| `http.coop` | L'en-tête Cross-Origin-Opener-Policy est défini pour l'isolation de processus inter-origines. | Avertissement |
+| `http.coep` | L'en-tête Cross-Origin-Embedder-Policy est défini (requis avec COOP pour l'isolation inter-origines). | Avertissement |
+| `http.corp` | L'en-tête Cross-Origin-Resource-Policy restreint l'inclusion inter-origines. | Avertissement |
+| `http.cookie_flags` | Les cookies posés en HTTPS utilisent les attributs Secure, HttpOnly et SameSite. | Avertissement |
+| `http.cookie_prefixes` | Les cookies utilisant les préfixes `__Secure-` / `__Host-` respectent les contraintes RFC 6265bis. | Avertissement |
+| `http.cookie_size` | Signale les lignes Set-Cookie dépassant les 4096 octets que les navigateurs doivent supporter au minimum. | Avertissement |
+| `http.sri` | Rapporte les balises script/style inter-origines dépourvues d'attributs Subresource Integrity. | Avertissement |
+| `http.security_txt` | Indique si `/.well-known/security.txt` (RFC 9116) est publié. | Avertissement |
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Délai par requête (ms) (`probeTimeoutMs`) | Temps maximal alloué à une requête HTTP/HTTPS. | 10000 |
+| Nombre maximal de redirections (`maxRedirects`) | Arrête de suivre les redirections au-delà de ce nombre de sauts. | 5 |
+| User-Agent (`userAgent`) | En-tête User-Agent envoyé à chaque requête. | `happyDomain-checker-http/1.0` |
+| Exiger HTTPS (`requireHTTPS`) | Le HTTP simple doit rediriger vers HTTPS. | true |
+| Exiger HSTS (`requireHSTS`) | Les réponses HTTPS doivent inclure un en-tête Strict-Transport-Security. | true |
+| max-age HSTS minimal (jours) (`minHSTSMaxAgeDays`) | Valeur max-age HSTS minimale acceptable, en jours. | 180 |
+| Exiger Content-Security-Policy (`requireCSP`) | Les réponses HTTPS doivent inclure un en-tête Content-Security-Policy. | false |
+
+## Dans happyDomain
+
+C'est un vérificateur de niveau service : configurez-le depuis l'onglet **Vérifications** du service « Serveur » sur le sous-domaine concerné. Pour la posture détaillée des certificats, ajoutez aussi le vérificateur {{< relref "/reference/checkers/tls" >}}. Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir {{< relref "/pages/checks" >}}.

content/reference/checkers/kerberos.en.md

@@ -0,0 +1,49 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Kerberos
+description: "Audits a Kerberos realm from its DNS records: SRV layout, KDC/kadmin/kpasswd reachability, an anonymous AS-REQ probe (realm, enctypes, pre-auth, clock skew), and an optional authenticated round-trip."
+weight: 260
+---
+
+The **Kerberos** checker audits a Kerberos realm starting from its DNS records. From the realm name (derived in uppercase from the domain) and the SRV records grouped under the *Kerberos* service, it runs a series of **anonymous probes** and, when credentials are supplied, an optional **authenticated round-trip** — giving a combined picture of the realm's availability and security posture.
+
+This checker is **service-level**: it targets a *Kerberos* service (`abstract.Kerberos`) published on a subdomain and is configured from that service's own **Checks** tab. It inspects the SRV layout (`_kerberos._tcp`, `_kerberos._udp`, `_kerberos-master._tcp`, `_kerberos-adm._tcp`, `_kpasswd._tcp`, `_kpasswd._udp`), forward-resolves every SRV target (A + AAAA), tests TCP reachability of each KDC/kadmin/kpasswd host and UDP reachability of the KDC via a real AS-REQ. The anonymous AS-REQ probe confirms the realm, reads the supported enctypes from `ETYPE-INFO2`, detects a PKINIT hint (`PA-PK-AS-REQ`) and measures clock skew.
+
+{{% notice style="info" title="Credentials are forwarded to the KDC" %}}
+When a principal and password are supplied, they are used once to obtain a TGT and then a TGS-REQ for the target service; they are forwarded to the KDC over the network and are never stored by the checker. Leave them blank to run anonymous probes only.
+{{% /notice %}}
+
+## What it checks
+
+| Rule | What it verifies | Severity |
+|---|---|---|
+| `kerberos.srv_present` | At least one `_kerberos._tcp` / `_kerberos._udp` SRV record is published for the realm. | Critical |
+| `kerberos.kdc_reachable` | At least one KDC endpoint (TCP/UDP 88) accepts a connection. | Critical |
+| `kerberos.as_probe` | The anonymous AS-REQ probe received a sane reply (`KRB-ERROR` or `AS-REP`). | Critical |
+| `kerberos.realm_match` | The KDC answers for the expected realm name. | Critical |
+| `kerberos.preauth_required` | Flags KDCs that return an `AS-REP` without requiring pre-authentication (AS-REP roasting exposure). | Warning |
+| `kerberos.clock_skew` | The KDC clock is within tolerance of the checker's clock. | Critical |
+| `kerberos.enctypes` | Reviews the encryption types advertised by the KDC, flagging DES/RC4-only configurations. | Critical |
+| `kerberos.kadmin_reachable` | Flags kadmin endpoints published via SRV but not reachable. | Warning |
+| `kerberos.kpasswd_reachable` | Flags kpasswd endpoints published via SRV but not reachable. | Warning |
+| `kerberos.auth_tgt` | The supplied principal/password can obtain a TGT (only runs when credentials are supplied). | Critical |
+| `kerberos.auth_tgs` | A TGS-REQ succeeds for the supplied target service (only runs when credentials and a target service are supplied). | Warning |
+
+The HTML report surfaces the most common misconfigurations with a direct remediation hint: no SRV records (publish `_kerberos._tcp.REALM. SRV …`), an SRV target with no A/AAAA, port 88 unreachable (open TCP+UDP 88), clock skew above the maximum (run ntpd/chrony), weak-enctype-only realms (switch to `aes256-cts-hmac-sha1-96`), the wrong realm in the reply, and AS-REP roasting exposure (enable `requires_preauth`).
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| Kerberos realm | DNS domain advertising the realm (auto-filled from the service scope; the realm name is derived in uppercase). Required. | *(auto)* |
+| Principal | Optional. Supply to run an authenticated round-trip; leave blank for anonymous probes only. | *(empty)* |
+| Password | Optional, secret. Password for the principal above; used once per run and never stored. | *(empty)* |
+| Service to request (TGS) | Optional. SPN requested via TGS-REQ once a TGT is acquired. Defaults to `krbtgt` (realm self-test). | *(empty)* |
+| Per-probe timeout (seconds) | Timeout for each probe. | `5` |
+| Require strong enctypes | When enabled, realms advertising only DES/RC4 are flagged as Critical. | `true` |
+| Max tolerated clock skew (seconds) | Default Kerberos tolerance is 300 s; tighter values surface drift earlier. | `300` |
+
+## In happyDomain
+
+Enable the Kerberos checker from the **Checks** tab of a Kerberos service. The realm domain is filled in automatically; supply a principal and password only if you want the authenticated TGT/TGS round-trip to run. See {{< relref "/pages/checks" >}} for the full workflow.

content/reference/checkers/kerberos.fr.md

@@ -0,0 +1,49 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Kerberos
+description: "Audite un royaume Kerberos à partir de ses enregistrements DNS : disposition SRV, accessibilité KDC/kadmin/kpasswd, sonde AS-REQ anonyme (royaume, enctypes, pré-authentification, dérive d'horloge) et aller-retour authentifié facultatif."
+weight: 260
+---
+
+Le vérificateur **Kerberos** audite un royaume Kerberos à partir de ses enregistrements DNS. À partir du nom du royaume (dérivé en majuscules depuis le domaine) et des enregistrements SRV regroupés sous le service *Kerberos*, il exécute une série de **sondes anonymes** et, lorsque des identifiants sont fournis, un **aller-retour authentifié** facultatif, ce qui donne une vue combinée de la disponibilité et de la posture de sécurité du royaume.
+
+Il s'agit d'un vérificateur de **niveau service** : il cible un service *Kerberos* (`abstract.Kerberos`) publié sur un sous-domaine et se configure depuis l'onglet **Vérifications** de ce service. Il inspecte la disposition SRV (`_kerberos._tcp`, `_kerberos._udp`, `_kerberos-master._tcp`, `_kerberos-adm._tcp`, `_kpasswd._tcp`, `_kpasswd._udp`), résout en avant chaque cible SRV (A + AAAA), teste l'accessibilité TCP de chaque hôte KDC/kadmin/kpasswd et l'accessibilité UDP du KDC via un véritable AS-REQ. La sonde AS-REQ anonyme confirme le royaume, lit les enctypes pris en charge depuis `ETYPE-INFO2`, détecte un indice PKINIT (`PA-PK-AS-REQ`) et mesure la dérive d'horloge.
+
+{{% notice style="info" title="Les identifiants sont transmis au KDC" %}}
+Lorsqu'un principal et un mot de passe sont fournis, ils servent une fois à obtenir un TGT puis à effectuer un TGS-REQ pour le service cible ; ils sont transmis au KDC sur le réseau et ne sont jamais stockés par le vérificateur. Laissez-les vides pour n'exécuter que les sondes anonymes.
+{{% /notice %}}
+
+## Ce qui est vérifié
+
+| Règle | Ce qui est vérifié | Gravité |
+|---|---|---|
+| `kerberos.srv_present` | Au moins un enregistrement SRV `_kerberos._tcp` / `_kerberos._udp` est publié pour le royaume. | Critique |
+| `kerberos.kdc_reachable` | Au moins un point d'accès KDC (TCP/UDP 88) accepte une connexion. | Critique |
+| `kerberos.as_probe` | La sonde AS-REQ anonyme a reçu une réponse cohérente (`KRB-ERROR` ou `AS-REP`). | Critique |
+| `kerberos.realm_match` | Le KDC répond pour le nom de royaume attendu. | Critique |
+| `kerberos.preauth_required` | Signale les KDC qui renvoient un `AS-REP` sans exiger de pré-authentification (exposition à l'AS-REP roasting). | Avertissement |
+| `kerberos.clock_skew` | L'horloge du KDC est dans la tolérance par rapport à celle du vérificateur. | Critique |
+| `kerberos.enctypes` | Examine les types de chiffrement annoncés par le KDC, signalant les configurations limitées à DES/RC4. | Critique |
+| `kerberos.kadmin_reachable` | Signale les points d'accès kadmin publiés via SRV mais inaccessibles. | Avertissement |
+| `kerberos.kpasswd_reachable` | Signale les points d'accès kpasswd publiés via SRV mais inaccessibles. | Avertissement |
+| `kerberos.auth_tgt` | Le principal/mot de passe fourni peut obtenir un TGT (ne s'exécute que si des identifiants sont fournis). | Critique |
+| `kerberos.auth_tgs` | Un TGS-REQ réussit pour le service cible fourni (ne s'exécute que si des identifiants et un service cible sont fournis). | Avertissement |
+
+Le rapport HTML met en avant les erreurs de configuration les plus courantes avec une piste de remédiation directe : absence d'enregistrements SRV (publier `_kerberos._tcp.REALM. SRV …`), une cible SRV sans A/AAAA, le port 88 inaccessible (ouvrir TCP+UDP 88), une dérive d'horloge au-dessus du maximum (lancer ntpd/chrony), des royaumes limités aux enctypes faibles (passer à `aes256-cts-hmac-sha1-96`), un mauvais royaume dans la réponse, et l'exposition à l'AS-REP roasting (activer `requires_preauth`).
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Royaume Kerberos | Domaine DNS annonçant le royaume (renseigné automatiquement depuis la portée du service ; le nom du royaume est dérivé en majuscules). Obligatoire. | *(auto)* |
+| Principal | Facultatif. À fournir pour exécuter un aller-retour authentifié ; laissez vide pour n'exécuter que les sondes anonymes. | *(vide)* |
+| Mot de passe | Facultatif, secret. Mot de passe du principal ci-dessus ; utilisé une fois par exécution et jamais stocké. | *(vide)* |
+| Service à demander (TGS) | Facultatif. SPN demandé via TGS-REQ une fois un TGT obtenu. Par défaut `krbtgt` (auto-test du royaume). | *(vide)* |
+| Délai d'attente par sonde (secondes) | Délai d'attente pour chaque sonde. | `5` |
+| Exiger des enctypes forts | Lorsqu'activé, les royaumes n'annonçant que DES/RC4 sont signalés comme Critique. | `true` |
+| Dérive d'horloge maximale tolérée (secondes) | La tolérance Kerberos par défaut est de 300 s ; des valeurs plus strictes font apparaître la dérive plus tôt. | `300` |
+
+## Dans happyDomain
+
+Activez le vérificateur Kerberos depuis l'onglet **Vérifications** d'un service Kerberos. Le domaine du royaume est renseigné automatiquement ; fournissez un principal et un mot de passe uniquement si vous souhaitez exécuter l'aller-retour authentifié TGT/TGS. Consultez {{< relref "/pages/checks" >}} pour le fonctionnement complet.

content/reference/checkers/ldap.en.md

@@ -0,0 +1,51 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: LDAP
+description: "Probes a domain's LDAP directory end-to-end: SRV discovery, transport encryption (StartTLS / LDAPS), RootDSE introspection, anonymous exposure, plaintext-bind refusal, and optional authenticated bind."
+weight: 250
+---
+
+The **LDAP** checker probes a domain's LDAP directory deployment from end to end. Starting from SRV discovery (`_ldap._tcp`, `_ldaps._tcp`), it tests reachability of every endpoint, confirms an encrypted channel is available (StartTLS per RFC 2830 or implicit TLS on port 636), introspects the RootDSE, looks for anonymous information disclosure, verifies the directory refuses cleartext binds, and — when credentials are supplied — performs an authenticated bind over TLS with an optional read test on a base DN.
+
+This checker is **service-level**: it targets an *LDAP* service (`abstract.LDAP`) published on a subdomain and is configured from that service's own **Checks** tab. For each transport it probes `_ldap._tcp` (falling back to port 389) and `_ldaps._tcp` (falling back to port 636), testing each resolved A/AAAA address per IP family.
+
+{{% notice style="info" title="TLS posture is folded in, not duplicated" %}}
+The LDAP checker confirms only that a TLS session can be established, recording the negotiated version and cipher for context. Each probed endpoint is published as a `tls.endpoint.v1` discovery entry so the dedicated TLS checker can verify the certificate chain, hostname match and expiry. Those findings are folded back onto the LDAP service page through the `ldap.tls_quality` rule — a bad certificate on an LDAP endpoint shows up here, not only in a separate TLS view. See {{< relref "/reference/checkers/tls" >}}.
+{{% /notice %}}
+
+## What it checks
+
+| Rule | What it verifies | Severity |
+|---|---|---|
+| `ldap.has_srv` | `_ldap._tcp` / `_ldaps._tcp` SRV records are published and resolvable. | Warning |
+| `ldap.endpoint_reachable` | Every discovered LDAP endpoint accepts a TCP connection. | Critical |
+| `ldap.has_encrypted_transport` | At least one reachable endpoint offers an encrypted channel (LDAPS or StartTLS). | Critical |
+| `ldap.starttls_supported` | StartTLS is offered and the upgrade succeeds on every reachable plain LDAP endpoint. | Critical |
+| `ldap.ldaps_handshake` | The direct TLS handshake succeeds on every LDAPS endpoint. | Critical |
+| `ldap.starttls_on_ldaps` | Flags servers that needlessly advertise StartTLS on the implicit-TLS LDAPS port. | Info |
+| `ldap.ipv6_reachable` | At least one endpoint is reachable over IPv6. | Info |
+| `ldap.refuses_plain_bind` | The directory refuses authentication over a cleartext channel (`confidentialityRequired`, resultCode 13, per RFC 4513 §5.1.2). | Critical |
+| `ldap.anonymous_search_blocked` | Flags directories that allow an anonymous `baseObject` search of the naming context (information disclosure). | Warning |
+| `ldap.rootdse_readable` | The RootDSE is readable over TLS and advertises naming contexts. | Warning |
+| `ldap.sasl_mechanisms` | Reviews `supportedSASLMechanisms`: presence of strong mechanisms (SCRAM-*, EXTERNAL, GSSAPI), absence of password-equivalent ones (PLAIN/LOGIN only). | Warning |
+| `ldap.protocol_version` | Flags servers that still advertise the deprecated LDAPv2 protocol. | Warning |
+| `ldap.bind_credentials` | The supplied bind credentials are accepted by the directory (only runs when `bind_dn` is set). | Critical |
+| `ldap.base_dn_read` | The bound account can read the supplied base DN (only runs when `base_dn` is set and the bind succeeded). | Critical |
+| `ldap.tls_quality` | Folds the downstream TLS checker findings (certificate chain, hostname match, expiry) onto the LDAP service. | Critical |
+
+The HTML report leads with the most common failures and includes server-specific remediation (OpenLDAP `olcSecurity`, 389-ds `require_tls`…): no encrypted endpoint reachable, StartTLS missing on 389, a StartTLS handshake that fails, a cleartext bind accepted on 389, an LDAPS handshake that fails, anonymous search exposing the DIT, PLAIN/LOGIN-only SASL, lingering LDAPv2, and rejected bind credentials.
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| Domain | The directory's domain (auto-filled from the service scope). Required. | *(auto)* |
+| Per-endpoint timeout (seconds) | Connection/probe timeout for each endpoint. | `10` |
+| Bind DN | Optional. DN to bind as; used only when a bind password is also set, and only over a TLS-protected channel. | *(empty)* |
+| Bind password | Optional, secret. The password is not persisted in the observation payload and is never sent over cleartext. | *(empty)* |
+| Base DN (read test) | Optional. After a successful bind, a `baseObject` search on this DN confirms the account has read access. Falls back to an anonymous `baseObject` search when no bind DN is supplied. | *(empty)* |
+
+## In happyDomain
+
+Enable the LDAP checker from the **Checks** tab of an LDAP service. The domain is filled in automatically; supply a bind DN and password only if you want the authenticated bind and base-DN read tests to run. See {{< relref "/pages/checks" >}} for the full workflow, and {{< relref "/reference/checkers/tls" >}} for the certificate posture of the same endpoints.

content/reference/checkers/ldap.fr.md

@@ -0,0 +1,51 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: LDAP
+description: "Sonde l'annuaire LDAP d'un domaine de bout en bout : découverte SRV, chiffrement du transport (StartTLS / LDAPS), introspection RootDSE, exposition anonyme, refus du bind en clair et bind authentifié facultatif."
+weight: 250
+---
+
+Le vérificateur **LDAP** sonde le déploiement LDAP d'un domaine de bout en bout. À partir de la découverte SRV (`_ldap._tcp`, `_ldaps._tcp`), il teste l'accessibilité de chaque point d'accès, confirme qu'un canal chiffré est disponible (StartTLS selon la RFC 2830 ou TLS implicite sur le port 636), introspecte le RootDSE, recherche une divulgation d'information anonyme, vérifie que l'annuaire refuse les binds en clair et, lorsque des identifiants sont fournis, effectue un bind authentifié sur TLS avec un test de lecture facultatif sur un DN de base.
+
+Il s'agit d'un vérificateur de **niveau service** : il cible un service *LDAP* (`abstract.LDAP`) publié sur un sous-domaine et se configure depuis l'onglet **Vérifications** de ce service. Pour chaque transport, il sonde `_ldap._tcp` (repli sur le port 389) et `_ldaps._tcp` (repli sur le port 636), en testant chaque adresse A/AAAA résolue par famille d'adresses.
+
+{{% notice style="info" title="La posture TLS est intégrée, pas dupliquée" %}}
+Le vérificateur LDAP confirme uniquement qu'une session TLS peut être établie, en enregistrant la version et l'algorithme négociés à titre de contexte. Chaque point d'accès sondé est publié comme entrée de découverte `tls.endpoint.v1` afin que le vérificateur TLS dédié puisse vérifier la chaîne de certificats, la correspondance du nom d'hôte et l'expiration. Ces constats sont réintégrés sur la page du service LDAP via la règle `ldap.tls_quality` : un certificat défectueux sur un point d'accès LDAP apparaît ici, et pas seulement dans une vue TLS distincte. Consultez {{< relref "/reference/checkers/tls" >}}.
+{{% /notice %}}
+
+## Ce qui est vérifié
+
+| Règle | Ce qui est vérifié | Gravité |
+|---|---|---|
+| `ldap.has_srv` | Les enregistrements SRV `_ldap._tcp` / `_ldaps._tcp` sont publiés et résolvables. | Avertissement |
+| `ldap.endpoint_reachable` | Chaque point d'accès LDAP découvert accepte une connexion TCP. | Critique |
+| `ldap.has_encrypted_transport` | Au moins un point d'accès accessible propose un canal chiffré (LDAPS ou StartTLS). | Critique |
+| `ldap.starttls_supported` | StartTLS est proposé et la bascule réussit sur chaque point d'accès LDAP en clair accessible. | Critique |
+| `ldap.ldaps_handshake` | La poignée de main TLS directe réussit sur chaque point d'accès LDAPS. | Critique |
+| `ldap.starttls_on_ldaps` | Signale les serveurs qui annoncent inutilement StartTLS sur le port LDAPS à TLS implicite. | Info |
+| `ldap.ipv6_reachable` | Au moins un point d'accès est accessible en IPv6. | Info |
+| `ldap.refuses_plain_bind` | L'annuaire refuse l'authentification sur un canal en clair (`confidentialityRequired`, resultCode 13, selon la RFC 4513 §5.1.2). | Critique |
+| `ldap.anonymous_search_blocked` | Signale les annuaires qui autorisent une recherche `baseObject` anonyme du contexte de nommage (divulgation d'information). | Avertissement |
+| `ldap.rootdse_readable` | Le RootDSE est lisible sur TLS et annonce des contextes de nommage. | Avertissement |
+| `ldap.sasl_mechanisms` | Examine `supportedSASLMechanisms` : présence de mécanismes forts (SCRAM-*, EXTERNAL, GSSAPI), absence de mécanismes équivalents à un mot de passe (PLAIN/LOGIN seuls). | Avertissement |
+| `ldap.protocol_version` | Signale les serveurs qui annoncent encore le protocole LDAPv2 déprécié. | Avertissement |
+| `ldap.bind_credentials` | Les identifiants de bind fournis sont acceptés par l'annuaire (ne s'exécute que si `bind_dn` est défini). | Critique |
+| `ldap.base_dn_read` | Le compte authentifié peut lire le DN de base fourni (ne s'exécute que si `base_dn` est défini et que le bind a réussi). | Critique |
+| `ldap.tls_quality` | Réintègre les constats du vérificateur TLS aval (chaîne de certificats, correspondance du nom d'hôte, expiration) sur le service LDAP. | Critique |
+
+Le rapport HTML commence par les défaillances les plus courantes et inclut une remédiation propre à chaque serveur (`olcSecurity` sous OpenLDAP, `require_tls` sous 389-ds...) : aucun point d'accès chiffré accessible, StartTLS absent sur 389, une poignée de main StartTLS qui échoue, un bind en clair accepté sur 389, une poignée de main LDAPS qui échoue, une recherche anonyme exposant le DIT, un SASL limité à PLAIN/LOGIN, un LDAPv2 résiduel, et des identifiants de bind rejetés.
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Domaine | Le domaine de l'annuaire (renseigné automatiquement depuis la portée du service). Obligatoire. | *(auto)* |
+| Délai d'attente par point d'accès (secondes) | Délai de connexion/sonde pour chaque point d'accès. | `10` |
+| Bind DN | Facultatif. DN avec lequel se connecter ; utilisé uniquement si un mot de passe de bind est aussi défini, et seulement sur un canal protégé par TLS. | *(vide)* |
+| Mot de passe de bind | Facultatif, secret. Le mot de passe n'est pas conservé dans la charge d'observation et n'est jamais transmis en clair. | *(vide)* |
+| DN de base (test de lecture) | Facultatif. Après un bind réussi, une recherche `baseObject` sur ce DN confirme que le compte dispose d'un accès en lecture. Repli sur une recherche `baseObject` anonyme si aucun bind DN n'est fourni. | *(vide)* |
+
+## Dans happyDomain
+
+Activez le vérificateur LDAP depuis l'onglet **Vérifications** d'un service LDAP. Le domaine est renseigné automatiquement ; fournissez un bind DN et un mot de passe uniquement si vous souhaitez exécuter les tests de bind authentifié et de lecture du DN de base. Consultez {{< relref "/pages/checks" >}} pour le fonctionnement complet, et {{< relref "/reference/checkers/tls" >}} pour la posture des certificats de ces mêmes points d'accès.

content/reference/checkers/legacy-records.en.md

@@ -0,0 +1,35 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Legacy records
+description: "Scans a zone for DNS record types deprecated by the IETF and reports each one with its RFC reference and a migration suggestion."
+weight: 330
+---
+
+The **Legacy DNS record types** checker scans a zone for record types the IETF has deprecated, and reports every occurrence with the relevant RFC reference and a concrete migration suggestion. Deprecated types clutter a zone and, in a few cases, are silently ignored by modern resolvers — so cleaning them up keeps the zone both tidy and unambiguous.
+
+This is a **zone-level** checker: it walks every service in the working zone in a single pass and consolidates findings by record type, so the report shows one picture rather than one result per record.
+
+## What it checks
+
+A single rule, `legacy_records`, inspects each orphan record body for a deprecated type and groups the findings by severity. The default rule status is critical (the worst severity present bubbles to the top of the report).
+
+| Severity | Record types | Why |
+|----------|--------------|-----|
+| Critical | `KEY`, `SIG`, `NXT` | RFC 3755: superseded by DNSKEY / RRSIG / NSEC; modern validators ignore them. |
+| Warning | `SPF`, `A6`, `MD`, `MF` | RFC 7208 / RFC 6563 / RFC 973: replaced by TXT, AAAA, MX. |
+| Info | `WKS`, `MB`, `MG`, `MR`, `MINFO`, `NULL`, `GPOS`, `NSAP`, `NSAP-PTR`, `X25`, `ISDN`, `RT`, `ATMA`, `EID`, `NIMLOC`, `SINK`, `NINFO`, `RKEY` | Experimental or historical (RFC 1035, 1183, 1706, 1712…); safe to delete. |
+
+For each detected type the report names every owner where it appears, the RFC reason, the suggested replacement, and a concrete "how to fix" instruction. A clean zone produces a single OK state with the scan count; parse errors encountered during the scan are surfaced in a separate "skipped" section so a silent skip never masquerades as a clean pass.
+
+{{% notice style="info" title="The SPF record type, not the SPF policy" %}}
+The `SPF` *record type* (RFC 4408) was deprecated by RFC 7208 in favour of publishing the SPF policy in a `TXT` record. This checker flags the obsolete `SPF` record type, not your SPF policy itself — which remains valid and necessary when published as a `TXT` record.
+{{% /notice %}}
+
+## Options
+
+This checker has no user-tunable options. The domain name and zone content are filled in automatically.
+
+## In happyDomain
+
+Enable this checker on the domain from the {{< relref "/pages/checks" >}} view; it runs over the whole zone in a single pass and needs no configuration. Use its findings as a clean-up checklist: each card tells you which record type to remove and what, if anything, to publish instead.

content/reference/checkers/legacy-records.fr.md

@@ -0,0 +1,35 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Enregistrements obsolètes
+description: "Analyse une zone à la recherche de types d'enregistrements DNS dépréciés par l'IETF et signale chacun avec sa référence RFC et une suggestion de migration."
+weight: 330
+---
+
+Le vérificateur **Types d'enregistrements DNS obsolètes** analyse une zone à la recherche de types d'enregistrements dépréciés par l'IETF, et signale chaque occurrence avec la référence RFC pertinente et une suggestion de migration concrète. Les types dépréciés encombrent une zone et, dans quelques cas, sont silencieusement ignorés par les résolveurs modernes : les nettoyer garde la zone à la fois propre et sans ambiguïté.
+
+Il s'agit d'un vérificateur de **niveau zone** : il parcourt chaque service de la zone de travail en une seule passe et consolide les constats par type d'enregistrement, afin que le rapport présente une vue d'ensemble plutôt qu'un résultat par enregistrement.
+
+## Ce qui est vérifié
+
+Une seule règle, `legacy_records`, inspecte le corps de chaque enregistrement orphelin à la recherche d'un type déprécié et regroupe les constats par sévérité. Le statut par défaut de la règle est critique (la pire sévérité présente remonte en tête du rapport).
+
+| Sévérité | Types d'enregistrement | Pourquoi |
+|----------|------------------------|----------|
+| Critique | `KEY`, `SIG`, `NXT` | RFC 3755 : remplacés par DNSKEY / RRSIG / NSEC ; les validateurs modernes les ignorent. |
+| Avertissement | `SPF`, `A6`, `MD`, `MF` | RFC 7208 / RFC 6563 / RFC 973 : remplacés par TXT, AAAA, MX. |
+| Info | `WKS`, `MB`, `MG`, `MR`, `MINFO`, `NULL`, `GPOS`, `NSAP`, `NSAP-PTR`, `X25`, `ISDN`, `RT`, `ATMA`, `EID`, `NIMLOC`, `SINK`, `NINFO`, `RKEY` | Expérimentaux ou historiques (RFC 1035, 1183, 1706, 1712, etc.) ; suppression sans danger. |
+
+Pour chaque type détecté, le rapport nomme chaque propriétaire où il apparaît, la raison RFC, le remplacement suggéré et une instruction concrète de correction. Une zone propre produit un unique état OK avec le décompte de l'analyse ; les erreurs d'analyse rencontrées pendant le balayage sont exposées dans une section « ignorés » distincte, afin qu'un saut silencieux ne se fasse jamais passer pour un passage propre.
+
+{{% notice style="info" title="Le type d'enregistrement SPF, pas la politique SPF" %}}
+Le *type d'enregistrement* `SPF` (RFC 4408) a été déprécié par la RFC 7208 au profit de la publication de la politique SPF dans un enregistrement `TXT`. Ce vérificateur signale le type d'enregistrement `SPF` obsolète, et non votre politique SPF elle-même, qui reste valide et nécessaire lorsqu'elle est publiée dans un enregistrement `TXT`.
+{{% /notice %}}
+
+## Options
+
+Ce vérificateur n'a aucune option réglable par l'utilisateur. Le nom de domaine et le contenu de la zone sont renseignés automatiquement.
+
+## Dans happyDomain
+
+Activez ce vérificateur sur le domaine depuis la vue {{< relref "/pages/checks" >}} ; il s'exécute sur l'ensemble de la zone en une seule passe et ne nécessite aucune configuration. Utilisez ses constats comme une liste de nettoyage : chaque carte vous indique le type d'enregistrement à supprimer et ce qu'il convient, le cas échéant, de publier à la place.

content/reference/checkers/matrix-federation.en.md

@@ -0,0 +1,34 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Matrix federation
+description: "Verifies that a Matrix homeserver federates correctly, using the Matrix Federation Tester."
+weight: 300
+---
+
+The **Matrix federation** checker verifies that a Matrix homeserver is correctly set up to federate with the rest of the Matrix network. It delegates the actual probing to a [Matrix Federation Tester](https://federationtester.matrix.org/) instance, stores the full report as an observation, and renders a rich HTML summary covering connections, certificates, well-known delegation and DNS/SRV resolution.
+
+This is a **service-level** checker. It applies to services of type **Matrix** (instant messaging) and is configured from that service's own **Checks** tab.
+
+## What it checks
+
+| Rule | What it verifies | Severity |
+|------|------------------|----------|
+| `matrix.connection_reachable` | Every discovered federation endpoint accepts an inbound connection. | Critical |
+| `matrix.federation_ok` | The overall federation status reported by the Matrix Federation Tester. | Critical |
+| `matrix.srv_records` | The Matrix SRV lookup (`_matrix-fed._tcp` / `_matrix._tcp`) succeeded or was legitimately skipped. | Critical |
+| `matrix.tls_checks` | The TLS posture on every reachable federation endpoint (certificate chain, hostname, Ed25519 key). | Critical |
+| `matrix.version` | The homeserver answers `/_matrix/federation/v1/version` with its name and version. | Warning |
+| `matrix.well_known` | `/.well-known/matrix/server`, when published, is valid and points at the declared `server_name`. | Critical |
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Matrix domain | The Matrix `server_name` to test. Filled in automatically from the service. | `matrix.org` |
+
+An additional **admin-level** option, `federationTesterServer`, sets the URL template of the Federation Tester instance to query. It is configured by the happyDomain operator, not per check, and defaults to `https://federationtester.matrix.org/api/report?server_name=%s`.
+
+## In happyDomain
+
+Enable this checker from the **Checks** tab of a Matrix service; see {{< relref "/pages/checks" >}} for how to configure and schedule checks. The Matrix domain is filled in automatically from the service.

content/reference/checkers/matrix-federation.fr.md

@@ -0,0 +1,34 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Fédération Matrix
+description: "Vérifie qu'un serveur Matrix fédère correctement, à l'aide du Matrix Federation Tester."
+weight: 300
+---
+
+Le vérificateur **Fédération Matrix** vérifie qu'un serveur Matrix (homeserver) est correctement configuré pour fédérer avec le reste du réseau Matrix. Il délègue le sondage proprement dit à une instance du [Matrix Federation Tester](https://federationtester.matrix.org/), stocke le rapport complet sous forme d'observation, et produit un résumé HTML détaillé couvrant les connexions, les certificats, la délégation well-known et la résolution DNS/SRV.
+
+Il s'agit d'un vérificateur de **niveau service**. Il s'applique aux services de type **Matrix** (messagerie instantanée) et se configure depuis l'onglet **Vérifications** de ce service.
+
+## Ce qui est vérifié
+
+| Règle | Ce qu'elle vérifie | Sévérité |
+|-------|--------------------|----------|
+| `matrix.connection_reachable` | Chaque point d'accès de fédération découvert accepte une connexion entrante. | Critique |
+| `matrix.federation_ok` | Le statut global de fédération rapporté par le Matrix Federation Tester. | Critique |
+| `matrix.srv_records` | La résolution SRV Matrix (`_matrix-fed._tcp` / `_matrix._tcp`) a réussi ou a été légitimement ignorée. | Critique |
+| `matrix.tls_checks` | La posture TLS sur chaque point d'accès de fédération joignable (chaîne de certificats, nom d'hôte, clé Ed25519). | Critique |
+| `matrix.version` | Le serveur répond à `/_matrix/federation/v1/version` avec son nom et sa version. | Avertissement |
+| `matrix.well_known` | `/.well-known/matrix/server`, lorsqu'il est publié, est valide et pointe vers le `server_name` déclaré. | Critique |
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Domaine Matrix | Le `server_name` Matrix à tester. Renseigné automatiquement depuis le service. | `matrix.org` |
+
+Une option supplémentaire de **niveau administrateur**, `federationTesterServer`, définit le modèle d'URL de l'instance du Federation Tester à interroger. Elle est configurée par l'opérateur happyDomain, et non par vérification, et vaut par défaut `https://federationtester.matrix.org/api/report?server_name=%s`.
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis l'onglet **Vérifications** d'un service Matrix ; consultez {{< relref "/pages/checks" >}} pour savoir comment configurer et planifier les vérifications. Le domaine Matrix est renseigné automatiquement depuis le service.

content/reference/checkers/ns-restrictions.en.md

@@ -0,0 +1,36 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Name-server restrictions
+description: "Probes every authoritative name server of a zone to confirm it is properly locked down: zone transfers refused, no open recursion, and RFC 8482 handling of ANY."
+weight: 90
+---
+
+The **Name-server restrictions** checker verifies that the authoritative name servers of a zone are properly locked down. For each declared name server it resolves the host name, then runs a set of DNS probes against every returned IPv4 and IPv6 address (IPv6 targets are skipped gracefully when the host has no IPv6 connectivity). The goal is to catch common misconfigurations that leak data or turn a name server into an abuse vector: open zone transfers, open recursion, and unbounded `ANY` responses.
+
+This checker is **service-level**: it targets an *Origin* or *NS-only Origin* service (`abstract.Origin`, `abstract.NSOnlyOrigin`) and is configured from that service's **Checks** tab.
+
+## What it checks
+
+Each rule emits one finding per probed name-server address, with a stable `code`.
+
+| Rule | Verifies | Severity on failure |
+|---|---|---|
+| `ns_resolution` | Every NS host name declared in the delegation resolves to at least one IP address. | Critical |
+| `ns_axfr_refused` | `AXFR` zone transfers are refused by every authoritative name server. | Critical |
+| `ns_ixfr_refused` | `IXFR` zone transfers are refused by every authoritative name server. | Warning |
+| `ns_no_recursion` | Authoritative name servers do not advertise recursion (RA bit unset). | Warning |
+| `ns_any_handled` | `ANY` queries are handled per RFC 8482 (HINFO or a minimal answer rather than the full zone contents). | Warning |
+| `ns_is_authoritative` | Name servers answer authoritatively (AA bit set) for the zone. | Info |
+
+{{% notice style="info" title="Why these matter" %}}
+An open `AXFR` lets anyone download the entire zone, exposing your internal naming. Open recursion turns your authoritative server into an amplification relay and cache-poisoning target. Unbounded `ANY` responses are a classic amplification vector that RFC 8482 was written to neutralise.
+{{% /notice %}}
+
+## Options
+
+This checker has no user-tunable options: it runs a fixed set of probes against each resolved name-server address.
+
+## In happyDomain
+
+Enable the Name-server restrictions checker from the **Checks** tab of an Origin service. See {{< relref "/pages/checks" >}} for the full workflow. For the broader health and agreement of those same authoritative servers, see {{< relref "/reference/checkers/authoritative-consistency" >}}.

content/reference/checkers/ns-restrictions.fr.md

@@ -0,0 +1,36 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Restrictions des serveurs de noms
+description: "Sonde chaque serveur faisant autorité d'une zone pour confirmer qu'il est correctement verrouillé : transferts de zone refusés, pas de récursion ouverte, gestion d'ANY conforme à la RFC 8482."
+weight: 90
+---
+
+Le vérificateur **Restrictions des serveurs de noms** vérifie que les serveurs faisant autorité d'une zone sont correctement verrouillés. Pour chaque serveur de noms déclaré, il résout le nom d'hôte puis lance une série de sondes DNS contre chaque adresse IPv4 et IPv6 renvoyée (les cibles IPv6 sont ignorées sans erreur lorsque l'hôte n'a pas de connectivité IPv6). L'objectif est de détecter les erreurs de configuration courantes qui divulguent des données ou transforment un serveur de noms en vecteur d'abus : transferts de zone ouverts, récursion ouverte et réponses `ANY` non bornées.
+
+Ce vérificateur s'applique au niveau du **service** : il cible un service d'origine ou d'origine NS-seule (`abstract.Origin`, `abstract.NSOnlyOrigin`) et se configure depuis l'onglet **Vérifications** de ce service.
+
+## Ce qu'il vérifie
+
+Chaque règle émet un constat par adresse de serveur de noms sondée, avec un `code` stable.
+
+| Règle | Vérifie | Sévérité en cas d'échec |
+|---|---|---|
+| `ns_resolution` | Chaque nom d'hôte NS déclaré dans la délégation se résout en au moins une adresse IP. | Critique |
+| `ns_axfr_refused` | Les transferts de zone `AXFR` sont refusés par chaque serveur faisant autorité. | Critique |
+| `ns_ixfr_refused` | Les transferts de zone `IXFR` sont refusés par chaque serveur faisant autorité. | Avertissement |
+| `ns_no_recursion` | Les serveurs faisant autorité n'annoncent pas la récursion (bit RA non positionné). | Avertissement |
+| `ns_any_handled` | Les requêtes `ANY` sont traitées conformément à la RFC 8482 (HINFO ou réponse minimale plutôt que le contenu complet de la zone). | Avertissement |
+| `ns_is_authoritative` | Les serveurs de noms répondent de façon autoritaire (bit AA positionné) pour la zone. | Info |
+
+{{% notice style="info" title="Pourquoi c'est important" %}}
+Un `AXFR` ouvert permet à quiconque de télécharger la zone entière, exposant votre nommage interne. La récursion ouverte transforme votre serveur faisant autorité en relais d'amplification et en cible d'empoisonnement de cache. Les réponses `ANY` non bornées constituent un vecteur d'amplification classique que la RFC 8482 a été écrite pour neutraliser.
+{{% /notice %}}
+
+## Options
+
+Ce vérificateur n'expose aucune option réglable : il exécute un ensemble fixe de sondes contre chaque adresse de serveur de noms résolue.
+
+## Dans happyDomain
+
+Activez le vérificateur Restrictions des serveurs de noms depuis l'onglet **Vérifications** d'un service d'origine. Consultez {{< relref "/pages/checks" >}} pour le déroulé complet. Pour la santé et l'accord plus larges de ces mêmes serveurs faisant autorité, voyez {{< relref "/reference/checkers/authoritative-consistency" >}}.

content/reference/checkers/ping.en.md

@@ -0,0 +1,34 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Ping
+description: "Sends ICMP probes to every address of a service and reports reachability, average round-trip time, packet loss, and IPv6 coverage."
+weight: 190
+---
+
+The **Ping (ICMP)** checker measures basic network reachability for the addresses behind a service. It sends a small number of ICMP echo requests to each `A`/`AAAA` address and reports whether the target replied, its average round-trip time (RTT), the observed packet-loss ratio, and whether at least one IPv6 address answered.
+
+**Scope:** service-level. It attaches to services of type `abstract.Server` (a subdomain that publishes `A`/`AAAA` records) and is configured from that service's **Checks** tab.
+
+## What it checks
+
+| Rule | Verifies | Warn / Critical conditions |
+|------|----------|----------------------------|
+| `ping.reachable` | Every target replied to at least one ICMP probe. | Critical when a target never replies. |
+| `ping.rtt` | Average round-trip time stays within thresholds. | Warning above the warning RTT, Critical above the critical RTT. |
+| `ping.ipv6_reachable` | At least one IPv6 target replied to an ICMP probe. | Warning when no IPv6 address answers. |
+| `ping.packet_loss` | Packet-loss ratio stays within thresholds. | Warning above the warning loss ratio, Critical above the critical loss ratio. |
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Warning RTT threshold (ms) (`warningRTT`) | Average RTT above which the check warns. | 100 |
+| Critical RTT threshold (ms) (`criticalRTT`) | Average RTT above which the check is critical. | 500 |
+| Warning packet loss threshold (%) (`warningPacketLoss`) | Packet-loss ratio above which the check warns. | 10 |
+| Critical packet loss threshold (%) (`criticalPacketLoss`) | Packet-loss ratio above which the check is critical. | 50 |
+| Number of pings to send (`count`) | ICMP echo requests sent per target. | 5 |
+
+## In happyDomain
+
+This is a service-level checker: configure it from the **Checks** tab of the *Server* service on the relevant subdomain. Its short default interval makes it well suited to lightweight, frequent reachability monitoring. For the general workflow of configuring and reading checks, see {{< relref "/pages/checks" >}}.

content/reference/checkers/ping.fr.md

@@ -0,0 +1,34 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Ping
+description: "Envoie des sondes ICMP à chaque adresse d'un service et rapporte l'accessibilité, le temps d'aller-retour moyen, la perte de paquets et la couverture IPv6."
+weight: 190
+---
+
+Le vérificateur **Ping (ICMP)** mesure l'accessibilité réseau de base des adresses derrière un service. Il envoie un petit nombre de requêtes echo ICMP à chaque adresse `A`/`AAAA` et rapporte si la cible a répondu, son temps d'aller-retour moyen (RTT), le taux de perte de paquets observé, et si au moins une adresse IPv6 a répondu.
+
+**Portée** : niveau service. Il s'attache aux services de type `abstract.Server` (un sous-domaine publiant des enregistrements `A`/`AAAA`) et se configure depuis l'onglet **Vérifications** de ce service.
+
+## Ce qu'il vérifie
+
+| Règle | Vérifie | Conditions avertissement / critique |
+|-------|---------|-------------------------------------|
+| `ping.reachable` | Chaque cible a répondu à au moins une sonde ICMP. | Critique lorsqu'une cible ne répond jamais. |
+| `ping.rtt` | Le temps d'aller-retour moyen reste dans les seuils. | Avertissement au-dessus du RTT d'avertissement, critique au-dessus du RTT critique. |
+| `ping.ipv6_reachable` | Au moins une cible IPv6 a répondu à une sonde ICMP. | Avertissement quand aucune adresse IPv6 ne répond. |
+| `ping.packet_loss` | Le taux de perte de paquets reste dans les seuils. | Avertissement au-dessus du taux d'avertissement, critique au-dessus du taux critique. |
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Seuil d'avertissement RTT (ms) (`warningRTT`) | RTT moyen au-dessus duquel la vérification avertit. | 100 |
+| Seuil critique RTT (ms) (`criticalRTT`) | RTT moyen au-dessus duquel la vérification est critique. | 500 |
+| Seuil d'avertissement de perte de paquets (%) (`warningPacketLoss`) | Taux de perte au-dessus duquel la vérification avertit. | 10 |
+| Seuil critique de perte de paquets (%) (`criticalPacketLoss`) | Taux de perte au-dessus duquel la vérification est critique. | 50 |
+| Nombre de pings à envoyer (`count`) | Requêtes echo ICMP envoyées par cible. | 5 |
+
+## Dans happyDomain
+
+C'est un vérificateur de niveau service : configurez-le depuis l'onglet **Vérifications** du service « Serveur » sur le sous-domaine concerné. Son intervalle par défaut court le rend adapté à une surveillance d'accessibilité légère et fréquente. Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir {{< relref "/pages/checks" >}}.

content/reference/checkers/ptr.en.md

@@ -0,0 +1,52 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: PTR records
+description: "Validates reverse DNS for an IP: PTR presence, target syntax, forward resolution and Forward-Confirmed Reverse DNS (FCrDNS)."
+weight: 120
+---
+
+The **PTR / Reverse DNS** checker verifies that an IP address has a correct, usable reverse-DNS record. A PTR maps an IP back to a hostname; mail servers, SSH daemons and many logging tools rely on it, and a missing or inconsistent PTR is one of the most common reasons outgoing mail is rejected.
+
+This is a **service-level** checker: it runs on a `PTR` service and is configured from that service's own **Checks** tab. It locates the reverse zone (under `in-addr.arpa` or `ip6.arpa`), queries the authoritative servers, and inspects what they actually serve — both for IPv4 and IPv6 addresses.
+
+## What it checks
+
+The checker runs a chain of rules, from structural sanity through query success to target hygiene and Forward-Confirmed Reverse DNS (FCrDNS).
+
+| Rule | What it verifies | Severity |
+|------|------------------|----------|
+| `ptr.in_reverse_arpa` | The PTR owner lies under `in-addr.arpa` or `ip6.arpa`. | Critical |
+| `ptr.owner_decodable` | The reverse-arpa owner name decodes back to an IP address. | Critical |
+| `ptr.reverse_zone_located` | The reverse zone serving the owner can be located (SOA found). | Critical |
+| `ptr.query_succeeded` | The PTR query returns NOERROR from the authoritative servers. | Critical |
+| `ptr.record_present` | At least one PTR record is served at the owner name. | Critical |
+| `ptr.single_record` | Flags more than one PTR on the same IP (RFC 1912 §2.1 recommends exactly one). | Warning |
+| `ptr.declared_match` | The PTR target served authoritatively matches the target declared in happyDomain. | Critical |
+| `ptr.target_syntax_valid` | The PTR target is a syntactically valid hostname (RFC 952/1123). | Critical |
+| `ptr.generic_hostname` | Flags PTR targets that embed the IP or match common ISP auto-generated patterns. | Warning |
+| `ptr.target_resolves` | The PTR target resolves to at least one A or AAAA record. | Critical / Warning |
+| `ptr.fcrdns_match` | The PTR target's A/AAAA resolves back to the original IP (FCrDNS). | Critical / Warning |
+| `ptr.ipv6` | Reports whether the PTR concerns an IPv6 (`ip6.arpa`) address, and that a PTR is present for it. | Critical |
+| `ptr.ttl_hygiene` | The PTR TTL is at or above the configured minimum. | Warning |
+
+The `ptr.target_resolves` and `ptr.fcrdns_match` rules are critical by default but drop to a warning when **Require forward-confirmed reverse DNS** is turned off.
+
+{{% notice style="info" title="FCrDNS, the round-trip rule" %}}
+Forward-Confirmed Reverse DNS means the chain rounds back to itself: the IP's PTR points to a hostname, and that hostname's A/AAAA includes the original IP. Mail servers reject connections from IPs that fail this round-trip, so leave **Require forward-confirmed reverse DNS** enabled for any host that sends mail.
+{{% /notice %}}
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Require forward-confirmed reverse DNS (FCrDNS) | When enabled, a PTR whose target does not resolve back to the original IP is critical; otherwise a warning. | `true` |
+| Allow multiple PTR records on the same IP | When disabled, more than one PTR at the same owner is flagged as a warning (RFC 1912 §2.1). | `false` |
+| Minimum PTR TTL (seconds) | PTR records with a TTL below this threshold are flagged as a warning. | `300` |
+| Flag generic-looking PTR hostnames | When enabled, PTR targets embedding the dotted IP or matching common ISP auto-generated patterns warn. | `true` |
+
+## In happyDomain
+
+Add the PTR service to the subdomain holding the reverse record, then enable this checker from that service's **Checks** tab. See {{< relref "/pages/checks" >}} for configuring and scheduling checks. The reverse zone, the PTR record and the declared target are filled in automatically from the service.
+
+For the forward side of alias and hostname resolution, see the related {{< relref "/reference/checkers/alias" >}} checker.

content/reference/checkers/ptr.fr.md

@@ -0,0 +1,52 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Enregistrements PTR
+description: "Valide le DNS inverse d'une adresse IP : présence du PTR, syntaxe de la cible, résolution directe et Forward-Confirmed Reverse DNS (FCrDNS)."
+weight: 120
+---
+
+Le vérificateur **PTR / DNS inverse** vérifie qu'une adresse IP dispose d'un enregistrement de DNS inverse correct et exploitable. Un PTR associe une IP à un nom d'hôte ; les serveurs de messagerie, les démons SSH et de nombreux outils de journalisation s'appuient dessus, et un PTR absent ou incohérent est l'une des causes les plus fréquentes de rejet du courrier sortant.
+
+Il s'agit d'un vérificateur de **niveau service** : il s'exécute sur un service `PTR` et se configure depuis l'onglet **Vérifications** de ce service. Il localise la zone inverse (sous `in-addr.arpa` ou `ip6.arpa`), interroge les serveurs faisant autorité et inspecte ce qu'ils servent réellement, aussi bien pour les adresses IPv4 qu'IPv6.
+
+## Ce qui est vérifié
+
+Le vérificateur enchaîne une série de règles, de la cohérence structurelle au succès de la requête, puis à l'hygiène de la cible et au Forward-Confirmed Reverse DNS (FCrDNS).
+
+| Règle | Ce qui est vérifié | Sévérité |
+|-------|--------------------|----------|
+| `ptr.in_reverse_arpa` | Le propriétaire du PTR se trouve sous `in-addr.arpa` ou `ip6.arpa`. | Critique |
+| `ptr.owner_decodable` | Le nom du propriétaire en `.arpa` se décode bien en une adresse IP. | Critique |
+| `ptr.reverse_zone_located` | La zone inverse servant ce propriétaire peut être localisée (SOA trouvé). | Critique |
+| `ptr.query_succeeded` | La requête PTR renvoie NOERROR depuis les serveurs faisant autorité. | Critique |
+| `ptr.record_present` | Au moins un enregistrement PTR est servi au nom du propriétaire. | Critique |
+| `ptr.single_record` | Signale plusieurs PTR sur la même IP (la RFC 1912 §2.1 en recommande un seul). | Avertissement |
+| `ptr.declared_match` | La cible PTR servie fait autorité correspond à celle déclarée dans happyDomain. | Critique |
+| `ptr.target_syntax_valid` | La cible PTR est un nom d'hôte syntaxiquement valide (RFC 952/1123). | Critique |
+| `ptr.generic_hostname` | Signale les cibles PTR qui contiennent l'IP ou suivent un motif générique de FAI. | Avertissement |
+| `ptr.target_resolves` | La cible PTR se résout vers au moins un enregistrement A ou AAAA. | Critique / Avertissement |
+| `ptr.fcrdns_match` | Le A/AAAA de la cible PTR se résout de nouveau vers l'IP d'origine (FCrDNS). | Critique / Avertissement |
+| `ptr.ipv6` | Indique si le PTR concerne une adresse IPv6 (`ip6.arpa`) et qu'un PTR est présent pour elle. | Critique |
+| `ptr.ttl_hygiene` | Le TTL du PTR est supérieur ou égal au minimum configuré. | Avertissement |
+
+Les règles `ptr.target_resolves` et `ptr.fcrdns_match` sont critiques par défaut, mais passent en avertissement lorsque l'option **Exiger le Forward-Confirmed Reverse DNS** est désactivée.
+
+{{% notice style="info" title="Le FCrDNS, la règle de l'aller-retour" %}}
+Le Forward-Confirmed Reverse DNS signifie que la chaîne boucle sur elle-même : le PTR de l'IP pointe vers un nom d'hôte, et le A/AAAA de ce nom d'hôte inclut l'IP d'origine. Les serveurs de messagerie rejettent les connexions des IP qui échouent à cet aller-retour ; laissez donc **Exiger le Forward-Confirmed Reverse DNS** activé pour tout hôte qui envoie du courrier.
+{{% /notice %}}
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Exiger le Forward-Confirmed Reverse DNS (FCrDNS) | Lorsqu'activée, un PTR dont la cible ne se résout pas vers l'IP d'origine est critique ; sinon, c'est un avertissement. | `true` |
+| Autoriser plusieurs PTR sur la même IP | Lorsqu'elle est désactivée, plusieurs PTR au même propriétaire sont signalés comme avertissement (RFC 1912 §2.1). | `false` |
+| TTL minimal du PTR (secondes) | Les PTR dont le TTL est inférieur à ce seuil sont signalés comme avertissement. | `300` |
+| Signaler les noms d'hôte PTR génériques | Lorsqu'activée, les cibles PTR contenant l'IP en notation pointée ou suivant un motif générique de FAI déclenchent un avertissement. | `true` |
+
+## Dans happyDomain
+
+Ajoutez le service PTR au sous-domaine portant l'enregistrement inverse, puis activez ce vérificateur depuis l'onglet **Vérifications** de ce service. Consultez {{< relref "/pages/checks" >}} pour configurer et planifier les vérifications. La zone inverse, l'enregistrement PTR et la cible déclarée sont renseignés automatiquement à partir du service.
+
+Pour le versant direct de la résolution des alias et des noms d'hôte, voyez le vérificateur {{< relref "/reference/checkers/alias" >}}.

content/reference/checkers/resolver-propagation.en.md

@@ -0,0 +1,45 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Resolver propagation
+description: "Probes a worldwide catalog of public recursive resolvers across several transports and regions, then compares their answers to the zone's authoritative servers."
+weight: 100
+---
+
+The **Resolver propagation** checker measures how a zone is seen from the *outside*, across the public internet. It probes a curated catalog of public recursive resolvers (Cloudflare, Google, Quad9, OpenDNS, Yandex, regional ISPs and more) over several transports (UDP, TCP, DoT, DoH) and from multiple regions, then compares their answers both to each other and to the zone's authoritative name servers. This surfaces propagation gaps, regional splits, `SOA` serial drift, stale caches, DNSSEC validation failures, `SERVFAIL`/`NXDOMAIN` inconsistencies and resolver filtering.
+
+This checker is **service-level**: it targets an *Origin* or *NS-only Origin* service (`abstract.Origin`, `abstract.NSOnlyOrigin`) and is configured from that service's **Checks** tab.
+
+## What it checks
+
+| Finding code | What it checks | Severity |
+|---|---|---|
+| `resolver_propagation.selection` | The current option set selects at least one public resolver. | Critical |
+| `resolver_propagation.reachable` | At least one selected resolver answered a query. | Critical |
+| `resolver_propagation.latency` | Resolvers that are unreachable or whose average response time exceeds the threshold. | Warning |
+| `resolver_propagation.filtered_hit` | Filtered resolvers returning a different answer than the consensus (typical blocklist behaviour). | Info |
+| `resolver_propagation.consensus` | Public resolvers agree on a single answer for each probed RRset. | Warning |
+| `resolver_propagation.matches_authoritative` | The public consensus matches the answer served by the zone's authoritative servers. | Critical |
+| `resolver_propagation.nxdomain` | RRsets for which some resolvers return `NXDOMAIN` while others return `NOERROR`. | Critical |
+| `resolver_propagation.servfail` | RRsets for which any resolver returns `SERVFAIL` (usually DNSSEC or reachability failure). | Critical |
+| `resolver_propagation.regional_split` | Regions where every resolver agrees on an answer that differs from the global consensus. | Warning |
+| `resolver_propagation.serial_drift` | Disagreement on the `SOA` serial across unfiltered resolvers. | Warning |
+| `resolver_propagation.stale_cache` | Resolvers still serving an `SOA` serial below the one saved by happyDomain. | Info |
+| `resolver_propagation.dnssec` | Validating resolvers successfully validate the zone's DNSSEC chain. | Critical |
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| `recordTypes` | Comma-separated RR types to probe at every owner. Empty = derive from the working zone (SOA/NS at the apex plus the RR types actually defined on each owner). | _derived from zone_ |
+| `subdomains` | Comma-separated owner names to probe in addition to the apex (e.g. `www,mail,@`). Empty = apex only. | `www` |
+| `includeFiltered` | Probe filtering resolvers (malware/family/adblock). Their answers diverge by design; enable only when diagnosing a blocklist hit. | `false` |
+| `region` | Restrict to a region: `all`, `global`, `na`, `eu`, `asia`, `ru`, `me`. | `all` |
+| `transports` | Comma-separated transports to probe: `udp`, `tcp`, `dot`, `doh`. Encrypted transports are only used where published. | `udp` |
+| `resolverAllowlist` | Comma-separated resolver IDs or IPs to probe exclusively (e.g. `cloudflare,google,9.9.9.9`). Empty = catalog selection. | _(empty)_ |
+| `latencyThresholdMs` | Resolvers averaging above this value emit an info finding. | `500` |
+| `runTimeoutSeconds` | Hard wall-clock budget for one propagation run. Slower resolvers report as unreachable. | `30` |
+
+## In happyDomain
+
+Enable the Resolver propagation checker from the **Checks** tab of an Origin service. See {{< relref "/pages/checks" >}} for the full workflow. This checker is the outward-facing counterpart to {{< relref "/reference/checkers/authoritative-consistency" >}}, which examines the authoritative servers directly; running both gives you the picture from the origin and from the resolvers that query it.

content/reference/checkers/resolver-propagation.fr.md

@@ -0,0 +1,45 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Propagation chez les résolveurs
+description: "Sonde un catalogue mondial de résolveurs récursifs publics sur plusieurs transports et régions, puis compare leurs réponses aux serveurs faisant autorité de la zone."
+weight: 100
+---
+
+Le vérificateur **Propagation chez les résolveurs** mesure la façon dont une zone est vue depuis l'*extérieur*, à travers l'internet public. Il sonde un catalogue choisi de résolveurs récursifs publics (Cloudflare, Google, Quad9, OpenDNS, Yandex, FAI régionaux et autres) sur plusieurs transports (UDP, TCP, DoT, DoH) et depuis plusieurs régions, puis compare leurs réponses entre elles et avec celles des serveurs faisant autorité de la zone. Cela révèle les retards de propagation, les divergences régionales, les écarts de numéro de série `SOA`, les caches périmés, les échecs de validation DNSSEC, les incohérences `SERVFAIL`/`NXDOMAIN` et le filtrage par les résolveurs.
+
+Ce vérificateur s'applique au niveau du **service** : il cible un service d'origine ou d'origine NS-seule (`abstract.Origin`, `abstract.NSOnlyOrigin`) et se configure depuis l'onglet **Vérifications** de ce service.
+
+## Ce qu'il vérifie
+
+| Code de constat | Ce qui est vérifié | Sévérité |
+|---|---|---|
+| `resolver_propagation.selection` | Le jeu d'options courant sélectionne au moins un résolveur public. | Critique |
+| `resolver_propagation.reachable` | Au moins un résolveur sélectionné a répondu à une requête. | Critique |
+| `resolver_propagation.latency` | Résolveurs injoignables ou dont le temps de réponse moyen dépasse le seuil. | Avertissement |
+| `resolver_propagation.filtered_hit` | Résolveurs filtrants renvoyant une réponse différente du consensus (comportement typique d'une liste de blocage). | Info |
+| `resolver_propagation.consensus` | Les résolveurs publics s'accordent sur une réponse unique pour chaque RRset sondé. | Avertissement |
+| `resolver_propagation.matches_authoritative` | Le consensus public correspond à la réponse servie par les serveurs faisant autorité de la zone. | Critique |
+| `resolver_propagation.nxdomain` | RRset pour lesquels certains résolveurs renvoient `NXDOMAIN` quand d'autres renvoient `NOERROR`. | Critique |
+| `resolver_propagation.servfail` | RRset pour lesquels un résolveur renvoie `SERVFAIL` (généralement échec DNSSEC ou de joignabilité). | Critique |
+| `resolver_propagation.regional_split` | Régions où tous les résolveurs s'accordent sur une réponse différente du consensus mondial. | Avertissement |
+| `resolver_propagation.serial_drift` | Désaccord sur le numéro de série `SOA` parmi les résolveurs non filtrants. | Avertissement |
+| `resolver_propagation.stale_cache` | Résolveurs servant encore un numéro de série `SOA` inférieur à celui enregistré par happyDomain. | Info |
+| `resolver_propagation.dnssec` | Les résolveurs validants valident avec succès la chaîne DNSSEC de la zone. | Critique |
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| `recordTypes` | Types de RR à sonder à chaque propriétaire, séparés par des virgules. Vide : dérivés de la zone de travail (SOA/NS à l'apex plus les types de RR réellement définis sur chaque propriétaire). | _dérivé de la zone_ |
+| `subdomains` | Noms de propriétaires à sonder en plus de l'apex, séparés par des virgules (par exemple `www,mail,@`). Vide : apex seul. | `www` |
+| `includeFiltered` | Sonde les résolveurs filtrants (malware/famille/anti-pub). Leurs réponses divergent par conception ; n'activer que pour diagnostiquer un blocage. | `false` |
+| `region` | Restreint à une région : `all`, `global`, `na`, `eu`, `asia`, `ru`, `me`. | `all` |
+| `transports` | Transports à sonder, séparés par des virgules : `udp`, `tcp`, `dot`, `doh`. Les transports chiffrés ne sont utilisés que là où ils sont publiés. | `udp` |
+| `resolverAllowlist` | Identifiants ou IP de résolveurs à sonder exclusivement, séparés par des virgules (par exemple `cloudflare,google,9.9.9.9`). Vide : sélection du catalogue. | _(vide)_ |
+| `latencyThresholdMs` | Les résolveurs dont la moyenne dépasse cette valeur émettent un constat d'information. | `500` |
+| `runTimeoutSeconds` | Budget temps absolu pour une exécution de propagation. Les résolveurs plus lents sont signalés comme injoignables. | `30` |
+
+## Dans happyDomain
+
+Activez le vérificateur Propagation chez les résolveurs depuis l'onglet **Vérifications** d'un service d'origine. Consultez {{< relref "/pages/checks" >}} pour le déroulé complet. Ce vérificateur est le pendant tourné vers l'extérieur de {{< relref "/reference/checkers/authoritative-consistency" >}}, qui examine directement les serveurs faisant autorité ; exécuter les deux donne la vue depuis l'origine et depuis les résolveurs qui l'interrogent.

content/reference/checkers/reverse-zone.en.md

@@ -0,0 +1,43 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Reverse zone
+description: "Inspects the PTR records of an in-addr.arpa or ip6.arpa reverse zone for FCrDNS, target resolvability, hostname syntax, generic names and TTL hygiene."
+weight: 110
+---
+
+The **Reverse zone** checker inspects the `PTR` records of a reverse DNS zone (`in-addr.arpa` or `ip6.arpa`) and validates that they are well formed and consistent with forward DNS. It verifies Forward-Confirmed Reverse DNS (FCrDNS), that targets resolve and are syntactically valid host names, flags generic or auto-generated names and short TTLs, and catches multiple-`PTR`-per-IP violations (RFC 1912 §2.1). Correct reverse DNS matters in practice: mail servers and SSH endpoints routinely reject or downgrade connections from IPs without proper FCrDNS.
+
+This checker is **zone-level**: it operates on the full content of a reverse zone (it applies to the domain and reads the whole zone).
+
+## What it checks
+
+| Finding code | What it verifies | Severity |
+|---|---|---|
+| `reverse_zone.is_reverse_arpa` | The zone is under `in-addr.arpa` or `ip6.arpa`. | Critical |
+| `reverse_zone.has_ptrs` | The reverse zone declares at least one `PTR` record. | Warning |
+| `reverse_zone.fcrdns` | Every `PTR` target's `A`/`AAAA` round-trips back to the original IP (Forward-Confirmed Reverse DNS). | Critical |
+| `reverse_zone.target_resolves` | Every `PTR` target resolves to at least one `A` or `AAAA` record. | Critical |
+| `reverse_zone.single_ptr_per_ip` | Flags IPs with multiple `PTR` records (RFC 1912 §2.1 recommends exactly one). | Warning |
+| `reverse_zone.target_syntax` | Every `PTR` target is a syntactically valid host name. | Critical |
+| `reverse_zone.generic_hostname` | Flags `PTR` targets that embed the IP or match common ISP auto-generated patterns. | Warning |
+| `reverse_zone.ttl_hygiene` | Flags `PTR` records whose TTL is below the configured minimum. | Warning |
+| `reverse_zone.truncated` | Reports when the zone has more `PTR`s than the configured cap allows to inspect. | Info |
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| `requireForwardMatch` | When enabled, a `PTR` whose target does not resolve back to the original IP is critical (otherwise warning). Mail and SSH servers require FCrDNS. | `true` |
+| `allowMultiplePTR` | When disabled, more than one `PTR` at the same owner is reported as warning (RFC 1912 §2.1 recommends a single `PTR` per IP). | `false` |
+| `minTTL` | `PTR` records with a TTL below this threshold (in seconds) are flagged as warning. | `300` |
+| `flagGenericPTR` | When enabled, `PTR` targets that embed the dotted IP or match common ISP auto-generated patterns are flagged as warning. | `true` |
+| `maxPTRsToCheck` | Caps the number of `PTR` records inspected per run, protecting the checker against very large reverse zones. | `1024` |
+
+{{% notice style="info" title="Forward-Confirmed Reverse DNS" %}}
+FCrDNS means the `PTR` target, looked up forward, resolves back to the original IP address. A `PTR` that points to a host whose `A`/`AAAA` does not include that IP fails the round-trip and is treated as a misconfiguration by many mail and SSH servers.
+{{% /notice %}}
+
+## In happyDomain
+
+Enable the Reverse zone checker on a reverse (`in-addr.arpa` / `ip6.arpa`) domain from its **Checks** view. See {{< relref "/pages/checks" >}} for the full workflow.

content/reference/checkers/reverse-zone.fr.md

@@ -0,0 +1,43 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Zone inverse
+description: "Inspecte les enregistrements PTR d'une zone inverse in-addr.arpa ou ip6.arpa : FCrDNS, résolvabilité des cibles, syntaxe des noms, noms génériques et hygiène des TTL."
+weight: 110
+---
+
+Le vérificateur **Zone inverse** inspecte les enregistrements `PTR` d'une zone DNS inverse (`in-addr.arpa` ou `ip6.arpa`) et valide qu'ils sont bien formés et cohérents avec le DNS direct. Il vérifie le Forward-Confirmed Reverse DNS (FCrDNS), s'assure que les cibles se résolvent et sont des noms d'hôtes syntaxiquement valides, signale les noms génériques ou auto-générés et les TTL trop courts, et détecte les violations de plusieurs `PTR` par IP (RFC 1912 §2.1). Un DNS inverse correct compte en pratique : les serveurs de courrier et les points d'accès SSH rejettent ou dégradent régulièrement les connexions provenant d'IP sans FCrDNS valide.
+
+Ce vérificateur s'applique au niveau de la **zone** : il opère sur le contenu complet d'une zone inverse (il s'applique au domaine et lit l'intégralité de la zone).
+
+## Ce qu'il vérifie
+
+| Code de constat | Ce qui est vérifié | Sévérité |
+|---|---|---|
+| `reverse_zone.is_reverse_arpa` | La zone est sous `in-addr.arpa` ou `ip6.arpa`. | Critique |
+| `reverse_zone.has_ptrs` | La zone inverse déclare au moins un enregistrement `PTR`. | Avertissement |
+| `reverse_zone.fcrdns` | Le `A`/`AAAA` de chaque cible `PTR` revient bien à l'IP d'origine (Forward-Confirmed Reverse DNS). | Critique |
+| `reverse_zone.target_resolves` | Chaque cible `PTR` se résout en au moins un enregistrement `A` ou `AAAA`. | Critique |
+| `reverse_zone.single_ptr_per_ip` | Signale les IP ayant plusieurs `PTR` (la RFC 1912 §2.1 en recommande exactement un). | Avertissement |
+| `reverse_zone.target_syntax` | Chaque cible `PTR` est un nom d'hôte syntaxiquement valide. | Critique |
+| `reverse_zone.generic_hostname` | Signale les cibles `PTR` qui intègrent l'IP ou correspondent aux motifs auto-générés courants des FAI. | Avertissement |
+| `reverse_zone.ttl_hygiene` | Signale les `PTR` dont le TTL est inférieur au minimum configuré. | Avertissement |
+| `reverse_zone.truncated` | Signale lorsque la zone compte plus de `PTR` que le plafond configuré ne permet d'inspecter. | Info |
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| `requireForwardMatch` | Si activé, un `PTR` dont la cible ne revient pas à l'IP d'origine est critique (sinon avertissement). Les serveurs de courrier et SSH exigent le FCrDNS. | `true` |
+| `allowMultiplePTR` | Si désactivé, plus d'un `PTR` au même propriétaire est signalé en avertissement (la RFC 1912 §2.1 recommande un seul `PTR` par IP). | `false` |
+| `minTTL` | Les `PTR` dont le TTL est inférieur à ce seuil (en secondes) sont signalés en avertissement. | `300` |
+| `flagGenericPTR` | Si activé, les cibles `PTR` qui intègrent l'IP pointée ou correspondent aux motifs auto-générés courants des FAI sont signalées en avertissement. | `true` |
+| `maxPTRsToCheck` | Plafonne le nombre de `PTR` inspectés par exécution, protégeant le vérificateur contre les très grandes zones inverses. | `1024` |
+
+{{% notice style="info" title="Forward-Confirmed Reverse DNS" %}}
+Le FCrDNS signifie que la cible du `PTR`, résolue en direct, revient bien à l'adresse IP d'origine. Un `PTR` pointant vers un hôte dont le `A`/`AAAA` n'inclut pas cette IP échoue à l'aller-retour et est considéré comme une mauvaise configuration par de nombreux serveurs de courrier et SSH.
+{{% /notice %}}
+
+## Dans happyDomain
+
+Activez le vérificateur Zone inverse sur un domaine inverse (`in-addr.arpa` / `ip6.arpa`) depuis sa vue **Vérifications**. Consultez {{< relref "/pages/checks" >}} pour le déroulé complet.

content/reference/checkers/sip.en.md

@@ -0,0 +1,44 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: SIP
+description: "Probes a domain's SIP/VoIP deployment end-to-end: RFC 3263 NAPTR/SRV resolution, endpoint reachability over UDP/TCP/TLS, and a SIP OPTIONS ping with capability inspection."
+weight: 270
+---
+
+The **SIP** checker probes a domain's SIP/VoIP deployment from its DNS records, following RFC 3263 resolution: NAPTR → SRV (`_sip._udp`, `_sip._tcp`, `_sips._tcp`) → A/AAAA. It tests reachability on every resolved `target:port` over UDP, TCP and TLS, then sends a raw SIP `OPTIONS` ping and inspects the reply (status line, `Server`/`User-Agent`, advertised `Allow` methods, round-trip time).
+
+This checker is **service-level**: it targets a *SIP* service (`abstract.SIP`) published on a subdomain and is configured from that service's own **Checks** tab. When no SRV record is published, the checker falls back to `<domain>:5060` / `<domain>:5061`, with a visible info marker in the report.
+
+{{% notice style="info" title="TLS posture is folded in, not duplicated" %}}
+For the TLS handshake the checker uses `InsecureSkipVerify`: it confirms only that a TLS session can be established. Every `_sips._tcp` target is published as a `tls.endpoint.v1` discovery entry so the dedicated TLS checker can verify the certificate chain, hostname match, expiry and cipher posture. Those findings are folded back onto the SIP service page through the `sip.tls_quality` rule. See {{< relref "/reference/checkers/tls" >}}.
+{{% /notice %}}
+
+## What it checks
+
+| Rule | What it verifies | Severity |
+|---|---|---|
+| `sip.srv_present` | `_sip._udp` / `_sip._tcp` / `_sips._tcp` SRV records are published and resolvable. | Critical |
+| `sip.transport_diversity` | Modern SIP transports (TCP, and ideally TLS) are published alongside legacy UDP. | Warning |
+| `sip.srv_targets_resolvable` | Every SRV target resolves to at least one A or AAAA address. | Critical |
+| `sip.endpoint_reachable` | Every discovered SIP endpoint accepts a connection on its transport. | Critical |
+| `sip.options_response` | Every reachable SIP endpoint answers `OPTIONS` with a 2xx response. | Critical |
+| `sip.options_capabilities` | Reviews the `Allow` header advertised in `OPTIONS` replies (INVITE support, presence of `Allow`). | Warning |
+| `sip.ipv6_coverage` | At least one SIP endpoint is reachable over IPv6. | Info |
+| `sip.tls_quality` | Folds the downstream TLS checker findings (chain, hostname match, expiry) onto the SIP service. | Critical |
+
+The checker performs, in order: the NAPTR lookup (`SIP+D2U`, `SIP+D2T`, `SIPS+D2T`), the SRV lookup for the three transports (with the `5060`/`5061` fallback), A/AAAA resolution of every SRV target, TCP connect / UDP send / TLS handshake, and the SIP `OPTIONS` request with its status, headers and `Allow` parsed.
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| SIP domain | The domain to test (auto-filled from the service scope). Required. | *(auto)* |
+| Per-endpoint timeout (seconds) | Probe timeout for each endpoint. | `5` |
+| Probe `_sip._udp` | Whether to probe the UDP transport. Disable if UDP is firewalled or the checker host cannot send UDP. | `true` |
+| Probe `_sip._tcp` | Whether to probe the TCP transport. | `true` |
+| Probe `_sips._tcp` (TLS) | Whether to probe the TLS transport. | `true` |
+
+## In happyDomain
+
+Enable the SIP checker from the **Checks** tab of a SIP service. The domain is filled in automatically. See {{< relref "/pages/checks" >}} for the full workflow, and {{< relref "/reference/checkers/tls" >}} for the certificate posture of the `_sips._tcp` endpoints.

content/reference/checkers/sip.fr.md

@@ -0,0 +1,44 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: SIP
+description: "Sonde le déploiement SIP/VoIP d'un domaine de bout en bout : résolution NAPTR/SRV (RFC 3263), accessibilité des points d'accès en UDP/TCP/TLS et un ping SIP OPTIONS avec inspection des capacités."
+weight: 270
+---
+
+Le vérificateur **SIP** sonde le déploiement SIP/VoIP d'un domaine à partir de ses enregistrements DNS, en suivant la résolution de la RFC 3263 : NAPTR → SRV (`_sip._udp`, `_sip._tcp`, `_sips._tcp`) → A/AAAA. Il teste l'accessibilité de chaque `cible:port` résolue en UDP, TCP et TLS, puis envoie un ping SIP `OPTIONS` brut et inspecte la réponse (ligne de statut, `Server`/`User-Agent`, méthodes `Allow` annoncées, temps d'aller-retour).
+
+Il s'agit d'un vérificateur de **niveau service** : il cible un service *SIP* (`abstract.SIP`) publié sur un sous-domaine et se configure depuis l'onglet **Vérifications** de ce service. Lorsqu'aucun enregistrement SRV n'est publié, le vérificateur se rabat sur `<domaine>:5060` / `<domaine>:5061`, avec un marqueur d'information visible dans le rapport.
+
+{{% notice style="info" title="La posture TLS est intégrée, pas dupliquée" %}}
+Pour la poignée de main TLS, le vérificateur utilise `InsecureSkipVerify` : il confirme uniquement qu'une session TLS peut être établie. Chaque cible `_sips._tcp` est publiée comme entrée de découverte `tls.endpoint.v1` afin que le vérificateur TLS dédié puisse vérifier la chaîne de certificats, la correspondance du nom d'hôte, l'expiration et la posture des algorithmes. Ces constats sont réintégrés sur la page du service SIP via la règle `sip.tls_quality`. Consultez {{< relref "/reference/checkers/tls" >}}.
+{{% /notice %}}
+
+## Ce qui est vérifié
+
+| Règle | Ce qui est vérifié | Gravité |
+|---|---|---|
+| `sip.srv_present` | Les enregistrements SRV `_sip._udp` / `_sip._tcp` / `_sips._tcp` sont publiés et résolvables. | Critique |
+| `sip.transport_diversity` | Des transports SIP modernes (TCP, et idéalement TLS) sont publiés en plus de l'UDP historique. | Avertissement |
+| `sip.srv_targets_resolvable` | Chaque cible SRV se résout en au moins une adresse A ou AAAA. | Critique |
+| `sip.endpoint_reachable` | Chaque point d'accès SIP découvert accepte une connexion sur son transport. | Critique |
+| `sip.options_response` | Chaque point d'accès SIP accessible répond à `OPTIONS` par une réponse 2xx. | Critique |
+| `sip.options_capabilities` | Examine l'en-tête `Allow` annoncé dans les réponses `OPTIONS` (prise en charge d'INVITE, présence d'`Allow`). | Avertissement |
+| `sip.ipv6_coverage` | Au moins un point d'accès SIP est accessible en IPv6. | Info |
+| `sip.tls_quality` | Réintègre les constats du vérificateur TLS aval (chaîne, correspondance du nom d'hôte, expiration) sur le service SIP. | Critique |
+
+Le vérificateur effectue, dans l'ordre : la recherche NAPTR (`SIP+D2U`, `SIP+D2T`, `SIPS+D2T`), la recherche SRV pour les trois transports (avec le repli `5060`/`5061`), la résolution A/AAAA de chaque cible SRV, la connexion TCP / l'envoi UDP / la poignée de main TLS, et la requête SIP `OPTIONS` avec son statut, ses en-têtes et son `Allow` analysés.
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Domaine SIP | Le domaine à tester (renseigné automatiquement depuis la portée du service). Obligatoire. | *(auto)* |
+| Délai d'attente par point d'accès (secondes) | Délai de sonde pour chaque point d'accès. | `5` |
+| Sonder `_sip._udp` | Faut-il sonder le transport UDP. À désactiver si l'UDP est filtré ou si l'hôte du vérificateur ne peut pas émettre d'UDP. | `true` |
+| Sonder `_sip._tcp` | Faut-il sonder le transport TCP. | `true` |
+| Sonder `_sips._tcp` (TLS) | Faut-il sonder le transport TLS. | `true` |
+
+## Dans happyDomain
+
+Activez le vérificateur SIP depuis l'onglet **Vérifications** d'un service SIP. Le domaine est renseigné automatiquement. Consultez {{< relref "/pages/checks" >}} pour le fonctionnement complet, et {{< relref "/reference/checkers/tls" >}} pour la posture des certificats des points d'accès `_sips._tcp`.

content/reference/checkers/smtp.en.md

@@ -0,0 +1,52 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: SMTP
+description: "Probes every MX target of a domain on port 25 the way an operator would with swaks: TCP connect, banner, EHLO, STARTTLS, mail-transaction and open-relay probes, reverse DNS and IPv6 coverage."
+weight: 200
+---
+
+The **Inbound SMTP (MX posture)** checker exercises the *inbound* side of a domain's mail service. For every MX target of the zone it performs the live probes a human operator would run with `swaks` or `telnet … 25`: TCP connect, ESMTP banner and EHLO, STARTTLS negotiation, mail-transaction probes (null sender, postmaster, open-relay), reverse DNS / FCrDNS, extension inventory, and IPv4/IPv6 coverage. The result is an actionable HTML report.
+
+**Scope:** service-level. It attaches to services of type `svcs.MXs` (the DNS-level MX record set) and is configured from that service's **Checks** tab.
+
+The probe answers "can this domain *receive* mail correctly?". It does **not** test outbound deliverability (SPF/DKIM/DMARC alignment, spam scoring, blacklist status), which is the job of the {{< relref "/reference/checkers/happydeliver" >}} checker. Mail-transaction probes always stop at `RCPT` and emit `RSET`: no `DATA` is sent, so no mail is delivered.
+
+## What it checks
+
+| Rule | Verifies | Severity |
+|------|----------|----------|
+| `smtp.null_mx` | Reports whether the domain publishes a null MX (RFC 7505). | Info |
+| `smtp.mx_present` | The domain publishes at least one MX record (or a null MX). | Critical |
+| `smtp.mx_sanity` | Flags MX targets violating RFC 5321 § 5.1 (IP literals, CNAME chains, unresolved names). | Critical |
+| `smtp.endpoint_reachable` | Every MX endpoint accepts a TCP connection on port 25. | Critical |
+| `smtp.banner_sanity` | Every reachable endpoint emits a 220 SMTP greeting. | Critical |
+| `smtp.ehlo_supported` | Every endpoint accepts EHLO. | Critical |
+| `smtp.starttls_offered` | Every endpoint advertises the STARTTLS extension. | Critical |
+| `smtp.starttls_handshake` | The STARTTLS handshake succeeds wherever advertised. | Critical |
+| `smtp.auth_posture` | Flags endpoints advertising SMTP AUTH before STARTTLS (cleartext credentials). | Critical |
+| `smtp.reverse_dns` | Every endpoint has a matching PTR record (FCrDNS). | Warning |
+| `smtp.null_sender` | Endpoints accept the null sender `MAIL FROM:<>` (required for DSNs). | Critical |
+| `smtp.postmaster` | Endpoints accept `RCPT TO:<postmaster@domain>` (RFC 5321 § 4.5.1). | Critical |
+| `smtp.open_relay` | Flags endpoints that relay mail for recipients outside the tested domain. | Critical |
+| `smtp.extension_posture` | Reports ESMTP extension posture (PIPELINING, 8BITMIME). | Info |
+| `smtp.ipv6_reachable` | At least one MX endpoint is reachable over IPv6. | Info |
+| `smtp.tls_quality` | Folds downstream TLS findings (chain, hostname, expiry) onto SMTP. | Critical |
+
+Certificate posture itself is out of scope here: each MX target is published as a `tls.endpoint.v1` discovery entry (opportunistic STARTTLS), and the {{< relref "/reference/checkers/tls" >}} checker runs certificate analysis on the same connection. Its findings are folded back into the `smtp.tls_quality` rule and the HTML report.
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Domain (`domain`) | Domain to test. Auto-filled from the service. | (from service) |
+| Per-endpoint timeout (seconds) (`timeout`) | Per-endpoint connection timeout. | 12 |
+| EHLO hostname (`helo_name`) | Hostname announced in EHLO/HELO. Use a name that resolves and has a valid PTR. | `mx-checker.happydomain.org` |
+| Probe null sender (`test_null_sender`) | Probe `MAIL FROM:<>` (RFC 5321 DSN acceptance). | true |
+| Probe postmaster (`test_postmaster`) | Probe `RCPT TO:<postmaster@domain>` (RFC 5321 § 4.5.1). | true |
+| Probe open-relay posture (`test_open_relay`) | Probe a recipient outside the tested domain to detect open relays. | true |
+| Open-relay probe recipient (`test_probe_address`) | Mailbox (outside the tested domain) used for the open-relay probe. | `postmaster@example.com` |
+
+## In happyDomain
+
+This is a service-level checker: configure it from the **Checks** tab of the *E-Mail servers* (MX) service. To confirm that mail your domain *sends* lands in the inbox, pair it with the {{< relref "/reference/checkers/happydeliver" >}} checker. For the general workflow of configuring and reading checks, see {{< relref "/pages/checks" >}}.

content/reference/checkers/smtp.fr.md

@@ -0,0 +1,52 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: SMTP
+description: "Sonde chaque cible MX d'un domaine sur le port 25 comme le ferait un opérateur avec swaks : connexion TCP, bannière, EHLO, STARTTLS, transactions de messagerie et sonde de relais ouvert, DNS inverse et couverture IPv6."
+weight: 200
+---
+
+Le vérificateur **SMTP entrant (posture MX)** examine le côté *entrant* du service de messagerie d'un domaine. Pour chaque cible MX de la zone, il effectue les sondes en direct qu'un opérateur exécuterait avec `swaks` ou `telnet … 25` : connexion TCP, bannière ESMTP et EHLO, négociation STARTTLS, sondes de transaction (expéditeur nul, postmaster, relais ouvert), DNS inverse / FCrDNS, inventaire des extensions et couverture IPv4/IPv6. Le résultat est un rapport HTML exploitable.
+
+**Portée** : niveau service. Il s'attache aux services de type `svcs.MXs` (l'ensemble des enregistrements MX) et se configure depuis l'onglet **Vérifications** de ce service.
+
+La sonde répond à la question « ce domaine peut-il *recevoir* le courrier correctement ? ». Elle ne teste **pas** la délivrabilité sortante (alignement SPF/DKIM/DMARC, score anti-spam, statut de liste noire), ce qui est le rôle du vérificateur {{< relref "/reference/checkers/happydeliver" >}}. Les sondes de transaction s'arrêtent toujours à `RCPT` et émettent `RSET` : aucun `DATA` n'est envoyé, donc aucun message n'est délivré.
+
+## Ce qu'il vérifie
+
+| Règle | Vérifie | Sévérité |
+|-------|---------|----------|
+| `smtp.null_mx` | Indique si le domaine publie un MX nul (RFC 7505). | Info |
+| `smtp.mx_present` | Le domaine publie au moins un enregistrement MX (ou un MX nul). | Critique |
+| `smtp.mx_sanity` | Signale les cibles MX violant la RFC 5321 § 5.1 (littéraux IP, chaînes CNAME, noms non résolus). | Critique |
+| `smtp.endpoint_reachable` | Chaque point de terminaison MX accepte une connexion TCP sur le port 25. | Critique |
+| `smtp.banner_sanity` | Chaque point de terminaison joignable émet une salutation SMTP 220. | Critique |
+| `smtp.ehlo_supported` | Chaque point de terminaison accepte EHLO. | Critique |
+| `smtp.starttls_offered` | Chaque point de terminaison annonce l'extension STARTTLS. | Critique |
+| `smtp.starttls_handshake` | La poignée de main STARTTLS aboutit là où elle est annoncée. | Critique |
+| `smtp.auth_posture` | Signale les points de terminaison annonçant SMTP AUTH avant STARTTLS (identifiants en clair). | Critique |
+| `smtp.reverse_dns` | Chaque point de terminaison a un enregistrement PTR concordant (FCrDNS). | Avertissement |
+| `smtp.null_sender` | Les points de terminaison acceptent l'expéditeur nul `MAIL FROM:<>` (requis pour les DSN). | Critique |
+| `smtp.postmaster` | Les points de terminaison acceptent `RCPT TO:<postmaster@domaine>` (RFC 5321 § 4.5.1). | Critique |
+| `smtp.open_relay` | Signale les points de terminaison relayant le courrier pour des destinataires hors du domaine testé. | Critique |
+| `smtp.extension_posture` | Rapporte la posture des extensions ESMTP (PIPELINING, 8BITMIME). | Info |
+| `smtp.ipv6_reachable` | Au moins un point de terminaison MX est joignable en IPv6. | Info |
+| `smtp.tls_quality` | Intègre les constats TLS en aval (chaîne, nom, expiration) au rapport SMTP. | Critique |
+
+La posture des certificats elle-même est hors de portée ici : chaque cible MX est publiée comme entrée de découverte `tls.endpoint.v1` (STARTTLS opportuniste), et le vérificateur {{< relref "/reference/checkers/tls" >}} effectue l'analyse des certificats sur la même connexion. Ses constats sont réintégrés dans la règle `smtp.tls_quality` et dans le rapport HTML.
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Domaine (`domain`) | Domaine à tester. Rempli automatiquement depuis le service. | (depuis le service) |
+| Délai par point de terminaison (secondes) (`timeout`) | Délai de connexion par point de terminaison. | 12 |
+| Nom EHLO (`helo_name`) | Nom annoncé dans EHLO/HELO. Utilisez un nom qui résout et possède un PTR valide. | `mx-checker.happydomain.org` |
+| Sonder l'expéditeur nul (`test_null_sender`) | Sonde `MAIL FROM:<>` (acceptation des DSN, RFC 5321). | true |
+| Sonder le postmaster (`test_postmaster`) | Sonde `RCPT TO:<postmaster@domaine>` (RFC 5321 § 4.5.1). | true |
+| Sonder la posture de relais ouvert (`test_open_relay`) | Sonde un destinataire hors du domaine testé pour détecter les relais ouverts. | true |
+| Destinataire de la sonde de relais ouvert (`test_probe_address`) | Boîte (hors du domaine testé) utilisée pour la sonde de relais ouvert. | `postmaster@example.com` |
+
+## Dans happyDomain
+
+C'est un vérificateur de niveau service : configurez-le depuis l'onglet **Vérifications** du service « Serveurs e-mail » (MX). Pour confirmer que le courrier que votre domaine *envoie* arrive en boîte de réception, associez-le au vérificateur {{< relref "/reference/checkers/happydeliver" >}}. Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir {{< relref "/pages/checks" >}}.

content/reference/checkers/ssh.en.md

@@ -0,0 +1,45 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: SSH
+description: "Connects to the advertised SSH ports of a server and audits reachability, banner-to-CVE matches, the full algorithm posture, observed host keys, SSHFP alignment and authentication methods."
+weight: 280
+---
+
+The **SSH** checker produces a comprehensive security audit of the SSH service exposed by a *Server*. It connects to the advertised SSH port(s) on every `A`/`AAAA` address and reports reachability, banner-to-CVE matches, the full algorithm posture (key exchange, host-key, cipher, MAC, compression), the observed host keys, SSHFP fingerprint alignment, and the authentication methods the server exposes. Results are presented as a "fix me fast" HTML report.
+
+**Scope:** service-level. It attaches to services of type `abstract.Server` (a subdomain that publishes `A`/`AAAA` and optionally `SSHFP` records) and is configured from that service's **Checks** tab.
+
+## What it checks
+
+| Rule | Verifies | Severity |
+|------|----------|----------|
+| `ssh.tcp_reachable` | Every probed (address, port) pair accepts a TCP connection. | Critical |
+| `ssh.handshake` | The SSH banner exchange and KEXINIT parse succeed on every reachable endpoint. | Critical |
+| `ssh.protocol_version` | Every endpoint advertises SSH-2 and rejects legacy SSH-1. | Critical |
+| `ssh.banner_software` | Flags servers whose banner is not a recognised OpenSSH build. | Info |
+| `ssh.known_vulnerabilities` | Matches the advertised OpenSSH version against a curated CVE catalog (regreSSHion, Terrapin, etc.). | Critical |
+| `ssh.host_key_strength` | Flags host keys below the accepted minimum size (e.g. RSA < 2048 bits). | Critical |
+| `ssh.kex_algorithms` | Flags weak or broken key-exchange algorithms. | Critical |
+| `ssh.host_key_algorithms` | Flags weak or deprecated host-key algorithms (ssh-rsa/SHA-1, ssh-dss…). | Critical |
+| `ssh.cipher_algorithms` | Flags weak or broken symmetric ciphers (CBC, 3DES, RC4…). | Critical |
+| `ssh.mac_algorithms` | Flags weak MAC algorithms (SHA-1, non-ETM…). | Critical |
+| `ssh.strict_kex` | The server advertises the strict-KEX marker (CVE-2023-48795 Terrapin mitigation). | Warning |
+| `ssh.preauth_compression` | Flags servers offering pre-authentication zlib compression. | Info |
+| `ssh.auth_methods` | Reviews advertised authentication methods (password exposure, public-key availability). | Warning |
+| `ssh.sshfp_alignment` | Compares published SSHFP records against observed host keys (match, missing, mismatch). | Critical |
+| `ssh.sshfp_hash` | Flags SSHFP record sets that only publish SHA-1 (type 1) fingerprints. | Warning |
+
+CVE matching covers, among others, regreSSHion (CVE-2024-6387), the ssh-agent PKCS#11 RCE (CVE-2023-38408), Terrapin (CVE-2023-48795), and several older username-enumeration and command-injection issues.
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Ports (`ports`) | Comma-separated extra TCP ports to probe. Port 22 is always probed. | (empty) |
+| Per-endpoint probe timeout (ms) (`probeTimeoutMs`) | Maximum time for dial + banner + KEXINIT + handshake on a single endpoint. | 10000 |
+| Enumerate authentication methods (`includeAuthProbe`) | Open a second connection with a dummy user to discover advertised auth methods. | true |
+
+## In happyDomain
+
+This is a service-level checker: configure it from the **Checks** tab of the *Server* service on the relevant subdomain. Its SSHFP rules cross-reference the `SSHFP` records published in your zone, so keeping those records in sync with the server's host keys improves the result. For the general workflow of configuring and reading checks, see {{< relref "/pages/checks" >}}.

content/reference/checkers/ssh.fr.md

@@ -0,0 +1,45 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: SSH
+description: "Se connecte aux ports SSH annoncés d'un serveur et audite l'accessibilité, les correspondances bannière/CVE, la posture complète des algorithmes, les clés d'hôte observées, l'alignement SSHFP et les méthodes d'authentification."
+weight: 280
+---
+
+Le vérificateur **SSH** produit un audit de sécurité complet du service SSH exposé par un service « Serveur ». Il se connecte aux ports SSH annoncés sur chaque adresse `A`/`AAAA` et rapporte l'accessibilité, les correspondances bannière/CVE, la posture complète des algorithmes (échange de clés, clé d'hôte, chiffrement, MAC, compression), les clés d'hôte observées, l'alignement des empreintes SSHFP et les méthodes d'authentification exposées par le serveur. Les résultats sont présentés dans un rapport HTML orienté correction rapide.
+
+**Portée** : niveau service. Il s'attache aux services de type `abstract.Server` (un sous-domaine publiant des enregistrements `A`/`AAAA` et éventuellement `SSHFP`) et se configure depuis l'onglet **Vérifications** de ce service.
+
+## Ce qu'il vérifie
+
+| Règle | Vérifie | Sévérité |
+|-------|---------|----------|
+| `ssh.tcp_reachable` | Chaque paire (adresse, port) sondée accepte une connexion TCP. | Critique |
+| `ssh.handshake` | L'échange de bannière SSH et l'analyse KEXINIT aboutissent sur chaque point de terminaison joignable. | Critique |
+| `ssh.protocol_version` | Chaque point de terminaison annonce SSH-2 et rejette l'ancien SSH-1. | Critique |
+| `ssh.banner_software` | Signale les serveurs dont la bannière n'est pas une version OpenSSH reconnue. | Info |
+| `ssh.known_vulnerabilities` | Confronte la version OpenSSH annoncée à un catalogue de CVE (regreSSHion, Terrapin, etc.). | Critique |
+| `ssh.host_key_strength` | Signale les clés d'hôte sous la taille minimale acceptée (par exemple RSA < 2048 bits). | Critique |
+| `ssh.kex_algorithms` | Signale les algorithmes d'échange de clés faibles ou cassés. | Critique |
+| `ssh.host_key_algorithms` | Signale les algorithmes de clé d'hôte faibles ou obsolètes (ssh-rsa/SHA-1, ssh-dss, etc.). | Critique |
+| `ssh.cipher_algorithms` | Signale les chiffrements symétriques faibles ou cassés (CBC, 3DES, RC4, etc.). | Critique |
+| `ssh.mac_algorithms` | Signale les algorithmes MAC faibles (SHA-1, non-ETM, etc.). | Critique |
+| `ssh.strict_kex` | Le serveur annonce le marqueur strict-KEX (mitigation Terrapin, CVE-2023-48795). | Avertissement |
+| `ssh.preauth_compression` | Signale les serveurs offrant la compression zlib avant authentification. | Info |
+| `ssh.auth_methods` | Examine les méthodes d'authentification annoncées (exposition par mot de passe, disponibilité de la clé publique). | Avertissement |
+| `ssh.sshfp_alignment` | Compare les enregistrements SSHFP publiés aux clés d'hôte observées (concordance, manquant, divergence). | Critique |
+| `ssh.sshfp_hash` | Signale les jeux SSHFP ne publiant que des empreintes SHA-1 (type 1). | Avertissement |
+
+La correspondance CVE couvre notamment regreSSHion (CVE-2024-6387), la RCE PKCS#11 de ssh-agent (CVE-2023-38408), Terrapin (CVE-2023-48795) et plusieurs anciennes failles d'énumération d'utilisateurs et d'injection de commandes.
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Ports (`ports`) | Ports TCP supplémentaires à sonder, séparés par des virgules. Le port 22 est toujours sondé. | (vide) |
+| Délai de sonde par point de terminaison (ms) (`probeTimeoutMs`) | Temps maximal pour la connexion, la bannière, le KEXINIT et la poignée de main sur un point de terminaison. | 10000 |
+| Énumérer les méthodes d'authentification (`includeAuthProbe`) | Ouvre une seconde connexion avec un utilisateur factice pour découvrir les méthodes d'authentification annoncées. | true |
+
+## Dans happyDomain
+
+C'est un vérificateur de niveau service : configurez-le depuis l'onglet **Vérifications** du service « Serveur » sur le sous-domaine concerné. Ses règles SSHFP recoupent les enregistrements `SSHFP` publiés dans votre zone ; garder ces enregistrements synchronisés avec les clés d'hôte du serveur améliore le résultat. Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir {{< relref "/pages/checks" >}}.

content/reference/checkers/stun-turn.en.md

@@ -0,0 +1,55 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: STUN / TURN
+description: "Probes STUN and TURN servers end-to-end: discovery, reachability, TLS/DTLS, STUN binding and authenticated TURN relay."
+weight: 310
+---
+
+The **STUN / TURN** checker probes STUN and TURN servers end-to-end. STUN and TURN are the NAT-traversal servers that real-time applications (WebRTC, voice and video) rely on to establish peer-to-peer media: STUN lets a host discover its public reflexive address, while TURN relays media when a direct path cannot be opened.
+
+This is a **service-level** checker. It runs SRV discovery (or uses an explicit URI), checks TCP/UDP reachability and the TLS/DTLS handshake, issues a STUN binding request, verifies that the TURN server requires authentication, performs an authenticated TURN `Allocate`, and finally exercises the relay path with a `CreatePermission + Send` round-trip.
+
+## What it checks
+
+| Rule | What it verifies | Severity |
+|------|------------------|----------|
+| `stun_turn.discovery` | At least one STUN/TURN endpoint could be discovered (explicit URI or SRV lookup). | Critical |
+| `stun_turn.srv_stun` | At least one STUN endpoint is available via SRV (`_stun` / `_stuns`) or explicit URI. | Warning |
+| `stun_turn.srv_turn` | At least one TURN endpoint is available via SRV (`_turn` / `_turns`) or explicit URI. | Critical |
+| `stun_turn.dial` | Every discovered endpoint accepts a connection (TCP/TLS handshake or UDP socket). | Critical |
+| `stun_turn.tls_transport` | At least one TLS/DTLS transport (`stuns` / `turns`) succeeds when present. | Critical |
+| `stun_turn.ipv6_coverage` | At least one STUN/TURN hostname resolves to an IPv6 address. | Warning |
+| `stun_turn.stun_binding` | The STUN Binding request receives a XOR-MAPPED-ADDRESS reply. | Critical |
+| `stun_turn.reflexive_public` | Flags endpoints returning a private/loopback reflexive address (server unaware of its public IP). | Critical |
+| `stun_turn.stun_latency` | Compares the STUN Binding RTT against the warning/critical thresholds. | Critical |
+| `stun_turn.turn_open_relay` | The TURN server requires authentication (challenges an unauthenticated `Allocate` with 401). | Critical |
+| `stun_turn.turn_auth` | The supplied TURN credentials (or REST shared secret) yield a successful `Allocate`. | Critical |
+| `stun_turn.relay_public` | Flags TURN servers whose allocated relay address is private/loopback (missing public relay IP). | Critical |
+| `stun_turn.relay_echo` | The TURN relay path can carry traffic to the configured probe peer (`CreatePermission + Send`). | Warning |
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Zone | Zone used for SRV-based discovery (`_stun._udp` / `_turn._udp` / `_turns._tcp`) when no explicit URI is given. Filled in automatically. | (auto-filled) |
+| Server URI | Explicit STUN/TURN URI (RFC 7064/7065). Overrides SRV-based discovery. | — |
+| Mode | `auto` probes both STUN and TURN; `stun` skips TURN allocation tests; `turn` requires TURN allocation. | `auto` |
+| TURN username | Username for long-term TURN credentials. | — |
+| TURN password | Password for long-term TURN credentials (secret). | — |
+| REST API shared secret | Shared secret to derive ephemeral credentials (draft-uberti-rtcweb-turn-rest); takes precedence over username/password (secret). | — |
+| Realm | Optional explicit TURN realm. | — |
+| Transports | Comma-separated transports to test among `udp`, `tcp`, `tls`, `dtls`. | `udp,tcp,tls` |
+| Relay echo target | `host:port` used to validate the relay path; a `CreatePermission + Send` is issued, no payload data is exchanged. | `1.1.1.1:53` |
+| Also test ChannelBind | Additionally exercise ChannelBind through the relay connection. | `false` |
+| RTT warning threshold (ms) | STUN Binding round-trip time above which a warning is raised. | 200 |
+| RTT critical threshold (ms) | STUN Binding round-trip time above which a critical alert is raised. | 1000 |
+| Per-probe timeout (s) | Time budget for each individual probe. | 5 |
+
+{{% notice style="info" title="Credentials are needed for the TURN tests" %}}
+The authentication, relay-public and relay-echo rules only run when valid TURN credentials are provided — either a username/password pair or a REST API shared secret. Without them, the checker still validates discovery, reachability, TLS and STUN binding, but cannot exercise the TURN relay path.
+{{% /notice %}}
+
+## In happyDomain
+
+Enable this checker from the **Checks** tab of the relevant service; see {{< relref "/pages/checks" >}} for how to configure and schedule checks. The zone is filled in automatically; supply a server URI and TURN credentials as needed for your deployment.

content/reference/checkers/stun-turn.fr.md

@@ -0,0 +1,55 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: STUN / TURN
+description: "Sonde de bout en bout les serveurs STUN et TURN : découverte, accessibilité, TLS/DTLS, binding STUN et relais TURN authentifié."
+weight: 310
+---
+
+Le vérificateur **STUN / TURN** sonde de bout en bout les serveurs STUN et TURN. STUN et TURN sont les serveurs de traversée de NAT sur lesquels reposent les applications temps réel (WebRTC, voix et vidéo) pour établir un flux média pair à pair : STUN permet à un hôte de découvrir son adresse réflexive publique, tandis que TURN relaie le média lorsqu'aucun chemin direct ne peut être ouvert.
+
+Il s'agit d'un vérificateur de **niveau service**. Il effectue la découverte SRV (ou utilise une URI explicite), contrôle l'accessibilité TCP/UDP et la poignée de main TLS/DTLS, émet une requête de binding STUN, vérifie que le serveur TURN exige une authentification, réalise un `Allocate` TURN authentifié, puis éprouve le chemin de relais par un aller-retour `CreatePermission + Send`.
+
+## Ce qui est vérifié
+
+| Règle | Ce qu'elle vérifie | Sévérité |
+|-------|--------------------|----------|
+| `stun_turn.discovery` | Au moins un point d'accès STUN/TURN a pu être découvert (URI explicite ou résolution SRV). | Critique |
+| `stun_turn.srv_stun` | Au moins un point d'accès STUN est disponible via SRV (`_stun` / `_stuns`) ou URI explicite. | Avertissement |
+| `stun_turn.srv_turn` | Au moins un point d'accès TURN est disponible via SRV (`_turn` / `_turns`) ou URI explicite. | Critique |
+| `stun_turn.dial` | Chaque point d'accès découvert accepte une connexion (poignée de main TCP/TLS ou socket UDP). | Critique |
+| `stun_turn.tls_transport` | Au moins un transport TLS/DTLS (`stuns` / `turns`) aboutit lorsqu'il est présent. | Critique |
+| `stun_turn.ipv6_coverage` | Au moins un nom d'hôte STUN/TURN se résout vers une adresse IPv6. | Avertissement |
+| `stun_turn.stun_binding` | La requête de binding STUN reçoit une réponse XOR-MAPPED-ADDRESS. | Critique |
+| `stun_turn.reflexive_public` | Signale les points d'accès renvoyant une adresse réflexive privée ou de bouclage (serveur ignorant son IP publique). | Critique |
+| `stun_turn.stun_latency` | Compare le temps d'aller-retour du binding STUN aux seuils d'avertissement et critique. | Critique |
+| `stun_turn.turn_open_relay` | Le serveur TURN exige une authentification (répond à un `Allocate` non authentifié par un 401). | Critique |
+| `stun_turn.turn_auth` | Les identifiants TURN fournis (ou le secret partagé REST) permettent un `Allocate` réussi. | Critique |
+| `stun_turn.relay_public` | Signale les serveurs TURN dont l'adresse de relais allouée est privée ou de bouclage (IP de relais publique manquante). | Critique |
+| `stun_turn.relay_echo` | Le chemin de relais TURN peut acheminer du trafic vers le pair de test configuré (`CreatePermission + Send`). | Avertissement |
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Zone | Zone utilisée pour la découverte SRV (`_stun._udp` / `_turn._udp` / `_turns._tcp`) en l'absence d'URI explicite. Renseignée automatiquement. | (renseignée automatiquement) |
+| URI du serveur | URI STUN/TURN explicite (RFC 7064/7065). Prend le pas sur la découverte SRV. | (aucun) |
+| Mode | `auto` sonde à la fois STUN et TURN ; `stun` ignore les tests d'allocation TURN ; `turn` exige l'allocation TURN. | `auto` |
+| Nom d'utilisateur TURN | Nom d'utilisateur pour les identifiants TURN à long terme. | (aucun) |
+| Mot de passe TURN | Mot de passe pour les identifiants TURN à long terme (secret). | (aucun) |
+| Secret partagé API REST | Secret partagé pour dériver des identifiants éphémères (draft-uberti-rtcweb-turn-rest) ; prend le pas sur le nom d'utilisateur et le mot de passe (secret). | (aucun) |
+| Realm | Realm TURN explicite facultatif. | (aucun) |
+| Transports | Liste de transports à tester, séparés par des virgules, parmi `udp`, `tcp`, `tls`, `dtls`. | `udp,tcp,tls` |
+| Cible de l'écho de relais | `hôte:port` utilisé pour valider le chemin de relais ; un `CreatePermission + Send` est émis, aucune donnée utile n'est échangée. | `1.1.1.1:53` |
+| Tester aussi ChannelBind | Éprouve en plus ChannelBind sur la connexion de relais. | `false` |
+| Seuil d'avertissement de RTT (ms) | Temps d'aller-retour du binding STUN au-delà duquel un avertissement est déclenché. | 200 |
+| Seuil critique de RTT (ms) | Temps d'aller-retour du binding STUN au-delà duquel une alerte critique est déclenchée. | 1000 |
+| Délai par sonde (s) | Budget de temps alloué à chaque sonde individuelle. | 5 |
+
+{{% notice style="info" title="Des identifiants sont nécessaires pour les tests TURN" %}}
+Les règles d'authentification, de relais public et d'écho de relais ne s'exécutent que lorsque des identifiants TURN valides sont fournis : soit un couple nom d'utilisateur/mot de passe, soit un secret partagé d'API REST. Sans eux, le vérificateur valide tout de même la découverte, l'accessibilité, le TLS et le binding STUN, mais ne peut pas éprouver le chemin de relais TURN.
+{{% /notice %}}
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis l'onglet **Vérifications** du service concerné ; consultez {{< relref "/pages/checks" >}} pour savoir comment configurer et planifier les vérifications. La zone est renseignée automatiquement ; fournissez une URI de serveur et des identifiants TURN selon les besoins de votre déploiement.

content/reference/checkers/tls.en.md

@@ -0,0 +1,50 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: TLS posture
+description: "Dials every TLS endpoint discovered for a domain, completes the handshake (with STARTTLS upgrade where needed) and audits certificate chain, hostname coverage, expiry and protocol strength."
+weight: 170
+---
+
+The **TLS** checker (internal name `TLS`) evaluates the transport-security posture of every TLS endpoint exposed by a domain. It does not scan ports on its own: it consumes **discovery entries** of type `tls.endpoint.v1` published by other service checkers (XMPP, SRV, CalDAV, CardDAV, SMTP…). For each discovered endpoint it performs a real TCP dial, an optional protocol-specific STARTTLS upgrade, and a full TLS handshake, then reports a per-endpoint posture.
+
+**Scope:** domain-level. The checker runs against the whole domain and folds in the endpoints that every other service checker has advertised. A given endpoint is therefore only probed if some service checker (for example {{< relref "/reference/checkers/smtp" >}}) published it.
+
+## What it checks
+
+| Rule | Verifies | Severity |
+|------|----------|----------|
+| `tls.endpoints_discovered` | At least one TLS endpoint has been discovered for this target. | Info |
+| `tls.reachability` | Every discovered endpoint accepts a TCP connection. | Critical |
+| `tls.handshake` | The TLS handshake completes on every reachable endpoint. | Critical |
+| `tls.starttls_advertised` | STARTTLS endpoints advertise the upgrade capability. | Critical |
+| `tls.starttls_dialect_supported` | The discovered STARTTLS dialect is implemented by the checker. | Critical |
+| `tls.peer_certificate_present` | The server presented a certificate during the handshake. | Critical |
+| `tls.chain_validity` | The presented chain validates against the system trust store. | Critical |
+| `tls.hostname_match` | The leaf certificate covers the probed hostname (SNI). | Critical |
+| `tls.expiry` | Flags expired or soon-to-expire leaf certificates. | Critical |
+| `tls.version` | Flags endpoints negotiating a TLS version below TLS 1.2. | Warning |
+| `tls.cipher_suite` | Reports the cipher suite negotiated on each endpoint. | Info |
+| `tls.enum.versions` | Flags endpoints that still accept TLS versions below TLS 1.2 (enumeration option). | Warning |
+| `tls.enum.ciphers` | Flags endpoints accepting broken cipher suites (NULL, anonymous, EXPORT, RC4, 3DES) (enumeration option). | Warning |
+
+STARTTLS upgrades are supported for SMTP/submission, IMAP, POP3, and XMPP (c2s and s2s). When a service checker marks an endpoint as requiring STARTTLS, the absence of the upgrade is reported as Critical; otherwise it is treated as opportunistic and reported as Warning.
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Per-endpoint probe timeout (ms) (`probeTimeoutMs`) | Maximum time allowed for dial + STARTTLS + TLS handshake on a single endpoint. | 10000 |
+| Enumerate accepted TLS versions and cipher suites (`enumerateCiphers`) | When enabled, each direct-TLS endpoint is swept with one ClientHello per (version, cipher) pair to discover the exact set the server accepts. Adds roughly 50 handshakes per endpoint. | false |
+
+The list of discovery entries is filled automatically from what other checkers publish and is not user-editable.
+
+## In happyDomain
+
+The TLS checker is a domain-level check: enable it from the domain's checks view. Because it works on endpoints discovered by other checkers, it pairs naturally with service-level checkers that publish TLS endpoints, such as {{< relref "/reference/checkers/smtp" >}}.
+
+{{% notice style="info" title="TLS posture vs DANE" %}}
+This checker validates the live certificate against the system trust store. Pinning the certificate in DNS through TLSA records is a separate concern, handled by the {{< relref "/reference/checkers/dane" >}} checker.
+{{% /notice %}}
+
+For the general workflow of configuring and reading checks, see {{< relref "/pages/checks" >}}.

content/reference/checkers/tls.fr.md

@@ -0,0 +1,50 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Posture TLS
+description: "Se connecte à chaque point de terminaison TLS découvert pour un domaine, termine la poignée de main (avec bascule STARTTLS si nécessaire) et audite la chaîne de certificats, la couverture du nom, l'expiration et la robustesse du protocole."
+weight: 170
+---
+
+Le vérificateur **TLS** (nom interne « TLS ») évalue la posture de sécurité du transport de chaque point de terminaison TLS exposé par un domaine. Il ne scanne pas de ports lui-même : il consomme des **entrées de découverte** de type `tls.endpoint.v1` publiées par d'autres vérificateurs de service (XMPP, SRV, CalDAV, CardDAV, SMTP, etc.). Pour chaque point de terminaison découvert, il effectue une véritable connexion TCP, une bascule STARTTLS spécifique au protocole le cas échéant, puis une poignée de main TLS complète, et il rapporte une posture par point de terminaison.
+
+**Portée** : niveau domaine. Le vérificateur s'exécute sur l'ensemble du domaine et intègre les points de terminaison annoncés par les autres vérificateurs de service. Un point de terminaison n'est donc sondé que si un vérificateur de service (par exemple {{< relref "/reference/checkers/smtp" >}}) l'a publié.
+
+## Ce qu'il vérifie
+
+| Règle | Vérifie | Sévérité |
+|-------|---------|----------|
+| `tls.endpoints_discovered` | Au moins un point de terminaison TLS a été découvert pour cette cible. | Info |
+| `tls.reachability` | Chaque point de terminaison découvert accepte une connexion TCP. | Critique |
+| `tls.handshake` | La poignée de main TLS aboutit sur chaque point de terminaison joignable. | Critique |
+| `tls.starttls_advertised` | Les points de terminaison STARTTLS annoncent la capacité de bascule. | Critique |
+| `tls.starttls_dialect_supported` | Le dialecte STARTTLS découvert est implémenté par le vérificateur. | Critique |
+| `tls.peer_certificate_present` | Le serveur a présenté un certificat pendant la poignée de main. | Critique |
+| `tls.chain_validity` | La chaîne présentée se valide avec le magasin de confiance du système. | Critique |
+| `tls.hostname_match` | Le certificat feuille couvre le nom sondé (SNI). | Critique |
+| `tls.expiry` | Signale les certificats feuilles expirés ou proches de l'expiration. | Critique |
+| `tls.version` | Signale les points de terminaison négociant une version TLS inférieure à TLS 1.2. | Avertissement |
+| `tls.cipher_suite` | Rapporte la suite cryptographique négociée sur chaque point de terminaison. | Info |
+| `tls.enum.versions` | Signale les points de terminaison acceptant encore des versions TLS inférieures à TLS 1.2 (option d'énumération). | Avertissement |
+| `tls.enum.ciphers` | Signale les points de terminaison acceptant des suites cryptographiques cassées (NULL, anonyme, EXPORT, RC4, 3DES) (option d'énumération). | Avertissement |
+
+Les bascules STARTTLS sont prises en charge pour SMTP/submission, IMAP, POP3 et XMPP (c2s et s2s). Lorsqu'un vérificateur de service marque un point de terminaison comme exigeant STARTTLS, l'absence de bascule est rapportée comme critique ; sinon, elle est considérée comme opportuniste et rapportée comme avertissement.
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Délai de sonde par point de terminaison (ms) (`probeTimeoutMs`) | Temps maximal alloué pour la connexion, la bascule STARTTLS et la poignée de main TLS sur un point de terminaison. | 10000 |
+| Énumérer les versions et suites TLS acceptées (`enumerateCiphers`) | Lorsqu'activée, chaque point de terminaison en TLS direct est balayé avec un ClientHello par paire (version, suite) afin de découvrir l'ensemble exact accepté par le serveur. Ajoute environ 50 poignées de main par point de terminaison. | false |
+
+La liste des entrées de découverte est remplie automatiquement à partir de ce que les autres vérificateurs publient et n'est pas modifiable par l'utilisateur.
+
+## Dans happyDomain
+
+Le vérificateur TLS est une vérification de niveau domaine : activez-le depuis la vue des vérifications du domaine. Comme il travaille sur des points de terminaison découverts par d'autres vérificateurs, il s'associe naturellement aux vérificateurs de service qui publient des points de terminaison TLS, comme {{< relref "/reference/checkers/smtp" >}}.
+
+{{% notice style="info" title="Posture TLS et DANE" %}}
+Ce vérificateur valide le certificat en direct avec le magasin de confiance du système. L'épinglage du certificat dans le DNS via des enregistrements TLSA est un sujet distinct, traité par le vérificateur {{< relref "/reference/checkers/dane" >}}.
+{{% /notice %}}
+
+Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir {{< relref "/pages/checks" >}}.

content/reference/checkers/xmpp.en.md

@@ -0,0 +1,44 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: XMPP
+description: "Probes a domain's XMPP deployment: SRV discovery, reachability, STARTTLS, SASL mechanisms and federation authentication."
+weight: 290
+---
+
+The **XMPP** checker probes a domain's XMPP (Jabber) deployment end-to-end, much like [xmpp.net](https://xmpp.net/) does: it discovers the relevant SRV records, opens a stream to each endpoint, negotiates STARTTLS, inspects the offered SASL mechanisms and confirms that server-to-server federation can authenticate.
+
+This is a **service-level** checker. It applies to services of type **XMPP** and is configured from that service's own **Checks** tab. It probes the four standard service names (`_xmpp-client._tcp`, `_xmpp-server._tcp`, `_xmpps-client._tcp`, `_xmpps-server._tcp`), the legacy `_jabber._tcp`, and falls back to `<domain>:5222` / `:5269` when no SRV record is published.
+
+{{% notice style="info" title="TLS posture is checked separately" %}}
+Certificate chain, hostname (SAN) match, expiry and cipher posture are **out of scope** here: a dedicated {{< relref "/reference/checkers/tls" >}} checker handles them. The XMPP checker only confirms that STARTTLS completes, records the negotiated TLS version and cipher for context, and folds the downstream TLS findings back onto the XMPP service report through the `xmpp.tls_quality` rule.
+{{% /notice %}}
+
+## What it checks
+
+| Rule | What it verifies | Severity |
+|------|------------------|----------|
+| `xmpp.srv_c2s` | Client-to-server SRV records (`_xmpp-client` / `_xmpps-client` / `_jabber`) are published and resolvable. | Critical |
+| `xmpp.srv_s2s` | Server-to-server SRV records (`_xmpp-server` / `_xmpps-server`) are published and resolvable. | Critical |
+| `xmpp.c2s_reachable` | At least one client-to-server endpoint accepts TCP and completes TLS. | Critical |
+| `xmpp.s2s_reachable` | At least one server-to-server endpoint accepts TCP and completes TLS. | Critical |
+| `xmpp.starttls_required` | STARTTLS is advertised and required on every reachable c2s/s2s endpoint. | Critical |
+| `xmpp.sasl_mechanisms` | The c2s SASL offer is sound (SCRAM present, no password-equivalent PLAIN-only). | Critical |
+| `xmpp.s2s_dialback` | Server-to-server endpoints advertise dialback or SASL EXTERNAL after TLS (federation auth). | Critical |
+| `xmpp.ipv6_reachable` | Flags deployments reachable only over IPv4. | Info |
+| `xmpp.direct_tls` | Flags c2s deployments that do not publish XEP-0368 direct-TLS (`_xmpps-*`) SRV records. | Info |
+| `xmpp.tls_quality` | Folds the downstream TLS checker findings (certificate chain, hostname match, expiry) onto the XMPP service. | Critical |
+
+The probe also covers TCP reachability of A/AAAA targets, stream feature parsing and IPv4/IPv6 coverage, surfaced through the rules above and the HTML report.
+
+## Options
+
+| Option | Meaning | Default |
+|--------|---------|---------|
+| Domain | XMPP domain (JID domain) to test. Filled in automatically from the service. | (auto-filled) |
+| Mode | Which side to probe: `c2s` (client-to-server), `s2s` (server-to-server), or `both`. | `both` |
+| Per-endpoint timeout (seconds) | Time budget for each probed endpoint. | 10 |
+
+## In happyDomain
+
+Enable this checker from the **Checks** tab of an XMPP service; see {{< relref "/pages/checks" >}} for how to configure and schedule checks. The domain is filled in automatically from the service. For the certificate side of the same endpoints, pair it with the {{< relref "/reference/checkers/tls" >}} checker.

content/reference/checkers/xmpp.fr.md

@@ -0,0 +1,44 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: XMPP
+description: "Sonde le déploiement XMPP d'un domaine : découverte SRV, accessibilité, STARTTLS, mécanismes SASL et authentification de fédération."
+weight: 290
+---
+
+Le vérificateur **XMPP** sonde de bout en bout le déploiement XMPP (Jabber) d'un domaine, à la manière de [xmpp.net](https://xmpp.net/) : il découvre les enregistrements SRV pertinents, ouvre un flux vers chaque point d'accès, négocie STARTTLS, inspecte les mécanismes SASL proposés et confirme que la fédération de serveur à serveur peut s'authentifier.
+
+Il s'agit d'un vérificateur de **niveau service**. Il s'applique aux services de type **XMPP** et se configure depuis l'onglet **Vérifications** de ce service. Il sonde les quatre noms de service standard (`_xmpp-client._tcp`, `_xmpp-server._tcp`, `_xmpps-client._tcp`, `_xmpps-server._tcp`), l'ancien `_jabber._tcp`, et se rabat sur `<domaine>:5222` / `:5269` lorsqu'aucun enregistrement SRV n'est publié.
+
+{{% notice style="info" title="La posture TLS est vérifiée séparément" %}}
+La chaîne de certificats, la correspondance du nom d'hôte (SAN), l'expiration et la posture des chiffrements sont **hors périmètre** ici : un vérificateur {{< relref "/reference/checkers/tls" >}} dédié s'en charge. Le vérificateur XMPP confirme seulement que STARTTLS aboutit, enregistre la version et le chiffrement TLS négociés à titre de contexte, et reverse les conclusions TLS dans le rapport du service XMPP via la règle `xmpp.tls_quality`.
+{{% /notice %}}
+
+## Ce qui est vérifié
+
+| Règle | Ce qu'elle vérifie | Sévérité |
+|-------|--------------------|----------|
+| `xmpp.srv_c2s` | Les enregistrements SRV client vers serveur (`_xmpp-client` / `_xmpps-client` / `_jabber`) sont publiés et résolvables. | Critique |
+| `xmpp.srv_s2s` | Les enregistrements SRV serveur vers serveur (`_xmpp-server` / `_xmpps-server`) sont publiés et résolvables. | Critique |
+| `xmpp.c2s_reachable` | Au moins un point d'accès client vers serveur accepte le TCP et achève le TLS. | Critique |
+| `xmpp.s2s_reachable` | Au moins un point d'accès serveur vers serveur accepte le TCP et achève le TLS. | Critique |
+| `xmpp.starttls_required` | STARTTLS est annoncé et requis sur chaque point d'accès c2s/s2s joignable. | Critique |
+| `xmpp.sasl_mechanisms` | L'offre SASL c2s est saine (présence de SCRAM, absence d'un PLAIN seul équivalent à un mot de passe en clair). | Critique |
+| `xmpp.s2s_dialback` | Les points d'accès serveur vers serveur annoncent le dialback ou SASL EXTERNAL après le TLS (authentification de fédération). | Critique |
+| `xmpp.ipv6_reachable` | Signale les déploiements joignables uniquement en IPv4. | Info |
+| `xmpp.direct_tls` | Signale les déploiements c2s qui ne publient pas d'enregistrements SRV direct-TLS XEP-0368 (`_xmpps-*`). | Info |
+| `xmpp.tls_quality` | Reverse sur le service XMPP les conclusions du vérificateur TLS sous-jacent (chaîne de certificats, correspondance du nom d'hôte, expiration). | Critique |
+
+La sonde couvre aussi l'accessibilité TCP des cibles A/AAAA, l'analyse des fonctionnalités de flux et la couverture IPv4/IPv6, exposées au travers des règles ci-dessus et du rapport HTML.
+
+## Options
+
+| Option | Signification | Défaut |
+|--------|---------------|--------|
+| Domaine | Domaine XMPP (domaine du JID) à tester. Renseigné automatiquement depuis le service. | (renseigné automatiquement) |
+| Mode | Côté à sonder : `c2s` (client vers serveur), `s2s` (serveur vers serveur) ou `both` (les deux). | `both` |
+| Délai par point d'accès (secondes) | Budget de temps alloué à chaque point d'accès sondé. | 10 |
+
+## Dans happyDomain
+
+Activez ce vérificateur depuis l'onglet **Vérifications** d'un service XMPP ; consultez {{< relref "/pages/checks" >}} pour savoir comment configurer et planifier les vérifications. Le domaine est renseigné automatiquement depuis le service. Pour le volet certificat de ces mêmes points d'accès, associez-le au vérificateur {{< relref "/reference/checkers/tls" >}}.

content/reference/checkers/zonemaster.en.md

@@ -0,0 +1,52 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Zonemaster
+description: "Run the Zonemaster test suite against a domain through its JSON-RPC API and group the results by test category (delegation, consistency, DNSSEC…)."
+weight: 350
+---
+
+The **Zonemaster** checker runs the [Zonemaster](https://zonemaster.net/) test suite against a domain and reports its findings grouped by test category. Zonemaster is a well-established DNS health and delegation validator; this checker drives it through its JSON-RPC API, stores the full results as an observation, and renders an HTML report grouped by module and severity.
+
+This checker is **domain-level**: it evaluates the domain's delegation and zone content rather than a single service.
+
+## How it works
+
+For each run the checker submits the domain to a Zonemaster JSON-RPC endpoint (the official public API by default), waits for the test batch to complete, and stores every message Zonemaster returns. Each message carries a module, a test case and a Zonemaster severity (INFO / NOTICE / WARNING / ERROR / CRITICAL).
+
+{{% notice style="info" title="Point only at a trusted Zonemaster instance" %}}
+The Zonemaster API URL is an administrator option. Because the checker issues requests to whatever URL is configured and surfaces the responses, point it only at a Zonemaster instance you trust.
+{{% /notice %}}
+
+## What it checks
+
+The checker maps each Zonemaster test module onto a category rule. Every rule emits a `<rule>.summary` state, plus one state per WARNING-or-worse message (so downstream consumers can match on stable codes); INFO and NOTICE messages are folded into the summary counts.
+
+| Rule | What it covers |
+|---|---|
+| `zonemaster.dnssec` | DNSSEC tests (signatures, NSEC/NSEC3, DS/DNSKEY coherence). |
+| `zonemaster.delegation` | Delegation tests (parent/child NS agreement, glue, referrals). |
+| `zonemaster.consistency` | Consistency tests (SOA serial, NS set, zone content across servers). |
+| `zonemaster.connectivity` | Connectivity tests (UDP/TCP reachability of authoritative servers, AS diversity). |
+| `zonemaster.nameserver` | Nameserver tests (server behaviour, EDNS, unknown RR handling). |
+| `zonemaster.syntax` | Syntax tests (domain name syntax, hostname legality). |
+| `zonemaster.zone` | Zone tests (SOA values, MX presence, mandatory records). |
+| `zonemaster.address` | Address tests (nameserver IP addresses, private/reserved ranges). |
+| `zonemaster.basic` | Basic/system tests (initial reachability and fundamental requirements). |
+
+Zonemaster severities are mapped onto happyDomain statuses: CRITICAL and ERROR → Critical; WARNING → Warning; NOTICE, INFO and DEBUG → Info. Each summary takes the worst status among its category's messages. When Zonemaster returns no message for a category, that rule reports Unknown (not tested).
+
+## Options
+
+| Option | Meaning | Default |
+|---|---|---|
+| Domain name to check (`domainName`) | Domain submitted to Zonemaster. **Required.** | auto-filled |
+| Profile (`profile`) | Zonemaster profile name to run the tests under. | `default` |
+| Result language (`language`, per user) | Language of the returned messages (`en`, `fr`, `de`, `es`, `sv`, `da`, `fi`, `nb`, `nl`, `pt`). | `en` |
+| Zonemaster API URL (`zonemasterAPIURL`, admin) | JSON-RPC endpoint to query. | `https://zonemaster.net/api` |
+
+## In happyDomain
+
+Enable this checker for the domain from the **Checks** view. See {{< relref "/pages/checks" >}} for scheduling and reading checks.
+
+Zonemaster overlaps in part with {{< relref "/reference/checkers/dnsviz" >}} on DNSSEC, but covers a broader range of delegation, connectivity and zone-content tests. For NSEC/NSEC3 hardening specifically, see {{< relref "/reference/checkers/dnssec" >}}.

content/reference/checkers/zonemaster.fr.md

@@ -0,0 +1,52 @@
+---
+date: 2026-06-11T09:00:00+02:00
+author: nemunaire
+title: Zonemaster
+description: "Lance la suite de tests Zonemaster sur un domaine via son API JSON-RPC et regroupe les résultats par catégorie de test (délégation, cohérence, DNSSEC…)."
+weight: 350
+---
+
+Le vérificateur **Zonemaster** lance la suite de tests [Zonemaster](https://zonemaster.net/) sur un domaine et rapporte ses constats regroupés par catégorie de test. Zonemaster est un validateur reconnu de la santé DNS et de la délégation ; ce vérificateur le pilote via son API JSON-RPC, conserve l'ensemble des résultats sous forme d'observation et produit un rapport HTML regroupé par module et par sévérité.
+
+Ce vérificateur s'applique au **niveau domaine** : il évalue la délégation et le contenu de zone du domaine plutôt qu'un service isolé.
+
+## Fonctionnement
+
+À chaque exécution, le vérificateur soumet le domaine à un point d'accès JSON-RPC Zonemaster (l'API publique officielle par défaut), attend la fin du lot de tests et conserve chaque message renvoyé par Zonemaster. Chaque message porte un module, un cas de test et une sévérité Zonemaster (INFO / NOTICE / WARNING / ERROR / CRITICAL).
+
+{{% notice style="info" title="Ne pointez que vers une instance Zonemaster de confiance" %}}
+L'URL de l'API Zonemaster est une option d'administrateur. Comme le vérificateur émet des requêtes vers l'URL configurée et en restitue les réponses, ne le pointez que vers une instance Zonemaster en laquelle vous avez confiance.
+{{% /notice %}}
+
+## Ce qui est vérifié
+
+Le vérificateur projette chaque module de test Zonemaster sur une règle de catégorie. Chaque règle émet un état `<règle>.summary`, plus un état par message de niveau WARNING ou pire (afin que les consommateurs en aval puissent s'appuyer sur des codes stables) ; les messages INFO et NOTICE sont agrégés dans les compteurs du résumé.
+
+| Règle | Ce qu'elle couvre |
+|---|---|
+| `zonemaster.dnssec` | Tests DNSSEC (signatures, NSEC/NSEC3, cohérence DS/DNSKEY). |
+| `zonemaster.delegation` | Tests de délégation (accord NS parent/enfant, glue, renvois). |
+| `zonemaster.consistency` | Tests de cohérence (numéro de série SOA, ensemble NS, contenu de zone entre serveurs). |
+| `zonemaster.connectivity` | Tests de connectivité (joignabilité UDP/TCP des serveurs autoritaires, diversité d'AS). |
+| `zonemaster.nameserver` | Tests des serveurs de noms (comportement du serveur, EDNS, traitement des RR inconnus). |
+| `zonemaster.syntax` | Tests de syntaxe (syntaxe des noms de domaine, légalité des noms d'hôtes). |
+| `zonemaster.zone` | Tests de zone (valeurs SOA, présence de MX, enregistrements obligatoires). |
+| `zonemaster.address` | Tests d'adresses (adresses IP des serveurs de noms, plages privées/réservées). |
+| `zonemaster.basic` | Tests de base/système (joignabilité initiale et prérequis fondamentaux). |
+
+Les sévérités Zonemaster sont projetées sur les statuts de happyDomain : CRITICAL et ERROR vers Critique ; WARNING vers Avertissement ; NOTICE, INFO et DEBUG vers Info. Chaque résumé retient le pire statut parmi les messages de sa catégorie. Lorsque Zonemaster ne renvoie aucun message pour une catégorie, la règle correspondante rapporte Inconnu (non testée).
+
+## Options
+
+| Option | Signification | Défaut |
+|---|---|---|
+| Nom de domaine à vérifier (`domainName`) | Domaine soumis à Zonemaster. **Obligatoire.** | prérempli |
+| Profil (`profile`) | Nom du profil Zonemaster sous lequel exécuter les tests. | `default` |
+| Langue des résultats (`language`, par utilisateur) | Langue des messages renvoyés (`en`, `fr`, `de`, `es`, `sv`, `da`, `fi`, `nb`, `nl`, `pt`). | `en` |
+| URL de l'API Zonemaster (`zonemasterAPIURL`, admin) | Point d'accès JSON-RPC à interroger. | `https://zonemaster.net/api` |
+
+## Dans happyDomain
+
+Activez ce vérificateur pour le domaine depuis la vue **Vérifications**. Voir {{< relref "/pages/checks" >}} pour la planification et la lecture des vérifications.
+
+Zonemaster recoupe en partie {{< relref "/reference/checkers/dnsviz" >}} sur le DNSSEC, mais couvre un éventail plus large de tests de délégation, de connectivité et de contenu de zone. Pour le durcissement NSEC/NSEC3 en particulier, voir {{< relref "/reference/checkers/dnssec" >}}.