Politique de confidentialité
Ce qui est traité, pourquoi et pendant combien de temps
Informations incomplètes : ce projet distingue le code inspecté des preuves de production datées. Les destinataires, la conservation des sauvegardes et la politique de conservation définitive doivent être complétés avant de présenter cette notice comme une description finale du service déployé.
Lors du dernier instantané de production vérifié le 29 août 2026, le service utilisait encore la pile historique. Cette preuve datée ne décrit pas nécessairement l’état actuel ; vérifiez à nouveau le service déployé avant toute affirmation actuelle. Le pipeline historique inspecté pouvait traiter l’adresse IP source, le qname, le type de requête et les métadonnées de transport dans des journaux opérationnels. Le dépôt configure un seuil de rétention de 31 jours avec suppression différée ; ce n’est pas une durée maximale vérifiée pour chaque copie stockée. Ces journaux, lorsqu’ils sont émis, sont limités à l’exploitation, à la réponse aux abus et aux incidents. Les garanties d’agrégation en mémoire de la v2 ne doivent pas être présentées comme déployées avant la preuve de la bascule.
1. Responsable du traitement
L’opérateur a confirmé son identité : MAIKO BOSSUYT, SIREN 834180911 ; le registre officiel confirme son statut d’entrepreneur individuel (EI). L’adresse professionnelle et le téléphone confirmés par l’opérateur figurent dans les mentions légales.
- Vie privée : privacy@ledns.eu
- Sécurité : security@ledns.eu
2. Résolveur DNS public
Dans l’implémentation v2 inspectée, pour une requête récursive ordinaire, l’adresse IP source complète est utilisée en mémoire vive pour répondre et appliquer les contrôles immédiats de sécurité. Elle n’est pas écrite dans le stockage analytique v2 comme un événement individuel adresse-vers-domaine. Cela ne décrit pas le pipeline historique observé le 29 août 2026.
Après une bascule v2 vérifiée, chaque nœud agrège les observations pendant une heure. Une ligne n’est exportée que si son comptage atteint le seuil configuré, au minimum 100 requêtes. Elle peut contenir un domaine enregistré ou un qname normalisé à fort volume, le transport, le type, le code réponse, des informations de cache/backend/menace et :
- au plus un préfixe /24 en IPv4 ou /48 en IPv6 ;
- l’ASN, l’organisation et un pays approximatif ;
- une estimation agrégée des sources distinctes produite par un HMAC quotidien dont la clé et les jetons restent en mémoire.
Pour ODoH, les agrégats omettent le réseau source, l’ASN et la géographie. Cette séparation dépend de l’utilisation d’un relais ODoH indépendant par le client ; elle ne transforme pas un accès DoH direct en ODoH.
Dans la configuration v2 inspectée, les agrégats du résolveur public expirent après 30 jours en horaire et 90 jours en journalier. Les agrégats autoritatifs client, stockés séparément pour la capacité et la fiabilité, expirent après 180 jours en horaire et 730 jours en journalier. Les fenêtres 7/30/90 jours des offres limitent l’accès au reporting du plan actuel ; elles ne décrivent pas la suppression du stockage. Ces données sont traitées comme potentiellement personnelles selon leur contexte, et non comme anonymes par défaut. Vérifiez le déploiement avant de présenter ces durées comme effectives.
3. Compte et DNS autoritatif géré
Selon les fonctions utilisées, le service traite notamment :
- adresse email, empreinte de mot de passe et état de vérification ;
- sessions, facteurs TOTP/WebAuthn, codes de secours et artefacts temporaires d’authentification ;
- clés API hachées en SHA-256, préfixes d’affichage et dates d’usage/révocation ;
- équipes, invitations, rôles, identités SAML et décisions d’approbation ;
- noms de domaine, modes primaire/secondaire, enregistrements, signatures DNSSEC et historique de zone ;
- IP et port du primaire, secrets TSIG de transfert et clés DDNS ;
- objets Smart historiques conservés pour lecture/suppression, cibles, health checks, résultats de sonde et états de bascule ; ces données ne signifient pas que le routage Smart est disponible au lancement ;
- événements restreints d’authentification, d’administration et de mise à jour DNS.
Les adresses sources des audits restreints appartiennent à une catégorie séparée des agrégats du résolveur. Dans le code inspecté, les adresses de session, de dernier usage d’une clé API et d’audit administratif sont réduites à un préfixe réseau avant stockage. L’audit DDNS peut conserver l’adresse complète. Ces données servent à la sécurité et à la traçabilité ; elles ne sont pas jointes aux domaines résolus pour créer un historique de navigation.
Dans la cible v2, les secrets TSIG nécessaires au service secondaire sont stockés dans PostgreSQL et doivent être protégés comme des identifiants sensibles. Le service de signature séparément déployable isole les clés DNSSEC via PKCS#11 dans SoftHSM ; SoftHSM est un HSM logiciel, pas un module matériel certifié. Cela ne prouve pas l’état du signer déployé.
4. Facturation Paddle et archives historiques
La nouvelle implémentation v2 prépare les abonnements via Paddle. le_dns conserve les références Paddle de client, transaction et abonnement, le plan, les montants et la devise, les états, les périodes payées et de grâce, ainsi que les références locales de commande et de compte. Les documents et preuves Mollie historiques restent séparés ; le moteur Mollie actif est retiré. Les ventes en mode réel restent fermées pendant la qualification.
Le serveur transmet à Paddle le prix choisi, la devise, une référence opaque de commande, l’environnement et la référence du compte marchand, ainsi qu’une référence client Paddle lorsqu’elle existe déjà. Le contenu des zones DNS n’est pas transmis. Paddle Checkout collecte les informations d’acheteur et de paiement nécessaires ; son chargement contacte les services Paddle depuis le navigateur. Paddle agit comme revendeur et responsable du traitement pour ses propres finalités de vente, paiement et conformité ; sa politique de confidentialité décrit ces traitements. Le déploiement, les destinataires effectifs et les éventuels transferts internationaux restent à vérifier avant l’ouverture commerciale.
L’estimateur de la page tarifs du portail est facultatif. Uniquement après une demande explicite, le navigateur charge Paddle.js et transmet le pays et le code postal sélectionnés à Paddle pour une estimation consommateur en EUR. Paddle reçoit également les informations de la requête réseau du navigateur. Cette prévisualisation ne crée ni client, ni paiement, ni abonnement, et le_dns n’enregistre pas la localisation sélectionnée dans le compte. Le site de présentation ne charge pas Paddle pour ses prix de référence France statiques.
5. Finalités et bases légales à confirmer
Les finalités techniques sont : fournir la résolution et l’hébergement DNS, sécuriser les comptes et le service, permettre l’administration et l’automatisation, traiter les abonnements et répondre aux obligations légales valides.
Les bases légales envisagées sont l’exécution du contrat pour les comptes, zones et abonnements, et l’intérêt légitime pour la sécurité, l’exploitation du résolveur et les agrégats après seuil. L’opérateur doit documenter leur nécessité et la mise en balance des intérêts, puis identifier le texte et les catégories de données concernés par toute obligation légale de conservation. Le défaut de 90 jours pour les audits est un paramètre produit, pas la preuve d’une obligation légale.
6. Conservation
Durées implémentées ou explicitement configurées dans la v2 inspectée :
| Catégorie | Durée / comportement |
|---|---|
| IP complète d’une requête récursive ordinaire | Mémoire vive uniquement pour le traitement immédiat |
| Agrégats du résolveur public | 30 jours en horaire / 90 jours en journalier |
| Agrégats autoritatifs client | 180 jours en horaire / 730 jours en journalier ; accès client borné séparément à 7/30/90 jours selon le plan actuel |
| Logs opérationnels Loki | Seuil configuré de 31 jours ; suppression différée, pas un maximum vérifié pour chaque copie |
| Audits admin et DDNS restreints | 90 jours par défaut |
| Sessions et artefacts d’authentification expirés | Purge par lots après expiration, avec délai par défaut de 7 jours |
| Historique de credentials révoqués | 90 jours par défaut |
| Éléments de sonde | 48 heures par défaut |
| Transitions BYOK et mutations terminées | 365 jours par défaut |
| Confirmations complètes d’arrêt du renouvellement et file d’envoi | Politique v2 préparée : un an après émission ; purge par lots du corps, de l’objet, du destinataire et de la file d’envoi. Les copies de messagerie/prestataire et sauvegardes nécessitent une politique d’effacement distincte et vérifiée. |
| Preuve minimale de l’arrêt du renouvellement | Politique v2 préparée : identifiants liés du compte/de l’abonnement, nature et dates de confirmation, cinq ans après la plus tardive des dates d’émission ou de fin de service pour la gestion des litiges. Ce n’est pas une obligation de garder l’email complet cinq ans, ni un remplacement de la conservation des contrats de souscription ou des factures. |
Ces valeurs décrivent les seuils d’éligibilité à la suppression et les objectifs de rétention de la configuration inspectée. L’effacement dépend de la bonne exécution des traitements périodiques. Les durées de sauvegarde et de réplication doivent être documentées séparément ; aucun maximum vérifié n’est disponible ici.
La suppression définitive d’une zone la retire du service actif après les contrôles de sécurité DNSSEC applicables. Le correctif v2 préparé exclut les secrets TSIG de zones_archive et ajoute une purge bornée avec un délai diagnostique de trente jours par défaut. Ce code testé localement ne prouve pas sa mise en production ni l’effacement des anciennes sauvegardes, qui exige un traitement distinct. Cette notice ne promet donc pas une suppression de toutes les copies sous trente jours.
7. Destinataires et sous-traitants
Dans l’instantané de production inspecté le 29 août 2026, la flotte utilisait OVHcloud et Scaleway dans l’Union européenne. Vérifiez à nouveau le déploiement et les contrats avant de présenter cette liste comme actuelle. Paddle est le revendeur prévu pour les nouvelles ventes v2 ; le parcours de paiement et les données transmises restent à vérifier. Le fournisseur ou l’instance de messagerie transactionnelle, le stockage de sauvegarde et leurs localisations effectives doivent être consignés et vérifiés avant publication contractuelle.
Le site public peut charger des ressources depuis status.ledns.eu et GitHub Sponsors. Il ne faut donc pas prétendre qu’aucune ressource tierce n’est contactée.
La liste finale des sous-traitants, leurs localisations, leurs garanties et l’existence éventuelle de transferts hors EEE doivent être vérifiées sur les contrats et le déploiement réel. La seule présence de fournisseurs européens dans le dépôt ne suffit pas à prouver l’absence de tout transfert international.
8. Cookies et suivi
Le portail utilise un cookie d’authentification strictement nécessaire, HttpOnly, Secure en production et SameSite=Strict. Il possède une expiration explicite correspondant à la durée de session configurée, huit heures par défaut ; il ne disparaît donc pas nécessairement à la fermeture du navigateur.
Le site ne contient pas de système d’analytics publicitaire dans le code inspecté. Les ressources tierces mentionnées ci-dessus peuvent néanmoins recevoir les informations techniques habituelles d’une requête web ; leur comportement doit être documenté et vérifié séparément.
9. Droits
Les personnes concernées peuvent demander l’accès, la rectification, l’effacement, la limitation, la portabilité ou l’opposition lorsque ces droits s’appliquent. Les demandes sont adressées à privacy@ledns.eu.
Le changement d’adresse email n’est pas disponible en self-service dans l’API v2 inspectée ; les demandes de rectification doivent donc être traitées manuellement. La réponse intervient normalement sous un mois. Si la complexité ou le nombre de demandes justifie une prolongation, les motifs sont communiqués dans ce premier mois ; la prolongation ne dépasse pas deux mois supplémentaires. Des informations complémentaires d’identité ne sont demandées qu’en cas de doute raisonnable et dans la mesure nécessaire.
10. Violations de données
Les procédures de détection, qualification, notification et coopération doivent être testées avant le lancement commercial. Les délais légaux dépendent du rôle de le_dns et du risque ; cette page ne transforme pas une obligation conditionnelle en preuve de préparation opérationnelle.
11. Réclamation
Une personne peut saisir l’autorité de contrôle compétente, notamment la CNIL en France.