cloudflare / cloudflared

Cloudflare Tunnel client (formerly Argo Tunnel)
https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/install-and-setup/tunnel-guide
Apache License 2.0
9.19k stars 811 forks source link

DNS over QUIC #637

Open bjornfro opened 2 years ago

bjornfro commented 2 years ago

Any plans for Cloudflare and cloudflared to support DNS over QUIC. I have "a feeling" that would work better than DoH, especially on networks that are not "perfect". Has some packet loss. Given the nature/overhead of TCP.

https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/

abelinkinbio commented 2 years ago

For cloudflared, we recently announced that we support quic as a primary transport protocol. You can learn more about how we built it on our blog and a little more about our motivations as well.

That said, we do not support quic for dns-proxy mode. We'll look into this, but do not have immediate plans to support this. Thanks for raising this FR.

bjornfro commented 2 years ago

Would you agree that it would/should in theory work better, especially on networks with questionable quality?

abelinkinbio commented 2 years ago

Interesting. In theory we do imagine it would be more reliable, but to be fair we haven't explored this concept enough to know for certain. We'll look into this further and keep this thread updated with our findings.

Unknown78 commented 2 years ago

Any updates?

abelinkinbio commented 2 years ago

Thank you for the additional upvote on this FR. Are you currently running cloudflared in dns-proxy mode over DoH as well? We don't have any updates to share at this time. This is not on the immediate roadmap, but we will keep this thread updated if and when that changes.

Unknown78 commented 2 years ago

I was using DNSCrypt's dns-proxy for DoH in my Windows. But then Windows 11 came and able to apply it on a machine-wide.

The new version of DNSCrypt's dns-proxy 2.1.2 support DNS-over-HTTP/3 which is QUIC-based. But the problem is that I could only found two public resolvers that supports it with very high latency, doh-crypto-sx and jp.tiarap.org.

Meanwhile, there's only 1 public resolvers currently with it's own proxy app that support DNS-over-QUIC directly without HTTP/3, that is AdguardTeam's dnsproxy.

Nowadays, I run it. with this command:

dnsproxy.exe -u quic://94.140.14.140 -u quic://94.140.14.141 --all-servers --edns --dns64

It must be direct IP to skip bootstrapping. Load balance with its secondary server is also a bonus.


At least I hope that Cloudflare's public resolvers, 1.1.1.1 and 1.0.0.1, will supports DNS-over-HTTP/3, if not DNS-over-QUIC directly. And I also hope Windows will supports it in the future.

bmeirellesRJ commented 2 years ago

any news?

cherinyy commented 1 year ago

DNS over QUIC (DoQ) is already a proposed standard and I expect it to be supported.

RFC 9250 - DNS over Dedicated QUIC Connections

mattkeenan commented 1 year ago

Bump, I use https://github.com/folbricht/routedns and currently use AdGuard's DoQ servers. It would be nice to see it more widely supported though. And I'm a Cloudflare customer.

ivanjx commented 7 months ago

is dns over http3 also covered here?

thegreatGreenstar commented 3 months ago

is dns over http3 also covered here?

As there has not been a response for a few weeks, to prevent the confusion that DoH/3 is DoQ, I suggest no, DoH/3 support should be its own issue.

ivanjx commented 3 months ago

would it be easier for ISP to detect DoQ traffic and just block it than DoH or DoH3?

thegreatGreenstar commented 3 months ago

would it be easier for ISP to detect DoQ traffic and just block it than DoH or DoH3?

According to section 3.3 of https://datatracker.ietf.org/doc/rfc9250/ “… firewalls and other middleboxes might be able to distinguish DoQ from other protocols that use QUIC, like HTTP, and apply different treatment.

The lack of measures in this specification to avoid protocol classification is not an endorsement of such practices.” So yes DoQ could be blocked with various techniques. Though section 4.4 mentions “… port 443 is used by many services using QUIC and HTTP-3 and is thus less likely to be blocked than other ports. Several mechanisms for stubs to discover recursives offering encrypted transports, including the use of custom ports, are the subject of ongoing work.” Thus simply blocking ports will be unsuccessful without breaking other major functionality, which may be useful due to the unlikelihood of such depending on the ISP. Additionally, fallback to DoT can be supported and should be allowed, which could be useful in cases where DoT is not blocked. (From my understanding DoQ is more similar to DoT than DoH even if it’s DoH/3.)

TL;DR summary: Yes, but it’s unlikely if the service allows encrypted dns at all, while “blending in” could be a use case of DoH/3, it IS slower, and has some security & privacy risks I won’t detail.