A Tunnel which Turns UDP Traffic into Encrypted UDP/FakeTCP/ICMP Traffic by using Raw Socket,helps you Bypass UDP FireWalls(or Unstable UDP Environment)
MIT License
7.16k
stars
1.16k
forks
source link
[feature request] built in DNS over HTTPS resolver for "client-side" use (solves minor roaming issues gracefully) #473
Proposed feature:
Built in DNS-over-HTTPS resolver (or alternatively a facility to query something like DOG but a built-in would be "cleaner")
Will allow straightforward solution to certain "server roaming" behaviors.
Usecase:
server lives on Oracle Cloud and occasionally reboots, getting new IP.
Server side, the box is configured in a way that first updates DNS records on a low-TTL DNS service (Cloudflare can go as low as 60 seconds) with its new IP and then brings up the UDP2RAW server (this part is done by various startup scripts on server and does not require any modification of UDP2RAW of course)
On client side, the proposed feature would enable the following command line switches
-rd
specifies the remote using a domain name rather than IP
used instead of -r
(for example -rd mydomain.com:8080 )
-hns
specifies the DNS-over-HTTPS resolver to use
looks like DOG's DNS-over HTTPS syntax
(for example -hns @https://cloudflare-dns.com/dns-query )
-ct
connection timeout, basically explicitly specify how long to wait for response until server IP is considered "stale" and resolution should be retried, complete with initiation of a fresh connection
important caveat:
every time client detects connection failure client re-runs the HTTPS-over-DNS query and thus updates the server's IP it knows
So when the server goes down and restarts with new IP, you're about to get only relatively small downtime (approximately "time to restart+time to update DNS+TTL of DNS record") and, eventually, as DNS records update, the client WILL find out the new IP of server and re-connect successfully
caveat 2:
the system will only work if the connection to DNS over HTTPS resolver being specified is not blocked
Additional consideration - maybe allow specifying more than one DNS-over-HTTPS resolver, comma separated, if not too much fuss to implement
for example
-hns @https://cloudflare-dns.com/dns-query,@https://mozilla.cloudflare-dns.com/dns-query,@https://dns.quad9.net/dns-query
The DNS resolvers would be tried in order (e.g. if request to cloudflare fails, try mozilla, then try quad, then try cloudflare again)
Such an approach should allow semi-graceful roaming of servers in all but most restrictive environments (NATs on both sides, completely banned DNS over HTTPS etc.) and minimize the information a local observer (ISP, etc.) can learn.
Proposed feature: Built in DNS-over-HTTPS resolver (or alternatively a facility to query something like DOG but a built-in would be "cleaner")
Will allow straightforward solution to certain "server roaming" behaviors.
Usecase: server lives on Oracle Cloud and occasionally reboots, getting new IP.
Server side, the box is configured in a way that first updates DNS records on a low-TTL DNS service (Cloudflare can go as low as 60 seconds) with its new IP and then brings up the UDP2RAW server (this part is done by various startup scripts on server and does not require any modification of UDP2RAW of course)
On client side, the proposed feature would enable the following command line switches
-rd specifies the remote using a domain name rather than IP used instead of -r (for example
-rd mydomain.com:8080)-hns specifies the DNS-over-HTTPS resolver to use looks like DOG's DNS-over HTTPS syntax (for example
-hns @https://cloudflare-dns.com/dns-query)-ct connection timeout, basically explicitly specify how long to wait for response until server IP is considered "stale" and resolution should be retried, complete with initiation of a fresh connection
important caveat: every time client detects connection failure client re-runs the HTTPS-over-DNS query and thus updates the server's IP it knows
So when the server goes down and restarts with new IP, you're about to get only relatively small downtime (approximately "time to restart+time to update DNS+TTL of DNS record") and, eventually, as DNS records update, the client WILL find out the new IP of server and re-connect successfully
caveat 2: the system will only work if the connection to DNS over HTTPS resolver being specified is not blocked
Additional consideration - maybe allow specifying more than one DNS-over-HTTPS resolver, comma separated, if not too much fuss to implement
for example
-hns @https://cloudflare-dns.com/dns-query,@https://mozilla.cloudflare-dns.com/dns-query,@https://dns.quad9.net/dns-queryThe DNS resolvers would be tried in order (e.g. if request to cloudflare fails, try mozilla, then try quad, then try cloudflare again)
Such an approach should allow semi-graceful roaming of servers in all but most restrictive environments (NATs on both sides, completely banned DNS over HTTPS etc.) and minimize the information a local observer (ISP, etc.) can learn.