nslookup ist fehlgeschlagen, funktioniert aber mit Systemdefekten

776
Richard Collins

Dies ist ein seltsames Problem, das ich den ganzen Tag verbracht habe. Es wäre toll, wenn jemand etwas Licht in diese Sache bringen könnte.

Das Problem tritt bei der Namensauflösung auf, aber ich bin nicht sicher, ob dies die Hauptursache ist:

# host www.google.com ;; connection timed out; no servers could be reached

so weit so langweilig, aber warte !:

#systemd-resolve www.google.com www.google.com: 209.85.202.103 209.85.202.106 209.85.202.105 209.85.202.104 209.85.202.147 209.85.202.99

Einfach ist das Problem mit resolv.conf richtig?

# This file is managed by man:systemd-resolved(8). Do not edit. # # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53  search xxx.uk xyz

Das System verwendet also den systemd-Resolver?

#dig @127.0.0.53 www.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.53 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached

ok, wenn der systemd resolver sagt, es sei 127.0.0.53, warum antwortet er nicht. 

#sudo netstat -lupn | grep 127 udp 0 0 127.0.0.53:53 0.0.0.0:* 1679/systemd-resolv

Wenn es nicht zuhört, was macht systemd-resolv?

Global DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa corp d.f.ip6.arpa home internal intranet lan local private test  Link 20 (veth10858e2) Current Scopes: LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no  Link 14 (vnet0) Current Scopes: LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no  Link 13 (virbr0-nic) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no  Link 12 (virbr0) Current Scopes: LLMNR/IPv4 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no  Link 11 (docker0) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no  Link 10 (docker_gwbridge) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no  Link 3 (em2) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.100.1 192.168.100.2 192.168.100.3 192.168.100.4 DNS Domain: cqp  Link 2 (em1) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: xxx.xxx.x.xx xxx.xxx.x.xx DNS Domain: xxx.uk

Ich habe mehrere Server, sie laufen alle auf dem neuesten Stand Ubuntu Artful, dieses Problem hat sich zwischen den Servern verschoben, um zu versuchen, das Problem zu beheben.
Sie sind Teil eines Docker-Schwarms, der entfernt wird, um das Problem an einer Stelle zu beheben.

Ich habe das durch das System aufgelöste Debugging aktiviert, aber bei einer Anforderung wurde keine Ausgabe ausgegeben.

1
Vielleicht blockiert Ihre Firewall es? grawity vor 6 Jahren 0
Sie haben vielleicht Recht, aber ich kann keine Regel sehen, die sie beeinflussen würde. Was ich nicht verstehe, ist, wie das System entscheidet, was gefragt wird. Ich dachte, dass es die resolv.conf-Datei enthält, an die die Anfrage gesendet werden soll Richard Collins vor 6 Jahren 0
nslookup ist nicht "das System". systemd-resolvectl ist nicht "das System". Beide verwenden einen direkteren Ansatz als "das System", und sie verwenden unterschiedliche APIs (systemd-resolvectl verwendet D-Bus, nicht UDP). grawity vor 6 Jahren 0
Ich weiß, dass es letztendlich auf gethostbyname () hinausläuft, was fehlschlägt. Wie entscheidet das, wie die Adresse aufgelöst werden soll, wenn nicht 127.0.0.53 verwendet wird, wie die resol.conf sagt? Richard Collins vor 6 Jahren 0
Mein Punkt war, dass ** sich nicht auf Gethostbyname () reduziert. Das 'nslookup'-Tool verwendet weiterhin resolv.conf, spricht aber direkt DNS. Und das `systemd-resol`-Tool spricht kein DNS, es spricht D-Bus. grawity vor 6 Jahren 0

1 Antwort auf die Frage

1
Neil Smith

Ich fand diese Antwort auf Hacker News, die vorgeschlagen SymLink /etc/resolv.confan /run/systemd/resolve/resolv.conf:

sudo rm /etc/resolv.conf sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Das hat bei mir funktioniert. Ich glaube nicht, dass ich nach der Neuerstellung des Symlinks Dienste neu starten musste.

Danke aber das ist schon der Fall. Richard Collins vor 5 Jahren 0

Verwandte Probleme