Gabriel Corona a écrit 4 commentaires

Ils veulent dire c'est que le client peut choisir n'importe quelle IP qui sera envoyée par Google en tant que EDNS Client Subnet pour faire la requête. Et par défaut, il n'inclue visiblement pas de EDNS Client Subnet. C'est donc plutôt pas mal de cette option.

Dans cette quête de "privacy" autour de DNS, il serait malheureux que ce soit une solution quasi propriétaire
(DNSCrypt) ou promue par Google (dns-over-https) qui l'emporte.

Après, si la solution promue par Google est implémentée par d'autres que Google ce ne serait pas forcément un problème.

Ce qui est un peu dommage, je trouve c'est que leur "dns-over-https" n'est pas du DNS/HTTPS. Ce n'est pas vraiment le protocole DNS, mais le contenu des champs des messages DNS encodés en JSON le tout transporté au dessus de HTTPS. L'idée étant, je crois, d'être facilement consommable par des client web JS (sinon, ils auraient pu faire un lib JavaScript qui parse et formate des messages DNS et faire passer des vrais messages DNS dans les tuyaux).

Mon retour d'utilisation de Stubby est mitigé.

Un truc que je trouve assez dommage c'est que Stubby tourne forcément en root pour le moment.

Si une bonne âme avait une idée pour configurer stunnel (ou socat) afin de "persister" la session TCP client,
je lui serais éternellement reconnaissant :)

Les requêtes arrivent un message par connection : si on voulait que stunnel ou socat fasse passer tous les messages dans la même connections TCP, on aurait besoin de faire le framing des messages et de faire la correspondance entre les réponses obtenues et les requêtes pour envoyer la bonne réponse au bon client. On aurait besoin d'une compréhension (minimale) du protocols DNS au niveau de stunnel/socat. Ce n'est pas vraiment le rôle de stunnel/socat d'implémenter la logique de framing et matching requêtes/réponses de DNS.

Non, ce n'est pas KSM qui fait ça. Ce dont on parle, c'est :

1. le fait que, quand un processus mmap un fichier dans son espace d'adressage, tant que les pages ne sont pas modifiées, elles sont partagées avec tous les autres processus (ce qui fait que le code d'un fichier ELF soit partagé entre tous les processus qui l'utilisent) ;

2. quand un process fork, il partage les pages mémoire avec son fils (jusqu'à ce que l'un des deux modifie la page ce qui entraîne une duplication de la page ou jusqu'à ce que l'un des process ne fasse un fork).

Bref, il s'agit d'éviter de dupliquer des pages.

Ceci est géré est déclenché par :

1. le code de gestion d'ELF du noyau qui se charge de mapper le linker dynamique (ld.so) en mémoire ;

2. le code du linker dynamique qui va mmap les autres fichiers ELF en mémoire (avec MAP_PRIVATE).

KSM est un mécanisme optionnel (en général ce n'est pas utilisé) qui permet de dédupliquer des pages qui sont identiques. Par défaut, il est en général désactivé dans le système (cat /sys/kernel/mm/ksm/run) et, de toute manière, il ne fonctionne que pour les pages qui ont été marquées MADV_MERGEABLE (pas le cas par défaut). Il indexe le contenu des pages physiques et tente de trouver des pages ayant le même contenu : dans ce cas, les pages sont dédupliquées/fusionnées (et les déduplique à nouveau si jamais l'une est modifiée). Ce processus de détection de pages peut consommer pas mal de temps CPU et cause des fautes de pages supplémentaires lorsque les pages dédupliquées sont modifiées.

Voir mes essais d'utilisation de KSM si ça intéresse quelqu'un.