Measuring open DNS resolver use
blog.apnic.net
blog.apnic.net
How many users utilise the full number of existing domain names in the world today?
How many names do users realistically need to access in a lifetime?
What if we exclude ad servers and other domains that exist solely for marketing?
It depends on the user, but in some cases the majority of their non-commercial web^1 use can be accomplished without ever making remote DNS queries; the IP addresses can be stored and used on a long-term basis. That is because a user may only visit the same small number of websites. The foregoing is of course only an opinion based on testing conducted by yours truly. Every user is different.
Try measuring how many times the non-commercial websites you visit change IP addresses in a year.
You might find that DNS resolution is like that "definition of insanity" meme: making the same query day after day, expecting a different answer.
1 It makes a difference whether or not a user is using the web to make purchases. For making purchases online, DNS resolution is almost always required. Domains and IP addresses in that context are constantly changing. Go figure. OTOH, if you are visiting a website such as news.ycombinator.com on a frequent basis, is it really necessary to look up the IP address for news.ycombinator.com every time you visit the website? I have used the same IP address for years at a time.
This trick of altering the hostname of a subresource to identify the client is a thing I long wished we could do, but sadly we didn't have enough control of the content to do that.
I'm in a country with both of these problems, so every machine I set up gets Cloudflare as the primary resolver with Google as the secondary. Fix these problems first, and I won't have to do this anymore. Centralization? I dunno. Taking control of DNS away from my state and ISP would actually count as decentralization in my book.
If it's not too revealing, can you share what country you're in?
Cloudflare is the first well-known provider that decided to support a working protocol for encrypted DNS. DoH might not be the best possible protocol, but it's shipping now and others are not. (DNSCrypt is also shipping, but it has the weird property of speaking something that isn't HTTPS on port 443. That's too easy to censor.) There will be healthy competition if other people would please stop arguing and start shipping, too.
I'm in South Korea. The censorship regime here is more prudish than draconian, and I'm not in any danger of prosecution for criticizing it. The way it is implemented is extremely crappy, though. On top of DNS-based censorship, ISPs are doing DPI on TLS handshakes to sniff hostnames in the SNI extension. Lots of techies here are very interested in new technologies showcased by Cloudflare. That includes not only DoH but also their proposal to use keys stored in DNS to close the SNI loophole. Once again, what works in this situation is not a novel, theoretically perfect protocol but one that ships now and blends into the petabytes of HTTPS traffic that Cloudflare handles every day.
On the face of it, it seems like we're going to end up with a bunch of black box devices (from Google, Amazon etc) in our homes that are totally immune to most forms of network policing because between DoH, ESNI, TLS and CDN fronting, you can't see anything.
It's exactly as true to say that DANE gave Gaddafi ownership of bit.ly's CA as to say that today Boris Johnson owns the CA for slither.io - and as ridiculous. Back when you first started claiming this the Ten Blessed Methods weren't even a thing. You're complaining about the inadequate back door lock on a house that has the front door propped open.
I work for an outfit that buys passive DNS data (among other things) and all our suppliers agree that DoH makes no difference to their roadmaps - because they don't care who asked, only what the query and answer are. Is Vixie doing something vastly different? Maybe so but you've offered no evidence what that could be.
I can live with that.
You keep making these emotional appeals, but if I'm wrong, I don't see you actually rebutting me. "Your argument is so bad I will not deign to engage with it" is not a rebuttal.
OK, so first up I guess the problem is you've no idea what "escrow" is and so you ended up confused as to what key escrow could be. So let's fix that first.
Escrow is a service people or companies offer, the idea goes like this. Alice wants to do a deal with Bob, and Bob wants to make a deal with Alice, they're going to swap some of Alice's baseball cards for Bob's antique vase, but they don't trust each other. Fortunately they both trust Trent, a Third Party. Trent offers an Escrow service, both Alice and Bob agree with Trent that the baseball cards and the antique vase go to Trent, and then when he's got both things he'll send them to their new owners. If anything goes wrong, Trent gives back anything he received to the person who sent it and the deal is off.
In the tech industry the most likely set up you'll see is that investors are worried all the stuff they're spending a lot of money on at a startup is not material that a bunch of burly guys can pick up and put in a truck if the firm fails - instead it's in Git repos or Google Drives and if it falls apart they know it has residual value that could be realised but they're not technical people, they're money people. So an escrow firm says fine, pay us a bunch of money and make the startup sign this data escrow agreement, and then if they fail you activate this clause and we give you a bunch of USB drives full of source code and whatever else. The escrow firm has IT people who can do stuff like send over keys for access to a GitHub, who know the difference between an S3 bucket and a SD card, which the investors don't want to have to learn about.
In key escrow _your_ keys are held by a third party on your behalf. You can do end-to-end encryption if you want, but you're obliged to use this escrowed key. If the third party releases the key (e.g. because of a warrant, or an NSL, or because they're corrupt) then whoever gets it can now decrypt everything you've sent, or impersonate you seamlessly.
If your iPhone honors a secret Apple passphrase that's a _backdoor_. If instead Apple insists on keeping a copy of your passphrase in a safe at Apple HQ that Tim Cook promises not to open _that_ would be escrow.
Your objection that in DNSSEC "the roots can simply override that key with their own" also applies to any PKI, the whole _point_ of a PKI is that the trusted third party binds identity to keys, and if trust is misplaced they might falsely bind an identity to the wrong key. So the problem is - as I illustrated - that objections on the basis of DNSSEC being a PKI work just as well against the Web PKI. As a reason to prefer the Web PKI over DNSSEC they're ineffective.
Saying that backdoors are "the whole _point_" of a cryptosystem is not the devastating refutation you appear to think it is.
But that goes from being a relevant point about Vixie (his support of a system with key escrow - a false claim) to the irrelevant and vague (trusted people might betray your trust) that I guess if I squint I could read as sort of vague anti-establishment sentiment and otherwise is just pointless.
Here's a much shorter way to write what you meant without needing to slip in a false claim about DNSSEC:
"Paul Vixie is a smart guy but he's wrong about this"
Plenty of anti-TLS 1.3 stuff for example says that they "need" the plaintext Certificate message which in TLS 1.3 is now encrypted. But that message is literally just some public data - an X.509 certificate, if you're using it to "verify" anything your security is broken because a bad guy can send someone else's cert. They can't send a working CertificateVerify for it, but you don't know that because that message was never plaintext.
I wish it didn't have the overhead of TCP/HTTP (which is why I was a bigger fan of DNSCrypt). Anyone can stand up a resolver that can handle 50k UDP requests a second and operate a public resolver. It starts to get operationally dicey to stand up infrastructure that can do 50k HTTP requests a second. As a result you end up with a small handful of players who can operate medium to large scale public resolvers.
The NTP pool works quite well on this model. It would be a much larger commitment for participants had to manage stateful connections.
How does this work in your mind?
You can also just not run DoH if you trust your network. I'm saying DoH is a good thing, not that everyone has to use it.
I can see that there are problems with DNS; there always have been, and it's always been obvious. But for now, I think I prefer running my own resolver. Unbound is really easy to set up.
If your router is linux, that might look like
/sbin/ip route add blackhole 9.9.9.9 2>/dev/null
/sbin/ip route add blackhole 1.1.1.1 2>/dev/null
/sbin/ip route add blackhole 1.0.0.1 2>/dev/null
/sbin/ip route add blackhole 8.8.8.8 2>/dev/null
/sbin/ip route add blackhole 8.8.4.4 2>/dev/null
Nothing stops anyone in the middle intercepting your queries and returning whatever they want, including your provider.
OK I am being a bit cruel but this is what we have. If you don't own up to intending to cuddle up to Amazon, Google, Apple, Microsoft in the next 30s then you are probably a liar or a bit deluded.
Thing is, I'm a bit of a fan of capitalism but perhaps some sort of light touch regulation is needed in the Wild West. A bloke with a big old star on the chest might be nice.
I'm in Australia, so I don't know if in twenty years I'll still be connected to Westnet or Sinonet. I'll probably buy a black market connection to Westnet from a guy with a mohawk and implants in his head.