Fritzbox 6591: Verbindung zum Internet bricht ab - nur Neustart hilft

frank_m24

IPPF-Urgestein
Mitglied seit
20 Aug 2005
Beiträge
18,356
Punkte für Reaktionen
151
Punkte
63
Kannst ja Testweise mal 1.1.1.1 oder 8.8.8.8 als DNS im Client probieren, also am PC oder Laptop ob es dann geht.
Genau das würde ich auch vorschlagen. Außerdem kann man in der Fritzbox mal andere DNS Server eintragen oder mit DoT testen. Darüber hinaus würde ich für ein ordentliches IPv6 Setup sorgen, inkl. geeigneter DNS Server.
 

Der D

Neuer User
Mitglied seit
6 Nov 2021
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Hallo

Danke für die rasche Antwort.
Wie muss ich das verstehen? Den DNS Client am Netzwerkgerät einstellen? Nicht im Router (Fritzbox)?
Würde ja bedeuten, das ich alle Netzwerkgeräte übersteuern müsse???

Die Supportdatei habe ich schon erstellt ;-) Danke aber für den Hinweis.
 

HabNeFritzbox

IPPF-Urgestein
Mitglied seit
12 Dez 2017
Beiträge
19,227
Punkte für Reaktionen
779
Punkte
113
Zu Testzwecken kannst ja wenn Problem besteht erstmal ein Gerät "übersteuern" und dort manuell den DNS setzen.

Kannst auch versuchen Google zu besuchen http://172.217.16.67 oder ne öffentliche Webcam http://60.122.194.196:81/CgiStart?page=Single&Language=9 oder andere Dienste welche per IP nutzbar sind.

@frank_m24 Wurde doch schon in FB geändert, diese macht wohl aber Probleme DNS Antworten herauszugeben, und so "kein Internet" ist.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,331
Punkte für Reaktionen
1,422
Punkte
113
nur eben nicht mehr die DNS Auflösung in der FB.
Woher kommt denn bitte immer wieder diese Annahme? Habe ich irgendein nslookup oder etwas Gleichwertiges übersehen, was diese These untermauern könnte?

Die diversen OS stellen fest, ob eine Internetverbindung besteht, indem sie bestimmte Ziele im Internet kontaktieren - wie das bei Windows aussieht (und zwar für unterschiedliche Versionen), kann man z.B. hier: https://docs.microsoft.com/de-de/tr...er-edge-open-connect-corporate-public-network nachlesen (im Abschnitt "Aktive NCSI-Prüfpunkte und die Netzwerkstatuswarnung"). Andere OS verwenden andere Ziele - selbst Browser machen heute eigene Tests, um z.B. Portalseiten mit der Notwendigkeit einer Anmeldung zu identifizieren.

Solange man also nur auf irgendwelche "Internet-Anzeigen" vertraut und daraus den Schluß zieht, das Internet wäre generell nicht verfügbar, kann man auch gleich zur Wahrsagerin gehen. Wenn man die Fehlerquelle tatsächlich SUCHEN will (woran ich langsam Zweifel bekomme), dann muß man schon selbst hingehen und entsprechende Tests machen, bei denen die notwendigen Operationen für eine erfolgreiche HTTP-Verbindung (um mal beim Browser zu bleiben, obwohl ja immer noch niemand zur Kenntnis nehmen will, daß schon in #1 die Domain avm.de noch aufgelöst werden konnte und zwar VOR dem Neustart - ja, es war sogar noch eine HTTP(S)-Verbindung dorthin möglich) in die einzelnen Schritte zerlegt werden und das dann auch nicht nur gegen irgendwelche (in meinen Augen sinnfreien) Adressen von DNS-Servern, sondern gegen einen Mix aus passenden Namen UND Adressen.

Dazu muß man dann halt auch VOR dem Problem schon mal tätig werden und sich die IP-Adressen passender Services heraussuchen - z.B. von heise.de, denn deren Seiten kann man auch mit Angabe der IP-Adresse aufrufen, was dann den DNS-Teil umgeht und erst wenn das funktioniert, aber mit dem Namen nicht, dann gäbe es irgendwelche plausiblen Gründe, den DNS-Service zu verdächtigen.
Rich (BBCode):
[email protected]:~> nslookup heise.de.
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   heise.de
Address: 193.99.144.80
Name:   heise.de
Address: 2a02:2e0:3fe:1001:302::

[email protected]:~> nslookup heise.de. 83.169.184.33 <=== noch einmal, diesmal direkt beim DNS-Server von Vodafone (KDG)
Server:         83.169.184.33
Address:        83.169.184.33#53

Non-authoritative answer:
Name:   heise.de
Address: 193.99.144.80
Name:   heise.de
Address: 2a02:2e0:3fe:1001:302::

[email protected]:~> wget -O - --no-check-certificate https://193.99.144.80/index.html | wc -
--2021-11-15 19:37:02--  https://193.99.144.80/index.html
Connecting to 193.99.144.80:443... connected.
    WARNING: certificate common name 'redirector.heise.de' doesn't match requested host name '193.99.144.80'.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.heise.de/index.html [following]
--2021-11-15 19:37:02--  https://www.heise.de/index.html
Resolving www.heise.de (www.heise.de)... 193.99.144.85, 2a02:2e0:3fe:1001:7777:772e:2:85
Connecting to www.heise.de (www.heise.de)|193.99.144.85|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.heise.de/ [following]
--2021-11-15 19:37:02--  https://www.heise.de/
Reusing existing connection to www.heise.de:443.
HTTP request sent, awaiting response... 200 OK
Length: 701752 (685K) [text/html]
Saving to: 'STDOUT'

-                                                           100%[=====================================] 685.30K  2.30MB/s    in 0.3s

2021-11-15 19:37:03 (2.30 MB/s) - written to stdout [701752/701752]

  22025   35319  701752 -
[email protected]:~>
Und so etwas kann man dann (wenn jetzt Konsens bestehen sollte, daß es eher kein ARP-Problem sein wird) auch für unterschiedliche Ziele machen - wie oben schon mal geschrieben, auch für solche, die noch vor dem Edge-Router des Providers liegen (wie z.B. seine DNS-Server, die stehen üblicherweise "lokal").

Ich gebe mich natürlich sofort geschlagen, wenn mir IRGENDJEMAND eine plausible(!) Erklärung dafür anbieten kann, warum in #1 der Zugriff auf avm.de auch im Fehlerfall noch funktioniert hat - wobei man die auch schon von mir beschriebene "Theorie", daß aus irgendwelchen Gründen noch ein aktueller Eintrag für avm.de in irgendeinem DNS-Cache herumhing, in Anbetracht der beschriebenen Umstände in #1 (nach längerer Abwesenheit erst nach Hause gekommen und es ging nichts mehr) auch eher als unwahrscheinlich einstufen müßte.

Aber auch das läßt sich ja problemlos im Fehlerfall prüfen, indem man mal eine DNS-Abfrage für irgendeine, ansonsten nicht genutzte Domain macht - auch da müßte man sich natürlich zuvor (und zwar ausreichend lange vor dem Problem oder man muß die Box danach neu starten, denn der DNS-Cache im FRITZ!OS hebt die Einträge sonst auch selbst so lange auf, wie es ihm sein Upstream mit der TTL für den Eintrag vorgibt:
Rich (BBCode):
~ # aicmd multid dnsd flush
~ # aicmd multid dnsd cache
~ # nslookup heise.de.
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      heise.de.
Address 1: 2a02:2e0:3fe:1001:302:: redirector.heise.de
Address 2: 193.99.144.80 redirector.heise.de
~ # aicmd multid dnsd cache
heise.de IN AAAA ;; hashval 695, flags 0 (expire in 84575 secs)
   ;; status: NOERROR, flags: qr rd ra
   ;; ANSWER SECTION (1):
   heise.de                 84576 IN AAAA  2a02:2e0:3fe:1001:302::

heise.de IN A ;; hashval 668, flags 0 (expire in 84575 secs)
   ;; status: NOERROR, flags: qr rd ra
   ;; ANSWER SECTION (1):
   heise.de                 84576 IN A     193.99.144.80

0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.0.1.0.0.1.e.f.3.0.0.e.2.0.2.0.a.2.ip6.arpa IN PTR ;; hashval 247, flags 0 (expire in 86385 secs)
   ;; status: NOERROR, flags: qr rd ra
   ;; ANSWER SECTION (1):
   0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.0.1.0.0.1.e.f.3.0.0.e.2.0.2.0.a.2.ip6.arpa 86386 IN PTR   redirector.heise.de

80.144.99.193.in-addr.arpa IN PTR ;; hashval 836, flags 0 (expire in 86105 secs)
   ;; status: NOERROR, flags: qr rd ra
   ;; ANSWER SECTION (1):
   80.144.99.193.in-addr.arpa 86106 IN PTR   redirector.heise.de

~ #
ein paar Adressen notieren - die halten dann auch schon mal eine Woche durch, ohne sich zu ändern.

Aber wie man sehen kann, würde diese Adresse fast 24 Stunden im Cache verbleiben - wobei die TTL auch nicht größer werden sollte als 24 Stunden, denn der SOA für diese Domain gibt die TTL mit 86400 vor und falls irgendein Server, der vom eigenen DNS-Forwarder rekursiv befragt wird, diesen Eintrag schon länger im Cache hat, kann er ihn nur mit einer TTL ausliefern, die kleiner ist und zwar um so viele Sekunden, wie seit dem Zeitpunkt vergangen sind, wo er ihn selbst in seinen Cache aufgenommen hat - denn auch dieser Eintrag muß ja nicht zwingend von ns.heise.de stammen, wenn ein anderer Server den gespeichert hatte.
Rich (BBCode):
[email protected]:~> dig heise.de. soa

; <<>> DiG 9.16.20 <<>> heise.de. soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15623
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 760b43e334defa53010000006192aef2b6ec8ba3bb658fb2 (good)
;; QUESTION SECTION:
;heise.de.                      IN      SOA

;; ANSWER SECTION:
heise.de.               85967   IN      SOA     ns.heise.de. hostmaster.heise.de. 2021111520 14400 3600 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 15 20:03:14 CET 2021
;; MSG SIZE  rcvd: 115

[email protected]:~> dig @ns.heise.de heise.de.

; <<>> DiG 9.16.20 <<>> @ns.heise.de heise.de.
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14304
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

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

;; ANSWER SECTION:
heise.de.               86400   IN      A       193.99.144.80

;; Query time: 19 msec
;; SERVER: 193.99.145.37#53(193.99.145.37)
;; WHEN: Mon Nov 15 20:04:10 CET 2021
;; MSG SIZE  rcvd: 53

[email protected]:~>
Langer Erklärung kurzer Sinn ... wenn man sich auf den Fehlerfall vorbereitet und ein paar Namen und die zugehörigen IP-Adressen notiert, muß man auch irgendwie dafür sorgen, daß der DNS-Cache im FRITZ!OS ebenfalls gelöscht wird. Wer keinen Shell-Zugriff hat (dann kann er das oben gezeigte aicmd multid dnsd flush verwenden - in neueren Versionen zumindest), der muß wohl die Box noch einmal neu starten und danach natürlich die erwähnten Namen nicht erneut abfragen, deshalb nimmt man da auch irgendetwas, was im Alltag bei einem selbst nicht vorkommt. Oder man nimmt gleich die Form des nslookup-Kommandos, bei der auch der zu befragende DNS-Server angegeben wird (gibt's oben auch in einem Beispiel) - dann spielt der Cache im multid auch keine Rolle mehr.

Ich verstehe immer noch nicht, wie man auf die Diagnose "DNS geht nicht" kommen kann, wenn man noch nicht einen "Beweis" dafür gesehen hat - selbst diejenigen, die einen Fetisch für die DNS-Server 8.8.8.8 oder 1.1.1.1 haben, hätten ja zumindest mal vorschlagen können, den DNS-Server auch tatsächlich abzufragen, anstatt nur mit ICMP den Weg dahin zu prüfen oder eine TCP-Verbindung (wo obendrein übliche DNS-Abfragen über UDP erfolgen, solange die Antworten in ein (UDP-)Paket passen) zum Port 53 dort zu testen:
Rich (BBCode):
vidar:~ # tcpdump -i vlan8 -n -vvv -X host 1.1.1.1 & sleep 2; dig @1.1.1.1 heise.de. 2>&1 >/dev/null; sleep 2; killall tcpdump
[4] 16415
tcpdump: listening on vlan8, link-type EN10MB (Ethernet), snapshot length 262144 bytes
[3]   Done                    tcpdump -i vlan8 -n -vvv -X host 1.1.1.1
20:17:45.086162 IP (tos 0x0, ttl 64, id 1029, offset 0, flags [none], proto UDP (17), length 77)
    192.168.131.2.55157 > 1.1.1.1.53: [udp sum ok] 4502+ [1au] A? heise.de. ar: . OPT UDPsize=4096 [COOKIE 7e71e853da69ee8c] (49)
        0x0000:  4500 004d 0405 0000 4011 30ef c0a8 8302  [email protected]
        0x0010:  0101 0101 d775 0035 0039 868f 1196 0120  .....u.5.9......
        0x0020:  0001 0000 0000 0001 0568 6569 7365 0264  .........heise.d
        0x0030:  6500 0001 0001 0000 2910 0000 0000 0000  e.......).......
        0x0040:  0c00 0a00 087e 71e8 53da 69ee 8c         .....~q.S.i..
20:17:45.097372 IP (tos 0x0, ttl 57, id 12970, offset 0, flags [DF], proto UDP (17), length 81)
    1.1.1.1.53 > 192.168.131.2.55157: [udp sum ok] 4502 q: A? heise.de. 1/0/1 heise.de. [22h59m13s] A 193.99.144.80 ar: . OPT UDPsize=1232 (53)
        0x0000:  4500 0051 32aa 4000 3911 c945 0101 0101  [email protected]
        0x0010:  c0a8 8302 0035 d775 003d bb57 1196 8180  .....5.u.=.W....
        0x0020:  0001 0001 0000 0001 0568 6569 7365 0264  .........heise.d
        0x0030:  6500 0001 0001 c00c 0001 0001 0001 4341  e.............CA
        0x0040:  0004 c163 9050 0000 2904 d000 0000 0000  ...c.P..).......
        0x0050:  00                                       .

2 packets captured
2 packets received by filter
0 packets dropped by kernel
vidar:~ #
Hier kann man - nebenbei - auch sehen, daß der Server (bzw. "die", denn das ist ja auch nicht nur ein einzelner) 1.1.1.1 diese Adresse schon etwas länger im eigenen Cache hat, denn die TTL ist nur noch mit knapp 23 Stunden angegeben in der Antwort des Servers.

Aber selbst wenn man JETZT die DNS-Auflösung etwas genauer unter die Lupe nehmen würde ... wie kommt man - bei den bisherigen Ergebnissen - denn bitte auf die Idee, daß nun ausgerechnet die DNS-Auflösung daran Schuld tragen muß, wenn z.B. Windows die Datei für den Status-Indikator nicht abrufen kann (s. Beschreibung bei MS oben)? Warum kann das nicht genauso gut ein Problem beim Abrufen dieser Datei vom MS-Server sein?
Rich (BBCode):
[email protected]:~> wget -O - http://www.msftconnecttest.com/connecttest.txt | wc -
--2021-11-15 20:24:28--  http://www.msftconnecttest.com/connecttest.txt
Resolving www.msftconnecttest.com (www.msftconnecttest.com)... 13.107.4.52
Connecting to www.msftconnecttest.com (www.msftconnecttest.com)|13.107.4.52|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 22 [text/plain]
Saving to: 'STDOUT'

-                                                           100%[=======================================>]      22  --.-KB/s    in 0s

2021-11-15 20:24:28 (1.33 MB/s) - written to stdout [22/22]

      0       3      22 -
[email protected]:~> wget -q -O - http://www.msftconnecttest.com/connecttest.txt | cat; echo
Microsoft Connect Test
[email protected]:~>
Diese Server stehen dann (bei fast allen gebräuchlichen OS) auch noch jenseits des Atlantiks, so daß schon eine Störung zwischen den Kontinenten (die auch kurzzeitig auftreten kann, genauso wie Überlastungen, denn diese Server sind STÄNDIG irgendwelchen Angriffen ausgesetzt, die dann erst mal ausbalanciert werden müssen) zu einer solchen "Anzeige" führen kann. Die darf man also auch nicht überbewerten - denn letztlich ist das nichts anderes als die Aussage: "Ich kann gerade irgendein 'Leuchtfeuer' im Internet nicht erreichen, was eigentlich funktionieren sollte." und die muß man nicht wirklich ernst nehmen.

Auch wenn es hier sicherlich nicht nur um kurzfristige Störungen geht ... aber wenn es mir (in der Rolle des Angreifers) gelingen würde, den DNS-Cache einer FRITZ!Box (ohne DNSSEC-Validierungen und TLS oder auch mit - irgendeine Lücke müßte es jüngst auch gegeben haben, sonst hätte AVM nicht in so kurzer Zeit die Version 07.29 für fast alle Modelle ausgerollt und da war zumindest in der info.txt von aktualisierten Zertifizierungsstellen die Rede, die auch für DNS over TLS benötigt würden - wobei es ja mit 07.29 auch noch auftreten soll, das Problem hier) mit einem langlebigen Eintrag für www.msftconnecttest.com zu vergiften (cache poisoning), dann funktionieren auf einen Schlag diese NCSI-Abfragen für alle Windows 10-Clients nicht mehr und zwar bis zu einem Neustart der Box oder bis zum "expire" für den gefaketen Eintrag.

Ich will damit auch nicht darauf hinaus, daß hier tatsächlich eine Lücke besteht, die Cache-Poisoning ermöglicht - aber es ist zumindest eine genauso plausible Theorie (in Anbetracht dessen, was hier bisher getestet wurde) wie die, daß da die DNS-Auflösung (für alle!) nicht mehr funktioniert. Und wenn ein Angreifer Verwirrung stiften wollte, dann würde er sich genau diese Services, die von den OS für solche Diagnosen verwendet werden, aussuchen - und so groß ist die Liste dieser Services (und der meist genutzten OS) nun auch wieder nicht, daß man deren Adressen nicht auf einen Schlag faken könnte. Und zu allem Überfluß würde das sogar noch dazu passen, daß diese Probleme eher sporadisch auftreten - eben dann, wenn die eigene IP-Adresse mal wieder dran war bei der nächsten Runde über irgendein Segment.

Wie gesagt - keinerlei Anspruch auf Übereinstimmung mit der Realität, aber mir fiele jetzt kein Aspekt der bisher zu sehenden Testergebnisse ein (außer vielleicht die Hoffnung, daß AVM ein Problem mit früheren Versionen in der 07.29 hoffentlich gefixt hätte), der gegen so eine Theorie sprechen würde. Sie mag zwar etwas "verrückter" sein als das Übliche, aber auch wenn man einen Hammer als Werkzeug hat, muß noch lange nicht jedes Problem auch als Nagel angesehen werden. Und es ist auch keine ernstgemeinte These (zumindest noch nicht) - eher eine Anregung, nicht immer nur mit Tunnelblick an die Probleme heranzugehen und die Fakten, die nicht zur eigenen Theorie passen, einfach nur auszublenden.

Wenn eine Idee wirklich einleuchtend sein soll, muß sie sich schon die Mühe machen, auch ALLE bisher vorliegenden Ergebnisse zu erklären (DESHALB sollte man die Idee auch mitteilen und nicht nur irgendwelche zusätzlichen Tests einfordern, von denen keiner weiß, was damit bewiesen oder widerlegt werden soll) und wenn sie das nicht kann, sollte man zumindest weitere/erneute Tests anregen, falls wirklich mal ein falsches Ergebnis dabei war.

Aber gleich drei oder vier Anzeichen zu ignorieren, die deutlich GEGEN die eigene These sprechen, ist für mich nur noch stures Festhalten an einer Idee, weil man sie selbst geäußert hat. Man muß sich von "Gegenbeweisen" auch schon mal überzeugen lassen, solange man sie mit der eigenen Theorie nicht erklären kann. (Und nein, ich beharre nicht auf meiner These mit dem PA - ich habe parallel dazu schon seit langem weitere Testalternativen vorgeschlagen, von denen aber bisher nicht eine einzige Gehör fand oder zumindest werden die entsprechenden Ergebnisse noch verheimlicht ... auch damit kann ich leben.) Jedoch tut mir (und späteren Lesern) doch bitte den Gefallen und prüft selbst, welche der bisher gezeigten Ergebnisse nun zu einer Theorie passen und welche nicht - das "Ignorieren" der tatsächlichen Umstände im Problemfall geht schon dann los, wenn man sich die Ergebnisse in #1 nicht richtig ansieht.
 
Zuletzt bearbeitet:

HabNeFritzbox

IPPF-Urgestein
Mitglied seit
12 Dez 2017
Beiträge
19,227
Punkte für Reaktionen
779
Punkte
113
Moin Peter,

dein Text ist sehr ausführlich, auch wieder zich Linux Befehle die ein einfacher Nutzer ohne Subsystem und co nicht einfach in Windows ausführen kann.

Und wieso ich auf DNS Idee komme? Da mache ich es mir in dem Fall evt. auch für dich "zu einfach", es werden Ping beantwortet, es gehen Daten raus, es kommt was zurück, fertig.

Wird DNS nicht beantwortet, schließen meisten einfach auf gesamte Internet würde nicht gehen, obwohl evt. nur DNS nicht aufgelöst wird, und daher Webseiten unbekannt sind, aber noch mit außen kommuniziert werden kann.

Die FB verwendet für eigene Dienste (Telefonie, Onlineupdate, usw.) die DNS vom Provider, egal was in FB einstellst. Daher kann die FB ggf. auf DNS zurückgreifen, oder hat den Cache verwendet. Dass was an DNS in FB angibst, gilt dann für alles außer der FB selbst.

Ich habe einfach versucht ganze einfach und möglichst pragmatisch einzugrenzen ohne gleiche ne Forensische Doktorarbeit zu erstellen.

Gibt es Probleme in der FB, würde ich mich eher an AVM wenden, wenn nichts mehr rein und raus geht an Daten, eher an Vodafone.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,331
Punkte für Reaktionen
1,422
Punkte
113
Die Linux-Befehle dienen nur zum Untermauern/Zeigen, was da alles getestet werden könnte. Die haben alle eine Entsprechung in Windows - praktisch jeder Ratgeber im Internet, der sich mit Netzwerk-Problemen befaßt, zieht diese auch zum Test heran - und nicht nur ein ping, weil dessen Aussage eben sehr, sehr begrenzt ist (egal, ob da Antworten kommen oder nicht). Als "erster Test" mag das noch hilfreich sein - aber dann muß man die Ergebnisse auch bei der eigenen Theorie berücksichtigen.

Gerade dann, WENN die Box tatsächlich die DNS-Server des Providers benutzen sollte (auch wenn der Browser, mit dem in #1 der "Zack"-Test von AVM aufgerufen wurde, wohl eher nicht auf der Box gelaufen sein wird) und es daher auch beim Auftreten des Problems noch funktioniert, macht es ja nur wenig Sinn, auf den Clients am Ende einen anderen DNS-Server einzustellen, als einen von denen, die von der Box selbst auch genutzt werden.

Gerade dann, wenn man den "Ausführenden" so wenig zutraut, daß die Beispiele nicht verstehen und nicht in der Lage sein sollen, diese auf andere Systeme zu übertragen, macht es ja noch weniger Sinn, so jemandem das Verstellen von essentiellen Einstellungen auf seinen Systemen zu empfehlen - vor allem dann, wenn das am Ende das genaue Gegenteil von dem wäre, was man selbst als Theorie über die Ursache aufstellen will.

Denn genau wie Du schreibst ... wenn die Box mit den DNS-Servern vom Provider kein Problem hat, sollte man am "Test-Client" ja eher dieselben Server einstellen und verwenden, wie an der FRITZ!Box - denn auch wenn man dort als Upstream für Clients einen Google- oder Cloudflare-Server konfiguriert haben sollte und die dann "das Problem" machen, bringt es ja keine Punkte, wenn das der Client dann direkt bei diesem Server probiert ... zumindest kann man das alles ganz wunderbar auch einfach mit simplen Kommandos testen (ein nslookup gibt es auch unter Windows und ping in der cmd.exe haben wir hier zumindest schon gesehen - die Kommandozeile kann also auch nicht die große Unbekannte sein, zumal sich andere Vorschläge ja auch desöfteren auf CLI-Aufrufe beziehen) und muß dafür nicht gleich den ganzen Client so umkonfigurieren, daß der solche Änderungen permanent übernimmt (und dann womöglich diese Änderungen nie wieder rückgängig gemacht werden vom Ausführenden, auch wenn die Tests damit lange vorbei sind).

Und zu dem "Ich mache es mir halt einfach.": Diejenigen, die hier nach Hilfe suchen, können nun mal nicht auf Anhieb erkennen, wie gut sich jemand mit Netzwerkproblemen auskennt, der ihnen da gerade Hilfestellung geben will. Das kann ja durchaus alles auch gut gemeint sein (ich unterstelle ja niemandem, daß er andere bewußt in die Irre leiten oder beschäftigen will) - nur hilft es demjenigen, der ein Problem hat, praktisch gar nichts, wenn da ständig drei oder vier "Experten" in unterschiedliche Richtungen an ihm herumzerren, weil sie sich untereinander nicht mal einigen können. Für eine eigene Theorie, woran es nach der höchstpersönlichen Ansicht liegen könnte, sollte man ja wenigstens irgendeinen Beleg vorbringen können (und sei es erst mal nur in Form einer Begründung, die auch die anderen Fakten berücksichtigt) und der darf dann auch nicht gleich mit den anderen vorliegenden Ergebnissen kollidieren.

Genau deshalb will ich auch nur zeigen, was man noch alles testen KÖNNTE und habe es inzwischen aufgegeben, von jemandem die Ausführung meiner Vorschläge "zu verlangen" - ich wollte mich tatsächlich raushalten und mein letzter Beitrag in diesem Thread war (vor #64) nicht umsonst schon eine Woche alt. Aber das heißt im Gegenzug auch noch nicht, daß ich bei Theorien, die ich so gar nicht nachvollziehen kann (oder bei entsprechenden Vorschlägen, was man nun als Nächstes machen sollte), einfach die Augen schließe und mir denke, daß mancher es vielleicht auch nicht anders wollte. Wenn ein Vorschlag unlogisch erscheint (und auch Lösungsvorschläge, die keine forensische Doktorarbeit sein sollen - das wäre ohnehin etwas zu anspruchslos als Thema - sollten ja schon einer gewissen Logik folgen und bisherige Ergebnisse berücksichtigen) und es an einer passenden Begründung mangelt, dann darf man sicherlich noch einmal nachhaken - wenn's dafür tatsächlich eine logische und damit nachvollziehbare Begründung gibt, kann das ja kaum zum Problem werden.
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
8,014
Punkte für Reaktionen
28
Punkte
48
Würde ja bedeuten, das ich alle Netzwerkgeräte übersteuern müsse???
Wie schon geschrieben worden ist, an einem Gerät.
Du hast ja einen PI, mit dem Du evtl. systemd-resolved benutzt.
Code:
systemctl status systemd-resolved
ls -la /etc/resolv.conf
Dann wird die resolv.conf ein symlink sein, denn Du temporär (für die Zeitdauer des Tests) löschen kannst (und nach dem Test wieder anlegen).
Code:
rm -rf /etc/resolv.conf
Mit nano kannst Du dann eine Datei /etc/resolv.conf, mit folgendem Eintrag:
Code:
nameserver 80.69.96.12
nameserver 81.210.129.4
options rotate
, anlegen.
Die VF-DNS-Server kannst Du vorher auf deinem PI testen:
Code:
host heise.de 81.210.129.4
host heise.de 80.69.96.12
Wenn sie funktionieren, kannst die resolv.conf gegen löschen/überschreiben noch (temporär) schützen, mit dem i-Flag:
Code:
chattr +i /etc/resolv.conf
lsattr /etc/resolv.conf
und jetzt testen:
Code:
host -v heise.de | grep -i received
nslookup berlin.de
Die hosts-Zeile in der /etc/nsswitch.conf des PI, sollte temporär (d. h. nur für die Zeitdauer des Tests) so sein:
Code:
hosts:          files dns
So kannst Du mit deinem PI, wenn das Problem erneut auftritt, eine Namensauflösung (DNS) ohne die Beteiligung der FritzBox, benutzen. Z. B. mit:
Code:
nc -zv 90.130.70.73 80
wget -4 -c -O /dev/null http://speedtest.tele2.net/100MB.zip
auf dem PI (DNS und download nach /dev/null). Wenn das auf deinem PI funktioniert, solltest Du sofort (ohne reboot der FritzBox), auf einem anderen mit der FritzBox schon verbundenen (Wlan oder Kabel) Gerät, den Zugriff aufs Internet mit einem Browser testen.
 
Zuletzt bearbeitet:

Der D

Neuer User
Mitglied seit
6 Nov 2021
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
dein Text ist sehr ausführlich, auch wieder zich Linux Befehle die ein einfacher Nutzer ohne Subsystem und co nicht einfach in Windows ausführen kann.
Danke, ich hab`s mich nicht getraut zu schreiben.
Ich habe einfach versucht ganze einfach und möglichst pragmatisch einzugrenzen ohne gleiche ne Forensische Doktorarbeit zu erstellen.
Und es hat mir bis jetzt geholfen!!
Seit meinem letzen Post habe ich keine Probleme mehr mit den Abbrüchen.

Was ich gemacht habe?
  1. Ich habe meine DNS Server in der FB angepasst
    Code:
    Bevorzugter DNSv4-Server von 8.8.8.8 auf 1.1.1.1 geändertAlternativer DNSv4-Server auf 8.8.8.8 belassen
  2. DNS over TLS (DoT) aktiviert
  3. Zertifikatsprüfung & Fallback aktiviert
    Code:
    Als Auflösungsnamen folgende eingetragen:
        dns.google
        dns.digitale-gesellschaft.ch
        dnr2.senselan.ch
Seit diesen Anpassungen habe ich bis jetzt keine Ausfälle mehr. Ohne die Hinweise mal einen Ping nach draussen abzusetzen wäre ich nie auf die Idee gekommen. Auch der Tip bzgl. DoT hat mein Verständniss (habe mich dann diesbezüglich etwas eingelesen) etwas erweitert.
Ich komme weder aus der IT-Brache, noch aus der Netzwerkadministration und bin noch mit 56k Modem / Akustikkopler gross geworden. Wissen so weit erweitert, wie es gebraucht wurde (wie gesagt weder IT noch Administration in der IT).

No matter...;

Noch mal ganz herzlichen Dank an alle, die konstruktive und einfache Hilfestellung für einen Laien wie mich geleistet haben. Das ist das was ich mir unter einem Forum vorstelle, ohne die Grunderwartung der Supporter ein IT-Studium abgelegt zu haben.

Danke!
 

Der D

Neuer User
Mitglied seit
6 Nov 2021
Beiträge
9
Punkte für Reaktionen
0
Punkte
1
Ich habe nie behauptet, das das ip-phone-forum ein Support-Forum ist oder hat ;)

Hilfe zur Selbsthilfe ist in dem Sinne auch ein Support ;)
Aber die Begriffbedeutung müssen wir jetzt nicht ausdiskutieren, ich wollte mich einfach nur bedanken und evtl. anderen die das gleiche Problem haben meine Lösung vorstellen, die ich ohne die Hilfe zur Selbsthilfe nicht gefunden hätte.
 

HabNeFritzbox

IPPF-Urgestein
Mitglied seit
12 Dez 2017
Beiträge
19,227
Punkte für Reaktionen
779
Punkte
113
Es wird der schnellste DNS verwendet von der FB, und dass wird wohl Google sein, also die beiden .ch Einträge werden wohl nicht angetastet.

Wenn 1.1.1.1 verwendet wird, dass ist Cloudflare, für DoT wäre dort der Eintrag 1dot1dot1dot1.cloudflare-dns.com

Zumindest bei mir habe ich mit Google bessere Erfahrung als mit Cloudflare, entsprechend würde ich da nur 8.8.8.8 und 8.8.4.4 verwenden und den Google Eintrag.
 
Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via