Résolveur DNS

Le module DNS Resolver offre une protection des utilisateurs contre les attaques d'interception DNS et de mise à jour de la 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 de résolution 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 à /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 source 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 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ésolveur 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 "5.1 One-Shot DNS Queries" dans 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 dans 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é ressemble à une requête DNS normale 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.