LWN: Comments on "System-wide encrypted DNS" https://lwn.net/Articles/1021357/ This is a special feed containing comments posted to the individual LWN article titled "System-wide encrypted DNS". en-us Mon, 03 Nov 2025 11:00:23 +0000 Mon, 03 Nov 2025 11:00:23 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net CVE magnet https://lwn.net/Articles/1025545/ https://lwn.net/Articles/1025545/ sammythesnake <div class="FormattedComment"> In this context, does your nick stand for "hanging my head"? :-P<br> </div> Mon, 16 Jun 2025 09:31:29 +0000 CVE magnet https://lwn.net/Articles/1023649/ https://lwn.net/Articles/1023649/ Cyberax <div class="FormattedComment"> There were several CVEs in systemd and unbound, caused by the classic C issues with buffer overflows and pointer arithmetic. So I don't trust them to not have more issues like that.<br> </div> Tue, 03 Jun 2025 17:59:00 +0000 Trust? https://lwn.net/Articles/1023612/ https://lwn.net/Articles/1023612/ paulj <div class="FormattedComment"> <span class="QuotedText">&gt; For most people the primary use of DNS is to look up IP addresses corresponding to domain names.</span><br> <p> The way the Internet works today is that - to a high likelyhood - the IP addresses of web sites that you visit belong to CDNs, which host (or at least act as the front-ends for) many many many (potentially millions or even orders of magnitude more) different hostnames. Your ISP knowing you connect to, say, Akamai or Cloudflare, doesn't really leak any significant information about which web site you were visiting.<br> <p> However, Cloudflare, Akamai, Google, etc., obviously still know - at an IP level (ignoring cookies, logged in sessions, etc.). If that bothers you, use Tor (and run your DNS over Tor via, e.g., dnscrypt-proxy). For logged-in sessions, etc., you are choosing to be known.<br> </div> Tue, 03 Jun 2025 13:15:55 +0000 CVE magnet https://lwn.net/Articles/1023599/ https://lwn.net/Articles/1023599/ pspacek <div class="FormattedComment"> Can you expand on 'those'? I don't follow.<br> </div> Tue, 03 Jun 2025 09:13:06 +0000 CVE magnet https://lwn.net/Articles/1023363/ https://lwn.net/Articles/1023363/ hmh <div class="FormattedComment"> DNS Recursive resolvers are *not* something you implement for mass consumption unless you have a DNS expert in the team. In DNS recursive resolver *servers*, protecting the content (queries, answers, and your cache) is paramount. And that ain't easy, at all, especially when you need to be wary of it both upstream and downstream.<br> <p> Implementing the RFCs perfectly would be only half the path to thread...<br> </div> Sun, 01 Jun 2025 16:03:47 +0000 Trust? https://lwn.net/Articles/1023325/ https://lwn.net/Articles/1023325/ Cyberax <div class="FormattedComment"> <span class="QuotedText">&gt; Please actually read the comments you are replying to more carefully. DOH does not keep your ISP from seeing where you connect to. </span><br> <p> It does. It obscures the host name, so mere passive probing is insufficient for reliable detection. The ISP will have to actively probe the target host to find out what it serves, which also fails if it is a multiplexing load balancer.<br> <p> Moreover, traffic monitoring is an order of magnitude more complex and expensive than just passively snooping on DNS requests. That's because traffic is usually handled completely in the dataplane of routers, and diverting it for inspection is expensive. But diverting a handful of DNS packets per minute for a typical host? That's easy.<br> <p> So in practice, DoH/DoT will increase the privacy.<br> </div> Fri, 30 May 2025 21:41:16 +0000 Trust? https://lwn.net/Articles/1023314/ https://lwn.net/Articles/1023314/ brunowolff <div class="FormattedComment"> Please actually read the comments you are replying to more carefully. DOH does not keep your ISP from seeing where you connect to. For most people the primary use of DNS is to look up IP addresses corresponding to domain names. Under that condition your ISP gets essentially the same information as seeing your DNS requests would. Now it might be that you use DNS for a substantial amount of use that does not involve IP addresses you are connecting to and for some reason your trust Cloudflare or Google more than your ISP. In that case DOH might be clearly better for you.<br> </div> Fri, 30 May 2025 18:09:00 +0000 Trust? https://lwn.net/Articles/1023311/ https://lwn.net/Articles/1023311/ Cyberax <div class="FormattedComment"> <span class="QuotedText">&gt; I said it decreases your privacy, because now your ISP and Cloudflare or Google get to see all of the destinations of your IP traffic</span><br> <p> Nope. With DoH my ISP or anybody on the network path will NOT see the queries. Only Google or Cloudflare will see them.<br> <p> And even that is reduced via oblivious DNS: <a href="https://blog.cloudflare.com/oblivious-dns/">https://blog.cloudflare.com/oblivious-dns/</a><br> </div> Fri, 30 May 2025 17:40:46 +0000 CVE magnet https://lwn.net/Articles/1023309/ https://lwn.net/Articles/1023309/ Cyberax <div class="FormattedComment"> Well, yes. I meant those. systemd-resolved also had a bunch of vulnerabilities around that time.<br> </div> Fri, 30 May 2025 17:37:27 +0000 Trust? https://lwn.net/Articles/1023290/ https://lwn.net/Articles/1023290/ brunowolff <div class="FormattedComment"> You didn't understand the original comment. The point was not that DNSSEC was a man in the middle attack. Rather that the protection it provides against a man in the middle attack isn't very helpful, because the threat actors that can mess with DNS have a lot of overlap with the ones that can manipulate where your IP traffic really goes.<br> Nor did I claim that DOH was a man in the middle attack. I said it decreases your privacy, because now your ISP and Cloudflare or Google get to see all of the destinations of your IP traffic. If you almost always visit Cloudflare protected sites or Google services, than that probably doesn't matter to you. Not everyone is going to have that profile. DOH helps if you use sites where traffic for servives that can be distinguished by DNS, but not by destination address a significant amount. Or if you think your ISP is tracking or modifying your DNS queries, but is not tracking or messing with the routing of your traffic. With things like AWS the former could apply to some people. and it is certainly plausible that some ISPs are doing the latter. Then maybe you could get a net increase in privacy buy letting Cloudflare or Google track everything you do in the case where they would mostly get that info anyway.<br> </div> Fri, 30 May 2025 14:22:02 +0000 Trust? https://lwn.net/Articles/1023261/ https://lwn.net/Articles/1023261/ paulj <div class="FormattedComment"> I use dnscrypt-proxy + Tor, to send my DNS via DoH over Tor to a bunch of different public DoH servers. The only problem I have is that it can be hard to get systemd resolvectl to implement the lookup logic I want with regard to also querying local network servers, to allow me to access local services that require asking a local LAN private DNS.<br> <p> I can either go with resolved's default "Ask every available resolver and use first response" policy, or "send everything to dnscrypt-proxy". The former leaks queries; the latter breaks local LAN services. I have, to date, not managed to figure out how to reliably get something better.<br> </div> Fri, 30 May 2025 12:28:11 +0000 Trust? https://lwn.net/Articles/1023171/ https://lwn.net/Articles/1023171/ pbrezina <div class="FormattedComment"> In my opinion, privacy is a brittle word with DNS as one way or another someone will know what hostname are you resolving. As you wrote, it is a matter of trust - do you trust your ISP or Cloudflare? Or is it the company's internal DNS server?<br> <p> Encrypting DNS traffic prevents eavesdropping and guarantees data integrity between the client and DoT server. Its not that much about you, an employee, configuring Cloudflares DNS as a forwarder and thus workaround your company's internal DNS - you probably would not be able to keep working as you would not be able to access many of the company's services. It's about connecting to the company's DNS using DoT so internal hostnames can not be eavesdropped or tampered with, which will be company's policy if they go for zero trust networks. The company's DNS will, of course, be able to log all queries, so I don't think we can speak about privacy at all in this context.<br> </div> Fri, 30 May 2025 11:37:07 +0000 The word "revocation" does not appear once. https://lwn.net/Articles/1023170/ https://lwn.net/Articles/1023170/ pbrezina <div class="FormattedComment"> Do you mean DNS cache or CA certificate revocation?<br> </div> Fri, 30 May 2025 11:03:41 +0000 Trust? https://lwn.net/Articles/1023166/ https://lwn.net/Articles/1023166/ nim-nim <div class="FormattedComment"> You can configure as many forwarders as you want, and spread your DNS traffic over multiple agencies. However forwarder selection is performance-oriented, agencies that skimp on provisioning won’t ever see your traffic.<br> <p> <a href="https://unbound.docs.nlnetlabs.nl/en/latest/reference/history/info-timeout-server-selection.html#normal-operations">https://unbound.docs.nlnetlabs.nl/en/latest/reference/his...</a><br> </div> Fri, 30 May 2025 10:04:45 +0000 Trust? https://lwn.net/Articles/1023160/ https://lwn.net/Articles/1023160/ taladar <div class="FormattedComment"> You can use dnscrypt ( <a href="https://www.dnscrypt.org">https://www.dnscrypt.org</a> ) to allow your own resolver to preserve privacy when resolving names. It works by essentially encrypting the query with the public key of a resolver but proxying the request via another host run by a different organization. That way one knows your IP but not your query and the other knows your query but not the originating IP.<br> </div> Fri, 30 May 2025 08:42:29 +0000 CVE magnet https://lwn.net/Articles/1023155/ https://lwn.net/Articles/1023155/ pspacek <div class="FormattedComment"> Are there data to back up this claim? Judging by <a href="https://www.nlnetlabs.nl/projects/unbound/security-advisories/">https://www.nlnetlabs.nl/projects/unbound/security-adviso...</a> the last memory-safety related issue has been discovered in 2019 ...<br> </div> Fri, 30 May 2025 06:58:52 +0000 Trust? https://lwn.net/Articles/1023154/ https://lwn.net/Articles/1023154/ pspacek <div class="FormattedComment"> That claim has been proven incorrect. See<br> - <a href="https://irtf.org/anrw/2019/slides-anrw19-final44.pdf">https://irtf.org/anrw/2019/slides-anrw19-final44.pdf</a><br> - <a href="https://dl.acm.org/authorize?N687437">https://dl.acm.org/authorize?N687437</a><br> </div> Fri, 30 May 2025 06:55:04 +0000 Trust? https://lwn.net/Articles/1023147/ https://lwn.net/Articles/1023147/ Cyberax <div class="FormattedComment"> <span class="QuotedText">&gt; Unless you are using a VPN or Tor, your ISP is going to see the IP address you end up communicating with and in many cases this is going to provide the same information as seeing the DNS queries that provided that address.</span><br> <p> Most addresses end up with CloudFlare/AWS/Google IPs right now, and they are often useless without a domain name.<br> <p> <span class="QuotedText">&gt; The groups of people who can man in the middle your DNS queries are similar to those that can man in the middle your IP traffic. So the benefit of DNSSEC is pretty limited.</span><br> <p> ?? DNSSEC is not man-in-the-middleable. Neither is DNS-over-HTTP.<br> </div> Fri, 30 May 2025 01:40:38 +0000 Trust? https://lwn.net/Articles/1023121/ https://lwn.net/Articles/1023121/ brunowolff <div class="FormattedComment"> Unless you are using a VPN or Tor, your ISP is going to see the IP address you end up communicating with and in many cases this is going to provide the same information as seeing the DNS queries that provided that address. So instead of just your ISP (and the local intelligence agency) seeing who you communicate with, google or cloudflare (and the NSA) get to see who you are communicating with.<br> The groups of people who can man in the middle your DNS queries are similar to those that can man in the middle your IP traffic. So the benefit of DNSSEC is pretty limited.<br> If you are using a VPN or Tor, you can do your DNS queries through them and it is then a similar situation to doing the queries when not using a VPN or Tor.<br> </div> Thu, 29 May 2025 21:26:16 +0000 CVE magnet https://lwn.net/Articles/1023102/ https://lwn.net/Articles/1023102/ hmh <div class="FormattedComment"> Ugh, that would be "I don't see... anywhere". Sorry.<br> </div> Thu, 29 May 2025 17:45:53 +0000 CVE magnet https://lwn.net/Articles/1023095/ https://lwn.net/Articles/1023095/ hmh <div class="FormattedComment"> I don't see "we have DNS experts in the team" nowhere. That bothers me a *lot*. DNS is not easy to do correctly, not even on stubs, let alone ISP-grade DNS Recursive Resolvers (which are by far the hardest of them all).<br> </div> Thu, 29 May 2025 17:43:21 +0000 Trust? https://lwn.net/Articles/1023096/ https://lwn.net/Articles/1023096/ Cyberax <div class="FormattedComment"> Regular recursive DNS traffic is not encrypted, even if it's signed. So it's trivially easy to eavesdrop for any party along the network path.<br> <p> 1.1.1.1 supports oblivious DNS, and the traffic to the resolver itself is encrypted. <br> </div> Thu, 29 May 2025 17:00:58 +0000 initramfs? https://lwn.net/Articles/1023012/ https://lwn.net/Articles/1023012/ cortana <div class="FormattedComment"> Among other things it can be used for "network bound disk encryption", i.e., decrypt a LUKS volume with a key recovered by talking to a tang server.<br> </div> Thu, 29 May 2025 13:13:03 +0000 Trust? https://lwn.net/Articles/1022967/ https://lwn.net/Articles/1022967/ kleptog <div class="FormattedComment"> Isn't that backwards? By running your own recursive resolver only you know what you looked up. Whereas by using 1.1.1.1 you've basically decided you want Cloudflare to know what you've looked up.<br> <p> So you have a choice between trusting your ISP who may be under orders from your local government, or trusting Cloudflare who may be under orders from the US government. I don't doubt that the NSA is arms deep in the Cloudflare infrastructure.<br> <p> BTW, encrypting DNS doesn't increase security, it increases privacy. Security is guaranteed by the TLS handshake in the connection to the service you want to talk to. Securing the DNS lookup changes nothing. Yet the article talks only about security but doesn't mention privacy at all...<br> <p> I also expect anyone on a corporate network is going to be asked to turn this off. They have a legitimate reason to be able to see what you're looking up, for the security of the business. In an ideal world I as a user would be able to choose who I trust, but the people here are basically building it so I have to trust the US government, no alternatives.<br> </div> Thu, 29 May 2025 08:51:35 +0000 initramfs? https://lwn.net/Articles/1022939/ https://lwn.net/Articles/1022939/ Cyberax <div class="FormattedComment"> For things like NFS/SMB/iSCSI root volumes?<br> </div> Thu, 29 May 2025 00:28:35 +0000 Trust? https://lwn.net/Articles/1022938/ https://lwn.net/Articles/1022938/ Cyberax <div class="FormattedComment"> I think you basically have to trust 1.1.1.1, 8.8.8.8 or something similar. You can also set up your own recursive resolver that does all the zone chasing to the root zone, but then you lose privacy.<br> </div> Thu, 29 May 2025 00:27:09 +0000 CVE magnet https://lwn.net/Articles/1022934/ https://lwn.net/Articles/1022934/ Cyberax <div class="FormattedComment"> One of my big problems with systemd-resolved (or Unbound) is that they're both written in C. With a bunch of CVEs caused by this attached.<br> <p> There are up-and-coming replacements in Rust, so it might be interesting to evaluate them: <a href="https://github.com/hickory-dns/hickory-dns">https://github.com/hickory-dns/hickory-dns</a><br> </div> Thu, 29 May 2025 00:23:35 +0000 Trust? https://lwn.net/Articles/1022935/ https://lwn.net/Articles/1022935/ pabs <div class="FormattedComment"> Which upstream recursive DNS resolver does this ultimately trust? The diagram mentions only 1.1.1.1.<br> </div> Thu, 29 May 2025 00:18:40 +0000 initramfs? https://lwn.net/Articles/1022933/ https://lwn.net/Articles/1022933/ pabs <div class="FormattedComment"> Why is DNS required in the initramfs?<br> </div> Thu, 29 May 2025 00:16:36 +0000 The word "revocation" does not appear once. https://lwn.net/Articles/1022928/ https://lwn.net/Articles/1022928/ ejr <div class="FormattedComment"> In my somewhat limited experience, orgs want an access revocation (revoked host identity, whatever) to be immediate. That means caches must be invalidated or not allowed in the first place.<br> <p> What in any of this can forcibly limit the decision's deadline? If nothing, then this is a non-starter no matter how well-intended it honestly seems to be.<br> </div> Wed, 28 May 2025 23:40:50 +0000