web-dev-qa-db-fra.com

Ubuntu 18.04. La recherche DNS du domaine 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 être ".lan" à la place, car .local est réservé aux DNS multicast. Mais c'est comme ça et ça ne peut pas être changé facilement. Donc, sur ma machine Windows, je peux cingler et naviguer sans problème vers ces noms de domaine. Sur mon Ubuntu cependant je ne peux pas.

Je ne peux pas utiliser d'IP, car certains domaines sont situés sur le même ordinateur et que le serveur Web IIS trie les problèmes et les acheminements.

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

Cependant, changer /etc/nsswitch.conf ne me convient pas. j'ai essayé

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

Aucun de ce qui a fonctionné. J'ai essayé de redémarrer après un changement aussi. 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 plus, 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) je reçois 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 je demande à Dig d'interroger directement le serveur, j'obtiens la réponse correcte:

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. La bonne adresse IP est définitivement dans la liste. (En fait, c'est le DNS principal.) De plus, le dnsIp est identique à serverIP, mais cela ne devrait pas être un problème.

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

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

networking18.04dnsdomain-server
9
FalcoGer

Je suis confronté à un problème très similaire (sinon identique) sous Linux Mint 19 (Tara). J'ai réussi à le résoudre en combinant 3 informations différentes. Tout semble être lié aux changements récents avec systemd-resolu.

Premièrement, oui, j’ai eu besoin de configurer /etc/nsswitch.conf comme vous le souhaitiez. Tant que dns vient avant mdns, vous devriez être bon. J'ai fini par simplement:

hosts:          files dns myhostname

ref: https://unix.stackexchange.com/a/457172/27121

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 afin que la résolution de systemd fonctionne comme je le voulais. J'ai donc édité le fichier /etc/systemd/resol.conf , les domaines paramètre dans la section [résoudre] . Dans mon cas, cela ressemblait à:

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

ref: https://askubuntu.com/a/1031271/872881

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

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

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

ref: https://askubuntu.com/a/938703/872881

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

Il est donc possible que je n’aie pas vraiment besoin de modifier le fichier /etc/systemd/resol.conf , mais j’ai gardé ce changement car il était logique et permet Pour que la résolution DNS fonctionne, il suffit de saisir le nom d'un ordinateur, sans le nom de domaine complet (FQDN) complet.

3
jeremfg

La réponse acceptée n'a pas résolu mon problème. Cela n'avait rien à voir avec avahi - je n'avais pas installé le service avahi. Mon système est configuré pour obtenir son adresse 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 que la résolution symv du résolv.conf d'Ubuntu 18.4 est liée à un fichier de raccord qui pointe vers l'hôte local pour la résolution du nom. La résolution de noms DNS Localhost signifie que le système refuse de rechercher les noms .local sur le serveur DNS fourni, estimant (à tort) que ces noms sont invalides. Ceci est 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 conf "résolution" réelle a le réglage "correct" dns (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 devez modifier le lien symbolique pour qu'il pointe 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.

8
OzPHB

Pour moi, la manière de travailler pour Ubuntu 18.04 est la suivante:

Modifier avahi conf:

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

et changez .local en .alocal:

[server]
domain-name=.alocal

ensuite, ouvrez resol.conf:

Sudo vim /etc/systemd/resolved.conf

et décommentez et éditez les domaines:

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

et enfin redémarrer les services:

Sudo service systemd-resolved restart
Sudo service avahi-daemon restart
2
Anton To

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. Éditez /etc/resolvconf/resolv.conf.d/head et ajoutez ce qui suit:

    nameserver 8.8.4.4  
nameserver 8.8.8.8

  3. Redémarrez le service resolvconf.

    Sudo service resolvconf restart

Le correctif devrait être permanent.

0
Kevin Stevens