Pourquoi le Private DNS du téléphone casse la résolution de noms du VPN

Les applications n’arrivent pas à résoudre un nom alors que le tunnel reste connecté et que tous les autres indicateurs semblent sains. Sur un téléphone, la cause habituelle est un résolveur choisi par l’appareil et non par le profil VPN. Deux réglages peuvent chacun revendiquer l’autorité sur la même requête. Déterminer lequel gagne, et s’il peut même répondre à la question, est plus rapide que de toucher au tunnel.

Deux réglages décident du même nom

Le réglage Private DNS du téléphone choisit un résolveur pour l’appareil, avec des modes allant de la sélection automatique à un nom d’hôte précis. Un profil VPN peut imposer son propre résolveur en même temps, et les deux se configurent sur des écrans différents et par des propriétaires différents. Aucun ne supplante forcément l’autre pour chaque application. C’est pourquoi un tunnel qui fonctionne et une requête qui échoue coexistent sans contradiction.

Le navigateur peut ajouter une troisième couche, car le DNS sécurisé à l’intérieur du navigateur peut choisir son propre fournisseur. L’application qui a produit l’erreur est le seul guide fiable pour savoir lequel des trois a répondu. Le résolveur doit aussi pouvoir répondre. Un nom propre à l’entreprise ne figure pas dans les données d’un résolveur public, donc la requête échoue sur le contenu et non sur la connectivité.

Choisissez le mode selon les noms dont vous avez besoin

Si l’appareil doit résoudre des noms internes, le résolveur doit être celui qui détient ces zones, ce qui signifie généralement le résolveur du tunnel ou une configuration DNS scindée que l’organisation documente. Si seuls les noms publics importent, un résolveur chiffré strict est un choix défendable qui supprime aussi les requêtes en clair. La décision découle des noms, et non d’une préférence sur le chiffrement.

Le comportement en cas d’échec varie aussi selon le mode. Un choix strict qui n’atteint pas son résolveur produit un échec pour chaque nom, tandis qu’un mode avec repli autorisé peut garder les noms publics fonctionnels et les noms internes cassés. Cette différence vous dit dans quel mode vous êtes avant d’ouvrir un écran de réglages. Sur un appareil géré, la politique approuvée décide et l’utilisateur ne peut pas la contourner en sécurité. Sur une installation personnelle, une comparaison documentée suffit à identifier le conflit, et le réglage de confidentialité voulu devrait être rétabli ensuite plutôt que laissé désactivé.

Vérifiez quelle application interroge

Reproduisez l’échec dans l’application qui l’a signalé, et notez si l’erreur est une erreur de nom ou une erreur de connexion. Une erreur de nom dans une application et une page réussie dans une autre sont la signature de deux résolveurs, pas d’un tunnel cassé.

adb shell settings get global private_dns_mode
adb shell settings get global private_dns_specifier
adb shell dumpsys connectivity | grep -i -m 5 dns

Ces commandes lisent la configuration actuelle de l’appareil, et les versions des fabricants peuvent renommer ou restreindre les valeurs sous-jacentes, alors traitez la sortie comme un indice et non comme une spécification. La documentation Android sur Private DNS décrit les modes et la forme de nom d’hôte qu’un appareil attend.

Comparez cette réponse au résolveur que le profil VPN impose. S’ils ne concordent pas, vous avez trouvé le conflit, et la question restante est lequel l’organisation veut voir gagner.

Rétablissez le réglage voulu après une comparaison

Changez un réglage, retestez les deux noms, et remettez le réglage en place. Un appareil laissé dans un mode permissif résout les noms internes et envoie discrètement chaque requête publique à qui répond en premier, ce qui est un changement de confidentialité que personne n’a consigné.

Écrivez le résultat sous forme de règle : les noms internes se résolvent par ce résolveur, les noms publics par celui-là, et le navigateur suit ou ne suit pas l’appareil. Une règle qui nomme le résolveur est vérifiable, alors qu’une note disant que le VPN a été réparé ne l’est pas. Vérifiez ensuite si autre chose sur l’appareil dépend du résolveur que vous avez changé. Les vérifications de mises à jour, la détection des portails captifs et les clients de messagerie font leurs propres requêtes, et ils échouent de manières que les utilisateurs signalent comme des problèmes sans rapport.