web-dev-qa-db-fra.com

Le serveur Ubuntu ne résout pas les noms d'hôte LAN

Peu coincé ici.

J'ai 2 machines qui ne peuvent pas résoudre les noms d'hôtes LAN, à moins qu'il y ait des entrées spécifiques dans/etc/hosts

Mais d'autres machines sur le LAN peuvent résoudre les noms d'hôte.

Mon LAN:

  • 1 routeur Cisco exécutant DD-WRT v24-sp2 avec DNSMasq activé. J'ai configuré cela avec les noms d'hôte et les adresses IP sur mon réseau local.
  • 1 x Kubuntu 12.10 (résout tous les noms d'hôte correctement tant qu'ils sont entrés dans DNSMasq sur le routeur)

  • 2 x NAS (résolvez également tous les noms correctement)

  • 1 x Ubuntu Server 12.04 (cela ne résout PAS les noms d'hôtes locaux à moins qu'ils ne soient entrés dans/etc/hosts)

  • 1 x XBMCLive (Dharma) (idem - ne résout que si les entrées sont dans/etc/hosts)

Comment faire en sorte que les 2 derniers utilisent les entrées DNSMasq du routeur? Chaque machine est configurée pour utiliser le routeur en tant que serveur de noms et toutes les unités résolvent les adresses externes correctement.

Merci.

quelques informations supplémentaires:

alors que sur le serveur, si je cingler un autre PC (wstation)

$ ping wstation
PING wstation.local.domain (x.x.x.x)

Si j'ajoute alors . Local

$ ping wstation.local
PING wstation.local.local.domain (x.x.x.x)

et directement

$ ping 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_req=1 ttl=64 time=0.387 ms
64 bytes from 10.0.0.4: icmp_req=2 ttl=64 time=0.316 ms
64 bytes from 10.0.0.4: icmp_req=3 ttl=64 time=0.312 ms
64 bytes from 10.0.0.4: icmp_req=4 ttl=64 time=0.280 ms
64 bytes from 10.0.0.4: icmp_req=5 ttl=64 time=0.322 ms
^C
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.280/0.323/0.387/0.038 ms
lanhostnamehostsdnsmasq
14
teracow

A propos de votre sortie actuelle

ping wstation
PING wstation.local.domain

Indique clairement que votre ordinateur est en train d’ajouter .local.domain à des requêtes autres que le nom de domaine complet. C'est quelque chose de mal configuré ou du moins de mauvais dans votre configuration. (sauf si vous utilisez réellement le suffixe .local.domain)

Résolution de noms et périodes

Une chose importante que beaucoup de gens ignorent, c'est qu'un nom complet doit toujours se terminer par un point (.). Si vous l'omettez, la machine essaiera de le résoudre dans le domaine de recherche local (par exemple, mydomain.tld). Donc, dans ce cas, une requête pour mypc.local deviendrait mypc.local.mydomain.tld. Pour éviter cela, interrogez avec la période.

Configuration du résolveur

La configuration du résolveur est d'une grande importance ici. Dans Ubuntu (et Debian), cela est configuré dans le fichier /etc/network/interfaces (en supposant que vous n’exécutez pas NetworkManager):

iface eth0 inet static
   address 192.168.3.3
   netmask 255.255.255.0
   gateway 192.168.3.1
   dns-nameservers 192.168.3.45 192.168.8.10
   dns-search foo.org bar.com                      # <-- these are the search domains

La résolution de noms sous Linux peut également être accomplie de différentes manières. Ce n’est pas seulement que le serveur DNS local est interrogé pour tout cela. Examinez votre fichier /etc/nsswitch.conf pour connaître la configuration de hosts de résolution:

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

Cela signifie que les fichiers sont d'abord testés (il s'agit du fichier /etc/hosts), puis mDNS et que, plus tard, le serveur DNS réel est interrogé. mDNS est implémenté sous Avahi sous Linux et s'appelle Bonjour sur Apple périphériques. Il utilise le suffixe .local par défaut et fonctionne via des messages broadcast. Un peu comme ARP fonctionne, mais ensuite pour DNS.

Tous ces systèmes peuvent être très déroutants, voire plus, lorsque vous utilisez .local dans une configuration DNS normale mélangée à des périphériques mDNS. Je suppose que c’est la raison pour laquelle vous ne comprenez pas pourquoi un périphérique fonctionne et que l’autre ne fonctionne pas: ils n’utilisent pas tous la même méthode de résolution.

Pour régler les choses

  • Évitez l’utilisation de .local à moins que vous ne souhaitiez vous fier entièrement à mDNS. Si j'ai bien compris votre question, vous voudriez que les choses soient configurées de manière centralisée. Mon approche est donc de l'éviter.
  • Configurez votre serveur DNS local (le périphérique DD-WRT dans votre cas) pour utiliser un nom de domaine spécial, par exemple. my.home. Pour Dnsmasq, il s'agit d'un paramètre unique, mais dans les configurations standard, il doit être configuré à la fois sur le serveur DNS et sur le serveur DHCP (comme annoncé par DHCP).
  • Configurez tous les ordinateurs pour qu'ils aient un nom d'hôte simple et unique. Ils l'utilisent dans leur demande de DHCP et cela est utilisé dans le Dnsmasq exécuté sur votre routeur pour les résoudre. Vous pouvez également les configurer manuellement pour ne pas avoir à recourir à DHCP.
  • Supprimez toute configuration restante dans /etc/resolv.conf au cas où vous la manipuleriez par le passé.

  • Configurez les ordinateurs de votre réseau pour utiliser my.home en tant que domaine de recherche local. Cela peut être fait via DHCP automatiquement ou si vous utilisez des adresses statiques via le fichier /etc/network/interfaces ou dans Network Manager:

    enter image description here

  • Désormais, la résolution de nom simple (ping hostname) ainsi que le nom complet (ping hostname.my.home) devraient fonctionner.
15
gertvdijk

Basé sur la réponse de gertvdijk, je viens de commenter la ligne dans nsswitch.conf

Sudo vim /etc/nsswitch.conf

.
.
.
hosts:          files dns # mdns4_minimal [NOTFOUND=return] dns
1
falnyr

J'ai eu des problèmes similaires avec un/etc/hosts contenant plusieurs espaces entre IP et nom d'hôte, utilisant plutôt un onglet. Après passage à 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.

voir aussi sur https://superuser.com/a/938366/467479

0
Thomas Lauria