rennradler
Anmeldungsdatum: 27. Februar 2010
Beiträge: 1833
|
Hallo Leute, ich habe ein schräges Problem bei der Namensauflösung. Manche Namen werden aufgelöst, manche nicht. Das Verhalten tritt sowohl in einer VM mit VirtualBox 5.1.18 als auch bei einer echten Installation auf, mit leicht unterschiedlichen Symptomen. Beispiel: www.google.com wird aufgelöst, www.gnome-look.org nicht. In einer VM sieht es so aus: sepp@k1704:~$ nslookup www.google.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: www.google.com
Address: 216.58.207.68
sepp@k1704:~$ nslookup www.gnome-look.org
;; connection timed out; no servers could be reached
beg@k1704:~$ nslookup www.gnome-look.org 10.0.2.3
Server: 10.0.2.3
Address: 10.0.2.3#53
Non-authoritative answer:
www.gnome-look.org canonical name = gnome-look.org.
Name: gnome-look.org
Address: 46.101.238.240
google wird also aufgelöst, gnome-look nicht. Erst wenn man den Nameserver der VM explizit angibt, also die interne Namensauflösung umgeht, wird gnome-look aufgelöst. So, und so sieht es in einer echten Installation aus:
sepp@darkstar:~$ nslookup www.gnome-look.org
;; connection timed out; no servers could be reached
sepp@darkstar:~$ nslookup www.gnome-look.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
www.gnome-look.org canonical name = gnome-look.org.
Name: gnome-look.org
Address: 46.101.238.240 Hier muß man nslookup mehrmals machen, manchmal klappt es nach den zweiten, meist erst nach dem dritten Versuch. Dann geht es auf Anhieb. 😲 Was ist dann da los? An meinem lokalen Netzwerk liegt es nicht - die anderen Rechner mit 16.04 haben keine Probleme mit der Namensauflösung.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Anscheinend hast du da seltsame Nameserver drin. Wie hast du dein Netzwerk konfiguriert? Hast du einen eigenen dns-Dienst eingerichtet? Ansonsten stelle die Nameserver mal auf dein Gateway (Router) ein oder auf 8.8.8.8, bzw. 8.8.4.4 (für ipv4).
|
rennradler
(Themenstarter)
Anmeldungsdatum: 27. Februar 2010
Beiträge: 1833
|
Nö, das ist die Ubuntu-Standardkonfiguration für einen Desktop. Da hab ich nicht dran geschraubt. Mit systemd-resolve --status sieht man, daß er schon den richtigen Nameserver (192.168.0.1, meine Fritz-Box bzw. die 10.0.2.3 in der VM) bekommen hat. Wenn ich in die resolv.conf die 192.168.0.1 als Nameserver eintrage, geht die Namensauflösung natürlich problemlos. Aber da sitzt weder das Problem, noch ist es eine Lösung. Und ja, ich hab auf meiner Fritz-Box freez laufen und einen dnsmasq, weil ich darüber auch die Namensauflösung im lokalen Netzwerk mache. Aber das hat nichts mit meinem Problem zu tun.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
rennradler schrieb: Nö, das ist die Ubuntu-Standardkonfiguration für einen Desktop.
Wie sind die Ausgaben von:
cat /etc/nsswitch.conf
sudo netstat -tulpen | grep -i :53
cat /etc/resolv.conf
? EDIT: rennradler schrieb: ... ich hab auf meiner Fritz-Box freez laufen und einen dnsmasq, weil ich darüber auch die Namensauflösung im lokalen Netzwerk mache.
BTW: Das geht auch mit der FB, ohne Freetz bzw. ohne dnsmasq. Oder ist das eine "alte" FB? ... oder was ist so "besonders" an deinem lokalen Netzwerk, dass Du dnsmasq brauchst?
|
rennradler
(Themenstarter)
Anmeldungsdatum: 27. Februar 2010
Beiträge: 1833
|
BTW: Das geht auch mit der FB, ohne Freetz bzw. ohne dnsmasq. Oder ist das eine "alte" FB? ... oder was ist so "besonders" an deinem lokalen Netzwerk, dass Du dnsmasq brauchst?
Nein, die kann das nicht. Das blöde Teil löst die über DHCP vergebenen Adressen nicht auf. Alt? Ja. Ansonsten: nsswitch.conf # /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat
group: compat
shadow: compat
gshadow: files
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: ni resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 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 Alles, wie Ubuntu aus der Kiste kommt. Da hab ich nichts angefaßt. Warum auch? sudo netstat -tulpen | grep -i :53
tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 102 24704 1864/systemd-resolv
tcp6 0 0 :::5355 :::* LISTEN 102 24707 1864/systemd-resolv
udp 0 0 127.0.0.53:53 0.0.0.0:* 102 24702 1864/systemd-resolv
udp 0 0 0.0.0.0:5353 0.0.0.0:* 114 23704 1647/avahi-daemon:
udp 0 0 0.0.0.0:5355 0.0.0.0:* 102 24703 1864/systemd-resolv
udp6 0 0 :::5353 :::* 114 23705 1647/avahi-daemon:
udp6 0 0 :::5355 War zwar nicht gefragt:
systemd-resolve --status
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 3 (wlp3s0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: allow-downgrade
DNSSEC supported: yes
Link 2 (enp0s25)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: allow-downgrade
DNSSEC supported: yes
DNS Servers: 192.168.0.1
DNS Domain: home
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
rennradler schrieb:
nsswitch.conf hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns sudo netstat -tulpen | grep -i :53
tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 102 24704 1864/systemd-resolv
tcp6 0 0 :::5355 :::* LISTEN 102 24707 1864/systemd-resolv
udp 0 0 127.0.0.53:53 0.0.0.0:* 102 24702 1864/systemd-resolv
udp 0 0 0.0.0.0:5353 0.0.0.0:* 114 23704 1647/avahi-daemon:
udp 0 0 0.0.0.0:5355 0.0.0.0:* 102 24703 1864/systemd-resolv
udp6 0 0 :::5353 :::* 114 23705 1647/avahi-daemon:
udp6 0 0 :::5355
Teste mal mit:
#hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
hosts: files dns
in der nsswitch.conf und auch zusätzlich mit:
sudo systemctl stop avahi-daemon
sudo apt-get purge --remove avahi-daemon
|
rennradler
(Themenstarter)
Anmeldungsdatum: 27. Februar 2010
Beiträge: 1833
|
Ich habe es in einer VM probiert, weil dort auch bei wiederholter Eingabe die Namensauflösung versagt. Beim einer echten Installation funktioniert es i.d.R. nach dem zweiten oder dritten Mal. Ergebnis: keinerlei Änderung. Daß die Namensauflösung prinzipiell problemlos geht, habe ich auch nochmal sichergestellt. Schreib ich in die resolv.conf 10.0.2.3 als Nameserver rein, geht die Namensauflösung sofort. (10.0.2.3 ist der Nameserver der VM).
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
rennradler schrieb: Ergebnis: keinerlei Änderung.
Dann teste mal mit:
sudo tcpdump -c 50 -vvveni any dst port 53
(an der richtigen Stelle) wohin die Namensauflösung "gehen will", wenn es nicht funktioniert.
|
rennradler
(Themenstarter)
Anmeldungsdatum: 27. Februar 2010
Beiträge: 1833
|
Hier der Output (Test mit Virtueller Maschine) bei Eingabe von nslookup www.gnome-look.org:
sudo tcpdump -c 50 -vvveni any dst port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
12:23:02.413253 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 64, id 30285, offset 0, flags [none], proto UDP (17), length 64)
127.0.0.1.33710 > 127.0.0.53.53: [bad udp cksum 0xfe73 -> 0x6440!] 55484+ A? www.gnome-look.org. (36)
12:23:02.413683 Out 08:00:27:79:8c:f3 ethertype IPv4 (0x0800), length 113: (tos 0x0, ttl 64, id 50959, offset 0, flags [DF], proto UDP (17), length 97)
10.0.2.15.55849 > 10.0.2.3.53: [bad udp cksum 0x1870 -> 0xf079!] 60718+% [1au] A? www.gnome-look.org. ar: . OPT UDPsize=889 DO (69)
12:23:02.471219 Out 08:00:27:79:8c:f3 ethertype IPv4 (0x0800), length 109: (tos 0x0, ttl 64, id 50968, offset 0, flags [DF], proto UDP (17), length 93)
10.0.2.15.41112 > 10.0.2.3.53: [bad udp cksum 0x186c -> 0xc4a4!] 52614+% [1au] SOA? gnome-look.org. ar: . OPT UDPsize=889 DO (65)
12:23:02.529098 Out 08:00:27:79:8c:f3 ethertype IPv4 (0x0800), length 109: (tos 0x0, ttl 64, id 50970, offset 0, flags [DF], proto UDP (17), length 93)
10.0.2.15.55097 > 10.0.2.3.53: [bad udp cksum 0x186c -> 0x182c!] 17209+% [1au] DS? gnome-look.org. ar: . OPT UDPsize=889 DO (65)
12:23:02.597536 Out 08:00:27:79:8c:f3 ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 50980, offset 0, flags [DF], proto UDP (17), length 82)
10.0.2.15.50303 > 10.0.2.3.53: [bad udp cksum 0x1861 -> 0x82e2!] 19698+% [1au] DNSKEY? org. ar: . OPT UDPsize=889 DO (54)
12:23:07.413305 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 64, id 31169, offset 0, flags [none], proto UDP (17), length 64)
127.0.0.1.33710 > 127.0.0.53.53: [bad udp cksum 0xfe73 -> 0x6440!] 55484+ A? www.gnome-look.org. (36)
12:23:07.724427 Out 08:00:27:79:8c:f3 ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 51033, offset 0, flags [DF], proto UDP (17), length 82)
10.0.2.15.50303 > 10.0.2.3.53: [bad udp cksum 0x1861 -> 0x82e2!] 19698+% [1au] DNSKEY? org. ar: . OPT UDPsize=889 DO (54)
12:23:12.414015 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 64, id 32282, offset 0, flags [none], proto UDP (17), length 64)
127.0.0.1.33710 > 127.0.0.53.53: [bad udp cksum 0xfe73 -> 0x6440!] 55484+ A? www.gnome-look.org. (36)
12:23:12.974859 Out 08:00:27:79:8c:f3 ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 51460, offset 0, flags [DF], proto UDP (17), length 82)
10.0.2.15.50303 > 10.0.2.3.53: [bad udp cksum 0x1861 -> 0x82e2!] 19698+% [1au] DNSKEY? org. ar: . OPT UDPsize=889 DO (54)
12:23:18.224951 Out 08:00:27:79:8c:f3 ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 52323, offset 0, flags [DF], proto UDP (17), length 82)
10.0.2.15.50303 > 10.0.2.3.53: [bad udp cksum 0x1861 -> 0x82e2!] 19698+% [1au] DNSKEY? org. ar: . OPT UDPsize=889 DO (54)
^C
10 packets captured
13 packets received by filter
0 packets dropped by kernel
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
rennradler schrieb: sudo tcpdump -c 50 -vvveni any dst port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
12:23:02.413253 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 64, id 30285, offset 0, flags [none], proto UDP (17), length 64)
127.0.0.1.33710 > 127.0.0.53.53: [bad udp cksum 0xfe73 -> 0x6440!] 55484+ A? www.gnome-look.org. (36)
12:23:02.413683 Out 08:00:27:79:8c:f3 ethertype IPv4 (0x0800), length 113: (tos 0x0, ttl 64, id 50959, offset 0, flags [DF], proto UDP (17), length 97)
D. h. systemd-resolvd (127.0.0.53:53) hat Probleme. Evtl. stoppen/deaktivieren und mit dnsmasq (unter 17.04/VM) oder nur mit der resolv.conf versuchen/testen.
|
rennradler
(Themenstarter)
Anmeldungsdatum: 27. Februar 2010
Beiträge: 1833
|
Nur mit der resolv.conf geht es natürlich - das wußte ich aber schon vorher. Und was ist jetzt die Schlußfolgerung? Ein Bug in der 17.04?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
rennradler schrieb: Und was ist jetzt die Schlußfolgerung? Ein Bug in der 17.04?
... oder ein Konfigurationsfehler? Wie sind die Ausgaben von:
cat /run/systemd/resolve/resolv.conf
ls -la /run/systemd/resolve/resolv.conf
cat /etc/systemd/resolved.conf
?
|
rennradler
(Themenstarter)
Anmeldungsdatum: 27. Februar 2010
Beiträge: 1833
|
Ich kann hier nichts auffälliges erkennen. Wenn was nicht paßt, wäre es ein Bug im Installer, da ich nichts händisch konfiguriert habe. cat /run/systemd/resolve/resolv.conf:
# This file is managed by systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known DNS servers.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 10.0.2.3
search home ls -al /run/systemd/resolve/resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 531 Apr 14 14:20 /run/systemd/resolve/resolv.conf cat /etc/systemd/resolved.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details
[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
#Domains=
#LLMNR=yes
#DNSSEC=allow-downgrade
#Cache=yes
#DNSStubListener=udp
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
rennradler schrieb: Ich kann hier nichts auffälliges erkennen. Wenn was nicht paßt, wäre es ein Bug im Installer, da ich nichts händisch konfiguriert habe. cat /etc/systemd/resolved.conf
[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
#Domains=
#LLMNR=yes
#DNSSEC=allow-downgrade
#Cache=yes
#DNSStubListener=udp
Teste mal auch mit folgenden _wirksamen_ Eintragungen in der "/etc/systemd/resolved.conf":
[Resolve]
DNS=8.8.8.8
FallbackDNS=8.8.4.4
|
rennradler
(Themenstarter)
Anmeldungsdatum: 27. Februar 2010
Beiträge: 1833
|
Dann gehts: $ nslookup www.gnome-look.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
www.gnome-look.org canonical name = gnome-look.org.
Name: gnome-look.org
Address: 46.101.238.240 Auffallend ist, daß die Antwort sofort kommt, ohne jegliche Verzögerung. Wenn ich vorher www.google.com zum ersten Mal angefragt habe, kam die Antwort nach ca. 2 Sekunden und bei www.gnome-look.org eben überhaupt nicht.
|