DNS-over-HTTPS Policy Requirements for Resolvers • Hacker News Board

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#151

Post by shawnz » Wed, Apr 10, 2019, 5:44 PM UTC

EvanAnderson wrote: post #133

foobarbazetc wrote: post #108

Earlier quoted context omitted.

Think of this more like which CA roots browsers include by default instead of a nefarious plan to stop you from doing whatever you want.

It's not a nefarious plan to stop me from doing what I want in a FOSS browser on a PC where I can compile and run what I want. It will be used that way, however, on locked-down devices users pay for but don't actually own.

Then don't buy such a device which clearly doesn't meet your needs. Why should every personal computing device on the planet be tailored to your requirements, at the cost of safety for the majority of other users? Most people don't use PiHole, they use Adblock or uBlock which are not affected by this. It's not as though they are taking away your ability to use adblocking technology.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#152

Post by CydeWeys » Wed, Apr 10, 2019, 5:47 PM UTC

LinuxBender wrote: post #140

CydeWeys wrote: post #82

Earlier quoted context omitted.

I was referring to the machines they were preventing the installation of Firefox on. For BYOD, I don't know what you're gonna do. Many students have smartphones too (some with tethering), and you can't control what they look at on those either. Plus, even if the school could somehow magically lock everything down 100% within the confines of the school building, the students can still get access to whatever at home, o…

You can use special paint on the buildings that blocks RF. There are also cell phone jammers. They require a license and approval from the FCC and have legal implications / risks.

This use case wouldn't get approved. It's very hard getting an exception and this doesn't come close to meriting it.

Preventing cell phone calls could have dire consequences in an emergency, and stopping kids from looking at porn doesn't remotely merit taking that risk.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#153

Post by wbl » Wed, Apr 10, 2019, 5:48 PM UTC

vetinari wrote: post #40

wbl wrote: post #23

Earlier quoted context omitted.

You can still administer the machine and change firefox's settings.

Most people roam among multiple networks. Are you going to change the settings manually after each connection in different network? Most people won't. We already have an automation for that, called DHCP, setting up network specific config system-wide... which Mozilla decided to ignore.

So whose device is it anyway? I don't want to use my ISP's lying DNS resolver.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#154

Post by wbl » Wed, Apr 10, 2019, 5:49 PM UTC

zzzcpan wrote: post #26

wbl wrote: post #22

Earlier quoted context omitted.

How is DoH a net negative? ESNI is coming soon. Also ISPs do all sorts of other badness with DNS like NXDOMAIN interception.

If you can't trust your ISP, leaking all of your DNS traffic to another party still doesn't let you trust your ISP, but now you have to trust that other party too, hence net negative. To avoid trusting your ISP you need at least a VPN.

Now that I use another revolver the NXDOMAIN problem is fixed.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#155

Post by LinuxBender » Wed, Apr 10, 2019, 5:50 PM UTC

CydeWeys wrote: post #152

LinuxBender wrote: post #140

Earlier quoted context omitted.

You can use special paint on the buildings that blocks RF. There are also cell phone jammers. They require a license and approval from the FCC and have legal implications / risks.

This use case wouldn't get approved. It's very hard getting an exception and this doesn't come close to meriting it. Preventing cell phone calls could have dire consequences in an emergency, and stopping kids from looking at porn doesn't remotely merit taking that risk.

I completely agree.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#156

Post by EvanAnderson » Wed, Apr 10, 2019, 5:57 PM UTC

shawnz wrote: post #151

EvanAnderson wrote: post #133

Earlier quoted context omitted.

It's not a nefarious plan to stop me from doing what I want in a FOSS browser on a PC where I can compile and run what I want. It will be used that way, however, on locked-down devices users pay for but don't actually own.

Then don't buy such a device which clearly doesn't meet your needs. Why should every personal computing device on the planet be tailored to your requirements, at the cost of safety for the majority of other users? Most people don't use PiHole, they use Adblock or uBlock which are not affected by this. It's not as though they are taking away your ability to use adblocking technology.

Macro-level view: The Mozilla Foundation may think that DNS-over-HTTPS is about "safety", but they're unwittingly furthering the agenda of those who would profit from the Internet not being decentralized. A decentralized Internet filled with devices that end users can control, should they choose, is a good thing for society, I'd argue. DNS-over-HTTPS is another piece of technology that can be used to eliminate that. It is not necessary to hand over freedom in exchange for "safety" or "security".

Micro-level view: I'm a sysadmin for my Customers, my family, and some of my friends. Inevitably I will have to deal with these awful devices. So will countless other sysadmins. I'm dreading having to deal with devices that invade my users' privacy, thwart my attempts at detecting bad actors on the network, and that just generally act like the person who paid for them doesn't actually own them.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#157

Post by vetinari » Wed, Apr 10, 2019, 5:59 PM UTC

wbl wrote: post #153

vetinari wrote: post #40

Earlier quoted context omitted.

Most people roam among multiple networks. Are you going to change the settings manually after each connection in different network? Most people won't. We already have an automation for that, called DHCP, setting up network specific config system-wide... which Mozilla decided to ignore.

So whose device is it anyway? I don't want to use my ISP's lying DNS resolver.

On your router, you can configure whatever you want to use for the DNS. You were able to do that for years.

But I want all the devices and apps to use whatever the local network tells them. I don't want to reconfigure the browser every time I connect at home/work/customer place/etc.

P.S. My ISP's DNS doesn't lie. Maybe you should vote with your money and choose better.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#158

Post by moosingin3space » Wed, Apr 10, 2019, 6:04 PM UTC

protomyth wrote: post #149

cpeterso wrote: post #118

Earlier quoted context omitted.

Not to Mozilla, but to whichever DoH service Firefox is configured to use, by default or by the user. Mozilla isn't running a DoH service.

What is the default?

Cloudflare 1.1.1.1 is the default.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#159

Post by protomyth » Wed, Apr 10, 2019, 6:05 PM UTC

What is the justification for an app to resolve domain names differently than the services the operating system provides? I am really curious why this is a thing.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#160

Post by vetinari » Wed, Apr 10, 2019, 6:07 PM UTC

EvanAnderson wrote: post #136

selenamarie wrote: post #102

Earlier quoted context omitted.

I'm working on our DoH implementation. I'm guessing this is a split-horizon set up with a domain that resolves both internally and externally. If you are willing, we're very interested in these situations and coming up with heuristics to detect and disable DoH proactively. We're also looking into standards changes that could make these configurations more reliably detectable at the application level. I'm selena at mo…

As a sysadmin who rails against split-horizon DNS (usually around Active Directory implementations where brain-damaged people have named the AD domain the same as a public Internet domain name) I'm already getting a churning feeling in my stomach thinking about how software is going to mishandle this scenario in DNS-over-HTTPS. It's going to be particularly god-awful for devices that roam between networks where the "…

> usually around Active Directory implementations where brain-damaged people have named the AD domain the same as a public Internet domain name

I don't like this one either, but often it is inherited from the past from other people and it is not going to change.

On the other hand, split-horizon DNS is going to stay with us, even if the AD domain is a subdomain of the public one. Records in the internal zone are not going to become public anytime soon.