It's been a week since engineers approved a new DNS encryption standard and everyone is still yelling

Re: The whole thing is just utterly depressing

I say this because of two things it simultaneously does -- it makes it necessary to rely on a large provider for your DNS resolution, and it makes it less likely that the problems with DNS will actually get resolved in a manner that maintains decentralization.

It's also a security problem, because it only addresses browser use. People are likely to think that all DNS queries will be secure, when that's not the case at all. It also encourages the terrible tendency for people to think that the web and the internet are the same thing, a factor which is, in my opinion, terrible for the internet.

On top of all that, this is shoving yet another unrelated thing through the HTTPS port. Doing this is also a security problem because it makes it difficult-to-impossible to selectively block services you don't want your network to be interacting with.

But please understand, if DoH were the only objectionable thing to come down the pike, I wouldn't react so strongly to it. But it just the latest thing in a series of moves that I think is harming the internet as a whole, so there's a bit of "straw that broke the camel's back" going on for me.

Re: Doh.....

For all the "but it looks like HTTPS" arguments, it's still fairly trivial to block the ones that are most likely to be used by the majority of people (i.e. Cloudflare etc). Block TCP 443 to 1.1.1.1 and any others you can find on the net.

You don't, for a second, have to block everything. If you block enough to be inconvenient then users will likely start turning TRR off.

I'm not saying I support that approach, just that claims it's unblockable because it just looks like https are crap. A good traffic profiler will probably be able to start picking out likely TRR destinations too, so you could even auto-populate an ACL if you're willing to accept occasional overblocking.

Re: where are the implimentations ?

And what if you're doing split horizon routing? (Yeah, yeah, I know, I don't like it either).

Re: where are the implimentations ?

.local I think is mainly used in windows and mac environments ? I've never used it in linux anyway. At the org I work for we have 47 domains hosted internally, some are both internal and external. All are .com or maybe .co.uk .de .fr etc.

Used to have over 100 but cut it down by a bit last year.

So saying .local isn't affected does nothing for what may be my situation at some point.

Re: Cat herding

The Web isn't the only use of DNS though. Any service that needs to resolve a hostname to find which IP address to connect too, or what domain a connecting IP belongs too (assuming PTR records are appropriately updated) rely on DNS. The assumption that "The Web" == "The internet" needs to die.

Yes "The Web" is an important service that many people use day in day out, but it is only one of many services that run over the internet.

Re: Cat herding

"I'm not so sure if his incentives align with Web (and thus DNS) users"

DNS is used by far more services than the web. All of them, in fact. All web users are DNS users, but not all DNS users are web users.

Re: Cat herding

"What changed this were the public pronouncements from Mozilla engineers that they wanted to make DoH the default method for doing _all_ DNS lookups from inside the Mozilla browser, and that they would take it upon themselves to chose the default far-end resolver DNS service (initially Cloudflare) on your behalf."

They didn't do that though, that is just for the opt-in test. Once DoH is added to Firefox stable it will use whatever DNS resolver you configure. Over time more and more DNS revolvers will add DoH support. DoH is just a protocol, it doesn't do anything in regards to centralisation or de-centralisation.

There are already quite a few independent DoH revolvers to pick from.

Re: Cat herding

Just because a DNS Researcher who happens to be employed by ICANN was involved in the authorship of this RFC doesn't in any way imply that ICANN corporately endorses the standard and will lobby for it.

Nope, ICANN would never do that. ICANN has, and always will be the epitomy of good governance. Now, would you like to buy a TLD?

But it is not a 'standard'. It's an RFC, not an STD. As such, it can be freely ignored. Or commented on by a wider audience than just the WG. That the WG didn't expect that it would hand traffic to the biggest abusers of confidentiality simply highlights the problems with the WG process. It might provide confidentiality for data in transit, but won't once it's hit the resolvers.. Or proxies, caches etc..

But I've been pondering Vixie's comemnt about control plane security more. DNS currently is a simple process to write a plain text request and read a plain text response. So a client doesn't need much trust, other than how it passes the response to whatever has requested the connection. That session may then be encrypted between client-host and seperate to any hosts process. Requiring encryption presumably means the hosts process has to hook into the device's encryption routines at a higher trust level so a DNS attack could end up compromising the control-plane functions.

Which can't be a good thing, especially as DNS is a function used by pretty much every Internet device, not just web browsers. Especially if there's pressure to make this a 'standard', or if the usual resolvers require it. It's been generally accepted that hard coding IP addresses into devices isn't best practice, and re-writing code for millions of IoT stuff will inevitably cause some to break, or become insecure.

Re: Cat herding

"as an ad-hoc means to secure your DNS lookups in environments where you can't trust that the local DNS resolver isn't messing with your queries (e.g. a coffee-shop Wi-Fi network)"

If you're using such an access point without also using a VPN, you have very serious exposure in more areas than just DNS lookups. For that use case, DoH is like spitting in the ocean.

Re: Not one to nitpick but...

"Remember that the first provider of DoH services is CloudFlare. They could enable DoH on *all* their front IP addresses. In that case, it would be impossible to block DoH without also blocking all sites hosted on CloudFlare (including El Reg)"

They could just declare that CloudFlare and the like are violating local sovereign laws and tell them to knock it off or get blockaded as a bloc: deal with the moles by burying the entire molehill. And tell any sites that use CloudFlare to consider alternatives tout suite or face becoming collateral damage in a sovereign struggle.

Re: Not one to nitpick but...

"That's called whack-a-mole, and it doesn't work."

It doesn't work well for sure, but if it's all you got...

Re: Not one to nitpick but...

"In that case, it would be impossible to block DoH without also blocking all sites hosted on CloudFlare (including El Reg)"

True, but the way the web has been going over the past five or ten years, I'm not entirely sure that I'll be able to keep using it long-term anyway.

Re: Not one to nitpick but...

"But the real reason is because it makes DoH almost impossible to block."

That's correct, but I suspect that the real reason isn't to protect users at all, but to protect the ability of companies (particularly ad companies like Google) to continue to spy uninterrupted. DoH makes it much more difficult to use a firewall to protect your systems from accessing locations that are used to collect data about you and your systems.

Removing this layer of protection is the primary reason that I view this as a bad move for everybody who isn't into surveillance.

Re: Not one to nitpick but...

"Because HTTP and DNS are different protocols with different payload format. The whole point of a well-known port is that you know in advance which protocol you are supposed to speak, when you open or accept a connection."

But what if that's EXACTLY what you're trying to avoid because you don't want people to know you're making a DNS connection for fear of it being tracked or at least blocked? A hostile government can attempt to hijack DNS for ill intent unless it can't tell HTTPS and DNS apart because they're simultaneously running on the same channel. How do you deal with such a scenario?

Re: Who do you trust?

"they cannot block it without blocking all HTTPS traffic."

Yes, they can, as long as DoH servers are being run from defined IP addresses. The use of HTTPS does not prevent routers from seeing where traffic is going to and blocking traffic to/from certain destinations.