Le module DNS Resolver offre une protection aux utilisateurs contre les attaques d'interception DNS et de mise à jour de configuration et améliore les performances du réseau pour les résolutions DNS. Le module contient le code qui implémente le résolveur de stub DNS, qui traduit des noms tels que www.google.com en adresses IP telles que 2001:db8::1 . Le résolveur de stub DNS prend en charge les éléments de l'API Java tels que InetAddress#getAllByName et Network#getAllByName , ainsi que les fonctions réseau natives , et implémente l'envoi et la réception de requêtes DNS et la mise en cache des résultats.
Changements dans Android 10
Sur les appareils exécutant Android 9 et versions antérieures, le code du résolveur DNS est réparti sur Bionic et netd . Les recherches DNS sont centralisées dans le démon netd pour permettre la mise en cache à l'échelle du système, tandis que les applications appellent des fonctions (telles que getaddrinfo ) dans Bionic. La requête est envoyée via un socket UNIX vers /dev/socket/dnsproxyd au démon netd , qui analyse la requête et appelle à nouveau getaddrinfo pour émettre des recherches DNS, puis met en cache les résultats afin que d'autres applications puissent les utiliser. L'implémentation du résolveur DNS était principalement contenue dans bionic/libc/dns/ et en partie dans system/netd/server/dns .
Android 10 déplace le code du résolveur DNS vers system/netd/resolv, le convertit en C++, puis modernise et refactorise le code. Le code dans Bionic continue d'exister pour des raisons de compatibilité des applications, mais n'est plus appelé par le système. Ces chemins sources sont affectés par la refactorisation :
-
bionic/libc/dns -
system/netd/client -
system/netd/server/dns -
system/netd/server/DnsProxyListener -
system/netd/server/ResolverController -
system/netd/resolv
Format et dépendances
Le module DNS Resolver (`com.android.resolv`) est livré sous forme de fichier APEX et est lié dynamiquement par netd ; cependant, netd n'est pas une dépendance car le module sert directement le socket local /dev/socket/dnsproxyd . Le point de terminaison Binder pour la configuration du résolveur a été déplacé de netd vers le résolveur, ce qui signifie que le service système peut appeler directement le module de résolution sans passer par netd .
Le module DNS Resolver dépend de libc (Bionic) et lie statiquement ses dépendances ; aucune autre bibliothèque n'est requise.
mDNS. résolution locale
À partir de novembre 2021, le résolveur Android prend en charge la résolution mDNS .local, qui implémente les « requêtes DNS multidiffusion 5.1 One-Shot » dans la RFC 6762 pour envoyer aveuglément des requêtes DNS standard à 224.0.0.251:5353 ou [FF02::FB]:5353. La résolution mDNS est prise en charge de manière transparente en appelant getaddrinfo() avec un nom d'hôte se terminant par *.local .
La résolution mDNS .local augmente la fonctionnalité existante de getaddrinfo() pour obtenir les adresses. Si un appareil prend en charge la résolution mDNS .local, l'API getaddrinfo() envoie des requêtes mDNS à 224.0.0.251:5353 ou [FF02::FB]:5353 et renvoie les adresses locales. Si un appareil ne prend pas en charge la résolution mDNS .local, la méthode API getaddrinfo() envoie une requête DNS au serveur DNS.
Le code est en AOSP, situé dans packages/modules/DnsResolver . Les utilisateurs peuvent conserver leur conception mDNS actuelle pour obtenir les adresses, ou utiliser getaddrinfo() à la place. Le comportement de cette fonctionnalité est similaire à une requête DNS classique envoyée aux adresses de multidiffusion mDNS. Cette fonctionnalité n'a aucun impact sur la santé du système.
Les utilisateurs peuvent utiliser la commande adb shell ping6 HOSTNAME .local , où HOSTNAME est le nom d'hôte d'un périphérique cible sur le réseau local, par exemple adb shell ping6 ipad.local .
Les connexions VPN et de données mobiles sont exclues de la résolution .local.