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

231–240 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#231

Post by JohnFen »

glennpratt wrote: post #229
JohnFen wrote: post #202

Earlier quoted context omitted.

> make it harder for bad actors to take advantage of your network. How so? It looks to me like it makes it easier for bad actors to take advantage of my network, by making it harder to detect and block DNS lookups.

You are focused on unsophisticated bad actors if DNS is all it takes to block.

I don't understand your point. I'm certainly not solely focused on the unsophisticated ones, but those sorts are important too. And they're much more common as they include ad and other trackers.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#232

Post by glennpratt »

nykolasz wrote: post #27

I replied sub-thread, but adding here to give some more visibility to some of the issues DoH is causing and will cause: I work at a k12 school and I am involved on many k12 IT communities. Some schools already removed Firefox from the students computers because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS. There is a fine line betwee…

Good! IT security theater can go away or own the device, install a root cert and really filter to your hearts content.

DNS filtering was always easily circumvented; a time sucking cat and mouse game at best.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#233

Post by JohnFen »

bluejekyll wrote: post #230
JohnFen wrote: post #224

Earlier quoted context omitted.

> I believe that the network level concerns over DoH are a little disingenuous I disagree. The problem with DoH is that it masquerades DNS lookups as web traffic. Other means of doing DNS lookups, encrypted or not, can be easily determined to be DNS lookups and handled according to the network policies. By disguising the lookups as web traffic, it means that I can no longer leave web traffic alone. I have to MITM HTT…

Can you describe the threat model your trying to account for? The reason I made that statement has to do with the means by which DNS can easily be circumvented and direct encrypted connections used instead. This means using DNS introspection as a means for security doesn't buy you much, DoH just makes that more apparent.

The threat model is anything that is trying to phone home without approval. This includes calling command-and-control servers, trackers for ads, data exfiltrators, etc.

All of these use domain names to set up the communications, for obvious reasons, so being able to thwart those lookups is of great value.

You're right, that all by itself is insufficient, but it's still very important.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#234

Post by glennpratt »

JohnFen wrote: post #231
glennpratt wrote: post #229

Earlier quoted context omitted.

You are focused on unsophisticated bad actors if DNS is all it takes to block.

I don't understand your point. I'm certainly not solely focused on the unsophisticated ones, but those sorts are important too. And they're much more common as they include ad and other trackers.

You want a warm blanket that you blocked some well known ad click tracker while having no real visibility overall. Security theater.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#235

Post by selenamarie »

vetinari wrote: post #160
EvanAnderson wrote: post #136

Earlier quoted context omitted.

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 g…

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

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#236

Post by selenamarie »

uep wrote: post #162
EvanAnderson wrote: post #136

Earlier quoted context omitted.

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 "…

My organization does this (AD domain appears to be the same as the public domain name), and I also had problems when I opted into the HTTPS DNS trial. As in, no internal servers resolved. I had thought that internal networks these days would favor multicast resolution (LLMNR/mDNS), but that doesn't appear to be the case here. Admin work is not my wheelhouse, so I have no idea what standard practice is. What is the re…

For now, we recommend having an enterprise policy for the browser configured. That is the best indication we have that the browser configuration is managed and this kind of issue might occur. We're also open to recommendations from admins on other things that might clue us in that we're in this situation. Finally, we're discussing the possibility of establishing a network standard that signals more strongly that "name shadowing" is occurring... like maybe there's some DNS response that can be configured locally that we can look to proactively and then disable DoH.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#237

Post by topranks »

stupidthrottle wrote: post #48
flarex wrote: post #4

Earlier quoted context omitted.

His main argument seems to be that the network operator should have control over DNS requests for safety reasons. Control and monitoring. This is the antithesis of privacy and encryption. I wouldn't be surprised if he was pro http over https either.

> His main argument seems to be that the network operator should have control over DNS requests And why is that an unreasonable position for a network operator to hold?

The main argument should be that the OS controls what DNS is used.

The user of the OS can then set their own DNS. If applications just ignore this and use their own it takes away power from the user. Sure Firefox lets you turn it off, but a lot of people won’t bother.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#238

Post by topranks »

mike-cardwell wrote: post #25
josteink wrote: post #3

Earlier quoted context omitted.

After seeing every implementation of DoH giving a flying fuck about your actual network settings, I’ve decided it’s a technology I want nothing to do with. I’ve actually actively blocked DoH for the major providers on my router, by writing some custom iptables rules. Hopefully there will be a simple to use OpenWrt-package which you can install to do this automatically in the future.

Could you share those iptables rules please?

The real difficulty as time goes on is to update the list.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#239

Post by Spivak »

vetinari wrote: post #214
Spivak wrote: post #198

Earlier quoted context omitted.

"Network operators should be able to set DNS servers for client devices." "You can configure your router, a client device, to use whatever DNS server you want in defiance of your ISP, a network operator." Which one do you want?

If you configure your router, you are the network operator (of the network that the router handles). Mozilla or other app vendors are not. No dichotomy there.

The point is that your router is a client of your ISPs network and you're overriding the servers provided by DHCP to your router.

In a crazy world where internally Firefox ran a small IP network for each tab and routed traffic between them for IPC would it suddenly be okay for Firefox to override DNS? Why or why not?

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#240

Post by topranks »

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.
Post reply on HN