Probleme mit WLAN wenn privates DNS genutzt wird

[FatManStanding]

Hallo,

ich nutze aufauf dem Smartphone (xiaomi mi 10 lite mit lineageOS 19, d.h. Android 12) privat DNS Einstellungen (cloudflare). Das gleiche habe ich im Router eingestellt. Ich bin dadavon ausgegangen, dass das private DNS nur für mobiles Internet genutztgenutzt wird. Wenn ich im WLAN bin sollte das DNS des Routers greifen. In den WLAN Einstellungen am Smartphone istist der Router als DNS server eingestellt.

Es kommt dann aber vor, dass das Smartphone im WLAN kein Internet hat. Ich kann aufauf dem Router und andere interne netzwerkgeräte zugreifen, Internet habe ich keines. Nach einer Weile geht alles wieder. Schalte ich private DNS aus passiert das nicht.

Kennt das verhalten jemand?

 

[Blutomen]

Wenn du im Smartphone das private DNS aktivierst wird das immer genutzt. Egal ob WLAN oder Mobile.
Jedoch sollte dein Smartphone damit auch im WLAN funktionieren außer du blockst dir im Heimnetz irgendwas weg.

 

[JennyCB]

Hier habe ich nur im Router einen alternativen DNS-Server eingetragen.
Sobald die Smartphones dann im Haus sind benutzen sie WLAN vom Router statt 4G/5G etc.
Das funktioniert soweit einwandfrei.

 

[Helge01]

Privates DNS ist ja DoH. Die DoH Cloudflare Adresse heißt https://dns.cloudflare.com/dns-query Wie man sieht ist das keine IP-Adresse, daher muss der Client erst eine herkömmliche unverschlüsselte DNS Abfrage für diese URL stellen, bevor er dann alle weiteren DNS-Auflösungen darüber verschlüsselt.

Da scheint es bei dir ein Problem zu geben. Wenn du im Router auch nur DoH zulässt, dann hat der Client keine Möglichkeit die Cloudflare Adresse aufzulösen.

An DoH ist aber wenig privat, da du dein komplettes Surfverhalten einen großen amerikanischen Anbieter mitteilst, der sich nicht mal wie dein Provider an EU Datenschutz halten muss.

 

[FatManStanding]

Bei mir steht da 1dot1dot1dot1.cloudflare-dns.com. wenn ich http da einfügen ist der ok-button grau. Das will er nicht.

 

[Helge01]

@FatManStanding Ist ja aber auch eine URL und keine IP-Adresse, daher gilt das gleiche. Der Client muss eine Möglichkeit haben diese Adresse aufzulösen.

 

[FatManStanding]

Dort gibt es nur die Möglichkeit den Hostnamen einzugeben. IPs werden ueberhaupt nicht genommen.

 

[Helge01]

@FatManStanding Auch das ist richtig, da DoH immer eine URL ist.
Deswegen muss dem Client eine herkömmliche unverschlüsselte DNS Auflösung möglich sein. Die hast du aber durch aktivieren von DoH im Router genommen.

Eigentlich ist zur Zeit verschlüsseltes DNS Unfug, da der Provider immer weiß welche Seite du aufrufst, außer du benutzt ein VPN, dann weiß es der VPN Anbieter. Beim Verbindungsaufbau zum Webserver per HTTPS wird vor der eigentlichen Verschlüsselung eine unverschlüsselte Client-Hello Nachricht gesendet. In dieser steht in Klartext der Hostnamen vom aufgerufenen Webserver.

Ob du zuvor die Namensauflösung per DoH verschlüsselt hast ist dann eigentlich egal.

Es sieht mindestens immer einer welche Webseite du aufrufst.

• DoH/DoT -> der DNS-Anbieter und der ISP
• eigener Unbound/Resolver oder ISP-DNS -> der ISP
• VPN + DoH/DoT -> der VPN- und der DNS-Anbieter

 

[h00bi]

Es kommt dann aber vor, dass das Smartphone im WLAN kein Internet hat.

Bekommst du ne Meldung?
Ich hatte das neulich im Gast-WLAN bei meinen Eltern, da hieß es der private DNS wäre nicht erreichbar/verfügbar.
Kam dann direkt als Pop-up auf dem Handy.

 

[cbtaste420]

Beim Verbindungsaufbau zum Webserver per HTTPS wird vor der eigentlichen Verschlüsselung eine unverschlüsselte Client-Hello Nachricht gesendet. In dieser steht in Klartext der Hostnamen vom aufgerufenen Webserver.

Dafür gibt es doch mit ECH eine Lösung.
Firefox und Chromium-Derivate unterstützen ECH bereits.
https://tls-ech.dev/
https://www.cloudflare.com/ssl/encrypted-sni/

 

[Helge01]

Dafür gibt es doch mit ECH eine Lösung.

Ist mir bekannt, nur das unterstützt kaum einer. Ursprünglich sollte standardmäßige SNI Verschlüsselung der Client-Hello Nachricht mit Protokoll TLS 1.3 kommen, wurde aber verworfen. Das hätte was gebracht da dadurch jede TLS 1.3 Verbindung geschützt wäre.