Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for DNS-over-HTTPS to systemd-resolved #8639

Open
lucaswerkmeister opened this issue Apr 2, 2018 · 17 comments
Open

Add support for DNS-over-HTTPS to systemd-resolved #8639

lucaswerkmeister opened this issue Apr 2, 2018 · 17 comments
Labels

Comments

@lucaswerkmeister
Copy link
Member

@lucaswerkmeister lucaswerkmeister commented Apr 2, 2018

Submission type

  • Request for enhancement (RFE)

systemd version the issue has been seen with

v238; master (34bfb98)

Used distribution

Arch Linux

Cloudflare’s new 1.1.1.1 DNS service supports both DNS-over-TLS (RFC 7858) and DNS-over-HTTPS (draft) according to their announcement. We already have an issue for supporting DNS-over-TLS (#5671), but I couldn’t find one for DNS-over-HTTPS support.

Google DNS also supports DNS-over-HTTPS (reference), but as far as I can tell it only supports JSON responses, not the DNS wire format used in the current version of the DNS-over-HTTPS draft. Cloudflare DNS supports both, depending on the ct query parameter (not the Accept header).

@ancarda
Copy link

@ancarda ancarda commented Apr 3, 2018

Would it make sense to do #7617 first?

@lucaswerkmeister
Copy link
Member Author

@lucaswerkmeister lucaswerkmeister commented Apr 4, 2018

Sounds reasonable. I think there might also be some opportunity for using 0-RTT TLS here, but I don’t fully understand the implications of that yet.

@ott
Copy link
Contributor

@ott ott commented May 22, 2018

I think 0-RTT TLS and TCP Fast Open are unrelated to DNS over HTTPS. So perhaps it makes sense to open a separate issue for them after #8849 has been merged.

@ott
Copy link
Contributor

@ott ott commented May 22, 2018

@lucaswerkmeister What would be the use case for DNS over HTTPS? It seems to be targeted at applications in constrained environments which permit only HTTP queries and no other network communication. A use case would be a WebRTC client that has to resolve a SRV RR to find a SIP server. Perhaps it is also possible to circumvent DNS censorship.

However, I don't see how DNS over HTTPS is of use in systemd. There will be support for DNS over TLS (#5671) soon. I also guess that DNS over HTTPS can easily be fingerprinted by its traffic pattern, so it's might only work until it is widely deployed. So it seems that DNS over HTTPS is only a more complicated encoding of DNS queries. HTTP does not seem to be of use here. But perhaps I overlooked some advantages.

@ott
Copy link
Contributor

@ott ott commented May 22, 2018

And just to give an example why tunnelling another protocol over HTTPS does not really help against censorship, consider for example the relatively simple ip-https-discover NMAP rule that identifies the Microsoft DirectAccess protocol that tunnels IPv6 over HTTPS. A more sophisticated intrusion detection system could discover the hostname or IP address of the DNS over HTTPS resolver from the TLS handshake or IP header of network traffic or initial DNS queries, probe whether it is a DNS over HTTPS resolver and if so, insert a packet filter rule.

For Google Public DNS it would even suffice to not resolve dns.google.com and for 1.1.1.1 it would suffice to block 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, 2606:4700:4700::1001 and cloudflare-dns.com.

@ott
Copy link
Contributor

@ott ott commented Oct 22, 2018

Sara Dickinson gave an interesting presentation about DNS-over-TLS and DNS-over-HTTPS at RIPE77. Her concerns seem to be more about “political” aspects of DNS-over-HTTPS or the “pragmatics” of the protocol and not about the protocol itself. So I’m not sure whether it adds anything meaningful to the discussion and is relevant. But perhaps it adds some more aspects to it.

Technology always exists in a social context and perhaps it helps in the decision about DNS-over-HTTPS to consider this context. Nonetheless, I don’t want to start a discussion about Google Public DNS, Cloudflare DNS and similar services. In the past they didn’t seem to lead anywhere.

@nl255
Copy link

@nl255 nl255 commented Feb 3, 2020

@ott The use case is being able to use secure/encrypted DNS with DNS servers that support DNS over HTTPS but not DNS over TLS and unfortunately it looks like DNS over HTTPS is going to become the new "de facto" standard which means it is going to be more and more of an uphill battle to convince said services to add support for DNS over TLS as well.

@codewiz
Copy link

@codewiz codewiz commented Feb 25, 2020

DNS-over-HTTP3 (DoH3) solves the head-of-line blocking problem which makes DoT a bad candidate for mobile networks. With adequate session caching, DoH3 also means 1-RTT lookups in most cases, even when the client jumps between networks or resumes from suspend.

Implementing DoH without HTTP/3 seems like a net loss over DoT in terms of latency and bandwidth usage.

@HLFH
Copy link

@HLFH HLFH commented Feb 27, 2020

DNS-over-HTTP3 (DoH3) solves the head-of-line blocking problem which makes DoT a bad candidate for mobile networks. With adequate session caching, DoH3 also means 1-RTT lookups in most cases, even when the client jumps between networks or resumes from suspend.

Implementing DoH without HTTP/3 seems like a net loss over DoT in terms of latency and bandwidth usage.

Isn't DoQ the upgrade of DoT?
Isn't DoH limited on Firefox with the default use of public providers such as Cloudflare & NextDNS?
Isn't DoH flawed on Firefox with the kill-switch for ISPs?
Isn't DoH just bloated compared to DoQ?

It would be completely possible to use the HTTP/QUIC mapping to carry DNS
requests as HTTP queries, as specified in [RFC8484]. We are somewhat
concerned that this mapping carries the overhead of HTTP into the DNS
protocol, resulting in additional complexity and overhead.

I do believe DoQ is better than DoT and DoH3.
https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07

@agrover
Copy link

@agrover agrover commented Feb 27, 2020

I do believe DoQ is better than DoT and DoH3.
https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-07

DoQ and DoH3 support should probably get their own issues. The timeline for them is gated both on their specs being published and QUIC support in systemd. DoH support is not. (I think all of them should eventually be supported btw)

Choosing which one is technically best isn't the main issue. DoH is being used today. I would like to configure my system DNS resolver to use DoH, and systemd-resolved doesn't currently support this option.

@codewiz
Copy link

@codewiz codewiz commented Feb 28, 2020

Isn't DoQ the upgrade of DoT?
There was an actual RFC (i.e. not a draft) detailing DNS-over-DTLS, but I don't think it got any traction: https://tools.ietf.org/html/rfc8094

DNS-over-QUIC is a distinct protocol using a different port (still TBD), with no specified mechanisms to upgrade existing DoT connections or signal its availability to DoT clients (like, for example Alt-svc for HTTP/1.1 -> HTTP/3).

Isn't DoH limited on Firefox with the default use of public providers such as Cloudflare & NextDNS?

DoH is not limited to Firefox. Any client and server can implement it. Pretty much every public DNS operator supports DoH already. DoH3 is not yet widely available, but it will change in 2020 as soon as the HTTP/3 standard is finalized.

Isn't DoH flawed on Firefox with the kill-switch for ISPs?

Sorry, this is pure FUD from ISPs, and it's also confusing the wire protocol with the configuration mechanism used by Firefox.

Isn't DoH just bloated compared to DoQ?

Do you have any numbers to back this claim? What do you mean by bloated? Code size? Number of RTTs per query? Bytes per query?

Also, there are multiple version of the HTTP protocol, we're talking about DNS-over-HTTP3 here.

@zdzichu
Copy link
Contributor

@zdzichu zdzichu commented Feb 28, 2020

Hey, this ticket is not a DoH learning classes. Please refrain from offtopic discussions.

@PAStheLoD
Copy link

@PAStheLoD PAStheLoD commented Feb 29, 2020

@ott , thise is a very strong claim, could you please support them with primary sources?

DNS-over-HTTPS is an additional attempt to find another source of income.

https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_is-mozilla-getting-paid-to-route-dns-requests-to-cloudflare

It seems Mozilla simply tries to do the same it did with LetsEncrypt. Proliferate crypto to other aspects of the Internet. There are many people against EDNS Client Subnet prefix explicitly because of its implications on end user privacy. (There are of course attempts to find a middle ground: https://medium.com/nextdns/how-we-made-dns-both-fast-and-private-with-ecs-4970d70401e5 , plus coupling this with QNAME Minimization might alleviate those concerns.)

I just wanted to show that DNS-over-HTTPS and also DNS-over-TLS are not widely used protocols

Chrome, Google Public DNS, many resolvers (eg PowerDNS, Unbound) implement one or both of them. Furthermore, the protocols are sound and young, and there are many people (Dozens of us! I tell you!) who would like to utilize DoH/DoT and keep using systemd-resolved.

@refi64
Copy link
Contributor

@refi64 refi64 commented Feb 29, 2020

@mjog
Copy link

@mjog mjog commented Feb 29, 2020

@bsmith7581
Copy link

@bsmith7581 bsmith7581 commented Jun 2, 2020

Isn't DoH limited on Firefox with the default use of public providers such as Cloudflare & NextDNS?

Firefox has a custom field in which the user can enter any RFC8484-complient DNS over HTTPS resolver. See attached image.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.