DNS over HTTPS in Firefox

I have a "Vodafone Kabel Deutschland" Internet connection at home, and there is IPv6, completely out of the box, _and enabled by default_.

Opening Google and asking "what is my IP" always shows my IPv6 address.

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.

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.

As it stands the only thing I can divine from a DNS request via Cloudflare's Mozilla DoH offering is that it... came from some particular Cloudflare node. Probably that node is near the originator, although maybe not. There's no way around revealing this unless you're happy sacrificing performance (e.g. TOR will incur a few hundred milliseconds latency, in exchange for which nobody knows where you are in the world)

But if the EDNS "Client Subnet" is back, I get to see part of an IP address which may be more or less incriminating. Among the addresses handled by my ISP are "dynamic" assignments, where even seeing the whole address without access to their logs doesn't tell you much, right through to genuinely portable address space owned by customers, where even seeing /20 potentially gives away the game about who the end user is. I'm in the middle, with a static (but not portable) /28 of my own. So when you snip off the last 8 bits, you narrow things down to maybe a dozen customers like me with "Client Subnet" as it stands today, and maybe you could make that hundreds, but you can't make it thousands without also destroying the utility of the technique, and you'd still identify those with portable space.

I suppose other options might include:

1. Recruit one or more other DoH providers willing to offer privacy, pick a random one (at start-up, for each query, or whatever)

2. Switch off privacy, preferring to give better CDN and sacrifice the user's privacy (or maybe do so outside the porn-viewing mode)

3. Incorporate this functionality but leave it unused by default (so 99% + of users never benefit)

When it comes to item (1) I think you've got the same situation as the Search box. Users _can_ pick GoodSearch, or whatever, but by default they get the search engine Mozilla picked. The DoH configuration absolutely can be changed by anybody who knows what DNS even is in the first place. Should the Mozilla corporation sell that default (assuming multiple bidders offer equivalent privacy) for $1M? It is, after all, just a default. How about for $10Bn? That's a LOT of evangelism and software development for the price of a default...

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.

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.

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. But if it's a just _default_ that's better than making all the millions of people who prefer Google reach in and change that setting.

This is also a security consideration, and Mozilla absolutely does make decisions about security on behalf of its users with only "Build your own browser instead from our source" left as an option for those who disagree. For example the upcoming distrust of CA roots controlled by Symantec (Verisign, Thawte, etcetera) won't be something you opt into, or even a default, it'll just happen automatically when you upgrade Firefox. Again I have no doubt that at least one person in the world would prefer to continue trusting these roots, and that person might not even work at Symantec, but Mozilla chose on behalf of its entire user population to distrust these CA roots.

Faster at what cost ?

As long it is easy, practical and doesn't require to the single intellectual effort the user will go for it. Bigcorp just see their own interest with the blessing of their own customers/client...

I agree with what you previously said : "I definitely don't want my browser to bypass the operating system's resolver.", it can be faster, but I will not swallow the "big privacy win".

99% of users don't, so this is a privacy win for them.

If you take the position that Mozilla should never make DoH the default in Firefox for "reasons", then you're saying that those reasons are more important than giving those users that privacy win.

So the answer is they're collecting that data. I'm sure if the data they get says "This is slower and often doesn't work" they will accept that and re-evaluate their approach.

It's important to actually collect data, that's how we got Natural Philosophy (and so Science) as a huge upgrade over previous approaches to philosophy that proceed as you've demonstrated by arguing from premises that seem to support the philosopher's position. Among the things philosophers felt comfortable they'd figured out by your method are that the Earth is fixed at the centre of the universe, flies are spontaneously generated by the decay of living matter, and all numbers are rational.

Chrome too has programmes collecting data (although it seems Google is more comfortable just "volunteering" its own users without their knowledge), it has found all sorts of interesting things through such experiments, and since it often shares the results that lets everybody avoid getting blind-sided. For example the reason TLS 1.3 on the wire looks so silly today is that the earlier drafts (before Draft 23) were randomly enabled for Google Chrome users, and Google's metrics showed that a frighteningly high proportion failed -- even though your approach (write down axioms, scratch your beard, come to a conclusion) said that these drafts were definitely back-compatible with TLS 1.2, reality insisted otherwise. So from there experimentation found a way to sneak past most of the garbage middleboxes that weren't compatible and the draft with those changes (plus other language that doesn't change anything on the wire) is what we have today.

[ For TLS 1.2 nobody did that before publication, they relied on your approach. The standard sat on paper for _years_ largely unused, because if you tried to enable it for ordinary users a huge proportion of them got a non-working browser, and so they'd just switch to a competitor who wasn't trying to do TLS 1.2. ]

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.

https://bitsup.blogspot.com/2018/05/the-benefits-of-https... 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.

https://bitsup.blogspot.com/2018/05/the-benefits-of-https...
This is also relevant: https://developers.google.com/speed/public-dns/docs/perfo...
The average ISP just isn't that good at managing this kind of service.

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.

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

Google probably does, and they're running a public DoH service: https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly...

Simply keeping a pool of open TLS connections is probably going to be a speed win.

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)

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.

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.

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.

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