16.10 DNS kann nicht aufgelöst werden


34

Nach dem Upgrade meiner 16.04-Installation auf 16.10 habe ich Probleme mit DNS.

Zuerst hatte ich ein paar Mal Probleme mit der WLAN-Verbindung, während es im Ethernet funktionierte. Jetzt scheint es auch über WLAN zu funktionieren. Ich weiß nicht warum und ob es in irgendeiner Weise mit dem Problem zu tun hat, mit dem ich jetzt konfrontiert bin:

Wenn Sie mit Cisco Anyconnect VPN eine Verbindung zu einem VPN-Host herstellen , wird in '/etc/resolv.conf' eine Zeile eingefügt . Ich verstehe , dass Ubuntu ist jetzt mit systemd-resolve , und der Mann - Seite sagt , dass es drei verschiedene Modi für den Umgang mit /etc/resolv.conf. Meine /etc/resolv.conf ist kein Symlink und listet 127.0.0.53 nicht als DNS-Server auf, so weit ich das verstehe, sollte systemd-resolved "es für DNS-Konfigurationsdaten lesen". Es scheint sich jedoch nicht darum zu kümmern.

graben

Das Seltsame (für mich) ist, dass dig host.customer.tldeine nette Antwort mit einem ANTWORT-ABSCHNITT zurückgegeben wird, der die IP des angeforderten Hosts zeigt, und der sich auf den DNS-Server bezieht, der von VPN-Client als SERVER zu /etc/resolv.conf hinzugefügt wurde. Wenn die VPN-Verbindung deaktiviert ist, erhalte ich keine Antwort. Dh dig liest /etc/resolv.conf .

Klingeln

Der Browser auf der anderen Seite gelangt nicht zu /etc/resolv.conf und kann den Hostnamen nicht auflösen. Ping / Curl übrigens auch nicht.

nmcli

Ich habe einen ähnlichen Beitrag gefunden und versucht zu rennen

nmcli device show <interfacename> | grep IP4.DNS

Es werden jedoch keine DNS für das cscotun0-Gerät aufgelistet. (Dies ist jedoch auch in 16.04 nicht der Fall.) Außerdem listet nmcli meinen DHCP-Server (meinen Router) als IP4.DNS-Host für meine eth / wlan-Verbindungen auf. Die Verwendung dig @192.168.0.1 xxxfür jede öffentliche Domain funktioniert einwandfrei.

Aufbau

In meiner /run/systemd/resolve/resolv.conf sind einige andere DNS-Server aufgeführt:

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

Diese werden nicht von meinem DHCP-Server bereitgestellt. Die Datei /etc/systemd/resolved.conf enthält nur kommentierte Zeilen mit Ausnahme der Abschnittsüberschrift:

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

Die Manpage für resolved.conf sagt das

DNS = Eine durch Leerzeichen getrennte Liste von IPv4- und IPv6-Adressen, die als System-DNS-Server verwendet werden sollen. ... Wenn diese Einstellung nicht angegeben ist, werden aus Kompatibilitätsgründen stattdessen die in /etc/resolv.conf aufgelisteten DNS-Server verwendet, sofern diese Datei vorhanden ist und Server darin konfiguriert sind. Diese Einstellung ist standardmäßig auf die leere Liste eingestellt.

FallbackDNS = Eine durch Leerzeichen getrennte Liste von IPv4- und IPv6-Adressen, die als Fallback-DNS-Server verwendet werden sollen. Alle per Link von systemd-networkd.service (8) erhaltenen DNS-Server haben Vorrang vor dieser Einstellung, ebenso wie alle über DNS = above oder /etc/resolv.conf eingestellten Server. Diese Einstellung wird daher nur verwendet, wenn keine anderen DNS-Serverinformationen bekannt sind. Wenn diese Option nicht angegeben ist, wird stattdessen eine kompilierte Liste von DNS-Servern verwendet.

Scheint, als würde der Fallback in meinem Fall in /run/systemd/resolve/resolv.conf landen.

EDIT: Ich war nicht sicher, was das Problem war, und um ehrlich zu sein, weiß ich immer noch nicht genau, wie das funktioniert, aber es stellte sich heraus, dass die Lösung in meinem Fall darin bestand, den systemd-resolvedDienst zu deaktivieren . Ich dachte, dass ein Dienst erforderlich ist, dass es die Komponente ist, die den DNS-Dienst für alle lokalen Anwendungen bereitstellt, aber anscheinend gibt es etwas anderes, das diesen Job ausführt.


Haben Sie ein Problem mit DNS, wenn Sie das VPN nicht verwenden?
Mark Stosberg


3
Ich wollte nur wissen, dass ich mit Anyconnect am 16.10 auf genau dieselben Probleme stoße. Das mehrmalige Verbinden mit dem VPN-Dienst scheint es vorübergehend zu beheben, aber irgendwann funktioniert der DNS nicht mehr.
Jmartinez

2
Ich habe ähnliche DNS-Probleme, die mit 16.04 nicht aufgetreten sind. Mein Vorschlag ist, mit dem Entfernen (Backup) von /etc/resolv.conf zu beginnen. Deinstallieren Sie das resolvconf-Paket. neustarten; und benutze dig, systemd-resolve mit und ohne VPN, um zu sehen, was funktioniert oder nicht.
Philcolbourn

1
Vergleichen Sie diesen Fehlerbericht: bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317
jdthood

Antworten:


15

Ich hatte ähnliche Probleme, zum Beispiel beim Hinzufügen eines zusätzlichen USB-WLAN-Dongles. Zuerst habe ich dnsmasq im Netzwerkmanager wie oben beschrieben deaktiviert und dnsmasq gestoppt (Dienst dnsmasq stop)

Ich habe festgestellt, dass die Routing-Tabelle beim Beheben von Fehlern während der VPN-Verbindung etwas anders aussieht (Ausgabe des Befehls route). Der Name des Gateways lautet DD-WRT für den Fall, dass es nicht funktioniert, und einfach „Gateway“, wenn es funktioniert. Die Ausgabe davon hat sich nicht geändert:

nmcli device show wlp1s0 | grep IP4.DNS

Die IP-Adresse meines Routers wurde weiterhin angezeigt. Ein Workaround, um es für eine Weile zum Laufen zu bringen, besteht darin, systemd-resolvd neu zu starten:

sudo service systemd-resolved restart

Da dnsmasq nicht in der Gleichung enthalten ist, ist entweder systemd-resolvd die Ursache für das Problem oder eine Änderung der Routingtabelle.

Das ist also der einzige Unterschied, den ich sehe:

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 

welches funktioniert. Und das, wenn es NICHT funktioniert:

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

Und der gleiche Namensunterschied auf der VPN-Leitung:

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

Wer weiß, was die Routing-Tabelle beeinflussen kann? Es wäre großartig, wenn wir dies identifizieren könnten, damit ein Fehlerbericht eingereicht werden kann. Ich werde ernsthaft krank und müde, all diese Fehler zu verfolgen, aber ich möchte, dass sie behoben werden, damit zukünftige Benutzer und wir glücklich sind :).

[update] Es scheint, als würde das Beenden von systemd-resolved das Problem beheben und andere Dinge nicht negativ beeinflussen. Sie können das versuchen und es wissen lassen, wenn es Sachen kaputt macht. Ich sah beim Ausführen von systemd-resolvd im Debug, als es kaputt ging:

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 *

Etwas deaktivieren:

sudo systemctl disable systemd-resolved.service

Ich habe den Ubuntu-Bericht mit Vorschlägen aktualisiert. [/ update] Hinzufügen: Hinweis: Der Fehlerbericht: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 enthält für einige Probleme einen Patch für 17.04. Bitte überprüfen Sie den Fehlerbericht und testen Sie den Patch, falls möglich. Vielen Dank!

[aktualisieren]

Bitte überprüfen Sie den oben genannten Fehlerbericht. Das Problem scheint für 17.10 behoben zu sein. Mit einem einfachen Befehl kann auch DNS-Leakage deaktiviert werden.

[/aktualisieren]


Vielen Dank für Ihren ausführlichen Bericht! Ich sehe andere Änderungen in der Routing-Tabelle als Sie - mein VPN scheint viele Routen hinzuzufügen, die, wie ich vermute, dynamisch verwendet werden. Das Deaktivieren von systemd-resolved funktionierte jedoch auch für mein Problem sehr gut!
Aweibell

Ich denke, irgendwann war der Name in der Routing-Tabelle nicht mehr wichtig, sondern es wurde systembedingt versucht, die DNS-Auflösung irgendwie durcheinander zu bringen. Ich musste auch den dnsmasq-Dienst deaktivieren, um zu verhindern, dass er gestartet wird, aber jetzt funktioniert alles. Hoffen wir, dass jemand die richtigen Abhängigkeiten zwischen Paketen behebt, die erforderlich sind, damit alles ordnungsgemäß funktioniert. Es ist so ein nerviger Fehler, mit dem man sich befasst.
Vincent Gerris

Bemerkenswert, ich hatte einen ganzen Tag mit diesem Problem zu kämpfen. Ein Neustart des von Systemd aufgelösten Dienstes hat nichts für mich getan, aber es komplett deaktiviert und keine Probleme mehr!
fd8s0

Um es noch einmal zu wiederholen: Ich hatte seit dem Upgrade von 16.10 auf 17.04 einige Tage lang Netzwerkprobleme. Ich habe die meisten Antworten hier ausprobiert, die meiste Zeit gearbeitet, und dann tauchte das Problem erneut auf. Schließlich funktionierte es , das System zu deaktivieren sudo systemctl disable systemd-resolved.service und das DNS einzustellen bis 8.8.8.8 in /etc/resolv.conf
Japheth Ongeri - inkalimeva

Diese einfache Zeile hat sich für mich gelöst: sudo service systemd-resolved restart, danke!
Sergio Abreu

36

Das DNS-Verhalten während der OpenVPN-Verbindung wurde sofort verbessert, als ich einem Vorschlag auf Ubuntuforums folgte:

  1. Öffnen Sie /etc/NetworkManager/NetworkManager.confin einem Editor mit Root-Rechten.
  2. Löschen Sie die gelesene #Zeile (oder kommentieren Sie sie mit einem Hash aus )dns=dnsmasq
  3. Starten Sie den NetworkManager über neu sudo service NetworkManager restart

Vielen Dank. Versuchte dies jetzt, aber es hat nicht funktioniert. Tatsächlich funktioniert DNS einwandfrei, außer wenn ich den Cisco VPN-Client starte, der den Symlink /etc/resolve.conf durch eine reine Textdatei ersetzt.
Aweibell

1
Dieser Fix hat bei mir funktioniert, ich hatte DNS-Probleme mit OpenVPN. Nach dieser Änderung hat sich meine /etc/resolve.conf geändert. Es ist sehr seltsam, da ich nicht einmal dnsmasq installiert habe.
Postfuturist

Dies könnte bei Problemen mit NM und openvpn funktionieren, verlangsamt aber zumindest die Verbindungen. Wie es erraten hier .
BairDev

3

Bin auf dasselbe Problem gestoßen. Irgendwie muss ich DNSmasq mit einer Anwendung installiert haben. Das Entfernen von dnsmasq löste das Problem für mich.

sudo apt-get remove dnsmasq 

Seitdem gibt es keine Verbindungsabbrüche mehr oder einige Websites können nicht mehr geladen werden (ich hatte ein Problem beim Laden von Google Mail, dh plötzlich konnte keine Verbindung zu Google Mail hergestellt werden, obwohl andere Websites funktionierten).


Beim Versuch , entfernen dnsmasq-Basispaket, aptitude mir sagt , dass es erforderlich ist , von Netzwerk-Manager und ubuntu-Fan , und das Entfernen es in einer Menge von zusätzlichen Paketen führt entfernt werden ..
aweibell

Welche Distribution und Version? Ich bin auf Ubuntu 16.10 und hatte keine Probleme, es zu entfernen. Sonst hätte ich es nicht gepostet :)
Nitai

Ich bin auch auf Ubuntu 16.10! Seltsam. 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

Gleiches hier mit 16.10. Es möchte auch all diese anderen Pakete entfernen.
Dave Kincaid

Ich hatte neulich wieder eine Unterbrechung. Irgendwie muss eine App dnsmasq erneut installiert haben. In jedem Fall habe ich es dieses Mal einfach mit systemd deaktiviert. Bisher läuft es nicht mehr und ich bekomme auch keine Verbindungsabbrüche.
Nitai

1

Bearbeiten /etc/nsswitch.confund ändern

hosts:          files mdns4_minimal [NOTFOUND=return] dns

zu

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Bearbeiten:

Ich habe seit einiger Zeit die gleichen Probleme. Ich konnte Domänennamen über VPN auflösen, aber ich konnte diese nicht pingen oder locken oder sie in anderen Anwendungen verwenden. Die oben beschriebene Änderung hat es für mich gelöst.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.