avahi: ping ne peut pas résoudre le nom d'hôte, mais nslookup peut
ping me dit qu'il ne peut pas résoudre un nom d'hôte ("ping: hôte inconnu domain.company.local") dans une URL, mais lorsque j'utilise Host ou nslookup sur le même ordinateur de la ligne de commande, les résolutions fonctionnent correctement (c'est-à-dire rapide et fiable).
Qu'est-ce qui peut causer cela?
Plus de tests: Firefox, wget et ping ont le même problème. Faire un ping sur l'adresse IP fonctionne.
Système d'exploitation: Linux (Ubuntu 13.04)
EDITMon /etc/resolv.conf lit:
nameserver 127.0.1.1
search domain.company.local
netstat rapports:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN -
donc quelque chose tourne sur ce port (nslookup indique également qu'il utilise 127.0.1.1 en tant que serveur DNS).
Il n'y a pas de /etc/*inetd.conf, donc je ne sais pas quelle application sert ce port.
Il semble que dnsmasq est utilisé:
/usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces
--pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1
--conf-file=/var/run/NetworkManager/dnsmasq.conf --cache-size=0 --proxy-dnssec
--enable-dbus=org.freedesktop.NetworkManager.dnsmasq
--conf-dir=/etc/NetworkManager/dnsmasq.d
Tous les fichiers et dossiers de configuration sont vides. Puisque nslookup dit qu'il utilise 127.0.1.1#53, je suppose que dnsmasq fonctionne même sans configuration. Mais comment sait-il quel DNS parent interroger?
EDIT2 Désactiver dnsmasq comme suggéré par harrymc n'a pas aidé. J'ai donc lancé strace ping qui m'a donné cette sortie étrange (juste les parties intéressantes):
open("/etc/Host.conf", O_RDONLY|O_CLOEXEC) = 4
read(4, "127.0.0.1\tlocalhost\n#127.0.1.1\ta"..., 4096) = 613
...
open("/lib/libnss_mdns4_minimal.so.2", O_RDONLY|O_CLOEXEC) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\f\0\0\0\0\0\0"..., 832) = 832
...
mmap(NULL, 2105560, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f7829b00000
...
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl(4, F_GETFD) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
connect(4, {sa_family=AF_FILE, path="/var/run/avahi-daemon/socket"}, 110) = 0
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fstat(4, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f782a4f8000
lseek(4, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(4, "RESOLVE-HOSTNAME-IPV4 domain.com"..., 44) = 44
read(4, "-15 Timeout reached\n", 4096) = 20
Donc ping cherche dans /etc/hosts ce qui a du sens. Ensuite, il charge mmap()s /lib/libnss_mdns4_minimal.so.2, ce qui a également un sens.
Mais alors il parle à avahi!?
Ce qui m'a conduit à cet article du forum: ping ne fait pas une demande DNS .
Mon /etc/nsswitch.conf contient également cette ligne:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
Si je ping une adresse de travail, je vois que le processus charge également /lib/libnss_mdns4_minimal.so.2 mais ensuite, il effectue une requête DNS via le port 53.
Donc, je suppose maintenant que /lib/libnss_mdns4_minimal.so.2 est en quelque sorte en train de remarquer que l'adresse IP se termine par .local et non par .com et que le [NOTFOUND=return] est déclenché.
Comment puis-je réparer ça?
Comme décrit en détail dans cet article de blog , vous devez éditer /etc/avahi/avahi-daemon.conf:
[server]
domain-name=.alocal
Cela lie le démon au domaine .alocal au lieu du .local par défaut.
et redémarrez le démon avec:
Sudo service avahi-daemon restart
Note du billet de blog:
Vous devrez peut-être vider le cache DNS, mDNS et le résolveur, ainsi que redémarrer vos navigateurs Web pour vider leur cache interne.
Après cela, ping et nslookup ont commencé à s’accorder.
Merci à harrymc de m'avoir mis sur la bonne voie.
Modifier /etc/nsswitch.conf et remplacer:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
par:
hosts: files dns
a travaillé pour moi.
Chose facile à faire: Editer /etc/default/avahi-daemon
Changer la ligne:
AVAHI_DAEMON_DETECT_LOCAL=1
à
AVAHI_DAEMON_DETECT_LOCAL=0
Redémarrez le avahi-daemon ou tuez-le.
Je n'aime pas Avahi et je n'utilise aucune de ses fonctionnalités. Si vous voulez vraiment désactiver avahi, modifiez /etc/init/avahi-daemon.conf, comme suit:
start on (never
and filesystem
and started dbus)
stop on stopping dbus
il semble que l'adresse locale ne soit pas accessible à Ubuntu.
une solution consiste à éditer /etc/nsswitch.conf et à changer cette ligne:
hosts: files mdns4_minimal [NOTFOUND=return] dns
par ça :
hosts: files dns
Si vous ne partagez pas de connexion avec d'autres périphériques ou machines virtuelles via votre ordinateur, vous pouvez désactiver Dnsmasq dans Network Manager.
Éditez /etc/NetworkManager/NetworkManager.conf et commentez la ligne (mettez un # devant elle):
dns=dnsmasq
Alors fais :
Sudo restart network-manager
Cela désactive le résolveur local.
Source: DNS dans Ubuntu 12.04 .
J'ai eu un cas intéressant avec les mêmes symptômes (ping, montage, etc. ne fonctionnant pas, mais hôte, Dig fonctionnant). Vérifiez les autorisations sur /etc/resolv.conf file. Dans mon cas, quelqu'un l'a changé et je n'avais pas le droit de le lire (bien que cat /etc/resolv.conf et la modification du fichier aient bien fonctionné).
En tout cas, strace montrait:
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
Et en conséquence, il essayait d'interroger localhost (127.0.0.1) au lieu d'une adresse IP du serveur de noms à partir du fichier resolv.conf:
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
Et tcpdump n’affichait aucun trafic DNS lors du ping. Tout fonctionne après un correctif d'autorisation:
# chmod 644 /etc/resolv.conf
# ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 111 Oct 3 09:54 /etc/resolv.conf
Un autre problème peut être les attributs étendus du fichier ou tout autre problème d'accès. Dans ce cas, supprimez simplement le fichier /etc/resolv.conf et recréez-le à partir de zéro.
Donc, je suppose maintenant que /lib/libnss_mdns4_minimal.so.2 remarque que l'adresse IP se termine par .local et non par .com, puis le [NOTFOUND = return] est déclenché.
Comment puis-je réparer ça?
Plutôt bien, mais les autres réponses sont excessives. La solution simple consiste à supprimer le bit effectivement déclenché, c’est-à-dire supprimer seulement [NOTFOUND=return].
Le supprimer signifie que si mdns4_minimal renvoie NOTFOUND, la prochaine entrée de la liste du résolveur est utilisée. C'est le comportement normal. [NOTFOUND=return] est une optimisation pour échouer plus rapidement sur des noms inconnus, mais suppose que tous les noms .local sont dans mDNS.
Une autre raison est le format de /etc/hosts. Assurez-vous qu'il n'y a pas d'espace entre IP et le nom d'hôte, utilisez plutôt une tabulation. Après avoir changé pour TAB, le nom d'hôte peut être résolu par ping.
127.0.0.1 test.local
^^^^^^^^ → Should be a TAB not multiple spaces.