LWN: Comments on "DNS over HTTPS in Firefox" https://lwn.net/Articles/756262/ This is a special feed containing comments posted to the individual LWN article titled "DNS over HTTPS in Firefox". en-us Fri, 10 Oct 2025 22:32:20 +0000 Fri, 10 Oct 2025 22:32:20 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net DNS over HTTPS in Firefox https://lwn.net/Articles/762467/ https://lwn.net/Articles/762467/ JanC_ <div class="FormattedComment"> Cloudflare has a large presence in the EU though, so they would be required to follow European privacy laws just like your employer &amp; ISP.<br> </div> Mon, 13 Aug 2018 13:51:55 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/758343/ https://lwn.net/Articles/758343/ flussence <div class="FormattedComment"> <font class="QuotedText">&gt;I trust Mozilla not to put backdoor in Firefox.</font><br> Have they apologised yet for their use of a pre-existing backdoor to push Comcast ads in-browser to several million users last November? The closest I've seen to them even acknowledging that they got caught is a pageful of sneering corporate spin-doctoring congratulating themselves on the “shared user experience”.<br> </div> Tue, 26 Jun 2018 20:10:53 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/757889/ https://lwn.net/Articles/757889/ mstone_ <div class="FormattedComment"> I don't think you grasp just how really, really, really terrible many ISP DNS implementations are.<br> <p> My ISP is one of the largest in the US, and the latency to the nameservers they put in the DHCP replies is worse than the latency to 8.8.8.8... They also hijack NXDOMAIN, and they don't play particularly nicely with DNSSEC (would probably break the revenue stream from NXDOMAIN hijacking.)<br> </div> Wed, 20 Jun 2018 18:37:00 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/757888/ https://lwn.net/Articles/757888/ mstone_ <div class="FormattedComment"> wait, you get ISP choice?<br> </div> Wed, 20 Jun 2018 18:20:13 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/757692/ https://lwn.net/Articles/757692/ nilsmeyer <div class="FormattedComment"> I remember when it still was Kabel Deutschland they were highjacking NXDOMAIN, instead displaying a search engine with lots of advertising. <br> </div> Sun, 17 Jun 2018 16:52:01 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/757561/ https://lwn.net/Articles/757561/ flussence <div class="FormattedComment"> I'll believe that when Mozilla starts actively promoting DNSSEC over crooked CAs and unnecessarily terrorising users to pressure hosts into supporting that system. Until then the words are as hollow as the security model.<br> </div> Fri, 15 Jun 2018 01:56:57 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/757016/ https://lwn.net/Articles/757016/ Cyberax <div class="FormattedComment"> I spent an inordinate amount of time trying to make sure that an UDP-only DNS server can work in the current Internet, with IPv6. Purely out of engineering sense - DNS should be stateless and connectionless.<br> <p> Well, it failed miserably. With DNSSEC you are routinely looking at replies that are greater than 1500 bytes long. IPv4 fragmentation usually saves the day (though it's slowly getting more and more broken) but with IPv6 it's a complete non-starter.<br> <p> There are two ways to fix it:<br> 1) Make DNS great^W small again. ECC instead of RSA basically fixes it for _most_ cases, but not all.<br> <p> 2) Just forget about all this stateless nonsense and go full-metal-stateful. This way you can utilize all the advances made by browsers, in particular QUIC and TLS 1.3. They allow zero-RTT connection initiation, at the cost of stored data.<br> </div> Sat, 09 Jun 2018 04:57:21 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/757004/ https://lwn.net/Articles/757004/ excors <div class="FormattedComment"> <font class="QuotedText">&gt; Why not DTLS? Why HTTP?</font><br> <p> <a href="https://bitsup.blogspot.com/2018/05/the-benefits-of-https-for-dns.html">https://bitsup.blogspot.com/2018/05/the-benefits-of-https...</a> seems to answer that.<br> </div> Fri, 08 Jun 2018 23:57:29 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756999/ https://lwn.net/Articles/756999/ fratti <div class="FormattedComment"> Hi,<br> <p> a lot of these arguments appear to try pushing DoH claiming the inferiority of real-world deployments of UDP DNS protocols, not actual inferiority of the protocol itself. I don't think this is fair, of course if you say "Yes, we at Cloudflare and Mozilla are going to deploy this better," it'll be a better deployment in the real world. That, however, does not make DoH a good idea, because you didn't fix the existing stacks, you made an overengineered new stack that is not more performant on the protocol level, but just on the implementation level. If you're going to take over both the protocol and the implementation, why not do it properly in both areas? Why not DTLS? Why HTTP?<br> </div> Fri, 08 Jun 2018 23:09:34 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756987/ https://lwn.net/Articles/756987/ mcmanus <div class="FormattedComment"> Hi - these are interesting thoughts that we have considered. They will need more attention as we get more experienced doing DNS with an authenticated endpoint.<br> <p> In the soft fail (expected) mode, the resolver never waits for the DoH connection to be ready - if the http2 session isn't up, then it uses the os resolver. Hard fail mode will block if that's what you want but that won't be the default config. Honestly, the connection is pretty much there unless you haven't been browsing at all lately - the browser looks up a surprising number of names. (nothing about this project changes that)<br> <p> the cache is interesting. Firefox has a cache of its own - meant to cover the lack of an OS cache. The cloud cache might be farther away than an ISP cache (but sometimes not), but its probably actually better populated than most ISPs but not all. It will be interesting.<br> <p> Lots of ISPs just forward silently to quad 8 anyhow as they sit in the middle. (note they don't assign the end user e2e quad 8 - wonder why that is.) Especially in asia.<br> <p> and tcp absolutely can outperform 1 packet per message in udp some of the time because DNS senders have absolutely terrible strategies for loss recovery and congestion control and tcp has been working on those problems for a long time. Indeed I've seen DNS stacks that actually induce their own losses (and then crudely repair them with 1second timers) through too much parallelism.. so there are some definite non obvious tradeoffs here.<br> </div> Fri, 08 Jun 2018 20:27:27 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756971/ https://lwn.net/Articles/756971/ mcmanus <div class="FormattedComment"> The Firefox DoH implementation has a soft fallback mode that is meant to deal with most instances of split horizon dns, 1918, and captive portals. Developers who already rely on a specific resolver to redirect between a couple different responsive addresses (like using /etc/hots to test a particular vip) would need to disable doh to use the os resolver. This should pretty much only be an issue when each address is 'working' at the http level (and 1918's are always screened out). Its possible we wold make that part of dev-tools in the same way that the cache is often bypassed easily in dev-tools.<br> <p> <p> </div> Fri, 08 Jun 2018 16:32:41 +0000 DNS but no security ? https://lwn.net/Articles/756812/ https://lwn.net/Articles/756812/ johnjones <div class="FormattedComment"> agreed mozilla should simply give the option to verify the DNS responses given over HTTPS i.e. DNSSEC<br> <p> there are patch's already for DNSSEC over TLS into the NSS<br> <p> <a rel="nofollow" href="https://hg.mozilla.org/users/dkeeler_mozilla.com/dnssec-tls/file/tip/nss-dnssec-tls.patch">https://hg.mozilla.org/users/dkeeler_mozilla.com/dnssec-t...</a><br> <p> anyone want to rework it and get it into the experimental ?<br> </div> Thu, 07 Jun 2018 02:25:53 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756768/ https://lwn.net/Articles/756768/ jwilk <div class="FormattedComment"> By choosing to use your ISP, you have already chosen to trust the ISP to respect your privacy rights, which implies trusting their agreements with any third parties they choose to share your data with... Oh wait, that's not right.<br> <p> Trust is not binary.<br> <p> I trust Mozilla not to put backdoor in Firefox. I don't trust them at all to care about my privacy. In fact, I'm pretty sure they don't. (Hilariously, when you run Firefox for the first time, it phones home in order to show you the privacy policy.)<br> <p> Similarly, I trust my ISP not to inject malicious code into my Internet traffic. I don't trust them that they don't snoop on me. I would be surprised if they didn't.<br> <p> </div> Wed, 06 Jun 2018 17:10:18 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756767/ https://lwn.net/Articles/756767/ jezuch <div class="FormattedComment"> Look, the OSI model is evolving. It's just grown an 8th layer :) We can have fun speculating which will be the 9th - Facebook API's? I can imagine just fine a future where everything other than fb is suspicious and blocked by middleware by default ;)<br> </div> Wed, 06 Jun 2018 16:48:18 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756765/ https://lwn.net/Articles/756765/ excors <div class="FormattedComment"> <font class="QuotedText">&gt; How is this any better than using my ISPs DNS?</font><br> <p> I think the difference is that, by choosing to use Firefox, you have already chosen to trust Mozilla to respect your privacy rights, which implies trusting their agreements with any third parties they choose to share your data with. (You can evaluate that trust based on their privacy policy, and the privacy policy they got Cloudflare to agree to, and their past record in following such policies, and comments from developers about their intentions, etc, and decide whether that trust is justified or not.)<br> <p> Meanwhile you might or might not trust your ISP - that's an independent decision. (Some ISPs have a history suggesting they shouldn't be trusted as anything more than a dumb pipe, sometimes from malice and sometimes incompetence). If you trust both Mozilla and your ISP, then DoH provides no privacy benefit (well, except from anyone passively monitoring your network traffic, which is a significant benefit) but also no privacy harm. If you trust Mozilla but not your ISP, then it does provide an obvious benefit. If you don't trust Mozilla, you shouldn't be using Firefox anyway because there's a million other ways they could harm you.<br> </div> Wed, 06 Jun 2018 15:54:12 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756764/ https://lwn.net/Articles/756764/ buchanmilne <div class="FormattedComment"> <font class="QuotedText">&gt; DNS performance is often surprisingly slow - "the 75th percentile for lookups is 181 milliseconds".</font><br> <p> This is hardly surprising; however for a long time the p0 for ICMP echo request to Cloudflare in my country was 170ms where the p50 for DNS requests to my ISPs caching DNS was &lt; 20ms.<br> <p> And most users are unlikely to worry about a p75 DNS resolution time of 181ms, if the quality of the p50 answers is 10x better (uses a CDN 5ms away rather than 50ms away, or 20ms away rather than 200ms away).<br> </div> Wed, 06 Jun 2018 15:40:12 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756762/ https://lwn.net/Articles/756762/ buchanmilne <div class="FormattedComment"> <font class="QuotedText">&gt; I'm sure at least one person in the world finds "Bing" to be absolutely the best search engine, and is annoyed every time something defaults to Google.</font><br> <p> There is another browser that often re-sets such defaults, e.g. from Google to Bing.<br> <p> I refuse to use that browser (for anything other than downloading a better browser).<br> <p> There is also an OS that keeps trying to change your default browser to use that browser.<br> <p> I refuse to use that OS.<br> <p> I hope I don't need to add Firefox to the list ...<br> </div> Wed, 06 Jun 2018 15:25:48 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756743/ https://lwn.net/Articles/756743/ buchanmilne <div class="FormattedComment"> <font class="QuotedText">&gt; That's only the case if the BGP feed to the ISP's CDN providers differs from the BGP offered to globally-visible neighbors. In which case the solution is to provide CloudFlare with the same BGP feed as provided to the ISP's other CDNs providers.</font><br> <p> Which requires you to deploy CloudFlare everywhere you have any CDN.<br> <p> Not going to happen.<br> <p> In a real ISP I used to be involved with:<br> * The country has 3 major public peering locations.<br> ** Cloudflare has presence at 2<br> ** Major CDNs have presence at 3<br> ** Smaller CDNs have presence at 1 or 2<br> * The ISP had 3 DCs, not co-located with the peering locations<br> ** The ISP had 1 major CDN at 3 DCs, this CDN was actually only present at the largest peering location<br> ** The ISP had 2 major CDNs in 2 DCs that were not at any local peering locations, and didn't want to be advertised to this ISP's peers<br> ** The ISP had 1 major CDN in 2 DCs that were present at local peering locations, and were ok being advertised to this ISP's peers, but wanted to avoid sending any of this ISPs customers to the deployment at the peering location (as it was resource constrained).<br> <p> It was not technically challenging to adjust the route filters appropriately to advertise the client subnets correctly to allow for this, and customers using the ISPs DNS would transparently get the best experience with the least exposure of their DNS requests. It would be technically challenging to get this setup to work with or without Cloudflare in the ISPs DCs.<br> <p> There is no real privacy improvement available here, because Mozilla's picture doesn't quite hold true. Due to the peering configuration, most DNS requrests to the large CDNs would not traverse the public internet, but would be routed across private peering connections (between the ISP and a root DNS operator, then between the ISP and it's CDN partner).<br> <p> With DNS over HTTPS, now these requests may traverse the open internet, and be exposed to a 3rd-party (Cloudflare).<br> <p> IMHO, for some use cases (e.g. public WiFi), this may be an improvement, but for either fixed-line or mobile-operator (e.g. 3G/LTE) internet access, this is a regression in terms of privacy (at least in my country).<br> <p> In short, this move does make me wonder if Cloudflare recently made some large donation to Mozilla ... which makes me suspicious of both parties.<br> </div> Wed, 06 Jun 2018 15:18:10 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756742/ https://lwn.net/Articles/756742/ buchanmilne <div class="FormattedComment"> <font class="QuotedText">&gt; That might explain the disconcerting ARP traffic (who-has w.x.y.z, tell 1dot1dot1dot1.cloudflare-dns.com) that now appears on my LAN.</font><br> <p> Use tcpdump -nn, to avoid being fooled by the change in reverse DNS for 1.1.1.1.<br> <p> Or, set your DNS servers up to be claim authority for 1.1.1.in-addr.arpa if you are going to steal someone else's public address space on your private LAN ...<br> <p> <font class="QuotedText">&gt; I suspect that 1.1.1.1--and probably all of 1.1.1/24 and 1.0.0/24--should now be included in the list of 'never route' addresses, because what's on my private LAN is no one else's business.</font><br> <p> Your private LAN has no business being on 1.1.1/24, or any subnet of 1/8.<br> </div> Wed, 06 Jun 2018 15:00:19 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756741/ https://lwn.net/Articles/756741/ buchanmilne <div class="FormattedComment"> <font class="QuotedText">&gt; Yes, that would be the trade for having privacy, if Firefox chooses to use DoH for the default resolver and sets Cloudflare as the default.</font><br> <p> Well, the question is, privacy from whom.<br> <p> There is still no privacy from Cloudflare in this case.<br> <p> How is this any better than using my ISPs DNS? The contents of my DNS requests are still (theoretically) visible by one entity (the same entity that may also be able to determine by other means the content I am viewing with varying levels of accuracy).<br> <p> O, right, the US is broken and has insufficient competition in the ISP market, where in most other countries this is a solved problem (capitalistic free market!).<br> <p> Thanks, but I will definitely not be enabling this feature, and will drop firefox if they make this a default.<br> <p> In my country, ISPs are well regulated, we have adequate privacy laws, and my ISP:<br> - Is legally obligated to not give this data to any 3rd party without a warrant<br> - Has a much better view of the network topology than any 3rd party<br> <p> For example, many ISPs have many different CDN deployments with different geographic deployments. The ISP I worked for a while ago had CDN deploymens for 4 different CDNs in 3 different data-centres. The biggest (by data volume) was deployed in 3, the next 2 were deployed in 2 DCs, the 4th in 1. And this ignores the off-network open-peering CDNs that are co-located with the CloudFlare POPs in our country.<br> <p> To me it looks suspiciously like Firefox is being paid by Cloudflare to make them more attractive than other CDNs/DDoS prevention companies.<br> </div> Wed, 06 Jun 2018 14:37:19 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756630/ https://lwn.net/Articles/756630/ nilsmeyer <div class="FormattedComment"> Cloudflare may have a lower latency connection to the authorative nameserver (very often they are the authorative nameserver) so in practice the lookup can be a lot faster.<br> </div> Tue, 05 Jun 2018 14:11:44 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756621/ https://lwn.net/Articles/756621/ darwish <div class="FormattedComment"> <font class="QuotedText">&gt; Vodafone (Germany) ... don't deploy IPv6, because when is that ever going to catch on?</font><br> <p> I have a "Vodafone Kabel Deutschland" Internet connection at home, and there is IPv6, completely out of the box, _and enabled by default_.<br> <p> Opening Google and asking "what is my IP" always shows my IPv6 address.<br> </div> Tue, 05 Jun 2018 13:42:01 +0000 MSN https://lwn.net/Articles/756603/ https://lwn.net/Articles/756603/ anselm <p> The story goes that, in Bill Gates's book, <em>The Road Ahead</em>, everywhere the first printing said “Microsoft Network”, the second printing said “the Internet”. </p> Tue, 05 Jun 2018 08:53:46 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756556/ https://lwn.net/Articles/756556/ jmanig <div class="FormattedComment"> OK, I understand your comment a little better now. Thank you for the clarification.<br> </div> Mon, 04 Jun 2018 19:37:10 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756554/ https://lwn.net/Articles/756554/ fratti <div class="FormattedComment"> Ah yes, a choice between Google and Cloudflare, now this truly is decentralisation.<br> </div> Mon, 04 Jun 2018 19:06:37 +0000 MSN https://lwn.net/Articles/756530/ https://lwn.net/Articles/756530/ tialaramex <div class="FormattedComment"> The Microsoft Network wasn't the Internet, quite deliberately. It was a walled garden. It's very important in a walled garden not to show the "customers" trapped inside your garden that there _is_ an outside, because of the grass-is-greener phenomenon. After all, if there's an outside, who is to say there aren't better things out there than in here? And once they start thinking that the jig is very much up. Several walled gardens existed, Microsoft's was probably the last to launch, AOL and Compuserve were more notable and longer-lived (as walled gardens anyway).<br> <p> By 1996 MSN had become a web-based interactive media site although "MSN Classic", the above walled garden, survived until 1998, increasingly shrivelled and unmaintained and "MSN Dial-up", the service you paid for that was no longer the walled garden, survives to this day if you still want dial-up Internet access for some reason. By the turn of the century "MSN" meant a web site Microsoft owned, msn.com, that was a "web portal" when that was a thing, which if you're over sixty maybe it still is.<br> <p> It's amazing to me that in 1995 there was (some) executive cover for MSN at Microsoft. Not just because Netscape Navigator 1.0 is from 1994, but because the Internet itself is clearly unstoppable by that point. In 1989 the Internet is dominant but perhaps not unstoppable, in the US a lot of systems are using IP, but JaNET is still an X.25 network, and many countries have little or no multi-institutional networking above bulletin-board type systems. By 1992 that's all over, "experimental" Internet service for JaNET dwarfs the "official" X.25 network it was created to run, countries with little English penetration are maintaining non-IP systems they've already built, but there is absolutely no demand for any new non-IP systems. There is a thriving cottage industry of filing the serial numbers off the Berkeley TCP/IP implementation and pasting it into other software to interoperate.<br> <p> There seems to have been some conceit at Microsoft that MSN could co-exist with the Internet, rather than one or the other being extinguished. That never made any sense at all. The only reason to have MSN at all was if you were sure you could extinguish the Internet and sell MSN instead, and that didn't pass the laugh test by 1995.<br> </div> Mon, 04 Jun 2018 18:39:58 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756524/ https://lwn.net/Articles/756524/ tialaramex <div class="FormattedComment"> Yes, but the point is that when you use software to examine ARP packets on your local network, that software isn't magically divining the true identity of the sender of those packets, if the packets have IP address 1.1.1.1 the software just does rDNS and says 1dot1dot1dot1.cloudflare-dns.com because that's what the entry for 1.1.1.1 in the reverse DNS says.<br> <p> Now, is it technically possible that a Cloudflare DNS server is on your LAN? Sure (maybe "your LAN" is in a datacentre or you work for Cloudflare). Is it likely? Nope, lots of idiots hijack 1.1.1.1 because they figure they'll pick a real value later, or they assume it's unused because it wasn't used back when they wrote their software, or just because they're very lazy and unimaginative.<br> <p> And yes, it's legitimate. The 1.1.1.0/24 network (and several others in that neighbourhood) are so poisoned as to be useless for most purposes because of the hijacking I mentioned. However this particular address is memorable and thus valuable to Cloudflare. They struck a deal with, IIRC APNIC (the RIR for the Asia Pacific region) who were unable to issue this address to an LIR because it's poisoned, Cloudflare's DoS-resistant network resources would be used to monitor the subnet for APNIC and in exchange APNIC would let them advertise anycast routing into this /24 (effectively just for 1.1.1.1 itself) to run DNS services around the world.<br> </div> Mon, 04 Jun 2018 17:40:55 +0000 DNS but no security ? https://lwn.net/Articles/756529/ https://lwn.net/Articles/756529/ Cyberax <div class="FormattedComment"> <font class="QuotedText">&gt; Clients ABSOLUTELY need to do DNSSEC checking themselves, otherwise you literally gain nothing from even attempting to use DNSSEC for some part of the journey.</font><br> Nothing stops you from doing it with DoH. Just query for NSKEY and RRSIG records and do the chain walking yourself.<br> <p> Actually, it makes it easier. The major impediment for DNSSEC are clueless local resolvers that simply ignore DNSSEC record requests or even actively strip them off.<br> </div> Mon, 04 Jun 2018 17:40:11 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756527/ https://lwn.net/Articles/756527/ Cyberax <div class="FormattedComment"> DNS can use UDP. But if you're using DNSSEC then the replies are most likely larger than your MTU, prompting a fallback to TCP. So now you have UDP request followed by a TCP request.<br> <p> Simply keeping a pool of open TLS connections is probably going to be a speed win.<br> </div> Mon, 04 Jun 2018 17:37:03 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756522/ https://lwn.net/Articles/756522/ tialaramex <div class="FormattedComment"> Apparently Firefox's implementation has both a soft fail and a hard fail DoH mode. In hard fail, too bad, you wanted DoH, the name you asked about is NXDOMAIN (or no records) according to the DoH resolver, so, this site isn't reachable.<br> <p> In soft fail, after it gets a negative response over DoH, Firefox tries your default OS resolver. This means /etc/hosts entries, "split brain" private DNS entries and so on will work after that happens.<br> <p> I can see there'd be split brain scenarios where this doesn't do what you want (e.g. the public Internet sees one server, which requires a separate multi-step authentication, but the private Intranet offers a different IP address for the same name, and on that server it uses, say, Windows authentication or a company SSO solution). But I suspect those are comparatively rare.<br> </div> Mon, 04 Jun 2018 17:32:03 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756517/ https://lwn.net/Articles/756517/ jmanig <div class="FormattedComment"> <font class="QuotedText">&gt; that's just what the official owner of 1.1.1.1 has set its reverse DNS to.</font><br> <p> Actually, 1.1.1.1 seems to be Cloudflare's new DNS over HTTPS server, or at least if the <a href="https://1.1.1.1">https://1.1.1.1</a> website is to be believed. I'll admit I just looked quickly and did not dig into whether this is legit or not.<br> </div> Mon, 04 Jun 2018 16:28:35 +0000 DNS but no security ? https://lwn.net/Articles/756512/ https://lwn.net/Articles/756512/ Wol <div class="FormattedComment"> <font class="QuotedText">&gt; Is Mozilla going to take responsibility for fraud if their DNSSEC implementation is buggy and incorrectly says a site is fine? I assume not, because of the standard disclaimer of warranty, and that seems like essentially the same situation.</font><br> <p> "Unfair Terms And Conditions".<br> <p> If Mozilla enable it by default, and disclaim warranty, then certainly for the man on the Clapham Omnibus they could get a *VERY* nasty shock in court ...<br> <p> Cheers,<br> Wol<br> </div> Mon, 04 Jun 2018 15:52:32 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756510/ https://lwn.net/Articles/756510/ Wol <div class="FormattedComment"> <font class="QuotedText">&gt; &gt; There never was any "contract" that a Web page is a static "document", and if there had been, it was lost when JS was enabled by default in Netscape 2 in 1995.</font><br> <p> <font class="QuotedText">&gt; You *know* that this is a very lopsided view of things. The Web is still degrading now, and the most important part of the slope started about five to seven years ago. Before, there always was a talk of "graceful degradation", but taking away the controls from users is just doing the rest. So yes, there were remnants of that contract there.</font><br> <p> The broken contract I really miss is that it is down to the *receiver* *device* to control the formatting, such that what appears on the screen and what appears on the printer and what appears on whatever other device the user may have ... I'm just totally fed up with a "simple" web page in the browser turning into 30 or 40 pages on the printer, many with just one giant letter on them, and the information that I really wanted that was clearly visible on screen doesn't even print!!!<br> <p> Cheers,<br> Wol<br> </div> Mon, 04 Jun 2018 15:47:09 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756464/ https://lwn.net/Articles/756464/ oldtomas <div class="FormattedComment"> <font class="QuotedText">&gt; There never was any "contract" that a Web page is a static "document", and if there had been, it was lost when JS was enabled by default in Netscape 2 in 1995.</font><br> <p> You *know* that this is a very lopsided view of things. The Web is still degrading now, and the most important part of the slope started about five to seven years ago. Before, there always was a talk of "graceful degradation", but taking away the controls from users is just doing the rest. So yes, there were remnants of that contract there.<br> <p> A strong indicator is web sites explaining to users how to enable Javascript (and trying to talk them into "just enable Javascript now, dammit"): those have been disappearing as those users become less and less.<br> <p> Leaving that little checkbox there might have changed things a bit. One little piece of user empowerment less, alas. <br> <p> (And yes, I acknowledge Mozilla's efforts with NoScript, but this is just a poor substitute).<br> <p> I know you don't like to hear it, because Mozilla's vision is "the browser as application platform", but that's what I observe. So I'm furious and you're sad.<br> </div> Mon, 04 Jun 2018 14:49:05 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756447/ https://lwn.net/Articles/756447/ roc <div class="FormattedComment"> I'm not doing this work. I don't even work for Mozilla. So I don't have the data myself. But I know the people who are doing it, and I trust them and their claims.<br> <p> <a href="https://bitsup.blogspot.com/2018/05/the-benefits-of-https-for-dns.html">https://bitsup.blogspot.com/2018/05/the-benefits-of-https...</a><br> This is also relevant: <a href="https://developers.google.com/speed/public-dns/docs/performance">https://developers.google.com/speed/public-dns/docs/perfo...</a><br> The average ISP just isn't that good at managing this kind of service.<br> <p> Having said that: you're right. I overstated the case to say it's "actually faster for almost all users". Sorry. It probably is for many users, but we don't have that data yet, and improvements like QUIC and push are probably needed to make it really fast.<br> <p> <font class="QuotedText">&gt; Cloudflare cackles as they get all the data because Mozilla buried the option to change the DoH "service" somewhere in about:config, and any alternative DoH service wouldn't have as good peerings as Cloudflare does.</font><br> <p> Google probably does, and they're running a public DoH service: <a href="https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers">https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly...</a><br> </div> Mon, 04 Jun 2018 13:34:43 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756444/ https://lwn.net/Articles/756444/ roc <div class="FormattedComment"> Yeah, Microsoft was copying AOL's playbook and setting up their own walled garden, MSN, making deals with all kinds of potential content providers. But before it really got going they saw that the Web would swamp them and pivoted to focusing on Internet Explorer, cancelling all those deals overnight.<br> <p> You were probably being sarcastic but if Microsoft had crushed the Web with their own platform through MSN or later WPF/Avalon, our situation today would be very different and probably a lot worse. Mozilla saved the day, with generous help from Bill Gates's blunders.<br> </div> Mon, 04 Jun 2018 13:20:06 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756441/ https://lwn.net/Articles/756441/ excors <div class="FormattedComment"> I seem to remember thinking The Microsoft Network was much cooler than the web, some time around 1995. I think it was an internet-based (but not web-based) dial-up service with multimedia pages and chat rooms and stuff, but it had a tragically short life. Maybe the web should have stuck with static hyperlinked documents, and we could all still be enjoying MSN today.<br> </div> Mon, 04 Jun 2018 13:05:07 +0000 DNS but no security ? https://lwn.net/Articles/756435/ https://lwn.net/Articles/756435/ excors <div class="FormattedComment"> Is Mozilla going to take responsibility for fraud if their DNSSEC implementation is buggy and incorrectly says a site is fine? I assume not, because of the standard disclaimer of warranty, and that seems like essentially the same situation. Unless you're going to check the DNSSEC records yourself with pen and paper, you inevitably have to trust somebody else. Trust is transitive - if you trust Mozilla then that implies you trust the third-party libraries they choose to use in their code (via trusting Mozilla's methods of evaluating those libraries), and similarly you trust the third-party services they choose to cooperate with. So you should either trust Mozilla and Cloudflare equally, or you should trust nobody and never do online banking.<br> </div> Mon, 04 Jun 2018 12:43:44 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756434/ https://lwn.net/Articles/756434/ excors <div class="FormattedComment"> <a href="https://www.theregister.co.uk/2017/12/14/protecting_dns_privacy/">https://www.theregister.co.uk/2017/12/14/protecting_dns_p...</a> says DNS performance is often surprisingly slow - "the 75th percentile for lookups is 181 milliseconds". (I don't know where that data originally comes from, but I don't doubt it exists). It sounds like many ISPs just implement DNS badly, and they don't care enough to improve it, and the people who do care (like end users and Mozilla) didn't have the power to fix anything. But now Mozilla can fix it by moving users onto more efficient DNS implementations.<br> <p> The latency of a single DNS request isn't hugely important in a web browser - the problem is when you need to sequentially make one request for the HTML page, then another to a different domain for the JS, then to a third domain for some JSON data, then to a fourth for an image, etc. Doing the handshake per request would be silly, but you can fix that by just keeping the DoH connection alive for a few seconds - you don't need an endless flood of keep-alive packets. If it times out and you need to restart the connection when the user clicks a link an hour later, that's fine.<br> <p> <a href="https://bitsup.blogspot.com/2018/05/the-benefits-of-https-for-dns.html">https://bitsup.blogspot.com/2018/05/the-benefits-of-https...</a> notes that DoH will be able to easily transition from HTTP/2-over-TCP to HTTP/2-over-QUIC-over-UDP, for more efficient transport and better handling of packet loss (which I assume is really bad in DNS-over-UDP), and there's the possibility of providing a speculative response before the request has even been sent (if they can work out how to preserve security/privacy/etc). Since browsers and CDNs obviously want to improve HTTP performance anyway, so the protocols and implementations will already exist, and DoH only requires coordination between a single browser and a single DNS provider (not every single ISP in the world) to provide the full benefit to the browser's users, it seems a reasonably straightforward approach.<br> </div> Mon, 04 Jun 2018 12:26:40 +0000 DNS over HTTPS in Firefox https://lwn.net/Articles/756433/ https://lwn.net/Articles/756433/ roc <div class="FormattedComment"> I should also point out that Mozilla did a significant amount of work on WebExtensions APIs in the last couple of years to make sure NoScript still works.<br> </div> Mon, 04 Jun 2018 11:56:40 +0000