[HN Gopher] Mozilla rolls out DoH to Canadian users of Firefox
___________________________________________________________________
Mozilla rolls out DoH to Canadian users of Firefox
Author : tristor
Score : 163 points
Date : 2021-07-08 14:33 UTC (8 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| protomyth wrote:
| Is there an open source DoH resolver?
| tristor wrote:
| Unbound supports DoH since 1.12.0 released in 2020. [1]
|
| [1]: https://blog.apnic.net/2020/12/14/dns-over-https-in-
| unbound/
| protomyth wrote:
| Anyone know if NSD or Bind is going that way?
| betaby wrote:
| Mozilla is literally switching Canadian users to use government's
| (CIRA) DNS by default. Seriously, how that's a good thing?
| _verandaguy wrote:
| It's not quite that clear cut. CIRA is strictly speaking a
| public, not-for-profit company, but the DNS servers were built
| and maintained by CSE (our NSA) for the malicious domain
| filtering/reporting aspect, the Centre for Cybersecurity
| (another public service arm mandated with building out our
| domestic cybersecurity infrastructure), and Shared Services,
| the federal government's infrastructure backbone.
|
| I know many people will stop reading at CSE and draw their own
| conclusions, but like with every issue there's nuance here. CSE
| arguably draws some of the foremost information security
| experts in the country, and their mandate does also include
| protecting the digital security of Canadians. I'm going to be
| cautiously optimistic and start looking for transparency
| resources around Canadian Shield.
| Sunspark wrote:
| Misleading. "CIRA is providing the threat blocking technology
| while the CSE's Canadian Centre for Cyber Security is
| offering its threat intelligence services -- basically a
| who's-who list of every bad actor roaming the web."
|
| CIRA has 3 levels much like opendns, private, protected and
| family. My router has already been using private for awhile
| mainly because it was the fastest dns.
|
| The server for where I am located is hosted at a local ISP.
| If they were truly nefarious vacuuming up every dns request
| and providing a printout of my activity to the prime minister
| every morning they'd just host the server on their own
| network.
|
| If CSE built it themselves as alleged, they did a good job in
| terms of its performance and I trust the Canadian government
| more than I trust an ad company.
| betaby wrote:
| Good for your. Canadian government did a great job with the
| recent CRTC decisions, right?
| Sunspark wrote:
| Don't try to muddy the waters by conflating the
| regulatory board's pricing decision with nefarious spooks
| searching for Newfoundland independence videos in my
| history.
| betaby wrote:
| CRTC explicitly asked to evaluate CIRA DNS as a potential
| way to block content for Canadians
| https://crtc.gc.ca/eng/archive/2021/2021-9.htm
| Sunspark wrote:
| "15. While network-level blocking can be implemented
| without accessing the content of Internet transmissions,
| the Commission nevertheless considers that any regulatory
| framework for blocking or filtering traffic must include
| safeguards to ensure user interests are protected. Any
| framework the Commission approves will need to include,
| at a minimum, provisions that (i) ensure Internet
| subscriber privacy, (ii) enable subscribers to opt into
| or out of blocking, (iii) provide a false-positive
| correction mechanism, (iv) ensure blocking decisions are
| unbiased and made in the best interest of Canadians, and
| (v) minimize subscriber information monitoring,
| collection, and usage."
|
| In case of emergency, break glass and use VPN.
| _verandaguy wrote:
| Good callout, thanks for the correction.
| ryan29 wrote:
| > I trust the Canadian government more than I trust an ad
| company.
|
| Me too. However, since it's sort of the government running
| it, I wonder if they could ever implement ad blocking
| without getting sued by the ad companies.
| tristor wrote:
| Every member of the Mozilla TRR program has to abide by the TRR
| resolver policies, undergo regular audits to ensure compliance,
| publicly commit to these policies in their own privacy policy,
| and publish annual transparency reports. CIRA meets these
| requirements, which provide assurance that they are treating
| user data with respect. See
| https://wiki.mozilla.org/Security/DOH-resolver-policy for more
| information.
| dubcanada wrote:
| First of all, CIRA is not the government, it is an elected
| public company.
|
| Second of all, it is not switching to use CIRA's DNS, it is
| added CIRA DNS to their revolver so .ca domains get fed through
| Mozilla's DNS over HTTP, rather then going Mozilla DNS <->
| CIRA.
| betaby wrote:
| No? What does it even mean 'added CIRA DNS to their revolver
| so .ca domains get fed through Mozilla's DNS over HTTP'.
| Please explain in technical terms.
| dubcanada wrote:
| CIRA is a root domain company (like Verisign for .com), it
| has root records because it owns the root nameservers for
| all .ca domains. All they are doing is adding those to
| Mozilla's existing supply (Cloudflare provides other DNS
| records). So rather then going Mozilla -> Cloudflare ->
| CIRA and back, it now just goes Mozilla -> CIRA. I don't
| have time to explain how DNS works. Look up Mozilla's
| Trusted Recursive Resolver and how it works.
| betaby wrote:
| No. Mozilla changes is about recursor, not '.ca' domain.
| UseStrict wrote:
| CIRA isn't government owned or backed, it's a member-directed
| not-for-profit organization. The government doesn't have
| anything beyond a non-voting board seat.
| uniqueuid wrote:
| Chris Siebenmann has written extensively and early on what this
| means for organizations:
|
| https://utcc.utoronto.ca/~cks/space/blog/web/FirefoxDNSOverH...
| fulafel wrote:
| I wonder what's the attraction of split horizon dns especially
| at an academic institution. It seems it will obviously break
| stuff since all kinds of things rely on dns working as it was
| designed to, providing a global namespace.
| ryan29 wrote:
| I personally use split horizon DNS for my home lab. I have
| several things that I put behind Cloudflare, but I don't want
| my local access to go me > cloudflare > me, so I use split
| horizon DNS. If you're not behind something like Cloudflare
| you can use NAT reflection (hairpin NAT), but those are a bit
| of a hack.
|
| Canada also has some large, private networks used by
| provincial governments that use split horizon DNS and DoH is
| going to be a huge pain for them. One specific example would
| be libraries that are on a private network and have access to
| resources handled differently depending on how you connect;
| via the private network = no auth, but via the internet =
| auth required.
|
| Split horizon DNS is a simple, practical way of affecting how
| traffic is routed in a lot of cases.
| uniqueuid wrote:
| > Fortunately we already have a split-horizon DNS setup,
| because we long ago made the decision to have a private top
| level domain for all of our sandbox networks, so we use our
| existing DNS infrastructure to give BINAT'd machines
| different IP addresses in the internal and external views.
|
| https://utcc.utoronto.ca/~cks/space/blog/sysadmin/BinatAndSp.
| ..
| fulafel wrote:
| Thanks. It's interesting that after this account the
| characterisation "fortunately" is still used. But the
| motivations still give good perspective though i would have
| done things differently.
| seanhunter wrote:
| There are definitely large organizations who run split
| horizon DNS because back in the mists of time they made poor
| choices and assigned IP addresses that were in the public
| address namespace (ie not a 10. or 192.168.1. etc) that they
| didn't own randomly to a large number of legacy subnets
| within their network. It's now too painful to migrate them,
| so they are a wart that has to be lived with until they
| eventually retire.
|
| In the meantime they have to use split dns so they are able
| to keep things kinda working.
|
| I have personally worked at least a couple of large orgs that
| have this setup (ie 100s or 1000s of ancient devices on
| internal networks squatting on what are actually public IPs).
| tyingq wrote:
| It would be nice if Firefox supported some way to automatically
| rotate which backend provider it's using for DoH. This would keep
| any one entity from having a continuous feed of every DNS lookup.
| tristor wrote:
| That's an interesting idea. I wonder how you'd feel about this
| in relation to the trade-off against multiple resolver
| providers having information about your Internet traffic? By
| using a single provider, you limit your risk exposure, but also
| increase your reliance on that provider. So it's not clear-cut
| that this would necessarily be beneficial.
| rakoo wrote:
| It's actually a very good point, and Tor is explicitely using
| a single entry guard because of that: it was analyzed that
| keeping a single guard for a long time is "on average" better
| than regularly changing guards.
| tyingq wrote:
| That's a fair point. I think I would still be happier if no
| one entity had everything. But I do recognize the downside.
| moltar wrote:
| Great idea. Would a local load balancing proxy do the trick?
| vngzs wrote:
| Not with a TCP proxy. To establish a HTTPS tunnel, the client
| needs to know the identity of the remote end for certificate
| validation. Randomizing remote ends with a naive proxy would
| lead to TLS errors.
|
| So you'd likely configure your browser to do DoH destined for
| that proxy, and have the proxy generate DoH requests to the
| remote ends. The downside is you'd have to somewhat manually
| set up certificate trust between your client and your proxy -
| either by trusting the proxy's certificate, or installing a
| root CA that issues the proxy's certificate in your browser's
| trust store.
| jeroenhd wrote:
| I use my PiHole to do balancing like this. I've set it up
| with DoT and DoH so that DNS requests are spread across
| several servers.
|
| Then, I expose my PiHole as a DoT + DoH server (DoT for Linux
| and Android, DoH for Firefox) so that I can always use my ad
| block lists and secured DNS traffic.
| unethical_ban wrote:
| I don't understand.
|
| I have a PiHole, and have the cloudflare DoH client
| installed on it.
|
| Requests from my network go to the PiHole, and the PiHole
| is set to query localhost:5053, which then hits a DoH
| provider.
|
| Why do you have separate setups for mobile vs. desktop web
| browser, why not have the OS do native DNS to your PiHole?
| jeroenhd wrote:
| When I'm on my laptop, in the train, working on Windows,
| I can't use my home DNS without exposing it to the world
| and becoming part of every DDoS attack there is. So, for
| those situations, I've got Firefox set up to do DoH.
| Windows can do some DNS encryption through a complex
| setup of local DNS servers but it's nothing as easy as
| the standard Linux setup.
|
| Similarly, I use DoT on my phone but if I want to connect
| to any hotspot, I have to disable DoT because the hotspot
| login detection fails with DoT configured. I think it's a
| Xiaomi thing. Regardless, I need to disable it to use. In
| one particular case (scanning groceries in the
| supermarket for the automated payout) I can't fall back
| to LTE like usual. Just in case I forget to turn DoT back
| on, I've also configured Firefox on my phone to use DoH
| because the mechanism is there and I might as well.
|
| There's small edge cases where I just like to fall back
| to browser DoH. DoT and I'm network DNS still works fine,
| of course.
| Thiez wrote:
| Doesn't this just result in _more_ organizations having
| your data? Presumably most DNS entries have some finite
| TTL, such as a few minutes / hours / days. Let's say one
| of your favorite websites has a TTL of 10 hours, and you
| visit this website once per day. Then eventually (soon!)
| you will have asked most or all of your servers for that
| domain, so now they _all_ have your data. Or do you have
| your PiHole configured that it always asks the same server
| for the same domain?
| 3np wrote:
| You could share the namespaces using some consistent
| hashing so any given domain would hit the same server.
|
| Maybe something exists for that already?
| jeroenhd wrote:
| You're right that this is the case. I set it up so that I
| can use the double encryption system with a DoH proxy
| when I eventually resolve this issue. In practice, 60% is
| my traffic ends up at cloudflare already, so I might as
| well use their DNS until then.
|
| It's also an availability thing. There's that one archive
| website on a vendetta against cloudflare for not
| forwarding enough data in DNS requests (eDNS or
| something?) that I can access by using alternative
| servers as well. In the rare case of a cloudflare outage,
| this also ensures uptime.
|
| DNS cannot be made fully anonymous, though that double
| encrypted DoH thing seems promising. Picking a few
| trusted providers isn't a problem for me personally.
| np-tokumei wrote:
| Distributing DNS queries across several resolvers is a good
| idea to make sure there's no single resolver would be able to
| learn the entire browsing history of a user. However, this
| distribution algorithm should be designed with care because
| distributing queries in a random or round-robin manner would
| lead to even worse privacy since every resolver will eventually
| learn the entire browsing history of the user.
|
| We have conducted some preliminary work on this idea and shared
| it with the team at Firefox, but I guess the current number of
| Trusted Recursive Resolvers is not large enough. However, I do
| believe that once Firefox have more than a dozen TRRs, (or if
| Firefox allows users to input more than just one customized DoH
| resolver), our proposed K-resolver resolution mechanism would
| help to increase the privacy benefit of DoH even further.
|
| "K-resolver: Towards Decentralizing Encrypted DNS Resolution"
|
| https://www.ndss-symposium.org/wp-content/uploads/2020/02/23...
| goodpoint wrote:
| Rotating between a handful of providers could be a net negative
| for privacy:
|
| - every FQDNs you resolve is leaked to at least one provider
|
| - the FQDNs you resolve often (e.g. every day) are leaked to at
| all the backend providers over time
|
| If you want to protect your privacy you need DNS resolution
| over Tor.
| JoshTriplett wrote:
| While I agree that rotating might be a net negative, that
| particular issue could be worked around: hash the FQDN and
| use the hash to determine which provider you use, so that a
| given user always resolves a given FQDN with the same
| provider. (Salt the hash, so that different users use
| different providers for that FQDN.)
|
| It's still not clear if it's a win to rotate, but if you were
| going to rotate, that would help.
| goodpoint wrote:
| That's not rotation, by definition.
|
| (and hardly beneficial for privacy: you just divided the
| FQDNs you leak across 3-4 providers)
| JoshTriplett wrote:
| The only advantage would be in reducing the ability to
| correlate a user's sites.
|
| But nonetheless, I agree.
| justusthane wrote:
| As a sysadmin for an organization with our own internal DNS
| servers that clients need to hit, how will this impact us? Do I
| need to deploy a GPO to disable DoH in order to force FF to keep
| using our DNS servers?
| gnabgib wrote:
| There's a windows GPO key[0] and a canary domain[1] you can
| NXDOMAIN (use-application-dns.net). Both of these only control
| the default (it won't override a user personally choosing the
| setting).
|
| [0]: https://github.com/mozilla/policy-
| templates/blob/master/READ...
|
| [1]: https://support.mozilla.org/en-US/kb/canary-domain-use-
| appli...
| pbhjpbhj wrote:
| Ah, so users can choose to override the local network
| administration? I didn't realise that. No way to prevent my
| family browsing to undesirable and unsafe sites without
| personally admin-ing each device and/or directly monitoring
| use?
|
| I realise this is currently all leaky, my attitude was to put
| controls in place (DNS based) and if they learnt to hack
| around it then they're probably old enough to handle what
| they find ... doesn't work for malware, etc., however.
|
| Presumably enabling DoH makes malware, advertising, etc.,
| impossible to block?
|
| When is MS Windows going to use DoH to force access for
| monitoring, currently I block a few domains.
| Xylakant wrote:
| > When is MS Windows going to use DoH to force access for
| monitoring, currently I block a few domains.
|
| Microsoft doesn't need DoH to circumvent DNS-based
| blocking. They control the OS and can make it do anything.
| josephcsible wrote:
| > No way to prevent my family browsing to undesirable and
| unsafe sites without personally admin-ing each device
|
| No there's not, for good reason. From a technical
| perspective, this is indistinguishable from an abusive
| spouse or oppressive government trying to block sites.
| tomjen3 wrote:
| I hope by family you mean your children? Because otherwise
| this feature is very much designed to you and what you do.
| shawnz wrote:
| > Ah, so users can choose to override the local network
| administration? ... Presumably enabling DoH makes malware,
| advertising, etc., impossible to block?
|
| It was always trivially possible to bypass DNS-based access
| control. Even before the establishment of DoH as a
| standard, you could have just served a text file containing
| the IP over HTTPS.
| josephcsible wrote:
| Do you use split-horizon DNS, or do all of your internal
| domains fail to resolve externally? If the former, then add
| your organization's domains to network.trr.excluded-domains. If
| the latter, everything will still work without you needing to
| do anything.
| chaz6 wrote:
| This is answered in the FAQ at https://support.mozilla.org/en-
| US/kb/dns-over-https-doh-faqs...
| justusthane wrote:
| Ah, thank you.
| tremon wrote:
| You will want to employ DPI anyway, to make sure no other
| apps/devices on your network subvert your internal security.
| DoH is just another signature to detect and block.
| shawnz wrote:
| It will automatically fall back to the internal DNS for names
| that don't resolve externally, so you might not need to do
| anything
| ocdtrekkie wrote:
| I recommend using Firefox's GPOs anyways: Not just to ensure
| users can't override disabling DoH, but also to turn off
| arbitrary extension install (a major malware vector) and other
| protocols designed to circumvent security inspection like QUIC.
|
| If you operate any network security appliances of any kind,
| browsers are basically built-by-default now to circumvent them,
| so you need to be configuring them heavily via group policy.
|
| Firefox, Chrome, and Edge all offer ADMX templates to add
| support for their policies pretty much drop-in to Active
| Directory.
| hulitu wrote:
| They force DoH in the name of freedom. What will be the DoH
| resolver ? Cloudfare ? Google ? One must use GP to disable this
| on Win or a DNS server on linux Everyday the reasons to keep
| firefox are converging to 0.
| admax88q wrote:
| > They force TLS in the name of freedom. Who will be the
| certificate provider? VeriSign? Comodo? One must use
| certificate manager or their own certificate server on linux.
| Everyday the reasons to keep firefox are converging to 0.
| FranchuFranchu wrote:
| > They force package managers in the name of freedom. Who
| will be the server? Canonical? RedHat? One must use wget,
| tar, and gcc on linux. Everyday the reasons to keep GNU/Linux
| are converging to 0.
| woogley wrote:
| DoH is configurable with GP or just a policies.json file if you
| want: https://github.com/mozilla/policy-
| templates/blob/master/READ...
| csunbird wrote:
| GP is a bit obscure, I was hoping that we can simply use
| Firefox preferences to point at another provider.
| woogley wrote:
| You can set custom provider in the settings UI:
| https://support.mozilla.org/en-US/kb/firefox-dns-over-
| https#...
| yjftsjthsd-h wrote:
| You can: Settings > General > Network Settings >
| Settings... > Enable DNS over HTTPS > Use Provider > Custom
| csunbird wrote:
| How hard would it be to run a private DoH server? (This is a
| serious question, not a snarky comment)
| kd913 wrote:
| I run it on my pihole with Dnscryptproxy.
|
| https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Local-DoH
|
| It isn't too hard.
| cuillevel3 wrote:
| Easy: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clie
| nts#D...
|
| I want to add, that you can't run your own public DNS server
| nowadays, because it can be misused for DOS and hosting
| providers scan for open DNS servers.
|
| So if you want your own public DNS resolver, DOH is much
| easier.
| csunbird wrote:
| > because it can be misused for DOS and hosting providers
| scan for open DNS servers
|
| Can you elaborate? I am thinking of doing exactly that, in
| case of need.
| lights0123 wrote:
| https://blog.cloudflare.com/deep-inside-a-dns-
| amplification-...
| csunbird wrote:
| Very, very interesting... I forgot the fact that ip
| addresses can be spoofed in the UDP packets, essentially
| making DNS resolvers to carry out the attack for botnets.
| vengefulduck wrote:
| DNS servers can be used in an DOS amplification attack by
| sending requests with spoofed ip addresses. So if you
| don't take measures to prevent this it's likely your
| server will be used in DOS attacks.
|
| https://us-cert.cisa.gov/ncas/alerts/TA13-088A
| cuillevel3 wrote:
| You could try to run an IPv6 only DNS server, harder to
| find.
| outloudvi wrote:
| One reason is that DNS is UDP based, on which source IP
| spoofing is possible.
| [deleted]
| roody15 wrote:
| Terrible decision IMO. To default to application level DNS that
| then defaults to a large centralized DNS provider is the opposite
| of supporting an open and decentralized internet.
|
| This should be an optional feature that is Opt in. Instead a
| quick banner appears when you start Firefox and if you don't
| quickly hit disable ... it enables this by default.
|
| disappointing behavior by Mozilla
| 542458 wrote:
| I'm not sure how this is significantly worse than the DNS
| status quo despite being more centralized.
|
| Traditional DNS is very easy for everybody and anybody to snoop
| and tamper with, including your ISP, the government, the
| resolver and anybody else with a chunk of network
| infrastructure on your path. DoH is very hard for anybody but
| the resolver to snoop or tamper with. The resolvers commit to
| not selling data and not retaining logs for more than 24h. Of
| course a court order will take precedence, but we've gone from
| "anybody who cares can see and tamper with your DNS queries" to
| "just your resolver can see and tamper with your DNS queries,
| and they're audited so that'll probably only happen under court
| order".
|
| All else held equal the increased centralization would make DoH
| a step backwards - but all else isn't held equal, and
| traditional DNS is such a bad protocol that most of the
| advantages of its decentralization don't actually manifest. And
| it's not like the DNS protocol weaknesses are hypothetical -
| they're used en masse by regimes and corporations around the
| world. With that in mind, I'd say default-on is a reasonable
| decision.
| josephcsible wrote:
| DNS is heavily abused by network operators for censorship and
| surveillance purposes. IMO, a slightly more centralized
| Internet is a good tradeoff to make that impossible. And if the
| current DoH provider ever does abuse their position, it'd be
| easy for Mozilla to switch to a new provider.
| netr0ute wrote:
| What happens if the DoH servers are blocked? I do this at home to
| stop any client from bypassing PiHole and if FF isn't smart
| enough to consider this scenario, then that's bad.
| sodality2 wrote:
| I'd hope your PiHole at least resolves over DoH... if not
| consider AdGuard Home instead
| netr0ute wrote:
| It's not the PiHole itself that's the problem, but rather the
| clients on the LAN. I already redirect the PiHole's traffic
| over a VPN so the ISP is none the wiser, but I could go
| further and use DoH for that too.
| tristor wrote:
| PiHole uses the DoH canary domain by default, so if you use
| PiHole it should just work without any effort on your part, and
| effectively disables DoH network wide. You can search how to
| encrypt the lookups that PiHole makes itself, a common scenario
| is to install cloudflared on the PiHole and point it at
| localhost, which you can see here:
| https://nathancatania.com/posts/pihole-dns-doh/
| Y_Y wrote:
| Even if you specify them by IP? I specifically redirect
| addresses like 8.8.8.8 to my pihole (at the router) to
| prevent cheeky applications circumventing it.
| tristor wrote:
| I'm not certain, but I believe that would still work,
| because the lookup for the canary domain is done using the
| local resolver and if you are redirecting its configuration
| to your PiHole, the PiHole would respond. It sounds like
| you have a relatively unique network configuration, so I'd
| advise that you test this and share the results with all of
| us.
| zinekeller wrote:
| Not OP, but yes, it should work (as long as you're
| talking plain DNS on port 53. Direct DoH, you're out of
| luck unless you want to DPI or block IPs (and if it's
| Cloudflare, it's block all of Cloudflare or allow their
| DoH version of 1.1.1.1).
| zinekeller wrote:
| It'll still work, check if use-application-dns.net returns
| NXDOMAIN.
| roody15 wrote:
| It fallbacks to local DNS
| netr0ute wrote:
| This is the kind of answer I needed.
| rany_ wrote:
| Firefox checks if use-application-dns.net is blocked, if it
| finds that it isn't blocked it ends up trying to use DoH.
|
| https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
| admax88q wrote:
| There's a lot of lament that this bypasses the operating system
| level config, but I feel like we wouldn't be here if the
| operating system had stepped up their DNS any time in the last
| several years.
|
| This is a workaround for the fact that many networks are hostile
| to DNS lookups (injecting ads, tracking, captive portals), and
| operating systems continue to just default to the ISPs DNS
| provider, which is often hostile.
|
| OS's could have switched to running their own local caching
| resolver ala unbound years ago, could have integrated DNSCrypt or
| DoT years ago. But instead the defaults are still horribly
| unsecure for the average user.
|
| For the techie user who's running PiHole or some custom local
| DNS, yeah this will be annoying, but for the average user who's
| just delegating to their ISP that is then tracking their DNS
| lookups and injecting ads if they mistype a domain, this is a
| win.
| slim wrote:
| Mozilla wants to be the gatekeeper to their users. Every
| company and it's dog wants to do this. "If you are not paying
| for the product, you are the product" should become "if you are
| a customer/user, you are also a product".
| ignoramous wrote:
| > _There 's a lot of lament that this bypasses the operating
| system level config, but I feel like we wouldn't be here if the
| operating system had stepped up their DNS any time in the last
| several years._
|
| OSes are relegated to support myriad environments with adhoc
| yet byzantine configuration. A browser's primary objective is
| to be a "user-agent" (as opposed to, say, subscribing to the
| whims of ISPs / Governments / anti-digital-rights-companies-
| masking-as-cyber-security-firms).
|
| > _For the techie user who 's running PiHole or some custom
| local DNS, yeah this will be annoying, but for the average user
| who's just delegating to their ISP that is then tracking their
| DNS lookups and injecting ads if they mistype a domain, this is
| a win._
|
| Internet censorship, which most of the population in the West
| isn't subject to or even aware of, is the primary reason DoH-
| in-a-browser is widely lauded. It just works, and thwarts all
| cheaper attempts at surveillance and censorship. Though, the
| likely effect would be, deep-packet-inspection becomes common
| place, but the imminent ESNI standard has that one covered,
| too.
|
| As someone who builds and maintains an open-source DoH
| resolver, I have come to fully appreciate the control and power
| a resolver running over HTTP/S puts in the hands of the users,
| both in the client and on the resolver-side.
| Hizonner wrote:
| > the imminent ESNI standard has that one covered, too.
|
| Too slow, I'm afraid. Word on the street is that any hello
| containing ESNI will be blocked from day one in too many
| places for it to ever get traction, including all of China. I
| believe draft ESNI is blocked by the GFOC _today_.
|
| To even have a chance of making ESNI/ECH widespread, you'd
| have to make it mandatory for all TLS. That wouldn't fly
| politically in the working group, because the "enterprise"
| people have at least some influence there, and they want to
| do exactly the same kinds of DPI that North Korea would want
| to do. Even if it came out mandatory on the standards track,
| it would probably _still_ fail at this point.
|
| It might have worked if it'd been mandatory in TLS 1.2 or
| even TLS 1.3, but it seems too late now.
|
| We'll see if they also disrupt DoH to the point of making it
| unusable. I bet they at least give it a try.
| Hizonner wrote:
| If Mozilla cared about _preventing_ DNS tampering, they could
| have done DNSSEC 10 years ago. That would have totally killed
| ads, ISP typosquatting, and captive portals. They, like all
| browsers, rejected that source of end-to-end security.
|
| The fact is that they want to _enable_ DNS tampering, because
| they want to use it as a way of enforcing their idea of
| "safety". So they're building this giant, highly centralized,
| and easily pressured, infrastructure of "trusted resolvers"
| that can mess with your DNS results to their heart's content.
| This will, of course, be a huge attractant for bad actors who
| want to do things even more harmful than injecting obnoxious
| advertizing.
|
| As for privacy, the only way that can work, even with something
| like DNSCrypt, is if the _individual user_ chooses the resolver
| from among a _very large set_ of possibilities.. which Mozilla
| is not enabling. Either that, or relatively exotic
| anonymization stuff that 's not actually worked out, and that
| Mozilla has shown zero interest in working out. "Trusted
| resolvers" just move the privacy problem to a different place,
| and, again, it's a highly centralized place that's easy to
| subvert.
|
| And DNS-over-TCP is desirable for sure, but it does nothing
| about tampering _or_ privacy. It 's just irrelevant, except
| maybe as a preliminary step making it easier to deploy some of
| the stuff that might actually help.
| kadoban wrote:
| How could Mozilla have "done" DNSSEC 10 years ago? Isn't that
| pretty much just not in their control?
| Hizonner wrote:
| If TLDs are signed (which they have been for a long time),
| and if the browser checks DNSSEC, you can't typosquat,
| because you can't spoof the TLD server's signature on the
| typo. That requires no cooperation from anybody but the
| browser and the TLD.
|
| WIth DNSSEC enabled, somebody can still impersonate an
| unsigned domain, but the whole reason that there are so
| many unsigned zones _to begin with_ is that nothing checks
| the signatures, so there 's no incentive to sign. By
| actually doing the checks, browsers, including Firefox,
| could have created an incentive for widespread DNSSEC
| signing.
|
| So they could have both unilaterally gotten a lot of
| benefit for their users, _and_ encouraged wider DNSSEC
| deployment that would have produced further benefit.
|
| Add in DANE, and it would also have given a much more
| satisfying fix for a bunch of CA issues that they've chosen
| to band-aid with stuff that only half works. You could
| probably even have gotten to a world with zero-cost TLS
| certs well before enough pressure built up to make Lets
| Encrypt come along.
| kadoban wrote:
| Interesting, thank you. That does sound more satisfying
| as a fix (though also sounds harder and possibly riskier.
| If they're the only ones checking, will some sites be
| broken only in Firefox?)
| tialaramex wrote:
| One of the reasons Mozilla couldn't "do" DNSSEC 10 years ago
| over plaintext DNS is that for some (enough) clients this
| doesn't work. Their DNS is broken, it was always broken, but
| so long as you only ever ask something easy like
| "news.ycombinator.com A?" it worked well enough. Asking
| DNSSEC queries doesn't work. "Last Change Broke It" rules
| apply so Mozilla gets the blame.
|
| With DoH of course this is much less relevant. The people
| operating Trusted Resolvers for DoH are obliged to actually
| implement the protocol correctly.
|
| If you choose a DoH provider which does DNSSEC for you (such
| as Cloudflare's 1.1.1.1), and you trust that provider, your
| answers are DNSSEC validated, today, without any changes to
| Firefox. Millions of people benefit, zero work.
|
| If you're concerned that Trusted Resolvers aren't enough
| privacy, Oblivious DoH eventually means that the TRs don't
| see your query any more, so the people answering the query
| don't know who you are, and people who know who you are don't
| know what your query is.
| Hizonner wrote:
| I'll bet a comparable number of clients won't be able to
| reach DoH servers for one reason or another. Especially
| because there seem to be people who are going to actively
| try to block them. Whenever you change anything, something
| will break.
|
| And it would have been relatively easy to put up a notice
| that said "your DNS server seems to be dropping all EDNS0
| data or whatever stupid thing it's doing; would you like to
| switch servers"? Which would have avoided centralizing
| _everybody_ by _default_.
|
| I know there were enterprise firewalls that broke DNSSEC on
| any packet that went through them... but frankly the
| sellers of those firewalls deserved to get heat, and any
| enterprise that would _deploy_ that kind of broken crap isn
| 't an organization I'd want to support as user.
|
| And that _still_ doesn 't justify putting DNS on top of
| _HTTP_ of all things. But that 's another story.
|
| As for Cloudflare doing DNSSEC checks, the fact that I
| shouldn't be trusting Cloudflare to do the validation for
| me is kind of the point. Validation (final validation, at
| least) belongs in the endpoint.
|
| If "oblivious DoH" is what it sounds like, it sounds like
| maybe I have to retract "zero interest in exotic
| anonymity". Which I am very happy to have to do.
| floatingatoll wrote:
| Release (not beta) macOS already lets you configure your system
| to use DNS-over-HTTPS, if you know the magic incantation to
| chant at it. Apple hasn't added UI for it _yet_ , but it's
| available and works when enabled.
| throw0101a wrote:
| > _This is a workaround for the fact that many networks are
| hostile to DNS lookups (injecting ads, tracking, captive
| portals), and operating systems continue to just default to the
| ISPs DNS provider, which is often hostile._
|
| This _workaround_ is hostile to _my own_ network (home or work)
| being able to track requests. I control my router / DCHP
| server, and I should be able to tell devices where to send DNS
| requests.
|
| Anything that does not do what I tell it to do is malware IMHO.
| elric wrote:
| So the fact that some ISPs are apparently untrustworthy is
| enough to blow up the whole thing which has worked pretty well
| for the past 30 years?
|
| There are plenty of valid use cases for captive portals. But
| yes, injecting ads and tracking are obviously messed up, but
| DNS is only a tiny part of that problem, and I don't see how
| using DoH will help with them. If you want to get rid those,
| then get rid of shitty ISPs. This is throwing out the baby with
| the bathwater.
|
| This will simply lead to ISPs and network operators blocking
| DoH. And instead of a wonderfully decentralized DNS, we'll end
| up with centralized DoH in the hands of Cloudflare and their
| ilk. Who have been shown repeatedly to be user hostile;
| especially towards privacy conscious users.
| kadoban wrote:
| Can they block DoH, with reasonable tradeoffs? How?
|
| And will they care enough? I get the sense that they don't
| really gain that much from messing with DNS, relatively.
| Hizonner wrote:
| They couldn't necessarily block _all_ DoH, but they could
| destroy its prevalence by just blocking all of the default
| resolvers and all of the resolvers that the browsers
| suggest to users. Those are public lists.
|
| I suspect you're right that they don't get that much value
| from messing with DNS, though... not enough to deal with
| the user complaints they'd get. So they probably wouldn't
| bother unless pressured.
|
| However, they _might_ decide to "play chicken" with
| Mozilla and other sources of DoH apps by seeing who yielded
| to the user complaints _first_. There 'd be a big
| temptation for Mozilla to fall back to "regular" DNS if DoH
| failed, and then the ISP would effectively win.
| kadoban wrote:
| They'd have to block by domain name, right, and block all
| HTTPS traffic to those domains? I somehow suspect that
| browers can win that particular cat and mouse game just
| by making the domains too important to block (share the
| domain with something users care about). Maybe I'm
| missing something there though, it probably is more
| complicated than just that.
| Hizonner wrote:
| In the end, DoH has to either start with some kind of
| seed IP address, even if it's a cache-priming DNS A
| record, or use a (presumably attackable) _non-DoH_ lookup
| to find its server. You can 't start with a domain name
| for the server that you use to resolve _all_ domain
| names.
|
| But I don't think that's very important, because domain
| names always resolve to IP addresses anyhow, and you
| can't change the IP addresses _that_ fast.
|
| So you would have to share an _IP address_ with something
| "too important to block". The political problem with
| _that_ tends to be that the operators of things that
| might be too important to block tend to think that those
| things are too important to expose to any _risk_ of being
| blocked, say by sharing them with something that somebody
| might _want_ to block.
|
| It's also not always administratively or technically
| trivial to share the domain name _or_ IP address(es) of
| some giant public Web service with another fundamentally
| unrelated service like DoH.
|
| I mean, sure, in the end, if enough large organizations
| tried hard enough, they could eventually come up with
| ways to make it pretty painful to block... but those
| large organizations tend to have overriding commercial
| concerns... and not to want to overtly taunt large
| governments...
| syoc wrote:
| The "some ISPs" is really important here.
|
| This is very much a US thing, I don't know as much about the
| situation in Canada, might be as bad. I really hope that this
| is not the begging of a roll out to the rest of the world.
| qmarchi wrote:
| > If you want to get rid those, then get rid of shitty ISPs.
|
| Good luck, when 30M+ only have DSL as an option, and >70%
| only have one Cable provider, and one DSL provider.
|
| FCC Data: https://broadbandmap.fcc.gov/#/area-
| comparison?version=jun20...
|
| More Info: https://www.theverge.com/22177154/us-internet-
| speed-maps-com...
| Animats wrote:
| _So the fact that some ISPs are apparently untrustworthy is
| enough to blow up the whole thing which has worked pretty
| well for the past 30 years?_
|
| Right. In place of that, we get one central point of DNS
| censorship. Where any unapproved site can be made to
| disappear.
|
| "CIRA Canadian Shield" "Truly free". Right. "Freedom is
| Slavery" is more like it. In the US, Mozilla is apparently
| putting users under the thumb of Cloudflare.[1]
|
| I'd rather have a mode where regular DNS and centrally
| controlled DNS are compared, and you get a popup if they
| differ. That warns you of censorship attempts. But that
| doesn't seem to be an option.
|
| [1] https://forum.netgate.com/topic/133679/heads-up-be-aware-
| of-...
| nimbius wrote:
| >There's a lot of lament that this bypasses the operating
| system level config
|
| systemd-resolved has the clandestine ability to forward all
| your DNS traffic to google in many distributions of Linux. I
| would say the state of resolution in general is getting
| uncomfortably sketchy.
|
| many wireless routers from Asus and others due to a buggy (or
| perhaps intentional) implementation of Dnsmasq will quietly
| intercept your DNS requests using their own built-in resolver.
| RT-ARCH13 is notorious for it even if NAT mode is disabled.
|
| for my pihole implementation I block 53 outbound and do DoH
| resolution using cloudflared on the pi.
|
| finally it bears remembering that the number one largest
| opposition to the use of DoH was ISP's who were (and still are)
| making a killing selling your search history. they went so far
| as to lobby congress to stop DoH. Now the very same ISP's we
| tried to protect users from are part of the DoH club anyway
| because, well, money talks.
|
| https://arstechnica.com/tech-policy/2020/06/comcast-mozilla-...
| danudey wrote:
| I recently tried setting up microk8s, since Ubuntu was
| pushing it pretty hard and it seemed useful, but a lot of
| stuff wouldn't work at all.
|
| Turns out that the microk8s config uses cloudflare DNS by
| default, and not your currently configured DNS or any kind of
| local DNS proxy. This was hugely frustrating because it's not
| the configuration that I would expect, it's not obvious why
| things are failing, and, in our case, it's sending internal
| DNS names to an external DNS server, unencrypted, over the
| public internet.
|
| Surely it's convenient, but definitely not trustworthy.
| TurningCanadian wrote:
| I didn't realize that Fedora dropped that proposal
| https://pagure.io/fesco/issue/1511
|
| May have been related to IPv6? Not sure.
|
| I remember trying it out at the time (https://fedoraproject.org
| /wiki/Changes/Default_Local_DNS_Res...) and not running in to
| issues
| vbezhenar wrote:
| How OS is going to circumvent local DNS? Hardcode 1.1.1.1? It's
| very easy for ISP to block this address.
| rank0 wrote:
| I'm not sure how I feel about DoH. It seems like there a ton of
| unnecessary overhead added by placing the super lightweight DNS
| protocol on top of HTTP. My initial reaction is also that I might
| lose some control over my network and which domains hosts query
| on my network. Are things like DNS sinkholes and domain
| blacklisting still possible with DoH?
| outloudvi wrote:
| > Are things like DNS sinkholes and domain blacklisting still
| possible with DoH?
|
| Surely they are... but the guy might not be your ISP but
| Cloudflare.
|
| EDIT: In Canada that would be that so-called CIRA (by default).
| But you always have control who can pollute your DNS, right?
| outloudvi wrote:
| Oh, as an addition, the one that really protects you from
| fake DNS records is DNSSEC (given you have trust on ICANN or
| so).
| tialaramex wrote:
| You don't get to control what _my_ devices do just because you
| control a network they 're transiting through. Even if DoH had
| never been standardised, clearly _my_ devices can do this
| anyway.
|
| On the other hand, if you actually control _your_ devices DoH
| shouldn 't be a problem, you can have them talk to whichever
| servers you prefer regardless of the protocol.
|
| As to the lightweight thing. We get a few benefits from running
| DNS on top of HTTPS rather than say TLS (which also exists, as
| DoT)
|
| 1. HTTPS allows us to put parameters in the URL which are thus
| confidential (HTTPS will encrypt them) and have those control
| the DNS lookup. So dns-server.example can offer all its users
| their own URL, even though they all talk to the exact same
| server (dns-server.example.com) and a snoop can't tell that one
| device used the rank0 account while another device used the
| tialaramex account, those are encrypted in the URL, yet the
| actual server can see which is used and maybe my devices get
| "pure" answers while yours have ad-blocking or whatever.
|
| 2. DNS doesn't have a rich error vocabulary. For your ad-
| blocked domains, a traditional DNS server has to either lie
| (bogus answer) or claim no answer exists (NXDOMAIN or OK 0
| answers) but HTTP has a rich variety of error codes. Maybe 403
| Forbidden is appropriate for the Xian parent who doesn't want
| their teenager looking at pornhub.com and 451 Unavailable For
| Legal Reasons is appropriate for a DNS service which excludes
| Pirate Bay due to lawsuits.
| iso1210 wrote:
| You want to use _my_ network you live by my rules. You don 't
| have to connect to it.
| akersten wrote:
| > You don't get to control what my devices do just because
| you control a network they're transiting through.
|
| And if I run a guest wifi in one of the many countries where
| I have legal obligations to take steps to block illegal
| traffic because I am ultimately responsible for the emissions
| of my network, what would you suggest I do?
|
| > DNS doesn't have a rich error vocabulary. For your ad-
| blocked domains, a traditional DNS server has to either lie
| (bogus answer) or claim no answer exists (NXDOMAIN or OK 0
| answers) but HTTP has a rich variety of error codes.
|
| It's a good thing that DNS has a limited vocabulary of error
| codes. I want the garbage website to think it couldn't load
| the ad because of a mysterious DNS issue. Having a reason
| like "DNSHTTP 486: Blocked by Client" would just make it that
| much easier for the site to deny you access/track you/detect
| your blocking activity.
| tialaramex wrote:
| As with steps someone might have a legal obligation to take
| to prevent people from thinking negative things about the
| King or to prevent six from being an even number, you
| should do whatever you feel is appropriate. It might even
| make a difference. Perhaps you could put up a notice which
| says "I run guest WiFi here and I have legal obligations to
| block illegal traffic so, don't do anything illegal".
|
| It's certainly weird to insist it's everybody's else's
| problem that you're subject to legal obligations that may
| be impossible to fulfil.
|
| If the purpose of this "obligation" is to ensure nobody is
| technically compliant and so they can arrest, imprison or
| even execute whoever they want, it doesn't seem like that's
| my fault, or Mozilla's fault, or any of the authors and
| acknowledged contributors for RFC 8484. Any more than it's
| Giuseppe Peano's fault that six is even.
|
| And if (as seems most likely) they're just covering their
| backside, the notice is probably sufficient.
| stinkytaco wrote:
| > And if I run a guest wifi in one of the many countries
| where I have legal obligations to take steps to block
| illegal traffic because I am ultimately responsible for the
| emissions of my network, what would you suggest I do?
|
| This is an oft overlooked part of these discussions. I
| manage a public network at a library (which is still the
| only access point for many people, unfortunately). DNS
| blacklisting certainly isn't the only tool in the toolkit,
| but it is one that DoH takes out. I'm genuinely conflicted
| on DoH because on one hand, I am a privacy advocate, but on
| the other I run a public network and that comes with
| certain obligations, both legal (we need to block
| filesharing) and to customers (we do traffic shaping
| because the budget it limited and bandwidth isn't cheap).
| dogecoinbase wrote:
| _You_ are not in control of _your_ devices. Your television
| will use this technology to report what shows you're watching
| to the company that manufactured it; the web browser running
| on your computer will use this technology to report your
| activity and retrieve advertisements even if you've tried to
| block them elsewhere.
| iso1210 wrote:
| It amazes me how people think the worlds largest
| advertising company is pushing DoH out of alturism. That
| pihole you're running? That 'steals' money from google. DOH
| gets rid of that.
| throw0101a wrote:
| > _On the other hand, if you actually control your devices
| DoH shouldn 't be a problem, you can have them talk to
| whichever servers you prefer regardless of the protocol._
|
| I already do tell the devices I control which DNS servers to
| use via DCHP and IPv6 RA. Firefox is choosing to ignore that
| by default, and now I have to go through extra steps to solve
| a problem that Mozilla created by not simply re-using the
| previous solution ( _gethostbyname(3)_ ).
|
| At the very least if they had simply used the already
| existing DoT, instead of inventing a new protocol (DoH), I
| could have monitored port 953 traffic and see which devices
| were broken. Now I have to figure out devices trying to sneak
| through my policies.
| luto wrote:
| > Are things like DNS sinkholes and domain blacklisting still
| possible with DoH?
|
| they aren't, which is part of the reason DoH is implemented in
| the first place.
| LinuxBender wrote:
| Still possible. The control moves from your home network,
| corporate network or local ISP to the default DoH resolvers
| defined in the browser. This can be changed, but we know most
| people outside of a corporation will not change this. So in
| this case, CIRA will be logging DNS requests and sink-holing
| undesirable domains presumably by Canadian standards.
|
| People can still use browser add-ons to block domains, URL's,
| objects on sites, etc... uBlock is my favorite for this.
| cuillevel3 wrote:
| Here's a blog post from someone who uses nginx 'doh-to-dns'
| to connect their DoH clients to Pi-hole.
|
| So, yes you can blacklist domains, as long as you can
| configure the DoH servers that the client uses.
| iso1210 wrote:
| > as long as you can configure the DoH servers that the
| client uses.
|
| Which now involves not just getting every machine, but
| every application on every machine
| AlexCoventry wrote:
| I think you left the link out.
| duckmysick wrote:
| I believe it's this one:
| https://www.aaflalo.me/2018/10/dns-over-https-with-pi-
| hole/
| cuillevel3 wrote:
| Oops, I meant this one: https://www.bentasker.co.uk/docum
| entation/linux/407-building...
| rank0 wrote:
| Can you expand on this a little more? I do not understand the
| reasoning here
| ZeroCool2u wrote:
| DoH makes widespread censorship and surveillance via
| intercepting plaintext DNS queries much more difficult.
|
| Of course, this is just one weapon in the arms race. It
| doesn't completely protect you, but every bit helps.
| JoshTriplett wrote:
| The vast majority of people don't run their own DNS server,
| or have any control over the DNS server they use.
|
| Most people use their ISP's or organization's DNS server,
| and have no control over it; instead, it's something used
| _against_ them. In many cases, that DNS server may do some
| combination of tracking, redirection to ads, or other
| things that make it undesirable to use.
|
| DoH eliminates one of the last major unencrypted protocols
| on the Internet, and instead uses an encrypted protocol to
| talk _exclusively_ to the intended server without the
| possibility of interception.
|
| If you _want_ to talk to your ISP 's DNS server, you're
| free to do so. But that should be your choice, not your
| ISP's.
| Kalium wrote:
| The tools to administer a home network, such as DNS
| blocking and DNS sinkholes, are the same tools nations use
| to administer their populaces. If the default in Firefox is
| to enable blocking and sinkholes for the home
| administrator's benefit, it will similarly be to the
| benefit of oppressive administrations.
|
| Home administrators who control their endpoints can turn
| DoH off with relative ease. By comparison, most governments
| cannot.
| swiley wrote:
| It would be nice if it would check the resolver config
| files (like the hosts file) with it enabled though.
|
| That was a really easy way to block harmful stuff or name
| things without requiring DNS. Having to choose between
| encryption and easy configuration is pretty poor UX.
| Kalium wrote:
| Naively, that seems like something that could be a very
| useful configuration option to set! Though I can also see
| why you might default to having it off if you don't trust
| the host resolver very much in the country-administering-
| people case.
| swiley wrote:
| You _have_ to trust the local OS config. No amount of
| clever application programming will ever let you get
| around that.
| Asdrubalini wrote:
| Pardon my ignorance, but can't you simply host your own DoH
| server where you choose the domains you want to block, which
| in turn points to a DNS / DoH server you trust? I guess it
| wouldn't be more difficult than hosting your own filtered DNS
| server like Pi-Hole.
| hulitu wrote:
| Yes you (or we) can. But you need to manually alter the
| settings everytime a new ff version is out. And other
| people can not. Brave new world. BTW how is Brave at this
| chapter ?
| cpeterso wrote:
| Why would you need to manually change your settings every
| time a new Firefox version is out? Firefox has settings
| UI to point to the DoH server of your choice and that
| setting does not get reset by new Firefox versions:
|
| https://support.mozilla.org/en-US/kb/firefox-dns-over-
| https#...
| ralphm wrote:
| Why every time? Isn't this a user config that overrides
| whatever default there is?
| ocdtrekkie wrote:
| Yep. The entire point is to make it impossible to block ads
| at the network level. And since ad companies control the
| application level too, they then have a complete end-to-end
| ad delivery stack that you can't tamper with.
| donmcronald wrote:
| Yep. Everything's going to be locked from the bootloader to
| the screen and you WILL watch the ads.
|
| What I think will really happen is the same thing as
| everything else. They'll use tech to take away features /
| abilities we have right now and then rent it back to us as
| a subscription.
|
| "OpenDNS is now part of Cisco"
|
| Add it up.
| tomjen3 wrote:
| We are talking about Firefox, a web browser, that allows
| you the most control over your computer, has the best
| adblock technology, on which the author of Ublock origin
| has said his software runs the best, which comes with
| built-in anti tracking, which now comes with technology
| making it harder for public wifi to trick your computer
| into going to captive portals, often with ads.
|
| And somehow you ad this up to making it impossible not to
| see ads and locked down computers.
|
| How?
| ocdtrekkie wrote:
| Firefox's primary sponsor is still Google. And whether
| they are pushing it because of malice or just
| incompetence, DoH was designed and built by Google to
| protect ad companies from network security. Implementing
| it by default is a hostile act, and one Mozilla should
| reconsider.
| slashdot2008 wrote:
| i have a pihole and have been worried that DoH would
| break it. i checked the network settings in firefox and
| the DoH setting is there but it is disabled.
|
| I doubt that chrome will allow one to disable DoH but at
| least firefox does for now.
| ocdtrekkie wrote:
| I believe Pihole automatically put in the NXDOMAIN entry
| needed to disable DoH on Firefox for you. But who knows
| how long Firefox will respect that, since there's nothing
| stopping ISPs from employing the same strategy to disable
| DoH.
| iso1210 wrote:
| For now.
|
| This is one step in the boiling-the-frog process.
| hulitu wrote:
| Yes unfortunately this seems to be the reason. Earlier you
| could tell the resolver to look at files first and filter
| with your hosts file the ad and other sites. Now you have
| to do packet inspection. We are living on a planet that's
| revolving and evolving ...
| JoshTriplett wrote:
| > The entire point is to make it impossible to block ads at
| the network level.
|
| The entire point is to make DNS secure. For every 1 person
| who uses DNS to block ads, there are many thousands who
| just use their ISP's DNS servers, and thus remain subject
| to surveillance, ads, redirects, and other malice. You
| can't possibly believe in good faith that the _entire_
| point or even the _primary_ point of DoH is to hurt the
| small fraction of people who use DNS to block ads, rather
| than to protect the much larger set of people who are
| subject to the whims and financial interests of their ISP.
| ocdtrekkie wrote:
| ISPs do not inject malware and phishing scams, Google Ads
| does. The benefit of blocking ISP tampering is vastly
| outweighed by protecting the bad behavior of a far more
| malevolent party.
| akersten wrote:
| > ISPs do not inject malware
|
| Not taking a side on this thread, but just want to point
| out that Comcast _literally_ has a patent describing just
| such a mechanism. [0]
|
| [0]: https://patents.google.com/patent/US20120224572
| ocdtrekkie wrote:
| From said patent:
|
| > including weather, emergency broadcast, and police
| stations
|
| These seem like reasonable uses of this technology. My
| ISP has tried to inject a copyright violation notice
| before. (This was hilarious, actually, because it went to
| a guest in my house's browser, not one of mine, and I
| almost didn't hear about it at all, because they only
| sent it that way once... and I had to _ask_ them to send
| me an actual letter about it with the details, which
| would 've been the straightforward way to tell me in the
| first place...) Irritations with copyright holders aside,
| that was a notification of a mark against my account,
| which is arguably information that needed to be delivered
| to me.
|
| Meanwhile, Google is preserving their ability to send
| phishing sites unimpeded.
| wbl wrote:
| Not a Verizon customer I take it?
| JoshTriplett wrote:
| Google ads (like most ads) are hosted by websites that
| intentionally put them there; install an adblocker.
| Google doesn't MITM sites; ISPs and malicious networks
| do. ISPs are also known to surveil traffic on their
| networks.
|
| I'm not disputing that Google ads and tracking, like all
| other ads and tracking, should be blocked. Run a browser
| you trust, and run an adblocker. But the widespread use
| of unencrypted DNS is a problem that needs fixing. And
| DoH provides the most viable solution for that problem,
| by running DNS over an ordinary HTTPS connection.
| rightbyte wrote:
| > Google doesn't MITM sites
|
| AMP.
| notatoad wrote:
| >the entire point is to make it impossible to block ads
|
| the entire point is to make it impossible to modify DNS
| requests at the network level. this has a lot more serious
| consequences than just blocking ads. especially for the
| parties involved with this, none of whom are advertising
| companies. phishing and data security are actual big issues
| with financial implications that companies want to prevent.
| just because blocking ads is the consequence that will most
| immediately impact you personally, doesn't make it the
| whole point.
|
| this accusation is especially rich on an article about
| mozilla, one of the few companies fighting to make sure
| that advertisers _don 't_ control the application level.
| wbl wrote:
| Use MDM and configure the browser. Or block the special
| probe domain Mozilla has for this purpose.
| ocdtrekkie wrote:
| > phishing and data security are actual big issues with
| financial implications that companies want to prevent
|
| These are issues exacerbated by DoH, not fixed by it. DoH
| assists in the circumvention of security and monitoring.
| We block ads because they're security problems.
| josephcsible wrote:
| Control over DNS is neither necessary nor sufficient to
| block ads.
| ocdtrekkie wrote:
| It's not sufficient in itself, but it bears most of the
| load of network-wide management of harmful traffic. It's
| the 99% effective method.
|
| Endpoint-level control is no longer possible, since ad
| companies are skipping the OS network stack and bringing
| their own. Application-level control is less efficient,
| and more difficult, particularly when the applications
| are designed by the same ad companies trying to
| circumvent DNS control as well. (See Manifest V3.)
| [deleted]
| vbezhenar wrote:
| Blocking ads at network level is very easy to circumvent.
| Just serve ads from your domain. It's impossible to block
| youtube video ads using DNS, for example, you must
| intercept their API queries and modify them on-the-fly
| which requires browser extensions or custom apps.
| ocdtrekkie wrote:
| It's easy to circumvent if your ads are first party, as
| in YouTube's case. Most ads are not. Even _most_ Google
| websites serve ads from ad-specific endpoints, as opposed
| to their own domain.
| vbezhenar wrote:
| I think that's because those who care about blocking ads,
| will block them anywhere. And percentage of those who're
| using pihole or similar methods to block ads is
| negligible, so they don't really care about that.
| katbyte wrote:
| And if your blocking ads your probably not the desired
| audience of them anyways.
| pitaj wrote:
| All you need is to point DoH at your own DNS server
| ocdtrekkie wrote:
| You can't do that with a Chromecast. The goal here is to
| sell devices which can ensure they always talk to their
| own DoH endpoint with no ability to secure it.
| shawnz wrote:
| Chromecast was already bypassing local DNS for years
| before DoH was even conceived.
|
| Blocking people from using DoH isn't going to solve the
| problem you are describing, it will just weaken users'
| privacy. Big vendors like Google will just create their
| own workarounds.
| akersten wrote:
| > Chromecast was already bypassing local DNS for years
| before DoH was even conceived.
|
| Before DoH though, my understanding is a good gateway
| appliance could just overwrite those DNS requests as it
| sees them. Now they'll be encrypted, and you'll have no
| way to tell the Chromecast where to connect (or even to
| where it is connecting).
| shawnz wrote:
| If the possibility of having the DNS packets rewritten
| was a concern for them, any junior developer could have
| easily implemented a proprietary REST web service to get
| the IPs over HTTPS just like DoH. Standardization of DoH
| in browsers isn't really furthering that issue.
| slashdot2008 wrote:
| How would they get the first IP for the REST client to
| contact?
| shawnz wrote:
| That problem isn't solved by DoH, you still need to
| hardcode the DoH server IP there too if you intend to
| bypass the network level settings. So a proprietary
| system would be no different.
|
| All the major appliance vendors (Google, Amazon) already
| have huge fixed IP ranges to devote to this purpose,
| which are effectively unblockable because they might be
| shared with important cloud services.
| swiley wrote:
| Yes they are but you'd have to run your own DoH server or
| follow the instructions to disable DoH like an ISP would (the
| possibility of which makes one wonder what the whole point
| is.)
| josephcsible wrote:
| Or just use one of the many public DoH servers that already
| do this.
| swiley wrote:
| The won't block my specific list of websites (reddit.com
| for example.)
| josephcsible wrote:
| Don't NextDNS and OpenDNS both let you do that?
| swiley wrote:
| Even if they do, you're now sending _all_ of your DNS
| queries to some external service. That 's a pretty
| serious privacy violation, even worse than 8.8.8.8.
| josephcsible wrote:
| They aren't possible for the network to unilaterally impose
| on unwilling users. They're still possible if the user
| actually wants it, by just setting their client's DoH server
| to one that does them.
| iso1210 wrote:
| A network suggests a DNS server
|
| You can choose to use that server or not
|
| If a network intercepts your DNS traffic, you can encrypt
| it yourself. If you don't trust the network you should be
| encrypting everything anyway
| simias wrote:
| I think it's an extremely inelegant and overkill solution to a
| real problem. So, the web in a nutshell.
| np-tokumei wrote:
| In the current designs, plaintext domain names are mainly exposed
| through two channels: the SNI extension in TLS, and traditional
| DNS name resolutions--the deployment of DoH/DoT is thus a
| prerequisite for ESNI. Equivalently, the use of DoH/DoT will not
| provide any meaningful privacy if domain names are still exposed
| through the (unencrypted) SNI extension in TLS handshake traffic.
|
| Recently, there is a push for the deployment of DoH/DoT, with
| major organizations already supporting it (e.g., Google,
| Cloudflare, Firefox), though this has not been followed by an
| equivalent effort for the deployment of ESNI, which is now being
| reworked in an Internet draft called Encrypted Client Hello (ECH:
| https://www.ietf.org/archive/id/draft-ietf-tls-esni-12.txt).
| Unless the confidentiality of domain names is preserved on both
| channels (SNI and DNS), neither technology can provide any actual
| privacy benefit if deployed individually.
|
| Also many websites hosted on IP addresses that do not host any
| other domains, the IP information can be used to infer which
| domain was visited. We have carried out some studies to
| investigate the extent to which domain name inference can be done
| through IP address information. For more technical details pls
| have a look at these papers:
|
| "Assessing the Privacy Benefits of Domain Name Encryption"
| https://arxiv.org/pdf/1911.00563.pdf
|
| "Domain name encryption is not enough: privacy leakage via IP-
| based website fingerprinting"
| https://petsymposium.org/2021/files/papers/issue4/popets-202...
| shawnz wrote:
| Firefox has indeed been making efforts to enable ESNI/ECH
| alongside their efforts to enable DoH. As you mention, they are
| mostly only useful together.
| np-tokumei wrote:
| yea, they have also disabled/removed ESNI since version 85
| https://www.ghacks.net/2021/02/24/the-case-of-the-missing-
| es...
|
| Hopefully ECH will make it this time
| lucasyvas wrote:
| Is it possible to configure multiple DoH providers so your DNS
| requests round robin like an actual DNS server list could/would?
| cpeterso wrote:
| You can point Firefox to any DoH provider you like, but there
| is no setting to set multiple DoH providers. If you are
| concerned about DoH providers tracking you, it seems like using
| two DoH providers would give each of them half your browsing
| history, which probably covers all the same sites as your full
| browsing history.
|
| https://support.mozilla.org/en-US/kb/firefox-dns-over-https#...
| scaryclam wrote:
| For anyone wondering, DoH = DNS over HTTPS
| enriquto wrote:
| how could firefox know that you are canadian? the title sounds
| nonsensical to me
| lucasyvas wrote:
| Can someone enlighten me as to why this should be a trusted
| default? Because I inherently wouldn't trust it. I wouldn't say I
| trust NextDNS, but I currently use them for DoH.
| 0xTJ wrote:
| I'd argue that if you're using it, you trust it. Otherwise you
| wouldn't use it. This seems a lot better than just letting the
| internet provider give a regular DNS.
| xg15 wrote:
| > _I 'd argue that if you're using it, you trust it._
|
| Nope.
| tremon wrote:
| _This seems a lot better than just letting the internet
| provider give a regular DNS_
|
| Why? You're already using your internet provider, so you
| trust them. Otherwise you wouldn't use them.
| JoshTriplett wrote:
| I don't want to trust my Internet provider to do anything
| other than route encrypted packets. I don't want any other
| service than that from them, and I don't trust them any
| further than "exchange bandwidth for money".
| dewey wrote:
| > Otherwise you wouldn't use them.
|
| A lot of times you don't really have a choice which ISP to
| use so that's not really a good argument.
| recursive wrote:
| DoH brings us closer to being able to use an internet
| provider you _don 't_ trust. And I already don't trust my
| ISP's DNS servers.
| coldpie wrote:
| No, the point of DOH is that you don't have to trust your
| ISP. In many countries the ISPs are actively hostile[1].
| You do have to trust the DOH provider, yes, but in this
| case Mozilla (or yourself if you have the tech knowledge)
| will be verifying trust on your behalf. You cannot do that
| at all with plain ol' DNS.
|
| DOH is a "best of a bad situation" kind of solution, it's a
| reaction to hostile ISPs. It's not something anyone really
| likes.
|
| [1] https://www.internetsociety.org/blog/2014/04/turkish-
| isps-hi...
| jeltz wrote:
| DoH means handing your data to one more party since your
| ISP can already see your SNI headers and the IP
| addresses. The only thing DoH does is stopping DNS
| spoofing at the cost of handing your data to a third
| party.
| coldpie wrote:
| > The only thing DoH does is stopping DNS spoofing at the
| cost of handing your data to a third party.
|
| It sounds like you think that's not worth it, but the
| evidence is that others disagree. Personally, I see both
| the pros & cons and have no strong feelings either way. I
| trust Mozilla's evaluation of the pros & cons more than I
| trust my own so I'm happy to do whatever they think is
| best, and I suspect most users feel the same way. If you
| disagree with their evaluation, you can toggle it off in
| Preferences, and they even show a banner on first start-
| up giving you that option.
| kevin_thibedeau wrote:
| Your ISP is selling all of your internet activity to data
| brokers. This gets added into the detail profile they have on
| your spending, preferences, political attitudes, and much more.
| DoH takes that away.
| elric wrote:
| Maybe your ISP is, but mine is not.
|
| DoH does not take that away. It might move it away from the
| hands of your apparently adversarial ISP, but delivers the
| information in the hands of whoever is running those DoH
| servers...presumably Cloudflare, who already hold far too
| much sway for my comfort.
| 542458 wrote:
| To qualify as a DoH resolver you have to agree to not log
| data for purposes other than providing the service, not
| keep logs for longer than 24h, and not sell any such data.
| This is audited.
|
| https://wiki.mozilla.org/Security/DOH-resolver-policy
| autoexec wrote:
| Where are you seeing anything about audits? The link just
| says that Mozilla can decide to remove people from the
| TRR program. They aren't sending people to Cloudflare and
| Comcast's server rooms. It's great that should a
| violation be disclosed to the public Mozilla might remove
| them, but unless there's a whistleblower the public will
| never know what's being done with their browsing history.
| tombh wrote:
| DoH = DNS over HTTPS
| FpUser wrote:
| I am curious how this will affect various applications and
| testing suites as those would know nothing about that Mozilla's
| decision.
|
| All in all it is sickening to watch all those entities trying to
| to usurp control over the areas that are better not to be fucked
| with.
| dleslie wrote:
| Worth noting is that the CIRA is a Canadian organization and so
| will be restricted by Canadian court orders and regulator
| rulings.
|
| So this rollout of DoH to Canadians isn't nearly as disruptive as
| it could be.
| CarelessExpert wrote:
| Nice to see they'll be making it easy to opt out. I use a Pihole
| on my network and this would be an enormous PITA if it was hard
| (or worse, impossible) to disable...
|
| Edit: I forgot, as another commenter pointed out, they also have
| a canary domain (use-application-dns.net) that you can blackhole
| to disable this at the network level (unless the user manually
| enables DoH).
| warhorse10_9 wrote:
| You can also just set the policy to disable this in registry or
| using policy.json on Linux. Mac has a similar setup, i'm just
| not familiar with it.
| CarelessExpert wrote:
| Yeah, I ended up going the canary domain route, and then
| setting up my pihole itself to use DoH using cloudflared
| outbound. Best of both worlds!
| iso1210 wrote:
| Yes, canary domain is fine - at least while it still works.
| I don't want to have to configure DNS for 50 different
| applications on 20 different machines. My OS does DNS, and
| my DHCP server doles out the DNS server I want my machines
| to use.
| CarelessExpert wrote:
| The Mozilla page on the topic
| (https://support.mozilla.org/en-US/kb/canary-domain-use-
| appli...) notes that:
|
| > The use of this domain is specified by Mozilla, as a
| limited-time measure until a method for signaling the
| presence of DNS-based content filtering is defined and
| adopted by an Internet standards body.
|
| Presumably that'd be the IETF, and I have no idea which
| committee would be working on this, if there's a draft
| RFC in the works, etc. But it's clear the expectation is
| some sort of standard mechanism will eventually replace
| the canary domain that yields the same functionality but
| in a less hacky way.
| Arnavion wrote:
| There was [1] which would've allowed websites to specify
| custom DoH resolvers for their subdomains, but it expired
| some time ago. The same authors are now working on [2]
| instead, which AFAICT is basically for the same thing.
|
| There's also [3] which is a way for the DHCP server to
| also provide DoT and DoH servers to the LAN (in addition
| to the usual DNS servers).
|
| [1]: https://datatracker.ietf.org/doc/draft-pauly-add-
| resolver-di...
|
| [2]: https://datatracker.ietf.org/doc/draft-ietf-add-ddr/
|
| [3]: https://datatracker.ietf.org/doc/draft-ietf-add-dnr/
| Arnavion wrote:
| PSA for network admins: Note that use-application-dns.net must
| return NXDOMAIN, _not_ (successfully) resolve to 0.0.0.0.
|
| I see plenty of people just adding it to their hosts file
| blacklists / DNS overrides like they do for other ad and
| malware domains, such that it resolves to a bad IP like
| 0.0.0.0. That's not what you should be doing in this case.
___________________________________________________________________
(page generated 2021-07-08 23:02 UTC)