Quad9 TCP-Ports 443 und 853 nicht erreichbar

oli-h · 2025-01-15T23:27:32+00:00

Sunrise community - customers help other customers with topics related to television, Internet, telephone and mobile. Register now!

oli-h

Ich nutze Quad9-DNS-Server (https://www.quad9.net) mit DoT (DNS-over-TLS), also IP 9.9.9.9 und TCP-Port 853.
Diesen kann aus dem Sunrise/UPC-Netz (meine IP 77.59.156.xxx) nicht erreichen.
Klassische (unverschlüsselte) DNS-Anfrage an UDP 9.9.9.9:53 hingegen funktionieren. Es scheint also nicht die IP blockiert zu sein.

Andere DoT-Services (konket 8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1, 185.95.218.42 sowie 185.95.218.43) funktionieren ab meiner Sunrise-IP.

Und: Der Quad9-DoT-Dienst (TCP-Port 853) an sich funktioniert auch - ich kann ihn mit meinem Handy (Swisscom-Netz) zuverlässig erreichen.

Mit DoH (DNS-over-HTTPS), also Port 443, ist die Situation identisch: Via Sunrise-Netz geht’s nicht, via Swisscom-Mobile hingegen schon.

Daniele_Sunrise

oli-h Vielen Dank für deine saubere und ausführliche Zusammenfassung des Tests.

Ich habe alle Informationen soeben intern an die entsprechenden Stellen weitergeleitet, sodass sie dein Vorgehen auch bei uns nachvollziehen können. Sobald ich eine Rückmeldung erhalten habe, melde ich mich wieder bei dir.

Liebe Grüsse
Daniele

oli-h

Ich hab’ noch etwas genauer analysiert. Die Situation via Sunrise-Netz ist komisch.

Testsetup

curl https://9.9.9.9
Das baut erstmal eine TLS-Verbindung zum DoH-Server von Quad9 auf.
Quad9 antwortet dann mit “not found”
Das dauert nur wenige Millisekunden sieht normalerweise so aus:
(Erfolgreicht) getestet von einem Linux-PC, verbunden via WiFi mit Hotspot meines Smartphones mit Wingo-Mobilnetz (=Swisscom)

Wenn ich aber derzeit via meiner Sunrise-IP (77.59.xxx,xxx) komme (selber Linux-PC, einfach WiFi abgeschaltet und Ethernet eingeschaltet), dann passiert das:
Das “Connection Reset” kommt nach ca. 130 Sekunden

Ich kann das Spiel auch mehrfach wiederholen: Via Wingo geht es immer, via Sunrise-DOCSIS-Netz nie

Analyse

Beim problemaitsche Fall ‘via Sunrise-Netz’ sieht der Netztraffic mit 9.9.9.9 so aus:

Was sieht man:

Pakete 1 bis 3: TCP-Connect (also der Three-Way-Handshake SYN -> SYN/ACK -> ACK) funktioniert
Paket 4: Senden des TLS-ClientHello
Paket 5: Quad9 antwortet zügig mit einem ACK (für dieses ClientHello)
-> so weit, so gut
Paket 6 ist dann irritierend: Es ist eine Wiederholung des ACK-Pakets 5, und zwar bereis 0.000041068 Sekunden nach Paket 5 (also 0.041068 ms. bzw. 40.1068 us).
Danach ist alles irgendwie ‘wirr’
Paket 11: Ein TCP Keep alive meinerseits (nach 60 Sekunden)
Paket 12: ACK seitens Quad9 –> die TCP-Verbindung besteht also noch
Paket 13: erneutes TCP-Keep-Alive (nach weiteren ca. 60 Sekunden)
Paket 14: Inzwischen hat Quad9 den Socket geschlossen und schickt ein TCP-Reset

Und wie gesagt: via Swisscom-Mobile gibt es diese Situation ab Paket 6 nicht: Keine Retransmits o.ä.

oli-h

Daniele_Sunrise

Bei Bedarf hab’ ich noch das PCAP-File - ich kann es aber nicht als Attachment o.ä. hier im Forum anhängen.
Forum sagt “Das Hochladen von Dateien dieses Typs ist nicht erlaubt”

pato

Hat eventuell mit den Ausfällen zu tun, die Quad9 am Wochenende hatte. Eventuell haben Sie Sunrise IP Ranges aktuell blockiert.

oli-h

pato Eventuell haben Sie Sunrise IP Ranges aktuell blockiert

Das glaube ich nicht, da ja klassischen DNS-Resolve via UDP Port 53 auf die IP 9.9.9.9 funktioniert.

Auch das erfolgreiche 3-way-TCP-Handshake sowie die Empfangsbestätigung des TLS-ClientHello deuten aus meiner Sicht darauf hin, dass Quad9 erstmal nix blockiert. Wenn sie blockieren wollten, wieso dann so kompliziert mit einer AC-Wiederholung.

Ich vermute eher irgendwo Packet-Loss oder irgendwas mit “IP-Packet-Fragmentation” und dem Flag “Do not Fragment”

pato

Hat eventuell mit den Ausfällen zu tun, die Quad9 am Wochenende hatte. Eventuell haben Sie Sunrise IP Ranges aktuell blockiert.

oli-h

Ich ergänze noch die Analysesession von gestern: Der Netztraffic, wenn man “curl https://9.9.9.9” via Wingo-Mobile macht, sieht so aus:

Auch hier: Was sieht man:

Die Pakete 1 bis 5 sehen gleich aus (also wie via Sunrise-DOCSIS-Netz)
Aber das bei Sunrise duplizerte ACK-Paket 6 gibt es nicht.
Dafür kommen in den Paketen 6 bis 8 ein korrektes TLS-ServerHello von Quad9
Wenn man genauer hinschaut, dann sieht man, dass das Wingo-Paket 8 in etwa dem Sunrise-Paket 7 entspricht.

im Sunrise-Netz passiert also irgendwie folgendes:

Das erste Datenpaket (Sunrise-Paket 6) wäre der erste Teil vom TLS-ServerHello. Dieses hätte eine Länge von 1448 Bytes (siehe Wingo-Paket 6). Sunrise beschneidet dieses Paket aber auf Länge 0 und damit sieht es für Wireshark wie ein reines “ACK”-Paket aus (aber eben: es hat vermulich mal Daten beinhaltet)
Das nächte Datenpaket, also Wingo-Paket 7 (erneut Länge 1448) fehlt bei Sunrise.
Der TCP-Seq-Counter ist inzwischen bei 1+1448+1448 = 2897
Dieser Seq-Counter “2897” wird im nächsten Paket sichtbar (Sunrise-Paket 7 bzw. Wingo-Paket 8).
Ein Hinweis auf Packet-Loss (Paket 7) bzw. sogar Paketmanipulation (Paket 6) durch Sunrise.

Traceroute zeigt, dass ab dem SwissIX-Node “swissix.as42.pch.net” die beiden Pfade “Sunrise” bzw. “Wingo” in Richtung Quad9 zusammenkommen. Hinter diesem Node laufen die Pakete also denselben Weg. Der Fehler muss also davor liegen - und da gehören alle Nodes der Sunrise (bzw. UPC).

oli-h

Ich hab’ inzwischen auch bei Quad9 ein entsprechendes Ticket eröffnet und eine wirklich interessante Antwort erhalten. Mit deren Erlaubnis darf ich die Stellungnahme von Quad9 hier veröffentlichen:

Unfortunately, the former UPC segment of the Sunrise network has not been fully integrated into the Sunrise network, and this segment is aware of everyone’s routes in Switzerland, but they are not announcing those routes/prefixes to Swiss-IX or CIXP, so we have to through Frankfurt back to you. This is known as an asymmetric route, and causes problems especially with TCP.

It is known. Sunrise have acknowledged the issue. They have told us it would be fixed by end of December, now “January maybe”. There is nothing we can do about this.

Sorry the news is not better. We have been consistently e-mailing their network team for months to fix this.

Da steht also sinngemäss

Sunrise hat das Routing im Internet-Exchange-Node Swiss-IX (ich vermute: in Zürich) nicht im Griff.
Eine der beiden Kommunikationsrichtungen zwischen Ex-UPC-Kunden und Quad9 (ich weiss nicht genau welche, ich vermute aber die von Quad9 zum Ex-UPC-Kunden) wird via Frankfurt geroutet . (obwohl sowohl Quad9 also auch Sunrise am Swiss-IX vertreten sind. Sunrise muss wohl lediglich den anderen mitteilen, dass diese und jene Ziel-IPs bitte direkt zum Sunrise-Router gehen sollten - und nicht via Frankfurt)
Das sind wohl Nachwehen durch die Fusion Sunrise/UPC. Die Netzwerker wollen vermutlich Redundanzen abbauen, beherrschen aber das Metier “Netz” nicht zu 100% (oder es ist ihnen egal, wenn ihre Ex-UPC-Kunden einfach verschiedene Internetdienste nicht nutzen können)
Das Problem ist dem Sunrise-Netzwerkteam also durchaus bekannt.
Der versprochene Termin “Dezember 2024” zur Lösung des Probleme wurde seitens Sunrise nicht gehalten
Das neue Versprechen “Vielleicht Januar” ist auch etwas schwammig

Meine Kundensicht ist: Sunrise sperrt mir die Nutzung von Quad9 DoT/DoH - ggfls. um die eigenen DNS-Server zu bevorzugen. Das verletzt die Netzneutralität.

GrandDixence

Die Netzwerktechnikern von Sunrise werden ihre guten Gründe haben, weshalb sie per BGP ein asymmetrisches Routing propagieren.
https://de.wikipedia.org/wiki/Border_Gateway_Protocol

Das dieses asymmetrische Routing nicht funktioniert, ist klar ersichtlich am fehlenden SERVER_HELLO.

Es gibt genügend Webseiten, wo man sich das ganze BGP-Zeugs anzeigen lassen kann, ich verstehe zu wenig von BGP, um das nachvollziehen zu können.

Aus Performancegründen sollten die DNS-Servern vom Internetanschlussanbieter (ISP) verwendet werden.
https://community.sunrise.ch/d/4397-diagnose-tool-der-connect-box-sagt-ihr-heim-netzwerk-hat-derzeit-einige-probl/2

Aus Verfügbarkeitsgründen ist der Einsatz von einem DNS-Server im Heimnetzwerk zu empfehlen, welcher bei einem Ausfall der DNS-Servern vom Internetanschlussanbieter (ISP) automatisch auf eine eigenständige (rekursive) Namensauflösung umschaltet. Unbound unterstützt diese “Rückfallebene” der Namensauflösung mit dem Konfigurationsparameter “forward-first: yes”

   forward-first: <yes or no>
          If  a forwarded query is met with a SERVFAIL error, and this op‐
          tion is enabled, unbound will fall back to normal recursive res‐
          olution for this query as if no query forwarding had been speci‐
          fied.  The default is "no".

Und aus Sicherheitsgründen sollte ein DNSSEC-validierender DNS-Server im Heimnetzwerk eingesetzt werden. Wichtige Hinweise zu DNSSEC gibt es unter:
https://community.sunrise.ch/d/36906-dns-probleme

Mit einem eigenständig, rekursiv arbeitenden DNS-Server im Heimnetzwerk ist die Netzneutralität jederzeit gewährleistet.

Ein eigener DNS-Server für das Heimnetzwerk kann man auf einem Mini-Rechner wie dem Raspberry Pi 4 betreiben. Siehe dazu:
https://www.lancom-forum.de/fragen-zur-lancom-systems-routern-und-gateways-f41/vdsl-umzug-glasfaser-neuer-router-t17926.html#p101750