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é ...?
systemdutilisation de Google DNS comme solution de rechange ...systemd-resolve heimdal.lan.se?Réponses:
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
Redémarrez ensuite 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
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.
la source
systemd-networkdlié à une autre chose serait de vérifier si leeth0ou leenXpériphérique a un*.networkfichier dans `/ lib / systemd / network /` voirinfo systemd-networkdetinfo systemd.networketinfo resolved.confJe 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:
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.Modifiez votre
/etc/nsswitch.conffichier en plaçant l'dnsentrée devant lesmdnsentrées.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.la source
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: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:
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.
la source
Pour moi, en exécutant un 18.04 récemment installé, j'ai apporté la première modification citée par @Civing:
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:
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.
la source