Les requêtes DNS sont mises en cache de manière permanente, comment vider le cache DNS de manière fiable sur Android 7+ ?

COMMENT FONCTIONNE LA REQUÊTE DNS ET LA MISE EN CACHE ?

La plupart du temps, je trouve que les recherches DNS ultérieures sont toujours pour mymovies et plus jamais pour mymovies.home

NOTE : Juste pour être sûr, vérifiez que .home le domaine de recherche est défini :

~$ dumpsys netd | grep 'search domains:'
        search domains: home

Ce comportement est dû à Cache DNS négatif . La question ne porte pas explicitement sur Android mais plutôt sur la compréhension du fonctionnement du DNS. En bref :

• Lorsque vous tapez mymovies dans un navigateur web (en supposant que le navigateur n'a pas de cache DNS), le résolveur DNS d'Android vérifie la correspondance domaine <--> IP dans le cache local ( netd ) et /etc/hosts . Ensuite, il effectue une requête (pour A record ) à l'adresse IP du serveur DNS qu'il a reçue du DHCP (ou que vous avez définie manuellement), qui est dnsmasq dans votre cas. La norme est d'ajouter le suffixe en premier, donc mymovies.home est interrogé en premier. Voir les détails dans Comment Android OS fait-il la résolution de nom DNS ?
• dnsmasq vérifie la cartographie statique dans hosts y dnsmasq.conf fichier. Si aucun résultat n'est trouvé, il transmet la requête au serveur DNS en amont, quel que soit le paramètre configuré dans le fichier dnsmasq.conf o /etc/resolv.conf (ou tout autre mécanisme utilisé par le système) - disons 1.1.1.1 .
• Après avoir reçu une réponse positive ou négative, dnsmasq répond au client (téléphone Android) avec la valeur Time To Live (TTL).
• Ni l'un ni l'autre dnsmasq ni 1.1.1.1 est capable de résoudre mymovies.home porque .home n'est pas un niveau supérieur connu Nom de domaine (TLD) à tout serveur faisant autorité. Ainsi, un NXDOMAIN réponse ( "ce qui signifie que le nom de domaine interrogé n'existe pas dans le DNS" ) est renvoyé par Serveur racine (ou un serveur de mise en cache récursif intermédiaire). La réponse comprend un SOA record avec un TTL élevé (et SOA.MINIMUM champ ) valeur - disons 5 heures.
• dnsmasq met en cache le NXDOMAIN avec une expiration de 5 heures et transmet la même chose à Android.
• Le résolveur d'Android met en cache la même chose pendant 5 heures, mais ce temps peut être doublé dans certaines situations ; voir quelques explications. aquí . Aussi Combien de temps dure généralement la mise en cache négative du DNS ? .
• Le résolveur d'Android effectue une autre requête pour ( A RR de) mymovies qui réussit à dnsmasq et est retourné avec un TTL plus petit qui doit être 0 dans votre cas (voir l'option --local-ttl sur dnsmasq homme ).

Ainsi, le résolveur d'Android effectuera la prochaine requête pour mymovies.home après 5 heures, et pour mymovies après 0 seconde. Si vous voulez que mymovies.home doit être réessayé plus tôt, définissez un mappage statique, qui peut éventuellement être --address=/mymovies.home/ pour obtenir NXDOMAIN から dnsmasq sans TTL. Ou pour s'amuser, installez NXDOMAIN Redirection localement.

DÉPANNAGE DNS :

Je vais vous suggérer de simplifier votre installation. Vous n'avez pas nécessairement besoin de Wireshark, utilisez simplement --log-queries pour voir comment dnsmasq répond aux demandes de renseignements. Il est également possible de se débarrasser COMPLÈTEMENT du cache sur Android et le serveur DNS. Mais notez que vous pouvez toujours obtenir une réponse en cache d'un serveur récursif non itératif, comme si votre FAI interceptait les DNS.

J'ai essayé beaucoup de choses comme :

2. chrome://net-internals/#dns pour vider le cache de l'hôte et vider les sockets aussi

L'effacement du cache DNS du navigateur n'efface pas le cache du système d'exploitation (maintenu par le système d'exploitation). netd ), bien que les deux doivent être dédouanés. Essayez plutôt de tester avec un outil natif (comme dig o nslookup ) qui ne s'appuie pas sur le résolveur du système et ne fait pas de mise en cache lui-même. Sur Termux, par exemple :

~$ dig mymovies @<dnsmasq_IP>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; ANSWER SECTION:
mymovies.com.       0   IN  A   192.168.1.124

~$ dig mymovies.home @<dnsmasq_IP>
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; AUTHORITY SECTION:
.           10678   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2020010901 1800 900 604800 86400

Note NOERROR et le TTL ( 0 ) de réponse positive, tandis que NXDOMAIN réponse, TTL ( 10678 ) et SOA.MINIMUM ( 86400 ) de réponse négative.

Même après avoir redémarré le téléphone, les recherches DNS ont maintenant cessé d'être mises en cache et le téléphone essaie d'abord de se connecter à l'Internet. mymovies.home à chaque fois !

Cependant, lors de la requête suivante ( dig mymovies.home @<dnsmasq_IP> ), il n'y aurait pas de AUTHORITY SECTION . C'est parce que le RR de la SOA (la source du TTL négatif) n'est pas mis en cache (selon les règles de l'UE). Format RR ): "Les enregistrements SOA sont toujours distribués avec un TTL de zéro pour interdire la mise en cache". . Mais dnsmasq fait une mise en cache négative (voir l'option --no-negcache ), donc cette fois-ci il répond avec NXDOMAIN à partir de son propre cache, mais sans TTL .

C'est pourquoi, si vous effacez le cache sur Android, il continue à interroger mymovies ainsi que mymovies.home parce que les deux ne sont pas mis en cache sur Android en raison d'un TTL nul, à moins que vous ne redémarriez le système. dnsmasq o 10678 Les secondes passent. Pour vérifier, envoyez SIGUSR1 a dnsmasq et voir dans le journal le délai d'expiration par rapport à mymovies.home entrée du cache. Cependant, certains autres serveurs DNS peuvent se comporter différemment.

EFFACEMENT DU CACHE DNS :

4. ndc resolver clearnetdns wlan0

Cette commande efface le serveur DNS, pas le cache DNS. Voir Comment configurer correctement le DNS ? .

Existe-t-il un moyen fiable et reproductible de vider le cache DNS sous Android Nougat 7.0 ?

Oui, mais pas une méthode directe en ligne de commande. Du point de vue de la mise en cache négative, nous n'avons rien comme unbound-control flush_negative sur Android. ndc resolver flushnet <network_ID> war supprimé dans Android 7 mais flushDnsCache existe toujours. On ne peut pas non plus appeler _resolv_flush_cache_for_net à partir de la ligne de commande. Services network_management y netd_listener ne fournissent pas non plus une telle méthode.

• Cependant setResolverConfiguration (partie de netd service) États : "Vider le cache en cas de besoin (c'est-à-dire lorsque les serveurs ... changent)" . On peut aussi l'appeler en utilisant ndc :

~$ ndc resolver clearnetdns <network_ID> ~$ ndc resolver setnetdns <ID_réseau> home <dmsmasq_IP> ``` * network_ID peut être obtenu en utilisant dumpsys netd | grep Default

Le cache doit donc être effacé avec la réinitialisation du serveur DNS. De plus, l'envoi de messages de diffusion android.intent.action.CLEAR_DNS_CACHE ( flushVmDnsCache ) peut également être nécessaire pour effacer Cache du DVM (ou tuer les applications). Une explication simple peut être trouvée aquí .

Mais je ne suis pas sûr que cette méthode fonctionne sur toutes les versions d'Android.

• L'activation et la désactivation du Wi-Fi (ou le mode avion) doivent fonctionner comme suit network_ID est détruit et un nouveau est créé.
• Ou redémarrer le démon de mise en réseau / mise en cache ( netd ). Cela redémarre également les services dépendants (y compris zygote ), ce qui provoque un redémarrage en douceur et tue toutes les applications en cours :

~# setprop ctl.restart netd ```

• Il existe également un hack pour contourner / désactiver entièrement la mise en cache des DNS en utilisant la variable d'environnement ANDROID_DNS_MODE=local . Mais il désactive également les domaines de recherche ( .home dans votre cas).