Bonjour à tous,
Je me lance ici un peu comme une bouteille à la mer. Je suis développeur (autodidacte, plutôt bas niveau à la base), actuellement sans emploi, et je bricole un projet perso depuis quelques semaines dont j'aimerais avoir des retours d'utilisateurs réels — pas forcément des experts DNS, justement des gens qui font tourner un petit lab ou un Raspberry à la maison.
Le problème que je voulais résoudre : j'utilise Unbound depuis des années et il fait très bien son boulot. Mais à chaque fois que je veux ajouter une entrée DNS locale, bloquer un domaine ou m'abonner à une liste de blocage, je dois éditer un fichier de conf, recharger le démon, et croiser les doigts pour ne rien casser. À la longue, ça m'a agacé.
Du coup j'ai écrit Runbound : un serveur DNS en Rust qui fait le même travail qu'Unbound, mais que je peux piloter à chaud via une petite API REST — ajouter une entrée, bloquer un domaine, m'abonner à une liste de pub/malware — sans jamais redémarrer le service. Bonus : il relit directement ma config Unbound existante, donc pas de migration.
En pratique, pour un usage maison, ça peut remplacer un couple Unbound + Pi-hole : résolution DNS classique + blocage de pub par listes. Il y a un fichier d'exemple home.conf prévu pour ce cas.
Quelques points qui peuvent intéresser ce coin du forum :
c'est libre (AGPL v3),
c'est un binaire statique unique, sans dépendance — tu télécharges, tu lances, ça marche (versions x86_64 et ARM/Raspberry Pi),
la config Unbound existante est réutilisée telle quelle.
Le dépôt est sur github redlemonbe/Runbound
Une mise en garde honnête : la doc du dépôt est un peu touffue. C'est volontaire — dès qu'on touche au DNS et à la sécurité, je préfère tout documenter plutôt que cacher la poussière sous le tapis — mais je sais que ça peut intimider au premier coup d'œil. Si vous voulez juste essayer sur un lab maison, ignorez 90 % du README : le script d'installation + le fichier home.conf suffisent. Le reste (durcissement, HA, XDP…) ne sert que pour des usages plus poussés.
Je précise : c'est un projet perso, fait « juste pour le plaisir » au départ, et je suis seul dessus. Donc je n'ai aucune prétention, et c'est exactement pour ça que je cherche des regards extérieurs.
Mes questions, très concrètement :
Est-ce que ce genre d'outil répondrait à un besoin que vous avez, ou est-ce que vous êtes très bien avec votre setup actuel ?
Si vous jetez un œil au dépôt : est-ce que c'est clair ? Est-ce que vous sauriez l'installer et l'essayer sans galérer ?
Qu'est-ce qui vous manquerait pour seulement envisager de le tester sur un lab à vous ?
Tout retour me sera utile, même « pas pour moi, voilà pourquoi ». Merci d'avance à ceux qui prendront deux minutes.
Runbound — serveur DNS libre en Rust, retours bienvenus
-
redlemonbe
- Messages : 2
- Inscription : 16 juin 2026, 11:04
- Status : Hors-ligne
Non, Runbound n'a pas reçu d'audit de sécurité indépendant par un humain tiers. Je ne veux pas prétendre le contraire, surtout sur un sujet touchant la sécurité.
Ce qui est en place, en revanche :
cargo audit (vulnérabilités connues des dépendances) et cargo-deny (licences + advisories), passés à chaque release ;
du fuzzing sur le parsing DNS (le point d'entrée le plus exposé) ;
un SBOM publié (CycloneDX) pour la traçabilité des dépendances ;
une revue adverse assistée par IA — white-box (revue de code : SSRF, injections, attaques temporelles, DoS, conformité RFC) et black-box (pentest de l'API et du protocole). J'insiste : l'IA sert uniquement de couche de revue, chaque trouvaille est triée et corrigée à la main par moi.
et, accessoirement, c'est du Rust : pas de débordement mémoire par construction, ce qui élimine d'office une grosse classe de failles DNS historiques (BIND/Unbound en C).
Le tout est libre (AGPL), donc le code est entièrement ouvert à l'inspection — c'est d'ailleurs un peu le but de mon message ici : si quelqu'un a l'œil pour ce genre de chose et veut jeter un regard critique, je suis 100 % preneur. C'est exactement le retour qui me manque.
Ce qui est en place, en revanche :
cargo audit (vulnérabilités connues des dépendances) et cargo-deny (licences + advisories), passés à chaque release ;
du fuzzing sur le parsing DNS (le point d'entrée le plus exposé) ;
un SBOM publié (CycloneDX) pour la traçabilité des dépendances ;
une revue adverse assistée par IA — white-box (revue de code : SSRF, injections, attaques temporelles, DoS, conformité RFC) et black-box (pentest de l'API et du protocole). J'insiste : l'IA sert uniquement de couche de revue, chaque trouvaille est triée et corrigée à la main par moi.
et, accessoirement, c'est du Rust : pas de débordement mémoire par construction, ce qui élimine d'office une grosse classe de failles DNS historiques (BIND/Unbound en C).
Le tout est libre (AGPL), donc le code est entièrement ouvert à l'inspection — c'est d'ailleurs un peu le but de mon message ici : si quelqu'un a l'œil pour ce genre de chose et veut jeter un regard critique, je suis 100 % preneur. C'est exactement le retour qui me manque.