-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom DoH addresses causes location "leak" #227
Comments
I understand the issue, and will here try to explain some limitations of the Custom DNS feature + propose potential improvements. When using a domain as a host, IVPN app will resolve IPs when Custom DNS settings are saved. In the case of using NextDNS, I guess the iOS device resolves the server with the lowest latency (closest server). We can improve this in a few ways:
Note that when VPN is connected, it is required to reconnect to update custom DNS IPs, so I am against adding any logic that automatically changes VPN tunnel configuration without the user being aware of it (hence the prompt proposal). As a workaround in the current IVPN iOS app, a user can go to Custom DNS settings, then edit Custom DNS domain, then save (the same domain). This will update the VPN tunnel configuration and prompt to reconnect VPN to apply the new configuration. cc: @jordan-ivpn |
@jurajhilje, I am the original reporter of this issue (we exchanged a few emails with @jordan-ivpn).
That's ok and makes sense. My suggestion would be: check the already available |
@andsyodel Thanks for the info. We will try to implement this option soon into a public beta TestFlight build and send it for feedback. I'll update here about our progress. |
@andsyodel Please contact @jordan-ivpn to get access to our TestFlight public beta. We added the "Resolve IP when VPN is connected" option in the Custom DNS settings. Feel free to post feedback here or send directly to Jordan. |
@jurajhilje I already contacted Jordan. I sent a private email with my discoveries. Unfortunately, I had to swich back to the PROD version of the app after my initial tests (do not have much more time to help with QAing) My findings:
I have sent Jordan a private email with Wireguard logs attached and a few details. Hope that helps. |
@andsyodel Thanks for the feedback, we'll check out reported issues and probably push a new TestFlight build. |
Bug report
A customer reported an issue:
"I found this morning what I consider a serious bug that happens when using IVPN + Custom DNS (NextDNS in my case) [DNS-over-HTTPS only, not a standard IP address, like 1.1.1.1].
DESCRIPTION
Using a NextDNS as Custom DNS in IVPN iOS app.
In IVPN, when switching servers from location A to location B, the “Resolved IP” in Settings > Custom DNS for VPN… does NOT update values to the new location, and instead stick with the previous VPN server.
So, If I am currently using Miami as server and switch to Stockholm, dnsleaktest.com, STILL shows DNS servers in Miami, even when I have switched to Stockholm (or any other region)
STEPS TO REPRODUCE
In Settings > Custom DNS for VPN, set a NextDNS DoH server previously set, like dns.nextdns.io/abcdef; check the Resolved IP values. Make sure to Enable the custom DNS.
Being connected to IVPN, perform a test in dnsleaktest.com and make sure the (NextDNS) DNS servers match the VPN server location.
Switch to a server in a different geographic location (Let’s say Canada). Re-test in dnsleaktest.com, and check again the DNS servers:
They are still in the previous location, since the Resolved IP still have the same value (even after switching VPN servers).
EXPECTED BEHAVIOUR
When using a Custom DNS like NextDNS, Resolved IP values should refresh when switching servers; so a test in dnsleaktest.com eill show that DNS servers match the VPN server location.
NOTES
The only way to manually refresh Custom DNS for VPN Resolved IP, is to clear the dns.nextdns.io/abcdef entry, and manually add it again and tap Done button, which will refresh Resolved IP values."
[Removing the DoH address from the IVPN App's settings likely breaks the HTTPS connection that may be responsible for the location persistence.]
Describe your environment
The text was updated successfully, but these errors were encountered: