9 votes

Comment Android effectue-t-il la résolution de noms DNS ?

Je suis en train d'apprendre comment Windows effectue la résolution des noms et j'ai besoin de savoir comment Android le fait pour qu'une application fonctionne sur mon ordinateur portable Windows et depuis mon téléphone Android.

En m'inspirant d'un post sur superuser.com, la méthode de résolution normale sur Windows est la suivante:

  1. Le client vérifie si le nom interrogé est le sien.
  2. Le client recherche ensuite un fichier Hosts local, une liste d'adresses IP et de noms stockée sur l'ordinateur local.
  3. Les serveurs du système de noms de domaine (DNS) sont interrogés.
  4. Si le nom n'est toujours pas résolu, la séquence de résolution des noms NetBIOS est utilisée en tant que solution de secours. Cet ordre peut être modifié en configurant le type de nœud NetBIOS du client.

J'utilise dnsmasq pour fournir une résolution DNS locale afin de pouvoir mapper mes propres noms d'hôtes fictifs à des adresses IP locales du réseau local. Cela me permet également de voir, dans le fichier journal de dnsmasq, la requête DNS de l'appareil vers le serveur DNS. Lorsque j'ai testé le site web depuis mon téléphone, j'aurais juré qu'en utilisant l'adresse URL http://monsite dans un navigateur Chrome sur le téléphone, le site web se chargeait et le journal de dnsmasq montrait exactement ce nom non qualifié - monsite - se résolvant vers l'adresse IP locale souhaitée du serveur web.

Cependant, cela remonte à il y a quelques jours, maintenant le journal de dnsmasq montre toujours que le suffixe DNS du serveur DHCP [home] a été ajouté. Donc, je vois monsite.home dans le journal de dnsmasq même si j'ai utilisé l'adresse URL http://monsite dans le navigateur Chrome du téléphone. Je n'ai rien changé avec le téléphone. Il est toujours configuré pour obtenir son adresse IP via DHCP, en pratique elle ne change jamais.

Donc, mes questions sont les suivantes:

  1. Comment le système d'exploitation Android résout-il les noms de domaine en adresses IP - quels sont les éléments qu'il essaie et dans quel ordre?
  2. Des retours sur la raison pour laquelle Android semblait résoudre le nom d'hôte non qualifié dans mon navigateur initialement sans qu'aucun suffixe DNS ne soit ajouté. Mais maintenant le suffixe [home] est toujours ajouté comme indiqué dans le fichier journal de dnsmasq.

Mise à jour 1

Après quelques tests supplémentaires, j'ai de nouveau vu le scénario où la page web http://mesfilms se charge depuis le téléphone Android mais le journal de dnsmasq semble montrer que la résolution du nom se produit sur un nom de domaine non qualifié (nom d'hôte simple: mesfilms).

Les x sont mon adresse IP publique de routeur censurée.

Est-ce que quelqu'un peut expliquer ce que dnsmasq fait ici?

À partir de 02:07:22, il semble initialement tenter de résoudre le nom mesfilms.home. Cela a du sens car l'IP du téléphone est allouée de manière dynamique par le serveur DHCP et je peux voir sur mon ordinateur portable que le serveur DHCP envoie le suffixe DNS [home] en tant que suffixe DNS spécifique à la connexion, donc il doit faire la même chose pour le téléphone, je suppose?

La raison pour laquelle cela échoue ici est que je n'ai pas d'entrée pour mesfilms.home dans dnsmasq.conf - je l'ai commentée. J'AI une entrée d'adresse pour mesfilms dans dnsmasq.conf et c'est pourquoi il peut résoudre mesfilms en une adresse IP.
Est-ce une différence de résolution de noms sur Android par rapport à Windows - que finalement le système d'exploitation Android ESSAYERA de résoudre un nom de domaine non qualifié (nom d'hôte simple) en une adresse IP?

13voto

Irfan Latif Points 16863

Comment les requêtes DNS effectuées par un programme sont résolues n'est pas spécifique à un OS, mais dépend de la bibliothèque de résolution que le programme utilise. Les résolveurs DNS ont traditionnellement fait partie de la bibliothèque C standard de l'OS, par exemple Bionic sur Android, libcmt sur Windows, glibc, musl, dietlibc, uClibc et autres sur Linux. Toutes les bibliothèques C n'utilisent pas la même approche pour résoudre les noms d'hôte/de domaine. Alors que glibc et similaires proposent des mécanismes complexes mais hautement configurables comme le Name Service Switch, d'autres se contentent simplement de hosts et de requêtes DNS vers le serveur de noms amont tel que configuré dans /etc/resolv.conf. Le résolveur d'Android (1, 2) consulte le cache, hosts et le DNS :

"Les recherches DNS sont centralisées dans le démon netd pour permettre la mise en cache au niveau 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 vers le démon netd, qui analyse la demande et appelle de nouveau getaddrinfo pour effectuer des recherches DNS, puis met en cache les résultats pour que d'autres applications puissent les utiliser."

L'adresse du serveur DNS est soit reçue via le contexte PDP sur les données mobiles, soit via le DHCP sur le Wi-Fi (éventuellement également définie manuellement), ou la valeur codée en dur 8.8.8.8 est utilisée. Depuis Android 9, il est également possible de configurer le DNS privé (DNS sur TLS) dans les paramètres. Il est également possible de définir le DNS et le nom de domaine en utilisant la commande ndc resolver setnetdns. Voir plus de détails dans Comment configurer correctement le DNS ?.

Le journal de dnsmasq montre toujours que le suffixe de DNS du serveur DHCP [home] a été ajouté

Le suffixe .home est fourni par votre serveur DHCP (routeur ?) à Android dans le cadre de la demande DHCP (code 15). Le client DHCP d'Android demande au serveur l'option 6 (serveur de noms de domaine) et l'option 15 (nom de domaine), qui sont ensuite transmises à la bibliothèque C (_resolv_set_nameservers_for_net) via DnsManager, NetworkManagementService et netd.

Sous Linux, le client DHCP (par ex. dhcpcd) modifie lui-même resolv.conf ou utilise un programme comme resolvconf qui est dédié à la gestion de resolv.conf. Le mot-clé nameserver définit le serveur DNS et search définit la liste de recherche pour la recherche de noms d'hôte (option DHCP 119 ou 15). Android utilise des valeurs par défaut codées en dur dans différents fichiers d'en-tête autres que celles reçues du DHCP ou définies manuellement.

Le client DHCP de Windows et le résolveur DNS prennent en charge l'option 15. Des configurations supplémentaires honorées par le service Client DNS (dnscache) et la bibliothèque peuvent être effectuées via les Connexions réseau ou l'Éditeur de stratégie de groupe ou l'Éditeur du Registre.

Est-ce une différence de résolution de noms sur Android par rapport à Windows - qu'éventuellement Android OS ESSAYERA de résoudre un nom de domaine non qualifié (nom d'hôte nu) en une adresse IP ?

D'après ce que j'ai vu, il s'agit presque du comportement standard pour les bibliothèques libc Linux. Le code de résolution DNS d'Android est également basé sur NetBSD - un autre système d'exploitation de type Linux. Un nom non qualifié d'une seule étiquette est d'abord essayé avec le suffixe DNS ajouté, puis essayé sans suffixe 4 fois (voir "options attempts:n" pour resolv.conf). Pour un nom à plusieurs étiquettes, l'ordre est inversé tandis qu'un FQDN (avec un point . final) n'est jamais essayé avec le suffixe. Sur Windows, vous pouvez ajouter un point à un nom non qualifié pour qu'il soit traité comme un FQDN. Il est possible de le définir comme comportement par défaut en ajoutant un point (.) à "Suffixe DNS pour cette connexion". Voir aussi pour les Requêtes de noms multietiquette.

Je suis en train d'apprendre comment Windows effectue la résolution de noms et j'ai besoin de savoir comment Android le fait

Comme indiqué au début, la résolution de noms pourrait ne pas être persistante dans tout l'OS. Sur Android, par exemple, Firefox ou Chrome dépendront du résolveur Bionic tandis que certains busybox ping (ou même certaines bibliothèques natives incluses avec des applications GUI) essayeront de lire resolv.conf et d'effectuer des requêtes DNS directement.
Aussi les outils de dépannage réseau comme ping et getent reposent sur les bibliothèques de résolution internes de l'OS comme NSS, tandis que les outils de diagnostic DNS comme nslookup, dig et host agissent comme des clients DNS indépendants - ils ne lisent pas le fichier hosts et peuvent ne pas respecter entièrement resolv.conf. dig fournit des arguments en ligne de commande pour (ne pas) utiliser les options définies dans resolv.conf, et de même Windows nslookup a son propre résolveur intégré.

Donc même sur le même OS, vous ne pouvez pas vous attendre au même comportement de résolution DNS en utilisant différents programmes GUI/CLI car ils pourraient utiliser différentes libc et/ou résolveurs différents et/ou configurations différentes.


CONNEXES :

1 votes

Irfan.. merci beaucoup pour cette réponse détaillée. Maintenant je peux voir comment les recherches DNS sont influencées par de nombreux facteurs. Il est intéressant de noter que Windows ne fera pas de recherche DNS sur un nom d'hôte brut mais qu'Android le fera en raison du code résolveur DNS différent. Cheers.

1voto

ADPascuas Points 11

Est-ce que quelqu'un peut expliquer ce que dnsmasq fait ici?

  • query[A] = demande de résolution pour IPv4
  • From: évidemment la source, comme vous l'avez déjà indiqué, l'adresse publique de votre routeur.
  • forwarded to: est l'URL vers les serveurs DNS que vous avez configurés pour ce type d'URL, au cas où il n'y aurait pas de configuration, les serveurs DNS par défaut ou votre passerelle sont utilisés.
  • reply: le serveur DNS n'est pas capable de résoudre l'hôte car ce domaine n'existe pas (mymovies.home) et délivre donc "NXDOMAIN" comme réponse.
  • 192.168.1.124 est l'IP que vous avez configurée statiquement pour mymovies

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X