Mozilla’s DNS over HTTPs • Hacker News Board

Re: Mozilla’s DNS over HTTPs

#421

Post by nybble41 » Tue, Feb 25, 2020, 6:25 PM UTC

pbhjpbhj wrote: post #291

rndgermandude wrote: post #136

Earlier quoted context omitted.

>The elephant in the room is that many networks need to have content filtering First of all, we're talking about domain filtering, not content filtering. And no, they want domain filtering, hardly anybody needs it, and there are better solutions than NXDOMAIN, such as actual content filters. >and you are proposing nothing useful. Why would I need to provide "something useful"? mozilla already described the many ways…

I need domain filtering: if the domain serves malware I want to block it, not just the known malware coming from it. If a domain serves porn, I want to block it on my kids computers (and mine) not just the content that is recognisable as porn. If a domain is used by malware I want to block it, and probably use the domain to determine the server, and block that too (too because the domain can move IP).

All of that can be implemented on the client (e.g. as a browser extension) without breaking the Internet. That's the only reliable way to do it anyway. MITM DNS filtering is easily bypassed and only effective against lazy malware.

Re: Mozilla’s DNS over HTTPs

#422

Post by ignoramous » Tue, Feb 25, 2020, 6:28 PM UTC

Mister_Snuggles wrote: post #348

I have some unusual, from the normal browser user perspective, DNS stuff and this just leads to a bunch of questions. My gateway has a bunch of static DNS entries for internal hosts, which are all in a fake top-level domain. How will resolving these work if the request goes to CloudFlare? CloudFlare obviously doesn't know about my internal domain. Currently my gateway resolves what it knows about and uses my ISP's DN…

cloudflared, knot-resolver, stubby, unbound, CoreDNS can be run as DoH and/or DoT stub and/or recursive resolvers, locally.

The easiest stub resolver to setup would be nextdns' client: https://github.com/nextdns/nextdns

Re: Mozilla’s DNS over HTTPs

#423

Post by j0057 » Tue, Feb 25, 2020, 6:29 PM UTC

nullc wrote: post #289

I'm so sad to see Mozilla move forward with this massive attack on user privacy. Firefox DoH is snake oil, plain and simple. It sends all the users DNS queries to Cloudflare, adding a new party which can surveil the user's traffic (and can be legally compelled to do so and not disclose this fact)-- providing a convenient choke point to save spies and hackers the trouble and exposure of extracting the data from tens o…

SNI is not a good argument, there is work being done to encrypt that as well in TLS 1.3 with Encrypted SNI[1].

[1] https://blog.cloudflare.com/encrypted-sni/

Re: Mozilla’s DNS over HTTPs

#424

Post by ignoramous » Tue, Feb 25, 2020, 6:31 PM UTC

datenwolf wrote: post #416

raesene9 wrote: post #406

My feeling on this is that it's a pretty imperfect solution but unsurprising that the browser manufacturers are pushing it forward given ISPs dragging their heels on DoT. We saw the same problem with TLS. Until the browser makers started pushing it and Let's encrypt made it simple/free the take up of TLS was patchy at best. This will have negative effects on tools that use DNS for blocking/monitoring, but then those…

> ISPs dragging their heels on DoT WTH does DoT adoption by ISPs have to do with that?! One can run their own DNS recursive resolver-cache perfectly fine on their own hosts, or at the network edge, without relying on ISPs. Better yet: Since the Root zone and TLD zone DNS servers change only seldomly, you can prefetch and cache them locally just fine, and upon resolving a DNS skip two recursion steps. Apart from doing…

> WTH does DoT adoption by ISPs have to do with that?!

The ISPs need to support DoT server-side, at their end?

Re: Mozilla’s DNS over HTTPs

#425

Post by sp332 » Tue, Feb 25, 2020, 6:31 PM UTC

pbhjpbhj wrote: post #194

bepvte wrote: post #46

Earlier quoted context omitted.

DNS over TLS and DNSCrypt both depend on servers... exactly as centralized as DoH. They are just different wire protocols that in the end do the exact same thing with a centralized DNS server.

This service is available from 2 companies; this services is available from 200,000 .. See they're exactly as centralised!!!one Explain that to me?

DoH is just a protocol. DNS providers are adopting it as it is tested further and as it suits their needs or their customers'.

There are 40 publicly available servers listed on https://github.com/curl/curl/wiki/DNS-over-HTTPS from large and small players.

Re: Mozilla’s DNS over HTTPs

#426

Post by mooman219 » Tue, Feb 25, 2020, 6:31 PM UTC

ignoramous wrote: post #214

vetinari wrote: post #148

Earlier quoted context omitted.

Chrome uses opportunistic DoT - it uses your system configured resolver, and if it supports DoT, it will use DoT, if not, it will fall back to 53/udp. I like Chrome's approach much better; it doesn't force you to statically configure DNS server - it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks.

> ...it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks. Not really. If you're not blackholing traffic at the dns-layer via DoH, set Firefox's trr.mode to 2 . Per documentation, at the cost of additional latency incurred, system-level / network-level resolvers should pick up the slack, provided they've been set as appropriate via DHCP or otherwise. Ref: https://…

If I sit any family member down in front of this comment, their eyes would glaze over. Not only is what you mention a PITA, it's impossible for most people.

Re: Mozilla’s DNS over HTTPs

#427

Post by colanderman » Tue, Feb 25, 2020, 6:32 PM UTC

dmd wrote: post #360

How does this work with hosts that are not resolvable outside your own network? If I tell firefox to go to internalsite.mycompany.com - which resolves internally, but not outside our network - how is firefox going to resolve it, if it's not using our DNS servers?

I wonder why they don't simply check if the user's resolv.conf is configured to resolve via a private IP address, and not use DoH if that's the case.

Re: Mozilla’s DNS over HTTPs

#428

Post by nullc » Tue, Feb 25, 2020, 6:32 PM UTC

debaserab2 wrote: post #393

ThePhysicist wrote: post #362

Earlier quoted context omitted.

I trust my own DNS provider much more than I trust Cloudflare to be honest. Also, most DNS requests over that “insecure protocol” happened over a single network hop or two and never left the infrastructure of the ISP. Cloudflare is now a public company and they need to aggressively monetize their services. Selling browsing data is a lucrative business and becoming “the” DNS provider for most users (while locking out…

Is there an indication they are moving in that direction already? (Genuine non-sarcastic question) They've built up a considerable amount of good-will in developer communities. Is there some historical indicator with cloudfare that suggests they are going to blow it all on their path to monetization, or are we extrapolating from other VC backed companies (which may be an understandable position to take, but why?)

It's interesting how bubbles work.

In my world, everyone has a story about how an obscure but interesting to surveil service that they were involved with was DDOS attacked and immediately cloudflare sales was showing up offering to mitigate the attack for free by MITMing their traffic. ... Even showing up on the IRC channels of open source projects. I've personally witnessed it three times.

Even if it weren't for the fact that it would be gross incompetence if the NSA hadn't compromised cloudflare up, down, and sidewise since it's such an attractive target, the surveillance based sales-leads approach used by cloudflare has convinced a lot of people that they're engaging in a protection racket. Not just technies, either-- I've heard from executives who pay for cloudflare service that they think is a protection racket but they pay anyways because it's just a cost of doing business.

[I don't personally think it is, but I think that cloudflare is unethically creating a situation where some customers will believe this and pay as a result.]

It's such a lovely setup for a state attacker. Step 1. Compromise cloudflare (either by getting insiders into it, or by hacking them). Step 2. DDOS attack the thing you really want to monitor. Step 3. Cloudflare sales shows up and helps onboard the victim onto your borrowed surveillance platform.

People think that kind of stuff about AV companies, but at least AV companies aren't showing up within minutes of an attack saying "Gee, isn't it so terrible that you've got a virus. We've got a cure for that!". At least AV companies mostly don't send your data all back to their servers where god knows what happens to it.

Even where the problem is usually just a volumetric DDOS, the cloudflare standard solution is a full encryption unwrapping layer-7 MITM.

DoH without cloudflare would also gather complaint but the fact that the default centralized panoptiresolver is cloudflare contributes a lot to many people's discomfort.

So, I don't think cloudflare has amassed much goodwill at all, and that's even before getting into how their 'protection' made much of the internet unusable behind tor or other anonymization proxies.

Re: Mozilla’s DNS over HTTPs

#429

Post by jedieaston » Tue, Feb 25, 2020, 6:32 PM UTC

asymptotically2 wrote: post #389

Avamander wrote: post #276

Earlier quoted context omitted.

> How does Firefox deal with corporate installations and internal DNS? Everything is configurable and there are canaries to override that.

> Everything is configurable But how many people are going to change it from the default?

It is disabled by default in Firefox ESR and enterprise environments are already using GPO to manage it anyway.

Re: Mozilla’s DNS over HTTPs

#430

Post by ignoramous » Tue, Feb 25, 2020, 6:33 PM UTC

mooman219 wrote: post #426

ignoramous wrote: post #214

Earlier quoted context omitted.

> ...it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks. Not really. If you're not blackholing traffic at the dns-layer via DoH, set Firefox's trr.mode to 2 . Per documentation, at the cost of additional latency incurred, system-level / network-level resolvers should pick up the slack, provided they've been set as appropriate via DHCP or otherwise. Ref: https://…

If I sit any family member down in front of this comment, their eyes would glaze over. Not only is what you mention a PITA, it's impossible for most people.

AFAIK, when one turns on DoH, Firefox's trr.mode defaults to 2. And that's the default behaviour most would want except for the ones using pi-hole et al.