Pourquoi résolu par systemd n'utilise pas mon serveur DNS local?

J'utilise un serveur BIND9 local pour héberger certains enregistrements DNS locaux. Lorsque j'essaie de chercher un nom de domaine local, je ne le trouve pas si je ne dis pas explicitement à dig d'utiliser mon serveur BIND9 local.

user@heimdal:~$ dig +short heimdal.lan.se
user@heimdal:~$ dig +short @192.168.1.7 heimdal.lan.se
192.168.1.2

Ubuntu 17.04 et résolu par systemd sont utilisés. Ceci est le contenu de mon / etc / résolu

# 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

Et la sortie de systemd-resolver --status

Global
         DNS Servers: 192.168.1.7
                      192.168.1.1
          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

La section Serveurs DNS semble avoir correctement configuré 192.168.1.7 comme serveur DNS principal (mon instance BIND9 locale). Je ne comprends pas pourquoi il n'est pas utilisé ...?

Ainsi, la modification de mon interface filaire eth0 à gérer a résolu ce problème pour moi.

Changer ifupdown en managed = true dans /etc/NetworkManager/NetworkManager.conf

[ifupdown]
managed=true

Redémarrez ensuite NetworkManager

sudo systemctl restart NetworkManager

Après cela, cela fonctionne parfaitement ..

Ce n'était pas 100%. J'ai également appliqué ces modifications pour essayer de tuer le résolveur

sudo service resolvconf disable-updates
sudo update-rc.d resolvconf disable
sudo service resolvconf stop

Un grand merci à ce billet de blog concernant le sujet: https://ohthehugemanatee.org/blog/2018/01/25/my-war-on-systemd-resolved/

Permet de prier pour que cela fonctionne .. Toute cette affaire de résolution de problèmes est tout simplement laide.

Je suppose que votre systemd-resolvedservice est configuré correctement, mais il ne voit jamais la demande. Le .localdomaine est traité spécialement par les systèmes exécutant mDNS . avahi-daemon, qui fournit des services mDNS / DNS-SD (alias "Bonjour" sur les produits Apple) peut être configuré pour avoir la priorité sur DNS pendant la résolution de nom; il semble qu'Ubuntu le fasse.

Vous pouvez choisir parmi quelques options:

1. Renommez votre .localdomaine en quelque chose de différent (éventuellement .internalou .lan). Cela peut être le plus facile à faire dans la pratique, car il vous suffit de modifier quelques éléments sur votre serveur DNS, et cela fonctionne mieux avec Avahi. Je recommanderais cette méthode.

2. Modifiez votre /etc/nsswitch.conffichier en plaçant l' dnsentrée devant les mdnsentrées.

3. Modifier la configuration d' Avahi pour changer le domaine mDNS de .localquelque chose d'autre en modifiant /etc/avahi/avahi-daemon.confet en changeant (ou en ajoutant) domain-name=.something(situé dans la [server]section). Vous devrez le faire sur tous les ordinateurs qui utilisent mDNS pour qu'ils fonctionnent toujours ensemble.

Semble que ce serait mieux en tant que commentaire, mais pas assez de réputation ....

La réponse de Civing correspondait le plus à ce que je voulais.

J'ai également dû ajouter dns=noneà la [main]section de /etc/NetworkManager/NetworkManager.conf, donc cela ressemble à ceci:

[main]
plugins=ifupdown,keyfile
dns=none

Je viens de passer à xubuntu 18.04, à partir de 14.04, et j'ai un LAN plus ancien que cela, avec de nombreux petits ajustements accumulés au fil des ans. Je veux donc que mon DNS fasse ce que je veux (oui, j'ai acheté de nombreux exemplaires du livre de Cricket Lius au fil des ans, à commencer par la deuxième édition).

En passant, j'avais précédemment ajouté les informations de résolution DNS que je veux voir au fichier /etc/resolvconf/resolv.conf.d/head.

En un mot, une fois que j'avais un /etc/resolv.conf de travail, en tant que root:

cat /etc/resolv.conf >> /etc/resolvconf/resolv.conf.d/head

Mais maintenant, je modifie juste /etc/resolv.conf directement, et il reste en place. Les visiteurs de mon LAN, qui utilisent systemd / resolvconf, sont SOOL. Ils n'existent pas.

La lecture a man 8 resolvconfaidé. Beaucoup. Je n'ai pas suivi les instructions pour mettre les choses où le programme ifup pouvait les trouver. Principalement parce qu'il y a toute une superstructure dans l'interface graphique qui était déjà ignorée par tout ce qui a été fait pendant la mise à niveau. Cela semble être un problème plus important (WTF, Ubuntu?).

Donc, c'est énormément, et il y a toujours le problème que ce que j'avais (il y a longtemps) entré dans l'interface graphique du panneau de contrôle réseau n'était pas obéi par le système nouvellement mis à niveau, mais c'est une question totalement différente, une fois que j'ai compris comment demande-le.

Pour moi, en exécutant un 18.04 récemment installé, j'ai apporté la première modification citée par @Civing:

[ifupdown]
managed=true

puis, notant que /etc/resolv.conf pointait toujours stub-resolv.conf et qu'un resolv.conf raisonnable avec le serveur DNS LAN approprié était en cours de génération, a changé le lien symbolique:

/etc/resolv.conf -> /run/systemd/resolve/resolv.conf

puis local tous les noms d'hôtes résolus via ping.

Il reste à voir combien de temps cela continuera de fonctionner.

Lors de la première installation, la configuration du réseau sans fil a échoué et je ne peux m'empêcher de me demander si l'installation a laissé /etc/resolv.conf dans cet état initial.

Donc, une suggestion est de regarder ce que génère la résolution; vous avez peut-être déjà une base de travail.