Closed ZenzoK90 closed 6 months ago
Another issue that I observed is, any apps which are in Bypass DNS and Firewall Rules, are still being resolved through Rethink dns not totally bypass.
You might want to Exclude the app, if you want Rethink to not monitor it. Bypass DNS & Firewall for example wouldn't "bypass" proxies (if set). Excluded apps are included if the VPN is set in Always-on VPN + Block connections without VPN mode via Android's built-in Settings app.
And, during internet traffic congestion, the connection gets drop or disconnected most of the time and sometimes failed to connect again.
DNSCrypt is weird in that it requires from the client (Rethink in this case) to periodically "refresh certificates" unlike other encrypted protocols supported by Rethink (which have automated refreshes). Personally, I wouldn't use DNSCrypt with Rethink if facing connectivity issues, if I could use ODoH instead.
On v0.5.5d , Dnscrypt doesn't seem to be resolving via proxy/relay as shown in the log DNS section
Dup:
Unsure why this happens to some, as in our testing, DNSCrypt has no trouble routing over
Note that:
Regarding the exclusion, I just don't want to totally exclude the app (Waterfox browser, as I'm using inbuilt Dns over Oblivious Http DooH ), because if I do that, the browser won't be able to Bypass censorship anymore. But, as the name suggests this should have been bypass from user's dns within the app.
About Dnscrypt not routed via Relay, this issue is happening in the latest version not in the previous one. Though, the previous version is routing via dnscrypt relays Anonymously, this latest version does not, as I have experienced this in the previous and the current version.
But, as the name suggests this should have been bypass from user's dns within the app.
Bypass DNS & Firewall (unfortunately named as it is) only bypasses DNS (domain) block/allow rules and Firewall (IP) block/allow rules. Not the actual DNS resolver itself.
Is what you're asking for ("bypassing DNS") is similar to:
About Dnscrypt not routed via Relay
Which proxy do you use? SOCKS5, HTTP, or Always-on WireGuard / Simple mode WireGuard?
Which proxy do you use? SOCKS5, HTTP, or Always-on WireGuard / Simple mode WireGuard?
I'm not talking about those proxies, what I mean is that, in Dnscrypt there is the resolver and the relay or proxy, which, when selected both the resolver and relay, it should have been resolved the domain/host anonymously via dnscrypt relay. But, in the latest version this is not happening. It seems the resolver, resolving the hosts directly bypassing dnscrypt relay.
Ah, gotcha.
Can you share the DNSCrypt stamp in use here? And is the relay built-in? If so, which one? If not, can you share the DNSCrypt stamp for the relay?
Note that, not all DNSCrypt resolvers work with relays. Nor do all relays work themselves.
Ah, gotcha.
Can you share the DNSCrypt stamp in use here? And is the relay built-in? If so, which one? If not, can you share the DNSCrypt stamp for the relay?
Note that, not all DNSCrypt resolvers work with relays. Nor do all relays work themselves.
sdns://AQcAAAAAAAAAEzIxMy4xOTYuMTkxLjk2Ojg0NDMgiwvumeI8et789m3naGH-4xzM40t6c2xO_fCxHldawJgYMi5kbnNjcnlwdC1jZXJ0Lmlia3N0dXJt
This stamp works with relay, as I'm using the same resolver with odoh dns protocol . Tried each and every DNSCrypt public resolver but the result is the same. Previous version doesn't have this issue.
sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz
Thanks for the stamps.
Tried each and every DNSCrypt public resolver but the result is the same. Previous version doesn't have this issue.
We'll take a look at this on priority.
Regression from this commit: https://github.com/celzero/rethink-app/commit/712647379aeed55ef54d2adcba2b3f02c4d36278#diff-152e5bbaf596752c766f71a5a4c188964f006d65b213d8892cdd6bf65c2af75b (will fix it in v055f
due in a few days).
Livedata to detect dnscrypt relay changes, Fix: #37885776
DNSCrypt is weird in that it requires from the client (Rethink in this case) to periodically "refresh certificates" unlike other encrypted protocols supported by Rethink (which have automated refreshes). Personally, I wouldn't use DNSCrypt with Rethink if facing connectivity issues, if I could use ODoH instead.
DNSCrypt is still not usable most of the time as it keeps disconnecting after few seconds. In the latest update, RethinkDns crashes when connection failure. Hopefully, this issue will get fixed in upcoming updates as I prefer mostly DNSCrypt protocol to connect with the internet.
DNSCrypt is still not usable most of the time as it keeps disconnecting after few seconds
Which DNSCrypt resolver? Can you share its Stamp (tap on the i
icon next to the DNSCrypt resolver entry (in Configure -> DNS -> Other DNS -> DNSCrypt) to copy its Stamp)?
DNSCrypt is still not usable most of the time as it keeps disconnecting after few seconds. In the latest update, RethinkDns crashes when connection failure.
This is concerning. Are you on v055h
?
If you're technical enough, can you email crash logs captured from exactly the time the crash happens via adb logcat
(ref) to mz
at celzero
dot com
(do mention this github issue)?
Which DNSCrypt resolver? Can you share its Stamp (tap on the
i
icon next to the DNSCrypt resolver entry (in Configure -> DNS -> Other DNS -> DNSCrypt) to copy its Stamp)?
sdns://AQcAAAAAAAAADTUxLjE1LjEyMi4yNTAg6Q3ZfapcbHgiHKLF7QFoli0Ty1Vsz3RXs1RUbxUrwZAcMi5kbnNjcnlwdC1jZXJ0LnNjYWxld2F5LWFtcw
This is concerning. Are you on
v055h
?If you're technical enough, can you email crash logs captured from exactly the time the crash happens via
adb logcat
(ref) tomz
atcelzero
dotcom
(do mention this github issue)?
Yes, Im on v055h latest release. Im not a tech savvy, but as you've suggested, I try to capture logcat file using adb but the file size is to big which is beyond the permissible size , so I couldn't mail the log file.
Im not a tech savvy, but as you've suggested, I try to capture logcat file using adb but the file size is to big which is beyond the permissible size , so I couldn't mail the log file.
Zip (compress archive) it? That should reduce the size by 5x to 10x.
Im not a tech savvy, but as you've suggested, I try to capture logcat file using adb but the file size is to big which is beyond the permissible size , so I couldn't mail the log file.
Zip (compress archive) it? That should reduce the size by 5x to 10x.
Yes, compression has reduced the size but mz at celzero dot com mail couldn't be found and the sending has failed. Am I missing something here. 🤔
Yes, compression has reduced the size but mz at celzero dot com mail couldn't be found and the sending has failed. Am I missing something here. 🤔
I have sent the log file to hello at celzero dot com, as there's something wrong with the email provided by you. Hope you received it.
Dnscrypt protocol provided in RethinkDns app is unusable at all, at first it gets connected but after few seconds got disconnected and reconnect and again disconnect. It goes on like this. Try different resolver with different relays, but nothing seems to help. It's really annoying that, though the DNSCrypt protocol is available in the app itself but cannot use it properly like other dns protocols. Hopefully you could do something for this in upcoming days.
I have sent the log file to hello at celzero dot com, as there's something wrong with the email provided by you. Hope you received it.
Yes, thanks. We've fixed the crash, too.
Dnscrypt protocol provided in RethinkDns app is unusable at all, at first it gets connected but after few seconds got disconnected and reconnect and again disconnect. It goes on like this.
Thanks. Looking at the logs you sent for clues. Stay tuned.
Thanks. Looking at the logs you sent for clues. Stay tuned.
Regarding dnscrypt not working properly, hope you'll also fix this as soon as possible 😁 because I mostly use dnscrypt than other dns protocols.
The server is refusing connections (either the server does not respond to IP from your network or your network is dropping connections to the server or IPv4 is not supported). Both DNSCrypt over TCP and UDP are retried and both fail:
# udp times out
04-27 23:08:39.034 7363 8000 E GoLog : multiserver.go:123: E dnscrypt: udp: [Preferred] write err; [write udp w.x.y.z:60114->174.138.29.175:1443: i/o timeout]
# retry
04-27 23:08:39.034 7363 8000 I GoLog : multiserver.go:256: D dnscrypt: udp failed, trying tcp
# tcp errors out
04-27 23:05:05.879 28897 6310 E GoLog : multiserver.go:265: W dnscrypt: querying [udp? false; tcpfallback?: true] failed: dial tcp 174.138.29.175:1443: connect: connection refused
I tried the stamp you shared above^f1 and it worked on my Android just fine both over Wifi and Mobile.
I set network IP version to AUTO always and tried both resolver and relays with IPv6 by switching IP version to ipv6 mode but still connections are dropped.
Is there a difference in handling Dnscrypt connections between RethinkDns and Invizible Pro app? Because when I try those same servers in Invizible Pro, the connections seem stable, no disconnection in between.
So, is there any workaround or solutions which I can try from my side to bypass this issue to make the connections stable.
Dnscrypt connections between RethinkDns and Invizible Pro app
Could be, but both InviZible and Rethink borrow / run the code from the dnscrypt-proxy project. Rethink does not fallback to other DNSes on send/recieve errors (but it does fallback on setup errors, and when it happens, a label Using Fallback DNS
is shown on Rethink's Homescreen). That is, failures in user-selected DNS are very apparent in Rethink. Unsure what InviZible does.
there any workaround or solutions which I can try from my side to bypass this issue
I can't think of any more workarounds other than using ODoH if you desire the anonymity properties of DNSCrypt+Relays.
I used the stamp you shared for over 2 days and never once did it fail. I use Auto all the time too, and in my case, both Wifi and Mobile support IPv4.
Unsure what InviZible does.
Strange! But Invizible really is more stable when handling Dnscrypt protocol.
- Do you have Configure -> DNS -> DNS Booster enabled?
Yes, DNS Booster is enabled.
- Does not using a relay improve stability?
The connection isn't stable even without the relay but yes, there's a difference in connection stability with and without relay as it doesn't disconnect more often. When selected a single relay, some Dnscrypt resolver stays connected for some time but, when I browse the internet back after leaving the RethinkDns app as well as my phone for some time, it fallback to ISP's dns instead of user-selected Fallback DNS (seems another bug in the latest version). It reconnect only when I open Rethink app again. Though, I have disabled battery optimization for Rethink.
I can't think of any more workarounds other than using ODoH if you desire the anonymity properties of DNSCrypt+Relays.
Alright then, if the problem cannot be solved from your end, I think it's better you close this issue. For now I'll try to stick to ODoH. Thanks.
when I browse the internet back after leaving the RethinkDns app as well as my phone for some time, it fallback to ISP's dns instead of user-selected Fallback DNS
Curious: How did you determine System DNS is being used? By looking at DNS Logs in Rethink (tapping on entries in Configure -> Logs -> DNS should show, in a bottomsheet that comes up, the server that particular query was sent to). Using website based "DNS leak" tests may be misleading at times. For example, turning ON Configure -> DNS -> Show website icon in DNS Logs will confuse those website based tests.
doesn't disconnect more often
This disconnect is in form of Rethink using another upstream (like you say, System DNS) or failure? The logs you shared show connection timeouts and not Fallback DNS or System DNS.
Invizible really is more stable
Like I said, I used the same DNSCrypt stamp you shared (without Relay) and the connection was stable. So, it really is puzzling why connections are timing out on your Android. One explanation is, on Android 14 onwards, Rethink's connections are being blocked by Android itself. Make sure Rethink can access both Mobile data and WiFi even when in background. This setting is found in different places on different phones. For me, these are under:
Curious: How did you determine System DNS is being used?
I mostly use browserleaks.com to check dnsleak. Yes, system dns is being use if there's an error or server down from the dns resolver and it doesn't fallback to user-prefered dns, instead it's disconnecting.
So, it really is puzzling why connections are timing out on your Android.
I'm on Android 11 Samsung device and always using mobile data therefore, could not try it on Wi-Fi if there's any differences. Maybe there's some connectivity issues with my ISP which leads to disconnection.
Don't know why only Dnscrypt has this connectivity issue here whereas, other dns protocols present in the Rethink app are working just fine.
Feeling strange 😕. After few disconnection issue, the network connectivity stays for longer period of time but, when I do dns check again the same happens, but it reconnect again only when I open the app. Every time when I open the app I saw its on waiting and reconnect again in no time. Seems, there's something going on while the app is in background. Note: I have disabled battery optimization. Data usage while on background is enable.
Updated: At last, the DNSCrypt issues has been fixed finally in v0.5.5j latest version. No disconnection in between anymore and working just like other dns protocols. Thanks to the team for fixing this issue.
Thanks for keeping us in the loop.
I don't know what might have fixed it, tbh! We didn't make any specific changes to address this particular issue. Glad it auto-resolved. Closing for now (feel free to re-open).
On v0.5.5d , Dnscrypt doesn't seem to be resolving via proxy/relay as shown in the log DNS section. Whereas, ODOH does not have this issue and its resolving via odoh proxy. And, during internet traffic congestion, the connection gets drop or disconnected most of the time and sometimes failed to connect again. Another issue that I observed is, any apps which are in Bypass DNS and Firewall Rules, are still being resolved through Rethink dns not totally bypass.