-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Comments
Would it make sense to do #7617 first? |
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. |
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. |
@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. |
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. |
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. |
@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. |
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?
I do believe DoQ is better than DoT and DoH3. |
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. |
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).
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.
Sorry, this is pure FUD from ISPs, and it's also confusing the wire protocol with the configuration mechanism used by Firefox.
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. |
Hey, this ticket is not a DoH learning classes. Please refrain from offtopic discussions. |
@ott , thise is a very strong claim, could you please support them with primary sources?
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.)
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. |
Minor correction: Mozilla is *not* the only one rolling out DoH. Chrome is
doing the same, with the difference that the browser only uses DoH if your
already-set DNS servers support it. Thus, soon, anyone using Chrome with
Google or Cloudflare or another DoH-friendly DNS will automatically be
using DoH.
Chrome's market share is much, much larger than Firefox's, so I don't think
it would be an exaggeration to say that soon DoH will have far more
widespread usage than DoT.
…On Sat, Feb 29, 2020, 4:32 AM ott ***@***.***> wrote:
@nl255 <https://github.com/nl255> It seems undecided to me. I have
neither seen any DNS-over-TLS or DNS-over-HTTPS resolver in practice. Most
people seem to have also not heard of it and if so, just about Mozilla
Firefox and Cloudflare. So I would say that both technologies seem
irrelevant today.
The only major use of DNS-over-HTTPS seems to be that Mozilla has started
to activate DNS-over-HTTPS in the USA. They offer both Cloudflare and
NextDNS as selectable options. Cloudflare is enabled by default.
According to StatCounter, Mozilla Firefox had a market share of 4.37 % in
total and 8.92 % on desktop computers in the USA in January 2020. So it's
difficult to argue that DNS-over-HTTPS is widely used even after Mozilla
forced it upon their users.
If you allow me to speculate, I would say this: Mozilla has financial
problems. Some of their search engine preselection deals ended or were
renewed with less income. They are desperately looking for new sources of
income. You can see this in their acquisition of Pocket and putting
advertisement in Mozilla Firefox and also their plans to offer a VPN
service. DNS-over-HTTPS is an additional attempt to find another source of
income.
Mozilla claims that Cloudflare does not create user profiles from the
requests. Even if this is true and Mozilla does not lie, Cloudflare could
aggregate and analyze the data and sell their analysis results or just use
it to optimize their CDN. Moreover, it ensures that websites of Cloudflare
customers load faster because their can be directly answered by Cloudflare
and always find the optimal CDN node from Cloudflare. Thus websites served
through Cloudflare might load faster in Mozilla Firefox than with other
CDNs. That might be a reason to select Cloudflare as a CDN and might
increase Cloudflare's market share.
Internet service providers are heavily regulated in some parts of the
world. For example, if an ISP in the European Union would do something
similar, they might get fined for violating the GDPR, be sued by
competitors or investigated by authorities. Cloudflare and Mozilla think
they might get away with it in the USA because some regulation does not
apply to them and data protection laws are weak in practice in the USA.
I would even argue that Mozilla's users are not their customers. They
might become customers if they use Mozilla Private Network or Pocket
Premium but Mozilla made most of their income with search engine
preselection and is trying to find additional sources of income for users
who don't use their paid services. I conclude from it that Mozilla's users
are not their customers and that they are in fact selling their users to
their real customers. And what else would you expect of a company with more
than USD 450 million revenue and more than 1000 employees that gives their
products away for free?
Mozilla might argue that DNS-over-HTTPS is something positive for their
users, that their users want it or that they are even protecting their
users' privacy. They might use corporate jargon language like “improves
user experience”, “users are asking for it” and the like. However, in the
end it is much more complicated to say whether Cloudflare and
DNS-over-HTTPS are to the benefit of users: if they don't live in a
surveillance state and dictatorship to which the USA seems like the “land
of the free” or their ISP is to incompetent to operate DNS resolvers or
already sells their data, it is probably of benefit but rather a threat.
When Mozilla added advertisements to Mozilla Firefox, they stated:
This snippet was an experiment to provide more value to Firefox users
through offers provided by a partner. It was not a paid placement or
advertisement. We are continually looking for more ways to say thanks for
using Firefox.
In addition to adding value to Firefox users these efforts are intended to
support an open ecosystem. When users see such offers no data is being
shared with a partner until users have made the choice to enter a
relationship. We hope that this strategy sets a positive example.
Just to give an example of the euphemistic and intentionally misleading
language that they use. For example, they call advertisement “snippets”,
claim that they add advertisement (which almost everyone dislikes) to “say
thanks for using Firefox” and to “[add] value to Firefox” or call a
commercial contract a “relationship”. So they deliberate lie to and try to
mislead their users with language that has some similarities to Newspeak.
They could have easily said something like this without compromising their
beliefs or changing their business:
Yes, it is true that we are trying advertisements in Mozilla Firefox. We
need to finance the development of Mozilla Firefox. We tried to finance it
with donations but it would by far not cover the costs. Therefore, we
decided to include advertisement in Mozilla Firefox that does not
compromise the users' privacy and is not personalized.
We have to find a way to continue the development of Mozilla Firefox.
Therefore, we had to choose the lesser evil. Otherwise, we would be
completely dependent on funding from major search engines who are an even
bigger threat to the users' privacy and the free and open Internet.
We know that advertisements are annoying and we are aware that the online
advertisement industry does not respect the users' privacy. However, we
think that we have found some compromise between our financial needs and
the users' privacy. We hope that we can be a positive example and that we
are able to show to this industry that online tracking and similar
intrusion of privacy are not necessary to make profits with online
advertisement.
Instead they lie and try to mislead and to deceive.
I apologize for this longer digression. I don't want to start a discussion
about Mozilla, Cloudflare or other aspects of DNS-over-HTTPS that are not
related to systemd-resolved here. I just wanted to show that DNS-over-HTTPS
and also DNS-over-TLS are not widely used protocols and that it's not a
natural law that DNS-over-HTTPS will replace (unencrypted) DNS. So I would
not join in to marketing and propaganda that tries to present
DNS-over-HTTPS as an unavoidable and necessary replacement for unencrypted
DNS and DNS-over-TLS. This claim is easily contradicted. Many people want
to convince you that their technology is “the next big thing”, that it will
deprecate everything and take over the market easily but often this is not
the case.
The situation might change if iOS and Android or Microsoft Windows use
DNS-over-HTTPS and there are many DNS-over-HTTP resolvers and unencrypted
DNS resolvers are widely turned off but this is not the case today. But
similarly DNS-over-TLS might become more popular when Let's Encrypt offers
certificates for IPv4 and IPv6 addresses and major DNS resolvers support
DNS-over-TLS and are integrated with certbot but this is also not the case
today.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8639?email_source=notifications&email_token=AAM4YSNSWN6BUDVKI6HXFYTRFDR2JA5CNFSM4EYOGUZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENLWN7I#issuecomment-592930557>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM4YSNAKHM7UAY7GOSL2HTRFDR2JANCNFSM4EYOGUZQ>
.
|
Can you all *please* take this argument elsewhere?
Thanks.
…On 1 March 2020 06:42:13 ott ***@***.***> wrote:
@ott No, I can't. You are right. The statement does not mention that they
will not receive money in the future and does not cover NextDNS or other
DNS providers though. However, that is of course speculation. Perhaps
Mozilla has only good intentions.
And just as a remark, DNS-over-TLS is already supported by systemd-resolved.
It should also be added that encryption of DNS does only provide limited
privacy as the DNS resolver still learns all DNS queries and might send
them unencrypted to authoritative DNS servers. Moreover, most DNS queries
are for IP addresses. An attacker that can monitor DNS queries can likely
also monitor all network traffic. There is also often a 1:1 correspondence
between IP addresses and DNS names, in fact, almost always with IPv6. So
DNS queries can be relatively easily inferred from subsequent network
traffic, albeit with some uncertainty and not in all use cases of the DNS.
So unless you are using a application-protocol level load balancer or
gateway and that is shared with many others (which has also privacy
effects), encrypted DNS does likely not improve privacy. The same is true
for ESNI.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Windows 10 Insider has added support for DNS over HTTPS: https://techcommunity.microsoft.com/t5/networking-blog/windows-insiders-can-now-test-dns-over-https/ba-p/1381282 |
Setting all the offtopic discussion aside, is there any decision on implementing this yet? |
Sorry for the bump, any updates regarding this issue? |
Off-topic. This topic is about DoH, not DoQ. |
Wow you right, sorry for the noise. |
I imagine like most feature requests, "patches welcome" :) |
I wonder if they are. Maybe @yuwata is interested in commenting on DNS-over-HTTPS inclusion. |
I think this is a good opportunity to implement, after all, HTTP/3 has also ushered in the official version. |
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. |
Still waiting... I need DoH in systemd because: DoT? No, thank you. |
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. |
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 |
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. |
Its mind boggling onto why there is no confirmation or denial if it will be implemented. |
Everyone needs DoH (which is better than DoT) support nowadays. Until implemented in |
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
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 |
|
What is the status of this. |
any updates? |
Look guys, #31537 exists. You can go and contribute your patches there, or help out in a more constructive manner. Just commenting "when is this gonna be ready" just spams people inboxes and doesn't help. See #31537 (comment) and write some code. |
Submission type
systemd version the issue has been seen with
Used distribution
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 theAccept
header).The text was updated successfully, but these errors were encountered: