65 votes

Mauvais serveur de noms défini par resolvconf et NetworkManager

Mon serveur DNS est 192.168.1.152 .

Ce DNS est fourni aux clients par DHCP. Les clients Windows sur mon réseau local résolvent les noms correctement en utilisant ce DNS, mais ma VM Ubuntu ne le fait pas.

La VM est configurée avec un réseau en pont et reçoit correctement le serveur DNS, mais mes noms d'hôtes locaux ne sont pas résolus par nslookup ou les navigateurs.

Voici un nslookup d'un de mes domaines locaux :

# nslookup unraid.local
Server:     127.0.0.53
Address:    127.0.0.53#53

** server can't find unraid.local: SERVFAIL

Voici ce qu'il devrait résoudre en utilisant mon serveur DNS :

# nslookup unraid.local 192.168.1.152
Server:     192.168.1.152
Address:    192.168.1.152#53

Name:   unraid.local
Address: 192.168.1.152

/etc/resolv.conf a un mauvais serveur de noms :

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

J'ai lancé cette commande. Sous Serveurs DNS, confusément, elle spécifie le bon serveur (et ma passerelle par défaut).

root@ubuntu:~# systemd-resolve --status
Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (ens33)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.1.152
                      192.168.1.1

Je ne veux pas "coder en dur" l'adresse IP du serveur DNS dans un fichier de configuration, car je ne pourrai pas la résoudre si je change de réseau.

Comment puis-je obtenir que resolvconf et NetworkManager automatiquement définir l'IP du serveur DHCP dans /etc/resolv.conf ?

77voto

RBADS Points 772

Connu systemd bug .

Solution temporaire sans qu'il soit nécessaire de reconfigurer si l'IP du DNS change :

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

70voto

Leandro Noskoski Points 819

Essayez d'éditer /etc/systemd/resolved.conf en ajoutant le serveur DNS de votre choix :

changer ça :

[Resolve]
#DNS=

à celui-ci (mais utilisez celui que vous voulez - ceci est un exemple) :

[Resolve]
DNS=192.168.1.152

après cela, redémarrez le service :

service systemd-resolved restart

Et quand vous vérifiez le statut, vous devriez voir

$ systemd-resolve --status
Global
         DNS Servers: 192.168.1.152

      DNSSEC NTA: 10.in-addr.arpa
                  16.172.in-addr.arpa
                  168.192.in-addr.arpa
                  17.172.in-addr.arpa
                  18.172.in-addr.arpa
                  19.172.in-addr.arpa

17voto

Fabio Fumarola Points 279

J'ai finalement trouvé une solution à ce problème pour ubuntu 17.10. Par défaut, cette version d'Ubuntu utilise systemd-resolved qui, je l'espère, sera stable pour les prochaines versions.

Afin d'utiliser le dns personnalisé au lieu du cache local résolu par systemd, procédez comme suit :

  1. ajouter de nouveaux serveurs de noms. Modifiez le fichier dans /etc/systemd/resolved.conf comme sudoer. Ici, j'ai commenté l'entrée DNS et j'ai placé mon DNS. [Resolve] DNS=10.96.0.10 8.8.8.8 8.8.4.4

  2. annuler le lien symbolique actuel vers /etc/resolv.conf

  3. créer un nouveau lien symbolique sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

  4. redémarrer le service sudo service systemd-resolved restart

  5. redémarrer le gestionnaire de réseau sudo systemctl restart networking

Et maintenant, si vous cherchez un nom fourni par votre add dns, vous devriez voir l'enregistrement résolu. dig nexus.default.svc.cluster.mydomain

La dernière étape consiste à mettre à jour l'ordre de résolution en /etc/nsswitch.conf en plaçant le dns avant le mdns4_minimal.

hosts           files dns mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname

3voto

BobDodds Points 51

Votre /etc/resolv.conf n'est pas le problème. systemd-resolved n'est pas configuré par défaut, ce qui fait échouer toutes les recherches. N'hésitez pas à vous plaindre de Unconfigured vs A Reasonable Default.

Ajouter manuellement des serveurs de noms à systemd-resolved . (modification par le commentaire d'Olorin ci-dessous pour ajouter mkdir , chemin correct /etc no /lib (afin de survivre aux mises à jour du système)

sudo mkdir -p /etc/systemd/resolved.conf.d
sudo nano /etc/systemd/resolved.conf.d/00-my-dns-server-is.conf

Ajouter :

[Resolve]
Cache=yes
DNS=192.168.1.152

Alors...

sudo systemctl daemon-reload

systemd-resolved est intelligent, mais, non configuré comme il l'est, par les mainteneurs de paquets, il a l'air stupide parce que les mainteneurs de paquets ne croient pas en un défaut raisonnable. Nous pouvons y mettre 13 serveurs racine Internet, alias "djb way", ou 10 serveurs opennic : https://pastebin.com/JBfYVVtG ou les trois serveurs opennic les plus rapides, comme mesuré par namebench. Plus les serveurs de noms des FAI, bien sûr. Plus Google, bien sûr. systemd-resolved n'est pas le problème. C'est moi le problème.

2voto

Bánó Gábor Points 21

Sur mon système, j'ai trouvé un mauvais lien symbolique : /etc/resolv.conf est un lien symbolique qui pointe vers /run/systemd/resolve/stub-resolv.conf

Ce fichier ne contient qu'une seule ligne :

nameserver 127.0.0.53#53

Par conséquent, la consultation du DNS du réseau local était souvent absente.

Donc, à la place, j'ai changé /etc/reolv.conf pour pointer vers /run/systemd/resolve/resolv.conf

et fonctionne maintenant correctement.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X