Journaux du résolveur DNS et journaux de connexion VPN : ce que chacun contient

Un journal de résolveur DNS et un journal de connexion VPN sont tous deux des enregistrements réseau, tous deux utiles et non interchangeables. Le résolveur reçoit les noms qu'on lui a demandé de résoudre. Le point de sortie du VPN gère les connexions de tunnel et enregistre ce que son implémentation a choisi d'enregistrer à leur sujet. Ils peuvent se trouver dans le même bâtiment, être exploités par la même équipe et relever de la même notice de confidentialité, et ils décrivent néanmoins des événements différents avec des identifiants différents et une conservation différente. Lire l'un comme s'il était l'autre, c'est ainsi que les enquêtes partent de travers.

Deux journaux, deux événements

Une entrée du résolveur répond à une question de nommage : ce client a demandé ce nom à ce moment-là, et la réponse était celle-ci. Une entrée du VPN répond à une question de connectivité : ce pair a établi ou perdu un tunnel, a reçu cette adresse et a transféré à peu près autant de données avant de disparaître. Aucun des deux n'est un enregistrement de ce que l'utilisateur a fait dans une session HTTPS, et aucun ne remplace l'autre.

La distinction a une conséquence pratique pour les promesses. L'affirmation qu'un fournisseur de VPN ne journalise pas l'activité du tunnel ne dit rien du résolveur qu'il fournit, et la politique de conservation d'un résolveur ne dit rien de qui s'est connecté au tunnel. Chaque affirmation appartient à son propre opérateur et à son propre système.

Suivez la requête avant de lire l'un ou l'autre journal

Une requête n'atteint un résolveur que si le chemin le lui demande réellement. Une application peut utiliser le résolveur du système d'exploitation, exécuter son propre client DNS chiffré, ou lire une réponse en cache et n'envoyer jamais rien. Un journal de résolveur qui ne montre rien n'est donc pas la preuve qu'un nom n'a jamais été utilisé ; c'est la preuve que ce résolveur n'a pas été interrogé.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Cette dernière commande lit le journal propre au résolveur local, ce qui n'est pas la même chose que le journal du serveur en amont. Si vos requêtes sortent en DNS over HTTPS vers un fournisseur, le stub local peut ne rien montrer tandis que le fournisseur détient l'enregistrement complet, et le fournisseur est un autre opérateur avec une autre politique.

Ce que chaque enregistrement peut montrer et ne peut pas montrer

Les relier est le vrai travail, et les relier n'est pas toujours possible. Un résolveur qui journalise les adresses des clients peut être comparé à un VPN qui attribue des adresses depuis un pool connu, et cette comparaison produit un lien plausible entre un nom interrogé et un tunnel, qui reste un lien entre deux enregistrements plutôt qu'un enregistrement d'une personne.

Le DNS chiffré change le transport, pas la visibilité au point de sortie. Le résolveur reçoit toujours la question à laquelle il répond, comme RFC 8484 le montre clairement, et la conservation dans ce résolveur est une décision de politique et non une propriété du protocole.

Où le DNS fractionné et les caches brouillent l'histoire

Plusieurs résolveurs sont normaux. Une conception à DNS fractionné envoie les noms internes vers un serveur interne et tout le reste vers un serveur public, si bien qu'une seule enquête peut impliquer deux journaux qui n'ont jamais été conçus pour être combinés et deux réglages de conservation qui n'ont jamais été conçus pour être comparés. Voir des requêtes dans les deux est la preuve que la conception fonctionne, pas la preuve d'une fuite.

Les caches coupent dans l'autre sens. Un nom populaire peut être résolu depuis le cache pendant des heures, si bien que l'enregistrement du résolveur montre la première requête puis plus rien, tandis que l'application de l'utilisateur continue de résoudre le même nom allègrement. L'absence d'entrées après un certain moment ne signifie pas que personne n'a utilisé le nom après ce moment.

Le trafic de fond est la troisième distorsion. Un téléphone qui résout un nom de télémétrie au démarrage, un navigateur qui résout un domaine de suggestion de recherche et un programme de mise à jour qui se signale toutes les heures apparaissent tous dans un journal de résolveur à côté du nom qui vous intéresse vraiment. Le volume dans ce journal n'est pas de l'attention, et compter les requêtes n'est pas compter les visites. Un journal de résolveur est un enregistrement de questions, et les questions sont bon marché à produire.

Posez les questions de conservation séparément

Pour chaque système, posez trois questions : qui collecte, ce qui est collecté, et combien de temps c'est conservé. Demandez ensuite qui peut le lire et selon quel processus. La discussion du RFC 8484 sur DNS over HTTPS rappelle utilement que le transport chiffré ne supprime pas le point de sortie, et la documentation propre à un opérateur est la seule affirmation fiable sur ce que ce point de sortie conserve.

Quand une affirmation sur la confidentialité porte sur « le VPN », décomposez-la avant de l'accepter : l'opérateur du tunnel, le résolveur que le tunnel fournit, tout résolveur en amont que ces requêtes atteignent, et les applications de l'appareil. Chacun a sa propre réponse, et une affirmation exacte pour l'un est régulièrement répétée comme si elle couvrait les quatre.

Pour le dépannage, utilisez la même division. Demandez quelle application a fait la requête et quel résolveur y a répondu, puis regardez le journal qui possède réellement cet événement. Deviner à partir de l'autre journal fait gagner une minute et coûte un après-midi.