Le DNS fait traditionnellement partie de la libc
. Le système Android Bionic libc
dépend de netd
pour le DNS traditionnel ainsi que pour le DNS privé ( DoT
). Voir aussi cette réponse pour plus de détails.
Étant donné que chaque application fonctionne dans sa propre version de la machine virtuelle (ART) dérivée de l'application zygote
Ainsi, lorsqu'une application crée un nouvelle connexion à un nom d'hôte distant, les requêtes DNS sont effectuées par la VM au nom de l'application, qui utilise la résolution DNS dans le code natif. L'ensemble est donc géré par l'exécution Java.
Lors de l'utilisation du tethering, un serveur DNS doit être exécuté sur l'appareil Android qui écoute les requêtes DNS reçues des hôtes connectés. Ces requêtes sont ensuite résolues selon la configuration du serveur DNS. dnsmasq
est la mise en œuvre actuelle de DHCP
/ DNS
sur Android jusqu'à Pie. Il s'agit d'un démon natif, qui reçoit les informations suivantes nameservers
von TetherController
(une partie de netd
) ou /etc/resolv.conf
(si no-resolv
n'est pas transmis) ou /etc/dnsmasq.conf
(en utilisant server=
).
Donc dnsmasq
travaille de manière indépendante et ne dépend pas de libc
o netd
pour la résolution DNS. Dans d'autres cas, si l'appareil connecté utilise un autre serveur de noms public et non le dnsmasq
Les requêtes DNS sont transmises à l'internet conformément à la politique de routage et aux règles NAT. Dans tous les cas, les requêtes ne passent pas par le DNS privé.
Cela dit, vous pouvez utiliser une solution tierce pour crypter les DNS. Optez pour une solution robuste : dnscrypt-proxy sur un appareil rooté. Voir cette réponse pour une configuration avancée.
Ou utilisez une application VPN comme cette . Mais le VPN ne redirige pas le trafic du hotspot à travers le réseau VPN pour autant que je l'ai testé sur Pie ROM. Vous devez modifier la table de routage et les règles de transfert. Cela fonctionne pour moi :
~# iptables -t mangle -I PREROUTING -i wlan0 -p udp --dport 53 -j MARK --set-mark 2
~# ip rule add fwmark 2 lookup 5000
~# ip route add default dev tun0 table 5000
~# iptables -I FORWARD -o wlan0 -i tun0 -j ACCEPT
~# iptables -I FORWARD -i wlan0 -o tun0 -j ACCEPT
En outre NAT
peut également s'avérer nécessaire dans certaines situations. Il semble donc qu'il n'y ait pas de solution sans racine.
PS :
Très probablement, Android Q aura DoT
sur le tethering aussi parce que dnsmasq
est remplacé par un service DHCP au sein de l'exécution Java.
RELATED : Comment partager la connexion VPN avec d'autres appareils sur le hotspot ?