saurik
commented
4 years ago Thank you for the use case. FWIW, there is some pending massive refactoring already planned for how DNS works within Orchid and allowing the user to control the end resulting behavior of the resolver is likely to be part of this (though at a low level)... but, note that it isn't exactly a per-hop problem (note that we are also explicitly rejecting any attempt at remote DNS configuration by OpenVPN servers), and it also interacts with plans we have regarding capturing DNS requests for protocol conversion (which has an interesting maybe-temporary limitation that, right now, we don't happen to have a legacy DNS client in the codebase, only a simple stand-in resolver that uses the JSON variant of DNS-over-HTTPS, so we currently can't translate requests into "normal" unencrypted DNS; that will possibly get fixed, though maybe it won't as maybe we determine the premise there to be flawed).
That said, I do have a pretty big concern about the premise: if you do this DNS server override, it makes it very clear to any final hop "this is @frostygoth" (whether because you one of the only users of this server globally, or simply one of the only users of this server who have bothered to set it as an Orchid override). This actual use case--block DNS requests based on some set of filter rules--to me is thereby not correctly solved by using a public (particularly if unencrypted) proxy resolver that you are then still hoping to access through some kind of anonymous circuit (even if you first were to do some routing to try to push DNS requests through a separate circuit, now that circuit's lack of flow encryption would undermine everything); when we finish the firewall features of the application, my hope is that you will prefer to instead load your DNS block list into the Orchid client to filter without external requests.
(I am thereby going to close this issue, as I think the specific request--DNS override to support a custom public proxy resolvers--is a "won't fix" even though the use case--support filtering DNS so I can block traffic I don't want based on hostnames--is something we have on our roadmap. If the specific request does get supported, it would be more of a low-level feature that happens by accident due to other changes, and not because of an attempt to solve your current frustration. That all said, if you believe that there is a good reason why this should be supported, I would be very interested in hearing the argument, and encourage you to follow up on this issue with a more detailed explanation for why a public proxy resolver might be required for your use case and if we can drop some assumptions I'm making: maybe you are willing to run encrypted DNS, making the DNS-specific routing circuit solution viable.)
Feature Request
Is your feature request related to a problem? Please describe.
It's an inconvenience more than a problem. I run a publicly accessible pihole DNS server with the sole purpose of rejecting DNS requests to urls that lead to advertisements. This keeps me from experiencing ads on my phone. It works great when I don't use the VPN, but when I'm connected to the orchid VPN (I only use orchid hops) my DNS requests start going to 1.0.0.1. This allows adds to start showing up, which really is just an inconvenience.
Describe the solution you'd like I think the best solution would be to create a field in the application where I can statically set my DNS servers to use for the VPN connection. Maybe you could put it below the "Default Curator" field in the settings menu. It would only need to take four decimal numbers between 0 and 255, so I think that input validation would be fairly simple.
Describe alternatives you've considered Alternatives would be that I just have to deal with it.
Additional context I can't really think of anything else, but if you have a question or need more information then just let me know.