16.10 ne parviennent pas à résoudre le DNS


34

Après avoir mis à niveau mon installation de 16.04 vers 16.10, j'ai des problèmes avec DNS.

Tout d'abord, j'ai eu quelques problèmes de connexion au WiFi alors que cela fonctionnait sur Ethernet. Maintenant, il semble que le WiFi fonctionne également. Je ne sais pas pourquoi, et si cela a un quelconque rapport avec le problème auquel je fais face maintenant:

Lors de la connexion à un hôte VPN avec Cisco Anyconnect VPN , une ligne est ajoutée dans '/etc/resolv.conf' . Je comprends que Ubuntu utilise maintenant systemd-resol , et la page de manuel indique qu’il existe trois modes de gestion de /etc/resolv.conf différents. Mon /etc/resolv.conf n’est pas un lien symbolique et ne répertorie pas 127.0.0.53 en tant que serveur DNS. Par conséquent, pour autant que je sache, systemd-resol devrait "le lire pour les données de configuration DNS". Cependant, il ne semble pas s'en soucier.

creuser

La chose étrange (pour moi) est que dig host.customer.tldrenvoie une bonne réponse avec une SECTION DE RÉPONSE indiquant l'adresse IP de l'hôte demandé, et fait référence au serveur DNS ajouté à /etc/resolv.conf par le client VPN en tant que SERVEUR. Lorsque la connexion VPN est désactivée, je ne reçois aucune réponse. Ie dig lit /etc/resolv.conf .

ping

Le navigateur, de l’autre côté, n’a pas accès à /etc/resolv.conf et n’est pas en mesure de résoudre le nom d’hôte. Soit dit en passant, ping / curl non plus.

nmcli

J'ai trouvé un article connexe et j'ai essayé de courir

nmcli device show <interfacename> | grep IP4.DNS

mais il ne répertorie pas de DNS pour le périphérique cscotun0. Cependant, nmcli répertorie mon serveur DHCP (mon routeur) en tant qu'hôte IP4.DNS pour mes connexions eth / wlan. Utiliser dig @192.168.0.1 xxxpour tout domaine public fonctionne bien.

configuration

Il existe d'autres serveurs DNS répertoriés dans mon /run/systemd/resolve/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:4860:4860::8844

Ceux-ci ne sont pas servis par mon serveur DHCP. le fichier /etc/systemd/resolved.conf contient uniquement des lignes commentées, à l'exception de l'en-tête de section:

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

La page de manuel de resol.conf indique que

DNS = Liste d'adresses IPv4 et IPv6 séparées par des espaces à utiliser comme serveurs DNS système. ... Pour des raisons de compatibilité, si ce paramètre n'est pas spécifié, les serveurs DNS répertoriés dans /etc/resolv.conf sont utilisés à la place, si ce fichier existe et si des serveurs y sont configurés. Ce paramètre est défini par défaut sur la liste vide.

FallbackDNS = Liste d'adresses IPv4 et IPv6 séparées par des espaces à utiliser comme serveurs DNS de secours. Tous les serveurs DNS par lien obtenus à partir de systemd-networkd.service (8) ont priorité sur ce paramètre, comme tous les serveurs définis via DNS = ci-dessus ou /etc/resolv.conf. Ce paramètre n'est donc utilisé que si aucune autre information de serveur DNS n'est connue. Si cette option n'est pas donnée, une liste compilée de serveurs DNS est utilisée.

On dirait que la solution de repli aboutit dans /run/systemd/resolve/resolv.conf dans mon cas.

EDIT: Je ne savais pas quel était le problème et, pour être honnête, je ne sais toujours pas comment cela fonctionne, mais au moins, il s’est avéré que la solution dans mon cas était de désactiver le systemd-resolvedservice. Je pensais que ce service était nécessaire, que c'était le composant qui fournissait le service DNS à toutes les applications locales, mais apparemment, il y a autre chose qui fait ce travail.


Avez-vous un problème avec DNS si vous n'utilisez pas le VPN?
Mark Stosberg

Avez-vous essayé cette solution du 16.04 qui pourrait s’appliquer pour les problèmes AnyConnect ?
Mark Stosberg

3
Je voulais juste noter que je rencontre exactement les mêmes problèmes avec Anyconnect le 16.10. Connecter plusieurs fois au service VPN semble résoudre ce problème temporairement, mais à un moment donné, le DNS ne fonctionne plus.
Jmartinez

2
J'ai des problèmes de DNS similaires résolus qui n'étaient pas présents avec 16.04. Ma suggestion est de commencer par supprimer (sauvegarde) /etc/resolv.conf; désinstaller le paquet resolvconf; redémarrer; et utilisez dig, systemd-resolution avec et sans VPN pour voir ce qui fonctionne ou non.
philcolbourn

Réponses:


15

J'ai rencontré des problèmes similaires, par exemple avec l'ajout d'un dongle wifi supplémentaire. D'abord, j'ai désactivé dnsmasq dans networkmanager comme décrit ci-dessus et j'ai arrêté dnsmasq (service dnsmasq stop)

J'ai remarqué que lors de la résolution d'une panne lors de ma connexion VPN, la table de routage est légèrement différente (sortie de la commande route). Le nom de la passerelle est DD-WRT dans le cas où cela ne fonctionne pas et simplement "passerelle" quand cela fonctionne. La sortie de cela n'a pas changé:

nmcli device show wlp1s0 | grep IP4.DNS

Il a continué à montrer mon routeur IP. Une solution de contournement pour le faire fonctionner pendant un moment consiste à redémarrer systemd-resolvd:

sudo service systemd-resolved restart

Puisque dnsmasq est hors de l’équation, c’est soit systemd-resolvd qui est la cause du problème, soit tout ce qui change la table de routage.

C'est donc la seule différence que je vois:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    601    0        0 

qui fonctionne. Et ceci quand ça ne marche PAS:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         DD-WRT          0.0.0.0         UG    601    0        0 wlp1s0

Et la même différence de nom sur la ligne VPN:

vpn-dns.name gateway         255.255.255.255 UGH   0      0        0 wlp1s0

Qui sait ce qui peut influencer la table de routage? Ce serait bien si nous pouvions l'identifier afin qu'un rapport de bogue puisse être déposé. Je commence à être sérieusement malade et fatigué de poursuivre tous ces bugs, mais j'aimerais les réparer afin que les futurs utilisateurs et nous-mêmes soyons heureux :).

[mise à jour] Il semble que l'arrêt de systemd-resol puisse résoudre ce problème et ne pas avoir d'impact négatif sur d'autres éléments. Vous pouvez essayer cela et le laisser savoir si ça casse des choses. J'ai vu lors de l'exécution de systemd-resolvd dans le débogage quand il s'est cassé:

Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *

Pour désactiver:

sudo systemctl disable systemd-resolved.service

J'ai mis à jour le rapport Ubuntu avec des suggestions. [/ update] Ajouter: Note: le rapport de bogue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 a un correctif pour 17.04 pour certains problèmes. Veuillez vérifier le rapport de bogue et si possible tester le correctif. Merci!

[mise à jour]

Veuillez vérifier le rapport de bogue mentionné ci-dessus, le problème semble être résolu pour 17.10 et avec une simple commande, la fuite DNS peut également être désactivée.

[/mise à jour]


Merci pour votre rapport détaillé! Je vois des changements différents dans la table de routage par rapport à vous - mon VPN semble ajouter de nombreux itinéraires, de manière dynamique au fur et à mesure de leur utilisation, je suppose. Cependant, la désactivation de systemd-resolu a très bien fonctionné pour mon problème également!
Aweibell

Je pense que finalement le nom dans la table de routage importait peu, c'était résolution résolue par systemd qui gâchait la résolution DNS d'une manière ou d'une autre. J'ai également dû désactiver le service Dnsmasq pour l'empêcher de démarrer, mais tout fonctionne maintenant. Espérons que quelqu'un corrigera le bon ensemble de dépendances entre les paquetages nécessaires pour que tout fonctionne correctement. C'est un tel bug ennuyeux à traiter.
Vincent Gerris

Il est à noter que j'ai eu du mal à résoudre ce problème pendant une journée complète. Redémarrer le service résolu par systemd ne m'a rien fait, mais le désactiver complètement et plus aucun problème!
fd8s0

Je répète que j'ai eu des problèmes de réseau depuis plusieurs jours depuis la mise à niveau à 17.04 de 16.10 J'ai essayé la plupart des réponses ici, la plupart des travaux pendant un certain temps, puis la question des cultures à nouveau ce qui a finalement travaillé a été invalidant résolu systemd utilisant sudo systemctl disable systemd-resolved.service et le réglage des dns à 8.8.8.8 dans /etc/resolv.conf
Japheth Ongeri - inkalimeva le

Cette simple ligne a résolu pour moi: redémarrage résolu par systemo sudo service, merci!
Sergio Abreu

36

Le comportement DNS lors de la connexion OpenVPN s'est amélioré immédiatement lorsque j'ai suivi une suggestion sur ubuntuforums:

  1. Ouvrir /etc/NetworkManager/NetworkManager.confdans un éditeur avec droits root.
  2. Supprimer (ou commenter avec un hachage #) la ligne qui litdns=dnsmasq
  3. Redémarrez NetworkManager via sudo service NetworkManager restart

Merci. J'ai essayé cela maintenant, mais cela n'a pas fonctionné. En fait, le DNS fonctionne bien, sauf lorsque je lance le client VPN Cisco, qui remplace le lien symbolique /etc/resolve.conf par un fichier texte brut.
Aweibell

1
Ce correctif fonctionnait pour moi, j'avais des problèmes de DNS avec OpenVPN. Après ce changement, mon /etc/resolve.conf a changé. C'est très étrange puisque je n'ai même pas installé Dnsmasq.
Postfuturist

Cela peut fonctionner pour des problèmes avec le NM et openvpn, mais au moins cela ralentit les connexions. Comme on le devine ici .
BairDev

3

Couru dans le même problème. D'une manière ou d'une autre, j'ai dû installer DNSmasq avec une application. Supprimer simplement dnsmasq a résolu le problème pour moi.

sudo apt-get remove dnsmasq 

Depuis lors, plus aucun débranchement ni aucun site ne pouvant plus être chargé (j'ai eu un problème de chargement de gmail, c’est-à-dire que tout à coup, il ne pouvait plus se connecter à gmail, bien que d’autres sites aient fonctionné).


Lors de la tentative de suppression du paquet dnsmasq-base , aptitude me dit que c’est requis par network-manager et ubuntu-fan . Si vous le supprimez, beaucoup de paquets supplémentaires seront supprimés.
aweibell

Quelle distribution et version? Je suis sur Ubuntu 16.10 et je n'ai eu aucun problème à le supprimer. Sinon je ne l'aurais pas posté :)
Nitai

Je suis aussi sur Ubuntu 16.10! Étrange. apt remove dnsmasq-base...The following packages will be REMOVED: account-plugin-ubuntuone checkbox-converged checkbox-gui dnsmasq-base indicator-network network-manager network-manager-gnome network-manager-openconnect network-manager-openconnect-gnome network-manager-openvpn network-manager-openvpn-gnome network-manager-pptp network-manager-pptp-gnome network-manager-vpnc pay-service plainbox-provider-checkbox plainbox-provider-resource-generic ubuntu-desktop ubuntu-fan ubuntu-push-client ....
Aweibell

Idem ici avec 16.10. Il veut aussi supprimer tous les autres paquets.
Dave Kincaid

Je viens d'avoir une déconnexion à nouveau l'autre jour. D'une manière ou d'une autre, une application doit avoir réinstallé dnsmasq. Dans tous les cas, cette fois je l'ai simplement désactivé avec systemd. Jusqu'à présent, il ne fonctionne plus et je n'ai pas de déconnexion non plus.
Nitai

1

Editer /etc/nsswitch.confet changer

hosts:          files mdns4_minimal [NOTFOUND=return] dns

à

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Modifier:

J'ai les mêmes problèmes depuis assez longtemps. J'ai été capable de résoudre les noms de domaine de vpn mais je n'ai pas été en mesure de les cingler ou de les curl, ni de les utiliser dans d'autres applications. Le changement décrit ci-dessus l'a résolu pour moi.

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.