Architecture DNS et confidentialité d’EDU Filter

Objectif technique

EDU Filter agit au niveau DNS. L’école demande un site, son instance dédiée applique les règles, puis renvoie une réponse autorisée ou bloquée. Ce choix couvre les appareils du réseau configuré sans installer un logiciel sur chacun d’eux.

Filtrage au niveau DNS

Pourquoi: Bloquer avant l’ouverture du site.
Effet: Tout appareil du réseau applique les règles.

Minimisation des données

Pourquoi: Réduire les données exposées.
Effet: Pas d’historique DNS persistant en fonctionnement normal.

Une instance par école

Pourquoi: Séparer les contextes scolaires.
Effet: Une configuration isolée par établissement.

Boucle DNS : demande, décision, réponse

L’école demande un site. La demande arrive sur le serveur dédié de l’établissement, qui contient Unbound local et les règles définies. Le serveur décide selon ces règles, puis répond à l’école : site accessible si autorisé, accès arrêté si bloqué.

1 École demande un site

2 Serveur DNS Unbound local + règles

3 Site demandé adresse retrouvée

C’est ici que nous agissons

Unbound local relié aux root-servers.
Filtre avec les règles définies avec l’école.
Résultat simple : autorisé ou bloqué.

Autorisé le site demandé revient à l’école

Bloqué la réponse est arrêtée par les règles

Pas d’upstream DNS public : résolution locale avec Unbound Les requêtes ne sont pas envoyées à Google, Cloudflare, Quad9, OpenDNS/Cisco ou un service équivalent.

Instance dédiée par école

Le modèle retenu est volontairement strict : une école = une instance. Les règles, les paramètres et les ajustements restent propres à l’établissement.

Pourquoi Une école primaire n’a pas les mêmes besoins qu’une autre.

Isolation Un réglage local ne se propage pas aux autres établissements.

Maintenance Diagnostic plus clair : une instance, un contexte, des règles.

Appareils Une nouvelle machine connectée au réseau passe par la protection.

Hébergement, données et responsabilités

L’infrastructure est hébergée en Belgique. L’objectif n’est pas de promettre une protection parfaite, mais de rendre l’architecture vérifiable, de limiter les données conservées et de donner à l’école des règles qu’elle peut comprendre et discuter.

Requêtes DNS

Réglage: Journalisation détaillée désactivée en fonctionnement normal.
Effet: Pas d’historique persistant des domaines demandés.

Journaux d’exploitation

Contenu: Démarrage, arrêt, erreur et état du service.
Durée: Quatorze jours maximum, accès technique autorisé uniquement.

Diagnostic temporaire

Usage: Trace ciblée uniquement pour comprendre un incident.
Suppression: Dans les 72 heures après clôture, avec l’école informée.

Pourquoi ne pas utiliser un résolveur DNS public ?

Les services publics ont leurs propres politiques et centralisent les requêtes qui leur sont envoyées. Unbound les résout localement depuis la chaîne DNS publique. Ce choix réduit la dépendance à un tiers et évite de lui transmettre les demandes de l’école.

Blocages, limites et support

Erreur de blocage Le référent transmet le domaine et le contexte, sans identifier un élève. La règle est vérifiée et corrigée si nécessaire.

Périmètre La protection s’applique au réseau configuré de l’école. Elle ne suit pas l’appareil sur un autre réseau.

Ce qui reste à protéger Comptes, appareils, mises à jour, antivirus et usages humains demandent d’autres mesures.

Support du pilote Contacts, horaires et procédure d’incident sont convenus avant l’installation. Pas de garantie 24/7 à ce stade.

Le filtre ne remplace pas la sensibilisation

Un système peut bloquer un domaine connu, mais il ne peut pas décider à la place d’un élève ou d’un adulte dans toutes les situations. La prévention et l’accompagnement restent une partie essentielle du projet.

Parler du projet avec l’ASBL