Je te rejoins sur le fond, dans une approche ‘puriste’, mais je dois dire que s’ils sont des colosses c’est que justement ils fournissent un service qui a de la valeur.
Les fonctionnalités que j’utilise chez Google et Cloudflare sont sur l’aspect sécurité. Et je pense qu’on peut se rejoindre sur un point, c’est que la sécurité sur internet, c’est difficile. Pour des projets personnels sans grande importance, le risque principal en faisant de l’auto hébergement c’est d’ouvrir une porte à un acteur mal intentionné qui viendrait faire des dégâts sur mon réseau local, sur mon poste professionnel, etc. Dans ce contexte, j’utilise des services qui me permettent de gagner du temps et de la sérénité pour un coût nul.
Google, je pourrais faire autrement, je l’utilise car ça m’évite de demander à ma femme de se créer un autre compte dont elle oublierait le mot de passe.
Cloudflare, à aujourd’hui je ne connais pas d’alternative qui m’apporte la même sécurité et les mêmes services, mais je suis à l’écoute d’idées différentes !
Ça m’attriste toujours de voir de l’autohébergement mais que derrière ça utilise Google pour de l’auth et Cloudflare comme CDN/proxy…
Mon but dans l’auto-hébergement c’est de sortir un peu des sentiers battus et donc de ne pas dépendre de ces deux colosses qui sont déjà partout sur le web.
Tu as tout à fait raison et c’est pour ça que j’inclue la télémétrie : parce qu’on ne peut pas se porter garant des hypothétiques bonnes intentions des tiers.
Pour quel usage ? Ces appareils ont un prix élevé (smartphones). Cela vaut-il vraiment le coût ? Prendre des photos, des vidéos, passer des appels téléphoniques… Je ne dénigre pas ces technologies mais on peut se demander si c’est vraiment adapté : le fait que cela soit courant ne rend pas les choses pertinentes.
Les outils de télémétrie ne sont pas forcément le mal incarné et contre les utilisateurs.
S’ils restent anonymes et a usage de l’entreprise qui développent le logiciel, ils peuvent être utilisés pour comprendre le comportement des utilisateurs en
supprimant les fonctionnalités non utilisés (et améliorer la stabilité et la performance de l’application)
améliorer l’ux de l’application.
comprendre quelles fonctionnalités sont à optimiser (les plus longues et les plus utilisés)
Le problème des outils de télémétrie et d’analytics, sont souvent qu’ils ne sont pas anonyme, ou fournis par des tiers qui en profite pour eux même.
Absolument, et celui depuis quelques années maintenant…
Tu comprends mieux ma “surprise” et mes questions ;)
Dans les faits, c’était “expérimental” début 2018 et vers la fin de ladite année est devenu “supportée”.
Voilà !
Même si je ne l’ai pas exprimé, j’avoue avoir eu du mal avec ton commentaire précédent, puisqu’unbound est capable de communiquer en DoT, depuis l’année précisée ci-dessus. Il suffit de “pointer” vers des serveurs DNS gérant ce protocole. Bien-sûr, il gère aussi très bien les requêtes selon le chiffrement DNSSEC, et le fait même avec les serveurs DNS roots, sans aucun soucis.
J’utilise unbound pour la simple raison que le service est intégré nativement sous Open… BSD, depuis des années - c’est même là que je l’ai découvert ; quand je me suis mis à Open… WRT, j’ai cherché à l’utiliser logiquement.
Pour tout avouer, j’ai même intégré le proxy DoH dans OpenWRT ; qui me semble très bien fait, et qui intègre la possibilité de divers listes de filtrage, dont la plupart des serveurs DNS supportant DoH, supportent aussi DoT, voire se mettent même à faire du Quic-over-DNS.
(d’où le partage de la liste dans mon article)
Ainsi, sans grande modification, j’ai dans mon OpenWRT, dnsmasq le chef d’orchestre qui forward en premier à unbound les requêtes DNS sur DoT - depuis mes deux sous-réseaux, Lan et Wifi -, et si pour une raison ou un autre, il bascule sur le proxy DoH, qui envoie/enverra les requêtes DNS vers plusieurs serveurs différents, sur les deux couches IPv(4|6).
(“ceinture et bretelles”)
Oui il fait du DoT et DoH mais pas au même endroit, en gros tu te retrouves avec ça :
Serveurs roots + la récursion < – DNS en clair – > (X)|Unbound < – DNS / DoH / DoT – > clients
et avec blocky tu as
Serveurs roots + la récursion < – DNS en clair – > Résolveurs upstreams < – DNS / DoH / DoT – > (X)|Blocky < – DNS – > clients
Du coup au niveau de ton routeur (X), le trafic vu avec unbound sera du DNS en clair, alors qu’avec blocky ça sera du DNS/DoT/DoH donc potentiellement chiffré.
Unbound est un “vrai” résolveur DNS.
Son boulot est d’aller interroger les serveurs roots puis de faire la récursion.
Il peut également faire du blocage bien que ce ne soit pas dans ses fonctionnalités initiales.
Blocky lui n’est pas un vrai résolveur, il va par contre consulter des résolveurs (de ce fait je le qualifie de proxy). Par contre lui est vraiment taillé pour le blocage, du coup il sait charger des blocklist mais surtout il sait les mettre à jour de lui-même et régulièrement.
Et il a pour gros avantage de pouvoir parler à plusieurs serveurs récursifs simultannément et ce via les nouveaux protocoles que sont DoT et DoH qui permettent de chiffrer la communication entre le résolveur et lui.
Du coup d’un point de vue extérieur les deux logiciels font sensiblement la même chose, mais sous le capot ça ne marche pas pareil.
Les deux ont leurs avantages.
Unbound permet de directement parler aux roots ainsi qu’au serveurs faisant autorité c’est donc un fonctionnement plus décentralisé. L’inconvénient c’est que du coup le trafic est en clair.
À contrario, blocky fait appels à des résolveurs extérieurs et donc plus centralisés (tout en permettant d’en utiliser de multiples et donc éviter de trop cette centralisation) mais avec du chiffrement.
On a le même âge, j’en ai croisé d’autre. N’oublie pas que ce que tu développes n’est que du code d’appli web (il me semble), normalement, il n’y a pas d’enjeux vitaux. Et puis, il y a de la place pour tout le monde, laisse les gens qui codent uniquement pour de l’argent faire des choses que les passionnés ne veulent pas faire.
Je t’assure que quand tu as vécu comment on a pollué ton métier avec des tas de conneries et des méthodes de travail novatrices et, au final, destructrices (pour les humains qui sont derrière), tu finis par devenir un peu méprisant.
Je n’ai pas de popup hormis celle qui demande de s’inscrire pour recevoir la newsletter par mail. Pour le coup c’est substack qui pilote sa plateforme, je n’ai pas la main dessus malheureusement.
Je suis désolé que cela dérange.
Abonnez-vous à la chaîne naitech cela prend que 2 secondes le temps d’un clique et ça encourage à partager et à continuer beaucoup plus de temps que prend un clique merci beaucoup pour votre soutien car la motivation commence à diminuer :(.
Je te rejoins sur le fond, dans une approche ‘puriste’, mais je dois dire que s’ils sont des colosses c’est que justement ils fournissent un service qui a de la valeur. Les fonctionnalités que j’utilise chez Google et Cloudflare sont sur l’aspect sécurité. Et je pense qu’on peut se rejoindre sur un point, c’est que la sécurité sur internet, c’est difficile. Pour des projets personnels sans grande importance, le risque principal en faisant de l’auto hébergement c’est d’ouvrir une porte à un acteur mal intentionné qui viendrait faire des dégâts sur mon réseau local, sur mon poste professionnel, etc. Dans ce contexte, j’utilise des services qui me permettent de gagner du temps et de la sérénité pour un coût nul. Google, je pourrais faire autrement, je l’utilise car ça m’évite de demander à ma femme de se créer un autre compte dont elle oublierait le mot de passe. Cloudflare, à aujourd’hui je ne connais pas d’alternative qui m’apporte la même sécurité et les mêmes services, mais je suis à l’écoute d’idées différentes !
Si vous aussi vous auto hébergez, partagez ici vos stacks et vos préférences !
Ça m’attriste toujours de voir de l’autohébergement mais que derrière ça utilise Google pour de l’auth et Cloudflare comme CDN/proxy… Mon but dans l’auto-hébergement c’est de sortir un peu des sentiers battus et donc de ne pas dépendre de ces deux colosses qui sont déjà partout sur le web.
Tu as tout à fait raison et c’est pour ça que j’inclue la télémétrie : parce qu’on ne peut pas se porter garant des hypothétiques bonnes intentions des tiers.
Merci pour ton commentaire !
Pour quel usage ? Ces appareils ont un prix élevé (smartphones). Cela vaut-il vraiment le coût ? Prendre des photos, des vidéos, passer des appels téléphoniques… Je ne dénigre pas ces technologies mais on peut se demander si c’est vraiment adapté : le fait que cela soit courant ne rend pas les choses pertinentes.
Les outils de télémétrie ne sont pas forcément le mal incarné et contre les utilisateurs.
S’ils restent anonymes et a usage de l’entreprise qui développent le logiciel, ils peuvent être utilisés pour comprendre le comportement des utilisateurs en
Le problème des outils de télémétrie et d’analytics, sont souvent qu’ils ne sont pas anonyme, ou fournis par des tiers qui en profite pour eux même.
Pour le reste je trouve l’idée intéressante.
Honnêtement au début j’ai cru que c’était un hommage au sketch du bon chasseur des inconnus….. :D
Absolument, et celui depuis quelques années maintenant… Tu comprends mieux ma “surprise” et mes questions ;)
Dans les faits, c’était “expérimental” début 2018 et vers la fin de ladite année est devenu “supportée”. Voilà !
Même si je ne l’ai pas exprimé, j’avoue avoir eu du mal avec ton commentaire précédent, puisqu’unbound est capable de communiquer en DoT, depuis l’année précisée ci-dessus. Il suffit de “pointer” vers des serveurs DNS gérant ce protocole. Bien-sûr, il gère aussi très bien les requêtes selon le chiffrement DNSSEC, et le fait même avec les serveurs DNS roots, sans aucun soucis.
J’utilise unbound pour la simple raison que le service est intégré nativement sous Open… BSD, depuis des années - c’est même là que je l’ai découvert ; quand je me suis mis à Open… WRT, j’ai cherché à l’utiliser logiquement.
Pour tout avouer, j’ai même intégré le proxy DoH dans OpenWRT ; qui me semble très bien fait, et qui intègre la possibilité de divers listes de filtrage, dont la plupart des serveurs DNS supportant DoH, supportent aussi DoT, voire se mettent même à faire du Quic-over-DNS. (d’où le partage de la liste dans mon article)
Ainsi, sans grande modification, j’ai dans mon OpenWRT, dnsmasq le chef d’orchestre qui forward en premier à unbound les requêtes DNS sur DoT - depuis mes deux sous-réseaux, Lan et Wifi -, et si pour une raison ou un autre, il bascule sur le proxy DoH, qui envoie/enverra les requêtes DNS vers plusieurs serveurs différents, sur les deux couches IPv(4|6). (“ceinture et bretelles”)
Voilà ! :D (tu sais tout… ou presque)
Ha bha je viens de voir ton article et je ne savais pas que Unbound pouvais parler à des résolveurs DoT ^__^
Oui il fait du DoT et DoH mais pas au même endroit, en gros tu te retrouves avec ça :
Serveurs roots + la récursion < – DNS en clair – > (X)|Unbound < – DNS / DoH / DoT – > clients
et avec blocky tu as
Serveurs roots + la récursion < – DNS en clair – > Résolveurs upstreams < – DNS / DoH / DoT – > (X)|Blocky < – DNS – > clients
Du coup au niveau de ton routeur (X), le trafic vu avec unbound sera du DNS en clair, alors qu’avec blocky ça sera du DNS/DoT/DoH donc potentiellement chiffré.
unbound fait du DoT assurément, et même du DoH. ;)
Concernant les métriques, il semble possible de les envoyer au couple Prometheus/Grafana, aussi.
À-propos des listes de blocages, il est vrai qu’il faut mettre en place un script/système de màj par ses petites mimines, et redémarrer le service.
Unbound est un “vrai” résolveur DNS. Son boulot est d’aller interroger les serveurs roots puis de faire la récursion. Il peut également faire du blocage bien que ce ne soit pas dans ses fonctionnalités initiales.
Blocky lui n’est pas un vrai résolveur, il va par contre consulter des résolveurs (de ce fait je le qualifie de proxy). Par contre lui est vraiment taillé pour le blocage, du coup il sait charger des blocklist mais surtout il sait les mettre à jour de lui-même et régulièrement. Et il a pour gros avantage de pouvoir parler à plusieurs serveurs récursifs simultannément et ce via les nouveaux protocoles que sont DoT et DoH qui permettent de chiffrer la communication entre le résolveur et lui.
Du coup d’un point de vue extérieur les deux logiciels font sensiblement la même chose, mais sous le capot ça ne marche pas pareil.
Les deux ont leurs avantages.
Unbound permet de directement parler aux roots ainsi qu’au serveurs faisant autorité c’est donc un fonctionnement plus décentralisé. L’inconvénient c’est que du coup le trafic est en clair.
À contrario, blocky fait appels à des résolveurs extérieurs et donc plus centralisés (tout en permettant d’en utiliser de multiples et donc éviter de trop cette centralisation) mais avec du chiffrement.
IO
Blocky me semble être une alternative à Unbound, qui est hautement “paramétrable” aussi, non ?!
C’est que tu n’as pas assez écouté ce clip : https://www.youtube.com/watch?v=gb4yPEMh24E :-)
On a le même âge, j’en ai croisé d’autre. N’oublie pas que ce que tu développes n’est que du code d’appli web (il me semble), normalement, il n’y a pas d’enjeux vitaux. Et puis, il y a de la place pour tout le monde, laisse les gens qui codent uniquement pour de l’argent faire des choses que les passionnés ne veulent pas faire.
Ça se sent tant que ça ?
Je t’assure que quand tu as vécu comment on a pollué ton métier avec des tas de conneries et des méthodes de travail novatrices et, au final, destructrices (pour les humains qui sont derrière), tu finis par devenir un peu méprisant.
Dommage, il y a du bon dans cet article, mais le style est un peu trop méprisant à mon goût.
Belle liste, dommage tout les liens pointent sur Spotify.
Je n’ai pas de popup hormis celle qui demande de s’inscrire pour recevoir la newsletter par mail. Pour le coup c’est substack qui pilote sa plateforme, je n’ai pas la main dessus malheureusement. Je suis désolé que cela dérange.
Une fois j’ai dû carrément grepper /dev/sdx à la recherche des derniers enregistrements du fichier écrasé.
Abonnez-vous à la chaîne naitech cela prend que 2 secondes le temps d’un clique et ça encourage à partager et à continuer beaucoup plus de temps que prend un clique merci beaucoup pour votre soutien car la motivation commence à diminuer :(.