Pourquoi 127.0.0.1 dans resolv.conf poserait-il des problèmes de résolution DNS?
[mise à jour et mise à jour II: voir mes solutions délicates et appropriées à la fin de la question, sur la base d'une des réponses]
J'ai une recherche DNS extrêmement lente lorsque mon fichier resolv.conf inclut l'adresse IP 127.0.0.1; en fait, de nombreux noms ne sont pas résolus du tout car ils (très certainement) expirent.
J'ai trouvé une question avec ce qui ressemble à une réponse valide ici:
recherche DNS extrêmement lente
sauf que je peux voir que l'outil dnsmasq est en cours d'exécution pour la plage d'adresses IP 192.168.122.2 à 192.168.122.254. Cela ressemble aux adresses IP utilisées par VirtualBox et qemu, alors j'imagine que si j'éteins dnsmasq, l'accès à Internet à partir d'un système virtuel échouera!
Y aurait-il une autre raison à la lenteur et/ou au délai d'attente? (Notez que le problème est plus évident avec certains systèmes, tels que les images des utilisateurs sur tous les sites Web de stackoverflow, y compris askubuntu, lorsque le problème se produit.)
À ce stade, je supprime l'adresse IP du fichier resolv.conf et cela contourne le problème lorsque je navigue, mais je ne pense pas que ce soit la meilleure solution (et bien entendu, cette adresse IP est réinstallée à chaque redémarrage!). Je souhaite une solution plus permanente à ce problème, qui me permette toujours d’exécuter les systèmes virtuels comme prévu.
P.S. Je n'exécute pas le gestionnaire de réseau.
Contenu de/etc/network/interfaces
Notez que j'ai eu le problème avant d'ajouter la 2ème adresse IP sur eth1 (c'est-à-dire eth1: 0).
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth1
iface eth1 inet static
address 162.226.130.121
netmask 255.255.255.248
network 162.226.130.120
broadcast 162.226.130.127
gateway 162.226.130.126
auto eth1:0
iface eth1:0 inet static
name Local network
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254
# bridge for virtual box
auto br0
iface br0 inet static
address 192.168.2.1
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
bridge_ports eth3
bridge_stp off
bridge_maxwait 0
bridge_fd 0
Contenu du fichier /etc/resolv.conf (qui est toujours un lien souple comme prévu) après un démarrage:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search m2osw.com
nameserver 192.168.122.1
nameserver 206.13.31.12
nameserver 206.13.28.12
Mettre à jour:
Je n’écris pas moi-même une réponse car j’ai beaucoup utilisé une autre réponse ici pour résoudre mon problème, bien que ce ne soit vraiment pas ce que je voulais faire, c’est la solution la plus simple à ce stade. Le bogue référencé par l'auteur de resolvconf ci-dessous, trouvé ici:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/93372
indique clairement que si vous souhaitez utiliser bind9, vous obtiendrez l'espace de noms 127.0.0.1 dans votre fichier resolv.conf. Pas le choix. (RESOLVCONF = no ne semble rien faire, bien que je puisse avoir une surprise après un redémarrage que je ferai très bientôt!)
En remarque: si je pointe le lien symbolique /etc/resolvconf/resolv.conf.d/tail vers/dev/null (comme indiqué ci-dessous), j'obtiens un resolv.conf ressemblant à ceci:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
En d'autres termes, je reçois toujours le 127.0.0.1 qui est le coupable à ce stade. Mais aussi, je perds complètement les deux autres serveurs de noms, même s'ils sont clairement spécifiés dans mon interface eth1. Ceci étant dit, si je regarde dans le répertoire/run/resolvconf/interface /, je vois un fichier eth1.net et lo.named. Le lo.named est copié dans le resolv.conf, mais pas le eth1.net. Je ne sais pas comment ces fichiers sont créés, puis copiés dans resolv.conf, mais c'est le dynamisme utilisé par resolvconf ...
Quoi qu'il en soit, le bug contient deux solutions:
(1) Supprimez le lien symbolique /etc/resolv.conf et remplacez-le par un fichier brut contenant exactement ce que vous voulez. Cela fonctionnera peut-être pour vous, mais j’ai pensé qu’il serait préférable de conserver le fichier dynamique par défaut.
(2) Modifiez vos paramètres bind9 afin que BIND puisse répondre à ces demandes DNS locales. La chose intéressante avec cela est que les noms seront maintenant mis en cache sur votre ordinateur. Donc tout n'est pas mauvais. Ceci étant dit, l'ouverture de mon serveur de noms à tous les noms de domaine ne m'intéressait pas trop ... Mais cela fonctionne et je n'ai pas à détruire le fichier resolv.conf dynamique.
Juste au cas où, il y a un exemple d'installation pour que la liaison fonctionne:
options {
[...]
forwarders {
// Google DNSes
8.8.8.8;
8.8.4.4;
};
[...]
};
Mise à jour II:
D'accord! Le redémarrage a supprimé le fichier lo.named du répertoire/run/resolvconf/interface. Cela doit être parce que bind sait le créer si RESOLVCONF = yes, mais ne le supprime pas si RESOLVCONF = no. Cependant, un redémarrage s'en charge car le répertoire/run est un disque RAM.
Sans ce fichier, le fichier /etc/resolv.conf est configuré avec exactement ce à quoi je m'attendais, à savoir la liste des serveurs de noms telle que définie dans la définition de eth1 trouvée dans/etc/network/interface, comme indiqué précédemment.
Alors ... c'est un gros bazar parce qu'il y a beaucoup de facteurs et qu'un redémarrage est nécessaire!
1: Ajoutez les options dns-nameservers et dns-search à/etc/network/interfaces.
auto eth1
iface eth1 inet static
address 162.226.130.121
netmask 255.255.255.0
gateway 162.226.130.126
dns-nameservers 8.8.8.8 162.226.130.126
dns-search m2osw.com
2: Supprimez toutes les options dns- des fichiers de /etc/resolvconf/resolv.conf.d/. Ce résolv.conf inclut les options nameserver après que nameserver 127.0.0.1 indique que ce type de fichier est présent. Si /etc/resolvconf/resolv.conf.d/tail est un lien symbolique, faites-en un lien symbolique vers /dev/null.
3: down up eth1.
Sudo ifdown eth1
Sudo ifup eth1
4: Regardez dans /etc/resolv.conf. Est-ce que nameserver 127.0.0.1 est toujours présent et les réponses aux requêtes DNS sont-elles toujours en retard? Si c'est le cas, déterminez d'où vient la ligne nameserver 127.0.0.1. Quelque chose enregistre l'adresse d'écoute 127.0.0.1 sans démarrer un serveur de noms local à l'adresse 127.0.0.1. (i) Une possibilité est le package bind9. Si vous n'exécutez pas de serveur de noms BIND local, purgez le package bind9 (Sudo apt-get purge bind9). Si vous utilisez un serveur de noms BIND qui ne fournit pas de service de noms Internet général, éditez/etc/default/bind9 et définissez RESOLVCONF=no, puis redémarrez le serveur de noms. Voir: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/93372 (ii) Une autre possibilité est que vous disposiez de restes de dnsmasq ou d'un paquet similaire sur le système. Purger ce paquet. Purgez également network-manager puisque vous ne l'utilisez pas.
5: Redémarrez et voyez si les choses se sont améliorées, puis faites votre rapport ici.
L'utilisation d'un serveur DNS avec une adresse de bouclage (par exemple, 127.0.0.1) pose des problèmes:
Tous les autres serveurs DNS avec une priorité inférieure sont ignorés par resolvconfname__.
La priorité des serveurs DNS est définie par les interfaces réseau avec lesquelles le serveur DNS est défini.
Voir /etc/resolvconf/interface-order and man 5 interface-order.
Heureusement, il existe une variable d'environnement pour modifier ce comportement:
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS
Voir man 8 resolvconf
Si mis
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no
dans /etc/default/resolvconf et redémarrez le service resolvconfname__, tous les autres serveurs DNS s'afficheront dans /etc/resolv.conf.
Si vous définissez/etc/network/interfaces avec une déclaration IP statique, vous êtes également responsable de la déclaration des adresses de serveur de noms DNS. Je suggère:
auto eth1
iface eth1 inet static
address 162.226.130.121
netmask 255.255.255.0
gateway 162.226.130.126 #Isn't the gateway actually xx.1??
dns-nameservers 8.8.8.8 162.226.130.126 #or any others you prefer.
Je pense que vous pouvez ensuite laisser resolv.conf seul pour qu'il soit réécrit par le système, si nécessaire.