AW: Telekom DNS Server (217.0.43.114) bitte fixen

[#1]

Hallo Support,

es geht um die Gruppe der (DoT) DNS Server (dns.telekom.de).

In meinem Gebiet wären zuständig:

217.0.43.113

217.0.43.114

Beim 217.0.43.114 gibt es seit mehreren Tagen, vielleicht sogar Wochen, Auffälligkeiten...siehe Bild.

Zum Vergleich der 217.0.43.113:

Ich bitte sie um Überprüfung u. ggf. Reparatur.

Mit freundlichem Gruß

PrΩmetheµs

[#2 · Accepted solution]

@jilse  schrieb:
Inwiefern untersscheiden sich die Zertifikate deiner Ansicht nach? In der Art des Zertifikats? In den verwendeten Algorithmen zur Signierung? Dass die zertifikate ueberhaupt unterschiedlich sind, duerfte normal sein, denn die beiden Server sind ja verschiedene Hosts mit unterschiedlichen Namen ...

Die Zertifikate sind, wenn sie vollständig vorhanden sind, genau identisch. Das betrifft jeden Telekom DOT Server.

Der Unterschied ist ganz einfach erklärt:

Manche haben das "Sicherheits-Zertifikat", u. andere DOT Server eben nicht.

Die Screens stelle ich nur auf Anfrage eines Technikers hier ein.

Und jetzt kommt das "interessante/lustige" an der Geschichte.

wird "dns.telekom.de" eingetragen, bekommt man i.d.R. 2 x (pri./sec.) x Server in Fra, oder 2 x in Ulm, oder 2 x in Düsseldorf, usw. genau das gleiche "Ding" wie ohne DoT.

In meinem Fall ist Frankfurt die Adresse für DNS (mit oder ohne Dot - egal).

Den zweiten Dot Server bekomme ich lustigerweise aus Düsseldorf zugewiesen.

Warum?

Weil der zweite "DoT Frankfurt Server" keine Sicherheitsheits-Zertifikate besitzt - der in Düsseldorf schon

Mir ist das ohnehin Wurst, da ich die zwei Standard ISP-DNS Server (wenn wunderts aus Fra),  z.Z. benutze.

Da nun aber der DoT-Verkehr aus Umgebung Frankfurt, nun über nur einen DoT-Server läuft, würde dass ganz genau die Überbelastung zu den Rush-Hour Zeiten im Bild vom 217.0.43.114 passen. Und genau dieser 217.0.43.114 ist auch immer der Aktive, lt. Fritz-Box. Da Düsseldorf einfach 3-4ms weiter weg ist, wird auch nicht gewechselt.

Lt. Telekom ist die DoT Geschichte noch nicht offiziell freigeschaltet. Fritz-Box User können die Geschichte allerdings testen...

Nun gut, wie auch immer. Ich habe es getestet - und für unzureichend befunden.

Und da sich hier Keiner von der Technik meldet, bin ich hier auch draußen.

Mit freundlichem Gruß

PrΩmetheµs

[#3]

@PrΩmetheµs  schrieb:

es geht um die Gruppe der (DoT) DNS Server (dns.telekom.de).

In meinem Gebiet wären zuständig:

217.0.43.113

217.0.43.114

Es geht vermutlich um die DNS-Server, die beim Aufbau der PPP-Verbindung als zustaendig uebermittelt werden. Das sind nicht die DNS Server, die sich hinter dem Namen dns.telekom.de verbergen. Ansonsten ist es natuerlich richtig, auf Probleme hinzuweisen. Anhand der Grafik wuerde ich vermuten, dass der Server mit der IP 217.0.43.114 (aus welchen Gruenden auch immer) nachmittags stark belastet bzw. ueberlastet ist. Treten dadurch bei dir wirklich Probleme auf? Befragt dein Rouer (den du doch sicherlich als DNS-Forwarder verwendest) nicht beide DNS-Server paallel und nutzt die Antwort des Servers, der zuerst geantwortet hat?

[#4]

1. Pings sagen nicht viel aus, da Server für Ping-Antworten die niedrigste Priorität haben.

2. Nutze doch Cloudflare.

[#5]

@Carsten_MK2  schrieb:
1. Pings sagen nicht viel aus, da Server für Ping-Antworten die niedrigste Priorität haben.

Ach waren das Antwortzeiten fuer "ping" und nicht fuer dNS-Anfragen, die in der Grafik dargestellt  waren? Dann sind sie natuerlich relativ nichtssagend. Da ich das Tool nicht kenne, mit dem die Grafik erzeuggt wurde, ging ich davon aus, dass DNS- und nicht Ping-Antwortzeiten gemessen wurden.

@Carsten_MK2  schrieb:
2. Nutze doch Cloudflare.

Warm sollte er das tun? Eigentlich sollten die per PPP zugewiesene DSN-Server schon netztopologisch "dicht dran" stehen und ausreichend leistungsfaehig sein. Das wwuerde ich von meinem Diensstleister erwarten. Daher meine Frage, ob es denn im realen Betrieb zu Einschraenkungen kommt.

[#6]

@jilse  schrieb:
Ach waren das Antwortzeiten fuer "ping" und nicht fuer dNS-Anfragen,

So interpretiere ich das Tool.

@jilse  schrieb:
Warm sollte er das tun? Eigentlich sollten die per PPP zugewiesene DSN-Server schon netztopologisch "dicht dran" stehen

Wenn es Probleme mit einem Dienst geben sollte und es eine kostenlose, hochperformante und hochverfügbare Alternative gibt, denn nehme ich die.

[#7]

@PrΩmetheµs  schrieb:
es geht um die Gruppe der (DoT) DNS Server (dns.telekom.de).

Sind die schon im Regelbetrieb?

[#8]

Hallo,

ich möchte mal ganz allgemein antworten.

Ich tracke schon seit mehreren Jahren über "Thinkbroadband" (auch mal die eigene IP). Das "Tool" pingt von Außerhalb...so weit ich weiß England.

Das "rote" ganz oben in der Grafik sind Paketverluste.

Kurz gesagt,

sobald sich erhebliche Schwankungen am genutzten DNS aufzeigen, werden diese Schwankungen (delays/Paketverluste) 1:1 auf der eigenen IP wieder gespiegelt. Und ja, das merkt man auch...je nach Anwendung/Erfahrung, mehr oder minder stark.

Ist es ein gleichmäßiger grüner Teppich, ohne die oberen roten "Spikes" am DNS, so ist die Grafik an getrackter eigener IP identisch - u. alles fühlt sich auch geschmeidig u. schnell an.

Mit freundlichem Gruß

PrΩmetheµs

[#9]

@PrΩmetheµs  schrieb:
Das "Tool" pingt von Außerhalb...so weit ich weiß England.

Und das lässt Rückschlüsse auf die Erreichbarkeit und Latenz im Telekom eigenen Netz zu? Da wäre ich jetzt ein wenig skeptisch. 
Und nur weil ein Server nicht auf Pings antwortet, weil er eventuell gerade was Wichtigeres zu tun hat, würde ich auch nicht unbedingt als Maßstab anlegen.

Wie schnell ist denn eigentlich die Response Zeit auf DoT Requests oder kommt es da zu Timeouts?

[#10]

@viper.de  schrieb:

@PrΩmetheµs  schrieb:
Das "Tool" pingt von Außerhalb...so weit ich weiß England.

Und das lässt Rückschlüsse auf die Erreichbarkeit und Latenz im Telekom eigenen Netz zu?

Eher nein.

@viper.de  schrieb:
Und nur weil ein Server nicht auf Pings antwortet, weil er eventuell gerade was Wichtigeres zu tun hat,

... oder evt. z.B. eine Firewall davor steht, die ping Requests limitiert. 

@viper.de  schrieb:
Wie schnell ist denn eigentlich die Response Zeit auf DoT Requests oder kommt es da zu Timeouts?

Wer braucht denn DNS over TLS? Welche Vorteile soll das bringen? Und welche Resolver benutzen das per Default?

[#11]

Hallo,

es geht nicht darum, ob man DoT DNS Server braucht, oder nicht.

@viper.de  schrieb:
Und das lässt Rückschlüsse auf die Erreichbarkeit und Latenz im Telekom eigenen Netz zu?

Ja.

Zum Vergleich noch drei weitere DNS Server der Telekom im Raum Frankfurt.

[#12]

@PrΩmetheµs  schrieb:

@viper.de  schrieb:
Und das lässt Rückschlüsse auf die Erreichbarkeit und Latenz im Telekom eigenen Netz zu?

Ja.

Nein, zumindest nicht unbedingt. Die Antwortzeiten bei DNS-Anfragen haben nur bedingt bis gar nichts mit den Antwortzeiten auf ping zu tun. AuchPakeetverluste bei "Dauerping" muessen nicht unbedingt etwas ueber den DNS-Service aussagen (da kann z.B. ICMP Ratelimiting auf einer Firewall vor dem DNS-Server implementiert sein).

[#13]

i@PrΩmetheµs  schrieb:
Zum Vergleich noch drei weitere DNS Server der Telekom im Raum Frankfurt

Hilfreich wäre jetzt ein Vergleich mit direkter Anbindung und nicht ein Vergleich der Latenzen verschiedener Server aus einem fremden Netz. Das ist doch sonst eine andere Route. Aber ich denke da kommen wir nicht auf einen gemeinsamen Nenner.

[#14]

@jilse  schrieb:
Nein, zumindest nicht unbedingt. Die Antwortzeiten bei DNS-Anfragen haben nur bedingt bis gar nichts mit den Antwortzeiten auf ping zu tun. AuchPakeetverluste bei "Dauerping" muessen nicht unbedingt etwas ueber den DNS-Service aussagen (da kann z.B. ICMP Ratelimiting auf einer Firewall vor dem DNS-Server implementiert sein).

Wäre ICMP aktiv, und würde die Abfrage blockt werden, wäre nur ein großer roter Balken zu sehen (100% Packet-Lost). Dies ist zum Beispiel beim Telekom Gateway der Fall.

Wie bereits geschrieben, ich kenne u. benutze "thinkbroadband" seit Jahren.

So, oder so, zu viel Theorie, Thesen und Mutmaßungen. Sobald 217.0.43.114 aktiv ist, läuft das Internet schlecht(er).

Sobald einer der anderen von mir genannten Telekom DNS Server ausgewählt wird - läuft alles rund.

Der Hinweis zur Überprüfung des 217.0.43.114 ist auch an die Telekom gerichtet.

@viper.de  schrieb:
Hilfreich wäre jetzt ein Vergleich mit direkter Anbindung und nicht ein Vergleich der Latenzen verschiedener Server aus einem fremden Netz. Das ist doch sonst eine andere Route. Aber ich denke da kommen wir nicht auf einen gemeinsamen Nenner.

Verstehe ich nicht.

All die genannten Screens, stammen von Telekom DNS-Server im Raum Frankfurt.

217.237.148.22 vom ISP - Fra
217.237.150.51 vom ISP - Fra

194.25.0.70 resolvbpa-f.t-ipnet.de - Fra öffentlich
194.25.0.68 resolv-f.dtag.de - Fra öffentlich

dns.telekom.de (DOT)
217.0.43.113 - Fra
217.0.43.114 - Fra

Mit freundlichem Gruß

PrΩmetheµs

[#15]

@PrΩmetheµs  schrieb:
Wäre ICMP aktiv, und würde die Abfrage blockt werden, wäre nur ein großer roter Balken zu sehen (100% Packet-Lost). Dies ist zum Beispiel beim Telekom Gateway der Fall.

Es git nicht nur "ICMP blocken" (wobei nur bestimmte ICMP Typen geblockt werden, denn ICMP komplett zu blocken, haette evt. erhebliche Netzwerkprobleme zur Folge, z.B. bei der "Path MTU Discovery") sondern auch "ICMP Rate Limiting", sprich es werden nur eine bestimmte Maximale Anzahl von ICMP Paketen pro Zeiteinheit und Source-IP beantwortet. Das ist sogar gaengige Praxis um bestimmte Arten von "Denial of Service Attacken" zu verhindern).

@PrΩmetheµs  schrieb:
Wie bereits geschrieben, ich kenne u. benutze "thinkbroadband" seit Jahren.

Aber der Server, auf demm dder Speedtest von denen laeeuft, steht in einem anderen Providernetz. Ueber die Verbindungen innerhalb des Telekom Netzes sagt das erst einmal relativ wenig aus, sondern nur ueber die Ereichbarkeit aus dem Netz von "thinkbroadband". Nein, das ist *nicht* das selbe. Es kann durchaus sein, dass der DNS Server (zumindest zu bestimmten Zeiten) ueberlastet ist, deswegen ist es gut, dass du das "Problem" angesprochen hast. Ob es aber tatsaechlich ein Problem ist, geht aus den von dir bereitgestellten Daten nicht hervor. Deswegen solltest du darauf verzichten, voreilige Schlussfolgerungen zu ziehen.

Umm wirklich die DNS Performance zu bestimmen, kann man sich nicht auf "ping Tests" verlassen, sonern solltee wirklich eiin dafuer passendes Toll verwenden, z.B. "namebench" oder der DNS Benchmark von "GRC":

https://code.google.com/archive/p/namebench/downloads

https://www.grc.com/dns/benchmark.htm

Aber bitte beachten: so etwas wirklich nur kurzzeitig zum testen einsetzen. Auch im Internet gilt: Du nutzt *immer* auch fremde Resourcen und solltest diese nicht ueber Gebuehr belasten. Wenn jeder staendig die DNS-Server mit solchen Tools trraktieren wuerde, wuerde dadurch womoeglich erst die Ueberlastung ausgeloest, die man diagnostizieren moechte ...

[#16]

@jilse  schrieb:
Umm wirklich die DNS Performance zu bestimmen, kann man sich nicht auf "ping Tests" verlassen, sonern solltee wirklich eiin dafuer passendes Toll verwenden, z.B. "namebench" oder der DNS Benchmark von "GRC":

Diese "Tools" kenne ich. Benutze sie auch.

Sobald ich die sogenannte Rush-Hour beim 217.0.43.114 erwische, sieht der Graph genau so katastrophal aus.

Letztes Jahr, (im Sommer) hatten sogar alle fünf DNS-Server diese Ping-Spikes, u. Packet-Verluste zur Rush-Hour.

Würde der Standort, von "wo" gepingt wird, eine Rolle spielen, wären Gemeinsamkeiten erkennbar.

Da aber 217.0.43.114 komplett aus der Rolle fällt, ist die Sache eindeutig.

Außerdem hat thinkbroadband den Vorteil einen 24h Diagramm darzustellen. Auffälligkeiten zu bestimmten/wiederkehrenden Zeiten lassen sich im Vergleich zu anderen Tools eindeutig dingfest machen.

Die Geschichte ist im Prinzip sehr einfach, hier mal ein Full-Screen mit allen 5:

Mit freundlichem Gruß

PrΩmetheµs

[#17]

@PrΩmetheµs  schrieb:

@jilse  schrieb:
Umm wirklich die DNS Performance zu bestimmen, kann man sich nicht auf "ping Tests" verlassen, sonern solltee wirklich eiin dafuer passendes Toll verwenden, z.B. "namebench" oder der DNS Benchmark von "GRC":

Diese "Tools" kenne ich. Benutze sie auch.

Von denen hat du keine Ausgaben bereitgestellt.

@PrΩmetheµs  schrieb:
Sobald ich die sogenannte Rush-Hour beim 217.0.43.114 erwische, sieht der Graph genau so katastrophal aus.

Die beiden von mir genannten Tools erzeugen keine Graphen. Die geben nur Antwortzeiten auf DNS-Anfragen an die jeweiligen DNS Server an. Ich kann mir ehrlich gesagt nur schwer vorstellen, dass das was du hier in den Graphen gezeigt hast, einen relevanten Einfluss auf die Performance haben soll, denn der Resolver deines lokalen Rechners cached ja auch noch  einmal die DNS-Antwoten, so dass nicht dauernd Anfragen an die DNS-Server raus gehen sollten. Um das noch weiter zu entschaerfen, koenntest du deinen Router als DNS Server eintragen (wenn du die IP-Adresse ueber DHCP vo Router beziehst, sollte das ohnehin schon der Fall sein, denn der Router sollte die eigene IP-Adresse als zu nutzender DNS Server uebermitteln), dann cached der DNS Proxy im Router die Antworten ebenfalls noch einmal, so dass nicht jedesmal neu der externe DNS-Server gefragt werden muss.

[#18]

@jilse  schrieb:
Die beiden von mir genannten Tools erzeugen keine Graphen

Doch tun sie.

@jilse  schrieb:
Die geben nur Antwortzeiten auf DNS-Anfragen an die jeweiligen DNS Server an. Ich kann mir ehrlich gesagt nur schwer vorstellen, dDaass das was du hier in den Graphen gezeigt hast, einen relevanten Einfluss auf die Performance haben soll, denn der Resolver deines lokalen Rechners cached ja auch noch  einmal die DNS-Antwoten, so dass nicht dauernd Anfragen an die DNS-Server raus gehen sollten. Um das noch weiter zu entschaerfen, koenntest du deinen Router als DNS Server eintragen (wenn du die IP-Adresse ueber DHCP vo Router beziehst, sollte das ohnehin schon der Fall sein, denn der Router sollte die eigene IP-Adresse als zu nutzender DNS Server uebermitteln), dann cached der DNS Proxy im Router die Antworten ebenfalls noch einmal, so dass nicht jedesmal neu der externe DNS-Server gefragt werden muss.

Das ergibt absolut keinen Sinn.

Darüber hinaus lässt sich damit unmöglich feststellen ob ein DNS Server fehlerfrei arbeitet, oder nicht.

Zu deinen vorgeschlagenen DNS-Tools.

• Hier wird der Ping (cached/uncached) zu div. oder auch manuell eingetragenen DNS Server reproduziert, und zwar nur zu der Zeit, indem das Tool ausgeführt wird. Eine 24h Prognose ist nur mit erheblichem Aufwand möglich.
• Der Ping geht bei deinem PC los...und irgendwann ist dieser dann am DNS Server (und wieder zurück). An der Stelle sollte dir klar sein was du eigentlich gemessen hast. Den DNS-Server, oder dein PC, deine Verkabelung, deinen Router, deine TEA-Dose, dein APL, den Telekom-Unterverteiler,  den Telekom-Hauptverteiler, Telekom Gateway, samt Backbone, und div. andere Telekom Hops.
• Alles machbar im Endeffekt, wenn der Weg komplett fehlerfrei ist. Dann lässt sich schnell eine Schwachstelle finden. Da aber der besagte DNS-Server nur zu Rush-Hour Zeiten Probleme macht, kann man nie sicher sein wo noch Probleme auftreten.
• Der Pingplotter wäre solch ein 24h Tool. Hat aber a) den Nachteil dass der PC 24h laufen muss, und b) man kann simultan nicht messen, das heißt nur eine Ziel-IP.

Ein Tool wie Thinkbroadband, welches über ein leistungsstarkes Glasfaser-Netzwerk verfügt, und simultan bis zu 5 IP's messen kann, und das Ganze ohne das der eigene Rechner/Verkabelung, bzw. das Sammelsurium der Telekom Backbone Verdrahtung mit gemessen wird, hat deutliche Analyse-Vorteile.

Und noch eine Tatsache:

Die restlichen vier (fehlerfreien) DNS-Server, hängen am gleichem Telekom Backbone dran.

Ich möchte hier nicht die Vor-u. Nachteile von Tools diskutieren.

Ich habe den Thread eröffnet damit sich ein Techniker

217.0.43.113

und

217.0.43.114

mal genau anschaut.

Bzgl. des TLS Sicherheitszertifikats gibt es nämlich zwischen den zwei o.g. DNS-DOT Servern auch Unterschiede - und genau sowas sollte nicht passieren.

[#19]

@PrΩmetheµs  schrieb:

Zu deinen vorgeschlagenen DNS-Tools.

• Hier wird der Ping (cached/uncached) zu div. oder auch manuell eingetragenen DNS Server reproduziert, und zwar nur zu der Zeit, indem das Tool ausgeführt wird. Eine 24h Prognose ist nur mit erheblichem Aufwand möglich.

Nein, die Tools machen eben keinen "ping" sondern DNS Anfragen. Es steht dir frei, zu den "problematischen Zeiten" die Tools auszufuehren.

@PrΩmetheµs  schrieb:
Der Pingplotter wäre solch ein 24h Tool. Hat aber a) den Nachteil dass der PC 24h laufen muss, und b) man kann simultan nicht messen, das heißt nur eine Ziel-IP.

Der Pingplotter macht (wie der Name schon sagt) "Pings" (sprich ICMP Echo Requests), die von mmir genannten Tools machen DNS-Abfragen. Ja, das ist ein Unterschied.

[#20]

@PrΩmetheµs  schrieb:
Verstehe ich nicht.

Zitat von der Website Deines britischen Broadband Testers

How does the Broadband Quality Monitoring work?

Once you have registered an IP address for monitoring, we will ping that IP address sending small ICMP echo requests

Quelle:

https://www.thinkbroadband.com/faq/broadband-quality-monitor

Was ganz genau hast Du jetzt nicht daran verstanden, dass deren Server in einem britischen Netz ICMP Echo Requests an einen Host im Telekom Netz senden? 
Inwieweit versprichst Du Dir jetzt Rückschlüsse auf die Route, die Deine Anfragen zu diesen Hosts nehmen?

[#21]

Wie thinkbroadband arbeitet weiß ich.

Schau Dir einfach die Screenshots an, dann weißt du wo der Unterschied liegt.

[#22]

@PrΩmetheµs  schrieb:

Ich möchte hier nicht die Vor-u. Nachteile von Tools diskutieren.

Ich habe den Thread eröffnet damit sich ein Techniker

217.0.43.113

und

217.0.43.114

mal genau anschaut.

Bzgl. des TLS Sicherheitszertifikats gibt es nämlich zwischen den zwei o.g. DNS-DOT Servern auch Unterschiede - und genau sowas sollte nicht passieren.

Inwiefern untersscheiden sich die Zertifikate deiner Ansicht nach? In der Art des Zertifikats? In den verwendeten Algorithmen zur Signierung? Dass die zertifikate ueberhaupt unterschiedlich sind, duerfte normal sein, denn die beiden Server sind ja verschiedene Hosts mit unterschiedlichen Namen ...

Unabhaengig von deiner Frage: Ich verstehe immmer noch nicht, was denn genau die Vorteile davon sein sollen. Schutz vorr Manipulation der DNS Antworten? Da schuetzt DNSSEC viel besser (da es auch Manipulationen der Daten direkt auf dem angefragten DNS-Server erkennen wuerde). "Geheimhaltung was genau angefragt wurde"? Moeglich, aber im Internet waere (ausser fuer den Betreiber des ersten Hops ausserhalb des eigenen Netzes und den Betreiber dees angefagten DNS-Servers) eine dafuer notwendige "Man in the middle" Attacke ausgesprochen schwierig, da im Internet noch nicht einmal symmmetrisches Routing voliegen muss und daher das systemmmmatische ausspaehen bestimmter Teilnehmer sehr unwahrscheinlich aere. Fuer mich ist DoT die Antwort auf eine voellig ueberfluesssige Frage. Das hat es meiner Ansicht nach mit Dan Bernsteins "DNSCurve" gemeinsam.

[#23 · Accepted solution]

@jilse  schrieb:
Inwiefern untersscheiden sich die Zertifikate deiner Ansicht nach? In der Art des Zertifikats? In den verwendeten Algorithmen zur Signierung? Dass die zertifikate ueberhaupt unterschiedlich sind, duerfte normal sein, denn die beiden Server sind ja verschiedene Hosts mit unterschiedlichen Namen ...

Die Zertifikate sind, wenn sie vollständig vorhanden sind, genau identisch. Das betrifft jeden Telekom DOT Server.

Der Unterschied ist ganz einfach erklärt:

Manche haben das "Sicherheits-Zertifikat", u. andere DOT Server eben nicht.

Die Screens stelle ich nur auf Anfrage eines Technikers hier ein.

Und jetzt kommt das "interessante/lustige" an der Geschichte.

wird "dns.telekom.de" eingetragen, bekommt man i.d.R. 2 x (pri./sec.) x Server in Fra, oder 2 x in Ulm, oder 2 x in Düsseldorf, usw. genau das gleiche "Ding" wie ohne DoT.

In meinem Fall ist Frankfurt die Adresse für DNS (mit oder ohne Dot - egal).

Den zweiten Dot Server bekomme ich lustigerweise aus Düsseldorf zugewiesen.

Warum?

Weil der zweite "DoT Frankfurt Server" keine Sicherheitsheits-Zertifikate besitzt - der in Düsseldorf schon

Mir ist das ohnehin Wurst, da ich die zwei Standard ISP-DNS Server (wenn wunderts aus Fra),  z.Z. benutze.

Da nun aber der DoT-Verkehr aus Umgebung Frankfurt, nun über nur einen DoT-Server läuft, würde dass ganz genau die Überbelastung zu den Rush-Hour Zeiten im Bild vom 217.0.43.114 passen. Und genau dieser 217.0.43.114 ist auch immer der Aktive, lt. Fritz-Box. Da Düsseldorf einfach 3-4ms weiter weg ist, wird auch nicht gewechselt.

Lt. Telekom ist die DoT Geschichte noch nicht offiziell freigeschaltet. Fritz-Box User können die Geschichte allerdings testen...

Nun gut, wie auch immer. Ich habe es getestet - und für unzureichend befunden.

Und da sich hier Keiner von der Technik meldet, bin ich hier auch draußen.

Mit freundlichem Gruß

PrΩmetheµs

[#24]

@PrΩmetheµs  schrieb:
Die Zertifikate sind, wenn sie vollständig vorhanden sind, genau identisch. Das betrifft jeden Telekom DOT Server.

Das Zertifikat bestaetigt den Zusammenhang zwischen Hostnamen und Schluesselpaar (oder auch den Zusammenhang zwischen IP-Adresse und Schluesselpaar). Nun haben die verschiedenen Server unterschiedliche Hostnamen und unterschiedliche IP-Adressen (i.d.R. auch unterschiedliche Schluessel, aber das spielt hier schon keine Rolle mehr, da unterschiedliche Namen und IP-Adressen schon ausreichen muessten, um auf ein anderes Zertifikat zu kommen). Wenn also nicht komplett gepfuscht wurde, *koennen* die Zertifikate nichht identisch sein, da die Server unterschiedliche Hostnamen und unterschiedliche IP-Adressen haben. Das geht gar nicht anders, sofern die Zertifikate zum jeweiligen Server passen. Das muesste jedem klar seiin, der weiss wie Zertifikate funkktionieren, voellig unabhaengig davon, ob er die Implementierungssdetails von DoT kennt oder nicht. Oder ist dir nicht klar, wie TLS funktioniert?

[#25]

@PrΩmetheµs  schrieb:

Den zweiten Dot Server bekomme ich lustigerweise aus Düsseldorf zugewiesen.

Warum?

Weil der zweite "DoT Frankfurt Server" keine Sicherheitsheits-Zertifikate besitzt - der in Düsseldorf schon

Er hat also gar kein gueltiges Zertifikat installiert. Ja, das ergibt Sinn. Haette er eines installiert, waere es mit an Sicherheit grenzender Wahrscheinlichkeit *nicht* identisch mit demm Zertifikat eines anderen DoT Servers. Die Gruende dafuer habe ich in einem anderen Beitrag erklaert.

[#26]

@jilse  schrieb:
Oder ist dir nicht klar, wie TLS funktioniert?

das ist mir zu 100% klar.

@jilse  schrieb:
Er hat also gar kein gueltiges Zertifikat installiert. Ja, das ergibt Sinn. Haette er eines installiert, waere es mit an Sicherheit grenzender Wahrscheinlichkeit *nicht* identisch mit demm Zertifikat eines anderen DoT Servers. Die Gruende dafuer habe ich in einem anderen Beitrag erklaert.

Wie schon an anderer Stelle erwähnt, sind es wieder einmal von dir aufgestellten Thesen. Beweise hast du bisher konkret keine geliefert. Aus deiner Sicht kannst du da so viel erklären wie du willst, ob es dann letztendlich auch den Fakten entspricht, steht auf einem anderen Blatt.

Fakt ist:

Es gibt "Zertifikate" welche exakt gleich sind, unabhängig von der DoT IP. Dann gibt es Zertifikate welche sich lediglich im Release Datum unterscheiden. Und genau an der Stelle fängt die erste Unzulänglichkeit schon an.

217.0.43.113 hatte ein anderes Release Datum als 217.0.43.114 (Check Herbst 2022).

Die nächste Unzulänglichkeit ist der Ablauf des Zertifikats, u. dann in diesem speziellen Fall der "Switch" auf den nächst naheliegenden Dot Server mit Zertifikat, unter nicht Beachtung des Load-Balancings.

Das Routing im Bezug auf SSL/TLS, was Du meinst, ist auch ohne DoT aktiv (zumindest in der Theorie). DoT bezieht sich auf die Domain "dns.telekom.de". Und genau hier liegt der Fehler, und die zweite Unzulänglichkeit. Das Zertifikat bei Dot ist "dns-telekom.de" zugeordnet., und wird "(Mutterschiff-mäßig)" auf alles DoT Server "verteilt" oder synchronisiert. Warum dennoch einzelne DoT Server das Zertifikat verlieren, kann ich nicht beurteilen.

Wie auch immer, Du kannst es nicht fixen, ich auch nicht, den Hinweis hat die Telekom nun.