La recherche DNS de domaine Ubuntu 18.04 .local ne fonctionne pas


18

J'utilise un Raspberry Pi 3 avec Ubuntu 18.04. Dans mon entreprise, nous avons un serveur DNS et quelques domaines avec ".local". Je sais que techniquement, ce n'est pas correct et il devrait plutôt être ".lan", car .local est réservé aux DNS multicast. Mais c'est comme ça et ça ne peut pas être facilement changé. Ainsi, sur ma machine Windows, je peux cingler et parcourir ces noms de domaine sans problème. Sur mon Ubuntu cependant je ne peux pas.

Je ne peux pas utiliser d'adresses IP car certains domaines se trouvent sur la même machine et le serveur Web IIS trie ce qui se passe où.

J'ai cherché et ça revient assez souvent:

Cependant, changer /etc/nsswitch.conf ne fait pas l'affaire pour moi. j'ai essayé

  • hôtes: fichiers mdns4_minimal [NOTFOUND = return] dns myhostname # default
  • hôtes: fichiers dns
  • hôtes: fichiers mdns4_minimal [NOTFOUND = continue] dns myhostname
  • hôtes: fichiers mdns4 [NOTFOUND = return] dns myhostname
  • hôtes: fichiers mdns4 [NOTFOUND = continue] dns myhostname
  • hôtes: fichiers dns mdsn4_minimal myhostname
  • hôtes: dns
  • quelques autres

Rien de tout cela n'a fonctionné. J'ai également essayé de redémarrer après un changement. J'ai essayé de dire à avahi que le nom de domaine = alocal dans /etc/avahi/avahi-daemon.conf, ne fonctionnait pas après le redémarrage du service, ne fonctionnait pas après le redémarrage. Après que cela ne fonctionne pas, j'ai essayé de désactiver complètement le service avahi-daemon.

sudo systemctl disable avahi-daemon

Après un redémarrage, j'ai essayé à nouveau quelques permutations dans /etc/nsswitch.conf, sans effet.

avec mes paramètres actuels dans les hôtes (fichiers DNS) j'obtiens cette réponse:

dig login.name.local # not the actual name

; <<>> Dig 9.11.3-1ubuntu1.1-Ubuntu <<>> login.name.local
;; global options: +cmd
;; Got answer:
;; WARNING .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33538
;; flags: qr rd ra; QUERY: 1, ANSWER:0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;login.name.local. 0     IN     A

;; Query time: 2msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Aug 23 10:51:50 CEST 2018
;; MSG SIZE  rcvd: 56

Cependant, lorsque j'invite Dig à interroger directement le serveur, j'obtiens la bonne réponse:

dig @dnsIP login.name.local
; <<>> Dig 9.11.3-1ubuntu1.1-Ubuntu <<>> login.name.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; WARNING .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57866
;; flags: qr aa rd ra; QUERY: 1, ANSWER:1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;login.name.local. 0     IN     A

;; ANSWER SECTION:
login.name.local. 3600 IN    A        serverIP

;; Query time: 2msec
;; SERVER: dnsIP#53(dnsIP)
;; WHEN: Thu Aug 23 10:51:50 CEST 2018
;; MSG SIZE  rcvd: 56

Cette version d'Ubuntu utilise netplan avec le gestionnaire de réseau. L'adresse IP DNS correcte est définitivement dans la liste. (en fait, c'est le DNS principal.) Le dnsIp est également le même que serverIP, mais cela ne devrait pas être un problème.

Ping ou connexion via un navigateur et cela ne fonctionne pas bien sûr. Aucun n'utilise la requête DNS.

Je ne sais pas quoi faire. Nous ne pouvons certainement pas passer à un autre nom de domaine. J'ai mis le nom du serveur dans / etc / hosts mais ce n'est qu'une solution temporaire.


changer le resolv.conf comme suggéré par jeremfg a fonctionné pour moi après avoir chassé ma queue autour de cela pendant plusieurs heures. Tnx.
user3529828

Réponses:


14

J'ai rencontré un problème très similaire (sinon exactement le même) sur Linux Mint 19 (Tara). J'ai réussi à le résoudre en combinant 3 informations différentes. Il semble que tout soit lié aux récents changements résolus par systemd.

Tout d'abord, oui, j'ai dû configurer /etc/nsswitch.conf comme vous l'avez fait et j'attendrais. Tant que le DNS passe avant le DNS, vous devriez être bon. J'ai terminé avec simplement:

hosts:          files dns myhostname

réf: /unix//a/457172/271210

Avant de passer à cette version de Mint, c'est la seule chose que je devais faire. Maintenant, j'ai également fini par apporter les deux autres modifications ci-dessous pour le faire fonctionner ...


Après cela, j'ai configuré mon domaine de recherche de sorte que la résolution de systemd fonctionne comme je le souhaitais. J'ai donc édité le fichier /etc/systemd/resolved.conf , le paramètre Domains dans la section [résoudre] . Dans mon cas, cela a fini par ressembler à:

[Resolve]
#DNS=
#FallbackDNS=
Domains=trilliant.local
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

réf: /ubuntu//a/1031271/872881

J'ai également changé la configuration d'avahi en quelque chose d'autre ("mdns" si je me souviens bien, mais cela n'a pas d'importance). Cela ne devrait cependant pas être exigé de ma compréhension. Ajout juste pour être complet.


Mais rien de tout cela n'a fonctionné jusqu'à ce que j'appelle ce qui suit:

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

réf: /ubuntu//a/938703/872881

Après avoir appelé cela, tout a commencé à fonctionner parfaitement et comme prévu!

Il est donc possible que je n'ai pas vraiment eu besoin de modifier le fichier /etc/systemd/resolved.conf mais j'ai conservé cette modification car cela avait du sens et me permet de taper uniquement le nom d'une machine, sans le FQDN complet, pour que la résolution DNS fonctionne .


Vous auriez pu mettre la dernière ligne au début et je suppose que vous obtiendriez plus de votes positifs en le faisant.
HongboZhu

@HongboZhu Je le ferais si je savais avec certitude que c'est le seul changement requis pour faire fonctionner les domaines locaux. Je suis sûr que vous devez toujours préférer le DNS au mdns dans la configuration du résolveur aussi. Je suppose que votre commentaire concerne la configuration du domaine au milieu? Si oui, oui, je suppose que je pourrais mettre cela à la fin comme un changement facultatif. Mais les deux autres pièces sont nécessaires à mon humble avis.
jeremfg

1
Sur ma nouvelle installation 18.04.2, il suffit de modifier le fonctionnement des "hôtes" sur nsswitch.conf.
Tomofumi

17

La réponse acceptée n'a pas résolu mon problème. Cela n'avait rien à voir avec avahi - je n'avais pas de service avahi installé. J'ai mon système configuré pour obtenir son IP ET ses paramètres de serveur DNS à partir de DHCP. Cependant, le DNS fourni par DHCP n'était pas vérifié pour les requêtes utilisant .local

Le vrai problème est qu'Ubuntu 18.4 a son resolv.conf sym-lié à un fichier stub qui pointe vers l'hôte local pour la résolution de nom. La résolution de nom DNS localhost signifie que le système refuse de vérifier le serveur DNS fourni pour les noms .local, estimant (incorrectement) que ces noms ne sont pas valides. Il s'agit de la configuration par défaut de /etc/resolv.conf:

ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jan 22 13:26 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

le contenu du fichier de raccord est (commentaires supprimés):

 cat /run/systemd/resolve/stub-resolv.conf
 .. removed comments..  
nameserver 127.0.0.53
    search reddog.microsoft.com

la "vraie" résolution conf a le paramètre DNS "correct" (à partir de dhcp):

cat /run/systemd/resolve/resolv.conf

..removed comments..
nameserver 10.168.200.250 # This is my server that can resolve .local
nameserver 208.67.220.220 # these are optional, fallback dns servers
nameserver 208.67.222.222
# Too many DNS servers configured, the following entries may be ignored.
nameserver 8.8.8.8
search reddog.microsoft.com

Pour que le système utilise votre résolveur DNS préféré au lieu de localhost, vous modifiez le lien symbolique pour pointer vers /run/systemd/resolve/resolv.conf au lieu de /run/systemd/resolve/stub-resolv.conf:

sudo rm -f /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Immédiatement après cela, la résolution de .local a commencé à fonctionner. pas besoin de redémarrer ou de redémarrer un service.


J'ai désinstallé Avahi, puis j'ai suivi vos étapes. Cela me l'a permis. Merci Monsieur. (Utilisation d'Ubuntu 18.04 Desktop).
José L. Patiño

Je vous remercie. C'était la réponse pour moi. Pourquoi cela ne "fonctionne-t-il" pas tout de suite?
adampski

quelle est la différence entre votre solution et la réponse acceptée? Pour les deux, on peut sauter les 2/3 premiers de la réponse - même c'est la même chose :-)
HongboZhu

C'est la seule réponse que j'ai vue jusqu'à présent qui reproduit le comportement dans les versions précédentes d'Ubuntu (et d'autres linux), c'est-à-dire que la liste des serveurs DNS est fournie par DHCP et la résolution d'adresse n'est jamais mise en cache localement.
Slicedpan

2

Pour moi, la façon de travailler pour Ubuntu 18.04 est:

Modifier la conf avahi:

sudo vim /etc/avahi/avahi-daemon.conf

et changez .local en .alocal:

[server]
domain-name=.alocal

puis ouvrez resolv.conf:

sudo vim /etc/systemd/resolved.conf

et commentez et modifiez les domaines:

[Resolve]
...
Domains=yourdomain.local
...

et enfin redémarrer les services:

sudo service systemd-resolved restart
sudo service avahi-daemon restart

Dans mon cas , je ne avais besoin de changer Domainsdans /etc/systemd/resolved.conf(et redémarrez le service).
tokosh

2
Cela ne l'a pas fait pour moi. toujours rien
FalcoGer

Même version d'Ubuntu. Utiliser openvpn. Cette solution fonctionne bien avec VPN sur de nombreuses machines de mon équipe.
razvanone

2

Ce qui a fonctionné pour moi a été d'ajouter le DNS local en tant que serveur de noms /etc/resolvconf/resolv.conf.d/head(comme décrit ici ).

  1. Installez le package resolvconf.

    sudo apt install resolvconf
    
  2. Modifiez /etc/resolvconf/resolv.conf.d/headet ajoutez les éléments suivants:

    nameserver 8.8.4.4  
    nameserver 8.8.8.8  
    
  3. Redémarrez le service resolvconf.

    sudo service resolvconf restart
    

Le correctif doit être permanent.


Le fichier principal contient un avertissement de ne pas modifier le fichier, car il est généré par resolvconf?
John Mee

@JohnMee Le headfichier est la source utilisée pour générer /run/resolvconf/resolv.conf. Cependant, je ne modifierais pas non plus ce fichier.
Melebius

0

Ma situation était similaire mais quelque peu différente: nous utilisons des noms de serveur comme myserversur Windows mais cela ne fonctionnait pas sur Ubuntu 16.04 et j'ai dû utiliser myserver.mycompany.local. Après la mise à niveau vers 18.04, j'ai eu le comportement suivant:

$ ping myserver.mycompany.local
ping: myserver.mycompany.local: Name or service not known

$ ping myserver
PING myserver.mycompany.local (192.168.x.y) 56(84) bytes of data.
64 bytes from myserver.mycompany.local (192.168.x.y): icmp_seq=1 ttl=62 time=3.05 ms
...

Je devais simplement remplacer myserver.mycompany.localpar myserverdans mes candidatures.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.