Mon ordinateur portable fonctionne sous bionic, fonctionnait astucieusement et j’ai effectué une mise à niveau complète via apt il ya quelques semaines et tout fonctionne comme prévu. Toutefois, lorsque j’essaie de me connecter à mon serveur, le nom de domaine complet n’est pas résolu, je peux me connecter via IP, etc. J'ai lu pas mal de choses, j'ai dû rattraper mon retard sur les énormes changements survenus sous Linux depuis mon dernier travail avec Redhat Linux en 2003.
Nous avons donc maintenant le gestionnaire de réseau et systemd, ce sont de gros changements par rapport à l'ancienne façon de faire Unix et je peux voir les raisons de l'évolution qui s'est produite, ce qui rend difficile le dépannage si vous êtes un vieil homme Unix ;-) Le résolveur systemd peut être échangé contre dnsmasq et le gestionnaire de réseau a un plugin qui fonctionne avec dnsmasq, ok, obtenez tout cela sans problème. Ce que je ne peux pas comprendre, c’est pourquoi, d’origine, Ubuntu ne transmet pas correctement la recherche DNS à mon routeur, qui est en mesure de fournir des entrées DNS statiques pour certains services de mon réseau. Cela fonctionne parfaitement avec Windows et Macos.
Pour tenter de résoudre ce problème, cela ne fonctionnait pas correctement avec le résolveur systemd, je l'ai échangé contre dnsmasq, toujours pas de cigare: - /
L'ordinateur portable prend correctement une adresse IP via DHCP et le gestionnaire de réseau remplit correctement le fichier /etc/resolv.conf avec l'adresse IP des routeurs pour les DNS.
La résolution DNS normale sur Internet fonctionne correctement et si j'éteins l'entrée automatique du résolveur DNS fournie par le gestionnaire de réseau, /etc/resolv.conf n'a pas d'entrée et Internet dns rompt comme prévu. Cela prouve également que mon ordinateur portable transmet également les requêtes DNS qu'il ne peut pas résoudre localement.
Je suis complètement désemparé quant à ce qui ne va pas. Toute suggestion sur les liens possibles avec le gestionnaire de réseau et/ou Dnsmasq serait grandement appréciée. De même, si quelqu'un possède un lien vers une très bonne plongée technique sur le DNS Linux 2016/17, cela serait d'une grande aide.
J'ai résolu mon propre problème, je propose donc ma solution pour que d'autres puissent le trouver utile.
Je viens de lire un blog sur le dépannage du client DNS Linux problèmes et j'ai constaté que le fichier /etc/nsswitch.conf ne comportait pas les mêmes entrées que les miennes.
Le mien ressemblait à:
hôtes: fichiers mdns4_minimal [NOTFOUND = return] dns nomhôte
Et l'entrée de blog ressemblait à:
hôtes: fichiers DNS monhôte
En supprimant mdns4_minimal et [NOTFOUND = return] lorsque j'ai redémarré les services DNS/réseau, la résolution du nom de domaine complet a commencé à fonctionner. Alors j'ai décidé de rechercher ce que mdns4_minimal et [NOTFOUND = return] réellement faire. J'ai ensuite rencontré une autre question ici sur askubuntu.com qui explique la cause réelle de mon problème .
Il s’avère que si, comme moi, vous utilisez le domaine .local pour votre DNS interne, ce tld est également utilisé pour le DNS multidiffusion mDNS, pour des services comme Bonjour. Pour que les DNS fonctionnent correctement, vous devez les hiérarchiser par rapport à mdns pour que cela fonctionne.
J'ai maintenant rendu mon fichier /etc/nsswitch.conf à son état d'origine avec les modifications suivantes:
hôtes: fichiers dns [NOTFOUND = return] mdns4_minimal mdns4
Comme vous pouvez le constater, la priorité est maintenant donnée à DNS sur mdns4 et mon résolveur local interroge mon réseau DNS, ce qui renvoie le résultat attendu:
~ $ ping nas01.home.local
PING nas01.home.local (192.168.1.101) 56 (84) octets de données.
64 octets de nas01.home.local (192.168.1.101): icmp_seq = 1 ttl = 64 fois = 0,196 ms
64 octets de nas01.home.local (192.168.1.101): icmp_seq = 2 ttl = 64 fois = 0,279 ms
64 octets de nas01.home.local (192.168.1.101): icmp_seq = 3 ttl = 64 fois = 0,243 ms
Il est peu probable que la plupart des gens utilisent .local à la maison ou au laboratoire, mais j’ai toujours préféré l’utiliser, même dans les environnements d’entreprise, car il ne s’agit pas d’un tld sur Internet.