Request ability to override DNS settings when connected to Orchid Hop about orchid HOT 1 CLOSED

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.)

from orchid.