Migration de pi-hole vers AdGuard Home et digression

  1. Digression
    1. QUIC
    2. DNS-over-whatever
    3. Le rapport avec AdGuard
  2. Conclusion

Attention, je deviens vulgaire au cours de cet article.

Je continue de supprimer mes services sous docker afin de privilégier des solutions natives à NixOS. Après avoir remplacé Drone par Woodpecker (et jusqu'à présent, j'en suis tout à fait satisfait), je me suis lancé dans le remplacement de pi-hole par AdGuard Home.

J'avais déjà fait plusieurs fois la tentative, étant donné que la popularité d'AGH n'est pas récente, sans jamais vraiment avoir été convaincu.

Si, techniquement, le passage de pi-hole à AdGuard Home s'est fait sans le moindre problème (voir le code ci-dessous), AGH me laisse une impression troublante que le web va finir par complètement nous échapper.

{
  services.adguardhome = {
    enable = true;
    settings = {
      bind_port = 8080;
      users = [
        {
          name = "richard";
          password = "<mon super mot de passe>";
        }
      ];
    };
  };
}

Ce sentiment n'est pas dû à l'application en elle-même mais aux technologies sous-jacentes. J'y pense et je n'en parle que maintenant parce que depuis plusieurs années que j'utilise pi-hole "à ma façon", je n'avais pas encore à me poser la question, mais maintenant que j'ai décidé de passer sur AdGuard Home, il est grand temps que je vous parle de mon inquiétude sur l'avenir de l'informatique.

En l'occurrence, je veux parler de DNS-over-QUIC et de DNS-over-HTTP/TLS.

Digression

QUIC

DNS-over-QUIC me dérange, à cause de QUIC. Pour rappel, c'est le HTTP/3 voulu, conçu et forcé par Google. Traitez-moi de conspirationniste anti-Google si vous voulez, mais permettez-moi un petit rappel de faits vérifiables, et de vous présenter les liens que j'établis entre ces faits.

QUIC a été déployé de façon publique et expérimentale dans Google Chrome en 2012, par et pour les services de Google. Un brouillon du protocole a été soumis à l'IETF en juin 2015 (rapidement remplacé par une nouvelle version en juillet). Six mois plus tard, soit une fois que l'IETF considère le brouillon comme étant obsolète, une nouvelle version est publiée, prolongeant la validité du brouillon. Certes, quelques modifications ont été réalisées entre temps, mais le timing est troublant.

D'autant plus que six mois plus tard, encore, le nouveau brouillon n'est toujours pas ratifié, et fait l'objet d'une nouvelle publication, prolongeant de fait sa validité pour l'IETF.

Ce brouillon a définitivement expiré le 9 janvier 2017. Pourtant, en octobre 2018, le protocole est subitement renommé HTTP/3 pour "anticiper sa promotion en standard du Web", ce qui ne se produira pourtant pas avant mai 2021 avec la publication de la RFC9000.

Peut-être que je me place d'office dans une chasse aux sorcières, néanmoins il est impossible de nier que Google est partout, et décide de beaucoup plus que ce qui concerne son moteur de recherche. Google a tout pouvoir pour imposer ses choix technologiques ; qu'ils soient bons ou mauvais n'est pas la question.

Google n'a demandé l'avis à personne (les utilisateurs de Chrome) pour faire ses expérimentations. Ce n'est pas comme s'ils expérimentaient sur leur moteur de recherche, où des changements seraient perçus comme la mise à jour de leur logiciel. On parle là de l'appropriation par la transformation d'un protocole réseau qui ne leur appartient pas. On parle d'une dystopie, où une entreprise privée s'arroge tout pouvoir sur les infrastructures logicielles du réseau public d'Internet. Ils avaient déjà fait le coup avec SPDY (devenu HTTP/2), mais comme tout le monde est content parce que ça permet aux devs web d'être de grosses fénéasses (en permettant notamment d'ouvrir plusieurs flux pour télécharger toutes les merdes en javascript qu'ils ne savent pas concaténer), tout le monde s'en fout que ce soit Google aux manettes.

Je ne comprends pas comment on peut être aussi cons, ou fantasmer à ce point un monde informatique où Google est Dieu tout puissant. J'en parlais déjà en 2016 de cette aberration de permettre à Google de faire tout et n'importe quoi sur Internet.

"Et alors ?", vous me direz avec un soupçon de condescendance, "Rien de grave n'est arrivé, on a de meilleurs protocoles, de quoi tu te plains ?". Je ne peux que lancer mon bras en l'air, dépité devant tant d'inaptitude à réfléchir au long terme et sur les ramifications de tout ça. C'est juste que ça fait depuis vingt ans qu'on vous dit que Google c'est le mal, qu'on vous explique pourquoi, qu'on vous propose des alternatives, et au final, c'est juste de la putain de politique. Les grands pontes se retrouvent à la tête des organismes les plus importants du Web (IETF, W3C), et on a juste à fermer nos gueules parce qu'ils savent mieux que nous ce qui est bien - pour eux et leurs entreprises.

À quel moment on a voté pour eux ? Qui sont nos représentants de ces organismes ? Ce n'est pas comme si un gars un jour avait développé un truc dans son garage et que ça avait du succès. Là, c'est de la putain de politique, et ça me gonfle que mon monde (l'informatique) soit déjà infesté par la politique.

DNS-over-whatever

DNS-over-HTTP, c'est la même rengaine, mais avec d'autres implications. C'est encore un truc que l'on doit à Google (même si Mozilla y a participé). Pareil pour DNS-over-TLS, Google est là. Je ne supporte plus cette entreprise qui fourre son nez partout, faisant croire qu'ils améliorent Internet alors qu'ils participent à sa centralisation.

À la base, DNS-over-HTTP, ratifié en 2018, devait résoudre des cas particuliers de la gestion des DNS, notamment en terme de sécurité. 6 ans après que j'ai proposé ODDNS et que je me sois fait pourrir par Stéphane Bortzmeyer1, me conduisant à abandonner le projet sous les insultes de mon "aide de camp" de l'époque, qui m'a notamment traité de "connard" à cause de cet abandon.

Là, je l'ai mauvaise parce qu'ODDNS, c'était une preuve de concept qu'exploiter DNS par HTTP était faisable, souhaitable. Sauf que je suis pas un commercial moi, je suis un technicien, et personne n'a compris ce que je faisais. ODDNS a eu son heure de gloire sur les réseaux sociaux dans le monde entier, pendant quelques jours. Avant que Bortzmeyer ne vienne me couper l'herbe sous le pied en dénigrant le travail d'un autre comme seul un informaticien sait le faire.

En outre, et c'est le plus important après cette digression dans la digression, DNS-over-HTTP est conçu pour éviter la censure. Un blocage DNS est inefficace over-HTTP. C'est parfait pour les utilisateurs victimes de la censure étatique, mais il fallait bien s'attendre à ce que des entreprises comme Google mettent la main dessus, et s'en servent pour éviter que les utilisateurs puisse continuer à bloquer leurs domaines...

Alors, si DNS-over-HTTP devient la norme, je fais comment pour bloquer toutes les merdes de Google, de facebook et de Microsoft ? Terminées les listes de domaines à blacklister. Impossible de savoir qui fait quoi sur mon propre réseau. Au moins, passant par mon propre DNS, je vois quel périphérique réclame la résolution de tel domaine. Avec DNS-over-HTTP, c'est fini ça, et mes données foutrons le camps chez Google, ou en Chine, sans que je le sache.

On dispose de serveurs DNS racines. L'infrastructure DNS du web repose sur ces serveurs. Google : "Bah, OSEF, on va faire du DNS-over-HTTP, comme ça ils restent en place, ils font leur tambouille, et puis comme on est Google les utilisateurs vont tous vouloir faire du DNS-over-HTTP (au pire on dit que c'est une expérimentation, on fait un draft, et puis t'as pas un pote à l'IETF ? valà, bam ça devient une RFC), on est des héros, on leur évite la censure, et puis c'est nous qui devenons les nouveaux serveurs racine, comme ça, on ramène encore plus de traffic, et de $$$, et on peut continuer avec les prochains trucs. Tiens, bah ! On va s'incruster dans l'IoT, et puis le Wifi aussi ! On a déjà les caméras, les sonnettes (une sonnette à 200€, au passage), les enceintes connectées et tout.".

Nous sommes des brebis, des moutons, et on n'a que peu de choix pour s'en sortir.

Putain, je veux pas de cet Internet-là. J'en ai jamais voulu. Je vous ai toujours dit ce que j'en pensais.

Je suis vraiment inquiet sur l'avenir d'Internet.

Le rapport avec AdGuard

Pi-hole ne m'a jamais parlé de DNS-over-HTTP et je ne me suis jamais renseigné sur quelqu'application tierce pour le faire. Je ne veux pas légitimer cet usage sur mon réseau.

DoH est nativement supporté par AdGuard Home, ce qui me fout déjà l'angoisse de ce que l'application peut faire avec une mauvaise configuration et de mauvaises attentions. L'hostilité grandissante des applications à l'encontre des utilisateurs anime en moi une paranoïa que même une licence GPL ne peut apaiser.

AdGuard valorise cet usage en poussant à sa configuration, à son activation, demandant de fait d'exposer l'interface sur le web. Mais je m'en fous de ça, moi. Tout ce que je veux, c'est que MON putain de réseau local passe par les services que JE contrôle, et personne d'autre.

Conclusion

AdGuard Home a désormais remplacé pi-hole sur mon réseau, tout fonctionne bien. Je l'ai déjà dit : techniquement, tout va bien.

Mais je ne suis pas tranquille pour autant, je suis mal à l'aise, inconfortable, comme si j'allais réaliser que j'aurai dû rester sous pi-hole, voire utiliser le système de blocage minimaliste proposé par OPNSense.

Je déteste ça.

Mise à jour du 22 juin 2023

Je suis repassé à pi-hole en docker en attendant de trouver mieux. Vraiment trop mal à l'aise avec AdGuard Home.


  1. Liens morts constatés le 29 février 2024 et sans exemplaire disponible sur web.archive.org.