résolu par systemd ne demande pas au serveur DNS le domaine local


12

Depuis la mise à niveau vers 17.04, je ne peux plus résoudre les adresses de mon réseau local (silvesternet.local). J'obtiens la réponse suivante:

$ systemd-resolve edgerouter
edgerouter: resolve call failed: No appropriate name servers or networks for name found

Dans le journal, il n'y a que des rapports de délais d'attente pour les transactions liées à cette recherche.

J'ai utilisé Wireshark pour renifler le trafic réseau, et il semble qu'il n'essaie même pas de rechercher le nom. Il n'y a aucun trafic DNS. La recherche d'un autre domaine externe fonctionne très bien.

De nombreux problèmes autour du même sujet mentionnent la modification de nsswitch.conf, mais cela ne semble rien résoudre. Mes paramètres actuels sont les suivants:

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

1
As-tu couru sudo apt update && sudo apt full-upgrade? Les bugs de l'image de sortie ont été corrigés ...
Zanna

si vous utilisez systemd-networkddes interfaces de configure, vous devrez peut - être ajouter UseDomains=truedans la [DHCP]section de vos .networkfichiers: wiki.archlinux.org/index.php/systemd-networkd#.5BDHCP.5D
Don Quichotte

En effet, proche du domaine. Il s'agissait en fait d'un bogue dans le micrologiciel edgerouter qui ne définissait pas le domaine dans la réponse DHCP.
Rob van der Most

Réponses:


10

Je crois que c'est par conception.

Ubuntu 17.04 est passé à la résolution de systemd pour la résolution de noms et il utilise uniquement LLMNR (recherche de nom de multidiffusion) pour la résolution de noms en une seule partie. Voir ce lien pour plus de détails: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html

Pour le raisonnement derrière cette décision, consultez la réponse de poettering dans ce rapport de bogue: https://github.com/systemd/systemd/issues/2514

UPD: ce problème peut être résolu en utilisant un domaine pour le réseau local. Si l'interface réseau est configurée (manuellement ou par DHCP) pour utiliser un domaine de recherche, alors systemd-resolution ajoutera ce domaine aux noms à étiquette unique, puis les recherchera via DNS unicast.

Évidemment, le serveur DNS local doit être reconfiguré pour reconnaître ces domaines. Dans le cas de dnsmasq qui lit des paires locales d'hôte à IP à partir de / etc / hosts, cela peut être accompli en ajoutant les instructions suivantes à dnsmasq.conf:

domain=mydomain.net
local=/mydomain.net/
expand-hosts

UPD2: Ou vous pouvez simplement revenir à dnsmasq comme décrit ici /ubuntu//a/911432/692094


Et une autre page de bogue avec quelques explications: github.com/systemd/systemd/issues/4821
ish-west

Le nom de domaine était le problème ici. Cela a également été causé par un bogue dans le micrologiciel edgerouter. L'option de nom de domaine de la configuration n'a pas été correctement stockée dans la configuration DHCP. Les clients n'ont donc pas obtenu de domaine à rechercher.
Rob van der Most

8

J'ai eu le même problème sur Ubuntu 18.04, qui utilise également la résolution de systemd pour DNS. Sa configuration par défaut ne résout pas les noms d'hôte à étiquette unique ou les noms d'hôte de domaine .local par DNS, mais par LLMNR ou mDNS respectivement.

Pour créer des noms d'hôte locaux en une seule partie ou des noms d'hôte de domaine .local résolus par DNS, j'ai activé le 3e des "Quatre modes de gestion de /etc/resolv.conf" décrits dans la page de manuel pour systemd-resolu.service :

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

Une réponse similaire a été donnée ici . Et encore une fois, pour le raisonnement derrière la valeur par défaut, voir la réponse de poettering dans ce rapport de bogue .


2

Ce qui a fonctionné pour moi après la mise à niveau vers 18.04 a été de configurer le fichier /etc/systemd/resolved.conf en changeant le paramètre Domains en domaine (local ou comme dans mon cas mydomain.local). J'ai également changé le paramètre DNS, mais il semblait que ce n'était pas pertinent, mais je le mentionne juste au cas où ce n'est pas vrai. Pour plus d'informations, rendez-vous sur https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html .

De plus, j'ai changé la configuration avahi (/etc/avahi/avahi-daemon.conf) pour changer le paramètre de domaine à l'intérieur de la section serveur de local (par défaut) à quelque chose d'autre comme certaines personnes l'ont souligné dans ce forum.

Avec les changements mentionnés, je peux atteindre les machines en utilisant des noms sans points, par exemple, en envoyant une requête ping à mon ordinateur, la machine est contactée avec succès. Cependant, si je lance un ping vers mycomputer.mydomain.local, cela ne fonctionne pas, le FQDN n'est pas résolu comme prévu.

En espérant que cela aide dans certains cas ou mène à une solution plus générale.


0

J'ai fait face à ce problème en raison d'une mauvaise configuration nsswitch.conf. Depuis la 12.04chaîne suivante a fonctionné comme prévu. Les noms d'hôtes sans domaine se résolvent avec succès.

Mais la nouvelle 17.04version (ainsi que la version 16.10) d'ubuntu avec l'ancien modèle de configuration du système nss ne fonctionne pas comme avant.

Version mal configurée de hosts, à partir des anciennes versions d'ubuntu: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

Version de travail réussie hosts, par exemple à partir du 17.04: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.