Thank you for your detailed feedback. I completely understand the concerns about using an experimental solution in a production environment for customers, and I respect your decision.
However, I would like to clarify one point: is your rejection specifically about MasterDnsVPN as a project, or about DNS tunneling as a technology in general?
The reason I ask is this:
While DNS tunneling is indeed complex and has limitations, none of the protocols you currently have implemented are able to work under whitelist-based filtering - which, in some cases, is applied for entire days (I'm referring specifically to the implemented protocols; you may have had success with others in internal testing, but at this moment, I unfortunately cannot use the VPN/proxy I've paid for).
DNS tunneling, on the other hand, can actually use the censors' own DNS infrastructure against them — since DNS queries must be resolved for the filtering system to work, the tunnel can ride on those very same requests to reach the outside world.
It's unfortunate that, beyond your VPN, I will need to set up my own hosting with DNS tunneling (or even VK calls) to achieve the same goal — and pay for both services, one of which is unfortunately not working for me right now.
I'm not insisting on MasterDnsVPN specifically - I'm advocating for the DNS tunneling approach itself. The project supports stronger encryption like AES and ChaCha20, but that's beside the point. The real benefit is that DNS tunneling can work where other protocols cannot, and I wanted to express my disagreement with the statement that it "doesn’t offer enough benefit compared to the protocols we already provide" - because right now, none of them are working for me.
That said, I fully understand your decision to keep this internal for now. I would appreciate it if you could confirm whether the rejection applies to DNS tunneling in general or just this implementation, so I know whether to look for alternatives outside your service or wait for future development.
Best regards
1 Comment
We rejected this in general. This method "might" work, but with very big caveat. It's one thing to deploy this for yourself and couple of people and totally different story if you deploy this for thousands for mass use.
Providers will likely notice the abnormal load on their DNS infrastructure and apply rate limiting.
There will be no solution to bypass whitelists for mass. You have to self-host and adapt to the changes to bypass whitelists. The only reliable way to bypass is too keep it low and under radar. Anything that draws too much attention will be detected and blocked quickly.