Le module du résolveur DNS protège les utilisateurs contre les attaques d'interception et de mise à jour de la configuration DNS, et améliore les performances réseau pour les résolutions DNS. Le module contient le code qui implémente le résolveur de simulation DNS, qui traduit des noms tels que www.google.com en adresses IP telles que 2001:db8::1. Le résolveur DNS stub prend en charge les éléments d'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.
Modifications apportées dans Android 10
Sur les appareils équipés d'Android 9 ou version antérieure, le code du résolveur DNS est réparti entre Bionic et netd. Les recherches DNS sont centralisées dans le daemon netd pour permettre le 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 à /dev/socket/dnsproxyd au daemon netd, qui analyse la requête et appelle à nouveau getaddrinfo pour effectuer 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 partiellement 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 de Bionic continue d'exister pour des raisons de compatibilité des applications, mais n'est plus appelé par le système. Ces chemins de source sont affectés par le refactoring:
bionic/libc/dnssystem/netd/clientsystem/netd/server/dnssystem/netd/server/DnsProxyListenersystem/netd/server/ResolverControllersystem/netd/resolv
Format et dépendances
Le module de résolution DNS ("com.android.resolv") est fourni en tant que fichier APEX et est lié dynamiquement par netd. Toutefois, netd n'est pas une dépendance, car le module sert directement le socket local /dev/socket/dnsproxyd. Le point de terminaison de liaison 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 du résolveur DNS dépend de libc (Bionic) et associe de manière statique ses dépendances. Aucune autre bibliothèque n'est requise.
Résolution .local mDNS
À partir de novembre 2021, le résolveur Android prend en charge la résolution mDNS .local, qui implémente les "5.1 One-Shot multicast DNS Queries" de la RFC 6762 pour envoyer des requêtes DNS standards de manière aveugle à 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 étend la fonctionnalité existante de getaddrinfo() pour obtenir les adresses. Si un appareil est compatible avec la résolution .local mDNS, 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 n'est pas compatible avec la résolution mDNS .local, la méthode de l'API getaddrinfo() envoie une requête DNS au serveur DNS.
Le code se trouve dans AOSP, 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 semblable à une requête DNS standard envoyée aux adresses multicast mDNS. Cette fonctionnalité n'a aucun impact sur l'état du système.
Les utilisateurs peuvent utiliser la commande adb shell ping6 HOSTNAME.local, où HOSTNAME est le nom d'hôte d'un appareil cible sur le LAN, par exemple adb shell ping6 ipad.local.
Les connexions VPN et de données mobiles sont exclues de la résolution .local.