Un développeur égyptien, connu sous le pseudonyme ZedAxis, a présenté un dongle basé sur ESP32-C3 coûtant environ 5 dollars et capable de bloquer la publicité via un mécanisme de DNS sinkhole. Le projet revendique jusqu’à 537 000 domaines de liste noire stockés dans 4 Mo de mémoire flash, grâce à une méthode de compression et de hachage décrite sur GitHub.
À l’heure où Pi-hole sur Raspberry Pi reste une référence, ce format clé USB vise un usage plus simple, alimenté par n’importe quel port USB disponible, routeur, téléviseur ou console.
ZedAxis présente un DNS sinkhole sur ESP32-C3 SuperMini
Le cur du projet repose sur une carte ESP32-C3 « SuperMini », une déclinaison très compacte de la famille ESP32, pensée pour des objets connectés à bas coût. La démonstration, publiée sur YouTube, montre un périphérique alimenté en USB-C et connecté en Wi-Fi, qui intercepte les requêtes DNS sortantes afin de neutraliser des domaines associés à la publicité et à certains traqueurs. Le principe est proche d’un Pi-hole, avec une logique de puits DNS qui renvoie une réponse inoffensive quand un domaine listé est demandé.
Dans l’approche de ZedAxis, l’objectif n’est pas de remplacer un routeur ou un pare-feu complet, mais de fournir un blocage de base, à coût minimal, avec un encombrement réduit. L’intérêt pratique se situe dans le fait que l’appareil peut être branché derrière un routeur via un adaptateur USB, ou sur tout appareil always-on disposant d’un port USB libre. Dans un foyer, cela peut limiter la dépendance à un ordinateur ou à un mini-serveur dédié, souvent plus coûteux, plus volumineux et parfois moins tolérant aux coupures d’alimentation.
Le projet met aussi en avant une administration simple. Un tableau de bord web permet l’accès aux réglages, et la découverte réseau est facilitée par mDNS, ce qui évite de devoir retrouver l’adresse IP à chaque changement. La mise à jour du firmware peut se faire en OTA (over-the-air), une fonction importante pour un périphérique destiné à rester branché en permanence, sans maintenance lourde. Cette couche d’ergonomie rapproche l’objet d’un produit prêt à l’emploi, même si l’assemblage, boîtier imprimé en 3D et adaptateur, reste du domaine du bricolage.
Le code est publié sur GitHub, et la documentation insiste sur la partie la plus atypique du projet, la manière de représenter une liste noire gigantesque dans une mémoire très limitée. Cette contrainte matérielle est centrale, car une carte à quelques dollars ne dispose pas d’un stockage comparable à celui d’un Raspberry Pi, ni d’une quantité de RAM confortable pour des structures de données volumineuses.
537 000 domaines annoncés, des chiffres nuancés sur la mémoire
La revendication la plus spectaculaire concerne la capacité de stockage, 537 000 domaines dans seulement 4 Mo de flash. Sur le papier, conserver des centaines de milliers de noms de domaine en clair dans une telle capacité paraît difficile, voire irréaliste, car un domaine peut faire plusieurs dizaines de caractères, sans compter les structures d’indexation nécessaires pour des recherches rapides. La page GitHub du projet apporte une nuance importante, en distinguant les données chargées en mémoire de travail et la représentation compacte stockée en flash.
Le dépôt explique que, strictement parlant, la flash ne contiendrait pas 537 000 chaînes de caractères de domaines telles quelles. Un chiffre cité dans la documentation évoque plutôt 141 000 entrées dans une configuration donnée, occupant environ 2,5 Mo de RAM dans un scénario décrit, ce qui remet en perspective la promesse initiale. La présentation publique conserve néanmoins le nombre maximal agrégé, qui dépend des listes importées, du mode de construction et des marges nécessaires au firmware et aux mises à jour.
La contrainte principale est le partage de la flash entre l’application et ses mécanismes de mise à jour. Les mises à jour OTA exigent généralement de réserver de l’espace pour stocker une image de firmware en parallèle avant bascule, ce qui réduit la place disponible pour la liste noire. Le projet indique, dans la plupart des cas, une limite opérationnelle autour de 250 000 domaines, car environ 1,3 Mo seraient nécessaires pour permettre l’OTA dans de bonnes conditions. Ce détail a un impact concret, un utilisateur qui privilégie l’OTA devra accepter une liste plus courte, tandis qu’un utilisateur prêt à flasher manuellement pourrait allouer davantage de flash aux données.
Cette tension entre promesse maximale et capacité exploitable existe sur de nombreux projets embarqués. La communication autour d’un chiffre élevé attire l’attention, mais la réalité dépend du partitionnement de la mémoire, de la taille du firmware et du niveau de fonctionnalités activées. Dans ce cas précis, l’intérêt journalistique est moins le record brut que la méthode employée pour rendre la recherche de domaines possible sur un microcontrôleur, sans disque, sans base de données et avec une RAM limitée.
Pour un lecteur qui compare à Pi-hole, l’écart reste net. Un Raspberry Pi avec carte microSD peut stocker des listes immenses, conserver des logs détaillés et exécuter des services additionnels. Le dongle ESP32 vise plutôt un blocage suffisant et résilient, avec un coût et un volume très faibles, au prix d’une observabilité et d’une extensibilité réduites.
Le hachage FNV-1a 40 bits pour compresser la liste noire
La clé technique mise en avant par ZedAxis est l’abandon du stockage des domaines en clair au profit d’un mécanisme de hachage. Le projet utilise un hachage FNV-1a en 40 bits, choisi pour sa rapidité et un risque de collision relativement faible dans un contexte embarqué. L’idée consiste à transformer chaque domaine en une empreinte compacte, puis à comparer l’empreinte d’une requête DNS à celles stockées, plutôt que de comparer des chaînes de caractères longues.
En pratique, une empreinte de 40 bits représente 5 octets par domaine. À ce niveau, 141 000 domaines peuvent théoriquement tenir dans l’ordre de 0,7 Mo de données brutes, sans compter l’indexation et les structures nécessaires pour un accès rapide. La documentation mentionne aussi une consommation RAM très contenue pour la correspondance, avec moins de 50 Ko de RAM alloués au matching des domaines publicitaires dans la configuration décrite. Ce point est important, car l’ESP32-C3 ne dispose pas de marges comparables à un SBC, et le projet indique avoir choisi une carte sans PSRAM pour rester sur un profil minimaliste.
Ce type de design introduit une contrepartie, le risque de collisions, deux domaines différents pouvant produire la même empreinte. FNV-1a est conçu pour limiter ce phénomène, mais il ne l’élimine pas. Dans un système de blocage, une collision signifie potentiellement qu’un domaine non publicitaire pourrait être bloqué par erreur, ou qu’un domaine publicitaire pourrait passer si une stratégie de résolution de collision est insuffisante. La documentation publique insiste sur le compromis entre empreinte courte et probabilité de collision, et sur le fait que l’algorithme est choisi pour un bon équilibre vitesse, simplicité et empreinte mémoire.
Le choix du 40 bits est un point notable. Beaucoup d’implémentations embarquées se contentent de 32 bits pour gagner encore plus de place, mais le taux de collision augmente mécaniquement. Passer à 40 bits augmente légèrement le volume total, mais réduit le risque de collisions pour des listes volumineuses. Le projet se positionne dans une zone intermédiaire, nettement plus compacte que 64 bits, tout en étant plus prudent que 32 bits.
Cette approche empreintes plutôt que chaînes rappelle des techniques utilisées dans des filtres probabilistes, comme les Bloom filters, même si le projet décrit semble s’appuyer sur une logique de hachage et de recherche adaptée à ses contraintes. Pour un usage domestique, le bénéfice est immédiat, une liste noire lourde devient manipulable sur un microcontrôleur, et le dongle reste discret, peu énergivore et facile à alimenter.
Du foyer aux petites entreprises, quelles limites face à Pi-hole?
La question soulevée par l’article d’origine porte sur un usage potentiel en petite entreprise, réduire la part de bande passante consommée par les régies publicitaires et certains scripts tiers. Sur le principe, un blocage DNS peut diminuer le nombre de requêtes vers des domaines publicitaires, accélérer certains chargements et réduire une partie du trafic inutile. Dans des environnements où plusieurs postes consultent des sites riches en publicité, l’effet peut être perceptible, même si la part exacte dépend des usages, des formats vidéo et du poids des contenus.
Mais une transposition professionnelle pose plusieurs limites. D’abord, un ESP32 reste un microcontrôleur, pas un serveur. La capacité à traiter un volume élevé de requêtes DNS simultanées, la robustesse réseau, la tolérance aux pannes et la supervision sont des critères importants en entreprise. Un Pi-hole sur matériel plus puissant peut fournir des statistiques, des journaux, des listes différenciées par groupe, et s’intégrer à une stratégie réseau plus large. Le dongle, lui, vise l’essentiel, répondre vite et bloquer une liste, avec une interface légère.
Ensuite, la gestion des exceptions est souvent décisive. Dans une petite entreprise, certains services SaaS, outils de visioconférence ou plateformes publicitaires internes peuvent dépendre de domaines partagés avec des réseaux de tracking. Un blocage trop agressif peut casser des fonctionnalités métier. Sur Pi-hole, la gestion fine des listes blanches, l’historique des requêtes et l’identification rapide des faux positifs sont des atouts. Sur un dispositif minimaliste, ces outils peuvent être plus limités, ce qui augmente le coût de support si des problèmes apparaissent.
Le projet évoque des évolutions possibles, dont une fonction de serveur DHCP. Ce type d’ajout changerait l’architecture, car le dispositif pourrait distribuer automatiquement les paramètres réseau, y compris le DNS, sans reconfiguration poste par poste. C’est une fonction utile, mais elle accroît la criticité, si le dongle tombe, les clients peuvent perdre leur configuration réseau. Dans un foyer, c’est un désagrément. Dans une structure professionnelle, cela peut devenir un point de défaillance unique.
Reste un intérêt réel, le coût et la simplicité matérielle. Un dispositif à 5 dollars, alimenté par un port USB, peut servir de solution d’appoint, de test, ou de blocage basique dans un réseau secondaire. Il peut aussi jouer un rôle pédagogique, montrer comment un DNS sinkhole fonctionne, et comment des choix d’architecture, hachage, partitionnement de flash, OTA, déterminent les compromis finaux. Si la communauté reprend l’idée, l’axe de progression le plus attendu concernera la fiabilité, la gestion des collisions, l’observabilité et l’administration à distance dans des environnements multi-clients.
Crédit image : Smial (talk) / Wikimedia Commons (FAL)
