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

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:

• https://smallbusiness.chron.com/resolving-local-ubuntu-38861.html
• Pourquoi aucun de mes serveurs locaux ne résout-il?
• Le serveur Ubuntu ne résout pas les noms d'hôtes LAN

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.

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 .

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.

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

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.

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.