Proxy-Spaß
Ich erstelle eine virtuelle Maschine mit Ubuntu 18.10 auf meinem Windows 10-Host mit Vagrant und VMware Workstation 15.
Die VM scheint einwandfrei zu funktionieren, einschließlich der meisten Netzwerkzugriffe.
Aber bei einem wichtigen Host habe ich kein Glück:
$ ping -c 4 production.cloudflare.docker.com
ping: production.cloudflare.docker.com: Temporary failure in name resolution
(Wenn ich genau dasselbe in Cygwin auf dem Windows-Host mache, funktioniert es einwandfrei.)
Wassollender Grund sein?DNS-Nameserver!
systemd-resolve --statusAllerdings sagt mir das, dass es ( "Current DNS Server: 8.8.4.4"on eth0, die einzige Schnittstelle mit nennenswerten RX- und TX-Mengen) verwendet.funktioniert gutwenn ich es explizit versuche:
$ dig @8.8.4.4 production.cloudflare.docker.com
; <<>> DiG 9.11.4-3ubuntu5.1-Ubuntu <<>> @8.8.4.4 production.cloudflare.docker.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45235
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
[...]
production.cloudflare.docker.com. 117 IN A 104.18.122.25
production.cloudflare.docker.com. 117 IN A 104.18.121.25
production.cloudflare.docker.com. 117 IN A 104.18.125.25
production.cloudflare.docker.com. 117 IN A 104.18.124.25
production.cloudflare.docker.com. 117 IN A 104.18.123.25
aber wenn ich durch Ubuntuslokaler Proxy, die Abfrageschlägt fehl:
$ dig production.cloudflare.docker.com
; <<>> DiG 9.11.4-3ubuntu5.1-Ubuntu <<>> production.cloudflare.docker.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60815
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[...]
;; SERVER: 127.0.0.53#53(127.0.0.53)
Offenbar 127.0.0.53macht es nicht das, was es meiner Meinung nach sollte. (Beachten Sie, dass ich ein Netzwerk-Neuling bin.)
Was vermisse ich?
Ich bin mir nicht einmal sicher, ob das eher eine Ubuntu- oder eine VMware-Frage ist. Oder vielleicht eine Vagrant-Frage?
Schauder.
Antwort1
Es handelt sich um eine Drei-Byte-Änderung!
Im Internet gibt es viele Berichte über DNS-Fehler bei Ubuntu. Wie in der Antwort von HackSlash wird in den meisten Antworten vorgeschlagen, die vorgesehenen Nameserver fest zu verdrahten /etc/resolv.conf. Aber wenn ich das richtig verstehe, wird dadurch das lokale Caching deaktiviert, was albern und ein wenig unsozial erscheint, also wollte ich das nicht tun.
Was ist das Problem?
Die Erklärung fand ich schließlich inhttps://superuser.com/a/1200745/372846: Ubuntu systemd-resolvedkann offenbar Nameserver, die DNSSEC verwenden, nicht richtig handhaben. Man muss die DNSSEC-Unterstützung ausschalten, dann ist alles in Ordnung.
Lösung
Ersetzen Sie in der Datei /etc/systemd/resolved.confdie Zeile DNSSEC=yesdurch DNSSEC=no; starten Sie dann den Resolver-Dienst durch neu sudo systemctl restart systemd-resolved.
Meine verbleibende Verwirrung
Der obige Beitrag handelte von Ubuntu 17.04, als systemd-resolvedUbuntu offenbar noch relativ neu war. Ein Kommentar unterdiese Antwortauf dieselbe Frage wird angegeben, dass die Standardeinstellung in späteren Ubuntu-Versionen geändert wird DNSSEC=no. Ich verwende 18.10 und das ist immer noch nicht geschehen – ebenso wenig wie die vollständige DNSSEC-Funktion.Was zum Teufel?
Antwort2
Dies wurde auf askubuntu beantwortet. Es gibt viele Lösungen, die empfehlen, einen anderen Resolver zu installieren.
Diese Antwort besagt, dass Sie das nicht tun müssen:
Wenn Sie nach einer schnellen und einfachen Lösung suchen, können Sie systemd-resolved einfach so konfigurieren, dass Ihre DNS-Server global verwendet werden:
$ cat /etc/systemd/resolved.conf
<...>
[Resolve]
DNS=8.8.8.8 8.8.4.4
<...>
Führen Sie anschließend einen Neustart systemd-resolved.servicebzw. Reboot durch.
VOLLSTÄNDIGE FRAGEN UND ANTWORTEN: https://askubuntu.com/questions/1012641/dns-set-to-systemds-127-0-0-53-how-to-change-permanently