[Gelöst] Timeout bei der ersten DNS Anfrage

[mat6937]

Als Erkenntnisgewinn sicherlich hilfreich, aber mein IPv6 wäre mir doch wichtig, da der Remote-Zugang, wenn ich nicht zu Hause bin über IPv6 realisiert ist.

Ja klar, war ja auch nur als temporärer Test gemeint und das Ergebnis ist auch nicht überraschend.

Sagen wir mal so, frühestens in ca. 20 bis 30 Jahren, wenn es kein IPv4 mehr gibt, wird dieses Problem auch gelöst sein.

[paulpaulpaul]

Nur was mache ich bis dahin?

[mat6937]

Nur was mache ich bis dahin?

Dort wo möglich, genau konfigurieren bzw. der Anwendung mitteilen, ob IPv4 oder IPv6 verwendet werden soll.

[paulpaulpaul]

Hmm, nicht wirklich befriedigend die Aussicht, zumal andere Hosts in dem Netz keine Probleme haben.

Ich habe mir gerade mit Wireshark mein Windows angeschaut. Dort wird per IPv6 nach AAAA gefragt, mit IPv4 nach A und beides Mal kommt sofort eine korrekte Antwort, die die App dann auch wie erwartet verwendet.

Aktuell hab ich meinen Router etwas in verdacht, der bekommt gerade ein SW-Update, sobald der Download fertig ist.

[mat6937]

... mein Windows angeschaut. Dort wird per IPv6 nach AAAA gefragt, mit IPv4 nach A und beides Mal kommt sofort eine korrekte Antwort, die die App dann auch wie erwartet verwendet.

Aber die korrekte Antwort geht auch mit v4 für AAAA bzw. mit v6 für A:

Code: Alles auswählen

:~ $ dig -4 aaaa heise.de +short
2a02:2e0:3fe:1001:302::

Code: Alles auswählen

:~ $ dig -6 a heise.de +short
193.99.144.80

Das kann nicht die Ursache sein.

[paulpaulpaul]

Ich habe scheinbar den Übeltäter gefunden. Nachdem mein Router ein Software Update erhalten hat, ist das Problem weg.

Allerdings denke ich gerade noch darüber nach, ob das Verhalten welches Debian hier gezeigt hat so korrekt/optimal ist.

Aus meiner Sicht:

1. App möchte Netzverbindung öffnen
2. App fragt nach A und AAAA Record
3. DNS antwortet nur auf eine Anfrage, die zweite Anfrage bleibt unbeantwortet, wobei "Es gibt kein AAAA-Record" auch eine Antwort wäre.
4. App wartet auf beide Antworten, die aber nicht kommen. => Timeout von 5 Sekunden
5. App frägt wieder nach A und AAAA Record
6. DNS beantwortet beide Anfragen
7. App kann Netzverbindung herstellen
8. ...

Scheinbar lösen das andere Betriebsysteme wie Windows oder Android besser, wobei ich aktuell nicht genauer sagen kann WIE diese das besser lösen.

Ich frage mich nur, warum Debian die eine Antwort, die es erhält, nicht nutzt.

Trotzdem: Vielen Dank ans Forum!

[mat6937]

2. App fragt nach A und AAAA Record
3. DNS antwortet nur auf eine Anfrage, die zweite Anfrage bleibt unbeantwortet, wobei "Es gibt kein AAAA-Record" auch eine Antwort wäre.
4. App wartet auf beide Antworten, die aber nicht kommen. => Timeout von 5 Sekunden

Aber das Problem wäre dann dein DNS-Server. Teste mal mit dem dns-tool host (UDP und TCP):

Code: Alles auswählen

host ubuntuusers.de <IP-Adresse-Router>
host -T ubuntuusers.de <IP-Adresse-Router>

Mit tcpdump kannst Du sniffen, um zu sehen wie der Router auf die Anfrage reagiert.

EDIT:

host fragt nach A und AAAA. Z. B.:

Code: Alles auswählen

:~ $ host ubuntuusers.de 192.168.178.1
Using domain server:
Name: 192.168.178.1
Address: 192.168.178.1#53
Aliases: 

ubuntuusers.de has address 213.95.41.4
ubuntuusers.de has IPv6 address 2001:780:0:25:dead:beef:cafe:1
ubuntuusers.de mail is handled by 10 mx1.ubuntu-de.org.
ubuntuusers.de mail is handled by 20 mx2.ubuntu-de.org.

[paulpaulpaul]

Da mein Router nun das Update hat, werden Tests sehr aufwändig. Diese Mühen möchte ich mir doch sparen.

Ja, es ist korrekt, das sich mein Router bis vor wenigen Minuten wohl falsch verhalten hat. Allerdings gehen andere Betriebsysteme mit diesem Fehler toleranter um. Und ab diesem Zeitpunkt wird es wohl philosophisch über die korrekte Vorgehensweise zu diskutieren.

[unitra]

Dann setze den Thread bitte auf gelöst.

Da mein Router nun das Update hat, werden Tests sehr aufwändig. Diese Mühen möchte ich mir doch sparen.

Ja, es ist korrekt, das sich mein Router bis vor wenigen Minuten wohl falsch verhalten hat. Allerdings gehen andere Betriebsysteme mit diesem Fehler toleranter um. Und ab diesem Zeitpunkt wird es wohl philosophisch über die korrekte Vorgehensweise zu diskutieren.

[paulpaulpaul]

Meintest du, dass ich wie soeben durchgeführt, im ersten Post den Betreff ändern soll?

Wäre sicherlich hilfreich in den FAQs oder mit einer netten Erweiterung für das Board. Ich konnte diesbezüglich leider nichts finden.

Oder verstehe ich was falsch?

[eggy]

"[gelöst]" (oder irgendwas ähnliches) in den Titel des ersten Postings zu malen ist hier schon die richtige Lösung. Die Boardsoftware kanns halt nicht von Haus aus, und zusätzliches Zeug bringt zusätzlichen Wartungsaufwand und Angriffsfläche, was nicht da ist, kann auch nicht kaputtgehen.

Zum Thema:
https://unix.stackexchange.com/question ... -5-seconds
Demnach sollte es helfen "options single-request-reopen" in die /etc/resolv.conf zu malen bzw "precedence ::ffff:0:0/96 100" in /etc/gai.conf anzupassen.

[mat6937]

Allerdings gehen andere Betriebsysteme mit diesem Fehler toleranter um.

Naja, was bei diesem OS mit einem "Workaround" (... oder ist es doch ganz normale Konfiguration und keine Notlösung?) gelöst werden muss/soll, ist bei den "toleranten" OSs evtl. schon Standard-Konfiguration. ... was zur Folge hat, dass man so manches dann nicht mitbekommt.

Z. B. auch evtl. hardcodiertes "dns-over-https" (oder gleichwertig):

Code: Alles auswählen

:~ $ doh heise.de
heise.de from https://1.1.1.1/dns-query
TTL: 7254 seconds
A: 193.99.144.80
AAAA: 2a02:02e0:03fe:1001:0302:0000:0000:0000