Aller au contenu principal
← retour à l'accueil EN

sécurité par conception

contrôles vérifiables, garanties qualifiées

Périmètre : cette page décrit le code et la configuration v2 inspectés. Elle ne constitue ni une certification, ni un audit indépendant, ni une preuve que chaque contrôle est déjà actif en production.

Lors du dernier instantané de production vérifié le 29 août 2026, les trois nœuds européens utilisaient encore la pile historique dnsdist, BIND et DNS secondaire. Cette preuve datée ne décrit pas nécessairement l’état actuel ; vérifiez à nouveau le service déployé avant toute affirmation actuelle. Les contrôles v2 ci-dessous sont des propriétés du code inspecté, pas des affirmations sur la production.

Protection du chemin DNS

L’edge Go applique plusieurs mécanismes distincts :

Les valeurs par défaut du code inspecté sont une capacité de 1 000 requêtes, une recharge de 500 requêtes par seconde, un blocage de cinq minutes au-delà de 2 000 requêtes dans une seconde et un seuil NXDOMAIN de 500 sur dix secondes. Ces mécanismes ne sont pas des fenêtres commerciales de « 1 000 QPS sur 10 secondes » ou « 500 QPS sur 60 secondes ».

Le serveur autoritatif possède son propre RRL par /24 ou /48, 50 réponses par seconde par défaut, avec réponse tronquée au-delà de la limite. Le RRL BIND configuré à 50 réponses par seconde est en mode observation (log-only) et ne doit pas être décrit comme la barrière active du résolveur.

Le cache plafonne les TTL positifs à 24 heures et les TTL négatifs à cinq minutes. Une réponse stale peut être servie pendant une fenêtre de 24 heures avec un TTL de 30 secondes ; 30 secondes n’est pas un TTL minimum général.

Chiffrement et intégrité

ODoH sépare l’adresse du client du contenu de la requête uniquement lorsqu’un relais indépendant est effectivement utilisé et ne collabore pas avec le target. Un accès direct au target n’offre pas cette séparation.

Comptes et autorisations

L’interface ne constitue jamais la frontière de sécurité : les middlewares serveur appliquent les droits du plan et de la zone.

Plesk et automatisation

L’endpoint d’automatisation Plesk est protégé par authentification API et par le droit plesk_extension. Pro et Enterprise portent ce plafond de préversion, mais l’intégration reste indisponible avant admission serveur, validation externe et inscription explicite de l’installation.

Signature DNSSEC

Dans la cible v2, le service de signature séparément déployable est isolé du serveur DNS et utilise PKCS#11 vers SoftHSM. Les objets privés sont marqués non extractibles par l’API PKCS#11. Cette propriété du code ne prouve pas l’état du signer déployé.

SoftHSM reste un HSM logiciel : un administrateur root de l’hôte peut accéder à son stockage. Aucun matériel certifié, attestation matérielle ou audit indépendant n’est revendiqué. Enterprise porte un plafond de préversion BYOK pour une KSK compatible, mais le parcours reste indisponible avant admission serveur et validation externe.

Lors du dernier instantané vérifié du 29 août 2026, les zones de service le_dns n’étaient pas signées. Cette preuve datée ne décrit pas nécessairement l’état actuel ; ne présentez pas leur validation DNSSEC comme active tant que le signer déployé et les DS parentes n’ont pas été vérifiés.

Données et audits

Dans l’implémentation v2 inspectée, le résolveur n’écrit pas d’événement individuel associant durablement l’IP complète à chaque qname. Après une bascule v2 vérifiée, il exporte des agrégats horaires après un seuil minimal de 100, avec au plus un réseau /24 IPv4 ou /48 IPv6. Les agrégats ODoH ne contiennent pas cette attribution réseau. Cela ne décrit pas le pipeline historique observé le 29 août 2026.

Dans la cible v2, les événements authentifiés d’administration et de DDNS sont séparés des analytics du résolveur et soumis à un sweeper de rétention, 90 jours par défaut. Les autres catégories et limites sont détaillées dans la politique de confidentialité. Vérifiez le déploiement avant de présenter cette durée comme effective.

Résilience

Dans l’instantané inspecté le 29 août 2026, la flotte publiée comprenait trois sites européens et utilisait du DNS round-robin. Cette preuve datée doit être revérifiée avant toute affirmation actuelle. Le code v2 inspecté ne démontre pas de sélection automatique du nœud le plus proche ni de retrait automatique d’une adresse malsaine de la rotation publique. Ces mécanismes ne sont donc pas promis.

Facturation et continuité DNS

La migration locale utilise Paddle comme revendeur (Merchant of Record) et reste en cours de qualification ; le paiement en production n’est pas ouvert. Dans ce code, les droits du plan dépendent des paiements et périodes vérifiés côté serveur : revenir du checkout ne suffit pas à activer une offre. Une annulation de renouvellement confirmée conserve les droits jusqu’à la fin de la période payée ; une mise en pause ou une reprise programmée est un état distinct. Le parcours réel des impayés, de la grâce et du retour à Free doit encore être qualifié avec Paddle, sans déduire sa réussite de ces seules règles de code.

Le contrat de continuité reste le suivant : les zones existantes ne sont jamais redirigées, garées, supprimées ou remplacées par de la publicité pour une raison de facturation. Dès le début du délai de grâce de sept jours, les nouvelles ressources, autorités, automatisations et surveillances payantes sont suspendues ; la résolution et la récupération de l’existant continuent. Après le délai, les limites Free s’appliquent. Cette politique n’est pas une preuve de validation du nouveau parcours de facturation en production.

Signalement