
Centralised DoH is bad for privacy - ahubert
https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/
======
eloff
It's bad for privacy in theory because you centralize DNS requests through
Cloudflare. In practice ISPs are almost universally reprehensible in how they
collect, track, and sell your data. Cloudflare on the other hand has a great
reputation for respecting user privacy and they do thrid-party audits on a
regular basis so you can have peace of mind about it. Encrypting your DNS
requests so your ISP (and other hops on the Internet) can't snoop on it is a
huge privacy win.

I'd much rather trust Cloudflare than my ISP. Doubly so when I'm out of the
house or traveling abroad.

Practice > theory. Every time.

~~~
DavideNL
> In practice ISPs are the almost universally reprehensible in how they
> collect, track, and sell your data

... in your country.

For me it's the other way around; i'd rather trust my ISP because privacy laws
in my country/EU are much better vs the US.

I interpret the move by Mozilla as hostile in regards of privacy, and i can't
understand why EU politics don't intervene when a US company starts hijacking
all Firefox users DNS requests (opt-out instead of opt-in.)

~~~
pingyong
The Cloudflare DNS servers you connect to are in the EU and are subject to EU
regulation just like your ISP. You don't have 11 ms (or anything sub-~90 ms)
latency to the US.

One thing to consider also is that unencrypted DNS means that virtually
_anyone_ can read (and modify) those requests, not just your ISP. That can be
before the data enters your ISPs network, or at any point that isn't
physically or technically well protected. Or, in the case of state actors, at
any point really.

~~~
throw0101a
> _The Cloudflare DNS servers you connect to are in the EU and are subject to
> EU regulation just like your ISP._

Yeah, sure:

> _Primarily the CLOUD Act amends the Stored Communications Act (SCA) of 1986
> to allow federal law enforcement to compel U.S.-based technology companies
> via warrant or subpoena to provide requested data stored on servers
> regardless of whether the data are stored in the U.S. or on foreign soil._

* [https://en.wikipedia.org/wiki/CLOUD_Act](https://en.wikipedia.org/wiki/CLOUD_Act)

~~~
tomschlick
The CLOUD Act would do nothing in this case because Cloudflare doesn't store
data related to your requests and claims they are regularly audited to prove
that.

CF has a lot more privacy minded people to whistle blow on that if they were
lying than your local ISP would.

~~~
throw0101a
Can they be forced to store data?

People at Yahoo were monitoring e-mail on behest of the US government, and not
even telling the company's CISO about it:

* [https://www.reuters.com/article/us-yahoo-nsa-exclusive-idUSK...](https://www.reuters.com/article/us-yahoo-nsa-exclusive-idUSKCN1241YT)

* [https://arstechnica.com/tech-policy/2016/10/report-fbi-andor...](https://arstechnica.com/tech-policy/2016/10/report-fbi-andor-nsa-ordered-yahoo-to-build-secret-e-mail-search-tool/)

~~~
tomschlick
I'm not sure.

Going by the Apple example, they refused to create new code to do something
they were not in the past. That limit made the courts agree with them that
they could not be compelled to create something new.

Yahoo / ISPs already have the data so they have to comply with the law by
providing that data upon request.

~~~
throw0101a
> _Yahoo / ISPs already have the data so they have to comply with the law by
> providing that data upon request._

Data is being sent to CF: can they be forced to raise the logging level from
"INFO" to "DEBUG"? See also Lavabit:

> _Lavabit is an open-source encrypted webmail service, founded in 2004. The
> service suspended its operations on August 8, 2013 after the U.S. Federal
> Government ordered it to turn over its Secure Sockets Layer (SSL) private
> keys, in order to allow the government to spy on Edward Snowden 's
> email.[2][3][4][5]_

* [https://en.wikipedia.org/wiki/Lavabit](https://en.wikipedia.org/wiki/Lavabit)

~~~
jachee
I imagine that at its scale, CF could legitimately claim technical limitations
prevent them from collecting data at the volume of traffic that 1.1.1.1 gets.

~~~
nickpsecurity
With NSA's expert testimony, the FBI could legitimately claim that was BS and
provide collection hardware to "assist" them. ;)

------
judge2020
Spectrum still takes over NXDOMAIN and points it to a Yahoo search page when
using their DNS, meaning you now have exposed the browser to all of the oath
trackers and pushed it to AdChoices, meaning targeted ads. Not every DNS
provider/ISP does this, but when you have one that does, it's probably a net
positive to instead beam it to CF which makes guarantees about logging and
gets audited[0].

0: [https://1.1.1.1/dns/#explanation](https://1.1.1.1/dns/#explanation)

~~~
lazyguy2
It's pretty unusual for ISPs to do this. But Spectrum is big enough that it's
a still a valid concern.

Especially now that more and more people are using mobile networks from people
like AT&T and Verizon, and these companies are effectively scum of the earth.

The real solution is to have the OS itself deal with DNS privacy concerns, not
the browser. Localhost DNS resolver with DNSSEC enabled that will bypass the
default DNS settings and go out to 'trusted' DNS servers when DNSSEC fails.
Maybe even use DoH if ISP blocks normal DNS traffic.

~~~
ohples
From my understanding there is no reason a OS level resolver library can't
support DoH, I am surpised we haven't seen whatever Linux uses add support for
it. Or maybe it did and I missed it.

~~~
Avamander
Doesn't systemd-resolved support it?

~~~
CameronNemo
Do they use Google DNS servers by default? Or is that just NTP?

[https://github.com/systemd/systemd/blob/master/meson_options...](https://github.com/systemd/systemd/blob/master/meson_options.txt#L223)

------
mukti
I suppose its good that DoH is addressing the privacy issues with DNS, but I
think I agree with the point this article is making overall. If its only one
vector of privacy, making it a default this early on (less than a year old?)
seems a bit presumptuous. If someone is looking for your DNS traffic, but
you're using DoH; they'll likely find what they're looking for using another
method.

In my opinion, this kind of goes against what I would expect a browser to do
as well. I don't like the idea that it just bypasses the OS settings. I
understand that there are guidelines for enterprise users, and people who want
to disable it; but I feel that a prompt when they globally enable the setting
isn't enough. Most average users will probably just click "Yes" on the dialog
that asks if they want it enabled.

The idea of DoH seems like a good one, but I would prefer if they figured out
a better way to implement it. Probably a huge majority of people are just
using their ISP's DNS servers, but I don't know that pointing them to
Cloudflare's DoH implementation is necessarily better.

------
judge2020
A solution here is like what Chrome is doing - a DoH upgrade list that only
uses it when your OS/router specifies a service that also provides DoH[0].

[https://github.com/chromium/chromium/blob/711b1ba2735f8af4bd...](https://github.com/chromium/chromium/blob/711b1ba2735f8af4bd6359c6292e1875412df74f/net/dns/dns_util.cc#L146-L217)

~~~
ocdtrekkie
This is a significant improvement over what Mozilla is doing, but still
retains a big issue: It doesn't account for network requests sent outside the
browser.

I'd far rather these developers focus on getting DNS-over-HTTPS support built
directly into operating systems and then properly using the OS's network
stack.

~~~
sp332
This is still very experimental. I think doing the experiments in applications
makes more sense than potentially breaking every network request on the system
at once.

------
mfer
For reference, Mozilla negotiated an agreement with Cloudflare around this.
It's different from Cloudflare normal policies. You can read it at
[https://developers.cloudflare.com/1.1.1.1/commitment-to-
priv...](https://developers.cloudflare.com/1.1.1.1/commitment-to-
privacy/privacy-policy/firefox/)

~~~
the8472
Does the agreement have teeth? Is it even enforceable in the face of NSLs?

> We also commit to documenting any government request to block access in our
> semi-annual transparency report, _unless legally prohibited from doing so._

I guess it is not.

~~~
MrRadar
Mozilla is only rolling out DoH to users in the US whose ISPs would already be
subject to NSLs. Presumably they will wait until non-US DoH providers are
available before rolling it out elsewhere.

~~~
captn3m0
Mozilla is not yet ready to even talk to non-US DoH providers as of now (I've
tried, Quad9 tried from what I've heard, and I'm sure many others did).

Till this changes, Mozilla DoH rollout will be US-only.

------
mr__y
There is one counterpoint for those concerned about all their DNS queries
going through Cloudflare: since more and more[0] websites use Cloudflare (CF)
service, the traffic goes through CF regardless of DNS lookups. I'm not saying
its good, just pointing out that in more and more cases CF will know about a
visit to a website whether their DNS/DoH is being used or not. In such a
scenario using anything else than CF would actually harm the privacy as this
would spray the information over other entities/providers. (If a website is
behind a CF revproxy, CF "knows" about a visit to that website, if then a non-
cf DNS service is used, that DNS provider becomes a second entity to have that
information). Of course as of now majority of websites are NOT using CF, but
apparently their market share is growing and this may become a larger issue in
the future.

[0] Already 10% in 2018 according to this:
[https://www.wired.com/story/cloudflare-spectrum-iot-
protecti...](https://www.wired.com/story/cloudflare-spectrum-iot-protection/)

------
clubm8
Ok but if I don't want to use DOH then what?

I'd previously used Cloudflare's DNS because I trusted it more than my ISP.

Is disabling DoH going to enhance my privacy?

What action items can I take away from this article?

I see a lot of writing about how DoH is back, but rarely do I see the writers
lay out a specific solution.

~~~
the8472
Run an iterative resolver somewhere, then connect to it either via DoT or some
VPN (wireguard, openvpn...) from your router or the OS stub resolver.

Depending on your threat model you could also run the iterative resolver
locally.

~~~
mr__y
To extend your idea, if that "resolver located somewhere" would be shared by
more than one user then mapping a dns query to a specific user/IP would be
much harder, hence further improving the privacy

~~~
the8472
Then you're back to where they have to trust the operator. The purpose of this
exercise is to reduce the number of parties that have to be trusted, not
increase them.

Ideally iterative resolver - autheoritative nameserver traffic would also be
encrypted, then we wouldn't have to "hide in the herd" (as much).

~~~
mr__y
I get the "trust the operator problem", I was thinking about sharing this for
several devices I own or possibly with family assuming that "trust the
operator" would not be an issue then, while increasing privacy a bit by
disabling the ability to match a DNS query to specific user/IP. If this was to
be shared publicly then of course you are right and this not only solves
nothing but makes it worse as it introduces another node to be "trusted"

------
ocdtrekkie
I was accused of having a hidden agenda and then blocked by the Senior
Director of Browser Engineering at Mozilla for suggesting that building DoH
into Firefox and bypassing the OS network stack was a significant concern.
This person expressed some bizarre lack of understanding of how DNS works, how
OSes work, etc. for such a position, as they seemed to suggest that the only
way Mozilla could impact DNS requests is at the browser level, and that
implementing it at the OS level wouldn't protect people from ISPs snooping?

Not only will Firefox's approach cause significant breakage, but the fact that
it doesn't protect non-browser traffic means users may mistakenly be protected
when they are not. Mozilla may be putting lives at risk here, and what's truly
irritating, is that Mozilla's said engineering director, didn't seem to
realize Mozilla could've built something that integrates with the operating
systems' network stack properly.

Mozilla should've invested in improving DoH support at the OS-level or built a
VPN client, again, that worked at the OS level to protect _all_ DNS requests
and/or network traffic, rather than trying to shoehorn in a way to redirect
your DNS queries to their partner into your existing install.

I have nothing inherently against Cloudflare, but Cloudflare should not want
to be associated with this bad hack solution to DoH, and Mozilla should
rethink implementing it.

~~~
bpt3
Can you elaborate on how performing DNS lookups over HTTPS is putting lives at
risk and what significant breakage will occur with this approach?

Also, I would argue that the most effective way for an organization that
maintains a popular browser to impact DNS requests is at the browser level.

~~~
rocqua
From his post, the argument for putting lives at risk seems to be a false
sense of security for apps using the OS resolver for DNS.

~~~
bpt3
I agree that's his implication, I was hoping for him to expand on that
thought.

------
megous
On the contrary, because it's tcp and encrypted you can tunel your queries
safely over tor.

Of course, there are some things to take care of even if you do that, because
privacy is not a simple binary switch you enable.

If you own some not so popular domains, you also should make sure to exclude
them from the queries, so that who you are not easily deanonimized by your
query patterns.

Both is easy relatively easy to do with dnscrypt-proxy.

It's not enough by itself, but DoH enables ways to get secure DNS queries to
your chosen provider anonmously and securely.

------
smnthermes
Cloudflare is not even remotely a trustworthy company:

[https://codeberg.org/crimeflare/cloudflare-
tor/src/branch/ma...](https://codeberg.org/crimeflare/cloudflare-
tor/src/branch/master/README.md)

~~~
waz0wski
lets also not forget cloudbleed, wherein they leaked sensitive data for 6
months

> In total, between 22 September 2016 and 18 February 2017 we now estimate
> based on our logs the bug was triggered 1,242,071 times.

[https://blog.cloudflare.com/quantifying-the-impact-of-
cloudb...](https://blog.cloudflare.com/quantifying-the-impact-of-cloudbleed/)

[https://news.ycombinator.com/item?id=13766339](https://news.ycombinator.com/item?id=13766339)

------
cracker_jacks
This article doesn't do a good job of explaining the censorship-resistant
benefits of DoH. The author conflates privacy and access as the same thing.
They are entirely different.

Access to information is the first step. Privacy is a luxury after access.

------
everdrive
I have yet to hear a compelling argument that DNS poses much of privacy risk
compared to:

\- Your ISP analyzing your IP addresses

\- Your ISP analyzing the names in your TLS certificates

\- The website you're visiting selling your information. (ie, this identify
belongs to this IP and browser cookie. See where else you find him)

\- The advertising iframes doing the same as the website above. Tracking you
everywhere, primarily by using cookies, canvas, etc.

~~~
judge2020
CF is just as well hitting at the first two points with Warp VPN and eSNI.

------
ssalka
For the uninitiated, what is DoH and what is its relation to DNS?

I can see this is comes from a DNS-focused blog, but a little background info
on the subject would really improve the quality of the article.

~~~
cabaalis
From my understanding, it uses HTTPS to perform dns lookups.

This has the benefit of encrypting your dns lookups so that people reading
packets can't read them.

However, your pc and the DOH provider still can read/store/analyze/sell your
dns lookups.

Your isp is probably selling your dns lookup data. So do you trust cloudflare
more than your isp?

The primary issue is that this bypasses the normal dns mechanisms built into
your local network. No more blocking sites using DNS. Presumably, ad block in
your browser will still work. But things like pi-hole will suffer.

~~~
ocdtrekkie
As a note, I believe Pi-hole is implementing the Canary domain to
automatically disable Firefox's DoH support: [https://support.mozilla.org/en-
US/kb/canary-domain-use-appli...](https://support.mozilla.org/en-US/kb/canary-
domain-use-application-dnsnet)

Though one wonders if ISPs and countries can use the same strategy to mitigate
any benefit of Firefox's strategy here.

------
throw0101a
If Mozilla cares about privacy and consent, it'd be nice they would have also
implemented DNS-over-TLS and let people choose what to use.

Also, their idea of " _use-application-dns.net_ " is half-baked: it breaks
DNSSEC because one has to override the responses from the .net folks--which
are signed. One suggest I head (by the author of the linked article) was to
use something like " _use.application-dns.net_ " instead. So you are
overriding the responses of a particular domain instead of a TLD.

Further, once you have 'access' to " _.applicaiton-dns.net_ " there are other
things that can be done:

* check for _use-doh_ for DNS-over-HTTPS desirability

* check for _use-dot_ for DNS-over-TLS desirability

It seems to me that Mozilla didn't bother talking to any DNS experts (e.g.,
DNS-OARC), and now everyone is scrambling.

Most people aren't against encrypted DNS, but it just needs to be implemented
properly.

~~~
tptacek
It's not clear to me why any user of Mozilla would care about DNSSEC (which
Mozilla doesn't support anyways). For that matter: while it's obvious why
Mozilla users would want to choose which resolver they trust (Cloud Flare, or
something else), it's not at all clear why they'd actively want DoT, whose
only real "benefit" over DoH is that it can be actively filtered by network
providers who don't want users encrypting their DNS queries.

~~~
throw0101a
> _It 's not clear to me why any user of Mozilla would care about DNSSEC
> (which Mozilla doesn't support anyways)._

So you talk to Cloudflare via DoH: how do you know that CF isn't manipulating
the results? (Perhaps by government coercion.)

> ... _it 's not at all clear why they'd actively want DoT, whose only real
> "benefit" over DoH is that it can be actively filtered by network providers
> who don't want users encrypting their DNS queries._

Mozilla may want to support it because it could prevent them from being banned
from corporate environments that may need to monitor queries for regulatory
reasons. It doesn't have to be the default, but being able to enable it via a
GPO could be useful.

~~~
tptacek
First, almost nobody signs their zones. DNSSEC has practically no meaningful
adoption (lots of tiny zones in Europe are signed because their registrars do
it automatically, but break zones down by usage and you'll see a very
different story). But, more importantly, DNSSEC is a server-server protocol;
it doesn't protect end-systems at all. If you're using _any_ external
resolver, the "SEC" part of DNSSEC is a single bit in the header saying "some
other resolver checked signatures". You'd have to trust Cloud Flare either
way.

~~~
wahern
What constitutes meaningful adoption? Deployment is 25% in the U.S., and
nearly 50% in Germany. See
[https://stats.labs.apnic.net/dnssec](https://stats.labs.apnic.net/dnssec)

More importantly, 91% of TLDs are signed. See
[http://stats.research.icann.org/dns/tld_report/](http://stats.research.icann.org/dns/tld_report/)
Because only the most esoteric of domains lack DNSSEC at the TLD level, this
means you can prevent your domain from being hijacked for anyone who cares by
simply signing your own zone. Who would care to validate DNSSEC at 25%
deployment? Providers of ridiculously centralized DoT and DoH DNS proxies,
like Google and Cloudflare.

> But, more importantly, DNSSEC is a server-server protocol; it doesn't
> protect end-systems at all.

It's trivial for systems to run their own recursive DNS service locally, while
_also_ making use of intermediate caching nameservers. systemd supports this,
for example, and OpenBSD _almost_ shipped with a local resolver service that
enforced DNSSEC by default (some last minute hiccups caused them to disable it
before release).

Chrome and Mozilla are shipping entire bespoke client DNS transports. Adding
recursive resolution support with DNSSEC verification to their in-browser
resolver is trivial by comparison. I've written a recursive DNS stub resolver,
so know first hand. In fact, CNAME chaining requires client stub resolvers to
already support recursive lookup logic as intermediate recursive, caching
resolvers don't always include CNAME chains in their responses, especially for
out-of-bailiwick chains or when chains can't be resolved from the local cache.
Going from CNAME recursion to recursion on authorities is trivial. Likewise,
DNSSEC verification is trivial compared to the nightmare that is TLS and X.509
certificate parsing and constraint checking.

~~~
tptacek
Those numbers are based on random zones nobody cares about largely being auto-
signed by registrars, which is security theater. Instead, look at
popular/major sites, and count how many of them are signed. Look at sites run
by _actual security teams_ and note that virtually none of them except for
Cloud Flare, which sells DNSSEC services, sign their zones.

Obviously people can stop using DNS servers altogether and run recursive
resolvers (and, of course, expose all their queries to their ISP, which is
precisely the problem DoH is trying to solve). And, as you know, effectively
nobody does this. Obviously, browsers can add support for DNSSEC. But they've
done the opposite thing: they've piloted it --- at Apple, at Mozilla, and at
Google --- and then later withdrew support.

DNSSEC is a dead letter. It has no operational relevance today; the root keys
could be Pastebinned and no site on the Internet would be compromised. And
after 25 years of pointless effort, no meaningful adoption has occurred;
rather, it has been _un-adopted_ from the few places that tried.

~~~
wahern
> auto-signed by registrars, which is security theater

Do you consider Let's Encrypt security theater?

> And after 25 years of pointless effort, no meaningful adoption has occurred;
> rather, it has been un-adopted from the few places that tried.

For a long time the zone enumeration "problem" plagued DNSSEC. Everybody
thought it was a fatal flaw, and it even led to a redesign that added
complexity in an attempt to mitigate it. This made DNSSEC seem unnecessarily
costly, a potential insecurity, and substantially hurt deployment.

Fast forward two decades and best practice is to put all your corporate
resources on the public network, hosted by third parties. The refrain from
those advocating for Google and Cloudflare DoH proxies is that organizations
should be moving away from hidden domains. Well, if you don't have hidden
internal networks and don't care about leaking your subdomains, then DNSSEC is
simple and easy to deploy when self-hosting DNS, and a trivial upgrade to DNS
hosting providers.

I get that you're a long-term opponent of DNSSEC. Well, I'm a weak opponent of
QUIC, especially QUIC outside the kernel. That doesn't mean I don't appreciate
and recognize the benefits, or actively try to oppose it. I try not to be
inconsistent.

If you think Let's Encrypt is great, and you advocate for centralized DoH,
then the major objections to DNSSEC cannot be sustained. That's different than
affirmatively advocating for DNSSEC, but I just don't get the fierce
opposition. To say that DNSSEC is, on balance, worse for the Internet (e.g.
security theater) seems preposterous to me.

~~~
tptacek
Would you trust LetsEncrypt more if the US DOJ ran it?

I really don't know how I can respond to this comment any better than I
already did, years ago:

[https://sockpuppet.org/blog/2015/01/15/against-
dnssec/](https://sockpuppet.org/blog/2015/01/15/against-dnssec/)

As you'll see, I have multiple reasons to believe DNSSEC is a powerful net
negative for the Internet. The simplest one to communicate is that unlike
LetsEncrypt, whose nuts-and-bolts security DNSSEC does not improve on, DNSSEC
also escrows out authority to world governments. But there are other arguments
that are actually more meaningful to me, such as the clunky, 1990s design of
its cryptography and the near-certainty that its installed base will be RSA-
dependent for the protocol's entire lifespan, be it 1 year or 20.

That piece goes into a lot more detail that I won't belabor here.

My point on this thread though is simple and factual and descriptive: an
ordinary user of the Internet --- in fact, even an ordinary software developer
on HN --- can expect to interact with the Internet at length without ever once
coming into contact with a website on a DNSSEC-signed zone. You see DNSSEC
brought up on these threads as if it was an important operational security
concern for people setting up Pi-Holes and whatnot, and you know as well as I
do that's simply false. You probably assume at first blush that I'm snarking
when I say the DNSSEC root keys could be Pastebinned to no real ill-effect,
but if you think about it for a few minutes I think you'll find that I'm not
snarking at all. You _want_ DNSSEC to work, and you're right, I don't, but
neither of us can kid each other about the fact that _it 's not working now._

~~~
yc12340
> Would you trust LetsEncrypt more if the US DOJ ran it?

You haven't responded to his question. _Do you consider Let 's Encrypt
security theater?_

~~~
tptacek
Of course I don't, and I believe they know that.

------
neogodless
Forgive my ignorance, but I searched the article and the internet
([https://www.google.com/search?client=firefox-b-1-d&q=doh](https://www.google.com/search?client=firefox-b-1-d&q=doh))
and I could not figure it out. Shoot - I just remembered.

"DNS over HTTPS" \- it does put this in the description of "what DoH does",
it's a little hard to find. There is a pattern that is popular to use a phrase
and _then_ abbreviate it, i.e. "DNS Over HTTPS (DoH)" which is perfect for
this sort of scenario. By pairing them, the users that search for "DoH" will
find it next to the phrase very early in the page.

It's not a great idea to bury the full phrase somewhere on the page, and omit
the abbreviation next to it.

------
Santosh83
In a hypothetical Internet of the future where almost all websites and web-
apps are also served from a handful of huge cloud providers, would DoH not
increase privacy since now ISPs (and potentially some govts) will have a very
hard time figuring out which site or app you are visiting?

------
bryanlarsen
Cannot Mozilla reasonably say that currently there's only one acceptable DoH
provider; it hopes to vet more soon and once there are more than one it will
select the default provider through some reasonable algorithm (random,
perhaps).

------
jedisct1
To avoid centralization, help deploy more independent resolvers:
[https://dnscrypt.info/](https://dnscrypt.info/)

And for more privacy, we will soon need DNS relays
[https://github.com/DNSCrypt/dnscrypt-
protocol/blob/master/AN...](https://github.com/DNSCrypt/dnscrypt-
protocol/blob/master/ANONYMIZED-DNSCRYPT.txt)

------
dagenix
> And for actual privacy on untrusted networks, nothing beats a VPN, except
> possibly not using hostile networks.

Except that using a VPN then funnels _all_ of your traffic through a single
server which is ideally placed to monitor your browsing activity. And, VPN
providers tend to be quite hard to evaluate for their trustworthiness.

~~~
rocqua
You can always run your own trusted VPN, either at home or at a rented box.

------
Forge36
Is it possible for me to run my own DoH at home? I can setup a DNS server,
however I can't find any details on how I can get a full DNS copy which avoids
the specifics of which website I'm looking up.

~~~
amarshall
> how I can get a full DNS copy

No such thing exists. Even if it did, the TTL of records and creation of new
ones would make it out-of-date almost immediately. The only way to get all sub
domains (and many domains) is to crawl or enumerate all permutations.

~~~
Forge36
I'm probably missing how other DNS servers update and propagate changes. I
update my website's registration with Google, it's not clear how other copies
are notified (or poll?) About my updates with Google.

------
psic4t
With all the discussion going on, I'm really wondering why nobody asks why
Cloudflare is offering their DoH infrastructure for free.

------
devit
Is it feasible to use private information retrieval algorithms so that query
privacy is preserved?

------
Illniyar
What about etc/hosts ?

~~~
StreamBright
Chrome ignores it.

[https://stackoverflow.com/questions/42636711/google-
chrome-i...](https://stackoverflow.com/questions/42636711/google-chrome-
ignoring-hosts-file)

~~~
cortesoft
This can't be true... I use /etc/hosts overrides in chrome all the time

~~~
darkhorn
In Firefox you can define those domains to be ignored, like "do not query
example.com from DoH".

------
auslander
Thank you Apple we still have Safari.

------
kijin
I've said this before and I'll say it again. If you don't like the fact that
DoH is centralized in the hands of Cloudflare, all you have to do is offer a
competing service. Especially if you're a DNS company in the first place. It's
your domain of expertise. Build something. Ship it. Once there are a number of
alternatives, Mozilla et al. will have no reason to insist on using a single
provider.

Right now, for a lot of people in a lot of countries, a choice to use any
resolver that isn't controlled by their ISP/government is a step in the right
direction. So please stop trying to drag down other people who are doing their
best to make progress. If you don't like the direction that they're headed,
build an alternative, write an RFC, or do whatever you can to show us how you
think it should be done instead. Show us the code or GTFO.

~~~
pdkl95
> If you don't like the fact that DoH is centralized in the hands of
> Cloudflare, all you have to do is offer a competing service.

You seem to be presuming that a single "service" is necessary. "Alternative"
centralized services are still a centralized service. The solution to
Cloudflare being able to log everything isn't to hand that same power to
someone else.

I run my own recursive resolver. Only the first request for a domain's NS
record goes to a centralized service; every other request goes to the _domain
specific_ nameserver. Asking ns.example.com for the A/AAAA record for
www.example.com doesn't tell example.com (collectively) much more than they
will learn from the HTTPS request that usually follows.

Yes, ".com" can log that I asked for the authoritative nameserver for
"example.com", but this is usually cached. The centralized nameservice doesn't
see most of the DNS traffic.

Yes, the communication with each domain's authoritative nameserver is often
unencrypted. This is unfortunate, and I strongly support an encrypted
replacement protocol for all communication with nameservers.

Using DoH sends all of the above to one entity... which then likely sends it
unencrypted to the authoritative nameservers. The ISP learns about the result
regardless right after the domain name has been resolved to an A/AAAA record,
when the browser sends the TCP+SYN packet to start HTTPS.

> for a lot of people in a lot of countries, a choice to use any resolver that
> isn't controlled by their ISP/government is a step in the right direction

Providing this as an _option_ for people in those situations is great. That
doesn't mean it will be a benefit for everyone. For many people, DoH is a
significant loss of privacy.

> So please stop trying to drag down other people who are doing their best to
> make progress.

Please stop using this cheap appeal to emotion that presumes one solution will
help everyone.

> Show us the code or GTFO.

We don't need to when the existing DNS situation was already a better option.
Please learn about the diverse way that DNS is actually used in practice.
Also, please consider the damage that is done by encouraging apps to bypass
OS-control of DNS. This takes a lot of control away from the user, and will
piss off a lot of people that use DNS-based adblocking.

~~~
mr__y
>The ISP learns about the result regardless right after the domain name has
been resolved to an A/AAAA record, when the browser sends the TCP+SYN packet
to start HTTPS.

not necesarilly. With HTTPS the ISP will see the IP being connected to, not
the domain. Since there can be multiple domains behind a single IP address,
the ISP cannot know the exact domain. On the other hand since more and more
websites use cloudflare revproxy service, quite often all the ISP will see is
one of cloudflare IPs being connected to, whereas Cloudflare will know the
exact domain (and URI) your browser is requesting. And Cloudflare will get
that information regardless of the way you look up DNS record

