celzero
v055o: Internal DNS not resolving
Requests for external domain names resolve as expected, but internal ones from my own DNS server do not -- e.g. curl reports:
* Host example.internal:80 was resolved.
* IPv6: 64:ff9b:1:da19:100:33fc:99de:2e9f
* IPv4: (none)
Context:
- DoH DNS server which serves records for e.g.
example.internal CNAME server.internal,server.internal A 172.16.1.1 - Wireguard split proxy which routes
172.16.0.0/16, and uses the same DNS server but via WG - Choose IP version = IPv4
Tried various combinations of:
- Choose IP version
- Advanced DNS filtering
- Split DNS
- Never proxy DNS
...but seemingly no change between them.
These requests don't appear to show up in the request log.
This was all working fine in v055n.
Logcat (with Advanced DNS filtering)
D RethinkDnsVpn getConnectionOwnerUid(): 10291, 17|10.111.222.1|10.111.222.3|53, null, 10.111.222.1, 10.111.222.3
D RethinkDnsVpn preflow: 10291, 10.111.222.1, 32099, 10.111.222.3, 53
I RethinkDnsVpn preflow: returning 10291 for src: 10.111.222.1:32099, dst: 10.111.222.3:53, isRethink? false
I GoLog D udp.go:173>common.go:213: com: udp: onFlow: noalg? true or hasips? true
I GoLog D udp.go:173>common.go:217: com: udp: onFlow: no realips(10.111.222.3) or domains( + ), for src=10.111.222.1:32099 dst=10.111.222.3:53
D RethinkDnsVpn VpnService; flow: 10291, 10.111.222.1:32099, 10.111.222.3:53, 10.111.222.3, null, null
D RethinkDnsVpn VpnService; createConnInfoObj: uid: 10291, srcIp: 10.111.222.1, srcPort: 32099, dstIp: 10.111.222.3, dstPort: 53, protocol: 17, query: null, connId: 627a8d85da89e588
D RethinkDnsVpn VpnService; flow: dns-request, returning Base, 10291, 627a8d85da89e588
I RethinkDnsVpn flow/inflow: returning mark: Mark{PIDCSV:Base,CID:627a8d85da89e588,UID:10291,} for connId: 627a8d85da89e588, uid: 10291, cm: null
D RethinkDnsVpn VpnService; onQuery: rcvd uid: 10291 query: example.internal, qtype: 28
D RethinkDnsVpn (onQuery)no split dns, using Preferred
D RethinkDnsVpn VpnService; onQuery (Dns+Firewall):example.internal, dnsx: DNSOpts{PIDCSV:wg3,Base,IPCSV:,TIDCSV:Preferred,TIDSECCSV:,NOBLOCK:false,}
I GoLog V transport.go:537: dns: fwd: 1 for 10291; query example.internal:28 [prefs:&{wg3,Base Preferred false}; chosen:[]]
I GoLog V transport.go:542: dns: fwd: 2 for 10291; query example.internal:28 [prefs:&{wg3,Base Preferred false}; chosen:[]]; id? Preferred, sid? , pid? wg3,Base, ips? []
I GoLog D wall.go:121: wall: skip local for example.internal. blockQ for with err no blocklist applies
I GoLog V transport.go:577: dns: fwd: 4 for 10291; query NOT blocked example.internal; why? no blocklist applies
I GoLog V transport.go:800>transport.go:754>alg.go:1681: alg: resolv: example.internal:Preferred[10291] => real(ip4 0, ip6 1) until: 0s; stale []
I GoLog D transport.go:800>dns64.go:172: dns64: for(udp:wg3,Base 10291), no-op q(example.internal.), q6(true), ans6(true), force64(false), ans0000(false)
I GoLog D wall.go:121: wall: skip local for example.internal. blockQ for with err no blocklist applies
I GoLog D wall.go:163: wall: no blockA for example.internal.; blocklist-stamp? (0) / rdnsr? (true)
I GoLog D wall.go:182: wall: answer for example.internal. not blocked answers not in blocklist 1:6B9lAokBAxGynT_wkAlWcyEAAAg=
I GoLog D alg.go:1043: alg: Preferred<>Preferred[10291]; example.internal:28 a6(a 1 / h 0 / s true) : a4(a 0 / h 0 / s false); ttl: 0s
I GoLog D alg.go:1083: alg: ok; for Preferred<>Preferred[10291]:example.internal:28, domains [example.internal] real: [64:ff9b:1:fffe::ac10:101] / fix: [] => subst invalid IP | 64:ff9b:1:da19:100:33fc:99de:2e9f; (mod? true / fix? false / synth? false); sec [64:ff9b:1:fffe::ac10:101]; ttl 0s
I GoLog D transport.go:800>alg.go:544: alg: merge: err ips merge; pri(1/1) sec(1/1), out(algans: algip(64:ff9b:1:da19:100:33fc:99de:2e9f) base(xips(xips: pri(map[Default:addrs([64:ff9b:1:fffe::ac10:101] / ttl: -5m1.734313736s) Preferred:addrs([64:ff9b:1:fffe::ac10:101] / ttl: 7.99990625s)]) sec(map[Preferred1
I GoLog D 0140:addrs([64:ff9b:1:fffe::ac10:101] / ttl: -3m19.696786014s) Preferred10291:addrs([64:ff9b:1:fffe::ac10:101] / ttl: 7.99990125s) Preferred10400:addrs([64:ff9b:1:fffe::ac10:101] / ttl: -3m17.092345182s)])) domains([example.internal server.internal]) blocklists() ttl(-1m 59s)))
I GoLog D async.go:58>alg.go:1227: alg: algips (reg? true / new? false) (alg: invalid IP+64:ff9b:1:da19:100:33fc:99de:2e9f => real: [64:ff9b:1:fffe::ac10:101]) for example.internal@Preferred[10291]; real? 1, sec? 1; until (ans: 1m59.99988448s / xips: 7.999884271s)
I GoLog D wall.go:163: wall: no blockA for example.internal.; blocklist-stamp? (0) / rdnsr? (true)
I GoLog D wall.go:182: wall: answer for example.internal. not blocked answers not in blocklist 1:6B9lAokBAxGynT_wkAlWcyEAAAg=
I GoLog V transport.go:641: dns: fwd: 5 for Preferred[10291]; query example.internal:28, smm[data: 64:ff9b:1:fffe::ac10:101,64:ff9b:1:da19:100:33fc:99de:2e9f, status: 1]; new-ans? false, blocklists? false, blocked? false
D RethinkDnsVpn VpnService; onResponse: type: DNS-over-HTTPS, id: Preferred, latency: 0.001826, qname: example.internal, rdata: 64:ff9b:1:fffe::ac10:101,64:ff9b:1:da19:100:33fc:99de:2e9f, rcode: 0, rttl: 0, server: alg.dns.internal, relay: , status: 1, blocklists: , msg: no error, loc:
I GoLog D transport.go:802: dns: udp: for 10291 err! tot: 1, t: 2ms, <nil>
I've also reinstalled v055n via GitHub releases, restored my backup, updated to v055p, but the problem persists.
Thanks for the logs. Those don't show anything untoward; since they only contain IPv6 query request/response cycle, while you're expecting there to be an IPv4 query?
There must also have been further logs when the app in question (seems like 10291) tries to connect to 64:ff9b:1:da19:100:33fc:99de:2e9f (unique IP assigned for Advanced DNS filtering purposes or 64:ff9b:1:fffe::ac10:101 assigned for internal NAT64/DNS64 which will be translated from ac10:101 to 172.16.1.1) and if there's something there going wrong (including routing to wg3), the other logs would show that.
These requests don't appear to show up in the request log.
As in, you don't see an entry in Configure -> Logs -> Network? Or in adb logcat (btw, we also push our app's logs to Configure -> Settings -> App logs; you can change the log level to "Debug" or "Verbose" or "Very Verbose" by clicking on the filter icon in the search bar).
v055oonwards, all DNS queries (except DNSSEC) are answered with a TTL of 0, to make Android not cache any answers. Unsure if that's tripping apps?
I've downgraded again on my main device for now, as unfortunately this breaks quite a bit of local stuff I've set up, and it's a bit of a nuisance having to restore both main and work profiles.
The log snippet is at Verbose level, and of one cycle of Termux curling an internal URL in a loop (i.e. the log lines that repeated each time), so plausibly something interesting happened earlier.
I'll try and get a separate device set up later so I can just leave it running, and get a more complete log without needing to redact other requests.
As in, you don't see an entry in Configure -> Logs -> Network?
I don't believe it was appearing in either tab of the Logs screen, but hold that thought and I'll try to catch the full flow next time.
I'll try and get a separate device set up later so I can just leave it running, and get a more complete log without needing to redact other requests.
We'll want to release v055r soon-ish if we end up fixing significant other issues (such as this one), and so if you do get your hands on "Very verbose" logs for this, let us know.
it's a bit of a nuisance having to restore both main and work profiles
Don't rely on the restore feature too much :D
Choose IP version = IPv4
Surprisingly, there's AAAA queries (IPv6) from apps, even though IPv6 is marked unroutable / unreachable.
Problem at firewall, when I actived the firewall, network slow down. If just active DNS, network is ok
I've set up v055q on a new device, stock settings, and imported a Wireguard profile. When enabled, I seem to have no DNS at all -- status line shows Protected with Wireguard until I make a request and it times out, then switches to No connection.
Logs screen: Network tab is empty, DNS shows:
- successful lookup for the external Wireguard endpoint (both IPv4 and IPv6)
- successful lookup for
ipv4only.arpa(both IPv4 and IPv6 6to4) - failed (⚠) lookups with a 15000ms timeout for all my subsequent requests
The built-in log viewer only had a handful of lines so I've grabbed a Very Verbose logcat via ADB.
📎 logcat-2025-08-14-22-55-46.log
Wireguard profile
[Interface]
PrivateKey = ...
Address = 10.9.0.5/32, fe80:94::5/128
DNS = 10.9.0.1, fe80:94::1
[Peer]
PublicKey = ...
AllowedIPs = 172.16.1.1/32, 10.9.0.0/16, fe80:94::/32
Endpoint = external.example:51871
set up v055q on a new device, stock settings, and imported a Wireguard profile. When enabled, I seem to have no DNS at all -- status line shows Protected with Wireguard until I make a request and it times out
Can you turn OFF Block connections without VPN if it is not? v055q on some ROMs is unhappy with it. Since we ourselves have a test device which exhibits such behaviour, we should be able find a workaround in a day or two.
Also see if setting Choose IP version to either IPv4 or Auto works?
firewall, when I actived the firewall, network slow down. If just active DNS
Thanks for the logs. Those are issues with our ICMP handling which we have to resolve but haven't had the time yet to do so.
For reference, test device is a OnePlus 5, running LineageOS 22.2 (Android 15) + microG.
Neither of the Always-on VPN or Block connections without VPN Android system options are enabled here (though they are on my main device). Choose IP version was the default IPv4, seemingly no change when set to Auto.
Ominous. We are redoing a bunch of things. Hopefully will be able to share a build by tomorrow.
failed (⚠) lookups with a 15000ms timeout for all my subsequent requests
08-14 22:57:03.932 11542 11605 I GoLog : E async.go:58>transport.go:806: dns: udp: for -1 err! tot: 2, t: 15006ms, read udp 10.9.0.5:53347: i/o timeout
...
08-14 22:57:03.932 11542 11782 D RethinkDnsVpn: VpnService; onResponse: type: DNS, id: wg2, latency: 15.006313, qname: www.google.com, rdata: --, rcode: 2, rttl: 0, server: 10.9.0.1:53, relay: wg2, status: 2, blocklists: , msg: read udp 10.9.0.5:53347: i/o timeout, loc:
...
08-14 22:57:03.932 11542 11605 I GoLog : E async.go:58>transport.go:806: dns: udp: for -1 err! tot: 2, t: 15006ms, read udp 10.9.0.5:53347: i/o timeout
It seems like the DNS resolver at 10.9.0.1:53 isn't responding.
Did you redact the "uid" in the logcat output and set it to -1? Because otherwise Lineage22 (Android 15) is exhibiting pre-Android 12 behaviour here. Split DNS won't work on such ROMs.
I've disabled Split DNS (it's marked experimental but on by default, is that expected?) but seemingly no change. 🙁
Still seeing dns: udp: for -1 err! (not redacted) in the log: logcat-2025-08-15-08-41-27.log
(requests should all be attributed to org.lineageos.jelly, PID 4736, which doesn't appear in the log)
I've disabled Split DNS (it's marked experimental but on by default, is that expected?) but seemingly no change. 🙁
Still seeing
dns: udp: for -1 err!(not redacted) in the log: logcat-2025-08-15-08-41-27.log (requests should all be attributed toorg.lineageos.jelly, PID 4736, which doesn't appear in the log)
The big problem at firewall feature, not DNS. So, please wait for team release new version. Or you can back 0.5.5n
Split DNS (it's marked experimental but on by default, is that expected?
Experimental because Split DNS is new and required extensive changes (ref) that all mostly work just fine.
It is attempted by default on Android 12+ devices as it should work and hence enabled on Android 12+ ROMs ... Unfortunate Lineage deviates away from AOSP (Lineage reports -1 when Rethink asks it for the identity of which uid sent a particular DNS query).
Have they flipped this switch? If so, why?
Curious: Do you see ANY app name (besides "Unknown" for -1) in DNS logs on your Lineage device?
Still seeing dns: udp: for -1 err
Is the WireGuard DNS functional & responsive? A timeout usually indicates it isn't responding or running.
It does seem like everything is being reported as UID -1, even when not connected via Wireguard, so maybe LineageOS has protected this information. I can have a look at putting the stock OS back on here and see if that changes things, though I think it stopped at Android 10 so I don't know how representative that will be. Alternatively, if you have any suggested OSes that work better with Rethink, I can see if any are supported / built for the device.
does seem like everything is being reported as UID -1, even when not connected via Wireguard, so maybe LineageOS has protected this information
And this results in all entries being 'Unknown' in Configure -> Logs -> DNS?
Can you see if turning ON Advanced DNS filtering and Split DNS then is able unearth the actual uid?
My guess is, most likely Lineage broke it. You can report this to them and see what they say? An active VPN app has the permissions applied to it to get this information.
look at putting the stock OS back on here
You don't have to go through the motions just for us (: and the stock Android 10 is going to be much worse than Lineage.
Indeed, everything except for Rethink's ipv4only.arpa requests show Unknown as the source app in the DNS tab (Advanced DNS filtering and Split DNS both enabled), despite apps being mostly attributed in the Network tab (the exceptions being some Google domain requests I guess coming from the system).
Have they flipped this switch? If so, why?
Seemingly not, though this is a few versions ago so I'm not sure where their current code is (or it might just unchanged since here).
Indeed, everything except for Rethink's ipv4only.arpa requests show Unknown as the source app in the DNS tab (Advanced DNS filtering and Split DNS both enabled
With Advanced DNS filtering + Split DNS turned ON, Split DNS should work across Android versions and be able to attribute individual DNS requests to app, regardless. If it doesn't, that's bug.
The fact that Rethink continues to show Unknown in DNS logs (and not update the app name when the said app sends egress request to its uniquely assigned IP via Advanced DNS filtering) is either an implementation oversight on our part or a bug (as in, Split DNS isn't happening at all).
Grabbed some screenshots in case I've missed something obvious...
Wireguard on:
(the
255.255.255.255 requests seem to be new since v0.5.5r, though might just be because I left Wireguard on, and therefore connection disrupted, overnight; no other connections appear in the Network tab)
Wireguard off:
(DNS requests still not attributed to apps, but Network tab populated and correctly attributed)
Settings:
(should all be defaults, except Advanced DNS filtering, Split DNS and Log level)
Thanks for the screenshots.
This is very weird. Have you setup Rethink in a separate profile or private space? And is Lineage routing traffic of those profiles to the main user (main profile)? That's one scenario where I can see why there'd be so many (in fact, all?) connections attributed to "Unknown" apps.
Do you also see "Unknown" for corresponding entries in Network logs (ie, IPs shown in DNS logs as "Unknown" also appear as "Unknown" in Network logs), too?
Just the main Owner profile, nothing fancy here -- it's a spare phone, and all that's currently installed is Rethink and Syncthing (stopped while I'm testing to keep noise out of the logs).
It's all requests except Rethink's own (ipv4only.arpa, blocklists) being attributed to Unknown.
Network tab logs show the requests attributed correctly, it's just the DNS tab not matching things up.
No immediate change in v0.5.5t.
However, after switching to Wireguard > Advanced tab and enabling my Wireguard configuration for all apps, DNS requests are now associated with their originating apps in both Logs > DNS and Logs > Network! Still no actual DNS resolution though.
Fresh log: logcat-2025-08-22-19-44-36.log
Thanks for the logs.
However, after switching to Wireguard > Advanced tab and enabling my Wireguard configuration for all apps, DNS requests are now associated with their originating apps in both Logs > DNS and Logs > Network!
The fact that you see app names just fine with Advanced WireGuard but not with Simple WireGuard is ... confusing: #2159 I've looked at the logs (shared on 15 Aug) 4 to 5 times now and it isn't clear why this would happen (the logs clearly point to -1 as the owner app returned by the OS for a given DNS query, which shouldn't be the case on Android 12+, regardless of WireGuard being in Simple or Advanced mode).
Still no actual DNS resolution though.
I checked the latest logs (22 Aug), and all it tells is, internal WireGuard DNS is not responsive (the same as in previous logs). The timeouts are a generous at 15secs, and yet no DNS answers flow in. Can you flip the DNS to 1.1.1.1 for your WireGuard and see if that works? If so, we know that the internal WireGuard DNS 10.9.0.1 isn't working...
You could also route Termux through the internal WireGuard and install dig or nslookup and see if it is able to get answers from 10.9.0.1 (make sure to turn OFF Configure -> DNS -> Prevent DNS leaks when you test this and Split DNS turned ON + Advanced DNS filtering if you continue to see Unknown in DNS logs despite Split DNS).
Apologies, I think the repro device had a mismatched Wireguard config -- having set both ends up again with a different IP, it seems to all be fine. 😩
Working as intended, for comparison: logcat-2025-08-24-16-19-10.log
#2159: The DNS tab attribution failing in Simple / working in Advanced modes still seems to apply even when DNS is now working.
So looking back at the originally reported issue, seems I can't actually reproduce it on a second device. I'll try and find some time tomorrow to do an update and settings reset on my main device and see if things start working again.
Debugging woes (possibly some other bits of interest)
Can you flip the DNS to
1.1.1.1for your WireGuard and see if that works?
Choice of DNS server doesn't seem to matter, whether one internal to the Wireguard connection or not:
I'm fairly confident the internal DNS is working and bound to the Wireguard interface -- here's a check from an unrelated device which isn't on the local network:
$ dig @10.9.0.1 test.internal.example
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @10.9.0.1 test.internal.example
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42897
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 0
; EDE: 4 (Forged Answer): (CUSTOM DNS)
;; QUESTION SECTION:
;test.internal.example. IN A
;; ANSWER SECTION:
test.internal.example. 0 IN CNAME internal.example.
internal.example. 0 IN A 172.16.1.1
;; Query time: 11 msec
;; SERVER: 10.9.0.1#53(10.9.0.1) (UDP)
;; WHEN: Sun Aug 24 15:25:02 BST 2025
;; MSG SIZE rcvd: 108
You could also route Termux through the internal WireGuard and install
digornslookupand see if it is able to get answers from10.9.0.1
Trying to ping from within Termux leaves an interesting footprint in the Network tab (no responses being logged in Termux):
Log of these attempts: logcat-2025-08-24-15-41-19.log
Ok, I've been poking around with v0.5.5t on my main device, first as an in-place upgrade from v0.5.5n, then an app data wipe and running with just the stock settings + Advanced DNS filtering + Wireguard config -- I can continue to repro problems in both cases, though it's acting a little different than what I originally saw with v0.5.5o.
With a split-tunnel Wireguard config, requests outside of the home network are successful and appear in both DNS and Network tabs as normal (also correctly attributed to apps in both tabs, i.e. I can't repro #2159 here).
Requests inside the network, as well as any requests with a full-tunnel config, don't resolve at all (straight DNS resolution failures, rather than the IPv6 64: addresses making it through like in the OP curl snippet). There seem to be two types of failure here:
- immediate fail, no entry in either of Network or DNS tabs
- delay of 25 or 30 seconds before fail, usually a DNS tab entry like this:
After running for a bit, the Wireguard screen notes DNS forwarded to RDNS Default, Fallback, which of course won't resolve my internal domains.
📎 logcat-2025-08-25-18-40-07.log
Setting the Wireguard config's DNS to e.g. 1.1.1.1 as suggested before doesn't seem to make a difference, though I'm not sure if my attempts are being scuppered by caching as they're the only ones I can see in the log for the failing cases (and they still don't seem to appear consistently).
Setting the Wireguard config's DNS to e.g. 1.1.1.1 as suggested before doesn't seem to make a difference, though I'm not sure if my attempts are being scuppered by caching as they're the only ones I can see in the log for the failing cases (and they still don't seem to appear consistently).
Unlikely, since the caching layer is a write-through (as in, it is always used when DNS Booster is set) and will forward queries to the actual DNS upstream as required (stale answers, cache miss, background refresh of popular domains, etc).
immediate fail, no entry in either of Network or DNS tabs
On v055t, this is concerning! I have never seen this myself. Do you see any running "dns:" logs or "wg:" logs in logcat that point to any obvious issue/error? It is quite tiresome to correlate the very many verbose logs with such failures, so understandable if you can't.
delay of 25 or 30 seconds before fail, usually a DNS tab entry like this:
I have seen these timeouts with (public) WireGuard DNS, but they are not frequent. It isn't clear why this happens, though surely there's something stupid in our DNS-related code that trips WireGuard the way it does.
The timeouts I was seeing is gone now when I add the DNS endpoint in "AllowedIPs" to one of the Peers. Can you see if doing so helps?
If so, we can think about adding DNS IPs in "AllowedIPs" to ALL peers, but unsure if that's the right thing to do.
The timeouts I was seeing is gone now when I add the DNS endpoint in "AllowedIPs" to one of the Peers.
My split-tunnel Wireguard defines one peer which is also the DNS server -- the configured DNS server IPs (10.9.0.1, fe80:94::1) are already part of the peer's Allowed IP ranges (172.16.1.1, 10.9.0.0/16, fe80:94::/32); I've tried adding the home network device IP as a DNS server too but no change there.
immediate fail, no entry in either of Network or DNS tabs
On
v055t, this is concerning!
I can't seem to repro this any more; everything is at least showing up in the DNS tab today. Will keep an eye out.
After a few more hours of poking, I've set my default (non-WG) DNS to the home network DNS (using a public subdomain), and with that I can seemingly resolve most of my lesser-used internal domains ok, but externally -- the DNS server logs show the request coming from my external IP address, and Rethink's DNS tab shows the external DNS domain used, which aligns with the previous observation of fallback DNS kicking in.
Even with that, there seems to be a couple of regularly-accessed subdomains that still fail to resolve, as well as a brand new one I added, so not sure if there's any correlation there or just observation bias (for the avoidance of doubt, these resolve fine from other devices, as well as on this device using v0.5.5n).
Here's a pair of very verbose logs for (hopefully) a single request to one working and one broken subdomain (the log streams fast so this is | grep -C 100 <domain>; I can try again with more context if needed), for a game of spot the difference:
📎 2025-08-30-logcat-rethink-grep-broken.log 📎 2025-08-30-logcat-rethink-grep-working.log
And here's another broken one while not connected to Wireguard and just using my internal DNS directly:
📎 2025-08-30-logcat-rethink-grep-broken-direct.log
(*.external.example and 100.100.100.100/aaaa:aaaa:aaaa:aaaa:1111:1111:1111:1111 represent public-facing subdomains and IPs; *.internal.example is only provided by the internal DNS and serves 172.16.0.0/16 records.)
Thanks for the logs! You're one of the few who shares those (:
I took a look at them to see if there's anything obvious, but I couldn't find it. That said, for timeouts I was seeing, I put in a fix which I think will also fix the issue you're reporting (though, I can't be sure; one way to test for this is to see if setting Persistent KeepAlive fixes the DNS-related timeouts, if it hasn't been set already). We've also disabled connection pooling for WireGuard DNS queries (just to be sure that it isn't behaving funny with some configurations).
the DNS server logs show the request coming from my external IP address, and Rethink's DNS tab shows the external DNS domain used, which aligns with the previous observation of fallback DNS kicking in.
This shouldn't happen if you Lockdown WireGuard (if in Advanced mode and Split DNS is turned ON and Rethink is able to get owner app from Android for a given DNS query) or run it in Simple mode. Otherwise, this is a leak (I must note that we have fixed a similar "leak" issue for v055u wrt mutliple Always-on Advanced mode WireGuards running in parallel).
# Seems like Split DNS is turned OFF 📎 2025-08-30-logcat-rethink-grep-broken.log
08-30 21:58:10.080 19880 19977 D RethinkDnsVpn: (onQuery)no split dns, using Preferred
(the log streams fast so this is | grep -C 100
;
Yeah, we've added just too many logs (think Rethink generates 50 to 100 log lines per DNS query and per UDP "connection"). These were needed given the explosion in complexity (and lack of tests) 🥶
I'll see if I can share a test v055u version today/tomorrow, but no pressure, if you're busy.