[Gelöst] Timeout bei der ersten DNS Anfrage

[paulpaulpaul]

Hallo Zusammen,

ich habe ein Problem mit meinem neu installierten Debian 10 und finde keine Lösung.

Bei einer ersten DNS Abfrage für einen Host laufe ich auf einen Timeout. Anbei ein schönes Beispiel mit einem einfachen ping. Die Ausführung dauert beim ersten Mal 5 Sekunden, beim zweiten Mal keine Sekunde:

Code: Alles auswählen

root@host:~# time ping -c 1 heise.de
PING heise.de(heise.de (2a02:2e0:3fe:1001:302::)) 56 data bytes
64 bytes from heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=1 ttl=56 time=26.9 ms

--- heise.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 26.936/26.936/26.936/0.000 ms

real    0m5,079s
user    0m0,000s
sys     0m0,008s
root@host:~#
root@host:~# time ping -c 1 heise.de
PING heise.de(heise.de (2a02:2e0:3fe:1001:302::)) 56 data bytes
64 bytes from heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=1 ttl=56 time=27.0 ms

--- heise.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.027/27.027/27.027/0.000 ms

real    0m0,051s
user    0m0,000s
sys     0m0,008s

Beim DNS-Server der in "/etc/resolv.conf" eingetragen ist, handelt es sich um meinen lokalen Router, der DNS auch für alle anderen Geräte (Windows, Linux, Android...) im Netz spielt, ohne jede Auffälligkeit.

Auch habe ich mir das ganze schon per tcpdump angeschaut. Der DNS-Server antwortet immer sofort, nur wird die erste Antwort scheinbar von den Applikationen nicht verwendet. Nach wenigen Sekunden erfolgt die zweite DNS Anfrage, welche dann auch verwendt wird.

Trage ich jedoch z.B. 1.1.1.1 oder 8.8.8.8 in "/etc/resolv.conf" ein, tritt der Effekt nicht auf. Es ist also scheinbar nur das Zusammenspiel meines Router/DNS mit meinem neuen Debian-Rechner.

Es ist auch egal, ob ich die IPv4 oder die IPv6 Adresse meines Routers verwendene.

In meiner resolv.conf stehe ausschliesslich eine Zeile: "nameserver 172.16.x.x".

Wer hat hierzu noch Ideen?

Viele Grüße

Paul

[MSfree]

Code: Alles auswählen

root@host:~# time ping -c 1 heise.de
PING heise.de(heise.de (2a02:2e0:3fe:1001:302::)) 56 data bytes
64 bytes from heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=1 ttl=56 time=26.9 ms

--- heise.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 26.936/26.936/26.936/0.000 ms

real    0m5,079s
user    0m0,000s
sys     0m0,008s
root@host:~#
root@host:~# time ping -c 1 heise.de
PING heise.de(heise.de (2a02:2e0:3fe:1001:302::)) 56 data bytes
64 bytes from heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=1 ttl=56 time=27.0 ms

--- heise.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.027/27.027/27.027/0.000 ms

real    0m0,051s
user    0m0,000s
sys     0m0,008s

Entweder ich sehe den Wald vor lauter Bäumen nicht oder du mißinterprätierst da etwas in deinem Ergebnis. Ich sehe da jedenfalls weder Timeouts noch lost Packets.

[paulpaulpaul]

Das interessante an dem Ping Beispiel war die Dauer der Ausführung. Deswegen der "time" Befehl vor dem Ping.

Der erste Ping an heise.de hat zum Ausführen 5,079 Sekunden gedauert.
Der selbe Ping beim zweiten Ausführen hat 0,051 Sekunden gedauert.

Beides Mal war der Ping erfolgreich, was auch nicht das Problem ist.

Der Unterschied ist darin begründet, dass beim ersten mal der DNS-Lookup aus einem mir noch nicht ersichtlichen Grund schief ging.

[MSfree]

Das interessante an dem Ping Beispiel war die Dauer der Ausführung. Deswegen der "time" Befehl vor dem Ping.

Das hatte ich auch gesehen.

Der Unterschied ist darin begründet, dass beim ersten mal der DNS-Lookup aus einem mir noch nicht ersichtlichen Grund schief ging.

Ich sehe keinen Anhaltspunkt dafür, daß ein DNS-Lookup schief gegangen ist. Die längere Ausführungszeit kann auch damit zusammenhängen, daß der erste Aufruf das Programm ping samt aller dazu benötigten shared Libraries ins RAM laden muß, beim zweiten Aufruf noch alles im Cache ist und somit viel schneller geht.

[paulpaulpaul]

5 Sekunden für

das Programm ping samt aller dazu benötigten shared Libraries ins RAM laden

Ganz so langsam ist der neue Rechner dann doch nicht.

Ausserdem sehe ich im tcpdump, dass hier 2x ein DNS-Lookup durchgeführt wird. Direkt nach dem zweiten Lookup wird das ICMP-Echo Paket versendet.

All dies deutet stark auf DNS Probleme hin, die auch bei anderen Programmen auftreten:

root@host:~# wget http://www.bild.de
--2019-09-12 15:30:30-- http://www.bild.de/
Auflösen des Hostnamens www.bild.de (www.bild.de)… 2.20.190.204, 2.20.190.142
Verbindungsaufbau zu www.bild.de (www.bild.de)|2.20.190.204|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently
Platz: https://www.bild.de/ [folgend]
--2019-09-12 15:30:35-- https://www.bild.de/
Verbindungsaufbau zu www.bild.de (www.bild.de)|2.20.190.204|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »index.html« gespeichert.

Auch hier wieder 5 Sekunden bis die Weiterleitung auf https aufgerufen wird 15:30:30 -> 15:30:35.

Dies kann ich bei nahezu allen Netzwerkprogrammen nachvollziehen.

Edit: Typo

[paulpaulpaul]

Ein tcpdump für einen Ping auf szon.de sieht z.b. wie folgt aus:

root@host:~# tcpdump host <ip dns server>
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp4s0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:36:27.622533 IP host.domainname.local.50844 > dns.domainname.local.domain: 53386+ A? szon.de. (25)
15:36:27.622558 IP host.domainname.local.50844 > dns.domainname.local.domain: 13460+ AAAA? szon.de. (25)
15:36:27.625091 IP host.domainname.local.49591 > dns.domainname.local.domain: 7878+ PTR? 254.0.16.172.in-addr.arpa. (43)
15:36:27.630931 IP dns.domainname.local.domain > host.domainname.local.49591: 7878 1/0/0 PTR dns.domainname.local. (79)
15:36:27.631267 IP host.domainname.local.36995 > dns.domainname.local.domain: 53361+ PTR? 13.0.16.172.in-addr.arpa. (42)
15:36:27.635276 IP dns.domainname.local.domain > host.domainname.local.36995: 53361 1/0/0 PTR host.domainname.local. (79)
15:36:27.649651 IP dns.domainname.local.domain > host.domainname.local.50844: 53386 1/0/0 A 213.182.22.30 (41)
15:36:32.627056 IP host.domainname.local.50844 > dns.domainname.local.domain: 53386+ A? szon.de. (25)
15:36:32.630222 IP dns.domainname.local.domain > host.domainname.local.50844: 53386 1/0/0 A 213.182.22.30 (41)
15:36:32.630379 IP host.domainname.local.50844 > dns.domainname.local.domain: 13460+ AAAA? szon.de. (25)
15:36:32.663405 IP dns.domainname.local.domain > host.domainname.local.50844: 13460 0/1/0 (92)
15:36:32.694611 IP host.domainname.local.57621 > dns.domainname.local.domain: 21477+ PTR? 30.22.182.213.in-addr.arpa. (44)
15:36:32.698408 IP dns.domainname.local.domain > host.domainname.local.57621: 21477 1/0/0 PTR szon.de. (65)
15:36:32.728316 ARP, Request who-has dns.domainname.local tell host.domainname.local, length 28
15:36:32.728963 ARP, Reply dns.domainname.local is-at a0:e0:af:bb:36:b2 (oui Unknown), length 46
^C
15 packets captured
15 packets received by filter
0 packets dropped by kernel
root@host:~#

[mludwig]

Was gibt denn direkt die Abfrage des DNS per nslookup oder dig aus? Vielleicht gibts wenigstens eine Fehlermeldung ...

[paulpaulpaul]

Leider finde ich auch hier nix konkretes. Allerdings sind die Abfragen auch so schnell wie erwartet:

Code: Alles auswählen

user@host:~$ time nslookup rtl.de
Server:         172.16.xx.xx
Address:        172.16.xx.xx#53

Non-authoritative answer:
Name:   rtl.de
Address: 80.92.65.53


real    0m0,076s
user    0m0,018s
sys     0m0,010s
user@host:~$ time dig sat1.de

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> sat1.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6849
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;sat1.de.                       IN      A

;; ANSWER SECTION:
sat1.de.                518     IN      A       195.30.111.130

;; Query time: 22 msec
;; SERVER: 172.16.xx.xx#53(172.16.xx.xx)
;; WHEN: Do Sep 12 17:22:35 CEST 2019
;; MSG SIZE  rcvd: 52


real    0m0,041s
user    0m0,017s
sys     0m0,000s

[MSfree]

Allerdings sind die Abfragen auch so schnell wie erwartet:

Der DNS-Server auf deinem Router cachet Anfragen. Wenn es überhaupt zu Verzögerungen kommt, dann nur für Adressen, die noch nicht oder nicht mehr im Cache des DNS-Server liegen.

Bei den meisten Routern ist eingestellt, den DNS-Server des Internetproviders zu nutzen. Wenn du mit deinem PC eine Adresse auflöst, fragt dieser den DNS des Routers, der wiederum die Anfrage an den DNS des Providers weiterleitet.

Die meisten Router kann man aber auch auf andere DNS umstellen. Dort könntest du ja mal 8.8.8.8 (Googles DNS) einstellen und shauen, ob das dein Geschwindigkeitsproblem löst. Ob 8.8.8.8 nun die beste Idee ist, sei mal dahingestellt, es gibt auch datanschutztechnisch weniger bedenkliche DNS-Anbieter im Internet.

[paulpaulpaul]

Das hat mit Cache oder kein Cache nichts zu tun, da der DNS Server des Router immer in wenigen Millisekunden antwortet. Dies ist mit dem tcpdump nachvollzogen.

Mein Windows-Rechner und mein Android-Phone verwenden den selben DNS-Server des Routers und bei diesen kommt es nicht zu den sekundenlagen Verzögerungen.

Es ist nur das Zusammenspiel des Routers mit meinem neuen Debian-Rechner.

Verwende ich auf dem Debian Rechner z.B. 8.8.8.8 sind die DNS Anfragen OK. Nur eben nicht, wenn diese vom DNS des Router kommen.
Alle anderen Hosts, die den Router als DNS-Server verwenden haben keine Probleme damit.

Was könnte mein Debian veranlassen, die erste Antwort des DNS Servers, welche ja auch ankommt, nicht zu nutzen?

[mludwig]

Naja, ohne Garantie stochere ich mal etwas im Nebel:
- der Client geht mit 2 Netzwerkkarten gleichzeitig online (z. B. Kabel und WLAN), das führt vielleicht zu solch seltsamen Verhalten?
- es gibt noch einen Client mit der gleichen IP im Netz -> das sollte im tcpdump zu sehen sein, indem man die MAC von Anfrage und Antwort vergleicht, Parameter tcpdump -e zusätzlich angeben.
- auf dem Router ist die MAC fest eingetragen, aber falsch (alter Client mit identischer IP)

Alles wenig wahrscheinlich ... aber prüfen kann man es trotzdem, geht ja schnell.

[paulpaulpaul]

Muss bei allen Drei Vermutungen mit einem klaren "Nein" antworten.

Der Debian Rechner hat nur eine Netzwerkschnittstelle:

Code: Alles auswählen

user@host:~$  ip link list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 10:7b:44:4d:04:9b brd ff:ff:ff:ff:ff:ff

Die IP-Adresse ist fest hinterlegt, kein DHCP.

Doppele IP-Adressen würde der Router erkennen und melden. Auch ein längerer tcpdump zeigt keine Ausfälligkeiten in diese Richtung.

[dufty2]

Der Unterschied zwischen "ping/sonstwas" und "nslookup/dig" bei der Namensauflösung besteht darin,
dass erstere /etc/nsswitch.conf und ggf. /etc/hosts benutzen.
Kannst Dir ja beide mal anschauen, bei nsswitch.conf insbesondere die Zeile:
hosts: files dns myhostname

[paulpaulpaul]

Beide Files hatte ich mir schon näher angeschaut. Bleibe aber ratlos zurück:

Code: Alles auswählen

root@plug:~# cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       host.domain.local host

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
root@host:~#

Code: Alles auswählen

root@host:~# cat /etc/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:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Ich habe mal "myhostname" in die hosts-Zeile mit eingetragen, jedoch ohne Erfolg. Wobei ich gestehen muss den Sinn von "myhostname" auch noch nicht verstanden zu haben.

Mit meiner Konfig sollten die entsprechenden Libs den Hostname doch zuerst im File "/etc/hosts" nachschauen und dann erst beim DNS anfragen.

Das machen die Libs scheinbar auch, nur wollen sie die erste Antwort des DNS nicht nutzen .

[dufty2]

Mmmh, man könnte jetzt noch ein

Code: Alles auswählen

# strace ping -c 1 heise.de

und die Ausgabe mit der bei der Verwendung von 8.8.8.8 als nameserver vergleichen.
Das wird aber schon heftig

[paulpaulpaul]

Hmm,

jetzt stoss ich auf Dinge, die ich nicht wirklich sicher verstehe. Ich bin zwar Netzwerktechniker, aber das geht mir nun doch zuweit in Richtung Programmierung....

Ich habe einen strace nun 2 Mal durchgeführt:

strace ping -c 1 zdf.de > 1.strace 2>&1
strace ping -c 1 zdf.de > 2.strace 2>&1

Da die Abfrage ja beim zweiten Mal immer klappt.

im File 1.strace stosse ich auf folgende Zeilen:

Code: Alles auswählen

connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.xx.xx")}, 16) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendmmsg(5, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="v\21\1\0\0\1\0\0\0\0\0\0\3zdf\2de\0\0\1\0\1", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=24}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\322\25\1\0\0\1\0\0\0\0\0\0\3zdf\2de\0\0\34\0\1", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=24}], 2, MSG_NOSIGNAL) = 2
poll([{fd=5, events=POLLIN}], 1, 5000)  = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [40])                = 0
recvfrom(5, "v\21\201\200\0\1\0\1\0\0\0\0\3zdf\2de\0\0\1\0\1\300\f\0\1\0\1\0\0"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.xx.xx")}, [28->16]) = 40
poll([{fd=5, events=POLLIN}], 1, 4972)  = 0 (Timeout)
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "v\21\1\0\0\1\0\0\0\0\0\0\3zdf\2de\0\0\1\0\1", 24, MSG_NOSIGNAL, NULL, 0) = 24
poll([{fd=5, events=POLLIN}], 1, 5000)  = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [40])                = 0
recvfrom(5, "v\21\201\200\0\1\0\1\0\0\0\0\3zdf\2de\0\0\1\0\1\300\f\0\1\0\1\0\0"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.xx.xx")}, [28->16]) = 40
poll([{fd=5, events=POLLOUT}], 1, 4985) = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "\322\25\1\0\0\1\0\0\0\0\0\0\3zdf\2de\0\0\34\0\1", 24, MSG_NOSIGNAL, NULL, 0) = 24
poll([{fd=5, events=POLLIN}], 1, 4985)  = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [83])                = 0
recvfrom(5, "\322\25\201\200\0\1\0\0\0\1\0\0\3zdf\2de\0\0\34\0\1\300\f\0\6\0\1\0\0"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.16.xx.xx")}, [28->16]) = 83
close(5)  

Man sieht, dass die erste Anfrage auf einen Timeout stösst.

Das habe ich im zweiten trace nicht mehr.

Wir wissen nun, dass die Anfrage an den DNS-Server raus geht, laut tcpdump auch zurückkommt. Aber die Antwort bleibt der Applikation verborgen.

Habe ich eventuell einen Bug getroffen?

[mat6937]

Ausserdem sehe ich im tcpdump, dass hier 2x ein DNS-Lookup durchgeführt wird.

Der 1. DNS-Lookup für den A-Record und der 2. DNS-Lookup für den AAAA-Record?

Versuch mal:

Code: Alles auswählen

time ping6 -c 1 ubuntuusers.de

oder mit:

Code: Alles auswählen

ping -4 -c 1 ubuntuusers.de

EDIT:

Versuch mal auch mit statischem (permanentem) neighbour-cache-Eintrag (für v4/arp und für v6/icmp6) für deinen Router.

EDIT 2:

Warum entscheidet sich auf deinem Gerät, ping (ohne "-4" und ohne "-6") nur für die IPv6-Adresse von heise.de, und nicht für die IPv4-Adresse (siehe deinen 1. Beitrag)?

[eggy]

Hilft jetzt nicht bei dem akuten Problem, aber wozu soll hier das Anonymisieren von lokalen Adressen gut sein?
Mit ner 172.16er kann nen Angreifer von außen nix anfangen (und von innen her leuchtet nen DNS im Gesamttraffic wie nen Weihnachtsbaum, den bekommst eh nicht versteckt)

Auch wenns wahrscheinlich unwahrscheinlich ist, irgendwas komisches im Bereich iptables und co?

[paulpaulpaul]

Der 1. DNS-Lookup für den A-Record und der 2. DNS-Lookup für den AAAA-Record?

Das war zweimal ein A-Record Lookup mit 5 Sekunden Abstand. siehe tcpdump in der 5/6 Antwort.

Wenn vor dem ping ein ping6 durchgeführt wird, klappt der Ping mit v4 ohne Verzögerung:

Code: Alles auswählen

root@host:~# time ping6 -c 1 ubuntuusers.de
PING ubuntuusers.de(ubuntuusers.de (2001:780:0:25:dead:beef:cafe:1)) 56 data bytes
64 bytes from ubuntuusers.de (2001:780:0:25:dead:beef:cafe:1): icmp_seq=1 ttl=58 time=22.9 ms

--- ubuntuusers.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 22.889/22.889/22.889/0.000 ms

real    0m0,071s
user    0m0,001s
sys     0m0,008s
root@host:~# time ping -4 -c 1 ubuntuusers.de
PING ubuntuusers.de (213.95.41.4) 56(84) bytes of data.
64 bytes from ubuntuusers.de (213.95.41.4): icmp_seq=1 ttl=59 time=22.1 ms

--- ubuntuusers.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 22.068/22.068/22.068/0.000 ms

real    0m0,058s
user    0m0,000s
sys     0m0,007s

Was soll der statische ARP/ND-Eintrag bringen? Die Anfrage kommt auch bei der ersten Anfrage bis zum DNS-Server und zurück, nur leider nicht im Stack bis zur Applikation.

Moderne Programme die IPv6 können bevorzugen IPv6 vor IPv4. Das Verhalten empfinde ich durchaus als korrekt. Mein Netzwerk ist vollständig IPv6 fähig.

IPtables oder lokale Firewall ist nicht installiert. Bei der Neuinstallation wurde nur "SSH-Server" als Paketvorwahl getroffen. Wenige ausgewählte Pakete habe ich mit apt noch nachinstalliert.

Anonymisieren von meinen Adressen: wird immer gemacht, egal ob Public/Privat/Link Local...

Ich fasse mal zusammen, mit welchen Programmen ich den "DNS-Timeout" bis jetzt bemerkt habe:

- ping
- wget
- ssh
- telnet

Bei folgenden Programmen konnte ich den Effekt nicht wahrnehmen:

- ping6
- nslookup
- dig

[mat6937]

Der 1. DNS-Lookup für den A-Record und der 2. DNS-Lookup für den AAAA-Record?

Das war zweimal ein A-Record Lookup mit 5 Sekunden Abstand.

Ich meine deinen 1. Beitrag. Zweimal einen A-Record und danach keinen AAAA-Record, aber der ping wird dann doch mit der IPv6-Adresse gemacht? Das verstehe ich nicht. Oder war da noch ein 3. DNS-Lookup für den AAAA-Record?

Wenn vor dem ping ein ping6 durchgeführt wird, klappt der Ping mit v4 ohne Verzögerung:

Wie sind die Ausgaben von:

Code: Alles auswählen

ip n s && ping -c 1 debianforum.de
ip n s && ping6 -c 1 debianforum.de
ip n s && ping -4 -c 1 debianforum.de

?

Moderne Programme die IPv6 können bevorzugen IPv6 vor IPv4. Das Verhalten empfinde ich durchaus als korrekt. Mein Netzwerk ist vollständig IPv6 fähig.

Ja, das ist ja gut und richtig. Aber deshalb ist ping als tool zum testen von DNS (Namensauflösung) völlig ungeeignet.
Besser mit den klassischen dns-tools (dig, host, nslookup & Co.) testen, statt mit ping.
Aber dir geht es ja nicht um DNS, sondern um die Verzögerung beim Ping.

EDIT:

Ich fasse mal zusammen, mit welchen Programmen ich den "DNS-Timeout" bis jetzt bemerkt habe:

- ping
- wget
- ssh
- telnet

Bei folgenden Programmen konnte ich den Effekt nicht wahrnehmen:

- ping6
- nslookup
- dig
[/quotr]

Evtl. auch dazu schreiben, wann bzw. mit welchen Programmen IPv4 und wann btw. mit welchen Programmen IPv6 verwendet wird. Evtl. auch testen, wann vor der Namensauflösung durch den Router, auch ein arp-request (... der ja auch verzögern kann) an den Router gemacht wird und warum dieser gemacht wird:

Code: Alles auswählen

tcpdump -c 100 -vvveni <Interface> arp

EDIT 2:

BTW: Für den Router bzw. lokalen DNS-Server ändere ich immer den "nud state" für den neighbour entry/arp-cache auf permanent:

Code: Alles auswählen

:~ $ cat /etc/resolv.conf
# Generated by resolvconf
search fritz.box
nameserver 192.168.178.1
nameserver fd00::c225:6ff:fe2b:52de

Code: Alles auswählen

:~ $ ip n s
192.168.178.22 dev wlan0 lladdr 48:02:2a:17:62:b4 REACHABLE
192.168.178.1 dev wlan0 lladdr c0:25:06:2b:52:de PERMANENT
fe80::c225:6ff:fe2b:52de dev wlan0 lladdr c0:25:06:2b:52:de router STALE
fd00::c225:6ff:fe2b:52de dev wlan0 lladdr c0:25:06:2b:52:de router PERMANENT

[paulpaulpaul]

OK, um arp/nd mal auszuschliessen, habe ich die Neigbor mal statisch gesetzt:

Code: Alles auswählen

root@host:~# ip n s
172.16.yy.yy dev enp4s0 lladdr e0:3f:49:0d:b9:08 REACHABLE   (<- PC mit SSH auf die Debian-Box)
172.16.xx.xx dev enp4s0 lladdr a0:e0:af:bb:36:b2 PERMANENT
xxx:xxx:xxx:xxx:xxx:xx:xx:xxx dev enp4s0 lladdr a0:e0:af:bb:36:b2 PERMANENT

Damit kommt uns das ARP-Thema mal sicher nicht mehr in die Quere. Aber leider auch ohne Verbesserung. Dabei ist es egal, ob das Ziel ein IPv4 oder IPv6 Ziel ist:

Anbei jeweils ein ping für ipv4 und ipv6. Jeweils mit einem tcpdump auf die MAC-Adresse des Routers/DNS:

Code: Alles auswählen

root@host:~# time ping -c 1 debian.org
PING debian.org(debian.org (2001:4f8:1:c::15)) 56 data bytes
64 bytes from debian.org (2001:4f8:1:c::15): icmp_seq=1 ttl=50 time=164 ms

--- debian.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 163.551/163.551/163.551/0.000 ms

real    0m5,221s
user    0m0,004s
sys     0m0,005s


root@host:~# tcpdump -c 100 -vvveni enp4s0 ether host a0:e0:af:bb:36:b2
tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:29:05.839271 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 18196, offset 0, flags [DF], proto UDP (17), length 56)
    172.16.ho.st.36364 > 172.16.dns.dns.53: [udp sum ok] 29343+ A? debian.org. (28)
12:29:05.839296 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 18197, offset 0, flags [DF], proto UDP (17), length 56)
    172.16.ho.st.36364 > 172.16.dns.dns.53: [udp sum ok] 12714+ AAAA? debian.org. (28)
12:29:05.863579 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 255, id 38168, offset 0, flags [none], proto UDP (17), length 120)
    172.16.dns.dns.53 > 172.16.ho.st.36364: [udp sum ok] 29343 q: A? debian.org. 4/0/0 debian.org. [7s] A 128.31.0.62, debian.org. [7s] A 130.89.148.14, debian.org. [7s] A 149.20.4.15, debian.org. [7s] A 5.153.231.4 (92)
12:29:10.843969 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 18703, offset 0, flags [DF], proto UDP (17), length 56)
    172.16.ho.st.36364 > 172.16.dns.dns.53: [udp sum ok] 29343+ A? debian.org. (28)
12:29:10.846939 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 134: (tos 0x0, ttl 255, id 38169, offset 0, flags [none], proto UDP (17), length 120)
    172.16.dns.dns.53 > 172.16.ho.st.36364: [udp sum ok] 29343 q: A? debian.org. 4/0/0 debian.org. [2s] A 128.31.0.62, debian.org. [2s] A 130.89.148.14, debian.org. [2s] A 149.20.4.15, debian.org. [2s] A 5.153.231.4 (92)
12:29:10.847111 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 18704, offset 0, flags [DF], proto UDP (17), length 56)
    172.16.ho.st.36364 > 172.16.dns.dns.53: [udp sum ok] 12714+ AAAA? debian.org. (28)
12:29:10.875037 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 182: (tos 0x0, ttl 255, id 38170, offset 0, flags [none], proto UDP (17), length 168)
    172.16.dns.dns.53 > 172.16.ho.st.36364: [udp sum ok] 12714 q: AAAA? debian.org. 4/0/0 debian.org. [4m55s] AAAA 2001:4f8:1:c::15, debian.org. [4m55s] AAAA 2001:67c:2564:a119::148:14, debian.org. [4m55s] AAAA 2001:41c8:1000:21::21:4, debian.org. [4m55s] AAAA 2603:400a:ffff:bb8::801f:3e (140)
12:29:10.876204 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 132: (tos 0x0, ttl 64, id 18705, offset 0, flags [DF], proto UDP (17), length 118)
    172.16.ho.st.33341 > 172.16.dns.dns.53: [udp sum ok] 43586+ PTR? 5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.1.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa. (90)
12:29:10.882482 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 156: (tos 0x0, ttl 255, id 38171, offset 0, flags [none], proto UDP (17), length 142)
    172.16.dns.dns.53 > 172.16.ho.st.33341: [udp sum ok] 43586 q: PTR? 5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.1.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa. 1/0/0 5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.1.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa. [4m54s] PTR debian.org. (114)
12:29:10.883320 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv6 (0x86dd), length 118: (flowlabel 0x274ea, hlim 64, next-header ICMPv6 (58) payload length: 64) xxx:xxx:xxx::host > 2001:4f8:1:c::15: [icmp6 sum ok] ICMP6, echo request, seq 1
12:29:11.046812 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv6 (0x86dd), length 118: (flowlabel 0xd8b2b, hlim 50, next-header ICMPv6 (58) payload length: 64) 2001:4f8:1:c::15 > xxx:xxx:xxx::host: [icmp6 sum ok] ICMP6, echo reply, seq 1
12:29:11.047243 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 132: (tos 0x0, ttl 64, id 18735, offset 0, flags [DF], proto UDP (17), length 118)
    172.16.ho.st.50547 > 172.16.dns.dns.53: [udp sum ok] 4722+ PTR? 5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.1.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa. (90)
12:29:11.053970 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 156: (tos 0x0, ttl 255, id 38172, offset 0, flags [none], proto UDP (17), length 142)
    172.16.dns.dns.53 > 172.16.ho.st.50547: [udp sum ok] 4722 q: PTR? 5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.1.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa. 1/0/0 5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.1.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa. [4m54s] PTR debian.org. (114)
^C
13 packets captured
13 packets received by filter
0 packets dropped by kernel

#########################################################################################
root@plug:~# time ping -c 1 suse.de
PING suse.de (130.57.66.19) 56(84) bytes of data.
64 bytes from suse.de (130.57.66.19): icmp_seq=1 ttl=46 time=175 ms

--- suse.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 175.345/175.345/175.345/0.000 ms

real    0m5,292s
user    0m0,004s
sys     0m0,004s


root@plug:~# tcpdump -c 100 -vvveni enp4s0 ether host a0:e0:af:bb:36:b2
tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:30:54.597446 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 67: (tos 0x0, ttl 64, id 42552, offset 0, flags [DF], proto UDP (17), length 53)
    172.16.ho.st.40524 > 172.16.dns.dns.53: [udp sum ok] 30906+ A? suse.de. (25)
12:30:54.597474 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 67: (tos 0x0, ttl 64, id 42553, offset 0, flags [DF], proto UDP (17), length 53)
    172.16.ho.st.40524 > 172.16.dns.dns.53: [udp sum ok] 1731+ AAAA? suse.de. (25)
12:30:54.646988 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 83: (tos 0x0, ttl 255, id 38186, offset 0, flags [none], proto UDP (17), length 69)
    172.16.dns.dns.53 > 172.16.ho.st.40524: [udp sum ok] 30906 q: A? suse.de. 1/0/0 suse.de. [54m35s] A 130.57.66.19 (41)
12:30:59.602556 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 67: (tos 0x0, ttl 64, id 42907, offset 0, flags [DF], proto UDP (17), length 53)
    172.16.ho.st.40524 > 172.16.dns.dns.53: [udp sum ok] 30906+ A? suse.de. (25)
12:30:59.605734 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 83: (tos 0x0, ttl 255, id 38187, offset 0, flags [none], proto UDP (17), length 69)
    172.16.dns.dns.53 > 172.16.ho.st.40524: [udp sum ok] 30906 q: A? suse.de. 1/0/0 suse.de. [54m30s] A 130.57.66.19 (41)
12:30:59.605882 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 67: (tos 0x0, ttl 64, id 42908, offset 0, flags [DF], proto UDP (17), length 53)
    172.16.ho.st.40524 > 172.16.dns.dns.53: [udp sum ok] 1731+ AAAA? suse.de. (25)
12:30:59.699514 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 144: (tos 0x0, ttl 255, id 38188, offset 0, flags [none], proto UDP (17), length 130)
    172.16.dns.dns.53 > 172.16.ho.st.40524: [udp sum ok] 1731 q: AAAA? suse.de. 0/1/0 ns: suse.de. [15m] SOA ns1.softwaregrp.com. hostmaster.microfocus.com. 2004134158 10800 3600 2419200 900 (102)
12:30:59.700296 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 1872, offset 0, flags [DF], proto ICMP (1), length 84)
    172.16.ho.st > 130.57.66.19: ICMP echo request, id 1364, seq 1, length 64
12:30:59.875610 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 46, id 13528, offset 0, flags [DF], proto ICMP (1), length 84)
    130.57.66.19 > 172.16.ho.st: ICMP echo reply, id 1364, seq 1, length 64
12:30:59.876066 10:7b:44:4d:04:9b > a0:e0:af:bb:36:b2, ethertype IPv4 (0x0800), length 85: (tos 0x0, ttl 64, id 42959, offset 0, flags [DF], proto UDP (17), length 71)
    172.16.ho.st.56161 > 172.16.dns.dns.53: [udp sum ok] 38833+ PTR? 19.66.57.130.in-addr.arpa. (43)
12:30:59.882327 a0:e0:af:bb:36:b2 > 10:7b:44:4d:04:9b, ethertype IPv4 (0x0800), length 106: (tos 0x0, ttl 255, id 38189, offset 0, flags [none], proto UDP (17), length 92)
    172.16.dns.dns.53 > 172.16.ho.st.56161: [udp sum ok] 38833 q: PTR? 19.66.57.130.in-addr.arpa. 1/0/0 19.66.57.130.in-addr.arpa. [54m29s] PTR suse.de. (64)
^C
11 packets captured
12 packets received by filter
0 packets dropped by kernel

[paulpaulpaul]

Bin soeben noch zu einer neuen Erkenntnis gekommen, die für das Problem sicherlich relevant ist:

Sobald dem Programm mitgeteilt wird, mit welchem Protokoll die Verbindung aufgebaut werden soll, entfällt die 5 Sekunden Pause.

Also "ping -c 1 -4 irgendwas" wird sofort ausgeführt. Ebenso in der IPv6 Variante.

Den selben Effekt kann ich mit wget und ssh auch verifizieren.

[mat6937]

Sobald dem Programm mitgeteilt wird, mit welchem Protokoll die Verbindung aufgebaut werden soll, entfällt die 5 Sekunden Pause.

Evtl. kannst Du das bevorzugte Verhalten der Programme, für den Fall das IPv6 und IPv4 möglich ist, ändern.
Mit Hilfe der Datei "/etc/gai.conf", so dass IPv4 vor IPv6 verwendet wird. Wenn ja, ist dann die 5 Sekunden Pause noch vorhanden?

[paulpaulpaul]

Leider nein, jetzt wird heise.de zwar im ping mit IPv4 angesprochen, aber trotzdem mit 5 Sekunden Verzögerung.

(Wäre als Lösung für mich auch nicht wirklich OK gewesen, aber Danke, mal wieder eine neue Konfig-Datei kennengelernt.)

[mat6937]

Leider nein, jetzt wird heise.de zwar im ping mit IPv4 angesprochen, aber trotzdem mit 5 Sekunden Verzögerung.

Damit ist ja auch nur das Standard-Verhalten für die Entscheidung ob IPv4 oder IPv6 bevorzugt werden soll, verändert worden.
D. h., immer wenn das Programm (z. B. ping) die Wahl zwischen IPv4 und IPv6 hat und unabhängig vom Standard-Verhalten, gibt es die 5 Sekunden Pause.