config.yml

@@ -1,10 +1,10 @@
 baseURL: https://help.happydomain.org/
 defaultContentLanguage: en
 defaultContentLanguageInSubdir: true
-enableGitInfo: true
 
 theme: hugo-theme-relearn
 
+
 languages:
   en:
     title: "happyDomain help center"
@@ -50,7 +50,6 @@ params:
   # next to it (a single space resolves to an empty logo title).
   linkTitle: " "
   showVisitedLinks: true
-  hideAuthorEmail: true
   mermaid: false
   # "auto" follows the OS light/dark preference: light -> green, dark ->
   # relearn-dark. Both must be declared as variants so the theme attaches the
@@ -62,17 +61,6 @@ params:
     - identifier: green
     - identifier: relearn-dark
 
-# The relearn theme attaches CSS classes to generated blocks (e.g. the
-# `children` shortcode appends `{class="children ..."}` after its list).
-# Goldmark only interprets that as block attributes when block parsing is
-# enabled; otherwise it is rendered as literal text.
-markup:
-  goldmark:
-    parser:
-      attribute:
-        block: true
-    renderer:
-      unsafe: true
 
 outputs:
-  home: ["HTML", "RSS", "PRINT"]
+  home: [ "HTML", "RSS", "PRINT"]

content/_index.en.md

@@ -4,6 +4,9 @@ title: Welcome to happyDomain
 author: Frederic
 description: "Finally a simple interface for domain names."
 archetype: home
+aliases:
+    en/pages/login
+    en/pages/signup
 ---
 
 happyDomain is an interface that centralize your domain names and reduces the usual friction points.
@@ -15,15 +18,13 @@ 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,
-- abstract all technical complexity into a logical view,
-- 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,
+- clearly visualize the changes that will be propagated,
-- keep a history of changes and roll back to a previous zone state with a single click,
+- keep a history of changes made to the zone,
-- monitor your domains and services with automatic checks (expiration, DNSSEC, response time, etc.),
+- return to a previous zone status with a single click,
-- get notified as soon as a check changes state,
+- group records by services/needs: email, delegation, server, load balancing, etc.
-- check whether a domain is available for registration and inspect any domain (WHOIS, DNS resolver),
+- abstract all technical complexity into a logical view,
-- import/export the zone as a standard file (BIND format),
+- import/export the zone as a standard file,
 - keep track of actions for later auditing,
 - automate tasks via a REST API.
 

content/_index.fr.md

@@ -4,6 +4,9 @@ title: happyDomain
 description: "L'interface des noms de domaine."
 author: nemunaire
 archetype: home
+aliases:
+    fr/pages/login
+    fr/pages/signup
 ---
 
 happyDomain est une interface qui centralise vos noms de domaines et réduit les points de friction habituels.
@@ -15,15 +18,13 @@ 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é,
-- abstraire toute la complexité technique en une vue logique,
-- 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,
+- visualiser clairement les changements qui seront propagés,
-- garder un historique des changements et revenir à un état antérieur de la zone en un clic,
+- garder un historique des changements effectués sur la zone,
-- surveiller vos domaines et services grâce à des vérifications automatiques (expiration, DNSSEC, temps de réponse, ...),
+- pouvoir revenir à un état antérieur de la zone en un clic,
-- être alerté par notifications dès qu'une vérification change d'état,
+- regrouper les enregistrements par services/besoins : emails, délégation, serveur, répartition de charge, ...
-- vérifier la disponibilité d'un domaine à l'enregistrement et inspecter n'importe quel domaine (WHOIS, résolveur DNS),
+- abstraire toute la complexité technique en une vue logique,
-- importer/exporter la zone sous forme d'un fichier standard (format BIND),
+- importer/exporter la zone sous forme d'un fichier standard,
 - garder une trace des actions pour les auditer plus tard,
 - automatiser des tâches via une API REST.
 

content/introduction/deploy/docker.en.md

@@ -7,335 +7,69 @@ weight: 15
 happyDomain is sponsored by Docker.
 You'll find the official container image on [the Docker Hub](https://hub.docker.com/r/happydomain/happydomain/).
 
-The image runs happyDomain as a single process with a LevelDB database stored on disk — no extra database to configure.
+This image will run happyDomain as a single process, with a LevelDB database (similarly to sqlite, LevelDB is stored on disk, no need to configure anything).
 
 
 ## Supported tags and architectures
 
-All tags are built for `amd64`, `arm64` and `arm/v7` and are based on Alpine.
+All tags are build for `amd64`, `arm64` and `arm/v7` and are based on alpine.
 
-Currently available tags:
+Currently, available tags are:
 
-- `latest`: the most up-to-date version, corresponding to the master branch.
+- `latest`: this is a the most up to date version, corresponding to the master branch.
 
+## Using this image
 
-## Quick start (single container)
+### For testing purpose
 
-For a quick test or personal use, pass `HAPPYDOMAIN_NO_AUTH=1` to skip account management:
+You can test happyDomain or use it for your own usage, with the option `HAPPYDOMAIN_NO_AUTH=1`: this will automatically creates a default account, and disable all features related to the user management (signup, login, ...).
 
 ```
 docker run -e HAPPYDOMAIN_NO_AUTH=1 -p 8081:8081 happydomain/happydomain
 ```
 
-Data are stored inside the container. To keep them across restarts, attach a volume:
+Data are stored in `/data` directory. If you want to keep your settings from one run to another, you'll need to attach this directory to a Docker managed volume or to a directory on your host:
 
 ```
 docker volume create happydomain_data
 docker run -e HAPPYDOMAIN_NO_AUTH=1 -v happydomain_data:/data -p 8081:8081 happydomain/happydomain
 ```
 
-For a production single-container setup that sends e-mail:
+### In production
+
+happyDomain needs to send e-mail, in order to verify addresses and doing password recovery, so you need basically to configure a SMTP relay.
+Use the options `HAPPYDOMAIN_MAIL_SMTP_HOST`, `HAPPYDOMAIN_MAIL_SMTP_PORT` (default 25), `HAPPYDOMAIN_MAIL_SMTP_USERNAME` and `HAPPYDOMAIN_MAIL_SMTP_PASSWORD` for this purpose:
 
 ```
-docker run \
+docker run -e HAPPYDOMAIN_MAIL_SMTP_HOST=smtp.yourcompany.com -e HAPPYDOMAIN_MAIL_SMTP_USERNAME=happydomain -e HAPPYDOMAIN_MAIL_SMTP_PASSWORD=secret -v /var/lib/happydomain:/data -p 8081:8081 happydomain/happydomain
-  -e HAPPYDOMAIN_MAIL_SMTP_HOST=smtp.yourcompany.com \
+```
-  -e HAPPYDOMAIN_MAIL_SMTP_USERNAME=happydomain \
+
-  -e HAPPYDOMAIN_MAIL_SMTP_PASSWORD=secret \
+If you prefer using a configuration file, you can place it either in `/data/happydomain.conf` to use the volume, or bind your file to `/etc/happydomain.conf`:
-  -v /var/lib/happydomain:/data \
+
-  -p 8081:8081 \
+```
-  happydomain/happydomain
+docker run -v happydomain.conf:/etc/happydomain.conf -p 8081:8081 happydomain/happydomain
+```
+
+#### Extend the base image
+
+By default, happyDomain uses `sendmail`, if you prefer, you can create you own image with the package `ssmtp`:
+
+```
+FROM happydomain/happydomain
+RUN apk --no-cache add ssmtp
+COPY my_ssmtp.conf /etc/ssmtp/ssmtp.conf
 ```
 
 
-## Full deployment with all checkers
+## Admin Interface
 
-happyDomain ships every checker built-in, but several of them rely on
+happyDomain exposes some administration command through a unix socket. The docker container contains a script to access this admin part: `hadmin`.
-external tools (DNSViz, Zonemaster, Matrix federation tester) that are
-packaged in their own container images. Running these as separate services
-gives you the full checker experience and better isolation.
 
-The recommended approach is `docker compose`. Save the following file as
+You can use it this way:
-`docker-compose.yml` and run `docker compose up -d`.
-
-```yaml
-services:
-  happydomain:
-    image: happydomain/happydomain
-    ports:
-      - "8080:8081"
-    environment:
-      # Uncomment for single-user / testing
-      # HAPPYDOMAIN_NO_AUTH: "1"
-
-      # Mail configuration (required for multi-user production use)
-      # HAPPYDOMAIN_MAIL_SMTP_HOST: "mailer"
-
-      # ── DNS / DNSSEC ─────────────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_DNSVIZ_ENDPOINT: "http://checker-dnsviz:8080"
-      HAPPYDOMAIN_CHECKER_DNSSEC_ENDPOINT: "http://checker-dnssec:8080"
-      HAPPYDOMAIN_CHECKER_ZONEMASTER_ENDPOINT: "http://checker-zonemaster:8080"
-      HAPPYDOMAIN_CHECKER_ZONEMASTER_ZONEMASTERAPIURL: "http://zonemaster:5000"
-      HAPPYDOMAIN_CHECKER_DELEGATION_ENDPOINT: "http://checker-delegation:8080"
-      HAPPYDOMAIN_CHECKER_AUTHORITATIVE_CONSISTENCY_ENDPOINT: "http://checker-authoritative-consistency:8080"
-      HAPPYDOMAIN_CHECKER_ALIAS_ENDPOINT: "http://checker-alias:8080"
-      HAPPYDOMAIN_CHECKER_LEGACY_RECORDS_ENDPOINT: "http://checker-legacy-records:8080"
-      HAPPYDOMAIN_CHECKER_NS_RESTRICTIONS_ENDPOINT: "http://checker-ns-restrictions:8080"
-      HAPPYDOMAIN_CHECKER_RESOLVER_PROPAGATION_ENDPOINT: "http://checker-resolver-propagation:8080"
-      HAPPYDOMAIN_CHECKER_REVERSE_ZONE_ENDPOINT: "http://checker-reverse-zone:8080"
-      HAPPYDOMAIN_CHECKER_PTR_ENDPOINT: "http://checker-ptr:8080"
-      HAPPYDOMAIN_CHECKER_DANGLING_ENDPOINT: "http://checker-dangling:8080"
-
-      # ── Security / Certificates ───────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_TLS_ENDPOINT: "http://checker-tls:8080"
-      HAPPYDOMAIN_CHECKER_DANE_ENDPOINT: "http://checker-dane:8080"
-      HAPPYDOMAIN_CHECKER_CAA_ENDPOINT: "http://checker-caa:8080"
-      HAPPYDOMAIN_CHECKER_BLACKLIST_ENDPOINT: "http://checker-blacklist:8080"
-
-      # ── E-mail ────────────────────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_SMTP_ENDPOINT: "http://checker-smtp:8080"
-      HAPPYDOMAIN_CHECKER_EMAIL_AUTOCONFIG_ENDPOINT: "http://checker-email-autoconfig:8080"
-      HAPPYDOMAIN_CHECKER_OPENPGPKEY_SMIMEA_ENDPOINT: "http://checker-email-keys:8080"
-
-      # ── Web & Protocols ───────────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_HTTP_ENDPOINT: "http://checker-http:8080"
-      HAPPYDOMAIN_CHECKER_SSH_ENDPOINT: "http://checker-ssh:8080"
-      HAPPYDOMAIN_CHECKER_PING_ENDPOINT: "http://checker-ping:8080"
-      HAPPYDOMAIN_CHECKER_SRV_ENDPOINT: "http://checker-srv:8080"
-
-      # ── Collaboration / Messaging ─────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_MATRIXIM_ENDPOINT: "http://checker-matrix:8080"
-      HAPPYDOMAIN_CHECKER_MATRIXIM_FEDERATIONTESTERSERVER: "http://matrixfederationtester:8080/api/report?server_name=%s"
-      HAPPYDOMAIN_CHECKER_XMPP_ENDPOINT: "http://checker-xmpp:8080"
-      HAPPYDOMAIN_CHECKER_SIP_ENDPOINT: "http://checker-sip:8080"
-
-      # ── Directory & Auth ──────────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_LDAP_ENDPOINT: "http://checker-ldap:8080"
-      HAPPYDOMAIN_CHECKER_KERBEROS_ENDPOINT: "http://checker-kerberos:8080"
-      HAPPYDOMAIN_CHECKER_STUNTURN_ENDPOINT: "http://checker-stun-turn:8080"
-
-      # ── CalDAV / CardDAV ──────────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_CALDAV_ENDPOINT: "http://checker-caldav:8080"
-      HAPPYDOMAIN_CHECKER_CARDDAV_ENDPOINT: "http://checker-carddav:8080"
-
-      # ── Optional: happyDeliver integration ────────────────────────────────
-      # HAPPYDOMAIN_CHECKER_HAPPYDELIVER_ENDPOINT: "http://checker-happydeliver:8080"
-
-    restart: unless-stopped
-    volumes:
-      - storage:/var/lib/happydomain:rw
-
-  # ── DNS / DNSSEC checkers ──────────────────────────────────────────────────
-
-  checker-dnsviz:
-    image: happydomain/checker-dnsviz
-    restart: unless-stopped
-
-  checker-dnssec:
-    image: happydomain/checker-dnssec
-    restart: unless-stopped
-
-  checker-zonemaster:
-    image: happydomain/checker-zonemaster
-    restart: unless-stopped
-
-  zonemaster:
-    image: zonemaster/backend
-    command: full
-    restart: unless-stopped
-
-  checker-delegation:
-    image: happydomain/checker-delegation
-    restart: unless-stopped
-
-  checker-authoritative-consistency:
-    image: happydomain/checker-authoritative-consistency
-    restart: unless-stopped
-
-  checker-alias:
-    image: happydomain/checker-alias
-    restart: unless-stopped
-
-  checker-legacy-records:
-    image: happydomain/checker-legacy-records
-    restart: unless-stopped
-
-  checker-ns-restrictions:
-    image: happydomain/checker-ns-restrictions
-    restart: unless-stopped
-
-  checker-resolver-propagation:
-    image: happydomain/checker-resolver-propagation
-    restart: unless-stopped
-
-  checker-reverse-zone:
-    image: happydomain/checker-reverse-zone
-    restart: unless-stopped
-
-  checker-ptr:
-    image: happydomain/checker-ptr
-    restart: unless-stopped
-
-  checker-dangling:
-    image: happydomain/checker-dangling
-    restart: unless-stopped
-
-  # ── Security / Certificate checkers ───────────────────────────────────────
-
-  checker-tls:
-    image: happydomain/checker-tls
-    restart: unless-stopped
-
-  checker-dane:
-    image: happydomain/checker-dane
-    restart: unless-stopped
-
-  checker-caa:
-    image: happydomain/checker-caa
-    restart: unless-stopped
-
-  checker-blacklist:
-    image: happydomain/checker-blacklist
-    restart: unless-stopped
-
-  # ── E-mail checkers ────────────────────────────────────────────────────────
-
-  checker-smtp:
-    image: happydomain/checker-smtp
-    restart: unless-stopped
-
-  checker-email-autoconfig:
-    image: happydomain/checker-email-autoconfig
-    restart: unless-stopped
-
-  checker-email-keys:
-    image: happydomain/checker-email-keys
-    restart: unless-stopped
-
-  # ── Web & Protocol checkers ────────────────────────────────────────────────
-
-  checker-http:
-    image: happydomain/checker-http
-    restart: unless-stopped
-
-  checker-ssh:
-    image: happydomain/checker-ssh
-    restart: unless-stopped
-
-  checker-ping:
-    image: happydomain/checker-ping
-    restart: unless-stopped
-    cap_add:
-      - NET_RAW  # required for ICMP ping
-
-  checker-srv:
-    image: happydomain/checker-srv
-    restart: unless-stopped
-
-  # ── Collaboration / Messaging checkers ─────────────────────────────────────
-
-  checker-matrix:
-    image: happydomain/checker-matrix
-    restart: unless-stopped
-
-  matrixfederationtester:
-    image: matrixdotorg/federation-tester-backend
-    environment:
-      BIND_ADDRESS: "0.0.0.0:8080"
-    restart: unless-stopped
-
-  checker-xmpp:
-    image: happydomain/checker-xmpp
-    restart: unless-stopped
-
-  checker-sip:
-    image: happydomain/checker-sip
-    restart: unless-stopped
-
-  # ── Directory & Auth checkers ──────────────────────────────────────────────
-
-  checker-ldap:
-    image: happydomain/checker-ldap
-    restart: unless-stopped
-
-  checker-kerberos:
-    image: happydomain/checker-kerberos
-    restart: unless-stopped
-
-  checker-stun-turn:
-    image: happydomain/checker-stun-turn
-    restart: unless-stopped
-
-  # ── CalDAV / CardDAV checkers ──────────────────────────────────────────────
-
-  checker-caldav:
-    image: happydomain/checker-caldav
-    restart: unless-stopped
-
-  checker-carddav:
-    image: happydomain/checker-carddav
-    restart: unless-stopped
-
-volumes:
-  storage:
-```
-
-### How it works
-
-Each checker runs as a standalone HTTP service. happyDomain delegates check
-requests to the matching container via the `HAPPYDOMAIN_CHECKER_<ID>_ENDPOINT`
-environment variable. When an endpoint is not set, the corresponding checker
-runs locally inside the happyDomain process instead.
-
-Two checkers rely on additional third-party backends:
-
-- **Zonemaster** (`checker-zonemaster`) queries the `zonemaster/backend`
-  service. The `HAPPYDOMAIN_CHECKER_ZONEMASTER_ZONEMASTERAPIURL` variable tells
-  the checker where that backend listens.
-- **Matrix federation tester** (`checker-matrix`) queries the
-  `matrixdotorg/federation-tester-backend` service. The
-  `HAPPYDOMAIN_CHECKER_MATRIXIM_FEDERATIONTESTERSERVER` variable points to its
-  report endpoint.
-
-### Optional: happyDeliver
-
-If you run a [happyDeliver](https://happydeliver.io) instance for mail-flow
-monitoring, uncomment the `HAPPYDOMAIN_CHECKER_HAPPYDELIVER_ENDPOINT` line and
-add the corresponding service:
-
-```yaml
-  checker-happydeliver:
-    image: happydomain/checker-happydeliver
-    restart: unless-stopped
-```
-
-### Optional: blacklist API keys
-
-The `checker-blacklist` service works without API keys (it uses DNS-based
-blocklists by default), but you can enable additional sources — Google Safe
-Browsing, VirusTotal, abuse.ch URLhaus — by configuring the matching admin
-options from the happyDomain administration interface once the stack is running.
-
-
-## Admin interface
-
-happyDomain exposes administration commands through a Unix socket. The
-container includes the `hadmin` wrapper:
 
 ```
 docker exec my_container hadmin /api/users
 docker exec my_container hadmin /api/users/0123456789/send_validation_email -X POST
 ```
 
-`hadmin` is a thin wrapper around `curl` — start with the URL path, then add
+This is in fact a wrapper above `curl`, but you have to start by the URL, and place options after it.
-any `curl` options after it.
-
-
-## Using a configuration file
-
-Instead of environment variables, you can place a configuration file either in
-`/data/happydomain.conf` (inside the data volume) or bind-mount it to
-`/etc/happydomain.conf`:
-
-```
-docker run -v happydomain.conf:/etc/happydomain.conf -p 8081:8081 happydomain/happydomain
-```

content/introduction/deploy/docker.fr.md

@@ -4,340 +4,78 @@ title: Avec Docker
 weight: 15
 ---
 
-happyDomain est sponsorisé par Docker.
+happyDomain est sponsorisé Docker.
 Vous trouverez notre image officielle sur [le Docker Hub](https://hub.docker.com/r/happydomain/happydomain/).
 
-L'image exécute happyDomain en tant que processus unique avec une base de données LevelDB stockée sur le disque — aucune base de données supplémentaire à configurer.
+Cette image exécutera happyDomain en tant que processus unique, avec une base de données LevelDB (similaire à sqlite, LevelDB est une base de données stockée sur le disque, il n'est pas nécessaire de configurer quoi que ce soit d'autre).
 
 
-## Versions, étiquettes et architectures supportées
+## Versions, étiquettes and architectures supportés
 
-Toutes les étiquettes (*tags*) sont construites pour `amd64`, `arm64` et `arm/v7` et sont basées sur Alpine.
+Toutes les étiquettes (*tags*) sont construites pour les architectures de processeur les plus courantes (`amd64`, `arm64` et `arm/v7`).
+Nous ne construisons des images uniquement basées sur la distribution Alpine Linux, ce qui assure des images de taille minimale.
 
-Les étiquettes actuellement disponibles :
+Actuellement, les étiquettes disponibles sont :
 
-- `latest` : la version la plus récente, correspondant à la branche `master` de notre dépôt.
+- `latest`: il s'agit de la version la plus récente, correspondant à la branche `master` de notre dépôt de sources.
 
 
-## Démarrage rapide (conteneur unique)
+## Utilisation de l'image
 
-Pour un test rapide ou un usage personnel, utilisez `HAPPYDOMAIN_NO_AUTH=1` pour désactiver la gestion des comptes :
+### À des fins de test
+
+Vous pouvez tester happyDomain ou l'utiliser pour votre usage personnel, avec l'option `HAPPYDOMAIN_NO_AUTH=1` : cela créera automatiquement un compte par défaut, et désactivera toutes les fonctionnalités liées à la gestion des utilisateurs (inscription, connexion, ...).
 
 ```
 docker run -e HAPPYDOMAIN_NO_AUTH=1 -p 8081:8081 happydomain/happydomain
 ```
 
-Les données sont stockées à l'intérieur du conteneur. Pour les conserver entre les redémarrages, attachez un volume :
+Les données sont stockées dans le répertoire `/data`.
+Si vous souhaitez conserver vos paramètres d'une exécution à l'autre, vous devrez attacher ce répertoire à un volume géré par Docker ou à un répertoire sur votre hôte :
 
 ```
 docker volume create happydomain_data
 docker run -e HAPPYDOMAIN_NO_AUTH=1 -v happydomain_data:/data -p 8081:8081 happydomain/happydomain
 ```
 
-Pour une instance de production avec envoi d'e-mails :
+
+### En production
+
+happyDomain a besoin d'envoyer du courrier électronique, afin de vérifier les adresses et d'effectuer la récupération des mots de passe, vous devez donc configurer un relais SMTP.
+Utilisez les options `HAPPYDOMAIN_MAIL_SMTP_HOST`, `HAPPYDOMAIN_MAIL_SMTP_PORT` (par défaut 25), `HAPPYDOMAIN_MAIL_SMTP_USERNAME` et `HAPPYDOMAIN_MAIL_SMTP_PASSWORD` à cette fin :
 
 ```
-docker run \
+docker run -e HAPPYDOMAIN_MAIL_SMTP_HOST=smtp.yourcompany.com -e HAPPYDOMAIN_MAIL_SMTP_USERNAME=happydomain -e HAPPYDOMAIN_MAIL_SMTP_PASSWORD=secret -v /var/lib/happydomain:/data -p 8081:8081 happydomain/happydomain
-  -e HAPPYDOMAIN_MAIL_SMTP_HOST=smtp.votreentreprise.com \
+```
-  -e HAPPYDOMAIN_MAIL_SMTP_USERNAME=happydomain \
+
-  -e HAPPYDOMAIN_MAIL_SMTP_PASSWORD=secret \
+Si vous préférez utiliser un fichier de configuration, vous pouvez le placer soit dans `/data/happydomain.conf` pour utiliser le volume, soit lier votre fichier à `/etc/happydomain.conf` :
-  -v /var/lib/happydomain:/data \
+
-  -p 8081:8081 \
+```
-  happydomain/happydomain
+docker run -v happydomain.conf:/etc/happydomain.conf -p 8081:8081 happydomain/happydomain
 ```
 
 
-## Déploiement complet avec tous les vérificateurs
+#### Étendre l'image de base
 
-happyDomain intègre tous les vérificateurs (*checkers*) en natif, mais certains
+Par défaut, happyDomain utilise `sendmail`, si vous préférez, vous pouvez créer votre propre image avec le paquet `ssmtp` :
-d'entre eux s'appuient sur des outils externes (DNSViz, Zonemaster, Matrix
-federation tester) distribués dans leurs propres images Docker. Les faire
-tourner comme des services séparés vous donne l'expérience complète des
-vérificateurs et une meilleure isolation.
 
-L'approche recommandée est `docker compose`. Enregistrez le fichier suivant
-sous le nom `docker-compose.yml` et lancez `docker compose up -d`.
-
-```yaml
-services:
-  happydomain:
-    image: happydomain/happydomain
-    ports:
-      - "8080:8081"
-    environment:
-      # Décommentez pour un usage mono-utilisateur / test
-      # HAPPYDOMAIN_NO_AUTH: "1"
-
-      # Configuration mail (obligatoire en production multi-utilisateurs)
-      # HAPPYDOMAIN_MAIL_SMTP_HOST: "mailer"
-
-      # ── DNS / DNSSEC ─────────────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_DNSVIZ_ENDPOINT: "http://checker-dnsviz:8080"
-      HAPPYDOMAIN_CHECKER_DNSSEC_ENDPOINT: "http://checker-dnssec:8080"
-      HAPPYDOMAIN_CHECKER_ZONEMASTER_ENDPOINT: "http://checker-zonemaster:8080"
-      HAPPYDOMAIN_CHECKER_ZONEMASTER_ZONEMASTERAPIURL: "http://zonemaster:5000"
-      HAPPYDOMAIN_CHECKER_DELEGATION_ENDPOINT: "http://checker-delegation:8080"
-      HAPPYDOMAIN_CHECKER_AUTHORITATIVE_CONSISTENCY_ENDPOINT: "http://checker-authoritative-consistency:8080"
-      HAPPYDOMAIN_CHECKER_ALIAS_ENDPOINT: "http://checker-alias:8080"
-      HAPPYDOMAIN_CHECKER_LEGACY_RECORDS_ENDPOINT: "http://checker-legacy-records:8080"
-      HAPPYDOMAIN_CHECKER_NS_RESTRICTIONS_ENDPOINT: "http://checker-ns-restrictions:8080"
-      HAPPYDOMAIN_CHECKER_RESOLVER_PROPAGATION_ENDPOINT: "http://checker-resolver-propagation:8080"
-      HAPPYDOMAIN_CHECKER_REVERSE_ZONE_ENDPOINT: "http://checker-reverse-zone:8080"
-      HAPPYDOMAIN_CHECKER_PTR_ENDPOINT: "http://checker-ptr:8080"
-      HAPPYDOMAIN_CHECKER_DANGLING_ENDPOINT: "http://checker-dangling:8080"
-
-      # ── Sécurité / Certificats ────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_TLS_ENDPOINT: "http://checker-tls:8080"
-      HAPPYDOMAIN_CHECKER_DANE_ENDPOINT: "http://checker-dane:8080"
-      HAPPYDOMAIN_CHECKER_CAA_ENDPOINT: "http://checker-caa:8080"
-      HAPPYDOMAIN_CHECKER_BLACKLIST_ENDPOINT: "http://checker-blacklist:8080"
-
-      # ── E-mail ────────────────────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_SMTP_ENDPOINT: "http://checker-smtp:8080"
-      HAPPYDOMAIN_CHECKER_EMAIL_AUTOCONFIG_ENDPOINT: "http://checker-email-autoconfig:8080"
-      HAPPYDOMAIN_CHECKER_OPENPGPKEY_SMIMEA_ENDPOINT: "http://checker-email-keys:8080"
-
-      # ── Web & Protocoles ──────────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_HTTP_ENDPOINT: "http://checker-http:8080"
-      HAPPYDOMAIN_CHECKER_SSH_ENDPOINT: "http://checker-ssh:8080"
-      HAPPYDOMAIN_CHECKER_PING_ENDPOINT: "http://checker-ping:8080"
-      HAPPYDOMAIN_CHECKER_SRV_ENDPOINT: "http://checker-srv:8080"
-
-      # ── Collaboration / Messagerie ────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_MATRIXIM_ENDPOINT: "http://checker-matrix:8080"
-      HAPPYDOMAIN_CHECKER_MATRIXIM_FEDERATIONTESTERSERVER: "http://matrixfederationtester:8080/api/report?server_name=%s"
-      HAPPYDOMAIN_CHECKER_XMPP_ENDPOINT: "http://checker-xmpp:8080"
-      HAPPYDOMAIN_CHECKER_SIP_ENDPOINT: "http://checker-sip:8080"
-
-      # ── Annuaire & Authentification ───────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_LDAP_ENDPOINT: "http://checker-ldap:8080"
-      HAPPYDOMAIN_CHECKER_KERBEROS_ENDPOINT: "http://checker-kerberos:8080"
-      HAPPYDOMAIN_CHECKER_STUNTURN_ENDPOINT: "http://checker-stun-turn:8080"
-
-      # ── CalDAV / CardDAV ──────────────────────────────────────────────────
-      HAPPYDOMAIN_CHECKER_CALDAV_ENDPOINT: "http://checker-caldav:8080"
-      HAPPYDOMAIN_CHECKER_CARDDAV_ENDPOINT: "http://checker-carddav:8080"
-
-      # ── Optionnel : intégration happyDeliver ──────────────────────────────
-      # HAPPYDOMAIN_CHECKER_HAPPYDELIVER_ENDPOINT: "http://checker-happydeliver:8080"
-
-    restart: unless-stopped
-    volumes:
-      - storage:/var/lib/happydomain:rw
-
-  # ── Vérificateurs DNS / DNSSEC ─────────────────────────────────────────────
-
-  checker-dnsviz:
-    image: happydomain/checker-dnsviz
-    restart: unless-stopped
-
-  checker-dnssec:
-    image: happydomain/checker-dnssec
-    restart: unless-stopped
-
-  checker-zonemaster:
-    image: happydomain/checker-zonemaster
-    restart: unless-stopped
-
-  zonemaster:
-    image: zonemaster/backend
-    command: full
-    restart: unless-stopped
-
-  checker-delegation:
-    image: happydomain/checker-delegation
-    restart: unless-stopped
-
-  checker-authoritative-consistency:
-    image: happydomain/checker-authoritative-consistency
-    restart: unless-stopped
-
-  checker-alias:
-    image: happydomain/checker-alias
-    restart: unless-stopped
-
-  checker-legacy-records:
-    image: happydomain/checker-legacy-records
-    restart: unless-stopped
-
-  checker-ns-restrictions:
-    image: happydomain/checker-ns-restrictions
-    restart: unless-stopped
-
-  checker-resolver-propagation:
-    image: happydomain/checker-resolver-propagation
-    restart: unless-stopped
-
-  checker-reverse-zone:
-    image: happydomain/checker-reverse-zone
-    restart: unless-stopped
-
-  checker-ptr:
-    image: happydomain/checker-ptr
-    restart: unless-stopped
-
-  checker-dangling:
-    image: happydomain/checker-dangling
-    restart: unless-stopped
-
-  # ── Vérificateurs Sécurité / Certificats ───────────────────────────────────
-
-  checker-tls:
-    image: happydomain/checker-tls
-    restart: unless-stopped
-
-  checker-dane:
-    image: happydomain/checker-dane
-    restart: unless-stopped
-
-  checker-caa:
-    image: happydomain/checker-caa
-    restart: unless-stopped
-
-  checker-blacklist:
-    image: happydomain/checker-blacklist
-    restart: unless-stopped
-
-  # ── Vérificateurs e-mail ────────────────────────────────────────────────────
-
-  checker-smtp:
-    image: happydomain/checker-smtp
-    restart: unless-stopped
-
-  checker-email-autoconfig:
-    image: happydomain/checker-email-autoconfig
-    restart: unless-stopped
-
-  checker-email-keys:
-    image: happydomain/checker-email-keys
-    restart: unless-stopped
-
-  # ── Vérificateurs Web & Protocoles ─────────────────────────────────────────
-
-  checker-http:
-    image: happydomain/checker-http
-    restart: unless-stopped
-
-  checker-ssh:
-    image: happydomain/checker-ssh
-    restart: unless-stopped
-
-  checker-ping:
-    image: happydomain/checker-ping
-    restart: unless-stopped
-    cap_add:
-      - NET_RAW  # requis pour l'ICMP
-
-  checker-srv:
-    image: happydomain/checker-srv
-    restart: unless-stopped
-
-  # ── Vérificateurs Collaboration / Messagerie ────────────────────────────────
-
-  checker-matrix:
-    image: happydomain/checker-matrix
-    restart: unless-stopped
-
-  matrixfederationtester:
-    image: matrixdotorg/federation-tester-backend
-    environment:
-      BIND_ADDRESS: "0.0.0.0:8080"
-    restart: unless-stopped
-
-  checker-xmpp:
-    image: happydomain/checker-xmpp
-    restart: unless-stopped
-
-  checker-sip:
-    image: happydomain/checker-sip
-    restart: unless-stopped
-
-  # ── Vérificateurs Annuaire & Authentification ───────────────────────────────
-
-  checker-ldap:
-    image: happydomain/checker-ldap
-    restart: unless-stopped
-
-  checker-kerberos:
-    image: happydomain/checker-kerberos
-    restart: unless-stopped
-
-  checker-stun-turn:
-    image: happydomain/checker-stun-turn
-    restart: unless-stopped
-
-  # ── Vérificateurs CalDAV / CardDAV ─────────────────────────────────────────
-
-  checker-caldav:
-    image: happydomain/checker-caldav
-    restart: unless-stopped
-
-  checker-carddav:
-    image: happydomain/checker-carddav
-    restart: unless-stopped
-
-volumes:
-  storage:
 ```
-
+FROM happydomain/happydomain
-### Comment ça fonctionne
+RUN apk --no-cache add ssmtp
-
+COPY my_ssmtp.conf /etc/ssmtp/ssmtp.conf
-Chaque vérificateur tourne comme un service HTTP autonome. happyDomain lui délègue
-les demandes de vérification via la variable d'environnement
-`HAPPYDOMAIN_CHECKER_<ID>_ENDPOINT`. Si aucun point d'accès n'est configuré, le
-vérificateur correspondant s'exécute localement dans le processus happyDomain.
-
-Deux vérificateurs s'appuient sur des services tiers supplémentaires :
-
-- **Zonemaster** (`checker-zonemaster`) interroge le service `zonemaster/backend`.
-  La variable `HAPPYDOMAIN_CHECKER_ZONEMASTER_ZONEMASTERAPIURL` indique au
-  vérificateur l'adresse de ce service.
-- **Matrix federation tester** (`checker-matrix`) interroge le service
-  `matrixdotorg/federation-tester-backend`. La variable
-  `HAPPYDOMAIN_CHECKER_MATRIXIM_FEDERATIONTESTERSERVER` pointe vers son point
-  d'accès de rapport.
-
-### Optionnel : happyDeliver
-
-Si vous exploitez une instance [happyDeliver](https://happydeliver.io) pour
-surveiller les flux e-mail, décommentez la ligne
-`HAPPYDOMAIN_CHECKER_HAPPYDELIVER_ENDPOINT` et ajoutez le service correspondant :
-
-```yaml
-  checker-happydeliver:
-    image: happydomain/checker-happydeliver
-    restart: unless-stopped
 ```
 
-### Optionnel : clés API pour checker-blacklist
-
-Le service `checker-blacklist` fonctionne sans clé API (il utilise des listes
-de blocage DNS par défaut), mais vous pouvez activer des sources supplémentaires
-— Google Safe Browsing, VirusTotal, abuse.ch URLhaus — en configurant les
-options d'administration correspondantes depuis l'interface d'administration de
-happyDomain une fois la pile démarrée.
-
 
 ## Interface d'administration
 
-happyDomain expose des commandes d'administration à travers un socket Unix.
+happyDomain expose certaines commandes d'administration à travers un socket unix.
-Le conteneur inclut l'utilitaire `hadmin` :
+Le conteneur docker contient un script pour accéder à cette partie d'administration : `hadmin`.
+
+Vous pouvez l'utiliser de cette manière :
 
 ```
 docker exec my_container hadmin /api/users
 docker exec my_container hadmin /api/users/0123456789/send_validation_email -X POST
 ```
 
-`hadmin` est une surcouche légère autour de `curl` — commencez par le chemin
+Il s'agit en fait d'une surcouche au-dessus de `curl`, mais vous devez commencer par l'URL, et placer les options après.
-d'URL, puis ajoutez les options `curl` après.
-
-
-## Utilisation d'un fichier de configuration
-
-Plutôt que des variables d'environnement, vous pouvez placer un fichier de
-configuration dans `/data/happydomain.conf` (dans le volume de données) ou le
-monter directement sur `/etc/happydomain.conf` :
-
-```
-docker run -v happydomain.conf:/etc/happydomain.conf -p 8081:8081 happydomain/happydomain
-```

content/pages/_index.en.md

@@ -6,30 +6,4 @@ archetype: chapter
 weight: 10
 ---
 
-This section walks through happyDomain feature by feature, following the path a new user
-takes: from creating an account to publishing a fully managed zone.
-
-You start by [creating an account]({{% relref "signup" %}}) and [logging in]({{% relref "login" %}}),
-then land on the [dashboard]({{% relref "domains" %}}) that centralizes all your domains.
-
-Before importing a domain, you connect a [provider]({{% relref "provider-list" %}}): happyDomain
-[adds]({{% relref "provider-new-choice" %}}) and [configures]({{% relref "provider-update" %}})
-it for you, whatever its [specific features]({{% relref "provider-features" %}}).
-
-You can then [import a domain]({{% relref "domain-new" %}}) and explore it in the
-[zone editor]({{% relref "domain-abstract" %}}), which
-lets you manage [subdomains]({{% relref "subdomains" %}}) and group records into
-[services]({{% relref "services" %}}). Every change is reviewed
-before you [publish]({{% relref "publish-changes" %}}) it, and the
-[history]({{% relref "domain-history" %}}) keeps track of everything. You can also
-[import or export]({{% relref "import-export" %}}) the whole zone as a standard file.
-
-happyDomain also helps you keep an eye on your domains with
-[monitoring and checks]({{% relref "checks" %}}), [availability lookups]({{% relref "domain-availability" %}})
-and the [domain test tool]({{% relref "tools-client" %}}).
-
-Finally, you can fine-tune your account: [your account and settings]({{% relref "settings" %}}),
-[sessions and API access]({{% relref "api-keys" %}}),
-[notifications]({{% relref "notifications" %}}) and [quotas]({{% relref "quotas" %}}).
-
 {{% children %}}

content/pages/_index.fr.md

@@ -5,34 +5,4 @@ archetype: chapter
 weight: 10
 ---
 
-Cette section présente happyDomain fonctionnalité par fonctionnalité, en suivant le
-parcours d'un nouvel utilisateur : de la création de son compte jusqu'à la publication
-d'une zone entièrement gérée.
-
-Vous commencez par [créer un compte]({{% relref "signup" %}}) et
-[vous connecter]({{% relref "login" %}}), puis vous arrivez sur le
-[tableau de bord]({{% relref "domains" %}}) qui centralise tous vos domaines.
-
-Avant d'importer un domaine, vous raccordez un [hébergeur]({{% relref "provider-list" %}}) :
-happyDomain l'[ajoute]({{% relref "provider-new-choice" %}}) et le
-[configure]({{% relref "provider-update" %}}) pour vous, quelles que soient ses
-[particularités]({{% relref "provider-features" %}}).
-
-Vous pouvez alors [importer un domaine]({{% relref "domain-new" %}}) et le consulter dans
-l'[éditeur de zone]({{% relref "domain-abstract" %}}), qui
-vous permet de gérer les [sous-domaines]({{% relref "subdomains" %}}) et de regrouper les
-enregistrements en [services]({{% relref "services" %}}). Chaque modification est
-examinée avant que vous ne la [publiiez]({{% relref "publish-changes" %}}),
-et l'[historique]({{% relref "domain-history" %}}) garde la trace de tout. Vous pouvez aussi
-[importer ou exporter]({{% relref "import-export" %}}) la zone entière sous forme de fichier standard.
-
-happyDomain vous aide également à garder un œil sur vos domaines, grâce à la
-[surveillance et aux vérifications]({{% relref "checks" %}}), aux
-[recherches de disponibilité]({{% relref "domain-availability" %}}) et à
-l'[outil de test de domaine]({{% relref "tools-client" %}}).
-
-Enfin, vous pouvez peaufiner votre compte : [votre compte et vos réglages]({{% relref "settings" %}}),
-les [sessions et accès API]({{% relref "api-keys" %}}), les
-[notifications]({{% relref "notifications" %}}) et les [quotas]({{% relref "quotas" %}}).
-
 {{% children %}}

content/pages/api-keys.en.md

@@ -1,55 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Sessions & API access
-author: nemunaire
-weight: 2200
-description: "Manage your active sessions and use authentication tokens to call the happyDomain REST API"
----
-
-happyDomain does not have a separate "API keys" feature. Instead, every way of accessing the platform, whether through the web interface or the REST API, relies on the same kind of **session token**. Managing your sessions therefore also means managing your API access.
-
-You manage your sessions from the security section of your account, under **Active Sessions**.
-
-<!-- TODO: screenshot of the sessions manager -->
-
-## Listing your active sessions
-
-The list shows every session currently open on your account. For each one you see:
-
-- its **description** (the name given when it was created), followed by a short fingerprint derived from the token;
-- a **current session** badge on the session you are using right now;
-- when it was **created**, when it was **last used**, and when it **expires**.
-
-Sessions are sorted with the most recently used first.
-
-## Creating a token for API access
-
-To obtain a token you can use to call the API:
-
-1. Click **Create API key**.
-2. Give the session a **description** (for example the name of the script or machine that will use it). This helps you recognise it later in the list.
-3. Validate the creation.
-
-The token secret is then displayed **once**. Use the eye button to reveal it and the copy button to put it on your clipboard.
-
-{{% notice style="warning" title="Copy the secret immediately" icon="triangle-exclamation" %}}
-The session secret is shown only at creation time and is never displayed again. Copy it and store it somewhere safe before closing the dialog. If you lose it, delete the session and create a new one.
-{{% /notice %}}
-
-## Using a token with the REST API
-
-The token is passed in the HTTP `Authorization` header as a Bearer token. For example, to list your domains:
-
-```sh
-curl -H "Authorization: Bearer YOUR_SECRET_TOKEN" https://your-happydomain-server/api/domains
-```
-
-Replace `YOUR_SECRET_TOKEN` with the secret you copied, and the host with the address of your happyDomain instance. Any API endpoint is reached the same way, by sending this header with each request.
-
-## Revoking a session
-
-To revoke a session (and the token associated with it), click the delete button on its row. The token stops working immediately. You cannot delete the session you are currently using from this list; to end it, simply log out, or use the option below.
-
-{{% notice style="info" title="Terminate all sessions" icon="circle-info" %}}
-The **Terminate all sessions** button closes every session at once, including the one you are using. This is useful if you suspect a token has leaked: all existing tokens become invalid and you are sent back to the [login page]({{% relref "login" %}}). You will then need to log in again and recreate any API tokens you still need.
-{{% /notice %}}

content/pages/api-keys.fr.md

@@ -1,54 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Sessions et accès à l'API
-weight: 2200
-description: "Gérez vos sessions actives et utilisez les jetons d'authentification pour appeler l'API REST de happyDomain"
----
-
-happyDomain ne propose pas de fonctionnalité distincte de « clés d'API ». À la place, toutes les façons d'accéder à la plateforme, que ce soit via l'interface web ou via l'API REST, reposent sur le même type de **jeton de session**. Gérer ses sessions revient donc aussi à gérer ses accès à l'API.
-
-Vous gérez vos sessions depuis la section sécurité de votre compte, sous « Sessions actives ».
-
-<!-- TODO: screenshot of the sessions manager -->
-
-## Lister vos sessions actives
-
-La liste présente toutes les sessions actuellement ouvertes sur votre compte. Pour chacune, vous voyez :
-
-- sa **description** (le nom donné lors de sa création), suivie d'une courte empreinte dérivée du jeton ;
-- un badge « session actuelle » sur la session que vous utilisez en ce moment ;
-- sa date de **création**, sa date de **dernière utilisation** et sa date d'**expiration**.
-
-Les sessions sont triées de la plus récemment utilisée à la plus ancienne.
-
-## Créer un jeton pour accéder à l'API
-
-Pour obtenir un jeton utilisable pour appeler l'API :
-
-1. Cliquez sur « Créer une clé d'API ».
-2. Donnez une **description** à la session (par exemple le nom du script ou de la machine qui l'utilisera). Cela vous aidera à la reconnaître plus tard dans la liste.
-3. Validez la création.
-
-Le secret du jeton est alors affiché **une seule fois**. Utilisez le bouton en forme d'œil pour le révéler et le bouton de copie pour le placer dans votre presse-papiers.
-
-{{% notice style="warning" title="Copiez le secret immédiatement" icon="triangle-exclamation" %}}
-Le secret de la session n'est affiché qu'au moment de sa création et n'est plus jamais montré ensuite. Copiez-le et conservez-le en lieu sûr avant de fermer la fenêtre. En cas de perte, supprimez la session et créez-en une nouvelle.
-{{% /notice %}}
-
-## Utiliser un jeton avec l'API REST
-
-Le jeton se transmet dans l'en-tête HTTP `Authorization`, en tant que jeton « Bearer ». Par exemple, pour lister vos domaines :
-
-```sh
-curl -H "Authorization: Bearer VOTRE_JETON_SECRET" https://votre-serveur-happydomain/api/domains
-```
-
-Remplacez `VOTRE_JETON_SECRET` par le secret que vous avez copié, et l'hôte par l'adresse de votre instance happyDomain. On atteint n'importe quel point d'accès de l'API de la même manière, en envoyant cet en-tête à chaque requête.
-
-## Révoquer une session
-
-Pour révoquer une session (et le jeton qui lui est associé), cliquez sur le bouton de suppression sur sa ligne. Le jeton cesse aussitôt de fonctionner. Vous ne pouvez pas supprimer depuis cette liste la session que vous utilisez actuellement ; pour y mettre fin, déconnectez-vous simplement, ou utilisez l'option ci-dessous.
-
-{{% notice style="info" title="Fermer toutes les sessions" icon="circle-info" %}}
-Le bouton « Fermer toutes les sessions » referme l'ensemble des sessions d'un coup, y compris celle que vous utilisez. C'est utile si vous soupçonnez la fuite d'un jeton : tous les jetons existants deviennent invalides et vous êtes renvoyé vers la [page de connexion]({{% relref "login" %}}). Il vous faudra alors vous reconnecter et recréer les jetons d'API dont vous avez encore besoin.
-{{% /notice %}}

content/pages/checks.en.md

@@ -1,174 +0,0 @@
----
-date: 2026-04-05T12:00:00+02:00
-title: Monitoring & Checks
-author: nemunaire
-weight: 1700
-description: "Set up automated health checks to monitor your domains and services"
----
-
-happyDomain includes a built-in monitoring system that lets you run automated health checks on your domains and services. Checkers periodically collect data (such as ping response times, domain expiry dates, or DNS audit results), evaluate it against thresholds you define, and report a clear status: OK, Warning, Critical, or Error.
-
-## Browsing available checkers
-
-You can see all available checkers by navigating to the **Checkers** page from the main menu.
-
-<!-- TODO: screenshot of the checkers list page -->
-
-Each checker is labelled with the scope it applies to:
-
-- **Domain-level**: checks that concern the domain itself, independent of DNS records (e.g. domain expiry via WHOIS).
-- **Zone-level**: checks that need the full zone content (e.g. DNSSEC validation).
-- **Service-level**: checks that target a specific service on a subdomain (e.g. ping, HTTP check).
-
-Use the search bar to filter checkers by name. Click on a checker to see its description and configuration options.
-
-
-## Configuring a checker for your domain
-
-To set up a checker on one of your domains:
-
-1. Go to your domain's page and open the **Checks** tab.
-2. You will see a table of checkers available for this domain. Click **Configure** next to the checker you want to set up.
-
-<!-- TODO: screenshot of the domain checks list -->
-
-On the configuration page, you will find several sections:
-
-### Checker options
-
-Options are grouped by category:
-
-- **Admin Options** -- system-wide settings controlled by the administrator (read-only for regular users).
-- **Configuration** -- user-level preferences such as warning and critical thresholds. These are the main settings you will adjust.
-- **Domain-specific Settings** -- values automatically filled in based on the domain being checked (e.g. the domain name itself).
-- **Checker Parameters** -- additional runtime parameters.
-
-Fill in or adjust the options to match your needs, then click **Save**.
-
-<!-- TODO: screenshot of the checker configuration page with options -->
-
-### Rules
-
-Each checker comes with one or more **rules** that evaluate different aspects of the collected data. For example, a ping checker might have separate rules for latency and packet loss.
-
-You can enable or disable individual rules using the toggle switches. Each rule may also have its own specific options that you can configure.
-
-<!-- TODO: screenshot of the rules section with toggles -->
-
-
-## Scheduling automatic checks
-
-Once a checker is configured, you can schedule it to run automatically at a regular interval.
-
-In the **Schedule** section of the checker configuration page:
-
-1. Toggle **Run automatically** to enable scheduling.
-2. Set the **Check interval** (in hours) -- this determines how often the check runs.
-3. The **Next scheduled run** time is displayed so you know when the next execution will happen.
-4. Click **Save** to apply the schedule.
-
-<!-- TODO: screenshot of the schedule card -->
-
-{{% notice style="info" title="Interval limits" icon="clock" %}}
-Each checker defines minimum and maximum intervals to prevent overloading external services. The interface will respect these bounds when you configure the schedule.
-{{% /notice %}}
-
-When scheduling is disabled, the checker can still be run manually at any time.
-
-
-## Running a check manually
-
-You can trigger a check at any time without waiting for the schedule:
-
-1. Navigate to the checker's **Executions** page (from the domain checks list, click **View Results**).
-2. Click **Run Check Now**.
-3. A dialog opens where you can:
-   - Select which rules to run for this execution.
-   - Override options temporarily (these overrides are not saved).
-4. Click **Run Check** to start the execution.
-
-<!-- TODO: screenshot of the Run Check modal -->
-
-A confirmation message will appear with the execution ID. The result will show up in the executions list once the check completes.
-
-
-## Viewing check results
-
-All past executions are listed on the checker's **Executions** page, accessible from your domain's Checks tab by clicking **View Results**.
-
-<!-- TODO: screenshot of the executions list -->
-
-The executions table shows:
-
-| Column | Description |
-|--------|-------------|
-| **Executed at** | When the check ran |
-| **Status** | The result: OK, Warning, Critical, Error, or Unknown |
-| **Message** | A summary of the findings |
-| **Duration** | How long the check took to complete |
-| **Type** | Whether it was a scheduled or manual run |
-
-Click **View** on any execution to see its detailed results.
-
-
-## Understanding execution details
-
-The execution detail page presents the results in the most appropriate format depending on what the checker provides.
-
-### Metrics
-
-When a checker produces metrics (e.g. response time, packet loss percentage), the detail page shows:
-
-- A **line chart** plotting the metric values over time across recent executions.
-- A **data table** listing each metric with its name, value, and unit.
-
-<!-- TODO: screenshot of the metrics chart and table -->
-
-### HTML reports
-
-Some checkers generate rich HTML reports (e.g. detailed DNS audit results). These are rendered directly in the page.
-
-### Raw data
-
-You can always switch to the **Raw JSON** view to inspect the full observation data collected during the execution. Use the view toggle at the top of the report section to switch between Metrics, HTML Report, and Raw JSON.
-
-### Rule evaluations
-
-Each rule that ran during the execution reports its own status and message. You can see the per-rule breakdown to understand which specific aspect triggered a warning or critical status.
-
-<!-- TODO: screenshot of rule evaluation results -->
-
-
-## Service-level checks
-
-Checkers that apply at the service level are configured from the service's own page rather than the domain-level Checks tab.
-
-1. Navigate to your domain, then to the specific subdomain and service.
-2. Open the **Checks** tab for that service.
-3. The workflow is the same as for domain-level checkers: configure options, set up scheduling, run checks, and view results.
-
-Service-level checkers automatically receive information about the service they are attached to (such as IP addresses from a Server service), so they require less manual configuration.
-
-
-## Managing check results
-
-From the executions list, you can:
-
-- **Delete a single result** by clicking the delete action on a specific execution.
-- **Delete all results** for a checker using the bulk delete option (a confirmation dialog will appear).
-
-This can be useful to clean up old data or reset after configuration changes.
-
-
-## Status reference
-
-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 |

content/pages/checks.fr.md

@@ -1,174 +0,0 @@
----
-date: 2026-04-05T12:00:00+02:00
-title: Surveillance & Vérifications
-author: nemunaire
-weight: 1700
-description: "Mettez en place des vérifications automatiques pour surveiller vos domaines et vos services"
----
-
-happyDomain intègre un système de surveillance qui permet de lancer des vérifications automatiques sur vos domaines et vos services. Les vérificateurs collectent périodiquement des données (temps de réponse au ping, date d'expiration d'un domaine ou résultats d'audit DNS, par exemple), les évaluent au regard des seuils que vous définissez et rapportent un statut clair : OK, Avertissement, Critique ou Erreur.
-
-## Parcourir les vérificateurs disponibles
-
-Vous pouvez consulter l'ensemble des vérificateurs disponibles depuis la page **Vérifications**, accessible par le menu principal.
-
-<!-- TODO: screenshot of the checkers list page -->
-
-Chaque vérificateur indique la portée à laquelle il s'applique :
-
-- **Niveau domaine** : vérifications qui concernent le domaine lui-même, indépendamment des enregistrements DNS (par exemple l'expiration du domaine via WHOIS).
-- **Niveau zone** : vérifications qui nécessitent le contenu complet de la zone (par exemple la validation DNSSEC).
-- **Niveau service** : vérifications qui ciblent un service précis sur un sous-domaine (par exemple un ping ou une vérification HTTP).
-
-Utilisez la barre de recherche pour filtrer les vérificateurs par nom. Cliquez sur un vérificateur pour afficher sa description et ses options de configuration.
-
-
-## Configurer un vérificateur pour votre domaine
-
-Pour mettre en place un vérificateur sur l'un de vos domaines :
-
-1. Rendez-vous sur la page de votre domaine et ouvrez l'onglet **Vérifications**.
-2. Un tableau présente les vérificateurs disponibles pour ce domaine. Cliquez sur **Configurer** en regard du vérificateur souhaité.
-
-<!-- TODO: screenshot of the domain checks list -->
-
-La page de configuration regroupe plusieurs sections :
-
-### Options du vérificateur
-
-Les options sont réparties par catégorie :
-
-- **Options d'administration** : paramètres globaux contrôlés par l'administrateur (en lecture seule pour les utilisateurs ordinaires).
-- **Configuration** : préférences au niveau de l'utilisateur, comme les seuils d'avertissement et critique. Ce sont les principaux réglages que vous ajusterez.
-- **Paramètres propres au domaine** : valeurs renseignées automatiquement à partir du domaine vérifié (par exemple le nom de domaine lui-même).
-- **Paramètres du vérificateur** : paramètres d'exécution supplémentaires.
-
-Renseignez ou ajustez les options selon vos besoins, puis cliquez sur **Enregistrer**.
-
-<!-- TODO: screenshot of the checker configuration page with options -->
-
-### Règles
-
-Chaque vérificateur s'accompagne d'une ou plusieurs **règles** qui évaluent différents aspects des données collectées. Un vérificateur de ping peut par exemple comporter des règles distinctes pour la latence et la perte de paquets.
-
-Vous pouvez activer ou désactiver chaque règle à l'aide des interrupteurs. Chaque règle peut également disposer de ses propres options à configurer.
-
-<!-- TODO: screenshot of the rules section with toggles -->
-
-
-## Planifier des vérifications automatiques
-
-Une fois un vérificateur configuré, vous pouvez planifier son exécution automatique à intervalle régulier.
-
-Dans la section **Planification** de la page de configuration du vérificateur :
-
-1. Activez **Exécuter automatiquement** pour mettre en place la planification.
-2. Définissez l'**intervalle de vérification** (en heures) : il détermine la fréquence d'exécution.
-3. L'heure de la **prochaine exécution planifiée** est affichée afin que vous sachiez quand aura lieu la prochaine vérification.
-4. Cliquez sur **Enregistrer** pour appliquer la planification.
-
-<!-- TODO: screenshot of the schedule card -->
-
-{{% notice style="info" title="Limites d'intervalle" icon="clock" %}}
-Chaque vérificateur définit un intervalle minimal et maximal afin d'éviter de surcharger les services externes. L'interface respecte ces bornes lorsque vous configurez la planification.
-{{% /notice %}}
-
-Lorsque la planification est désactivée, le vérificateur peut tout de même être lancé manuellement à tout moment.
-
-
-## Lancer une vérification manuellement
-
-Vous pouvez déclencher une vérification à tout moment, sans attendre la planification :
-
-1. Rendez-vous sur la page **Exécutions** du vérificateur (depuis la liste des vérifications du domaine, cliquez sur **Voir les résultats**).
-2. Cliquez sur **Lancer la vérification**.
-3. Une fenêtre s'ouvre, dans laquelle vous pouvez :
-   - Sélectionner les règles à exécuter pour cette exécution.
-   - Remplacer temporairement certaines options (ces remplacements ne sont pas enregistrés).
-4. Cliquez sur **Lancer la vérification** pour démarrer l'exécution.
-
-<!-- TODO: screenshot of the Run Check modal -->
-
-Un message de confirmation apparaît avec l'identifiant de l'exécution. Le résultat s'affiche dans la liste des exécutions une fois la vérification terminée.
-
-
-## Consulter les résultats des vérifications
-
-Toutes les exécutions passées sont répertoriées sur la page **Exécutions** du vérificateur, accessible depuis l'onglet Vérifications de votre domaine en cliquant sur **Voir les résultats**.
-
-<!-- TODO: screenshot of the executions list -->
-
-Le tableau des exécutions présente :
-
-| Colonne | Description |
-|--------|-------------|
-| **Exécutée le** | Date à laquelle la vérification a été lancée |
-| **Statut** | Le résultat : OK, Avertissement, Critique, Erreur ou Inconnu |
-| **Message** | Un résumé des constats |
-| **Durée** | Le temps qu'a pris la vérification |
-| **Type** | S'il s'agit d'une exécution planifiée ou manuelle |
-
-Cliquez sur **Voir** sur une exécution pour en afficher les résultats détaillés.
-
-
-## Comprendre le détail d'une exécution
-
-La page de détail d'une exécution présente les résultats sous la forme la plus adaptée à ce que fournit le vérificateur.
-
-### Métriques
-
-Lorsqu'un vérificateur produit des métriques (temps de réponse, pourcentage de perte de paquets, etc.), la page de détail affiche :
-
-- Un **graphique en courbes** qui trace l'évolution des valeurs de la métrique au fil des exécutions récentes.
-- Un **tableau de données** qui répertorie chaque métrique avec son nom, sa valeur et son unité.
-
-<!-- TODO: screenshot of the metrics chart and table -->
-
-### Rapports HTML
-
-Certains vérificateurs génèrent des rapports HTML détaillés (par exemple les résultats d'un audit DNS). Ces rapports sont affichés directement dans la page.
-
-### Données brutes
-
-Vous pouvez à tout moment basculer vers la vue **JSON brut** pour examiner l'ensemble des données d'observation collectées durant l'exécution. Utilisez le sélecteur de vue en haut de la section du rapport pour passer de Métriques à Rapport HTML et JSON brut.
-
-### Évaluation des règles
-
-Chaque règle exécutée durant l'exécution rapporte son propre statut et son propre message. Le détail règle par règle permet de comprendre quel aspect précis a déclenché un statut d'avertissement ou critique.
-
-<!-- TODO: screenshot of rule evaluation results -->
-
-
-## Vérifications au niveau service
-
-Les vérificateurs qui s'appliquent au niveau service se configurent depuis la page du service concerné, et non depuis l'onglet Vérifications du domaine.
-
-1. Rendez-vous sur votre domaine, puis sur le sous-domaine et le service concernés.
-2. Ouvrez l'onglet **Vérifications** de ce service.
-3. Le déroulement est identique à celui des vérificateurs de niveau domaine : configurer les options, mettre en place la planification, lancer des vérifications et consulter les résultats.
-
-Les vérificateurs de niveau service reçoivent automatiquement les informations relatives au service auquel ils sont rattachés (comme les adresses IP d'un service Serveur), ce qui réduit la configuration manuelle.
-
-
-## Gérer les résultats des vérifications
-
-Depuis la liste des exécutions, vous pouvez :
-
-- **Supprimer un résultat** en cliquant sur l'action de suppression d'une exécution précise.
-- **Supprimer tous les résultats** d'un vérificateur grâce à l'option de suppression groupée (une fenêtre de confirmation apparaît).
-
-Cela peut être utile pour faire le ménage dans les anciennes données ou repartir de zéro après des changements de configuration.
-
-
-## Référence des statuts
-
-Les vérificateurs rapportent l'un des statuts suivants, par ordre de gravité :
-
-| Statut | Signification |
-|--------|---------|
-| **OK** | Tout se situe dans les paramètres acceptables |
-| **Information** | Constat informatif, aucune action nécessaire |
-| **Avertissement** | Un seuil est sur le point d'être atteint ; une attention est recommandée |
-| **Critique** | Un seuil a été dépassé ; une action est 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 |

content/pages/domain-abstract.en.md

@@ -0,0 +1,8 @@
+---
+date: 2021-01-12T21:38:49+02:00
+title: Your domain
+author: Frederic
+weight: 30
+---
+
+Need help to write this Documentation page

content/pages/domain-abstract.fr.md

@@ -0,0 +1,7 @@
+---
+date: 2020-12-09T18:12:45+01:00
+title: Éditer votre zone
+weight: 30
+---
+
+Documentation à faire

content/pages/domain-abstract/index.en.md

@@ -1,107 +0,0 @@
----
-date: 2021-01-12T21:38:49+02:00
-title: "Using the zone editor"
-author: Frederic
-weight: 900
-description: "View, add, edit and delete records and services in your zone, grouped by subdomain"
----
-
-The zone editor is the main screen for working with a domain. It presents the content of your zone grouped by subdomain, and lets you add, edit and delete the services and records that make up your zone, all without touching your hosting provider until you decide to [publish changes]({{% relref "publish-changes" %}}).
-
-## The editor layout
-
-When you open a domain, the screen is split in two parts:
-
-- On the left, a **sidebar** lists every subdomain of the zone. It also gives access to domain-wide actions (history, audit log, checks, WHOIS, import/export, etc.).
-- On the right, the **Zone Viewer** displays the content of the zone, one block per subdomain.
-
-![The happyDomain zone editor, with the subdomain sidebar and the zone viewer](happydomain-abstract-zone-records.webp)
-
-At the very top of the sidebar you will find the **Add a subdomain** button and a gear menu grouping the other actions. The button used to send your changes to your provider (**Publish my changes**) is also reachable from here; see [this page]({{% relref "publish-changes" %}}) for details.
-
-{{% notice style="info" title="Nothing is sent automatically" icon="cloud" %}}
-Every change you make in the editor is kept locally in happyDomain. It is only transmitted to your hosting provider once you explicitly publish it.
-{{% /notice %}}
-
-## Browsing the zone
-
-The zone is organised **by subdomain**. The root of the domain is shown first (displayed with the bare domain name), followed by each subdomain. Intermediate subdomains that hold no service of their own are still shown, marked with a dotted icon, so you can always see the full tree.
-
-- Click a subdomain heading to **expand or collapse** it and reveal the services it contains.
-- When a block is collapsed, a badge shows how many services it holds; hover it to get a quick summary.
-- Use the **sidebar** to jump straight to a subdomain: it mirrors the list and scrolls the viewer to the matching block.
-
-Aliases pointing to a subdomain are shown next to its heading with a `+ N aliases` badge.
-
-<!-- TODO: screenshot of a subdomain block expanded, showing its services -->
-
-## Records and services
-
-happyDomain does not show you a raw list of DNS records by default. Instead, it groups related records into **services**, higher-level objects that are easier to reason about (a mail server, a website, a delegation, etc.). Each service expands into the actual records it generates.
-
-If you prefer to work directly with individual records, you can switch the zone view mode in your [account settings]({{% relref "settings" %}}). The editor then offers an **Add a record** button instead of **Add a service**.
-
-## Adding a subdomain
-
-1. Click **Add a subdomain** at the top of the sidebar.
-2. Enter the name of the subdomain to create (relative to your domain).
-3. happyDomain then proposes to add a first service on that subdomain right away.
-
-A subdomain only really exists once it carries at least one service, so the two steps are chained together.
-
-![The add-a-subdomain dialog](happydomain-modal-new-subdomain.webp)
-
-## Adding a service
-
-To add a service to an existing subdomain:
-
-1. Locate the subdomain block (or the domain root) in the viewer.
-2. Click the **+** button on the subdomain heading, or use the **Add a service** action.
-3. Pick the service type from the selector. The list adapts to what already exists on that subdomain (for instance, you cannot add two conflicting services).
-4. Fill in the form for the chosen service, then save.
-
-![The service type selector](happydomain-modal-service-selector.webp)
-
-## Inspecting a service
-
-Click a service to open the **details panel** that slides in from the right. It shows:
-
-- A description of the service type and any comment you set.
-- The concrete DNS records the service produces.
-- The propagation status (when the change was last published).
-- Any health checks attached to that service (see {{% relref "checks" %}}).
-
-From this panel you can also adjust the **default TTL** of the service, edit it, or delete it.
-
-![The service details panel](happydomain-offcanva-service-details.webp)
-
-## Editing a service
-
-1. Open the service details panel, then click **Edit this service**; or use the pencil button shown on simple services such as aliases.
-2. happyDomain opens the full editing form for the service.
-3. Make your changes and save. The viewer refreshes to reflect them.
-
-## Deleting a service
-
-1. Open the service details panel.
-2. Click **Delete this service**.
-
-The service and all the records it generated are removed from your working copy of the zone.
-
-{{% notice style="warning" title="Some services cannot be removed" icon="triangle-exclamation" %}}
-The origin service of a zone (the one carrying the SOA and the authoritative name servers) is essential and cannot be deleted from the editor.
-{{% /notice %}}
-
-For aliases (CNAME) and reverse pointers (PTR), a dedicated delete button is available directly on the subdomain heading.
-
-## Aliases
-
-When a subdomain holds services, you can attach an **alias** to it using the link button on its heading. The alias makes another name resolve to this subdomain.
-
-## Next steps
-
-None of the above changes anything at your hosting provider yet. When you are happy with your edits:
-
-- Review what will change, then send the changes; see {{% relref "publish-changes" %}}.
-
-You can also re-import the live zone, or import/export it as a standard zone file: see {{% relref "import-export" %}}.

content/pages/domain-abstract/index.fr.md

@@ -1,106 +0,0 @@
----
-date: 2020-12-09T18:12:45+01:00
-title: "Utiliser l'éditeur de zone"
-weight: 900
-description: "Visualiser, ajouter, modifier et supprimer les enregistrements et services de votre zone, regroupés par sous-domaine"
----
-
-L'éditeur de zone est l'écran principal pour travailler sur un domaine. Il présente le contenu de votre zone regroupé par sous-domaine, et vous permet d'ajouter, modifier et supprimer les services et enregistrements qui composent votre zone, sans rien changer chez votre hébergeur tant que vous n'avez pas décidé de [publier vos changements]({{% relref "publish-changes" %}}).
-
-## Disposition de l'éditeur
-
-Lorsque vous ouvrez un domaine, l'écran est divisé en deux parties :
-
-- À gauche, une **barre latérale** liste tous les sous-domaines de la zone. Elle donne aussi accès aux actions concernant l'ensemble du domaine (historique, journal d'audit, contrôles, WHOIS, import/export, etc.).
-- À droite, le **Visualiseur de zone** affiche le contenu de la zone, un bloc par sous-domaine.
-
-![L'éditeur de zone d'happyDomain, avec la barre latérale des sous-domaines et le visualiseur de zone](happydomain-abstract-zone-records.webp)
-
-Tout en haut de la barre latérale se trouvent le bouton **Ajouter un sous-domaine** et un menu en forme d'engrenage regroupant les autres actions. Le bouton servant à transmettre vos changements à votre hébergeur (« Diffuser mes changements ») est également accessible depuis cet écran ; voyez [cette page]({{% relref "publish-changes" %}}) pour les détails.
-
-{{% notice style="info" title="Rien n'est envoyé automatiquement" icon="cloud" %}}
-Chaque modification que vous faites dans l'éditeur est conservée localement dans happyDomain. Elle n'est transmise à votre hébergeur que lorsque vous la publiez explicitement.
-{{% /notice %}}
-
-## Parcourir la zone
-
-La zone est organisée **par sous-domaine**. La racine du domaine apparaît en premier (affichée avec le nom de domaine seul), suivie de chaque sous-domaine. Les sous-domaines intermédiaires qui ne portent aucun service sont tout de même affichés, signalés par une icône en pointillés, afin que vous puissiez toujours voir l'arborescence complète.
-
-- Cliquez sur le titre d'un sous-domaine pour le **déplier ou le replier** et révéler les services qu'il contient.
-- Lorsqu'un bloc est replié, un badge indique combien de services il contient ; survolez-le pour obtenir un aperçu rapide.
-- Utilisez la **barre latérale** pour accéder directement à un sous-domaine : elle reflète la liste et fait défiler le visualiseur jusqu'au bloc correspondant.
-
-Les alias pointant vers un sous-domaine apparaissent à côté de son titre, sous forme d'un badge « + N alias ».
-
-<!-- TODO: screenshot d'un bloc de sous-domaine déplié, montrant ses services -->
-
-## Enregistrements et services
-
-Par défaut, happyDomain ne vous présente pas une liste brute d'enregistrements DNS. Il regroupe au contraire les enregistrements liés en **services**, des objets de plus haut niveau plus simples à appréhender (un serveur de courrier, un site web, une délégation, etc.). Chaque service se déploie en montrant les enregistrements concrets qu'il génère.
-
-Si vous préférez travailler directement avec les enregistrements individuels, vous pouvez changer le mode d'affichage de la zone dans [vos préférences]({{% relref "settings" %}}). L'éditeur propose alors un bouton **Ajouter un enregistrement** au lieu d'**Ajouter un service**.
-
-## Ajouter un sous-domaine
-
-1. Cliquez sur **Ajouter un sous-domaine** en haut de la barre latérale.
-2. Saisissez le nom du sous-domaine à créer (relatif à votre domaine).
-3. happyDomain vous propose ensuite d'ajouter immédiatement un premier service sur ce sous-domaine.
-
-Un sous-domaine n'existe réellement qu'à partir du moment où il porte au moins un service : les deux étapes sont donc enchaînées.
-
-![La fenêtre d'ajout d'un sous-domaine](happydomain-modal-new-subdomain.webp)
-
-## Ajouter un service
-
-Pour ajouter un service à un sous-domaine existant :
-
-1. Repérez le bloc du sous-domaine (ou la racine du domaine) dans le visualiseur.
-2. Cliquez sur le bouton **+** présent sur le titre du sous-domaine, ou utilisez l'action **Ajouter un service**.
-3. Choisissez le type de service dans le sélecteur. La liste s'adapte à ce qui existe déjà sur ce sous-domaine (par exemple, vous ne pouvez pas ajouter deux services en conflit).
-4. Remplissez le formulaire du service choisi, puis enregistrez.
-
-![Le sélecteur de type de service](happydomain-modal-service-selector.webp)
-
-## Inspecter un service
-
-Cliquez sur un service pour ouvrir le **panneau de détails** qui apparaît par la droite. Il présente :
-
-- Une description du type de service et le commentaire éventuel que vous avez défini.
-- Les enregistrements DNS concrets que le service produit.
-- L'état de propagation (date de la dernière publication de la modification).
-- Les contrôles de santé éventuellement rattachés à ce service (voyez {{% relref "checks" %}}).
-
-Depuis ce panneau, vous pouvez aussi ajuster le **TTL par défaut** du service, le modifier ou le supprimer.
-
-![Le panneau de détails d'un service](happydomain-offcanva-service-details.webp)
-
-## Modifier un service
-
-1. Ouvrez le panneau de détails du service, puis cliquez sur **Modifier ce service** ; ou utilisez le bouton crayon affiché sur les services simples comme les alias.
-2. happyDomain ouvre le formulaire d'édition complet du service.
-3. Effectuez vos changements et enregistrez. Le visualiseur se met à jour pour les refléter.
-
-## Supprimer un service
-
-1. Ouvrez le panneau de détails du service.
-2. Cliquez sur **Supprimer ce service**.
-
-Le service et tous les enregistrements qu'il générait sont retirés de votre copie de travail de la zone.
-
-{{% notice style="warning" title="Certains services ne peuvent pas être supprimés" icon="triangle-exclamation" %}}
-Le service d'origine d'une zone (celui qui porte le SOA et les serveurs de noms faisant autorité) est essentiel et ne peut pas être supprimé depuis l'éditeur.
-{{% /notice %}}
-
-Pour les alias (CNAME) et les pointeurs inverses (PTR), un bouton de suppression dédié est disponible directement sur le titre du sous-domaine.
-
-## Alias
-
-Lorsqu'un sous-domaine porte des services, vous pouvez lui rattacher un **alias** à l'aide du bouton en forme de lien présent sur son titre. L'alias fait pointer un autre nom vers ce sous-domaine.
-
-## Et ensuite
-
-Aucune des opérations ci-dessus ne change quoi que ce soit chez votre hébergeur pour l'instant. Lorsque vos modifications vous conviennent :
-
-- Examinez ce qui va changer, puis envoyez les changements ; voyez {{% relref "publish-changes" %}}.
-
-Vous pouvez aussi réimporter la zone en ligne, ou [l'importer / l'exporter sous forme de fichier de zone standard]({{% relref "import-export" %}}).

content/pages/domain-availability.en.md

@@ -1,87 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Domain availability & lookups
-author: nemunaire
-weight: 1800
-description: "Check whether a domain is available for registration, and inspect any domain with the WHOIS and DNS resolver tools"
----
-
-happyDomain bundles a few diagnostic tools that work on any domain name, whether or not you manage it in happyDomain. They let you check if a name is available for registration, look up its registration details (WHOIS), and query its DNS records directly (resolver).
-
-## Availability checker
-
-The **Availability** page lets you keep an eye on one or more domain names you would like to register, and be told as soon as one becomes available.
-
-<!-- TODO: screenshot of the availability page -->
-
-### Watching a domain
-
-To start watching a name:
-
-1. Type the domain you are interested in (for example `mydomain.example`) in the input at the top of the page.
-2. Click **Add**.
-
-The name is added to your watch list and an immediate check is launched in the background, so you do not have to wait for the next automatic check to see its current state.
-
-### Reading the status
-
-Each watched domain shows a badge reflecting the result of the last check:
-
-| Badge | Meaning |
-|-------|---------|
-| **Available** | The name appears to be free and can probably be registered. |
-| **Registered** | The name is already taken. |
-| _(error message)_ | The check could not be completed (for example the extension is unsupported, or the registry could not be reached). |
-| **Never checked** | No result is available yet. |
-
-The time of the last check is displayed next to the status.
-
-### Rechecking and removing
-
-- Click **Check now** next to a domain to trigger a fresh check immediately. A spinner is shown while the check runs in the background, and the status updates automatically once it finishes.
-- Click the trash icon to stop watching a domain. A confirmation is asked before removal.
-
-{{% notice style="tip" title="Availability is a best effort" icon="lightbulb" %}}
-The availability result is only an indication. Some extensions cannot be checked reliably, and a name that appears free may still be reserved or blocked at registration time. Always confirm with a registrar before counting on a name.
-{{% /notice %}}
-
-
-## WHOIS lookup
-
-The **WHOIS** tool shows the public registration information of a domain: its registrar, important dates and current status.
-
-<!-- TODO: screenshot of the WHOIS lookup page -->
-
-Enter a domain name and run the lookup. happyDomain then displays a clear summary of the collected information:
-
-- **Status**: the registration statuses returned for the domain (for example `active`, `clientTransferProhibited`, a `hold` state, etc.), shown as colour-coded badges.
-- **Creation date** and **Expiration date**: when the domain was first registered and when its registration is due to expire. The expiration is accompanied by a progress bar and a countdown, which turns orange then red as the date approaches.
-- **Registrar**: the company through which the domain is registered, with a link to its website when available.
-- **Nameservers**: the authoritative nameservers declared for the domain.
-
-If the name is not registered, a message tells you the domain was not found. If the lookup itself fails, the error is shown.
-
-{{% notice style="info" title="WHOIS and the availability checker" icon="circle-info" %}}
-The availability checker relies on the same underlying registration data as the WHOIS lookup. If you want the full registration picture for a name, use the WHOIS tool; if you simply want to know whether a name is free (and be notified later), add it to your availability watch list.
-{{% /notice %}}
-
-
-## DNS resolver
-
-The **DNS resolver** lets you query the live DNS of any domain, exactly as it is published on the Internet right now. This is handy to confirm that a change has propagated, or to inspect a domain you do not manage.
-
-<!-- TODO: screenshot of the resolver page -->
-
-Enter a domain name and run the query. By default, every record type is requested (`ANY`). Open the **Advanced** options to refine the query:
-
-- **Field (record type)**: restrict the query to a single record type (`A`, `AAAA`, `MX`, `TXT`, etc.).
-- **Resolver**: choose which DNS resolver to send the query to. Several well-known public resolvers are offered, and you can pick **Custom** to enter the address of any resolver you want to test against.
-- **Show DNSSEC records**: include the DNSSEC-related records (`RRSIG`, `NSEC`, `NSEC3`) in the results, which are hidden by default.
-
-If you manage domains in happyDomain, their names are suggested as you type the domain to query.
-
-Results are grouped by record type, and each entry shows its fields together with its TTL. When the domain exists but has no record of the requested type, a message says so explicitly.
-
-{{% notice style="tip" title="Resolver vs. your zone in happyDomain" icon="lightbulb" %}}
-The resolver shows what is **currently published** by the authoritative servers, which may differ from a draft zone you are editing in happyDomain until you [publish your changes]({{% relref "publish-changes" %}}).
-{{% /notice %}}

content/pages/domain-availability.fr.md

@@ -1,86 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Disponibilité et recherches de domaines
-weight: 1800
-description: "Vérifier si un domaine est disponible à l'enregistrement, et inspecter n'importe quel domaine grâce aux outils WHOIS et résolveur DNS"
----
-
-happyDomain embarque quelques outils de diagnostic qui fonctionnent sur n'importe quel nom de domaine, qu'il soit ou non géré dans happyDomain. Ils permettent de vérifier si un nom est disponible à l'enregistrement, de consulter ses informations d'enregistrement (WHOIS), et d'interroger directement ses enregistrements DNS (résolveur).
-
-## Vérificateur de disponibilité
-
-La page **Disponibilité** vous permet de surveiller un ou plusieurs noms de domaine que vous souhaiteriez enregistrer, et d'être prévenu dès que l'un d'eux devient disponible.
-
-<!-- TODO: screenshot of the availability page -->
-
-### Surveiller un domaine
-
-Pour commencer à surveiller un nom :
-
-1. Saisissez le domaine qui vous intéresse (par exemple `mondomaine.example`) dans le champ situé en haut de la page.
-2. Cliquez sur **Ajouter**.
-
-Le nom est ajouté à votre liste de surveillance et une première vérification est lancée immédiatement en arrière-plan, afin de ne pas avoir à attendre la prochaine vérification automatique pour connaître son état actuel.
-
-### Lire le statut
-
-Chaque domaine surveillé affiche un badge qui reflète le résultat de la dernière vérification :
-
-| Badge | Signification |
-|-------|---------------|
-| **Disponible** | Le nom semble libre et peut probablement être enregistré. |
-| **Enregistré** | Le nom est déjà pris. |
-| _(message d'erreur)_ | La vérification n'a pas pu aboutir (par exemple l'extension n'est pas prise en charge, ou le registre n'a pas pu être contacté). |
-| **Jamais vérifié** | Aucun résultat n'est encore disponible. |
-
-La date de la dernière vérification est indiquée à côté du statut.
-
-### Revérifier et supprimer
-
-- Cliquez sur **Vérifier maintenant** à côté d'un domaine pour déclencher immédiatement une nouvelle vérification. Une animation est affichée pendant que le contrôle s'exécute en arrière-plan, et le statut se met à jour automatiquement une fois terminé.
-- Cliquez sur l'icône de corbeille pour cesser de surveiller un domaine. Une confirmation est demandée avant la suppression.
-
-{{% notice style="tip" title="La disponibilité reste indicative" icon="lightbulb" %}}
-Le résultat de disponibilité n'est qu'une indication. Certaines extensions ne peuvent pas être vérifiées de manière fiable, et un nom qui semble libre peut tout de même être réservé ou bloqué au moment de l'enregistrement. Confirmez toujours auprès d'un bureau d'enregistrement avant de compter sur un nom.
-{{% /notice %}}
-
-
-## Recherche WHOIS
-
-L'outil **WHOIS** affiche les informations publiques d'enregistrement d'un domaine : son bureau d'enregistrement, ses dates importantes et son statut actuel.
-
-<!-- TODO: screenshot of the WHOIS lookup page -->
-
-Saisissez un nom de domaine puis lancez la recherche. happyDomain affiche alors un résumé clair des informations collectées :
-
-- **Statut** : les statuts d'enregistrement renvoyés pour le domaine (par exemple `active`, `clientTransferProhibited`, un état `hold`, etc.), présentés sous forme de badges colorés.
-- **Date de création** et **Date d'expiration** : la date du premier enregistrement du domaine et celle à laquelle son enregistrement doit expirer. L'expiration est accompagnée d'une barre de progression et d'un compte à rebours, qui passe à l'orange puis au rouge à l'approche de l'échéance.
-- **Bureau d'enregistrement** : l'organisme auprès duquel le domaine est enregistré, avec un lien vers son site lorsqu'il est disponible.
-- **Serveurs de noms** : les serveurs de noms faisant autorité déclarés pour le domaine.
-
-Si le nom n'est pas enregistré, un message vous indique que le domaine est introuvable. Si la recherche elle-même échoue, l'erreur est affichée.
-
-{{% notice style="info" title="WHOIS et vérificateur de disponibilité" icon="circle-info" %}}
-Le vérificateur de disponibilité s'appuie sur les mêmes données d'enregistrement que la recherche WHOIS. Si vous souhaitez la vue complète de l'enregistrement d'un nom, utilisez l'outil WHOIS ; si vous voulez simplement savoir si un nom est libre (et être prévenu ultérieurement), ajoutez-le à votre liste de surveillance de disponibilité.
-{{% /notice %}}
-
-
-## Résolveur DNS
-
-Le **résolveur DNS** vous permet d'interroger le DNS en direct de n'importe quel domaine, exactement tel qu'il est publié sur Internet en cet instant. C'est pratique pour confirmer qu'une modification s'est bien propagée, ou pour inspecter un domaine que vous ne gérez pas.
-
-<!-- TODO: screenshot of the resolver page -->
-
-Saisissez un nom de domaine puis lancez la requête. Par défaut, tous les types d'enregistrement sont demandés (`ANY`). Ouvrez les options **Avancées** pour affiner la requête :
-
-- **Champ (type d'enregistrement)** : restreignez la requête à un seul type d'enregistrement (`A`, `AAAA`, `MX`, `TXT`, etc.).
-- **Résolveur** : choisissez le résolveur DNS auquel envoyer la requête. Plusieurs résolveurs publics réputés sont proposés, et vous pouvez sélectionner **Personnalisé** pour saisir l'adresse du résolveur de votre choix.
-- **Afficher les enregistrements DNSSEC** : inclure les enregistrements liés à DNSSEC (`RRSIG`, `NSEC`, `NSEC3`) dans les résultats, masqués par défaut.
-
-Si vous gérez des domaines dans happyDomain, leurs noms vous sont suggérés au fur et à mesure que vous saisissez le domaine à interroger.
-
-Les résultats sont regroupés par type d'enregistrement, et chaque entrée affiche ses champs ainsi que son TTL. Lorsque le domaine existe mais ne possède aucun enregistrement du type demandé, un message l'indique explicitement.
-
-{{% notice style="tip" title="Résolveur et votre zone dans happyDomain" icon="lightbulb" %}}
-Le résolveur montre ce qui est **actuellement publié** par les serveurs faisant autorité, ce qui peut différer d'une zone en cours d'édition dans happyDomain tant que vous n'avez pas [publié vos modifications]({{% relref "publish-changes" %}}).
-{{% /notice %}}

content/pages/domain-history.en.md

@@ -1,43 +1,7 @@
 ---
 date: 2025-06-15T11:06:00+02:00
 title: "View change history"
-weight: 1500
+weight: 40
 ---
 
 Every time you [publish changes]({{% relref "publish-changes" %}}) with happyDomain, they are recorded in a log. This log allows you to easily retrieve the status of your domains as they were previously deployed, and to see when you made each change.
-
-## Opening the history
-
-From your domain's page, open the **History** entry in the menu. happyDomain displays every recorded version of the zone, from the most recent at the top to the oldest at the bottom.
-
-<!-- TODO: screenshot of the history page -->
-
-To keep the list readable, versions are grouped by month. A heading marks the beginning of each month so you can quickly locate a change by its time period.
-
-## Reading a version
-
-Each version is identified by the moment it was last modified, along with the avatar and email address of the author who made the change.
-
-Three dates may be shown for a version:
-
-- **Published on**: when this version was deployed to your DNS provider. A version without this date was saved but never published.
-- **Committed on**: when the version was committed (saved as a definitive state of the zone).
-- **Modified on**: when the version was last edited.
-
-If a message was attached when the changes were published, it appears below the dates, much like a commit message in version control.
-
-## Viewing the zone at a given time
-
-To inspect the full content of the zone as it was for a given version, click the eye button next to its date. happyDomain opens that version in read-only mode, so you can browse all the records exactly as they were at that moment.
-
-## Comparing two versions
-
-Under each version (except the oldest one), the **View differences** section lets you compare it with the version that immediately precedes it.
-
-<!-- TODO: screenshot of the differences accordion expanded -->
-
-Expand the section to reveal the changes: added records, deleted records, and modified records are highlighted, so you can see at a glance what each publication changed. The most recent comparison is expanded automatically when you open the page.
-
-{{% notice style="info" title="No history yet?" %}}
-A domain only builds up a history once you start publishing changes to it. If you have just imported a domain, its history will fill in as you make and publish your first modifications.
-{{% /notice %}}

content/pages/domain-history.fr.md

@@ -1,43 +1,7 @@
 ---
 date: 2025-06-15T11:06:00+02:00
 title: "Voir l'historique des changements"
-weight: 1500
+weight: 40
 ---
 
 À chaque fois que vous [publiez des modifications]({{% relref "publish-changes" %}}) avec happyDomain, celles-ci sont enregistrées dans un journal. Ce journal vous permet de retrouver facilement l'état de vos domaines tels qu'ils étaient déployés précédemment, et de voir quand vous avez fait chaque modification.
-
-## Ouvrir l'historique
-
-Depuis la page de votre domaine, ouvrez l'entrée **Historique** dans le menu. happyDomain affiche toutes les versions enregistrées de la zone, de la plus récente en haut à la plus ancienne en bas.
-
-<!-- TODO: capture d'écran de la page d'historique -->
-
-Pour garder la liste lisible, les versions sont regroupées par mois. Un en-tête marque le début de chaque mois, ce qui vous permet de retrouver rapidement une modification d'après sa période.
-
-## Lire une version
-
-Chaque version est identifiée par le moment de sa dernière modification, accompagné de l'avatar et de l'adresse électronique de l'auteur qui l'a effectuée.
-
-Trois dates peuvent être affichées pour une version :
-
-- **Publiée le** : le moment où cette version a été déployée chez votre fournisseur DNS. Une version sans cette date a été enregistrée, mais jamais publiée.
-- **Enregistrée le** : le moment où la version a été figée (sauvegardée comme un état définitif de la zone).
-- **Dernière modification le** : le moment où la version a été modifiée pour la dernière fois.
-
-Si un message a été associé lors de la publication des changements, il apparaît sous les dates, à la manière d'un message de commit dans un gestionnaire de versions.
-
-## Voir la zone à un instant donné
-
-Pour examiner le contenu complet de la zone tel qu'il était pour une version donnée, cliquez sur le bouton en forme d'œil situé à côté de sa date. happyDomain ouvre cette version en lecture seule, ce qui vous permet de parcourir tous les enregistrements exactement tels qu'ils étaient à ce moment.
-
-## Comparer deux versions
-
-Sous chaque version (sauf la plus ancienne), la section **Voir les changements** vous permet de la comparer avec la version qui la précède immédiatement.
-
-<!-- TODO: capture d'écran de la section des changements dépliée -->
-
-Dépliez la section pour révéler les modifications : les enregistrements ajoutés, supprimés et modifiés sont mis en évidence, ce qui vous permet de voir d'un coup d'œil ce que chaque publication a changé. La comparaison la plus récente est dépliée automatiquement à l'ouverture de la page.
-
-{{% notice style="info" title="Pas encore d'historique ?" %}}
-Un domaine ne se constitue un historique qu'à partir du moment où vous commencez à y publier des changements. Si vous venez d'importer un domaine, son historique se remplira au fur et à mesure que vous effectuerez et publierez vos premières modifications.
-{{% /notice %}}

content/pages/domain-new.en.md

@@ -2,7 +2,7 @@
 date: 2021-01-12T21:38:49+02:00
 title: Import a domain
 author: Frederic
-weight: 800
+weight: 20
 ---
 
 Importing a domain into happyDomain does not make happyDomain the owner of your domain. This action does not involve any changes to your usual hosting provider. happyDomain will contact your hosting provider or server to check which services are currently registered.

content/pages/domain-new.fr.md

@@ -1,7 +1,7 @@
 ---
 date: 2020-12-09T18:12:45+01:00
 title: Importer un domaine
-weight: 800
+weight: 20
 ---
 
 Importer un domaine dans happyDomain ne rend pas happyDomain propriétaire de votre domaine. Cette action n'implique aucune modification auprès de votre hébergeur habituel. happyDomain va communiquer avec votre hébergeur ou votre serveur afin de consulter les services qui sont actuellement enregistrés.

content/pages/domains/_index.en.md

@@ -4,17 +4,14 @@ title: Centralize your domains
 author: Frederic
 aliases:
     home
-weight: 300
+weight: 10
 ---
 
-happyDomain provides you with a unified graphical interface with modern features, regardless of where your domain names are hosted. They can be on a DNS server (PowerDNS, bind, knot, ...) of your own, or with one or several providers (around 50 are currently supported).
-
-
 ## Your domains
 
 The home page presents the list of all the domains managed by happyDomain, whatever their host:
 
-![The domains managed by happyDomain](domain-list.webp)
+![The domains managed by happyDomain](domain-list.png)
 
 Click one of the domains to start [make changes]({{% relref "domain-abstract" %}}) (add a sub-domain, add a service, ...).
 
@@ -23,7 +20,7 @@ Click one of the domains to start [make changes]({{% relref "domain-abstract" %}
 
 On the right, you can see the list of the different hosting providers for your:
 
-![The hosters of your domains](providers-list.webp)
+The hosters of your domains](hosters-list.png)
 
 You can [add new host]({{% relref "provider-new-choice" %}}) by clicking on the + button in the table header.
 
@@ -31,7 +28,7 @@ Clicking on a row in this table will filter the list of domains to show only dom
 
 You will also see, if the host allows you to list the domains that belong to you, the domains that you can add to happyDomain:
 
-![Domain filtering according to the hosting provider](filtered-by-provider.webp)
+![Domain filtering according to the hosting provider](hoster-ovh.png)
 
 To view the entire list again, simply click on the selected host again.
 
@@ -40,19 +37,19 @@ To view the entire list again, simply click on the selected host again.
 
 If you find an error or no longer need a hosting provider, click on the ... on the line of the host concerned. You will then be able to choose between [update information]({{% relref "provider-update" %}}) or delete the host:
 
-![Modify or delete a hosting](provider-menu.webp)
+![Modify or delete a hosting](hoster-edit.png)
 
 Note that you will not be able to remove the host as long as domains referring to it exist in the list on the left.
 
 
 ## Add a domain
 
-You have a new domain you want to manage in happyDomain? Start by entering its name in the field above the list. You will then be guided to the screen [to choose the host]({{% relref "domain-new" %}}).
+You have a new domain you want to manage in happyDomain? Start by entering its name in the field below the list. You will then be guided to the [to choose the host] screen ({{% relref "domain-new" %}}).
 
-![Location to add a domain that is not listed](new-domain.webp)
+![Location to add a domain that is not listed](new-domain.png)
 
-Some DNS providers allows you to create a domain directly in their database, even if it was not already registered. First, you'll need to select the right provider. You'll see a dedicated "Create on" button.
+The field does not show when a host is selected on the right. Unless this host does not allow to list:
 
-![Some provider will permit to create a domain](create-domain-on-provider.webp)
+![Special case of addition for authoritative DNS servers](hoster-self.png)
 
-Some providers could charge you for this action, so pay attention if this implies to realy buy the domain.
+In this case, validating the field will automatically search for the new domain with the selected host, as indicated by the message just above the field.

content/pages/domains/_index.fr.md

@@ -3,7 +3,7 @@ date: 2020-12-09T18:12:45+01:00
 title: Regrouper vos domaines
 aliases:
     home
-weight: 300
+weight: 10
 ---
 
 happyDomain vous apporte une interface graphique unifiée et avec des fonctionnalités modernes quelque soit l'endroit où sont hébergés vos noms de domaine. Ils peuvent être sur un serveur DNS (PowerDNS, bind, knot, ...) qui vous est propre, ou bien chez un ou plusieurs hébergeurs (une 50aine sont supportés à l'heure actuelle).
@@ -13,7 +13,7 @@ happyDomain vous apporte une interface graphique unifiée et avec des fonctionna
 
 La page d'accueil présente la liste de l'ensemble des domaines gérés par happyDomain, quelque soit leur hébergeur :
 
-![Les domaines gérés par happyDomain](domain-list.webp)
+![Les domaines gérés par happyDomain](domain-list.png)
 
 Cliquez sur l'un des domaines pour commencer à [y apporter des modifications]({{% relref "domain-abstract" %}}) (ajouter un sous-domaine, ajouter un service, ...).
 
@@ -22,7 +22,7 @@ Cliquez sur l'un des domaines pour commencer à [y apporter des modifications]({
 
 Sur la droite, vous voyez la liste des différents hébergeurs de vos domaines :
 
-![Les hébergeurs de vos domaines](providers-list.webp)
+![Les hébergeurs de vos domaines](hosters-list.png)
 
 Vous pouvez [ajouter un nouvel hébergeur]({{% relref "provider-new-choice" %}}) en cliquant sur le bouton +, présent dans l'en-tête du tableau.
 
@@ -30,7 +30,7 @@ En cliquant sur une ligne de ce tableau, vous filtrerez la liste des domaines po
 
 Vous verrez aussi, si l'hébergeur permet de lister les domaines qui vous appartiennent, les domaines que vous pouvez ajouter à happyDomain :
 
-![Filtrage des domaines en fonction de l'hébergeur](filtered-by-provider.webp)
+![Filtrage des domaines en fonction de l'hébergeur](hoster-ovh.png)
 
 Pour afficher à nouveau la liste dans son intégralité, recliquez simplement sur l'hébergeur qui est sélectionné.
 
@@ -39,7 +39,7 @@ Pour afficher à nouveau la liste dans son intégralité, recliquez simplement s
 
 Si vous constatez une erreur ou n'avez plus besoin d'un hébergeur, cliquez sur les ... sur la ligne de l'hébergeur concerné. Vous aurez alors la possibilité de choisir entre [mettre à jour les informations]({{% relref "provider-update" %}}) ou supprimer l'hébergeur :
 
-![Modification ou suppression d'un hébergeur](provider-menu.webp)
+![Modification ou suppression d'un hébergeur](hoster-edit.png)
 
 Notez que vous ne pourrez pas supprimer l'hébergeur tant que des domaines y faisant référence existeront dans la liste de gauche.
 
@@ -48,10 +48,10 @@ Notez que vous ne pourrez pas supprimer l'hébergeur tant que des domaines y fai
 
 Vous avez un nouveau domaine que vous souhaitez gérer dans happyDomain ? Commencez par entrer son nom dans le champ présent sous la liste. Vous serez ensuite guidé vers l'écran [permettant de choisir l'hébergeur]({{% relref "domain-new" %}}).
 
-![Emplacement pour ajouter un domaine qui n'est pas listé](new-domain.webp)
+![Emplacement pour ajouter un domaine qui n'est pas listé](new-domain.png)
 
-Certains hébergeurs DNS vous permettent de créer un domaine directement dans leur base de données, même s'il n'était pas déjà enregistré. Vous devrez d'abord sélectionner le bon hébergeur. Vous verrez alors un bouton « Créer sur » dédié.
+Le champ n'apparaît pas lorsqu'un hébergeur est sélectionné à droite. Sauf si cet hébergeur ne permet pas de lister les domaines :
 
-![Certains hébergeurs permettent de créer un domaine](create-domain-on-provider.webp)
+![Cas particulier d'ajout pour les serveurs DNS autoritaire](hoster-self.png)
 
-Certains hébergeurs peuvent vous facturer cette action, soyez donc attentif si cela implique d'acheter réellement le domaine.
+Dans ce cas, la validation du champ recherchera automatiquement le nouveau domaine auprès de l'hébergeur sélectionné, comme l'indique le message juste au dessus du champ.

content/pages/import-export/index.en.md

@@ -1,63 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: "Importing and exporting a zone"
-author: nemunaire
-weight: 1600
-description: "Bring an existing zone file into happyDomain, or export your zone in standard BIND format"
----
-
-happyDomain can exchange your zone with the rest of the DNS world using the standard zone file format (the well-known BIND format). You can **import** a zone file to populate your working copy, and **export** the current zone to read it, copy it, or keep it elsewhere.
-
-These actions are available from the gear menu at the top of the zone editor sidebar.
-
-## Re-importing the live zone
-
-Before working with files, it is worth knowing that you can always pull the **current** zone back from your provider. In the gear menu, choose **Retrieve the current zone**.
-
-This contacts your hosting provider, reads the zone as it stands right now, and refreshes your working copy from it. Use it when the zone may have been changed outside happyDomain, or to start again from a clean state.
-
-{{% notice style="warning" title="This replaces unpublished edits" icon="triangle-exclamation" %}}
-Re-importing the live zone fetches the provider's version. Any local change you had not yet published may be superseded, so review your pending changes first (see {{% relref "publish-changes" %}}) if you want to keep them.
-{{% /notice %}}
-
-## Importing a zone file
-
-To load a zone from a standard zone file:
-
-1. Open the gear menu in the sidebar and choose the **upload / import a zone** action.
-2. A dialog opens with two tabs:
-   - **From text** -- paste the content of a zone file directly into the text area.
-   - **From a zone file** -- select a file from your computer.
-3. Click the upload button to send it.
-
-![The import zone dialog, with the "From text" and "From a zone file" tabs](happydomain-modal-import-zone.webp)
-
-happyDomain parses the zone file, recognises the records, and groups them back into services in your working copy. As with every other edit, the imported content stays local until you publish it.
-
-{{% notice style="info" title="Standard format" icon="circle-info" %}}
-The expected format is the standard textual zone file, the same one BIND and most DNS tools use. A line such as `@ 4269 IN SOA root ns 2042070136 ...` is a typical example of what you can paste.
-{{% /notice %}}
-
-## Exporting / viewing the zone
-
-To obtain your zone as a standard zone file:
-
-1. Open the gear menu and choose **View my zone**.
-2. happyDomain renders the current zone in standard BIND format, with syntax highlighting.
-3. Use the **Copy to clipboard** button to grab the whole file in one click.
-
-![The zone displayed in standard BIND format, with syntax highlighting and a copy-to-clipboard button](happydomain-export-zone.webp)
-
-This view always reflects the zone you are currently looking at. If you are browsing a past version from the {{% relref "domain-history" %}}, the export shows that historical version, which is handy for comparing or restoring an earlier state.
-
-## Typical workflows
-
-- **Migrating from another tool**: export the zone from your previous tool as a zone file, then import it here with **From a zone file**.
-- **Keeping a backup**: open **View my zone** and copy the content somewhere safe.
-- **Bulk editing**: export, edit the file in your favourite editor, then re-import the result.
-
-## After importing
-
-Importing only changes your working copy. To make it effective at your provider:
-
-1. Review the resulting diff and publish the changes (see {{% relref "publish-changes" %}}).

content/pages/import-export/index.fr.md

@@ -1,63 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: "Importer et exporter une zone"
-author: nemunaire
-weight: 1600
-description: "Importer un fichier de zone existant dans happyDomain, ou exporter votre zone au format BIND standard"
----
-
-happyDomain peut échanger votre zone avec le reste du monde DNS en utilisant le format de fichier de zone standard (le célèbre format BIND). Vous pouvez **importer** un fichier de zone pour alimenter votre copie de travail, et **exporter** la zone actuelle pour la lire, la copier ou la conserver ailleurs.
-
-Ces actions sont accessibles depuis le menu en forme d'engrenage situé en haut de la barre latérale de l'éditeur de zone.
-
-## Réimporter la zone en ligne
-
-Avant de travailler avec des fichiers, il est utile de savoir que vous pouvez toujours récupérer la zone **actuelle** auprès de votre hébergeur. Dans le menu engrenage, choisissez « Récupérer la zone actuelle ».
-
-Cette action contacte votre hébergeur, lit la zone telle qu'elle est en ce moment, et rafraîchit votre copie de travail à partir d'elle. Utilisez-la lorsque la zone a pu être modifiée en dehors de happyDomain, ou pour repartir d'un état propre.
-
-{{% notice style="warning" title="Cela remplace les modifications non publiées" icon="triangle-exclamation" %}}
-Réimporter la zone en ligne récupère la version de l'hébergeur. Tout changement local que vous n'aviez pas encore publié peut être écrasé : examinez donc d'abord [vos changements en attente]({{% relref "publish-changes" %}}) si vous souhaitez les conserver.
-{{% /notice %}}
-
-## Importer un fichier de zone
-
-Pour charger une zone à partir d'un fichier de zone standard :
-
-1. Ouvrez le menu engrenage de la barre latérale et choisissez l'action d'import de zone.
-2. Une fenêtre s'ouvre avec deux onglets :
-   - **Depuis du texte** : collez le contenu d'un fichier de zone directement dans la zone de saisie.
-   - **Depuis un fichier de zone** : sélectionnez un fichier sur votre ordinateur.
-3. Cliquez sur le bouton d'envoi pour le transmettre.
-
-![La fenêtre d'import de zone, avec les onglets « Depuis du texte » et « Depuis un fichier de zone »](happydomain-modal-import-zone.webp)
-
-happyDomain analyse le fichier de zone, reconnaît les enregistrements et les regroupe à nouveau en services dans votre copie de travail. Comme pour toute autre modification, le contenu importé reste local tant que vous ne l'avez pas publié.
-
-{{% notice style="info" title="Format standard" icon="circle-info" %}}
-Le format attendu est le fichier de zone textuel standard, le même que celui qu'utilisent BIND et la plupart des outils DNS. Une ligne telle que `@ 4269 IN SOA root ns 2042070136 ...` est un exemple typique de ce que vous pouvez coller.
-{{% /notice %}}
-
-## Exporter / visualiser la zone
-
-Pour obtenir votre zone sous forme de fichier de zone standard :
-
-1. Ouvrez le menu engrenage et choisissez « Voir ma zone ».
-2. happyDomain affiche la zone actuelle au format BIND standard, avec coloration syntaxique.
-3. Utilisez le bouton **Copier dans le presse-papier** pour récupérer le fichier entier en un clic.
-
-![La zone affichée au format BIND standard, avec coloration syntaxique et un bouton de copie dans le presse-papier](happydomain-export-zone.webp)
-
-Cette vue reflète toujours la zone que vous consultez actuellement. Si vous parcourez une version passée depuis l'[historique]({{% relref "domain-history" %}}), l'export montre cette version historique, ce qui est pratique pour comparer ou restaurer un état antérieur.
-
-## Cas d'usage typiques
-
-- **Migrer depuis un autre outil** : exportez la zone de votre outil précédent sous forme de fichier de zone, puis importez-la ici avec « Depuis un fichier de zone ».
-- **Conserver une sauvegarde** : ouvrez « Voir ma zone » et copiez le contenu dans un endroit sûr.
-- **Édition en masse** : exportez, modifiez le fichier dans votre éditeur favori, puis réimportez le résultat.
-
-## Après un import
-
-Un import ne modifie que votre copie de travail. Pour le rendre effectif chez votre hébergeur :
-
-1. Examinez le différentiel obtenu, puis [publiez les changements]({{% relref "publish-changes" %}}).

content/pages/login/index.en.md

@@ -1,45 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Log in
-author: nemunaire
-weight: 200
-description: "Sign in to happyDomain and recover a forgotten password"
----
-
-Once you have [created an account]({{% relref "signup" %}}) and validated your email address, you can sign in to access your domains.
-
-## Signing in
-
-On the login page, enter the email address and password you chose at registration, then click **Go**.
-
-![The happyDomain login page](happydomain-login-page.webp)
-
-If the credentials are correct, you are taken to your dashboard. If they are not, an error message is displayed: double-check your address and password and try again.
-
-{{% notice style="info" title="Repeated attempts" icon="shield" %}}
-For security reasons, the server may ask you to complete an anti-bot challenge (captcha) after a few failed attempts, or temporarily rate-limit further tries. Wait a moment, then retry.
-{{% /notice %}}
-
-### Signing in with an external provider
-
-When the server is configured for it, an additional button lets you sign in through an external identity provider (for example Google, GitLab, GitHub, Microsoft or Apple). Click it to be redirected to that provider and authenticate there.
-
-## Forgotten password
-
-If you no longer remember your password, click **Forgotten password?** below the login form.
-
-![The happyDomain forgotten password page](happydomain-forget-password-page.webp)
-
-Enter the email address of your account and click **Send the recovery link**. If an account matches, a message containing a recovery link is sent to that address.
-
-Open the link from your mailbox to reach the account recovery form, where you can set a new password:
-
-1. Type your **new password** (it must meet the same strength requirements as at sign-up).
-2. Retype it in the **confirmation** field.
-3. Click **Redefine my password**.
-
-Once the password is redefined, you are redirected to the login page to sign in with your new credentials.
-
-{{% notice style="warning" title="Servers without email" icon="triangle-exclamation" %}}
-On instances that run without a mail service, password recovery is not available: clicking **Forgotten password?** displays a notice inviting you to contact the server administrator to reset your password.
-{{% /notice %}}

content/pages/login/index.fr.md

@@ -1,44 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Se connecter
-weight: 200
-description: "Connectez-vous à happyDomain et récupérez un mot de passe oublié"
----
-
-Une fois votre [compte créé]({{% relref "signup" %}}) et votre adresse e-mail validée, vous pouvez vous connecter pour accéder à vos domaines.
-
-## Se connecter
-
-Sur la page de connexion, saisissez l'adresse e-mail et le mot de passe choisis lors de l'inscription, puis cliquez sur « C'est parti ».
-
-![La page de connexion d'happyDomain](happydomain-login-page.webp)
-
-Si les identifiants sont corrects, vous arrivez sur votre tableau de bord. Sinon, un message d'erreur s'affiche : vérifiez votre adresse et votre mot de passe, puis réessayez.
-
-{{% notice style="info" title="Tentatives répétées" icon="shield" %}}
-Pour des raisons de sécurité, le serveur peut vous demander de compléter une vérification anti-robot (captcha) après plusieurs échecs, ou limiter temporairement les nouvelles tentatives. Patientez un instant, puis réessayez.
-{{% /notice %}}
-
-### Se connecter avec un fournisseur externe
-
-Lorsque le serveur est configuré pour cela, un bouton supplémentaire permet de se connecter via un fournisseur d'identité externe (par exemple Google, GitLab, GitHub, Microsoft ou Apple). Cliquez dessus pour être redirigé vers ce fournisseur et vous y authentifier.
-
-## Mot de passe oublié
-
-Si vous ne vous souvenez plus de votre mot de passe, cliquez sur « Mot de passe oublié ? » sous le formulaire de connexion.
-
-![La page de récupération de mot de passe d'happyDomain](happydomain-forget-password-page.webp)
-
-Saisissez l'adresse e-mail de votre compte, puis cliquez sur « Envoyer le lien de récupération ». Si un compte correspond, un message contenant un lien de récupération est envoyé à cette adresse.
-
-Ouvrez le lien depuis votre messagerie pour accéder au formulaire de récupération de compte, où vous pourrez définir un nouveau mot de passe :
-
-1. Saisissez votre **nouveau mot de passe** (il doit respecter les mêmes exigences de robustesse qu'à l'inscription).
-2. Ressaisissez-le dans le champ de **confirmation**.
-3. Cliquez sur « Redéfinir mon mot de passe ».
-
-Une fois le mot de passe redéfini, vous êtes redirigé vers la page de connexion pour vous identifier avec vos nouveaux identifiants.
-
-{{% notice style="warning" title="Serveurs sans e-mail" icon="triangle-exclamation" %}}
-Sur les instances fonctionnant sans service de messagerie, la récupération de mot de passe n'est pas disponible : cliquer sur « Mot de passe oublié ? » affiche un message vous invitant à contacter l'administrateur du serveur pour réinitialiser votre mot de passe.
-{{% /notice %}}

content/pages/me.en.md

@@ -0,0 +1,31 @@
+---
+date: 2021-01-12T21:38:49+02:00
+title: "Set up your profile"
+author: Frederic
+weight: 40
+---
+
+You access this page by clicking on the top menu "My Account" link.
+
+## Account Settings
+
+The screen is divided into three parts. The first one will allow you to change the settings related to your account: such as the language of the interface or the way the contextual help is displayed.
+
+
+## Change password
+
+The second part of the screen allows you to change the password.
+
+
+## Change account email address
+
+It is currently not possible to change the email address of your account. We invite you to contact us if you wish to change it.
+
+
+## Delete your account
+
+The last part of the page allows you to delete your happyDomain account.
+
+Once the deletion is validated, your account will no longer be accessible and all data belonging to you will be deleted shortly after, during a regular database cleanup.
+
+From the moment you delete your account, your domains will continue to respond according to the last update you made on happyDomain. The deletion will not affect the distributed data.

content/pages/me.fr.md

@@ -0,0 +1,30 @@
+---
+date: 2020-12-10T10:26:54+01:00
+title: "Paramétrer son profil"
+weight: 40
+---
+
+Vous accédez à cette page en cliquant sur le lien « Mon compte » dans le menu en haut.
+
+## Paramètres du compte
+
+L'écran est divisé en 3 parties. La première va vous permettre de modifier les paramètres liés à votre compte : tel que la langue de l'interface ou la manière dont l'aide contextuelle est affichée.
+
+
+## Changer de mot de passe
+
+La seconde partie de l'écran vous permet de changer de mot de passe.
+
+
+## Changer l'adresse électronique de compte
+
+Il n'est pour l'instant pas possible de changer l'adresse électronique de votre compte. Nous vous invitons à nous contacter si vous souhaitez la changer.
+
+
+## Supprimer son compte
+
+La dernière partie de la page vous permet de supprimer votre compte happyDomain.
+
+Une fois la suppression validée, votre compte ne sera plus accessible et l'ensemble des données vous appartenant sera supprimé peu de temps après, lors d'un nettoyage régulier de la base de données.
+
+À partir du moment où vous supprimez votre compte, vos domaines continueront de répondre selon la dernière mise à jour que vous avez effectué sur happyDomain. La suppression n'affectera pas les données distribuées.

content/pages/notifications.en.md

@@ -1,116 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Notifications
-author: nemunaire
-weight: 2300
-description: "Receive alerts when your monitoring checks change state, and configure where and when those alerts are delivered"
----
-
-happyDomain can notify you when something changes on your domains. Notifications are driven by the [monitoring & checks]({{% relref "checks" %}}) system: whenever a checker changes status (for example from **OK** to **Warning**, or back to **OK** after a problem), happyDomain can deliver an alert to the channels you have configured.
-
-You manage notifications from the **Notifications** page in your account settings. It is organised into three tabs: **Channels**, **Preferences** and **History**.
-
-<!-- TODO: screenshot of the notifications page with its three tabs -->
-
-
-## What triggers a notification
-
-Notifications are tied to your checkers. happyDomain watches the status reported by each check and sends a notification when:
-
-- a check **degrades** to (or beyond) a severity you care about, for example reaching **Warning**, **Critical** or **Error**;
-- a check **recovers**, returning to a healthy state, if you have asked to be notified of recoveries.
-
-Each notification therefore describes a status transition (the previous status and the new status) for a given target. Which transitions reach you, and through which channels, is entirely controlled by your **preferences** (see below).
-
-
-## Channels
-
-A **channel** is a destination where notifications are sent. Open the **Channels** tab to manage them.
-
-To add one, click **Add**, choose a **Type**, give it a **Name** (so you can recognise it later) and fill in the type-specific fields. A channel can be **enabled** or disabled with a switch without deleting it.
-
-happyDomain offers the following channel types out of the box:
-
-### Email
-
-Sends notifications to an email address.
-
-- **Email address**: the recipient. If left empty, the notification is sent to your account's email address.
-
-### Webhook
-
-Sends an HTTP request to a URL of your choice, which is useful to integrate happyDomain with chat tools, automation platforms or your own services.
-
-- **Webhook URL** (required): the endpoint that will receive the notification.
-- **Webhook headers**: optional custom HTTP headers (name/value pairs) to add to the request, for example an authorization header.
-- **Webhook secret**: an optional secret used to sign the request so the receiver can verify it really comes from happyDomain.
-
-### UnifiedPush
-
-Delivers push notifications to your devices through a [UnifiedPush](https://unifiedpush.org/) distributor.
-
-- **UnifiedPush endpoint** (required): the endpoint URL provided by your UnifiedPush application.
-
-{{% notice style="info" title="Other channel types" icon="circle-info" %}}
-The list of available types depends on what the instance administrator has enabled. For types that happyDomain does not provide a dedicated form for, the editor falls back to a raw JSON configuration field.
-{{% /notice %}}
-
-### Testing a channel
-
-Once a channel is created and enabled, use the **send/test** button next to it to deliver a test notification. This confirms the configuration works before relying on it for real alerts.
-
-<!-- TODO: screenshot of the channels list with the test button -->
-
-
-## Preferences
-
-Channels say *where* notifications go; **preferences** say *what* gets sent and *when*. Open the **Preferences** tab and click **Add** to create a rule.
-
-A preference combines the following settings:
-
-### Scope
-
-Choose how broadly the rule applies:
-
-- **Global**: applies to all your domains and services.
-- **Domain**: applies to a single domain you select.
-- **Service**: applies to a specific service (you select the domain and provide the service identifier).
-
-### Channels
-
-Select one or more of your configured channels to receive the notifications matching this preference. If you have no channels yet, create one first in the **Channels** tab.
-
-### Minimum status
-
-Pick the lowest severity that should trigger a notification. The available levels, in increasing severity, are **OK**, **Info**, **Warning**, **Critical** and **Error**. Only status changes that reach this level (or higher) are notified. For example, choosing **Warning** means you are alerted on Warning, Critical and Error, but not on purely informational changes.
-
-### Notify on recovery
-
-When enabled, you also receive a notification when a previously degraded check returns to a healthy state, so you know when a problem has been resolved.
-
-### Quiet hours
-
-Optionally define a period during which notifications are held back, for instance overnight. Set a **start** hour and an **end** hour (0 to 23). When quiet hours are active, alerts raised within that window are not sent immediately.
-
-### Enabled
-
-Each preference can be turned on or off with a switch, letting you temporarily suspend a rule without deleting it.
-
-<!-- TODO: screenshot of the preference editor -->
-
-{{% notice style="tip" title="Start simple" icon="lightbulb" %}}
-A common setup is a single **Global** preference, pointing at one channel, with a minimum status of **Warning** and recovery notifications enabled. You can later add more specific per-domain or per-service rules as your needs grow.
-{{% /notice %}}
-
-
-## History
-
-The **History** tab lists the notifications happyDomain has attempted to send. For each entry you can see:
-
-- the target concerned;
-- the status transition (previous status → new status);
-- whether delivery **succeeded** or **failed** (with the error message when it failed).
-
-Use **Load more** to page back through older entries. This view is the place to check why an expected alert did not reach you, for example a channel misconfiguration causing repeated failures.
-
-<!-- TODO: screenshot of the notification history list -->

content/pages/notifications.fr.md

@@ -1,115 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Notifications
-weight: 2300
-description: "Recevoir des alertes lorsque vos contrôles de supervision changent d'état, et configurer où et quand ces alertes sont délivrées"
----
-
-happyDomain peut vous prévenir lorsque quelque chose change sur vos domaines. Les notifications reposent sur le système de [supervision et contrôles]({{% relref "checks" %}}) : chaque fois qu'un contrôle change de statut (par exemple de **OK** à **Avertissement**, ou un retour à **OK** après un problème), happyDomain peut envoyer une alerte vers les canaux que vous avez configurés.
-
-Vous gérez les notifications depuis la page **Notifications** des paramètres de votre compte. Elle s'organise en trois onglets : **Canaux**, **Préférences** et **Historique**.
-
-<!-- TODO: screenshot of the notifications page with its three tabs -->
-
-
-## Ce qui déclenche une notification
-
-Les notifications sont liées à vos contrôles. happyDomain surveille le statut rapporté par chaque contrôle et envoie une notification lorsque :
-
-- un contrôle **se dégrade** jusqu'à (ou au-delà d') une gravité qui vous importe, par exemple en atteignant **Avertissement**, **Critique** ou **Erreur** ;
-- un contrôle **se rétablit**, en revenant à un état sain, si vous avez demandé à être prévenu des rétablissements.
-
-Chaque notification décrit donc une transition de statut (l'ancien statut et le nouveau) pour une cible donnée. Les transitions qui vous parviennent, et par quels canaux, sont entièrement déterminées par vos **préférences** (voir ci-dessous).
-
-
-## Canaux
-
-Un **canal** est une destination vers laquelle les notifications sont envoyées. Ouvrez l'onglet **Canaux** pour les gérer.
-
-Pour en ajouter un, cliquez sur **Ajouter**, choisissez un **Type**, donnez-lui un **Nom** (afin de le reconnaître par la suite) et renseignez les champs propres à ce type. Un canal peut être **activé** ou désactivé à l'aide d'un interrupteur, sans avoir à le supprimer.
-
-happyDomain propose les types de canaux suivants d'origine :
-
-### E-mail
-
-Envoie les notifications à une adresse e-mail.
-
-- **Adresse e-mail** : le destinataire. Si le champ est laissé vide, la notification est envoyée à l'adresse e-mail de votre compte.
-
-### Webhook
-
-Envoie une requête HTTP vers une URL de votre choix, ce qui est utile pour intégrer happyDomain à des outils de discussion, des plateformes d'automatisation ou vos propres services.
-
-- **URL du webhook** (obligatoire) : le point d'accès qui recevra la notification.
-- **En-têtes du webhook** : des en-têtes HTTP personnalisés facultatifs (paires nom/valeur) à ajouter à la requête, par exemple un en-tête d'autorisation.
-- **Secret du webhook** : un secret facultatif servant à signer la requête, afin que le destinataire puisse vérifier qu'elle provient bien de happyDomain.
-
-### UnifiedPush
-
-Délivre des notifications push sur vos appareils via un distributeur [UnifiedPush](https://unifiedpush.org/).
-
-- **Point d'accès UnifiedPush** (obligatoire) : l'URL du point d'accès fournie par votre application UnifiedPush.
-
-{{% notice style="info" title="Autres types de canaux" icon="circle-info" %}}
-La liste des types disponibles dépend de ce que l'administrateur de l'instance a activé. Pour les types pour lesquels happyDomain ne propose pas de formulaire dédié, l'éditeur bascule sur un champ de configuration JSON brut.
-{{% /notice %}}
-
-### Tester un canal
-
-Une fois un canal créé et activé, utilisez le bouton d'envoi/test situé à côté de lui pour délivrer une notification de test. Cela confirme que la configuration fonctionne avant de compter dessus pour de vraies alertes.
-
-<!-- TODO: screenshot of the channels list with the test button -->
-
-
-## Préférences
-
-Les canaux indiquent *où* vont les notifications ; les **préférences** indiquent *quoi* est envoyé et *quand*. Ouvrez l'onglet **Préférences** puis cliquez sur **Ajouter** pour créer une règle.
-
-Une préférence combine les réglages suivants :
-
-### Portée
-
-Choisissez l'étendue d'application de la règle :
-
-- **Globale** : s'applique à l'ensemble de vos domaines et services.
-- **Domaine** : s'applique à un seul domaine que vous sélectionnez.
-- **Service** : s'applique à un service précis (vous sélectionnez le domaine et fournissez l'identifiant du service).
-
-### Canaux
-
-Sélectionnez un ou plusieurs de vos canaux configurés pour recevoir les notifications correspondant à cette préférence. Si vous n'avez pas encore de canal, créez-en un d'abord dans l'onglet **Canaux**.
-
-### Statut minimum
-
-Choisissez la gravité la plus basse qui doit déclencher une notification. Les niveaux disponibles, par gravité croissante, sont **OK**, **Info**, **Avertissement**, **Critique** et **Erreur**. Seuls les changements de statut qui atteignent ce niveau (ou un niveau supérieur) sont notifiés. Par exemple, choisir **Avertissement** signifie que vous êtes alerté pour les états Avertissement, Critique et Erreur, mais pas pour les changements purement informatifs.
-
-### Notifier le rétablissement
-
-Lorsque cette option est activée, vous recevez également une notification quand un contrôle auparavant dégradé revient à un état sain, afin de savoir qu'un problème a été résolu.
-
-### Heures calmes
-
-Vous pouvez définir une période durant laquelle les notifications sont retenues, par exemple la nuit. Indiquez une heure de **début** et une heure de **fin** (de 0 à 23). Lorsque les heures calmes sont actives, les alertes survenant dans cette plage ne sont pas envoyées immédiatement.
-
-### Activée
-
-Chaque préférence peut être activée ou désactivée à l'aide d'un interrupteur, ce qui permet de suspendre temporairement une règle sans la supprimer.
-
-<!-- TODO: screenshot of the preference editor -->
-
-{{% notice style="tip" title="Commencez simplement" icon="lightbulb" %}}
-Une configuration courante consiste en une unique préférence **Globale**, pointant vers un canal, avec un statut minimum d'**Avertissement** et les notifications de rétablissement activées. Vous pourrez ensuite ajouter des règles plus spécifiques par domaine ou par service au fur et à mesure de vos besoins.
-{{% /notice %}}
-
-
-## Historique
-
-L'onglet **Historique** liste les notifications que happyDomain a tenté d'envoyer. Pour chaque entrée, vous pouvez voir :
-
-- la cible concernée ;
-- la transition de statut (ancien statut → nouveau statut) ;
-- si l'envoi a **réussi** ou **échoué** (avec le message d'erreur en cas d'échec).
-
-Utilisez **Charger plus** pour remonter dans les entrées plus anciennes. Cette vue est l'endroit où vérifier pourquoi une alerte attendue ne vous est pas parvenue, par exemple un canal mal configuré provoquant des échecs répétés.
-
-<!-- TODO: screenshot of the notification history list -->

content/pages/provider-features.en.md

@@ -1,45 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Provider features
-author: nemunaire
-weight: 700
-description: "Compare what each DNS provider supports with the provider feature matrix"
----
-
-Not every DNS provider supports the same set of capabilities. Some can list the domains in your account automatically, others handle only the most common record types, and a few support more specialised records such as `CAA` or `TLSA`. The **Supported providers** page presents this information as a single comparison table so you can pick the right provider, or understand why a given [service]({{% relref "services" %}}) is unavailable for one of your domains.
-
-## Reading the feature matrix
-
-The page lists every provider happyDomain integrates with, one per row, with its logo and name. Each column corresponds to a capability, and the cell shows whether that provider supports it:
-
-- a green check mark means the capability **is supported**;
-- a red cross means it **is not supported**.
-
-<!-- TODO: screenshot of the provider feature matrix -->
-
-The table scrolls horizontally if it is wider than your screen, and the header row stays visible while you scroll, so you can always tell which capability each column refers to.
-
-## The capabilities
-
-The matrix compares the following capabilities:
-
-| Column | Meaning |
-|--------|---------|
-| **Supported providers** | The provider can automatically list the domains in your account, so you can import them without typing each name. When unsupported, you add domains manually. |
-| **Common types** | The provider supports the everyday record types (such as `A`, `AAAA`, `MX`, `TXT`, `CNAME`). This is what most domains need. |
-| **CAA** | Support for `CAA` records, which declare the certificate authorities allowed to issue certificates for your domain. |
-| **OPENPGPKEY** | Support for `OPENPGPKEY` records, used to publish OpenPGP public keys in DNS. |
-| **PTR** | Support for `PTR` records, used mainly for reverse DNS (mapping an IP address back to a name). |
-| **SRV** | Support for `SRV` records, which advertise the location of a service (port and host) for protocols that rely on them. |
-| **SSHFP** | Support for `SSHFP` records, which publish SSH host key fingerprints in DNS. |
-| **TLSA** | Support for `TLSA` records, used by DANE to bind a certificate to a name. |
-
-{{% notice style="info" title="Why this matters" icon="circle-info" %}}
-When you add a [service]({{% relref "services" %}}) to a subdomain, happyDomain only offers the service types your provider can actually publish. If a service you expect is greyed out, the feature matrix is the place to confirm whether the underlying record type is supported by that provider.
-{{% /notice %}}
-
-## Choosing a provider
-
-If you are still deciding where to host your DNS, use this page to make sure the provider you have in mind covers the record types you need. A provider that supports the **Common types** is enough for most websites and email setups; the specialised columns matter only if you rely on the corresponding features (DANE, reverse DNS, SSH fingerprints, and so on).
-
-Once you have picked a provider, head over to [add it]({{% relref "provider-new-choice" %}}) to happyDomain.

content/pages/provider-features.fr.md

@@ -1,44 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Fonctionnalités des fournisseurs
-weight: 700
-description: "Comparer ce que prend en charge chaque hébergeur DNS grâce à la matrice des fonctionnalités"
----
-
-Tous les hébergeurs DNS ne prennent pas en charge les mêmes capacités. Certains savent lister automatiquement les domaines de votre compte, d'autres ne gèrent que les types d'enregistrements les plus courants, et quelques-uns prennent en charge des enregistrements plus spécialisés comme `CAA` ou `TLSA`. La page **Fournisseurs supportés** présente ces informations sous la forme d'un unique tableau comparatif, afin de vous aider à choisir le bon hébergeur, ou à comprendre pourquoi un [service]({{% relref "services" %}}) donné n'est pas disponible pour l'un de vos domaines.
-
-## Lire la matrice des fonctionnalités
-
-La page liste tous les hébergeurs avec lesquels happyDomain s'intègre, un par ligne, avec son logo et son nom. Chaque colonne correspond à une capacité, et la cellule indique si l'hébergeur la prend en charge :
-
-- une coche verte signifie que la capacité **est prise en charge** ;
-- une croix rouge signifie qu'elle **n'est pas prise en charge**.
-
-<!-- TODO: capture d'écran de la matrice des fonctionnalités des fournisseurs -->
-
-Le tableau défile horizontalement s'il est plus large que votre écran, et la ligne d'en-tête reste visible pendant le défilement : vous savez ainsi toujours à quelle capacité se rapporte chaque colonne.
-
-## Les capacités
-
-La matrice compare les capacités suivantes :
-
-| Colonne | Signification |
-|---------|---------------|
-| **Fournisseurs supportés** | L'hébergeur sait lister automatiquement les domaines de votre compte, ce qui vous permet de les importer sans saisir chaque nom. Lorsque ce n'est pas pris en charge, vous ajoutez les domaines manuellement. |
-| **Types courants** | L'hébergeur prend en charge les types d'enregistrements du quotidien (comme `A`, `AAAA`, `MX`, `TXT`, `CNAME`). C'est ce dont la plupart des domaines ont besoin. |
-| **CAA** | Prise en charge des enregistrements `CAA`, qui déclarent les autorités de certification autorisées à émettre des certificats pour votre domaine. |
-| **OPENPGPKEY** | Prise en charge des enregistrements `OPENPGPKEY`, utilisés pour publier des clés publiques OpenPGP dans le DNS. |
-| **PTR** | Prise en charge des enregistrements `PTR`, utilisés principalement pour le DNS inverse (associer une adresse IP à un nom). |
-| **SRV** | Prise en charge des enregistrements `SRV`, qui annoncent l'emplacement d'un service (port et hôte) pour les protocoles qui s'appuient dessus. |
-| **SSHFP** | Prise en charge des enregistrements `SSHFP`, qui publient les empreintes des clés d'hôte SSH dans le DNS. |
-| **TLSA** | Prise en charge des enregistrements `TLSA`, utilisés par DANE pour lier un certificat à un nom. |
-
-{{% notice style="info" title="Pourquoi c'est important" icon="circle-info" %}}
-Lorsque vous ajoutez un [service]({{% relref "services" %}}) à un sous-domaine, happyDomain ne propose que les types de services que votre hébergeur peut réellement publier. Si un service que vous attendiez apparaît grisé, la matrice des fonctionnalités est l'endroit où vérifier si le type d'enregistrement sous-jacent est pris en charge par cet hébergeur.
-{{% /notice %}}
-
-## Choisir un hébergeur
-
-Si vous hésitez encore sur l'endroit où héberger votre DNS, servez-vous de cette page pour vous assurer que l'hébergeur envisagé couvre les types d'enregistrements dont vous avez besoin. Un hébergeur qui prend en charge les **types courants** suffit pour la plupart des sites web et des configurations de messagerie ; les colonnes spécialisées ne comptent que si vous utilisez les fonctionnalités correspondantes (DANE, DNS inverse, empreintes SSH, etc.).
-
-Une fois votre hébergeur choisi, rendez-vous sur la page pour l'[ajouter]({{% relref "provider-new-choice" %}}) à happyDomain.

content/pages/provider-list/_index.en.md

@@ -5,7 +5,7 @@ title: List your name providers
 aliases:
     hosters
     source-list
-weight: 400
+weight: 15
 ---
 
 You can access this page by clicking on the the top menu link "The hosts of my domains".
@@ -14,9 +14,9 @@ You can access this page by clicking on the the top menu link "The hosts of my d
 
 This page shows only the list of registries and domain hosts you have added to your account, and [allows you to add more]({{% relref "provider-new-choice" %}}).
 
-![The hosters of your domains](providers-list.webp)
+![The hosters of your domains](hosters-list.png)
 
 You can add a new host by clicking on the "+" button at the top of the page.
 
-By clicking on a row of the table, you will access [the parameters used by happyDomain to contact this host]({{% relref "provider-update" %}}).
+By clicking on a row of the table, you will access the parameters used by happyDomain to contact this host.
 This is where you'll be able to modify the name you gave to this host, and where you'll be able to modify the access parameters.

content/pages/provider-list/_index.fr.md

@@ -4,18 +4,18 @@ title: Lister vos hébergeurs de noms
 aliases:
     hosters
     source-list
-weight: 400
+weight: 15
 ---
 
-Vous accédez à cette page en cliquant sur le lien « Les hébergeurs de mes domaines » dans le menu en haut.
+Vous accédez à cette page en cliquant sur le lien « Les hôtes de mes domaines » dans le menu en haut.
 
 ## Vos registres et hébergeurs de domaines
 
 Cette page montre uniquement la liste des registres et des hébergeurs de domaines que vous avez ajouté à votre compte, et [vous permet d'en ajouter]({{% relref "provider-new-choice" %}}).
 
-![Les hébergeurs de vos domaines](providers-list.webp)
+![Les hébergeurs de vos domaines](hosters-list.png)
 
 Vous pouvez ajouter un nouvel hébergeur en cliquant sur le bouton +, présent en haut de la page.
 
-En cliquant sur une ligne du tableau, vous accéderez aux [paramètres qu'utilise happyDomain pour contacter cet hébergeur]({{% relref "provider-update" %}}).
+En cliquant sur une ligne du tableau, vous accéderez aux paramètres qu'utilise happyDomain pour contacter cet hébergeur.
 C'est là que vous allez pouvoir modifier le nom que vous avez donné à cet hébergeur, et que vous pourrez modifier les paramètres d'accès.

content/pages/provider-new-choice/_index.en.md

@@ -4,7 +4,7 @@ author: Frederic
 title: Add a provider
 aliases:
     source-new-choice
-weight: 500
+weight: 17
 ---
 
 You access this screen by clicking on the ["My domain providers"]({{% relref "provider-list" %}}) link in the top menu, then by clicking on the "+ Add a new domain host" button.

content/pages/provider-new-choice/_index.fr.md

@@ -3,7 +3,7 @@ date: 2020-12-09T18:12:45+01:00
 title: Ajouter un hébergeur
 aliases:
     source-new-choice
-weight: 500
+weight: 17
 ---
 
 Vous accédez à cet écran en cliquant sur le lien [« Les hébergeurs de mes domaines »]({{% relref "provider-list" %}}) dans le menu en haut, puis en cliquant sur le bouton « + Ajouter un nouvel hébergeur de domaines ».

content/pages/provider-update.en.md

@@ -5,7 +5,7 @@ title: Hosting provider settings
 aliases:
     source-new-state
     source-update
-weight: 600
+weight: 19
 ---
 
 You access this screen either:

content/pages/provider-update.fr.md

@@ -4,7 +4,7 @@ title: Paramètres de l'hébergeur
 aliases:
     source-new-state
     source-update
-weight: 600
+weight: 19
 ---
 
 Vous accédez à cet écran soit :

content/pages/publish-changes.en.md

@@ -0,0 +1,16 @@
+---
+date: 2025-06-15T11:08:00+02:00
+title: "Publish modifications"
+weight: 40
+---
+
+When you make a change in happyDomain, it is not directly passed on to your host or server.
+
+Once you've made all the changes you wish to be propagated, click on the “Distribute my changes” button.
+
+A window will open showing exactly which concrete changes will be passed on to your host or server.
+
+If at this stage you don't want to apply all the changes, you can uncheck some of them.
+
+Don't forget to enter a message in the appropriate field: this message will be recorded in your log.
+Later, when you need to see what changes you've made, it might be simpler to read “Changing host from Wordpress to Alwaysdata” rather than trying to interpret IP changes, ...

content/pages/publish-changes.fr.md

@@ -0,0 +1,16 @@
+---
+date: 2025-06-15T11:08:00+02:00
+title: "Publier des modifications"
+weight: 40
+---
+
+Lorsque vous effectuez un changement dans happyDomain, celui-ci n'est pas directement répercuté auprès de votre hébergeur ou de votre serveur.
+
+Une fois que vous avez fait toutes les modifications que vous souhaitez voir propagées, cliquez sur le bouton « Diffuser mes changements ».
+
+Une fenêtre va s'ouvrir montrant précisément quelle modifications concrètes seront répercutées auprès de votre hébergeur ou de votre serveur.
+
+Si à ce stade vous ne voulez pas appliquer tous les changements, vous pouvez en décocher certains.
+
+N'oubliez pas d'indiquer un message dans le champs prévu à cet effet : ce message sera consigné dans votre journal.
+Plus tard, lorsque vous aurez besoin de voir quelles ont été vos modifications, cela pourrait s'avérer plus simple de lire « Changement d'hébergeur de Wordpress vers Alwaysdata » plutôt que de chercher à interpréter les changements d'IP, ...

content/pages/publish-changes/index.en.md

@@ -1,68 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: "Publishing changes"
-author: nemunaire
-weight: 1300
-description: "Review the diff of your pending changes, choose exactly which ones to apply, and publish them to your provider"
----
-
-When you make a change in happyDomain, it is not sent to your hosting provider straight away. Your edits accumulate in a working copy, and nothing reaches your provider until you decide to publish. Before that happens, happyDomain lets you review the exact list of changes that your edits produce, fine-tune what will be applied, and record a message for your history.
-
-## Opening the diff
-
-In the zone editor, the **Publish my changes** button shows a small counter with the number of pending changes detected for your zone. Click it to open the review window.
-
-![The Publish my changes button with its pending-changes counter](happydomain-publish-changes-button.webp)
-
-happyDomain computes the difference between the zone as it currently lives at your provider and the working copy you have been editing. If everything is already in sync, you will simply see a message telling you there is nothing to apply.
-
-## Understanding the diff
-
-Each line of the diff describes one concrete correction, written in a human-readable form and colour-coded by its nature:
-
-| Colour | Meaning |
-|--------|---------|
-| **Green** | An addition (a record being created) |
-| **Red** | A deletion (a record being removed) |
-| **Yellow** | A modification (an existing record being changed) |
-| **Blue** | Another kind of change (for example a reordering or provider-specific operation) |
-
-At the bottom of the window, a **summary** recaps how many additions, deletions and modifications are currently selected.
-
-![The diff window listing colour-coded changes with their summary](happydomain-modal-diff-view.webp)
-
-## Selecting which changes to apply
-
-Every line in the diff has a checkbox. By default the changes are listed for your review, and you decide which ones to keep:
-
-- **Uncheck** any change you do not want to apply right now. It stays in your working copy and will reappear next time.
-- Keep checked only the changes you are confident about.
-
-This is useful when you have made several unrelated edits but only want to publish some of them, or when you want to roll out a sensitive change separately.
-
-The summary and the apply button update live to reflect your current selection. If nothing is selected, the apply button stays disabled.
-
-## Writing a commit message
-
-Before applying, enter a message in the **What's changed?** field. This message is recorded in your history alongside the changes.
-
-{{% notice style="tip" title="Describe the intent, not the IPs" icon="lightbulb" %}}
-The diff describes the technical operations, but your message is what makes your history readable later on. When you need to look back at what you did, "Move mail to a new provider" is far easier to understand than re-deriving meaning from a list of IP changes.
-{{% /notice %}}
-
-## A confirmation step for safety
-
-Depending on your [account preferences]({{% relref "settings" %}}), happyDomain may show an extra confirmation screen after you choose to apply:
-
-- It asks your provider to **prepare** the corrections, then shows you exactly how many operations the provider will actually run for your selection.
-- If that number differs from what you selected (for instance because a change was already applied, or the provider expands one change into several), a warning is displayed so you can double-check before confirming.
-
-You can configure whether this confirmation appears always, never, or only when the prepared corrections do not match your selection.
-
-<!-- TODO: screenshot of the confirmation screen showing prepared corrections -->
-
-## After publishing
-
-Once you confirm, happyDomain sends the selected changes to your provider and records the operation, with your message, in the domain's log. From there you can review past deployments at any time, and roll back to an earlier state if needed; see {{% relref "domain-history" %}}.
-
-To inspect the resulting zone itself rather than the diff, or to keep a copy as a standard zone file, see {{% relref "import-export" %}}.

content/pages/publish-changes/index.fr.md

@@ -1,68 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: "Publier des modifications"
-author: nemunaire
-weight: 1300
-description: "Examiner le différentiel de vos changements en attente, choisir précisément ceux à appliquer, et les publier chez votre hébergeur"
----
-
-Lorsque vous effectuez un changement dans happyDomain, celui-ci n'est pas immédiatement répercuté auprès de votre hébergeur. Vos modifications s'accumulent dans une copie de travail, et rien n'est transmis à votre hébergeur tant que vous n'avez pas décidé de publier. Avant cela, happyDomain vous permet d'examiner la liste exacte des changements produits par vos modifications, d'ajuster finement ce qui sera appliqué, et de consigner un message dans votre historique.
-
-## Ouvrir le différentiel
-
-Dans l'éditeur de zone, le bouton « Diffuser mes changements » affiche un petit compteur indiquant le nombre de changements en attente détectés pour votre zone. Cliquez dessus pour ouvrir la fenêtre de relecture.
-
-![Le bouton « Diffuser mes changements » avec son compteur de changements en attente](happydomain-publish-changes-button.webp)
-
-happyDomain calcule la différence entre la zone telle qu'elle existe actuellement chez votre hébergeur et la copie de travail que vous avez éditée. Si tout est déjà synchronisé, un message vous indiquera simplement qu'il n'y a rien à appliquer.
-
-## Comprendre le différentiel
-
-Chaque ligne du différentiel décrit une correction concrète, formulée de façon lisible et colorée selon sa nature :
-
-| Couleur | Signification |
-|---------|---------------|
-| **Vert** | Un ajout (un enregistrement créé) |
-| **Rouge** | Une suppression (un enregistrement retiré) |
-| **Jaune** | Une modification (un enregistrement existant modifié) |
-| **Bleu** | Un autre type de changement (par exemple un réordonnancement ou une opération propre à l'hébergeur) |
-
-En bas de la fenêtre, un **résumé** récapitule le nombre d'ajouts, de suppressions et de modifications actuellement sélectionnés.
-
-![La fenêtre du différentiel listant les changements colorés avec leur résumé](happydomain-modal-diff-view.webp)
-
-## Choisir les changements à appliquer
-
-Chaque ligne du différentiel comporte une case à cocher. Par défaut, les changements sont listés pour votre relecture, et c'est vous qui décidez lesquels conserver :
-
-- **Décochez** tout changement que vous ne souhaitez pas appliquer maintenant. Il reste dans votre copie de travail et réapparaîtra la prochaine fois.
-- Ne laissez cochés que les changements dont vous êtes sûr.
-
-C'est utile lorsque vous avez fait plusieurs modifications sans rapport entre elles mais ne voulez en publier qu'une partie, ou lorsque vous souhaitez déployer un changement sensible séparément.
-
-Le résumé et le bouton d'application se mettent à jour en direct selon votre sélection. Si rien n'est sélectionné, le bouton d'application reste désactivé.
-
-## Rédiger un message de validation
-
-Avant d'appliquer, saisissez un message dans le champ « Qu'est-ce qui a changé ? ». Ce message est consigné dans votre historique aux côtés des changements.
-
-{{% notice style="tip" title="Décrivez l'intention, pas les adresses IP" icon="lightbulb" %}}
-Le différentiel décrit les opérations techniques, mais c'est votre message qui rendra votre historique lisible plus tard. Lorsque vous aurez besoin de revoir ce que vous avez fait, « Déplacement du courrier vers un nouvel hébergeur » est bien plus facile à comprendre que de reconstituer le sens à partir d'une liste de changements d'IP.
-{{% /notice %}}
-
-## Une étape de confirmation par sécurité
-
-Selon les [préférences de votre compte]({{% relref "settings" %}}), happyDomain peut afficher un écran de confirmation supplémentaire après que vous avez choisi d'appliquer :
-
-- Il demande à votre hébergeur de **préparer** les corrections, puis vous montre exactement combien d'opérations l'hébergeur exécutera réellement pour votre sélection.
-- Si ce nombre diffère de ce que vous avez sélectionné (par exemple parce qu'un changement était déjà appliqué, ou parce que l'hébergeur décompose un changement en plusieurs), un avertissement s'affiche pour que vous puissiez vérifier avant de confirmer.
-
-Vous pouvez configurer si cette confirmation apparaît toujours, jamais, ou uniquement lorsque les corrections préparées ne correspondent pas à votre sélection.
-
-<!-- TODO: screenshot de l'écran de confirmation montrant les corrections préparées -->
-
-## Après la publication
-
-Une fois que vous confirmez, happyDomain envoie les changements sélectionnés à votre hébergeur et consigne l'opération, avec votre message, dans le journal du domaine. Vous pouvez ensuite consulter les déploiements passés à tout moment, et [revenir à un état antérieur]({{% relref "domain-history" %}}) si besoin.
-
-Pour inspecter la zone résultante elle-même plutôt que le différentiel, ou pour en conserver une copie sous forme de fichier de zone standard, consultez la page [Importer et exporter]({{% relref "import-export" %}}).

content/pages/quotas.en.md

@@ -1,40 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Quotas & limits
-author: nemunaire
-weight: 2400
-description: "Understand the limits an administrator may set on your account, and what happens when one is reached"
----
-
-A happyDomain instance can apply **quotas** to each account. Quotas are limits set by the person running the instance (the administrator), not by you. They exist mainly to keep a shared instance fair and to avoid overloading the servers, and they apply above all to the [monitoring & checks]({{% relref "checks" %}}) system.
-
-{{% notice style="info" title="Quotas are managed by the administrator" icon="circle-info" %}}
-Quotas are **read-only** for regular users. There is no screen in your account where you can view or change your own quota: they are configured server-side and adjusted only through the administration interface. If a limit is getting in your way, the right course of action is to contact the administrator of your instance.
-{{% /notice %}}
-
-
-## What quotas can cover
-
-On a default happyDomain instance, quotas relate to how the monitoring scheduler works for your account. An administrator may set, per account or instance-wide:
-
-- **Maximum checks per day**: a cap on how many checker executions are run automatically for you each day. Once the cap is reached, further scheduled checks wait until the next day.
-- **Result retention**: how long the results of your checks are kept before old executions are automatically cleaned up.
-- **Inactivity pause**: after a period without logging in, the scheduler may stop running your automatic checks until you sign in again. This keeps the instance from spending resources on abandoned accounts.
-- **Scheduling pause**: an administrator can entirely pause automatic scheduling for an account.
-
-Each of these can be left at the instance default, set to a specific value for your account, or explicitly made unlimited, at the administrator's discretion.
-
-{{% notice style="tip" title="No fixed limit on the number of domains" icon="lightbulb" %}}
-On a standard happyDomain instance, the quota system does not impose a built-in cap on the number of domains you can manage. If a particular instance does restrict this, it is a policy of that instance; ask its administrator for the details that apply to you.
-{{% /notice %}}
-
-
-## What you see when a limit is reached
-
-Quotas mostly act in the background. You will not usually see a quota screen; instead you notice their effects:
-
-- **Automatic checks stop running**: if your daily check cap is reached, or your account is in an inactivity or scheduling pause, scheduled checks simply do not run until the condition clears. You can still trigger a check **manually** from the [checks]({{% relref "checks#running-a-check-manually" %}}) interface.
-- **Older results disappear**: with a retention limit, executions older than the allowed age are removed during routine cleanup, so the history only goes back so far.
-- **An action is refused**: where an operation would exceed a limit, the interface shows an error message explaining what went wrong.
-
-If you are unsure whether a behaviour is caused by a quota, or you need a limit raised, contact the administrator of your instance.

content/pages/quotas.fr.md

@@ -1,39 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Quotas et limites
-weight: 2400
-description: "Comprendre les limites qu'un administrateur peut appliquer à votre compte, et ce qu'il se passe lorsque l'une d'elles est atteinte"
----
-
-Une instance happyDomain peut appliquer des **quotas** à chaque compte. Les quotas sont des limites définies par la personne qui administre l'instance (l'administrateur), et non par vous. Ils servent principalement à préserver l'équité sur une instance partagée et à éviter de surcharger les serveurs ; ils concernent avant tout le système de [supervision et contrôles]({{% relref "checks" %}}).
-
-{{% notice style="info" title="Les quotas sont gérés par l'administrateur" icon="circle-info" %}}
-Les quotas sont en **lecture seule** pour les utilisateurs ordinaires. Il n'existe aucun écran dans votre compte permettant de consulter ou de modifier votre propre quota : ils sont configurés côté serveur et ne sont ajustés qu'au travers de l'interface d'administration. Si une limite vous gêne, la bonne démarche consiste à contacter l'administrateur de votre instance.
-{{% /notice %}}
-
-
-## Ce que les quotas peuvent couvrir
-
-Sur une instance happyDomain par défaut, les quotas portent sur le fonctionnement du planificateur de supervision pour votre compte. Un administrateur peut définir, par compte ou pour l'ensemble de l'instance :
-
-- **Nombre maximal de contrôles par jour** : un plafond sur le nombre d'exécutions de contrôles lancées automatiquement pour vous chaque jour. Une fois ce plafond atteint, les contrôles planifiés suivants attendent le lendemain.
-- **Conservation des résultats** : la durée pendant laquelle les résultats de vos contrôles sont conservés avant que les anciennes exécutions ne soient automatiquement nettoyées.
-- **Pause pour inactivité** : après une période sans connexion, le planificateur peut cesser d'exécuter vos contrôles automatiques jusqu'à votre prochaine connexion. Cela évite que l'instance ne dépense des ressources pour des comptes abandonnés.
-- **Pause de planification** : un administrateur peut entièrement suspendre la planification automatique d'un compte.
-
-Chacun de ces réglages peut rester à la valeur par défaut de l'instance, être fixé à une valeur particulière pour votre compte, ou être explicitement rendu illimité, à la discrétion de l'administrateur.
-
-{{% notice style="tip" title="Pas de limite fixe sur le nombre de domaines" icon="lightbulb" %}}
-Sur une instance happyDomain standard, le système de quotas n'impose pas de plafond intégré sur le nombre de domaines que vous pouvez gérer. Si une instance particulière restreint ce point, il s'agit d'une politique propre à cette instance ; demandez à son administrateur les détails qui vous concernent.
-{{% /notice %}}
-
-
-## Ce que vous voyez lorsqu'une limite est atteinte
-
-Les quotas agissent surtout en arrière-plan. Vous ne verrez généralement pas d'écran de quota ; vous en constatez plutôt les effets :
-
-- **Les contrôles automatiques cessent de s'exécuter** : si votre plafond quotidien de contrôles est atteint, ou si votre compte est en pause pour inactivité ou de planification, les contrôles planifiés ne s'exécutent simplement plus tant que la condition persiste. Vous pouvez toujours déclencher un contrôle **manuellement** depuis l'interface des [contrôles]({{% relref "checks#lancer-une-vérification-manuellement" %}}).
-- **Les anciens résultats disparaissent** : avec une limite de conservation, les exécutions plus anciennes que la durée autorisée sont supprimées lors du nettoyage régulier, si bien que l'historique ne remonte que jusqu'à un certain point.
-- **Une action est refusée** : lorsqu'une opération dépasserait une limite, l'interface affiche un message d'erreur expliquant ce qui n'a pas fonctionné.
-
-Si vous ne savez pas si un comportement est dû à un quota, ou si vous avez besoin qu'une limite soit relevée, contactez l'administrateur de votre instance.

content/pages/services/index.en.md

@@ -1,86 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Services
-author: nemunaire
-weight: 1200
-description: "Understand how happyDomain turns raw DNS records into high-level services, and how to add one to a subdomain"
----
-
-happyDomain does not ask you to think in terms of individual DNS records. Instead, it groups the records that belong together into a single, meaningful **service**: a mailbox, a website, a delegation, a CAA policy, and so on. This is the foundation of the [abstract view]({{% relref "domain-abstract" %}}) of your zone.
-
-## What is a service?
-
-A service is a higher-level object that hides the complexity of one or several DNS records behind a clear, purpose-driven form.
-
-For example, instead of editing a raw `MX` record, a couple of `A`/`AAAA` records and an `SPF` `TXT` record separately, you fill in a single **email** service. happyDomain takes care of generating the right records, with the right names and the right syntax.
-
-Each service belongs to a family:
-
-- **Services** (abstract): the recommended, human-friendly objects (email, website, CAA, delegation, ...). They map to one or more records automatically.
-- **Providers**: services tied to a specific third party that publishes its own helper (for example a hosted service that needs a predefined set of records).
-- **Raw DNS resources**: a fallback that lets you add a single record (`A`, `TXT`, `SRV`, ...) directly, when no abstract service fits your need.
-
-{{% notice style="info" title="Why services instead of records?" icon="lightbulb" %}}
-Working with services means you do not have to remember the exact record types, their order, or their syntax. happyDomain validates your input and generates valid DNS for you, which greatly reduces the risk of a misconfiguration.
-{{% /notice %}}
-
-## The service view of a subdomain
-
-When you open a domain, each subdomain is displayed as a list of the services attached to it. A subdomain can hold several services at once: for instance the apex (`@`) of a domain often carries an email service, a website service and a CAA policy together.
-
-![A subdomain showing several services in the zone editor](happydomain-abstract-zone-records.webp)
-
-From this view you can:
-
-- **Add** a new service to the subdomain.
-- **Edit** an existing service to change its values.
-- **Delete** a service you no longer need.
-
-All these changes are staged locally and only applied to your provider when you publish them. See the [abstract view]({{% relref "domain-abstract" %}}) for how editing and propagation work.
-
-## Adding a service to a subdomain
-
-To attach a new service, start from the subdomain where you want it (see [Subdomains]({{% relref "subdomains" %}}) for navigating the zone), then follow these steps.
-
-### 1. Open the service selector
-
-Click the **Add service** action on the subdomain. A selector opens, listing every service type you can add.
-
-![The service selector modal](happydomain-modal-service-selector.webp)
-
-The selector is organised in tabs so you can narrow down the list:
-
-- **All**: every available service type.
-- **Services**: the abstract, high-level services (recommended).
-- **Providers**: services specific to a provider.
-- **Raw DNS resources**: a single record type when you need full control.
-
-You can also type in the search box at the top to filter the list by name. Pressing Enter selects the first available match.
-
-{{% notice style="tip" title="Greyed-out entries" icon="circle-info" %}}
-Some service types may appear disabled. This happens when the service cannot be added in the current context: for example because your DNS provider does not support the underlying record type, or because that service already exists on this subdomain and only one instance is allowed. Hover over a disabled entry to see the reason.
-{{% /notice %}}
-
-### 2. Choose the service type
-
-Select the service that matches what you want to publish. happyDomain knows which record types your provider supports, so only the relevant choices are offered. To check what a given provider can handle, see the [Provider features]({{% relref "provider-features" %}}) page.
-
-### 3. Fill in the service form
-
-happyDomain then presents a form tailored to the chosen service. Each field corresponds to a meaningful piece of information (a target host, a priority, a public key, a policy value, ...) rather than to raw record syntax.
-
-<!-- TODO: screenshot of a service edit form -->
-
-Fill in the fields, then confirm to add the service to the subdomain.
-
-### 4. Review the generated records
-
-Once the form is validated, happyDomain converts your input into the corresponding DNS records and adds them to the staged zone. You can review them in the [abstract view]({{% relref "domain-abstract" %}}) before publishing your changes to your provider.
-
-## Trying services without an account
-
-happyDomain also offers a public **record generator** where you can build and preview the DNS records produced by a service without signing in. Pick a service type, enter a domain name, fill in the form, and the generated zone-file entries are displayed instantly.
-
-This is a handy way to discover how a given service maps to actual DNS records, or to grab a record you will paste elsewhere.
-
-<!-- TODO: screenshot of the public record generator -->

content/pages/services/index.fr.md

@@ -1,85 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Services
-weight: 1200
-description: "Comprendre comment happyDomain transforme les enregistrements DNS bruts en services de haut niveau, et comment en ajouter un à un sous-domaine"
----
-
-happyDomain ne vous demande pas de raisonner en termes d'enregistrements DNS individuels. À la place, il regroupe les enregistrements qui vont ensemble au sein d'un unique **service** porteur de sens : une messagerie, un site web, une délégation, une politique CAA, etc. C'est le fondement de la [vue abstraite]({{% relref "domain-abstract" %}}) de votre zone.
-
-## Qu'est-ce qu'un service ?
-
-Un service est un objet de plus haut niveau qui masque la complexité d'un ou de plusieurs enregistrements DNS derrière un formulaire clair, orienté usage.
-
-Par exemple, au lieu d'éditer séparément un enregistrement `MX`, quelques enregistrements `A`/`AAAA` et un enregistrement `SPF` de type `TXT`, vous remplissez un seul service **messagerie**. happyDomain se charge de générer les bons enregistrements, avec les bons noms et la bonne syntaxe.
-
-Chaque service appartient à une famille :
-
-- **Services** (abstraits) : les objets recommandés, pensés pour les humains (messagerie, site web, CAA, délégation, etc.). Ils se traduisent automatiquement en un ou plusieurs enregistrements.
-- **Fournisseurs** : des services liés à un acteur tiers précis qui publie son propre assistant (par exemple un service hébergé nécessitant un ensemble d'enregistrements prédéfini).
-- **Ressources DNS brutes** : une solution de repli qui vous permet d'ajouter directement un enregistrement unique (`A`, `TXT`, `SRV`, etc.), lorsqu'aucun service abstrait ne correspond à votre besoin.
-
-{{% notice style="info" title="Pourquoi des services plutôt que des enregistrements ?" icon="lightbulb" %}}
-Travailler avec des services vous évite d'avoir à mémoriser les types d'enregistrements exacts, leur ordre ou leur syntaxe. happyDomain valide votre saisie et génère du DNS correct à votre place, ce qui réduit fortement le risque d'erreur de configuration.
-{{% /notice %}}
-
-## La vue par services d'un sous-domaine
-
-Lorsque vous ouvrez un domaine, chaque sous-domaine est présenté sous la forme d'une liste des services qui lui sont rattachés. Un sous-domaine peut accueillir plusieurs services à la fois : par exemple, la racine (`@`) d'un domaine porte souvent à la fois un service de messagerie, un service de site web et une politique CAA.
-
-![Un sous-domaine affichant plusieurs services dans l'éditeur de zone](happydomain-abstract-zone-records.webp)
-
-Depuis cette vue, vous pouvez :
-
-- **Ajouter** un nouveau service au sous-domaine ;
-- **Modifier** un service existant pour en changer les valeurs ;
-- **Supprimer** un service dont vous n'avez plus besoin.
-
-Toutes ces modifications sont préparées localement et ne sont appliquées chez votre hébergeur qu'au moment de leur publication. Consultez la [vue abstraite]({{% relref "domain-abstract" %}}) pour comprendre le fonctionnement de l'édition et de la propagation.
-
-## Ajouter un service à un sous-domaine
-
-Pour rattacher un nouveau service, placez-vous sur le sous-domaine où vous le souhaitez (voir [Sous-domaines]({{% relref "subdomains" %}}) pour naviguer dans la zone), puis suivez ces étapes.
-
-### 1. Ouvrir le sélecteur de services
-
-Cliquez sur l'action **Ajouter un service** du sous-domaine. Un sélecteur s'ouvre, listant tous les types de services que vous pouvez ajouter.
-
-![La fenêtre de sélection des services](happydomain-modal-service-selector.webp)
-
-Le sélecteur est organisé en onglets pour vous aider à restreindre la liste :
-
-- **Tous** : tous les types de services disponibles.
-- **Services** : les services abstraits de haut niveau (recommandé).
-- **Fournisseurs** : les services spécifiques à un fournisseur.
-- **Ressources DNS brutes** : un type d'enregistrement unique, lorsque vous avez besoin d'un contrôle total.
-
-Vous pouvez également saisir un terme dans le champ de recherche, en haut, pour filtrer la liste par nom. Appuyer sur Entrée sélectionne le premier résultat disponible.
-
-{{% notice style="tip" title="Entrées grisées" icon="circle-info" %}}
-Certains types de services peuvent apparaître désactivés. Cela se produit lorsque le service ne peut pas être ajouté dans le contexte actuel : par exemple parce que votre hébergeur DNS ne prend pas en charge le type d'enregistrement sous-jacent, ou parce que ce service existe déjà sur ce sous-domaine et qu'une seule instance est autorisée. Survolez une entrée désactivée pour en connaître la raison.
-{{% /notice %}}
-
-### 2. Choisir le type de service
-
-Sélectionnez le service correspondant à ce que vous souhaitez publier. happyDomain connaît les types d'enregistrements pris en charge par votre hébergeur : seuls les choix pertinents vous sont donc proposés. Pour savoir ce qu'un hébergeur donné sait gérer, consultez la page [Fonctionnalités des fournisseurs]({{% relref "provider-features" %}}).
-
-### 3. Remplir le formulaire du service
-
-happyDomain présente alors un formulaire adapté au service choisi. Chaque champ correspond à une information porteuse de sens (un hôte cible, une priorité, une clé publique, une valeur de politique, etc.) plutôt qu'à de la syntaxe d'enregistrement brute.
-
-<!-- TODO: capture d'écran d'un formulaire d'édition de service -->
-
-Renseignez les champs, puis validez pour ajouter le service au sous-domaine.
-
-### 4. Vérifier les enregistrements générés
-
-Une fois le formulaire validé, happyDomain convertit votre saisie en enregistrements DNS correspondants et les ajoute à la zone en préparation. Vous pouvez les vérifier dans la [vue abstraite]({{% relref "domain-abstract" %}}) avant de publier vos modifications chez votre hébergeur.
-
-## Essayer les services sans compte
-
-happyDomain propose également un **générateur d'enregistrements** public qui vous permet de construire et de prévisualiser les enregistrements DNS produits par un service sans être connecté. Choisissez un type de service, saisissez un nom de domaine, remplissez le formulaire : les entrées de fichier de zone générées s'affichent instantanément.
-
-C'est un moyen pratique de découvrir comment un service donné se traduit en véritables enregistrements DNS, ou de récupérer un enregistrement à coller ailleurs.
-
-<!-- TODO: capture d'écran du générateur d'enregistrements public -->

content/pages/settings.en.md

@@ -1,76 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Your account and settings
-author: nemunaire
-weight: 2000
-description: "Manage your happyDomain account and tailor the interface: language, field hints, confirmation, zone view, password and account deletion"
-aliases:
-    me
----
-
-happyDomain lets you manage your account and tailor how the interface behaves. Your preferences are saved with your account, so you find them again on every device you connect from.
-
-You reach this page from the **My Account** link in the top menu. Each option is described below.
-
-<!-- TODO: screenshot of the settings form -->
-
-## Language
-
-Choose the language used throughout the interface. The list contains every language currently available in your happyDomain instance. Changing it takes effect as soon as you save.
-
-## Field hints
-
-Form fields often come with a short help text. This setting controls how that help is displayed:
-
-- **Hide** -- no help text is shown.
-- **Tooltip near field** -- the help appears as a tooltip when you hover the field.
-- **Under field when focused** -- the help appears below the field, but only while you are editing it.
-- **Under field, always** -- the help is permanently displayed below each field.
-
-Pick the level of guidance that suits your familiarity with DNS.
-
-## Confirmation before applying
-
-When you publish changes to your DNS provider, happyDomain can show a confirmation step beforehand. This setting decides when:
-
-- **Ask on unexpected differences** -- the confirmation appears only when the changes differ from what was expected.
-- **Always ask** -- a confirmation is always shown before applying.
-- **Never ask, overwrite on publish** -- changes are applied directly, without a confirmation step.
-
-See [Publishing changes]({{% relref "publish-changes" %}}) for the full publication workflow.
-
-## Zone view layout
-
-Choose how a domain's zone is displayed:
-
-- **Grid view (easiest)** -- the most visual and approachable layout.
-- **List view (fastest)** -- a compact list, quicker to scan.
-- **List with records (advanced)** -- a list that also exposes the underlying DNS records, for advanced users.
-
-## Show DNS record types
-
-This switch shows the resource record type (A, MX, CNAME, etc.) associated with each service. It is meant for users who are already familiar with DNS and want to see the technical record types behind the friendly service names.
-
-## Newsletter
-
-The option to receive news about future improvements is proposed when you [create your account]({{% relref "signup" %}}). To change your subscription afterwards, refer to the unsubscribe link included in the messages you receive.
-
-## Saving
-
-When your preferences are set, click **Save settings**. A confirmation message appears and the new settings take effect immediately, including a language change if you made one.
-
-## Change password
-
-A dedicated part of the page lets you change the password of your account.
-
-## Change account email address
-
-It is currently not possible to change the email address of your account. We invite you to contact us if you wish to change it.
-
-## Delete your account
-
-The last part of the page allows you to delete your happyDomain account.
-
-Once the deletion is validated, your account will no longer be accessible and all data belonging to you will be deleted shortly after, during a regular database cleanup.
-
-From the moment you delete your account, your domains will continue to respond according to the last update you made on happyDomain. The deletion will not affect the distributed data.

content/pages/settings.fr.md

@@ -1,75 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Votre compte et vos réglages
-weight: 2000
-description: "Gérez votre compte happyDomain et personnalisez l'interface : langue, aide des champs, confirmation, affichage des zones, mot de passe et suppression du compte"
-aliases:
-    me
----
-
-happyDomain vous permet de gérer votre compte et d'ajuster le comportement de l'interface. Vos préférences sont enregistrées avec votre compte ; vous les retrouvez ainsi sur chaque appareil depuis lequel vous vous connectez.
-
-Vous accédez à cette page en cliquant sur le lien « Mon compte » dans le menu en haut. Chaque option est décrite ci-dessous.
-
-<!-- TODO: screenshot of the settings form -->
-
-## Langue
-
-Choisissez la langue utilisée dans toute l'interface. La liste contient toutes les langues actuellement disponibles sur votre instance happyDomain. Le changement prend effet dès l'enregistrement.
-
-## Aide des champs
-
-Les champs des formulaires sont souvent accompagnés d'un court texte d'aide. Ce réglage détermine la façon dont cette aide s'affiche :
-
-- **Masquer** : aucun texte d'aide n'est affiché.
-- **Infobulle près du champ** : l'aide apparaît sous forme d'infobulle au survol du champ.
-- **Sous le champ lors de la saisie** : l'aide apparaît sous le champ, mais uniquement pendant que vous le modifiez.
-- **Sous le champ, en permanence** : l'aide reste affichée sous chaque champ.
-
-Choisissez le niveau d'accompagnement adapté à votre aisance avec le DNS.
-
-## Confirmation avant application
-
-Lorsque vous publiez des modifications chez votre fournisseur DNS, happyDomain peut afficher une étape de confirmation au préalable. Ce réglage décide du moment :
-
-- **Demander en cas de différences inattendues** : la confirmation n'apparaît que lorsque les modifications diffèrent de ce qui était attendu.
-- **Toujours demander** : une confirmation est systématiquement affichée avant l'application.
-- **Ne jamais demander, écraser à la publication** : les modifications sont appliquées directement, sans étape de confirmation.
-
-Consultez [Publier ses modifications]({{% relref "publish-changes" %}}) pour le déroulé complet de la publication.
-
-## Affichage des zones
-
-Choisissez la façon dont la zone d'un domaine est présentée :
-
-- **Vue en grille (le plus simple)** : la présentation la plus visuelle et la plus accessible.
-- **Vue en liste (le plus rapide)** : une liste compacte, plus rapide à parcourir.
-- **Liste avec enregistrements (avancé)** : une liste qui expose également les enregistrements DNS sous-jacents, pour les utilisateurs avancés.
-
-## Afficher les types d'enregistrements DNS
-
-Cet interrupteur affiche le type d'enregistrement (A, MX, CNAME, etc.) associé à chaque service. Il s'adresse aux personnes déjà familières du DNS qui souhaitent voir les types techniques derrière les noms de services simplifiés.
-
-## Lettre d'information
-
-L'option permettant de recevoir les nouvelles des prochaines améliorations vous est proposée lors de la [création de votre compte]({{% relref "signup" %}}). Pour modifier ensuite votre abonnement, référez-vous au lien de désinscription présent dans les messages que vous recevez.
-
-## Enregistrement
-
-Une fois vos préférences définies, cliquez sur « Enregistrer les réglages ». Un message de confirmation apparaît et les nouveaux réglages prennent effet immédiatement, y compris un changement de langue si vous en avez effectué un.
-
-## Changer de mot de passe
-
-Une partie dédiée de la page vous permet de changer le mot de passe de votre compte.
-
-## Changer l'adresse électronique de compte
-
-Il n'est pour l'instant pas possible de changer l'adresse électronique de votre compte. Nous vous invitons à nous contacter si vous souhaitez la changer.
-
-## Supprimer son compte
-
-La dernière partie de la page vous permet de supprimer votre compte happyDomain.
-
-Une fois la suppression validée, votre compte ne sera plus accessible et l'ensemble des données vous appartenant sera supprimé peu de temps après, lors d'un nettoyage régulier de la base de données.
-
-À partir du moment où vous supprimez votre compte, vos domaines continueront de répondre selon la dernière mise à jour que vous avez effectué sur happyDomain. La suppression n'affectera pas les données distribuées.

content/pages/signup.en.md

@@ -1,44 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Create an account
-author: nemunaire
-weight: 100
-description: "Sign up for a happyDomain account and validate your email address"
----
-
-Before you can manage your domains, you need a happyDomain account. Creating one takes less than two minutes and only requires an email address and a password.
-
-## Filling in the sign-up form
-
-From the home page, follow the link to register, then fill in the form:
-
-<!-- TODO: screenshot of the sign-up form -->
-
-- **Email address** -- this address identifies you on the platform and is used to contact you for security-related operations (password recovery, important notices). It must contain a valid `@`.
-- **Password** -- choose a strong password (see below).
-- **Password confirmation** -- retype the exact same password to avoid typos.
-- **Keep me informed of future big improvements** -- an optional checkbox to subscribe to the project newsletter. Leave it unchecked if you do not wish to receive these updates.
-
-The interface language you are currently using is automatically recorded with your account, so the emails you receive will be in that language.
-
-{{% notice style="tip" title="Password requirements" icon="key" %}}
-A password is accepted only if it contains at least 8 characters, including at least one uppercase letter, one lowercase letter and one digit. It must also contain a special character, or be at least 11 characters long.
-{{% /notice %}}
-
-Some servers display an anti-bot challenge (captcha) below the form. If so, complete it before submitting.
-
-When everything is filled in correctly, click **Sign up!**.
-
-## Validating your email address
-
-On most servers, an email is sent to the address you provided right after registration. Open your mailbox and click the validation link it contains to activate your account.
-
-<!-- TODO: screenshot of the email validation page -->
-
-If you did not receive the message (check your spam folder first), you can request a new one from the email validation page by entering your address again and clicking **Send again**.
-
-{{% notice style="info" title="Servers without email" icon="circle-info" %}}
-Some happyDomain instances run without an email service. On these servers, no validation message is sent: your account is usable immediately and you can [log in]({{% relref "login" %}}) right away.
-{{% /notice %}}
-
-Once your address is validated, you are redirected to the [login page]({{% relref "login" %}}) where you can sign in with your new credentials.

content/pages/signup.fr.md

@@ -1,43 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Créer un compte
-weight: 100
-description: "Inscrivez-vous sur happyDomain et validez votre adresse e-mail"
----
-
-Avant de pouvoir gérer vos domaines, il vous faut un compte happyDomain. Sa création prend moins de deux minutes et ne demande qu'une adresse e-mail et un mot de passe.
-
-## Remplir le formulaire d'inscription
-
-Depuis la page d'accueil, suivez le lien d'inscription, puis remplissez le formulaire :
-
-<!-- TODO: screenshot of the sign-up form -->
-
-- **Adresse e-mail** : cette adresse vous identifie sur la plateforme et sert à vous contacter pour les opérations liées à la sécurité (récupération de mot de passe, informations importantes). Elle doit contenir un `@` valide.
-- **Mot de passe** : choisissez un mot de passe robuste (voir ci-dessous).
-- **Confirmation du mot de passe** : ressaisissez exactement le même mot de passe afin d'éviter toute faute de frappe.
-- **Tenez-moi informé des prochaines grandes améliorations** : une case à cocher facultative pour vous abonner à la lettre d'information du projet. Laissez-la décochée si vous ne souhaitez pas recevoir ces nouvelles.
-
-La langue de l'interface que vous utilisez est automatiquement enregistrée avec votre compte ; les e-mails que vous recevrez seront ainsi dans cette langue.
-
-{{% notice style="tip" title="Exigences du mot de passe" icon="key" %}}
-Un mot de passe n'est accepté que s'il contient au moins 8 caractères, dont au moins une majuscule, une minuscule et un chiffre. Il doit en outre contenir un caractère spécial, ou bien faire au moins 11 caractères.
-{{% /notice %}}
-
-Certains serveurs affichent une vérification anti-robot (captcha) sous le formulaire. Le cas échéant, complétez-la avant de valider.
-
-Lorsque tout est correctement renseigné, cliquez sur « Inscrivez-vous ! ».
-
-## Valider votre adresse e-mail
-
-Sur la plupart des serveurs, un e-mail est envoyé à l'adresse indiquée juste après l'inscription. Ouvrez votre messagerie et cliquez sur le lien de validation qu'il contient pour activer votre compte.
-
-<!-- TODO: screenshot of the email validation page -->
-
-Si vous n'avez pas reçu le message (vérifiez d'abord votre dossier de courrier indésirable), vous pouvez en demander un nouveau depuis la page de validation : saisissez à nouveau votre adresse, puis cliquez sur « Renvoyer ».
-
-{{% notice style="info" title="Serveurs sans e-mail" icon="circle-info" %}}
-Certaines instances happyDomain fonctionnent sans service de messagerie. Sur ces serveurs, aucun message de validation n'est envoyé : votre compte est utilisable immédiatement et vous pouvez [vous connecter]({{% relref "login" %}}) sans attendre.
-{{% /notice %}}
-
-Une fois votre adresse validée, vous êtes redirigé vers la [page de connexion]({{% relref "login" %}}) où vous pourrez vous identifier avec vos nouveaux identifiants.

content/pages/subdomains/index.en.md

@@ -1,66 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Subdomains
-author: nemunaire
-weight: 1100
-description: "Navigate and manage the subdomains of a domain: the subdomain list, the tree view, and how to create a new subdomain path"
----
-
-A domain is rarely flat: it is made of a root (the apex, written `@`) and a hierarchy of subdomains such as `www`, `mail`, or `blog.staging`. happyDomain presents this hierarchy in a clear, navigable way so you can quickly find and manage each part of your zone.
-
-## The subdomain list
-
-When you open a domain, the left sidebar shows the list of subdomains for the currently selected zone version. Each entry is displayed as a path relative to the domain, with the apex shown as the domain name itself.
-
-![The sidebar listing the subdomains of the domain](happydomain-abstract-zone-records.webp)
-
-The list behaves like a table of contents:
-
-- It is **indented** to reflect the hierarchy: a subdomain is shifted to the right according to its depth in the tree, so `blog.staging` appears nested under `staging`.
-- Clicking an entry **scrolls** the main panel to the corresponding subdomain.
-- As you scroll through the zone, the sidebar **highlights** the subdomain you are currently looking at and follows along automatically.
-
-Intermediate levels that do not carry any service of their own are still shown, so the tree remains coherent and easy to read. (For reverse zones, only the actual entries are listed.)
-
-## Managing a subdomain
-
-Each subdomain in the main panel groups the [services]({{% relref "services" %}}) attached to it. From there you can add, edit, or remove services. Adding a service to an existing subdomain is covered in detail in [Services]({{% relref "services#adding-a-service-to-a-subdomain" %}}).
-
-## Creating a new subdomain path
-
-To create a brand-new subdomain (one that does not exist yet in your zone), use the **Add a subdomain** action at the top of the sidebar.
-
-<!-- TODO: screenshot of the Add a subdomain button -->
-
-### 1. Enter the subdomain name
-
-A dialog opens asking for the new subdomain to create under your domain. Type the name **relative to the domain**: for example, enter `www` to create `www.example.com`, or `blog.staging` to create a nested path in one step.
-
-![The new-subdomain creation dialog](happydomain-modal-new-subdomain.webp)
-
-The name is validated as you type. You only need to provide the part to the left of your domain name; happyDomain appends the domain for you.
-
-{{% notice style="tip" title="Apex and nested paths" icon="sitemap" %}}
-Leave the field empty (or use `@`) to target the domain apex itself. You can also create several levels at once by typing a dotted path such as `a.b.c`: the intermediate levels are created as needed.
-{{% /notice %}}
-
-### 2. Add a first service
-
-Creating a subdomain only makes sense if it carries at least one service, so happyDomain chains directly into the service selector once you confirm the name. Pick the service type and fill in its form exactly as described in [Services]({{% relref "services" %}}).
-
-The new subdomain then appears in the sidebar and in the main panel, with the service you just added.
-
-{{% notice style="info" title="Changes are staged" icon="circle-info" %}}
-Creating a subdomain and its service does not contact your DNS provider immediately. Like every other change, it is staged locally and only sent to your provider when you publish the zone. See the [abstract view]({{% relref "domain-abstract" %}}) for how to review and apply your changes.
-{{% /notice %}}
-
-## Other domain actions
-
-Next to the **Add a subdomain** button, a menu gives access to domain-wide actions, including:
-
-- viewing the [history]({{% relref "domain-history" %}}) of zone versions;
-- consulting the audit log of changes;
-- configuring [checks]({{% relref "checks" %}}) for the domain;
-- running a WHOIS lookup;
-- viewing or re-importing the zone, or uploading a zone file;
-- removing the domain from happyDomain.

content/pages/subdomains/index.fr.md

@@ -1,65 +0,0 @@
----
-date: 2026-06-10T12:00:00+02:00
-title: Sous-domaines
-weight: 1100
-description: "Naviguer et gérer les sous-domaines d'un domaine : la liste des sous-domaines, la vue en arbre et la création d'un nouveau sous-domaine"
----
-
-Un domaine est rarement plat : il se compose d'une racine (l'apex, noté `@`) et d'une hiérarchie de sous-domaines tels que `www`, `mail` ou `blog.staging`. happyDomain présente cette hiérarchie de façon claire et navigable, afin que vous puissiez retrouver et gérer rapidement chaque partie de votre zone.
-
-## La liste des sous-domaines
-
-Lorsque vous ouvrez un domaine, la barre latérale de gauche affiche la liste des sous-domaines pour la version de zone sélectionnée. Chaque entrée est présentée sous la forme d'un chemin relatif au domaine, l'apex étant affiché sous la forme du nom de domaine lui-même.
-
-![La barre latérale listant les sous-domaines du domaine](happydomain-abstract-zone-records.webp)
-
-Cette liste se comporte comme une table des matières :
-
-- elle est **indentée** pour refléter la hiérarchie : un sous-domaine est décalé vers la droite en fonction de sa profondeur dans l'arbre, si bien que `blog.staging` apparaît imbriqué sous `staging` ;
-- cliquer sur une entrée **fait défiler** le panneau principal jusqu'au sous-domaine correspondant ;
-- au fil de votre défilement dans la zone, la barre latérale **met en évidence** le sous-domaine que vous consultez et suit automatiquement votre position.
-
-Les niveaux intermédiaires qui ne portent aucun service propre restent affichés, de sorte que l'arbre demeure cohérent et facile à lire. (Pour les zones inverses, seules les entrées réelles sont listées.)
-
-## Gérer un sous-domaine
-
-Dans le panneau principal, chaque sous-domaine regroupe les [services]({{% relref "services" %}}) qui lui sont rattachés. Vous pouvez y ajouter, modifier ou supprimer des services. L'ajout d'un service à un sous-domaine existant est détaillé dans la page [Services]({{% relref "services#ajouter-un-service-à-un-sous-domaine" %}}).
-
-## Créer un nouveau sous-domaine
-
-Pour créer un sous-domaine entièrement nouveau (qui n'existe pas encore dans votre zone), utilisez l'action **Ajouter un sous-domaine**, en haut de la barre latérale.
-
-<!-- TODO: capture d'écran du bouton « Ajouter un sous-domaine » -->
-
-### 1. Saisir le nom du sous-domaine
-
-Une fenêtre s'ouvre et vous demande le nouveau sous-domaine à créer sous votre domaine. Saisissez le nom **relatif au domaine** : par exemple, entrez `www` pour créer `www.example.com`, ou `blog.staging` pour créer un chemin imbriqué en une seule fois.
-
-![La fenêtre de création d'un sous-domaine](happydomain-modal-new-subdomain.webp)
-
-Le nom est validé au fur et à mesure de la saisie. Vous n'avez besoin de fournir que la partie située à gauche de votre nom de domaine ; happyDomain ajoute le domaine pour vous.
-
-{{% notice style="tip" title="Apex et chemins imbriqués" icon="sitemap" %}}
-Laissez le champ vide (ou utilisez `@`) pour viser la racine du domaine elle-même. Vous pouvez aussi créer plusieurs niveaux d'un coup en saisissant un chemin avec des points, comme `a.b.c` : les niveaux intermédiaires sont créés au besoin.
-{{% /notice %}}
-
-### 2. Ajouter un premier service
-
-Créer un sous-domaine n'a de sens que s'il porte au moins un service : happyDomain enchaîne donc directement avec le sélecteur de services dès que vous confirmez le nom. Choisissez le type de service et remplissez son formulaire exactement comme décrit dans la page [Services]({{% relref "services" %}}).
-
-Le nouveau sous-domaine apparaît alors dans la barre latérale et dans le panneau principal, avec le service que vous venez d'ajouter.
-
-{{% notice style="info" title="Les modifications sont préparées" icon="circle-info" %}}
-Créer un sous-domaine et son service ne contacte pas immédiatement votre hébergeur DNS. Comme toute autre modification, l'opération est préparée localement et n'est envoyée à votre hébergeur qu'au moment de la publication de la zone. Consultez la [vue abstraite]({{% relref "domain-abstract" %}}) pour savoir comment vérifier et appliquer vos modifications.
-{{% /notice %}}
-
-## Autres actions sur le domaine
-
-À côté du bouton **Ajouter un sous-domaine**, un menu donne accès aux actions concernant l'ensemble du domaine, notamment :
-
-- consulter l'[historique]({{% relref "domain-history" %}}) des versions de la zone ;
-- consulter le journal d'audit des modifications ;
-- configurer les [vérifications]({{% relref "checks" %}}) du domaine ;
-- effectuer une recherche WHOIS ;
-- afficher ou réimporter la zone, ou téléverser un fichier de zone ;
-- retirer le domaine de happyDomain.

content/pages/tools-client.en.md

@@ -2,7 +2,7 @@
 date: 2021-01-12T21:38:49+02:00
 author: Frederic
 title: Test a domain
-weight: 1900
+weight: 50
 ---
 
 Please, help us to write this Documentation page

content/pages/tools-client.fr.md

@@ -1,7 +1,7 @@
 ---
 date: 2020-12-10T10:26:54+01:00
 title: Tester un domaine
-weight: 1900
+weight: 50
 ---
 
 Documentation à faire

content/reference/checkers/_index.en.md

@@ -1,36 +0,0 @@
----
-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

@@ -1,36 +0,0 @@
----
-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

@@ -1,49 +0,0 @@
----
-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

@@ -1,49 +0,0 @@
----
-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

@@ -1,51 +0,0 @@
----
-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

@@ -1,51 +0,0 @@
----
-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

@@ -1,35 +0,0 @@
----
-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

@@ -1,35 +0,0 @@
----
-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

@@ -1,42 +0,0 @@
----
-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

@@ -1,42 +0,0 @@
----
-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

@@ -1,48 +0,0 @@
----
-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

@@ -1,48 +0,0 @@
----
-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

@@ -1,42 +0,0 @@
----
-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

@@ -1,42 +0,0 @@
----
-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

@@ -1,48 +0,0 @@
----
-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

@@ -1,48 +0,0 @@
----
-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

@@ -1,69 +0,0 @@
----
-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" >}}.