Environnement de test ou unipersonnel local

Suivez ce guide d’installation si vous souhaitez utiliser happyDomain directement sur votre machine, le plus simplement possible, sans disposer de la gestion d’utilisateurs.

C’est une configuration simple, qui est appropriée pour évaluer happyDomain ou pour l’utiliser sans authentification sur sa propre machine, ou avec une authentification fournie par un reverse proxy.

Vous pouvez le déployer en utiliser Docker ou bien en téléchargeant l’un des exécutables mis à votre disposition. Nous verrons ci-après les deux méthodes.

Via Docker/podman

Si vous être familier de Docker (ou podman), vous pouvez disposer d’happyDomain en quelques secondes avec la ligne de commande suivante :

docker container run -e HAPPYDOMAIN_NO_AUTH=1 -p 8081:8081 happydomain/happydomain

Si vous souhaitez rendre les données persistantes, il faut ajouter un volume :

docker volume create happydns_data
docker container run -v happydns_data:/data -e HAPPYDOMAIN_NO_AUTH=1 -p 8081:8081 happydomain/happydomain

Quelque soit votre choix, rendez-vous ensuite sur http://localhost:8081 pour commencer à utiliser happyDomain.

Via l’exécutable

1. Commencez par télécharger l’exécutable correspondant à votre architecture de processeur sur : https://get.happydomain.org/master/. Les versions darwin sont pour MacOS, tandis que les versions linux sont pour GNU/Linux. Toutes les versions distribuées sont statiques et devraient fonctionner quelque soit votre libc (GNU libc la plupart du temps, musl pour Alpine, …).

2. Rendez le binaire que vous avez téléchargé exécutable : chmod +x happydomain-OS-ARCH.

3. Exécutez le binaire : HAPPYDOMAIN_NO_AUTH=1 ./happydomain-OS-ARCH.

4. Rendez-vous sur http://localhost:8081/ pour commencer à utiliser happyDomain.

Que font ces options ?

L’option HAPPYDOMAIN_NO_AUTH=1 est un paramètre qui indique à happyDomain qu’il ne doit pas attendre d’authentification : les domaines sont partagées entre toutes les connexions qui arrivent. En fait, cela va automatiquement créer un utilisateur par défaut et désactiver toutes les fonctionnalités de connexion, d’enregistrement de compte, …

Peut-on le mettre sur Internet comme ça ?

Non ! Il est primordial que vous n’exposiez pas votre happyDomain sur Internet sans authentification. En effet, tout son contenu serait accessible à n’importe qui, et pourrait prendre possession de votre/vos domaines.

Utilisez systématiquement un reverse-proxy tel que nginx, Apache, HAproxy, Treafik, … en ajoutant une étape de filtrage ou d’authentification basique.

Par exemple, vous pouvez filtrer les IP qui peuvent accéder au service. Voici un exemple de configuration pour nginx, filtrant les IP (directive allow) :

server {
    listen 80;
    listen [::]:80;

    server_name happydomain.example.com;

    location / {
        allow 42.42.42.42;
        deny all;

        proxy_pass	http://localhost:8081;
        proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
    }

}

Vous pouvez aussi ajouter une authentification à base de mot de passe simple.

Avec Docker

happyDomain est sponsorisé par Docker. Vous trouverez notre image officielle sur le Docker Hub.

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.

Versions, étiquettes et architectures supportées

Toutes les étiquettes (tags) sont construites pour amd64, arm64 et arm/v7 et sont basées sur Alpine.

Les étiquettes actuellement disponibles :

• latest : la version la plus récente, correspondant à la branche master de notre dépôt.

Démarrage rapide (conteneur unique)

Pour un test rapide ou un usage personnel, utilisez HAPPYDOMAIN_NO_AUTH=1 pour désactiver la gestion des comptes :

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 :

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 :

docker run \
  -e HAPPYDOMAIN_MAIL_SMTP_HOST=smtp.votreentreprise.com \
  -e HAPPYDOMAIN_MAIL_SMTP_USERNAME=happydomain \
  -e HAPPYDOMAIN_MAIL_SMTP_PASSWORD=secret \
  -v /var/lib/happydomain:/data \
  -p 8081:8081 \
  happydomain/happydomain

Déploiement complet avec tous les vérificateurs

happyDomain intègre tous les vérificateurs (checkers) en natif, mais certains 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.

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:

Comment ça fonctionne

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 pour surveiller les flux e-mail, décommentez la ligne HAPPYDOMAIN_CHECKER_HAPPYDELIVER_ENDPOINT et ajoutez le service correspondant :

  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. Le conteneur inclut l’utilitaire hadmin :

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 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

Configuration

happyDomain respecte la méthodologie 12 factor et permet notamment d’agir sur la configuration de l’application de plusieurs manières.

Par quels moyens configurer happyDomain ?

Il est possible de configurer happyDomain de trois manières différentes : fichier de configuration, environnement, ligne de commande. Toutes les options sont disponibles pour chacun de ces mécanismes.

La précédence, lorsqu’une option est définie par plusieurs mécanismes simultanément, est qu’une option présente dans un fichier de configuration sera écrasé par l’environnement, qui sera écrasée par une option passée sur la ligne de commande.

Configuration par fichier

Au lancement de l’application, le premier fichier de configuration parmi la liste suivante sera utilisé :

• ./happydomain.conf
• $XDG_CONFIG_HOME/happydomain/happydomain.conf
• /etc/happydomain.conf

Seulement le premier fichier existant est pris en compte. Il n’est pas possible d’avoir une partie de ses options dans /etc/happydomain.conf et une autre dans ./happydomain.conf, seul ce dernier fichier de configuration sera pris en compte.

Il est possible de préciser un chemin personnalisé en l’ajoutant comme paramètre supplémentaire à la ligne de commande. Ainsi, pour utiliser le fichier de configuration situé à /etc/happydomain/config, on utilisera :

./happydomain /etc/happydomain/config

Format du fichier de configuration

Une ligne de commentaires commence par #, il n’est pas possible d’avoir des commentaires à la fin d’une ligne, en ajoutant # suivi d’un commentaire.

Placez sur chaque ligne le nom de l’option de configuration et la valeur attendue, séparés par =. Par exemple :

storage-engine=leveldb
leveldb-path=/var/lib/happydomain/db/

Configuration par l’environnement

Au lancement d’happyDomain, toutes les variables commençant par HAPPYDOMAIN_ sont analysées à la recherche d’options de configuration valides.

Vous pouvez réaliser la même chose que dans l’exemple précédent, avec les variables d’environnement suivantes :

HAPPYDOMAIN_STORAGE_ENGINE=leveldb
HAPPYDOMAIN_LEVELDB_PATH=/var/lib/happydomain/db/

Notez que les - sont remplacés par des _ dans les variables d’environnement.

Configuration par la ligne de commande

Enfin, la ligne de commande peut être utilisée pour passer des options, selon le format UNIX usuel.

Pour continuer l’exemple précédent, nous pouvons réaliser la même configuration avec la ligne de commande suivante :

./happydomain -storage-engine leveldb -leveldb-path /var/lib/happydomain/db/

ou encore en utilisant le signe = pour assigner clairement la valeur.

./happydomain -storage-engine=leveldb -leveldb-path=/var/lib/happydomain/db/

Éléments de configuration

La liste exhaustive des éléments configurables peut être listé en appelant happyDomain avec l’option -h ou --help.

Voici la liste des principales options :

Paramètres généraux

bind

Interface (ip, port) à utiliser pour exposer le service happyDomain.

admin-bind

Interface (ip, port ou socket) à utiliser pour exposer l’API d’administration.

default-ns

Adresse et port du serveur résolveur de noms à utiliser par défaut lorsqu’une résolution de nom est nécessaire.

dev

URL vers laquelle toutes les requêtes liées à l’interface graphique seront renvoyées.

externalurl

URL du service, tel qu’il doit apparaître dans les mails et contenus à destination du public.

disable-providers-edit

Interdit toute action sur les fournisseurs de service DNS (ajour/édition/suppression), par exemple pour avoir un mode de démonstration.

Mise en page

custom-head-html

Chaîne de caractères à placer avant la fin de l’en-tête HTML.

custom-body-html

Chaîne de caractères à placer avant la fin du corps HTML.

hide-feedback-button

Cache l’icône permettant de donner son retour d’expérience.

msg-header-text

Ajoute un message personnalisé dans une bannière en haut de toutes les pages.

msg-header-color

Classe de couleur de fond pour la bannière ajoutée en haut de l’application web (par défaut “danger”, pourrait être primary, secondary, info, success, warning, danger, light, dark, ou toute autre classe de couleur bootstrap).

Stockage des données

storage-engine

Permet de choisir le mécanisme de stockage des données parmi tous les mécanismes supportés.

LevelDB (storage-engine=leveldb)

leveldb-path

Chemin vers le dossier contenant la base LevelDB à utiliser.

Paramètres e-mail

Nous employons go-mail comme bibliothèque pour envoyer les mails.

mail-from

Définit le nom et l’adresse de l’expéditeur des mails envoyés par le service.

Notez que sans les options mail-smtp-*, happyDomain utilisera le binaire sendmail pour envoyer les mails. Cela peut être couplé aux paquets msmtp ou ssmtp par exemple, pour définir les paramètres pour tout le système.

mail-smtp-host

IP ou nom d’hôte du serveur SMTP à utiliser.

mail-smtp-port

Port à utiliser sur le serveur distant.

mail-smtp-username

Lorsque de l’authentification est nécessaire sur le serveur distant, nom d’utilisateur à utiliser.

mail-smtp-password

Lorsque de l’authentification est nécessaire sur le serveur distant, mot de passe à utiliser.

Authentification

no-auth

Désactive la notion d’utilisateurs et de contrôle d’accès. Un compte par défaut est utilisé.

disable-embedded-login

Désactive le mécanisme de connexion interne en faveur de l’external-auth ou d’OIDC.

disable-registration

Interdit la création de nouveau compte à travers le formulaire ou l’API (cela ne désactive pas la création de compte lorsque l’on se connecte pour la première fois à partir d’un service d’authentification externe).

external-auth

Base de l’URL du service d’authentification et d’enregistrement à utiliser à la place du système de connexion embarqué.

jwt-secret-key

Clef secrète utilisée pour vérifier les tokens JWT.

Voir aussi paramètres OpenID Connect.

Spécifique aux bureaux d’enregistrement

Certain bureau d’enregistrement nécessitent que les applications tierces s’identifient en plus d’identifier l’utilisateur.

Bind

with-bind-provider

Active BIND en tant que fournisseur DNS (attention, ce paramètre n’est pas adapté à un environnement partagé/cloud car il accède au système de fichiers local).

OVH

Veuillez vous référer à cette documentation afin de générer les identifiants.

ovh-application-key

Application key pour l’API d’OVH

ovh-application-secret

Clef secrète pour l’API d’OVH

OpenID Connect

happyDomain supporte l’authentification d’utilisateurs via le protocole OpenID Connect. Si vous avez un prestataire pour l’authentification (Auth0, Okta, …) ou que vous avez un logiciel dit “Identity Provider” (IdP) tel que Keycloak, Authentik, Authelia, … vous pouvez l’utiliser avec happyDomain et vous passez, éventuellement, du système d’inscription et d’authentification embarqué.

Configuration

Pour activer l’authentification OpenID Connect, vous aurez besoin de définir les options suivantes :

HAPPYDOMAIN_OIDC_PROVIDER_URL=https://auth.example.com/
HAPPYDOMAIN_OIDC_CLIENT_ID=youClientId
HAPPYDOMAIN_OIDC_CLIENT_SECRET=0a1b2c3d4e6f7A8B9C0D

L’option PROVIDER_URL correspond à l’URL de base du service d’authentification. Celui-ci doit mettre à disposition une page de découverte de ses paramètres (accessible à /.well-known/openid-configuration).

Paramétrage du fournisseur OpenID Connect

Vous aurez besoin de créer une application dans votre fournisseur d’authentification, avec les paramètres suivants :

• Provider type: OIDC ou OAuth2
• Grant type: Authorization Code
• Application type: Web ou PWA
• Client type: private
• Scopes: openid, profile, email

Définissez également une adresse de retour autorisée :

• https://yourHappyDomain.example.com/auth/callback

Connexion à un serveur BIND distant

BIND est un serveur DNS récursif et faisant autorité développé par l’Internet Systems Consortium.

Il est possible de l’utiliser avec happyDomain en passant par le Dynamic DNS (RFC 2136).

Cette documentation vous guidera dans la configuration de BIND pour activer le DNS dynamique, puis pour relier ensemble happyDoain et votre serveur BIND.

Configurer BIND pour activer le DNS dynamique

Tout d’abord, vous devez modifier le fichier de configuration principal de BIND (généralement /etc/named.conf ou /etc/bind/named.conf selon votre distribution) pour ajouter un secret qui sera partagé entre happyDomain et BIND pour authentifier les modifications. Ensuite, vous devez indiquer quels domaines seront gérés par happyDomain.

Ajouter un secret partagé

Sous la section principale key de votre configuration, ajoutez la clé suivante :

key "happydomain" {
    algorithm hmac-sha512;
    secret "<SOME_SECRET>";
};

Remplacez <SOME_SECRET> par une chaîne obtenue en utilisant openssl rand -base64 48.

Créer une règle d’autorisation pour happyDomain

En plus de la clé, vous devez spécifier comment la clé peut être utilisée en définissant une ACL et en autorisant les mises à jour à partir de celle-ci.

Ajoutez l’ACL suivante à votre configuration :

acl "happydomain_acl" {
    key happydomain;
};

Autoriser les mises à jour pour chaque zone

Maintenant que vous avez créé une règle permettant à la clé happydomain d’apporter des modifications, vous devez indiquer à quelles zones cette règle s’applique.

Pour chaque zone, vous devez ajouter une déclaration update-policy référencant l’ACL happydomain_acl :

Par exemple, pour une zone existante happydomain.org, ajoutez la déclaration update-policy comme suit :

zone "happydomain.org" {
    type master;
    file "/var/named/happydomain.org.db";
    update-policy {
        grant happydomain_acl name happydomain.org. ANY;
    };
};

La déclaration update-policy est une liste, donc vous pouvez déjà avoir d’autres politiques dans cette liste. Dans ce cas, ajoutez simplement la déclaration grant pour happydomain_acl.

Autoriser les mises à jour pour routes les zones

Si vous gérez de nombreuses zones, il peut être plus pratique de définir l’autorisation par défaut pour toutes les zones. Dans ce cas, vous pouvez utiliser une update-policy globale dans la section options :

options {
    update-policy {
        grant happydomain_acl zonesub ANY;
    };
};

Cela appliquera la update-policy à toutes les zones, permettant à l’ACL happydomain_acl de mettre à jour n’importe quel enregistrement.

Appliquer la configuration

Après avoir modifié le fichier de configuration, rechargez le service BIND pour appliquer les modifications :

rndc reload

Lier happyDomain et BIND

Une fois BIND bien configuré, vous pouvez le lier à happyDomain en utilisant le connecteur Dynamic DNS :.

Remplissez ensuite le formulaire avec l’adresse à laquelle votre serveur BIND est accessible, puis ensuite les différents champs Key avec les informations indiqués dans votre configuration :

• Key Name : correspond au champ id ;
• Key Algorithm : correspond au champ algorithm ;
• Secret Key : correspond au champ secret.

Une fois le fournisseur ajouté, il ne permet pas de lister les domaines existants, mais vous pouvez toujours ajouter manuellement tous vos domaines.

En suivant ces étapes, vous aurez configuré BIND pour fonctionner avec happyDomain en utilisant le DNS dynamique, assurant des mises à jour DNS sécurisées et authentifiées.

Connexion à un knot local

Knot est un serveur DNS faisant autorité développé par l’association cz.nic.

Il est possible de l’utiliser avec happyDomain en passant par le Dynamic DNS (RFC 2136).

Configurer Knot pour permettre le Dynamic DNS

Tout d’abord, il faut éditer le fichier de configuration principal de knot (généralement /etc/knot/knot.conf) afin d’ajouter un secret qui sera partagé entre happyDomain et knot pour authentifier les modifications. Puis il faudra indiquer quels domaines vont être gérés par happyDomain.

Ajout d’un secret partagé

Sous la section principale key de votre configuration, ajoutez la clef suivante :

key:
  [...]
  - id: happydomain
    algorithm: hmac-sha512
    secret: "<SOME_SECRET>"

Remplacez évidemment <SOME_SECRET> par une chaîne de caractères telle qu’obtenue avec openssl rand -base64 48.

Création d’une autorisation pour happyDomain

En plus de la clef, vous devez préciser dans la configuration comment la clef peut être utilisée.

Pour cela, sous la section principale acl, on ajoute :

acl:
  [...]
  - id: acl_happydomain
    key: happydomain
    action: transfer
    action: update

Cela associe la key définie juste avant aux actions transfer et update, respectivement pour permettre de récupérer la zone et pour mettre à jour des enregistrements.

Associer l’autorisation à chaque zone

Maintenant que vous avez créé une règle autorisant la clef happydomain à apporter des modifications, il faut indiquer à quelles zones cette règle s’applique.

Pour chaque zone, il faut ajouter un élément acl référençant la règle acl_happydomain :

Par exemple, pour une zone happydomain.org déjà existante, on ajoutera la ligne acl comme suit :

zone:
  [...]
  - domain: happydomain.org
    acl:
      - acl_happydomain
    [...]

L’élément acl est une liste, vous pouvez donc avoir déjà d’autres éléments acl dans cette liste. Il convient alors d’ajouter simplement l’élément acl_happydomain à la liste déjà existante.

Il faut ajouter cet élément acl pour chaque zone, sauf à utiliser l’astuce suivante.

Associer l’autorisation à toutes les zones

Si vous gérez de nombreuses zones, il peut être plus pratique de définir l’autorisation par défaut pour toutes les zones. Dans ce cas, à la place de la section précédente, on modifiera le modèle default :

template:
  - id: default
    acl:
      - acl_happydomain
  [...]

Le modèle default est appliqué par défaut à toutes les zones. En faisant ainsi, toutes les zones hériteront de la règle acl_happydomain.

Appliquer la configuration

Maintenant que le fichier de configuration a été modifié, indiquez à knotd qu’il doit recharger sa configuration :

knotc reload

Liaison entre happyDomain et knot

Une fois knot bien configuré, vous pouvez le relier à happyDomain en utilisant le connecteur Dynamic DNS :

Remplissez ensuite le formulaire avec l’adresse à laquelle votre serveur knot est accessible, puis ensuite les différents champs Key avec les informations de la section key de knot :

• Key Name : correspond au champ id ;
• Key Algorithm : correspond au champ algorithm ;
• Secret Key : correspond au champ secret.

Une fois le fournisseur ajouté, il ne permet pas de lister les domaines existants, mais vous pouvez tout de même ajouter manuellement tous vos domaines.

Configuration pour l'API OVH

Afin de pouvoir gérer des domaines hébergés par OVH, il est nécessaire de passer par une étape de configuration supplémentaire.

En effet, le principe de fonctionnement de l’authentification à l’API d’OVH se fait en 2 étapes :

1. Tout d’abord il faut enregistrer une application (par exemple happyDomain). Une application dispose d’un identifiant et d’un secret qu’il convient de renseigner en tant que paramètre d’happyDomain.
2. Pour chaque compte OVH que l’on souhaite gérer, l’interface d’happyDomain redirige vers la page d’OVH permettant de créer la Consumer key.

L’application doit être créée à partir d’un compte OVH existant, peu importe qu’il dispose de domaines ou non, il s’agit d’identifier la personne responsable de la mise en œuvre de l’application désignée. L’accès aux données d’un compte, notamment aux domaines qu’ils gèrent, se fait au travers de la Consumer key.

Pour plus d’information, voir cette page : https://docs.ovh.com/gb/en/api/api-rights-delegation/#application-registration

Enregistrer votre instance d’happyDomain auprès d’OVH

1. Rendez-vous sur la page https://api.ovh.com/createApp/.
2. Remplissez le formulaire avec un nom et une description qui refléte le nom et l’usage de votre application, par exemple happyDomain.

Une fois le formulaire validé, vous obtiendrez une clef et un secret. Ces informations sont à indiquer dans la configuration d’happyDomain :

ovh-application-key

Application key pour l’API d’OVH

ovh-application-secret

Clef secrète pour l’API d’OVH

SOA (Start Of Authority)

L’enregistrement Start Of Authority (SOA) est défini par la RFC 1035. Il est obligatoire et unique : un seul SOA figure à l’apex (la racine) de chaque zone DNS. Sa présence indique que le serveur de noms fait autorité sur la zone. Il porte également les paramètres qui régissent la réplication de la zone entre serveurs et sa mise en cache par les résolveurs.

Les champs de l’enregistrement SOA

Le SOA réunit sept valeurs :

Le SOA dans happyDomain

happyDomain ne présente pas le SOA comme un enregistrement à éditer champ par champ. La racine de votre zone est plutôt modélisée par un service Origin, qui regroupe le SOA et les serveurs de noms de la zone (les enregistrements NS). On retrouve donc le SOA à la racine du domaine, aux côtés de la liste des serveurs faisant autorité, et non dans un formulaire distinct.

Le numéro de série est, dans la plupart des cas, géré automatiquement. Lors de la publication de vos modifications, de nombreux hébergeurs DNS gèrent eux-mêmes ce numéro. happyDomain détecte cette capacité, puis relit la zone après publication afin de refléter le numéro de série réellement attribué par l’hébergeur. Vous n’avez normalement pas à le renseigner à la main.

Pour en savoir plus sur la représentation de l’apex et des autres regroupements, consultez le chapitre /fr/reference/services/.

TXT

Un enregistrement TXT (défini par la RFC 1035) associe une ou plusieurs chaînes de texte libre à un nom de votre zone. Il ne porte aucune signification propre. C’est ce qui en fait l’un des types d’enregistrement les plus polyvalents : chaque application est libre de définir sa propre convention pour le texte qu’elle y dépose.

Usages courants

Comme un enregistrement TXT peut contenir n’importe quel texte, il est devenu le support de nombreuses conventions répandues :

• Vérification de propriété ou de site : un fournisseur demande de publier un jeton afin de confirmer que l’on contrôle bien le domaine.
• SPF : déclare quels serveurs sont autorisés à envoyer du courrier pour le domaine.
• DKIM : publie la clé publique servant à signer le courrier sortant.
• DMARC : définit la politique à appliquer lorsqu’une vérification SPF ou DKIM échoue.
• Diverses autres publications de clés ou de politiques propres à différents outils.

Pour la plupart de ces usages, happyDomain propose des services dédiés, de plus haut niveau (SPF, DKIM, DMARC, vérification de site, etc.). Ils sont plus simples et plus sûrs à utiliser qu’un enregistrement TXT brut : ils guident la saisie avec les bons champs et en valident la syntaxe. On les retrouve dans le chapitre /fr/reference/services/, notamment parmi les services liés au courrier électronique. Mieux vaut recourir à ces services dès que l’un d’eux correspond au besoin.

Éditer un enregistrement TXT dans happyDomain

Dans l’éditeur de zone, un enregistrement TXT ordinaire apparaît sous la forme d’un service Enregistrement texte. Il est volontairement minimal : un unique champ contient le contenu textuel de l’enregistrement.

Pour le manipuler :

1. Ouvrez le sous-domaine où l’enregistrement doit se trouver (la racine de la zone, ou un sous-domaine comme www).
2. Ajoutez ou ouvrez le service Enregistrement texte.
3. Saisissez la chaîne de texte complète dans son unique champ.
4. Ajustez la durée de vie (TTL) si besoin, puis publiez vos modifications pour les appliquer.

La valeur saisie est conservée telle quelle. La modifier puis publier met à jour l’enregistrement TXT correspondant sur ce sous-domaine.

E-Mail

Le service E-Mail permet de déclarer les serveurs de courrier responsables d’une zone. Il oriente également vers les services associés, qui régissent la manière dont le courrier est envoyé et authentifié pour le domaine.

Dans happyDomain, ce service porte le nom de E-Mail servers. Son unique rôle consiste à publier les enregistrements MX, ceux qui indiquent au reste d’Internet où livrer les courriels adressés à votre domaine. Tout ce qui protège le courrier sortant, c’est-à-dire prouver qu’un message provient réellement de vous, relève de services dédiés et distincts, décrits plus bas.

Recevoir du courrier : les enregistrements MX

Un enregistrement MX (Mail eXchanger) désigne une machine qui accepte le courrier du domaine. Une zone en publie généralement plusieurs, afin que la livraison continue de fonctionner si l’un des serveurs devient indisponible.

Chaque entrée comporte deux parties :

• La priorité : un nombre qui ordonne les serveurs. Les serveurs émetteurs essaient d’abord le nombre le plus bas ; les valeurs plus élevées ne servent que de secours. Deux enregistrements partageant la même priorité sont considérés comme équivalents et se répartissent la charge.
• Le serveur de courrier : le nom d’hôte de la machine qui reçoit le courrier (par exemple mx1.example.com.). Cet hôte doit lui-même se résoudre vers une adresse ; il ne s’agit pas d’indiquer directement une adresse IP.

Une configuration courante ressemble à ceci :

Ici, mx1 est contacté en premier et mx2 sert de secours.

Envoyer du courrier : authentification et lutte contre l’usurpation

Publier des enregistrements MX suffit pour recevoir du courrier, mais ne dit rien sur les serveurs autorisés à en envoyer en votre nom. Sans cette indication, n’importe qui peut forger des messages au nom de votre domaine. happyDomain propose plusieurs services dédiés, chacun gérant ses propres enregistrements DNS, pour établir cette protection :

• SPF (Sender Policy Framework) : un enregistrement TXT, placé en général à l’apex de la zone, qui énumère les serveurs autorisés à envoyer du courrier pour le domaine. Les destinataires comparent le serveur émetteur à cette liste.
• DKIM (DomainKeys Identified Mail) : publie la partie publique d’une clé de signature dans un enregistrement TXT, sous un sélecteur ._domainkey. Vos serveurs signent les messages sortants, et les destinataires vérifient la signature à l’aide de cette clé publiée.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) : un enregistrement TXT placé sur _dmarc, qui indique aux destinataires comment traiter les messages échouant aux contrôles SPF ou DKIM (les laisser passer, les mettre en quarantaine ou les rejeter), et où envoyer les rapports agrégés.

Deux autres services couvrent la sécurité du transport et la remontée d’informations :

• MTA-STS : déclare que le courrier destiné à votre domaine doit être livré au travers d’une connexion sécurisée (TLS).
• TLS-RPT : recueille les rapports relatifs aux problèmes de livraison TLS rencontrés par les serveurs émetteurs.

Ces services sont indépendants du service E-Mail servers. On peut n’ajouter que ceux dont on a besoin, mais une configuration de courrier complète et bien protégée associe le plus souvent MX, SPF, DKIM et DMARC.

Dans l’éditeur de zone

Pour configurer le courrier d’un sous-domaine dans l’éditeur de zone de happyDomain :

1. On ajoute le service E-Mail servers au sous-domaine, puis on renseigne une ligne par serveur de courrier, avec sa priorité et son nom d’hôte.
2. On ajoute SPF, DKIM et DMARC en tant que services à part entière sur le sous-domaine concerné (SPF et DMARC se placent généralement à l’apex). Chacun présente un formulaire dédié plutôt que le contenu brut de l’enregistrement.

Comme chacune de ces abstractions constitue un service distinct, on les gère séparément, même si elles concourent toutes à rendre le courrier de votre domaine à la fois livrable et digne de confiance. Le chapitre /fr/reference/services/ présente la liste complète des services disponibles.

Expiration du domaine

Le vérificateur Expiration du domaine surveille la date d’expiration de l’enregistrement d’un nom de domaine et vous avertit avant qu’elle ne soit dépassée. Laisser un domaine expirer peut conduire à le perdre au profit d’un autre titulaire : c’est l’une des vérifications les plus importantes au niveau du domaine.

Il s’agit d’un vérificateur de niveau domaine : il concerne l’enregistrement du domaine lui-même, et non ses enregistrements DNS. La date d’expiration est obtenue auprès du registre via une requête WHOIS/RDAP, en même temps que le nom du bureau d’enregistrement.

Ce qui est vérifié

Une seule règle, domain_expiry_check, compare le nombre de jours restant avant l’expiration à deux seuils et rapporte le statut correspondant.

Le message indique toujours le nombre de jours restant avant l’expiration, quel que soit le statut.

Le vérificateur expose également une métrique, domain_expiry_days_remaining, étiquetée avec le bureau d’enregistrement, afin de suivre l’évolution du temps restant.

Options

Dans happyDomain

Activez ce vérificateur depuis la vue Vérifications du domaine ; consultez /fr/pages/checks/ pour savoir comment configurer et planifier les vérifications. Le nom de domaine est renseigné automatiquement.

Pour la situation inverse, surveiller un domaine que vous ne possédez pas encore afin de l’enregistrer dès qu’il se libère, consultez le vérificateur /fr/reference/checkers/domain-availability/ et /fr/pages/domain-availability/. Les vérificateurs de niveau domaine apparentés incluent /fr/reference/checkers/domain-lock/ et /fr/reference/checkers/domain-contact/.

Verrou de transfert du domaine

Le vérificateur Verrou de transfert du domaine vérifie qu’un domaine porte les codes de statut EPP qui le protègent contre les transferts, modifications ou suppressions non autorisés. Un domaine verrouillé (par exemple portant clientTransferProhibited) ne peut pas être transféré sans que le verrou soit d’abord retiré, ce qui constitue une défense essentielle contre le détournement de domaine.

Il s’agit d’un vérificateur de niveau domaine : les codes de statut sont lus auprès du registre via une requête WHOIS/RDAP, et non dans les enregistrements DNS de la zone.

Ce qui est vérifié

Une seule règle, domain_lock_check, compare les codes de statut EPP rapportés par le registre à la liste des statuts que vous exigez.

La comparaison tolère les différences de format : les espaces, tirets et tirets bas sont ignorés et la casse n’a pas d’importance. Ainsi clientTransferProhibited, client-transfer-prohibited et client transfer prohibited sont tous considérés comme équivalents.

Options

Dans happyDomain

Activez ce vérificateur depuis la vue Vérifications du domaine ; consultez /fr/pages/checks/ pour savoir comment configurer et planifier les vérifications. Le nom de domaine est renseigné automatiquement.

Ce vérificateur se combine naturellement avec /fr/reference/checkers/domain-expiry/ et /fr/reference/checkers/domain-contact/ pour garder la maîtrise de l’enregistrement d’un domaine.

Contacts du domaine

Le vérificateur Contacts du domaine compare les informations de contact enregistrées pour un domaine (contacts titulaire, administratif et technique) aux valeurs que vous attendez. Une modification inattendue d’un contact, en particulier le titulaire, peut être un signe précoce de détournement ou d’une erreur administrative.

Il s’agit d’un vérificateur de niveau domaine : les données de contact sont lues auprès du registre via une requête WHOIS/RDAP. De nombreux registres masquent les champs de contact pour des raisons de confidentialité ; ce vérificateur détecte ce masquage et le signale au lieu de le traiter comme une divergence.

Ce qui est vérifié

Une seule règle, domain_contact_check, évalue chaque rôle de contact sélectionné et émet un résultat par rôle.

Les comparaisons sont exactes et insensibles à la casse. Le masquage est détecté à partir de marqueurs courants dans les champs de contact comme redacted, privacy, withheld, not disclosed, data protected, contact privacy et whoisguard.

Options

Dans happyDomain

Activez ce vérificateur depuis la vue Vérifications du domaine ; consultez /fr/pages/checks/ pour savoir comment configurer et planifier les vérifications. Le nom de domaine est renseigné automatiquement.

Ce vérificateur complète /fr/reference/checkers/domain-expiry/ et /fr/reference/checkers/domain-lock/, qui ensemble gardent l’enregistrement d’un domaine sous surveillance.

Disponibilité du domaine

Le vérificateur Disponibilité du domaine surveille un nom de domaine que vous ne possédez pas et vous notifie dès qu’il devient disponible à l’enregistrement. C’est le pendant de /fr/reference/checkers/domain-expiry/ : au lieu de protéger un domaine que vous détenez, il vous permet d’en saisir un dès qu’il se libère.

Il s’agit d’un vérificateur de niveau domaine : l’état d’enregistrement est déterminé auprès du registre via une requête WHOIS/RDAP. Un domaine est considéré comme disponible lorsque le registre indique qu’il n’existe pas.

Ce qui est vérifié

Une seule règle, domain_availability_check, indique si le domaine surveillé est toujours enregistré ou s’il s’est libéré.

Options

Ce vérificateur ne propose aucune option configurable. Le nom de domaine surveillé est fourni automatiquement.

Dans happyDomain

Contrairement aux autres vérificateurs de niveau domaine, Disponibilité du domaine n’est pas planifié sur les domaines que vous gérez. Il est piloté par la liste dédiée de surveillance de disponibilité. Consultez /fr/pages/domain-availability/ pour savoir comment ajouter un domaine à surveiller, et /fr/pages/checks/ pour le fonctionnement général des vérifications.

Expiration des références externes

Le vérificateur Expiration des références externes récupère les informations d’enregistrement des domaines externes auxquels votre zone fait référence. Lorsqu’un enregistrement pointe vers un nom que vous ne possédez pas (un CNAME vers un service tiers, un MX vers un prestataire externe, une délégation NS, etc.), la sûreté de votre zone dépend du maintien de l’enregistrement de ce domaine externe. S’il expire et qu’il est ré-enregistré par quelqu’un d’autre, le pointeur peut être détourné.

Il s’agit d’un vérificateur de niveau zone : il énumère les cibles externes découvertes dans la zone et effectue une requête WHOIS/RDAP par domaine enregistrable distinct. Les cibles partageant le même domaine enregistrable réutilisent une seule requête, et les requêtes s’exécutent avec une concurrence limitée afin qu’une zone volumineuse ne sature pas le registre.

Ce qui est vérifié

Ce vérificateur est avant tout un collecteur. Il rassemble les informations WHOIS par cible (nom enregistrable, date d’expiration, date de création, bureau d’enregistrement, statuts) et les publie pour le vérificateur de références orphelines, où sont émis les verdicts exploitables sur l’expiration, la période de rédemption ou un ré-enregistrement récent.

Sa propre règle, external_whois_collected, ne rapporte que le déroulement de la collecte :

Options

Ce vérificateur ne propose aucune option configurable. La liste des cibles externes est fournie automatiquement à partir des références découvertes dans la zone.

Dans happyDomain

Activez ce vérificateur depuis la vue Vérifications de la zone ; consultez /fr/pages/checks/ pour savoir comment configurer et planifier les vérifications. La découverte des cibles externes est automatique.

Pour l’enregistrement des domaines que vous possédez directement, consultez /fr/reference/checkers/domain-expiry/.

Validation DNSSEC

Le vérificateur DNSSEC audite l’hygiène opérationnelle d’une zone signée. Il ne revalide pas de bout en bout la chaîne de confiance cryptographique (cette tâche est confiée à un vérificateur dédié fondé sur DNSViz) : il se concentre sur les aspects de politique et d’exploitation au quotidien de la signature, à savoir les algorithmes et tailles de clés utilisés, la validité et la fraîcheur des signatures, le mode de déni d’existence (NSEC ou NSEC3) et la cohérence de la vue servie par chaque serveur faisant autorité.

Ce vérificateur s’applique au niveau du domaine : il opère sur l’apex de la zone. À partir d’un résolveur récursif d’amorçage, il découvre les serveurs de noms de l’apex et interroge le DS parent, puis questionne directement chaque serveur faisant autorité.

Ce qu’il vérifie

Le vérificateur évalue les règles suivantes. Plusieurs d’entre elles sont pilotées par les options décrites plus bas.

Chaîne et matériel de clés

Algorithmes et robustesse des clés

Signatures

Déni d’existence (NSEC / NSEC3)

Hygiène des TTL

Options

L’administrateur peut également définir un résolveur d’amorçage (resolver, au format host:port) servant à découvrir les serveurs de noms de l’apex et à interroger le DS parent ; sa valeur par défaut est /etc/resolv.conf.

Dans happyDomain

Activez le vérificateur DNSSEC sur un domaine depuis sa vue Vérifications. Consultez /fr/pages/checks/ pour le déroulé complet de l’ajout, de la planification et de la lecture des vérifications. Pour le passage de relais DS/DNSKEY côté délégation, voyez le vérificateur /fr/reference/checkers/delegation/.

Délégation

Le vérificateur Délégation audite la façon dont une zone est déléguée depuis son parent. Il confronte la zone parente et les serveurs de noms enfants pour confirmer la cohérence du passage de relais : le parent et l’enfant s’accordent sur l’ensemble des NS, les enregistrements de glue sont corrects, la chaîne DNSSEC DS/DNSKEY est alignée, et chaque serveur délégué est joignable et réellement faisant autorité pour la zone.

Ce vérificateur s’applique au niveau du service : il cible un service de délégation (abstract.Delegation) publié sur un sous-domaine, et se configure depuis l’onglet Vérifications de ce service.

Ce qu’il vérifie

Chaque règle émet un code de constat stable, afin que les résultats puissent être appariés de façon déterministe.

Nombre de serveurs de noms et découverte du parent

NS et glue au parent

Passage de relais DNSSEC

Joignabilité et autorité des serveurs enfants

Options

Dans happyDomain

Activez le vérificateur Délégation depuis l’onglet Vérifications d’un service de délégation. Consultez /fr/pages/checks/ pour le déroulé complet. Pour la cohérence entre les serveurs faisant autorité de l’apex lui-même (plutôt que le passage de relais parent/enfant), voyez /fr/reference/checkers/authoritative-consistency/ ; pour l’hygiène DNSSEC de la zone signée, voyez /fr/reference/checkers/dnssec/.

Cohérence des serveurs faisant autorité

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 /fr/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.

Options

Dans happyDomain

Activez le vérificateur Cohérence des serveurs faisant autorité depuis l’onglet Vérifications d’un service d’origine. Consultez /fr/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 à /fr/reference/checkers/resolver-propagation/.

Restrictions des serveurs de noms

Le vérificateur Restrictions des serveurs de noms vérifie que les serveurs faisant autorité d’une zone sont correctement verrouillés. Pour chaque serveur de noms déclaré, il résout le nom d’hôte puis lance une série de sondes DNS contre chaque adresse IPv4 et IPv6 renvoyée (les cibles IPv6 sont ignorées sans erreur lorsque l’hôte n’a pas de connectivité IPv6). L’objectif est de détecter les erreurs de configuration courantes qui divulguent des données ou transforment un serveur de noms en vecteur d’abus : transferts de zone ouverts, récursion ouverte et réponses ANY non bornées.

Ce vérificateur s’applique au niveau du service : il cible un service d’origine ou d’origine NS-seule (abstract.Origin, abstract.NSOnlyOrigin) et se configure depuis l’onglet Vérifications de ce service.

Ce qu’il vérifie

Chaque règle émet un constat par adresse de serveur de noms sondée, avec un code stable.

Options

Ce vérificateur n’expose aucune option réglable : il exécute un ensemble fixe de sondes contre chaque adresse de serveur de noms résolue.

Dans happyDomain

Activez le vérificateur Restrictions des serveurs de noms depuis l’onglet Vérifications d’un service d’origine. Consultez /fr/pages/checks/ pour le déroulé complet. Pour la santé et l’accord plus larges de ces mêmes serveurs faisant autorité, voyez /fr/reference/checkers/authoritative-consistency/.

Propagation chez les résolveurs

Le vérificateur Propagation chez les résolveurs mesure la façon dont une zone est vue depuis l’extérieur, à travers l’internet public. Il sonde un catalogue choisi de résolveurs récursifs publics (Cloudflare, Google, Quad9, OpenDNS, Yandex, FAI régionaux et autres) sur plusieurs transports (UDP, TCP, DoT, DoH) et depuis plusieurs régions, puis compare leurs réponses entre elles et avec celles des serveurs faisant autorité de la zone. Cela révèle les retards de propagation, les divergences régionales, les écarts de numéro de série SOA, les caches périmés, les échecs de validation DNSSEC, les incohérences SERVFAIL/NXDOMAIN et le filtrage par les résolveurs.

Ce vérificateur s’applique au niveau du service : il cible un service d’origine ou d’origine NS-seule (abstract.Origin, abstract.NSOnlyOrigin) et se configure depuis l’onglet Vérifications de ce service.

Ce qu’il vérifie

Options

Dans happyDomain

Activez le vérificateur Propagation chez les résolveurs depuis l’onglet Vérifications d’un service d’origine. Consultez /fr/pages/checks/ pour le déroulé complet. Ce vérificateur est le pendant tourné vers l’extérieur de /fr/reference/checkers/authoritative-consistency/, qui examine directement les serveurs faisant autorité ; exécuter les deux donne la vue depuis l’origine et depuis les résolveurs qui l’interrogent.

Zone inverse

Le vérificateur Zone inverse inspecte les enregistrements PTR d’une zone DNS inverse (in-addr.arpa ou ip6.arpa) et valide qu’ils sont bien formés et cohérents avec le DNS direct. Il vérifie le Forward-Confirmed Reverse DNS (FCrDNS), s’assure que les cibles se résolvent et sont des noms d’hôtes syntaxiquement valides, signale les noms génériques ou auto-générés et les TTL trop courts, et détecte les violations de plusieurs PTR par IP (RFC 1912 §2.1). Un DNS inverse correct compte en pratique : les serveurs de courrier et les points d’accès SSH rejettent ou dégradent régulièrement les connexions provenant d’IP sans FCrDNS valide.

Ce vérificateur s’applique au niveau de la zone : il opère sur le contenu complet d’une zone inverse (il s’applique au domaine et lit l’intégralité de la zone).

Ce qu’il vérifie

Options

Dans happyDomain

Activez le vérificateur Zone inverse sur un domaine inverse (in-addr.arpa / ip6.arpa) depuis sa vue Vérifications. Consultez /fr/pages/checks/ pour le déroulé complet.

Enregistrements PTR

Le vérificateur PTR / DNS inverse vérifie qu’une adresse IP dispose d’un enregistrement de DNS inverse correct et exploitable. Un PTR associe une IP à un nom d’hôte ; les serveurs de messagerie, les démons SSH et de nombreux outils de journalisation s’appuient dessus, et un PTR absent ou incohérent est l’une des causes les plus fréquentes de rejet du courrier sortant.

Il s’agit d’un vérificateur de niveau service : il s’exécute sur un service PTR et se configure depuis l’onglet Vérifications de ce service. Il localise la zone inverse (sous in-addr.arpa ou ip6.arpa), interroge les serveurs faisant autorité et inspecte ce qu’ils servent réellement, aussi bien pour les adresses IPv4 qu’IPv6.

Ce qui est vérifié

Le vérificateur enchaîne une série de règles, de la cohérence structurelle au succès de la requête, puis à l’hygiène de la cible et au Forward-Confirmed Reverse DNS (FCrDNS).

Les règles ptr.target_resolves et ptr.fcrdns_match sont critiques par défaut, mais passent en avertissement lorsque l’option Exiger le Forward-Confirmed Reverse DNS est désactivée.

Options

Dans happyDomain

Ajoutez le service PTR au sous-domaine portant l’enregistrement inverse, puis activez ce vérificateur depuis l’onglet Vérifications de ce service. Consultez /fr/pages/checks/ pour configurer et planifier les vérifications. La zone inverse, l’enregistrement PTR et la cible déclarée sont renseignés automatiquement à partir du service.

Pour le versant direct de la résolution des alias et des noms d’hôte, voyez le vérificateur /fr/reference/checkers/alias/.

Chaîne d'alias

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.

Options

Dans happyDomain

Ajoutez le service CNAME au sous-domaine, puis activez ce vérificateur depuis l’onglet Vérifications de ce service. Consultez /fr/pages/checks/ pour configurer et planifier les vérifications. Le domaine parent et le sous-domaine sont renseignés automatiquement.

Vérificateurs apparentés : /fr/reference/checkers/dangling/ surveille les cibles d’alias devenues non enregistrées ou NXDOMAIN, et /fr/reference/checkers/ptr/ couvre le versant DNS inverse.

Enregistrements orphelins

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 :

Options

Dans happyDomain

Activez ce vérificateur sur le domaine depuis la vue /fr/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 : /fr/reference/checkers/alias/ valide la structure des chaînes d’alias individuelles, et /fr/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.

CAA

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 /fr/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.

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 :

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 /fr/pages/checks/ pour configurer et planifier les vérifications. Pour que la comparaison produise un verdict, un vérificateur de sonde TLS comme /fr/reference/checkers/dane/ (ou le checker-tls autonome) doit avoir observé des certificats sur la cible.

DANE / TLSA

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é

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.

Options

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 /fr/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é : /fr/reference/checkers/caa/ vérifie, sur les mêmes certificats, que l’autorité émettrice était bien autorisée par la politique CAA du domaine.

Posture TLS

Le vérificateur TLS (nom interne « TLS ») évalue la posture de sécurité du transport de chaque point de terminaison TLS exposé par un domaine. Il ne scanne pas de ports lui-même : il consomme des entrées de découverte de type tls.endpoint.v1 publiées par d’autres vérificateurs de service (XMPP, SRV, CalDAV, CardDAV, SMTP, etc.). Pour chaque point de terminaison découvert, il effectue une véritable connexion TCP, une bascule STARTTLS spécifique au protocole le cas échéant, puis une poignée de main TLS complète, et il rapporte une posture par point de terminaison.

Portée : niveau domaine. Le vérificateur s’exécute sur l’ensemble du domaine et intègre les points de terminaison annoncés par les autres vérificateurs de service. Un point de terminaison n’est donc sondé que si un vérificateur de service (par exemple /fr/reference/checkers/smtp/) l’a publié.

Ce qu’il vérifie

Les bascules STARTTLS sont prises en charge pour SMTP/submission, IMAP, POP3 et XMPP (c2s et s2s). Lorsqu’un vérificateur de service marque un point de terminaison comme exigeant STARTTLS, l’absence de bascule est rapportée comme critique ; sinon, elle est considérée comme opportuniste et rapportée comme avertissement.

Options

La liste des entrées de découverte est remplie automatiquement à partir de ce que les autres vérificateurs publient et n’est pas modifiable par l’utilisateur.

Dans happyDomain

Le vérificateur TLS est une vérification de niveau domaine : activez-le depuis la vue des vérifications du domaine. Comme il travaille sur des points de terminaison découverts par d’autres vérificateurs, il s’associe naturellement aux vérificateurs de service qui publient des points de terminaison TLS, comme /fr/reference/checkers/smtp/.

Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir /fr/pages/checks/.

HTTP / HTTPS

Le vérificateur HTTP / HTTPS sonde le serveur web déclaré par un service « Serveur » en HTTP simple (port 80) et en HTTPS (port 443), puis évalue une série de règles indépendantes sur les réponses : accessibilité, chaîne de redirections HTTP vers HTTPS et ensemble moderne des en-têtes de sécurité HTTP (HSTS, CSP, options de cadre, isolation inter-origines, etc.), ainsi que l’hygiène des cookies.

Portée : niveau service. Il s’attache aux services de type abstract.Server (un sous-domaine publiant des enregistrements A/AAAA) et se configure depuis l’onglet Vérifications de ce service.

L’analyse approfondie du TLS et des certificats est volontairement déléguée au vérificateur /fr/reference/checkers/tls/ ; ce vérificateur ne s’appuie sur TLS que comme transport.

Ce qu’il vérifie

Options

Dans happyDomain

C’est un vérificateur de niveau service : configurez-le depuis l’onglet Vérifications du service « Serveur » sur le sous-domaine concerné. Pour la posture détaillée des certificats, ajoutez aussi le vérificateur /fr/reference/checkers/tls/. Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir /fr/pages/checks/.

Ping

Le vérificateur Ping (ICMP) mesure l’accessibilité réseau de base des adresses derrière un service. Il envoie un petit nombre de requêtes echo ICMP à chaque adresse A/AAAA et rapporte si la cible a répondu, son temps d’aller-retour moyen (RTT), le taux de perte de paquets observé, et si au moins une adresse IPv6 a répondu.

Portée : niveau service. Il s’attache aux services de type abstract.Server (un sous-domaine publiant des enregistrements A/AAAA) et se configure depuis l’onglet Vérifications de ce service.

Ce qu’il vérifie

Options

Dans happyDomain

C’est un vérificateur de niveau service : configurez-le depuis l’onglet Vérifications du service « Serveur » sur le sous-domaine concerné. Son intervalle par défaut court le rend adapté à une surveillance d’accessibilité légère et fréquente. Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir /fr/pages/checks/.

SMTP

Le vérificateur SMTP entrant (posture MX) examine le côté entrant du service de messagerie d’un domaine. Pour chaque cible MX de la zone, il effectue les sondes en direct qu’un opérateur exécuterait avec swaks ou telnet … 25 : connexion TCP, bannière ESMTP et EHLO, négociation STARTTLS, sondes de transaction (expéditeur nul, postmaster, relais ouvert), DNS inverse / FCrDNS, inventaire des extensions et couverture IPv4/IPv6. Le résultat est un rapport HTML exploitable.

Portée : niveau service. Il s’attache aux services de type svcs.MXs (l’ensemble des enregistrements MX) et se configure depuis l’onglet Vérifications de ce service.

La sonde répond à la question « ce domaine peut-il recevoir le courrier correctement ? ». Elle ne teste pas la délivrabilité sortante (alignement SPF/DKIM/DMARC, score anti-spam, statut de liste noire), ce qui est le rôle du vérificateur /fr/reference/checkers/happydeliver/. Les sondes de transaction s’arrêtent toujours à RCPT et émettent RSET : aucun DATA n’est envoyé, donc aucun message n’est délivré.

Ce qu’il vérifie

La posture des certificats elle-même est hors de portée ici : chaque cible MX est publiée comme entrée de découverte tls.endpoint.v1 (STARTTLS opportuniste), et le vérificateur /fr/reference/checkers/tls/ effectue l’analyse des certificats sur la même connexion. Ses constats sont réintégrés dans la règle smtp.tls_quality et dans le rapport HTML.

Options

Dans happyDomain

C’est un vérificateur de niveau service : configurez-le depuis l’onglet Vérifications du service « Serveurs e-mail » (MX). Pour confirmer que le courrier que votre domaine envoie arrive en boîte de réception, associez-le au vérificateur /fr/reference/checkers/happydeliver/. Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir /fr/pages/checks/.

Délivrabilité sortante (happyDeliver)

Le vérificateur de délivrabilité sortante (nommé Outbound deliverability (via happyDeliver) dans happyDomain) mesure le sort que connaîtrait un message envoyé depuis votre domaine sur le chemin de la boîte de réception du destinataire. Au lieu d’examiner les enregistrements DNS isolément, il pilote une instance externe happyDeliver pour réaliser un test de bout en bout.

Ce vérificateur s’applique au niveau service : il est rattaché à un service (typiquement la configuration de messagerie d’un sous-domaine) et a besoin d’identifiants SMTP pour envoyer le message de test en votre nom.

Fonctionnement

À chaque exécution, le vérificateur :

1. Alloue une adresse de réception neuve sur l’instance happyDeliver configurée.
2. Envoie un véritable courriel de test depuis le domaine testé vers cette adresse, en utilisant le serveur de soumission SMTP et les identifiants que vous fournissez.
3. Interroge happyDeliver jusqu’à ce que le message ait été reçu et analysé.
4. Conserve le rapport de happyDeliver et expose le score de chaque section sous forme de métrique.

happyDeliver note le message sur plusieurs sections (DNS, authentification, filtres anti-spam, listes noires, en-têtes, contenu) et calcule un score global. Le vérificateur transforme chaque section en une règle.

Ce qui est vérifié

Chaque règle de section compare le score happyDeliver de cette section à un minimum configurable. La vérification est Critique lorsque le score passe sous le minimum, sinon OK.

Une règle distincte, happydeliver.lifecycle, rapporte le déroulement de l’exécution elle-même : OK lorsque le message a été analysé, Critique lorsque l’adresse de test n’a pu être allouée, que le message n’a pu être envoyé, ou que happyDeliver a renvoyé une erreur d’attente, de récupération ou d’analyse, et Avertissement lorsque le message n’a pas été analysé avant l’expiration du délai.

Chaque minimum de section se règle via son option de règle min_score_<section> dans l’interface de happyDomain.

Options

Envoi (par domaine)

Contenu du message (par domaine)

Temporisation (par domaine)

Instance (admin, redéfinissable par domaine)

Dans happyDomain

Activez ce vérificateur depuis l’onglet Vérifications du service et fournissez les détails de soumission SMTP afin que happyDomain puisse envoyer le message de test. Voir /fr/pages/checks/ pour le fonctionnement général de la planification et de la lecture des vérifications.

La délivrabilité dépendant fortement de votre posture anti-usurpation, associez ce vérificateur à une configuration /fr/reference/services/email/ bien réglée (SPF, DKIM et DMARC). Pour la partie DNSSEC de la chaîne de confiance de votre domaine, voir /fr/reference/checkers/dnssec/.

Autoconfiguration de la messagerie

Le vérificateur d’autoconfiguration de la messagerie s’assure que les clients de messagerie peuvent découvrir automatiquement comment se connecter à vos serveurs de courriel. Lorsque l’autoconfiguration est publiée correctement, l’utilisateur saisit seulement son adresse et son mot de passe, et son client (Thunderbird, Outlook, applications mobiles) trouve de lui-même les bons hôtes IMAP/POP et SMTP, les ports et les réglages de sécurité.

Ce vérificateur s’applique au niveau service : il concerne les services d’autoconfiguration de messagerie et de RFC 6186 d’un domaine. À chaque exécution, il sonde les mécanismes de découverte utilisés par les clients réels :

• Autoconfig Thunderbird (brouillon Bucksch) : https://autoconfig.<domaine>/mail/config-v1.1.xml comme URL primaire, avec le repli sur l’apex https://<domaine>/.well-known/autoconfig/..., une variante optionnelle en HTTP simple, le repli sur l’ISPDB de Mozilla et les replis via le parent MX.
• Autodiscover Microsoft (POX) : https://autodiscover.<domaine>/autodiscover/autodiscover.xml.
• Enregistrements SRV de la RFC 6186 : _imaps, _imap, _pop3s, _pop3, _submissions, _submission, _autodiscover.
• Résolution MX, pour le contexte et la découverte fondée sur les MX.

Il analyse chaque réponse, recoupe les serveurs annoncés par les différentes sources et produit un rapport HTML accompagné d’extraits de correction prêts à coller pour les défauts les plus courants.

Ce qui est vérifié

En cas d’échec, la section « Fix this first » du rapport fournit des extraits prêts à copier : un exemple de config-v1.1.xml et ses URL canoniques lorsque rien n’est publié, une incitation à ajouter le sous-domaine autoconfig. lorsque seul .well-known répond, une redirection vers HTTPS, un rappel sur la couverture du certificat, un aide-mémoire de ports pour les serveurs en clair (SSL 993/465, STARTTLS 143/587) et un extrait de zone SRV prêt à coller.

Options

Par utilisateur

Admin

Dans happyDomain

Activez ce vérificateur depuis l’onglet Vérifications du service d’autoconfiguration de messagerie concerné. Voir /fr/pages/checks/ pour la planification et la lecture des vérifications.

Ce vérificateur est le compagnon naturel d’une configuration de messagerie complète : voir /fr/reference/services/email/ pour les services MX, SPF, DKIM et DMARC qui régissent la remise et l’authentification du courrier.

Clés de messagerie (DKIM / OpenPGP)

Le vérificateur de clés de messagerie (nommé OPENPGPKEY & SMIMEA dans happyDomain) valide les clés cryptographiques qu’un domaine publie dans le DNS afin que ses correspondants puissent chiffrer le courrier destiné à ses utilisateurs. Il couvre deux types d’enregistrements de style DANE :

• OPENPGPKEY (RFC 7929) : la clé publique OpenPGP d’un utilisateur, publiée sous un nom haché du propriétaire, sous ._openpgpkey.<zone>.
• SMIMEA (RFC 8162) : le certificat S/MIME d’un utilisateur, publié sous un nom haché du propriétaire, sous ._smimecert.<zone>.

Ce vérificateur s’applique au niveau service : il concerne les services OpenPGP et S/MIME d’un sous-domaine, exécute une suite de tests complète, puis produit un rapport HTML dont le bloc supérieur pointe vers la correction des défauts les plus courants.

Ce qui est vérifié

DNS et DNSSEC

OpenPGP (OPENPGPKEY)

S/MIME (SMIMEA)

Options

L’origine de la zone, le sous-domaine, le service et le type de service sont préremplis par happyDomain.

Dans happyDomain

Activez ce vérificateur depuis l’onglet Vérifications du service OpenPGP ou S/MIME concerné. Voir /fr/pages/checks/ pour le fonctionnement général.

Ces enregistrements partagent leur modèle de sécurité avec le DNSSEC : pour confirmer que la chaîne de signature de votre zone est elle-même saine, voir /fr/reference/checkers/dnssec/. Pour la configuration de messagerie environnante, voir /fr/reference/services/email/.

CalDAV / CardDAV

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.

Ce qui est vérifié

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.

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 /fr/pages/checks/ pour le fonctionnement complet, et /fr/reference/checkers/tls/ pour la posture des certificats de ces mêmes points d’accès.

LDAP

Le vérificateur LDAP sonde le déploiement LDAP d’un domaine de bout en bout. À partir de la découverte SRV (_ldap._tcp, _ldaps._tcp), il teste l’accessibilité de chaque point d’accès, confirme qu’un canal chiffré est disponible (StartTLS selon la RFC 2830 ou TLS implicite sur le port 636), introspecte le RootDSE, recherche une divulgation d’information anonyme, vérifie que l’annuaire refuse les binds en clair et, lorsque des identifiants sont fournis, effectue un bind authentifié sur TLS avec un test de lecture facultatif sur un DN de base.

Il s’agit d’un vérificateur de niveau service : il cible un service LDAP (abstract.LDAP) publié sur un sous-domaine et se configure depuis l’onglet Vérifications de ce service. Pour chaque transport, il sonde _ldap._tcp (repli sur le port 389) et _ldaps._tcp (repli sur le port 636), en testant chaque adresse A/AAAA résolue par famille d’adresses.

Ce qui est vérifié

Le rapport HTML commence par les défaillances les plus courantes et inclut une remédiation propre à chaque serveur (olcSecurity sous OpenLDAP, require_tls sous 389-ds…) : aucun point d’accès chiffré accessible, StartTLS absent sur 389, une poignée de main StartTLS qui échoue, un bind en clair accepté sur 389, une poignée de main LDAPS qui échoue, une recherche anonyme exposant le DIT, un SASL limité à PLAIN/LOGIN, un LDAPv2 résiduel, et des identifiants de bind rejetés.

Options

Dans happyDomain

Activez le vérificateur LDAP depuis l’onglet Vérifications d’un service LDAP. Le domaine est renseigné automatiquement ; fournissez un bind DN et un mot de passe uniquement si vous souhaitez exécuter les tests de bind authentifié et de lecture du DN de base. Consultez /fr/pages/checks/ pour le fonctionnement complet, et /fr/reference/checkers/tls/ pour la posture des certificats de ces mêmes points d’accès.

Kerberos

Le vérificateur Kerberos audite un royaume Kerberos à partir de ses enregistrements DNS. À partir du nom du royaume (dérivé en majuscules depuis le domaine) et des enregistrements SRV regroupés sous le service Kerberos, il exécute une série de sondes anonymes et, lorsque des identifiants sont fournis, un aller-retour authentifié facultatif, ce qui donne une vue combinée de la disponibilité et de la posture de sécurité du royaume.

Il s’agit d’un vérificateur de niveau service : il cible un service Kerberos (abstract.Kerberos) publié sur un sous-domaine et se configure depuis l’onglet Vérifications de ce service. Il inspecte la disposition SRV (_kerberos._tcp, _kerberos._udp, _kerberos-master._tcp, _kerberos-adm._tcp, _kpasswd._tcp, _kpasswd._udp), résout en avant chaque cible SRV (A + AAAA), teste l’accessibilité TCP de chaque hôte KDC/kadmin/kpasswd et l’accessibilité UDP du KDC via un véritable AS-REQ. La sonde AS-REQ anonyme confirme le royaume, lit les enctypes pris en charge depuis ETYPE-INFO2, détecte un indice PKINIT (PA-PK-AS-REQ) et mesure la dérive d’horloge.

Ce qui est vérifié

Le rapport HTML met en avant les erreurs de configuration les plus courantes avec une piste de remédiation directe : absence d’enregistrements SRV (publier _kerberos._tcp.REALM. SRV …), une cible SRV sans A/AAAA, le port 88 inaccessible (ouvrir TCP+UDP 88), une dérive d’horloge au-dessus du maximum (lancer ntpd/chrony), des royaumes limités aux enctypes faibles (passer à aes256-cts-hmac-sha1-96), un mauvais royaume dans la réponse, et l’exposition à l’AS-REP roasting (activer requires_preauth).

Options

Dans happyDomain

Activez le vérificateur Kerberos depuis l’onglet Vérifications d’un service Kerberos. Le domaine du royaume est renseigné automatiquement ; fournissez un principal et un mot de passe uniquement si vous souhaitez exécuter l’aller-retour authentifié TGT/TGS. Consultez /fr/pages/checks/ pour le fonctionnement complet.

SIP

Le vérificateur SIP sonde le déploiement SIP/VoIP d’un domaine à partir de ses enregistrements DNS, en suivant la résolution de la RFC 3263 : NAPTR → SRV (_sip._udp, _sip._tcp, _sips._tcp) → A/AAAA. Il teste l’accessibilité de chaque cible:port résolue en UDP, TCP et TLS, puis envoie un ping SIP OPTIONS brut et inspecte la réponse (ligne de statut, Server/User-Agent, méthodes Allow annoncées, temps d’aller-retour).

Il s’agit d’un vérificateur de niveau service : il cible un service SIP (abstract.SIP) publié sur un sous-domaine et se configure depuis l’onglet Vérifications de ce service. Lorsqu’aucun enregistrement SRV n’est publié, le vérificateur se rabat sur <domaine>:5060 / <domaine>:5061, avec un marqueur d’information visible dans le rapport.

Ce qui est vérifié

Le vérificateur effectue, dans l’ordre : la recherche NAPTR (SIP+D2U, SIP+D2T, SIPS+D2T), la recherche SRV pour les trois transports (avec le repli 5060/5061), la résolution A/AAAA de chaque cible SRV, la connexion TCP / l’envoi UDP / la poignée de main TLS, et la requête SIP OPTIONS avec son statut, ses en-têtes et son Allow analysés.

Options

Dans happyDomain

Activez le vérificateur SIP depuis l’onglet Vérifications d’un service SIP. Le domaine est renseigné automatiquement. Consultez /fr/pages/checks/ pour le fonctionnement complet, et /fr/reference/checkers/tls/ pour la posture des certificats des points d’accès _sips._tcp.

SSH

Le vérificateur SSH produit un audit de sécurité complet du service SSH exposé par un service « Serveur ». Il se connecte aux ports SSH annoncés sur chaque adresse A/AAAA et rapporte l’accessibilité, les correspondances bannière/CVE, la posture complète des algorithmes (échange de clés, clé d’hôte, chiffrement, MAC, compression), les clés d’hôte observées, l’alignement des empreintes SSHFP et les méthodes d’authentification exposées par le serveur. Les résultats sont présentés dans un rapport HTML orienté correction rapide.

Portée : niveau service. Il s’attache aux services de type abstract.Server (un sous-domaine publiant des enregistrements A/AAAA et éventuellement SSHFP) et se configure depuis l’onglet Vérifications de ce service.

Ce qu’il vérifie

La correspondance CVE couvre notamment regreSSHion (CVE-2024-6387), la RCE PKCS#11 de ssh-agent (CVE-2023-38408), Terrapin (CVE-2023-48795) et plusieurs anciennes failles d’énumération d’utilisateurs et d’injection de commandes.

Options

Dans happyDomain

C’est un vérificateur de niveau service : configurez-le depuis l’onglet Vérifications du service « Serveur » sur le sous-domaine concerné. Ses règles SSHFP recoupent les enregistrements SSHFP publiés dans votre zone ; garder ces enregistrements synchronisés avec les clés d’hôte du serveur améliore le résultat. Pour le fonctionnement général de la configuration et de la lecture des vérifications, voir /fr/pages/checks/.

XMPP

Le vérificateur XMPP sonde de bout en bout le déploiement XMPP (Jabber) d’un domaine, à la manière de xmpp.net : il découvre les enregistrements SRV pertinents, ouvre un flux vers chaque point d’accès, négocie STARTTLS, inspecte les mécanismes SASL proposés et confirme que la fédération de serveur à serveur peut s’authentifier.

Il s’agit d’un vérificateur de niveau service. Il s’applique aux services de type XMPP et se configure depuis l’onglet Vérifications de ce service. Il sonde les quatre noms de service standard (_xmpp-client._tcp, _xmpp-server._tcp, _xmpps-client._tcp, _xmpps-server._tcp), l’ancien _jabber._tcp, et se rabat sur <domaine>:5222 / :5269 lorsqu’aucun enregistrement SRV n’est publié.

Ce qui est vérifié

La sonde couvre aussi l’accessibilité TCP des cibles A/AAAA, l’analyse des fonctionnalités de flux et la couverture IPv4/IPv6, exposées au travers des règles ci-dessus et du rapport HTML.

Options

Dans happyDomain

Activez ce vérificateur depuis l’onglet Vérifications d’un service XMPP ; consultez /fr/pages/checks/ pour savoir comment configurer et planifier les vérifications. Le domaine est renseigné automatiquement depuis le service. Pour le volet certificat de ces mêmes points d’accès, associez-le au vérificateur /fr/reference/checkers/tls/.

Fédération Matrix

Le vérificateur Fédération Matrix vérifie qu’un serveur Matrix (homeserver) est correctement configuré pour fédérer avec le reste du réseau Matrix. Il délègue le sondage proprement dit à une instance du Matrix Federation Tester, stocke le rapport complet sous forme d’observation, et produit un résumé HTML détaillé couvrant les connexions, les certificats, la délégation well-known et la résolution DNS/SRV.

Il s’agit d’un vérificateur de niveau service. Il s’applique aux services de type Matrix (messagerie instantanée) et se configure depuis l’onglet Vérifications de ce service.

Ce qui est vérifié

Options

Une option supplémentaire de niveau administrateur, federationTesterServer, définit le modèle d’URL de l’instance du Federation Tester à interroger. Elle est configurée par l’opérateur happyDomain, et non par vérification, et vaut par défaut https://federationtester.matrix.org/api/report?server_name=%s.

Dans happyDomain

Activez ce vérificateur depuis l’onglet Vérifications d’un service Matrix ; consultez /fr/pages/checks/ pour savoir comment configurer et planifier les vérifications. Le domaine Matrix est renseigné automatiquement depuis le service.

STUN / TURN

Le vérificateur STUN / TURN sonde de bout en bout les serveurs STUN et TURN. STUN et TURN sont les serveurs de traversée de NAT sur lesquels reposent les applications temps réel (WebRTC, voix et vidéo) pour établir un flux média pair à pair : STUN permet à un hôte de découvrir son adresse réflexive publique, tandis que TURN relaie le média lorsqu’aucun chemin direct ne peut être ouvert.

Il s’agit d’un vérificateur de niveau service. Il effectue la découverte SRV (ou utilise une URI explicite), contrôle l’accessibilité TCP/UDP et la poignée de main TLS/DTLS, émet une requête de binding STUN, vérifie que le serveur TURN exige une authentification, réalise un Allocate TURN authentifié, puis éprouve le chemin de relais par un aller-retour CreatePermission + Send.

Ce qui est vérifié

Options

Dans happyDomain

Activez ce vérificateur depuis l’onglet Vérifications du service concerné ; consultez /fr/pages/checks/ pour savoir comment configurer et planifier les vérifications. La zone est renseignée automatiquement ; fournissez une URI de serveur et des identifiants TURN selon les besoins de votre déploiement.

Liste noire (DNSBL)

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 :

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 /fr/pages/checks/.

Enregistrements obsolètes

Le vérificateur Types d’enregistrements DNS obsolètes analyse une zone à la recherche de types d’enregistrements dépréciés par l’IETF, et signale chaque occurrence avec la référence RFC pertinente et une suggestion de migration concrète. Les types dépréciés encombrent une zone et, dans quelques cas, sont silencieusement ignorés par les résolveurs modernes : les nettoyer garde la zone à la fois propre et sans ambiguïté.

Il s’agit d’un vérificateur de niveau zone : il parcourt chaque service de la zone de travail en une seule passe et consolide les constats par type d’enregistrement, afin que le rapport présente une vue d’ensemble plutôt qu’un résultat par enregistrement.

Ce qui est vérifié

Une seule règle, legacy_records, inspecte le corps de chaque enregistrement orphelin à la recherche d’un type déprécié et regroupe les constats par sévérité. Le statut par défaut de la règle est critique (la pire sévérité présente remonte en tête du rapport).

Pour chaque type détecté, le rapport nomme chaque propriétaire où il apparaît, la raison RFC, le remplacement suggéré et une instruction concrète de correction. Une zone propre produit un unique état OK avec le décompte de l’analyse ; les erreurs d’analyse rencontrées pendant le balayage sont exposées dans une section « ignorés » distincte, afin qu’un saut silencieux ne se fasse jamais passer pour un passage propre.

Options

Ce vérificateur n’a aucune option réglable par l’utilisateur. Le nom de domaine et le contenu de la zone sont renseignés automatiquement.

Dans happyDomain