16.10 échoue à résoudre le DNS

32

Après la mise à niveau de mon installation 16.04 vers la version 16.10, je rencontre des problèmes avec le DNS.

Tout d’abord, j’ai eu quelques problèmes lorsqu’il était connecté au WiFi, alors qu’il fonctionnait sur Ethernet. Maintenant, il semble aussi fonctionner sur le WiFi. Je ne sais pas pourquoi et si cela est lié au problème auquel je suis confronté maintenant:

Lors de la connexion à un hôte VPN avec Cisco Anyconnect VPN , il ajoute une ligne dans /etc/resolv.conf . Je comprends que Ubuntu utilise maintenant systemd-resolve , et la page de manuel indique qu'il existe trois modes différents pour gérer /etc/resolv.conf. Mon fichier /etc/resolv.conf n'est pas un lien symbolique et ne répertorie pas 127.0.0.53 en tant que serveur DNS. Autant que je sache, systemd-Résolution doit 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.tld , retourne une bonne réponse avec une section ANSWER montrant l'ip de l'hôte demandé, et il fait référence au serveur DNS ajouté à /etc/resolv.conf par le client vpn comme le SERVEUR. Lorsque la connexion VPN est désactivée, je n'ai pas de réponse. C'est à dire. creuser lit /etc/resolv.conf.

ping

De l’autre côté, le navigateur n’atteint pas /etc/resolv.conf et n’est pas capable de résoudre le nom de l’hôte. Soit dit en passant, ping / curl.

nmcli

J'ai trouvé une publication associée , et essayé de courir

nmcli device show <interfacename> | grep IP4.DNS

mais il ne répertorie aucun 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. L'utilisation de dig @192.168.0.1 xxx pour tout domaine public fonctionne correctement.

configuration

D'autres serveurs DNS sont répertoriés dans /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 ne contient que 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 relative à resolve.conf indique que

  

DNS =     Une liste séparée par des espaces d'adresses IPv4 et IPv6 à utiliser comme serveurs DNS du système.     ...     Pour des raisons de compatibilité, si ce paramètre n’est pas spécifié, les serveurs DNS     énumérés dans /etc/resolv.conf sont utilisés à la place, si ce fichier existe et tout     les 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 DNS de secours   les serveurs. Tous les serveurs DNS par lien obtenus à partir de systemd-networkd.service (8)   prévalent sur ce paramètre, comme le font tous les serveurs définis via DNS = ci-dessus ou   /etc/resolv.conf. Ce paramètre n'est donc utilisé que si aucun autre serveur DNS   l'information est connue. Si cette option n'est pas fournie, une liste intégrée dans les serveurs DNS est utilisée à la place.

On dirait que le repli se termine dans /run/systemd/resolve/resolv.conf dans mon cas.

EDIT: Je n'étais pas certain du problème, et pour être honnête, je ne sais toujours pas exactement comment cela fonctionne, mais au moins, il s’est avéré que la solution dans mon cas consistait à Désactivez le service systemd-resolved . Je pensais que le service était requis, que c'était le composant qui fournissait le service DNS à toutes les applications locales, mais apparemment, il y a autre chose à faire pour faire ce travail.

    
posée aweibell 18.10.2016 - 23:37
la source

4 réponses

15

J'ai rencontré des problèmes similaires, par exemple en ajoutant une clé USB wifi supplémentaire. J'ai d'abord 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 du problème lors de la 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ù il ne fonctionne pas et simplement «passerelle» lorsqu'il fonctionne. La sortie de ceci n'a pas changé:

nmcli device show wlp1s0 | grep IP4.DNS

Il a continué à montrer mon IP de routeur. Une solution pour le faire fonctionner pendant un certain temps 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 quelque chose qui change la table de routage.

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

[email protected]:~$ 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:

[email protected]:~$ 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 formidable si nous pouvons identifier cela pour qu'un rapport de bogue puisse être déposé. Je suis sérieusement fatigué de poursuivre tous ces bugs, mais j'aimerais les réparer pour que les futurs utilisateurs et nous-mêmes serons heureux:).

[mise à jour] Il semble que stopper systemd-résolution peut résoudre ce problème et ne pas avoir d’impact négatif sur d’autres choses. Vous pouvez essayer cela et le faire savoir si ça casse des choses. J'ai vu lors de l'exécution de systemd-resolvd en debug 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. [/mettre à jour] Ajouter: Note: le rapport de bogue: lien a un correctif pour 17.04 pour certains problèmes. Veuillez vérifier le rapport de bogue et, si possible, tester le correctif. Merci!

[update]

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 de DNS peut également être désactivée.

[/ update]

    
réponse donnée Vincent Gerris 18.12.2016 - 16:51
la source
34

Le comportement du DNS lors de la connexion OpenVPN s’est amélioré immédiatement après avoir suivi une suggestion sur ubuntuforums:

  1. Ouvrez /etc/NetworkManager/NetworkManager.conf dans un éditeur avec les droits root.
  2. Supprimer (ou commenter avec un hachage # ) la ligne qui lit dns=dnsmasq
  3. Redémarrez NetworkManager via sudo service NetworkManager restart
réponse donnée krlmlr 22.11.2016 - 22:30
la source
3

Ran dans le même problème. D'une certaine manière, je dois avoir installé DNSmasq avec certaines applications. Supprimer simplement Dnsmasq a résolu le problème pour moi.

sudo apt-get remove dnsmasq 

Depuis lors, plus de déconnexions ou de sites ne pouvant plus se charger (j’ai eu un problème de chargement de gmail, c’est-à-dire qu’il n’a pas été possible de se connecter à gmail, bien que d’autres sites aient fonctionné).

    
réponse donnée Nitai 29.11.2016 - 02:49
la source
1

Modifier /etc/nsswitch.conf et modifier

hosts:          files mdns4_minimal [NOTFOUND=return] dns

à

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Modifier:

J'ai eu les mêmes problèmes pendant un certain temps. J'ai été capable de résoudre les noms de domaine à partir de vpn mais je n'ai pas pu cingler ou boucler ceux-ci ou les utiliser dans d'autres applications. Le changement décrit ci-dessus l'a résolu pour moi.

    
réponse donnée PaL 20.10.2017 - 00:49
la source

Lire d'autres questions sur les étiquettes