N’autoriser le DNS que via votre résolveur VPN : un parcours pas à pas

Suivez une seule résolution de nom dès l’instant où vous la tapez. Le navigateur interroge le système d’exploitation, le système interroge le résolveur que sa politique retient, et la requête quitte l’appareil par une interface et un transport quelconques. Votre conception VPN affirme que la réponse doit venir d’un résolveur précis par un chemin précis. L’écart entre ces deux affirmations, c’est ce que vous configurez puis faites respecter.

Étape 1 : nommer le résolveur et le chemin

Notez trois choses avant de toucher à un pare-feu : l’adresse du résolveur, le protocole et le port attendus, et l’interface par laquelle la requête doit sortir. Sans cette liste, une règle est une supposition sur le trafic et non l’application d’une décision. Un VPN peut transporter les données des applications pendant que le DNS suit un agencement distinct, et ce n’est pas une erreur en soi. C’est ce qui arrive quand personne n’a dit autre chose au client.

Nommer le chemin explicitement, c’est la différence entre une conception et un accident. Cela vous donne aussi de quoi tester plus tard, car chaque observation peut être comparée à une attente écrite. Gardez cette liste dans le ticket de changement plutôt que dans la tête de quelqu’un.

Étape 2 : placer la politique là où elle vit vraiment

Le choix du résolveur appartient au client : configuration réseau du système, réglages propres au client VPN ou politique de navigateur gérée. Placez-la d’abord là, avec le mécanisme que la plateforme prend en charge, car un pare-feu ne peut pas obliger un client à choisir un résolveur dont il n’a jamais entendu parler. Sur un client à tunnel divisé, dites explicitement quels domaines vont au résolveur interne. Dans un parc géré, la politique du navigateur est souvent le seul levier pour DoH, car le navigateur peut choisir son propre résolveur chiffré indépendamment du réglage système.

Sautez cette étape et allez droit au pare-feu : vous obtenez une règle qui autorise le bon résolveur et un client qui ne l’utilise jamais. La règle paraît correcte et les journaux du résolveur restent vides, un duo déroutant à déboguer. Configurez d’abord le choix, puis imposez-le.

Étape 3 : imposer le chemin de façon étroite

Ajoutez maintenant l’autorisation réseau pour le chemin permis : l’adresse du résolveur, le protocole et le port, et l’interface par laquelle il doit sortir. Gardez la règle limitée à ce résolveur au lieu d’autoriser tout le DNS sortant. Les trois chemins ci-dessous sont ceux qu’un client moderne peut emprunter, et seul le premier est couvert par une règle sur le port 53.

Bloquer DoH et DoT est légitime ; supposer qu’une règle sur le port 53 les a déjà bloqués ne l’est pas. Un navigateur en DoH résout les noms par un chemin que votre règle n’a jamais décrit, et une application qui embarque son propre résolveur fait de même. Écrivez chaque chemin que vous comptez autoriser et chacun de ceux que vous comptez refuser. Une règle qui ne nomme pas un chemin n’a rien décidé à son sujet.

Étape 4 : suivre les noms privés et publics

Le DNS divisé envoie délibérément seuls les espaces de noms privés vers un résolveur interne tandis que les noms publics vont ailleurs : avoir plusieurs résolveurs dans la conception n’est donc pas une fuite. La fuite, c’est une requête qui aurait dû aller à votre résolveur et qui arrive ailleurs, ou un chemin prévu inaccessible qui fait retomber le client en silence. Ce sont ces deux cas qu’il faut chercher. Suivez un nom interne et un nom public sous la politique prévue et notez quel résolveur a répondu à chacun.

Un site de test qui affiche votre résolveur est un indice, pas une preuve, car il ne voit que les requêtes qui l’ont atteint. Capturez la requête côté client quand vous devez savoir quel chemin elle a réellement pris, puis comparez les deux observations. Quand elles divergent, vous avez trouvé un repli que personne n’a documenté.

Si l’adresse du résolveur est correcte mais injoignable, le problème relève du routage ou du filtrage et non de la politique. Tracez la requête vers cette adresse et confirmez que la réponse revient par l’interface attendue avant de modifier le moindre réglage de résolveur.

Étape 5 : garder un chemin de retour

Avant de durcir l’accès DNS sur la passerelle, confirmez une méthode de récupération qui ne dépend pas de la résolution de noms. Un résolveur cassé rend tout outil de réparation plus difficile à atteindre, y compris ceux qui serviraient à annuler le changement. Gardez une console locale ou un chemin hors bande ouvert jusqu’à ce que la nouvelle politique soit prouvée. Ne le retirez qu’après que la politique a survécu à une reconnexion.

Après une reconnexion ou une mise à jour de la politique du navigateur, inspectez de nouveau l’état effectif, car les deux peuvent changer le résolveur sans changer votre règle. L’exigence est un destinataire connu et un chemin protégé pour les requêtes, pas une étiquette de résolveur rassurante sur une capture d’écran. La spécification RFC 8484 de DNS over HTTPS est la référence pour le chemin chiffré que votre règle de port ne voit pas.