
DNS over HTTPS–What Is It and Why Do People Care? [pdf] - signa11
https://crsreports.congress.gov/product/pdf/IN/IN11182
======
60654
Encrypted DNS is a good idea, I just wish all of the basic protocols were
getting encryption in-place, instead of being reinvented over HTTPS.

First HTTP/3 (nee QUIC) reinvented TCP and ports over HTTPS, now DOH is
reinventing DNS over HTTPS... Sigh. Both of these would be better off by
evolving and modernizing their respective existing protocols. And HTTP is a
client/server protocol with a _heavy_ handshake cost, why are we using it for
a quick one-off request like DNS.

~~~
cmroanirgo
I don't disagree.

But the problem began decades ago when sysadmins started using firewalls to
control what employees could access. During early 2000's I was involved in
moving a lot of apps that used a bespoke port to port 80/443 just to make sure
our apps and services didn't have any client hiccups due to (rightly so?)
belligerent sysadmins.

All this has really done has made sysadmins lives harder bc of packet
inspection. So, all app developers and now infrastructure solution devs must
run thru 443, otherwise the take up wouldn't happen. The internet is
effectively running on one port nowadays.

~~~
ma2rten
Why not extent the existing protocol and keep it on port 53, which DNS already
uses?

~~~
snuxoll
Because some companies run with an effective

    
    
        iptables -t filter -A FORWARD -p udp --dport 53 -j DROP
    

And prevent anything from their own internal resolvers from accessing outside
DNS services, especially now that encrypted SNI is moving more web filtering
to the DNS layer.

~~~
mlyle
But that one is OK. DNS over HTTPS doesn't exist to circumvent enterprise
content filtering (hence why you can hint you don't want it to run with a DNS
entry, making it vulnerable to downgrade attacks).

Easier to make the orgs internal recursive resolver "does the right thing"
than all clients, too.

~~~
growse
> DNS over HTTPS doesn't exist to circumvent enterprise content filtering

Replace "enterprise" with "ISP" or "nation state", and that's closer to what
the DoH aims are.

------
Glyptodon
My only gripe with DNS over HTTPS is that it seems to somehow be coupled with
making it harder for me to actually force everything to use a particular DNS
at the OS level, so apps can do things like circumvent your pihole regardless
of how you configure your device's DNS settings.

~~~
baroffoos
They could do that already. There is nothing requiring that your app uses the
OS set dns server

~~~
throw0101a
> _They could do that already._

Before Mozilla's drama with DoH, which app(s) did that?

Now that Mozilla has shown people that it's 'okay' to override the OS I'm
worried that more things will do that same cockamamie thing.

~~~
ultraism
Not an app, but Chromecasts have 8.8.8.8 hard coded.

------
ma2rten
This was very well written. I am pleasantly surprised.

 _Another concern is that DOH will complicate content delivery to users.
Today, content delivery networks (CDNs) host multiple instances of web content
on geographically dispersed servers. This creates resiliency for web services
and helps to deliver content to users more quickly. If ISPs lose the ability
to view users’ DNS queries, they will still be able to route users to a CDN,
but not necessarily the closest or most efficient CDN. Technical measures that
may alleviate this concern include sharing some user data (like general
geolocation data) and CDN load management tactics._

Is this a real concern? Don't ISPs just route on IP addresses?

 _Other potential implications of DOH implementation involve issues such as
international data flow and advertising competition._

What on earth is this referring to?

~~~
tannhaeuser
That refers to the fact that DoH gives the same old monopolies on the web
(Google, Cloudflare) additional web visit signal data, worsening the already
appalling state of the economy on the internet captured by Google and Facebook
for more than a decade, with naive nerds cheering in the name of technical
progress. It also refers to ad blocking no longer being able to block ads
based on domain names and IP addresses.

~~~
ma2rten
Other providers can provide DNS over HTTPS. It doesn't affect client side ad
blocking. You can still point your browser to a regular DNS server (like some
kind of DNS-based adblock solution), just the default changed.

~~~
spc476
For how long though? I don't necessarily trust either Chrome or Firefox to
quietly accept my "why yes, use normal DNS" choice, so I've just gone ahead
and set up DoH at home (since I'm already running DNS at home). But then
again, I can.

------
emddudley
> The Congressional Research Service (CRS), a federal legislative branch
> agency located within the Library of Congress, serves as shared staff
> exclusively to congressional committees and Members of Congress. CRS experts
> assist at every stage of the legislative process — from the early
> considerations that precede bill drafting, through committee hearings and
> floor debate, to the oversight of enacted laws and various agency
> activities.

[https://crsreports.congress.gov/Home/About](https://crsreports.congress.gov/Home/About)

------
pdkl95
By its own definition[1], DOH forbids recursive resolution of queries. The
client "MUST NOT use a different [DOH resolver] simply because it was
discovered outside of the client's configuration"[2].

The protocol seems to be designed to require clients to send all of their DNS
traffic to a single upstream provider. This may be similar to your current DNS
configuration, and your network may even be limiting your ability to use the
internet with bad policies on broken middleboxen. That's unfortunate for you,
but please don't presume everyone has similar limitations.

>> "But we need to overload port 443 to hide our DNS traffic!"

It's unfortunate your ISP or national infrastructure requires such
obfuscation. In those situations, the current DOH protocol could be a good
workaround.

However, protecting against a malicious upstream server sending bad results is
very different than protecting against large institutions being able to
eavesdrop on your DNS traffic to build a model of your pattern-of-life. The
latter is only stopped by _not giving a single entity_ all of your DNS
traffic, which DOH explicitly requires.

If you recursively resolve DNS queries locally - ideally in a future where
traffic to authoritative servers is encrypted (DoT?) - only the first request
goes to a centralized server. Most traffic goes to the domain's authoritative
server, which is probably the same controlled by the same entity you are about
to connect to with HTTPS.

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

[2]
[https://tools.ietf.org/html/rfc8484#section-3](https://tools.ietf.org/html/rfc8484#section-3)

------
ameliaquining
> Today, DNS queries are generally sent unencrypted. This allows any party
> between the browser and the resolver to discover which website users want to
> visit. Such parties can already monitor the IP address with which the
> browser is communicating, but monitoring DNS queries can identify which
> specific website users seek. As more services move to cloud computing
> infrastructure, this distinction becomes increasingly important, because
> multiple websites may be consolidated under a few IP addresses, rather than
> each having a unique IP address.

This is super misleading. Even with DoH, any party on the network can see
which websites you're talking to, because their hostnames are sent in the
clear via SNI. ESNI fixes this, but it's not clear to me whether the major
cloud providers are going to go for that, and if they don't it's not going
anywhere.

[https://news.ycombinator.com/item?id=21264814](https://news.ycombinator.com/item?id=21264814)
was a good discussion of the actual security benefits of DoH.

------
colinprince
I wonder if Mozilla will change their rollout plan now that the UK has dropped
their porn-filtering plans[0]

0\.
[https://www.bbc.com/news/technology-50073102](https://www.bbc.com/news/technology-50073102)

~~~
ultraism
They still will want to block piracy sites.

[https://en.wikipedia.org/wiki/List_of_websites_blocked_in_th...](https://en.wikipedia.org/wiki/List_of_websites_blocked_in_the_United_Kingdom#Court_ordered_implementations_targeting_copyright_and_trademark_infringement)

------
ma2rten
DNS is heavily cached. What are the caching implications for encrypting DNS?

~~~
TheSmiddy
It's only the traffic that is encrypted. It's still cached on the server and
the client.

~~~
spc476
I _wish_ it was cached by Firefox. But it's not. I'm running a DoH setup at
home, and from the logs, it looks like Firefox is _NOT_ doing any caching of
results it gets.

At least my DNS server is caching the results though.

------
GuyPostington
This links directly to a PDF. Reader beware.

~~~
Gaelan
What's wrong with links to PDFs? A concern with malware?

~~~
dhritzkiv
I'm not sure about these days, but I do remember being hesitant about opening
PDFs 12+ years ago, before I switched to MacOS (Safari has always had very
good PDF display ability via OS X), and before all the major browsers had
built-in PDF display (PDFs would often be downloaded as a file, which would
trigger the opening of some PDF viewer shareware pre-installed on Windows).
Terrible UX back then.

~~~
notzuck
Yeah that was true back then. Opening a PDF link on windows 2000 or XP always
a pain in the ass. I think those days are mostly over now though.

------
totorovirus
FYI: South Korea uses SNI to block porn sites.

~~~
baroffoos
Encrypted SNI is on the way. Alternatively, if the site is on a CDN or hosting
platform you can usually send any SNI you want and it still resolves to the
correct site.

~~~
ameliaquining
Major cloud providers started blocking domain fronting last year.

------
LinuxBender
Disclaimer: This will be a wildly unpopular opinion.

I do not believe that DoH was created first and foremost to protect the
privacy of people. I believe that it was created to use the frog in boiling
water methodology of silently pushing millions of people into centralized
logged DNS that can be used for whatever purpose those companies see
appropriate, in my personal opinion.

I do not believe this opinion is far fetched. No company is going to just
provide a large amount of infrastructure out of the kindness of their hearts.
I am not saying that philanthropists do not exist. They do, but not here. This
is a data grab first and foremost, in my opinion.

Another factor in my opinion is the lack of support for a corporate
infrastructure. Some companies may manage some facets of user settings in
Chrome and Firefox via AD policies, but I believe that is the exception rather
than the norm. Companies will be leaking even more internal infrastructure
topology than they do today. It isn't like ISP's manage browser settings, nor
would they want to.

Nation states? DoH will not affect them at all. They will simply null route
all of the DoH hosts like they do with existing proxies and VPN providers.
This is what I had to do in my home network so that I could maintain control
of my DNS.

~~~
cracker_jacks
I think you're arguing against the wrong thing here. You want decentralization
of DNS. I don't see DoH really impacting this issue in any clear direction.

On one hand, you have centralized DNS (based on your ISP). DoH gives you some
choice over that now through your browser. On the other, you have only a
handful of DNS providers to choose from. DoH is just a technology, there's
nothing preventing ISPs from still providing their DNS services over HTTPS.

~~~
pdkl95
> I don't see DoH really impacting this issue in any clear direction.

See my other posts[1][2] about why DoH explicitly requires centralization.

> you have centralized DNS (based on your ISP)

You might, I don't, because DNS doesn't require that the client delegate
recursive resolution to an upstream server.

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

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

~~~
cracker_jacks
This is a strange definition of decentralization. I suppose it gives you
redundancy. But aren't you broadcasting information about your request to
multiple parties if you're doing recursive resolution from different
providers?

But I agree that this should be a choice on the client-side.

~~~
pdkl95
(sorry for the late response!)

> This is a strange definition of decentralization.

DNS is - by definition[1] - a distributed database.

    
    
        Name servers store a distributed database consisting of the
        structure of the domain name space, the resource sets associated
        with domain names, [...]
    

> I suppose it gives you redundancy.

The distributed database is about administrative boundaries[2].

    
    
        Authority is vested in name servers.  A name server has
        authority over all of its domain until it delegates authority
        for a subdomain to some other name server.
    

Redundancy in the DNS system is provided by a requirement that at least two
authoritative nameservers must be listed when delegating authority to a
subdomain.

> But aren't you broadcasting information about your request to multiple
> parties

Recursive resolution only involves multiple parties when the authoritative
nameserver for a DNS zone[3] isn't known and again when the TTL (time-to-live)
for the zone's NS record expires. Once the NS records are cached locally,
queries only involve one party. DNS is a very flexible system that is designed
to allow queries at any level and easy caching.

Also, consider that TTL for different record types is often very different.
The only record that necessarily must be requested from the 2nd-level domain
(".com") or other central server (like 8.8.8.8) are the NS records for a zone.
Using the IETF's rfc server in [1] as an example, to lookup the A record for
"tools.ietf.org", we first (unfortunately) leak information to .org (or
8.8.8.8, etc) to discover the domain's authoritative servers:

    
    
        ;; SERVER: 8.8.8.8#53
        ;; QUESTION SECTION:
        ;tools.ietf.org.                        IN      NS
    
        ;; ANSWER SECTION:
        tools.ietf.org.         1209600 IN      NS      heroldrebe.levkowetz.com.
        tools.ietf.org.         1209600 IN      NS      zinfandel.levkowetz.com.
        tools.ietf.org.         1209600 IN      NS      dechaunac.levkowetz.com.
        tools.ietf.org.         1209600 IN      NS      dunkelfelder.levkowetz.com.
        tools.ietf.org.         1209600 IN      NS      durif.levkowetz.com.
    

We then cache that locally for 1209600 seconds (14 _days!_ ). While this does
leak the fact that you asked about _something_ in the " _.ietf.org " zone to a
central server, two (apx) of these requests _per month* doesn't reveal much
about your _pattern-of-life_.

The TTLs of A (and AAAA) records tend to be much shorter, sometimes
unnecessarily short for better surveillance resolution. In this case, IETF is
using a fairly standard 10 minutes:

    
    
        ;; SERVER: 4.31.198.61#53 (durif.levkowetz.com)
        ;; QUESTION SECTION:
        ;tools.ietf.org.                        IN      A
    
        ;; ANSWER SECTION:
        tools.ietf.org.         600     IN      A       4.31.198.61
        tools.ietf.org.         600     IN      A       4.31.198.62
        tools.ietf.org.         600     IN      A       64.170.98.42
    

For comparison, the A record for graph.facebook.com (their big
"analytics"/spyware ingress server) seems to have a random TTL between ~5 and
59 seconds. Thy are effectively forcing a DNS query on every analytics event.
That's insane, but my point is that doing the recursive resolution locally
means that almost all of those DNS queries are sent to dns.facebook.com
_only_. The upstream DNS at the ISP or 8.8.8.8 only gets ~two UDP packets per
month. With DoH, all of that still happens, but it has to be routed though
Cloudflare first!

[1] RFC 882, page 13, "NAME SERVERS"
[https://tools.ietf.org/html/rfc882#page-13](https://tools.ietf.org/html/rfc882#page-13)

[2] RFC 882, page 14, "Authority and administrative control of domains"
[https://tools.ietf.org/html/rfc882#page-14](https://tools.ietf.org/html/rfc882#page-14)

[3] From [1], "In general, a name server will be an authority for all or part
of a particular domain. The region covered by this authority is called a
zone."

