Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS-over-HTTPS Policy Requirements for Resolvers

blog.mozilla.org

Post reply on HN
Print view View original

291–300 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#291

Post by Avamander »

AlexandrB wrote: post #184
Avamander wrote: post #109

Earlier quoted context omitted.

Don't worry. Soon Chrome will also implement DoH and ESNI, then you actually have to either forbid BYOD or actually start teaching students manners, how browsing porn is not okay in school context. I'm really quite annoyed by the connotation that kids should rather be helicopter-parented (by tech or by people) than actually taught what's okay and what's not. The very least the new tech provides is that any silent hel…

> Soon Chrome will also implement DoH and ESNI, then you actually have to either forbid BYOD or actually start teaching students manners... If you think that this is how it will go, you're very naive. If schools and parents can't block porn anymore, prepare for more legislation that blocks porn by default at the ISP unless you pay some kind of fee - like what the UK has proposed. Also look for a return of "content st…

Thankfully I don't live in the USA where asinine things like that would work. Pretty sure there isn't a single school here try and enforce a web filter other than "Let's agree not to visit pages that are not allowed [OK]". I'm hope I'm not naive, maybe just not super-accustomed to the "tHinK oF tHE ChiLDRen"-narrative for pushing filters (or other things) trough.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#292

Post by 3xblah »

topranks wrote: post #240
3xblah wrote: post #71

"To that end, today we are releasing a list of DOH requirements, available on the Mozilla wiki, that we will use to vet potential resolvers for Firefox. The requirements focus on three areas: 1) limiting data collection and retention from the resolver, 2) ensuring transparency for any data retention that does occur, and 3) limiting any potential use of the resolver to block access or modify content. " I sometimes use…

I’d be fairly certain this would be against Mozilla’s requirements.

Any idea of the reasoning behind that choice?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#293

Post by glennpratt »

JohnFen wrote: post #285
shawnz wrote: post #280

Earlier quoted context omitted.

If DNS-based access control is not sufficient on it's own, then is it really worth it to block DoH (which could have other significant security and privacy benefits) just to retain the possibility of using it? Why not focus on improving those other, already necessary access control technologies and forget about abusing DNS for this purpose, so we get the best of both worlds?

Because I believe in multilayered security. No one approach to security is sufficient, but combining as many approaches as possible can allow each approach to help cover the weaknesses of the other approaches. Also, I disagree that denying the lookup of certain domain names is abusing DNS. If I were running a DNS server that was being used by the public, or that was being used by downstream DNS servers, that would be…

> If I were running a DNS server that was being used by the public, or that was being used by downstream DNS servers, that would be different.

Without cooperation of the device, that is indistinguishable from that of a bad actor.

You can get what you want by owning the device and requiring it to cooperate (ie with controlled software or a certificate to allow monitoring / blocking).

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#294

Post by tlrobinson »

pwnna wrote: post #288
tlrobinson wrote: post #85

Earlier quoted context omitted.

How far off are we from DoH being supported by common operating systems, DHCP, etc? It would be nice if these apps could detect whether the system is using DoH and only fall back to their own DoH resolver in the case they're using "legacy" DNS.

What's the point of using DoH over the local network? We can generally assume the local network is "secure". If I want to use DoH when sending DNS queries to the outside world, I can setup my own forwarder to forward DNS queries via DoH.

That's not always a safe assumption, e.x. public WiFi.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#295

Post by tlrobinson »

coldacid wrote: post #103
tlrobinson wrote: post #85

Earlier quoted context omitted.

How far off are we from DoH being supported by common operating systems, DHCP, etc? It would be nice if these apps could detect whether the system is using DoH and only fall back to their own DoH resolver in the case they're using "legacy" DNS.

Honestly, all these apps shouldn't even bother detecting for DoH or not. If people want to use DoH they can set up their own local resolver and configure their network for it (and for folks on Windows, that could even be packaged third-party).

The reason browsers are interested in including DoH is to protect users who don't even know this is a problem, and definitely aren't going to set up their own resolver.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#296

Post by the8472 »

Spivak wrote: post #278
the8472 wrote: post #200

Earlier quoted context omitted.

You have that backwards. It's applications that are less than trustworthy. That's why we try to sandbox them. As for the DHCP part, if you're on a public network you should only trust it as far as you need it to bootstrap your tunnel over which you can then finally contact a trusted resolver. OS resolver -> a single thing you need to secure every app uses its own resolver -> complete mess which makes it harder to ens…

Browsers don't trust the OS to provide secure private name resolution. And they really shouldn't when every OS just blindly takes whatever is offered via DHCP. I absolutely agree that DNS should be a system-level concern rather than app-level. But today, right now, for computers as they are and will continue to be for the foreseeable future this is a huge improvement. Browsers being the app that handles basically all…

I don't think this is the proper approach. Once it's in browsers it will also be in electron applications. And those may update less frequently. Now you have balkanized implementations of custom DNS stub resolvers using different remote endpoints. That makes security updates more difficult, network issues more difficult to debug and so on.

Doing it properly would involve securing the system, once. This could be easily done by installing a DoH stub resolver service and then pointing the system config to localhost.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#297

Post by shawnz »

JohnFen wrote: post #285
shawnz wrote: post #280

Earlier quoted context omitted.

If DNS-based access control is not sufficient on it's own, then is it really worth it to block DoH (which could have other significant security and privacy benefits) just to retain the possibility of using it? Why not focus on improving those other, already necessary access control technologies and forget about abusing DNS for this purpose, so we get the best of both worlds?

Because I believe in multilayered security. No one approach to security is sufficient, but combining as many approaches as possible can allow each approach to help cover the weaknesses of the other approaches. Also, I disagree that denying the lookup of certain domain names is abusing DNS. If I were running a DNS server that was being used by the public, or that was being used by downstream DNS servers, that would be…

> I believe in multilayered security. No one approach to security is sufficient, but combining as many approaches as possible can allow each approach to help cover the weaknesses of the other approaches.

Agreed with you there, I'm not saying that multilayered security is a bad thing.

What I'm saying is that right now, in terms of easy and accessible DNS privacy, we have 0 layers. Don't you think it might be worth sacrificing this one partial, incomplete access control solution in favour of solving that?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#298

Post by selenamarie »

vetinari wrote: post #271
selenamarie wrote: post #235

Earlier quoted context omitted.

A subdomain that doesn't resolve is handled properly -- meaning DoH is then disabled.

Didn't know that, great, thanks. On the other of the common problems: I assume there is no way to blackhole existing, public records, other than extension ala uBlock/Adblock?

We're working on exceptions support, which would allow specific domains to be looked up via DNS instead of DoH. In that case, mirroring a blackhole list to the exceptions support would result in what you want (I mean, if I understand what you're asking).

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#299

Post by DaniloDias »

JohnFen wrote: post #286
flarex wrote: post #7

Earlier quoted context omitted.

The argument that because encryption can be used for nefarious purposes it should not be offered by DNS providers at all does not add up. ISPs can block, redirect and sell DNS traffic and many are already doing some or all of these.

I don't think anybody is arguing that DNS lookups shouldn't be encrypted. The issue is doing DNS lookups via HTTPS.

I’m specifically arguing that dns lookups should not be encrypted. Dns can be descriptive: ntp.example.com sounds like an Ntp server. Oh- this pcap shows an ntp flow afterwards. Probably synchronizing time.

Oh- adnetwork.example.com. Probably serving up ads.

Oh Agrrvxdrgkndzzzvbbhydsxxjjj.net.org.com. Probably botnet related.

Vs

I need to look at every protocol flow and sort by IP?

Who in their right mind blindly trusts all computers like this? If you ever want to troubleshoot your network, your job becomes way more tedious if dns requests are encrypted.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#300

Post by pas »

AnaniasAnanas wrote: post #268
moosingin3space wrote: post #170

Earlier quoted context omitted.

How does DoT avoid this issue? IIRC, DoT runs over port 853, which is trivial to block.

I am pretty sure that the client can use a bridge to connect.

And that's DoH. A DoT-over-HTTPS proxy if you will.

And for HTTP/1.1 it should use WebSocket for a persistent connection, but probably it already targeted HTTP/2.

Post reply on HN