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 · 33 comments · May be fixed by #31537
Open

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

lucaswerkmeister opened this issue Apr 2, 2018 · 33 comments · May be fixed by #31537
Labels
downstream/rhel Tracking bugs for RHEL resolve RFE 🎁 Request for Enhancement, i.e. a feature request

Comments

@lucaswerkmeister
Copy link
Member

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

@yuwata yuwata added RFE 🎁 Request for Enhancement, i.e. a feature request resolve labels Apr 2, 2018
@ancarda
Copy link

ancarda commented Apr 3, 2018

Would it make sense to do #7617 first?

@lucaswerkmeister
Copy link
Member Author

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 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 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 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 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 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 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 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 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 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 commented Feb 28, 2020

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

@PAStheLoD
Copy link

@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 commented Feb 29, 2020 via email

@mjog
Copy link

mjog commented Feb 29, 2020 via email

@bsmith75
Copy link

bsmith75 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

@triatic
Copy link

triatic commented Jun 12, 2020

@deathtrip
Copy link

Setting all the offtopic discussion aside, is there any decision on implementing this yet?

@Hazmi35
Copy link

Hazmi35 commented May 7, 2022

Sorry for the bump, any updates regarding this issue?

@triatic
Copy link

triatic commented Jun 17, 2022

Any plan/roadmap to support DoQ? I am looking forward to use my AdGuardHome server via DoQ, mainly to compare with DoT.

Off-topic. This topic is about DoH, not DoQ.

@benoitjpnet
Copy link

Wow you right, sorry for the noise.

@yrro
Copy link
Contributor

yrro commented Jun 17, 2022

Sorry for the bump, any updates regarding this issue?

I imagine like most feature requests, "patches welcome" :)

@triatic
Copy link

triatic commented Jun 17, 2022

I imagine like most feature requests, "patches welcome" :)

I wonder if they are. Maybe @yuwata is interested in commenting on DNS-over-HTTPS inclusion.

@daiaji
Copy link

daiaji commented Jul 13, 2022

I think this is a good opportunity to implement, after all, HTTP/3 has also ushered in the official version.

@danielzgtg
Copy link

danielzgtg commented Oct 28, 2022

I need DoH even if systemd adds DoQ. QUIC simply does not work in most large organizations.

I am on university eduroam. I tested on Android and DoT is blocked. DoQ is probably also blocked because HTTP/3 websites load in HTTP/2. This is because of our port-blocking policy, but we do not have a website-blocking policy. DoH is however NOT blocked because the Cloudflare 1.1.1.1 app works. It shows DoH in the information inside. Furthermore it would be nice to automatically switch between DoQ and DoH because QUIC is not blocked on my home internet.

I would like this in systemd, not each browser nor the Cloudflare app. It is unmaintainable to set this across each browser and possibly command line tools like cURL. Some poorly-written programs might even just ignore the settings. I also do not want to install the 1.1.1.1 Linux app because it is not as sandboxed compared to Android.

@ghost
Copy link

ghost commented Dec 17, 2022

Still waiting...

I need DoH in systemd because:
DoH on MikroTik is unstable.
The dnscrypt-resolver I used was removed from dnscrypt-proxy2.

DoT? No, thank you.

@dtardon dtardon added the downstream/rhel Tracking bugs for RHEL label Jan 25, 2023
@20NE
Copy link

20NE commented Jun 27, 2023

I need DoH in systemd too

@pointydev
Copy link

If i'm not mistaken, DoH support in resolved would also allow for Encrypted Client Hello (ECH) to be used in major browsers without the need for "Secure DNS" in Chromium or equivalents.

@tmccombs
Copy link

tmccombs commented Jul 18, 2023

In Firefox, I think the current ECH implementation is only active if forefox itself is using DoH. See https://bugzilla.mozilla.org/show_bug.cgi?id=1500289

@Surendrajat
Copy link

DoH is useful to me as I want the DNS traffic to be mixed with the rest of the HTTP traffic and DoT is sometimes blocked. It has been a pain to always setup a DNS proxy to get DoH support on Linux for a few years now. I wonder what's the hold up now that all major browsers and systems support this protocol.

@ku4eto
Copy link

ku4eto commented Sep 27, 2023

Its mind boggling onto why there is no confirmation or denial if it will be implemented.
Just say "yes" or "no". Its an important feature, that has already gained enough track, to be considered to be implemented in systemd as well.

@GreyXor
Copy link

GreyXor commented Oct 7, 2023

Everyone needs DoH (which is better than DoT) support nowadays. Until implemented in systemd-resolved, i'm using https://github.com/m13253/dns-over-https

@Artoria2e5
Copy link

Artoria2e5 commented Feb 5, 2024

#8639 (comment) 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.

Not disagreeing with the overall message (and we do have a DoQ issue now), but I want to note that... DoH3 is unlikely to ever get a standalone specification, because DoH spec (RFC 8484) is written in a way that's mostly independent of the HTTP version. It only specifies a recommended minimum of HTTP/2; HTTP/3 would be already covered by it, even though it involves pretty big changes going from TCP to UDP. RFC 9250 section "Introduction" also notes

DNS over HTTPS (DoH) [RFC8484] can be used with HTTP/3 to get some of the benefits of QUIC.


AAAnyways. I see that systemd already uses curl via systemd-importd, so it's probably reasonable to get DoH out first using the same bunch of curl-utils functions. Someone has to think about the configuration syntax too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
downstream/rhel Tracking bugs for RHEL resolve RFE 🎁 Request for Enhancement, i.e. a feature request
Development

Successfully merging a pull request may close this issue.