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):
peh@vidar:~> 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::
peh@vidar:~> 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::
peh@vidar:~> 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 -
peh@vidar:~>
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):
peh@vidar:~> 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
peh@vidar:~> 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
peh@vidar:~>
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):
peh@vidar:~> 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 -
peh@vidar:~> wget -q -O - http://www.msftconnecttest.com/connecttest.txt | cat; echo
Microsoft Connect Test
peh@vidar:~>
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.
