
DNS over HTTPS - sohkamyung
https://github.com/curl/curl/wiki/DNS-over-HTTPS
======
politelemon
> for privacy, performance and security.

I understand the privacy and security aspects. But I am wondering - how can
DNS over HTTPS be more performant in the case of curl commands? A browser
could probably persist the connection to the resolver and issue several
requests together, but with a single curl command surely there's the overhead
of initiating the first DNS resolve, the HTTPS connection, the second DNS
resolve. There must be some delay compared to regular DNS.

Side note - I just learned that performant is not a recognized word
([https://english.stackexchange.com/questions/38945/what-is-
wr...](https://english.stackexchange.com/questions/38945/what-is-wrong-with-
the-word-performant))

~~~
coinerone
"Performant" is a word in German. It translates to exact what "perfomant"
would mean in english if it were an english word. The funny thing is, google
translate, translates the german word "performant" to the english word
"performant".
[https://translate.google.com/?hl=de#de/en/per%C2%ADfor%C2%AD...](https://translate.google.com/?hl=de#de/en/per%C2%ADfor%C2%ADmant)

~~~
nijaru
It is not actually translating anything since performant is not considered a
real word in English, although I commonly see it used in the tech world.

~~~
SEMW
> performant is not considered a real word in English, although I commonly see
> it used...

This is close to being a contradiction in terms. The purpose of words is to
communicate, and if a word is being successfully used to communicate -- which
clearly it is -- what exactly does it mean to say that isn't "considered a
real word"?

Also, "Considered" by whom? The dictionary? Dictionaries are descriptivist --
they record usage, they don't prescribe it [0]. If it isn't in the dictionary
yet, that's only because the usage hasn't been used widely and/or for long
enough that it meets the inclusion criteria [1].

(As it happens, "performant" is at the stage where it is starting to pass
those thresholds, and is now in the OED [2])

[0]
[http://englishplus.com/news/news1100.htm](http://englishplus.com/news/news1100.htm)

[1] [http://public.oed.com/about/frequently-asked-
questions/#qual...](http://public.oed.com/about/frequently-asked-
questions/#qualify)

[2]
[https://en.oxforddictionaries.com/definition/performant](https://en.oxforddictionaries.com/definition/performant)

~~~
jfk13
> (As it happens, "performant" is at the stage where it is starting to pass
> those thresholds, and is now in the OED [2])

Strictly speaking, I don't believe your [2] is the OED. It's "Oxford _Living_
Dictionaries", which I assume tries to be more current/dynamic, but might be
regarded as less authoritative.

Interestingly, the word "performant" _is_ in the OED itself, with the earliest
citation being from 1809 -- but it is listed only as a noun, meaning "A person
who performs a duty, ceremony, etc., a performer", not the adjectival usage
under discussion here.

[http://www.oed.com/view/Entry/262085?redirectedFrom=performa...](http://www.oed.com/view/Entry/262085?redirectedFrom=performant)
(requires login)

~~~
zimpenfish
Would you prefer the dictionary from Cambridge University Press as a source?

[https://dictionary.cambridge.org/dictionary/english/performa...](https://dictionary.cambridge.org/dictionary/english/performant)

------
kabes
You can also do http(s) over DNS:
[http://code.kryo.se/iodine/](http://code.kryo.se/iodine/) . Nice way to avoid
paying captive portals, although probably not legal.

~~~
gsich
Why not?

~~~
pbhjpbhj
In USA and UK at least unauthorised access or use of a computer is
criminalised. On some situations you can argue for assumed consent, the law
doesn't operate on "if I can do it then it's authorised". Unless you can show
you have permission then it's not authorised, ergo not legal.

AIUI; not legal advice.

~~~
gsich
But the premise was to circumvent crap such as captive portals. Doing that on
your own computer (mostly in a public wlan), I don't see any reason against
it.

~~~
remedan
You're still circumventing security measures to use somebody else's hardware
in a way they clearly don't want you to. That's illegal in most cases.

~~~
gsich
Who is the "someone else" in your case? Where does the someone else's hardware
come from? OP mentioned this to get rid off e.g captive portals.

Iodine requires a client and a server. Both belong to you, what is the problem
here? That I use a network to transmit packets? We are not talking about
installing iodine on someone else's computer!

~~~
lyk
Not sure if you're trolling, but the network is being accessed by bypassing
the captive portal. The network is being accessed in a way that isn't
permitted.

~~~
gsich
And how should I know that there is a captive portal? I connect (connection is
established after receiving IP address!) and use iodine (or similar).

~~~
tedunangst
I'm sure the jury will be delighted to hear your explanation.

~~~
loup-vaillant
"I used iodine all the time, so I can't even notice the presence of a captive
portal, if any."

"My son handles the computer stuff for me, I don't even know about that
logging page you're talking about."

"I thought restricted networks had a WPA-2 password? That's what they use at
my workplace."

~~~
pbhjpbhj
"The door to the house was open, move of the stuff was tied down, how could i
be expected to know I wasn't authorised to use it??"

Judges just aren't that stupid.

~~~
loup-vaillant
Here's the thing: I _never_ give my real name to captive portals. I don't even
give a real email address.

Who can tell me with a straight face that this is criminal behaviour

------
philip1209
We prototyped this as an intern project at OpenDNS, too:
[https://github.com/opendns/OpenResolve](https://github.com/opendns/OpenResolve)

We mostly built it because it sounded cool, but one use case that I though was
important was being able to boot these images in different data centers to
collect telemetry on DNS differences geographically (eg for hijacking or
anycast).

~~~
LogicX
Nice project!

We at DNSFilter are able to collect that same telemetry just by having
resolvers at each of the anycast locations -- between the different locations,
and passing along eDNS Client Subnet information, many responses will be
(legitimately) different. A little hard to see a hijack in that noise.

------
fpoling
I can see how DNS over HTTPS addresses security, but I do not see how it helps
with privacy. After resolving the IP address over secure connection HTTPS
still sends the host name unencrypted, so one can just eavesdrop on that. And
if encrypted DNS becomes widespread, I suspect that various state-imposed
firewalls like one Russia will just look for HTTPS connection header to block
a particular site.

~~~
tylerhou
> After resolving the IP address over secure connection HTTPS still sends the
> host name unencrypted

Correct me if I'm wrong, but I'm pretty sure the host name is generally only
sent in an HTTP header, which should be encrypted over HTTPS.

[https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Ho...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Host)

~~~
pjc50
No, in order to multi-host SSL sites the host name has to be sent first in
order for the correct certificate to be presented.

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

~~~
deathanatos
You don't even need SNI; the initial Server Hello, which contains the server's
certificate (which contains the DNS name the certificate is issued for) is
sent in the clear.

~~~
tialaramex
No longer true in TLS 1.3 as I understand it

The ServerHello starts out by finishing key agreement and then (in the same
message) it assumes its peer now knows the session key and encrypts the rest
of the message, including Certificate.

~~~
deathanatos
Interesting; do you have a reference? In particular, how does it complete key
agreement without the certificate? The first thing that comes to my mind is
that in order to build the encrypted connection, you need to know _who_ you're
building it with, i.e., you need the certificate. You _could_ build an
encrypted connection with just whoever is on the other end, and then exchange
the cert, but I would wonder then how you would prevent a MitM from just
building two connections and forwarding the content across. (Though that would
defeat a passive listener, at least.)

(Essentially, the problem is that prior to requesting the certificate for
X.com, you need to know that you're talking to X.com; a sort of authentication
chicken and egg.)

~~~
tialaramex
The TLS 1.3 drafts (and given they're in Last Call, presumably the RFC itself
once published) use different types of brackets to indicate whether and how
things are encrypted in the ASCII art diagrams. The curly braces {} are used
for the Certificate structure, meaning it is encrypted using the session keys
but it is NOT authenticated application data yet. We'll see why in a moment.

So, firstly I'm going to say, go read the drafts for yourself
[https://tools.ietf.org/html/draft-ietf-tls-
tls13-23](https://tools.ietf.org/html/draft-ietf-tls-tls13-23) because I am
pretty sure that's the most snarky response and also hey, it's right there, if
I'm wrong that's a great place to start in proving so.

But then I'll answer your substantive question, because the answer is pretty
interesting (and quite unlike earlier versions of TLS).

So, you are correct that we can (and TLS does) do DH without knowing who we're
talking to, and that our problem is that although our session is encrypted and
can't be eavesdropped, this seems useless because we don't know who the heck
we're talking to, surely we can be subject to a Man in the Middle attack.

However, TLS 1.3 has a trick here, after sending Certificate the server sends
CertificateVerify. CertificateVerify signs the entire key agreement (which we
just did) with the identity from the Certificate. So, a client receiving
CertificateVerify either gets a matching signature (the party we did our DH
key agreement with _was_ the owner of the Certificate - good) or they don't
(we're being MitM'd the phone call is coming from inside the house - get out!)

Once the client has checked CertificateVerify (and presuming they're happy
with whatever was inside Certificate) they're truly secure and Application
Data can begin to be processed.

------
mosselman
“...for privacy...” and “Google runs one...”

Strikes me as funny. Interesting concept apart from this detail though. Are
there any servers that aren’t owned by advertisers and the like?

~~~
aplorbust
[https://stat.ripe.net/data/dns-
chain/data.json?resource=exam...](https://stat.ripe.net/data/dns-
chain/data.json?resource=example.net)

[https://dns-lg.sidnlabs.nl/example.com/A](https://dns-
lg.sidnlabs.nl/example.com/A)

------
alien_at_work
I really hope this doesn't catch on widely. It should be a tool for use where
censorship issues can't be solved politically.

Otherwise, why even have protocols at all? Just say the only protocol is HTTP.
IP, etc. are just an HTTP implementation detail.

~~~
banachtarski
I would love this to catch on wildly! DNS through TLS means it's all end-to-
end encrypted, DNS reflection attacks are harder, etc. The "why even have
protocols" doesn't make sense. Protocol can be layered just fine (HTTP itself
is a good example). DNS as it exists now is another random special snowflake
that vendors need corresponding snowflake implementations for.

~~~
alien_at_work
>DNS through TLS means it's all end-to-end encrypted

I didn't say I'm against DNS being encrypted, even with TLS. I just hate that
instead of doing the right thing (e.g. political battle with the government,
opening a port on a firewall) people choose the laziest way: just tunnel it
over HTTP.

>Protocol can be layered just fine (HTTP itself is a good example)

They can, but why do it? Just figure out a way to make your server be yet-
another-"REST"-service and pat yourself on the back for cleverness.

>DNS as it exists now is another random special snowflake that vendors need
corresponding snowflake implementations for.

As is: SMTP, POP, IMAP, SSH, AMQP, FIX, SWIFT, LDAP, ODBC and a host of other
protocols. Why do you use negative language like "random special snowflake
that vendors need corresponding snowflake implementations for"? These are
seperate protocols, which serve seperate specific needs. This is how IP was
designed to work.

~~~
gkya
Political battles are hard to do, and take time, sometimes very very long
times they take.

~~~
alien_at_work
I don't disagree at all. But I don't find this sufficient justification to
engage in poor engineering practices.

DNS has a different set of use cases than HTTP so, while it can be made to
work with enough effort (anything can), HTTP can never be as good at DNS as an
actual protocol designed to do DNS can.

------
Aissen
Anyone has good pointers on DNS over DTLS (draft RFC 8094) vs DNS over TLS
(RFC 7858) vs DNS over HTTPS (this draft) ? And if you could throw in DNSSEC
in the mix, that would be helpful.

~~~
LogicX
With pleasure - (CTO of DNSFilter, this is my world)

DNS over DTLS (RFC 8094) speaks only to UDP This could be compared with
DNSCrypt's implementation

DNS over TLS (RFC 7858) is TCP focused

DNS over HTTPs is focused on... you guessed it, HTTPs

So all the same thing, all trying to add security and privacy, just over
different transport mechanisms.

While we're at it -- you did not mention DNS over QUIC:
[https://tools.ietf.org/id/draft-huitema-quic-
dnsoquic-00.htm...](https://tools.ietf.org/id/draft-huitema-quic-
dnsoquic-00.html)

Some factors which start to come in to play with the various options are:
Compatibility with firewalls and proxies (DNS over HTTPs wins, others over
port 853 have a disadvantage, even if you put them on port 443, they may get
stopped by deep packet inspection)

TLS Improvement knobs: 0-RTT, TCP Fast Open, etc. (You can find a summary of
these here:
[https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implement...](https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status)
)

And closely related, performance. It's tough to beat a lossy protocol with
minimal overhead (UDP), but there have been a lot of improvements with Keep
alive, eDNS0, pipelining, etc.

We're currently doing a lot of testing around this, as we are working to offer
useragents and LAN proxies implementing DNS over TLS, compared with DNSCrypt.

Finally: DNSSEC. It lives in a different part of the 'security' spectrum
here... The purpose of DNSSEC is to be able to authenticate the validity of an
answer when traveling through untrusted parties (say you're using a third-
party resolver, or do you trust your ISP's DNS to not mangle with responses).
It does not encrypt request/responses. It does not provide privacy. It answers
the question: "Can I trust this response I received for example.org to be the
one that example.org intended me to receive?"

~~~
Aissen
Thanks, that's great!

I didn't even know about dns-over-QUIC, but considering QUIC is still a draft
itself… (I've been excited about it for quite a while though).

Regarding middleboxes, I forgot about those, and it's very sad that they keep
hindering progress this way.

------
nly
I've been pushing all my DNS traffic over a VPN, transparently, for the whole
house, for years now (by setting the VPN remote IP as the upstream resolver on
my router).

It seems the only advantage of DNS-over-HTTPS is that it does DNS over TLS on
port 443, which is harder for militant netadmins to block.

It's definitely a solution to a niche problem, but if we really want to
encrypt DNS at scale then we could do it easily enough by introducing DNScurve
to the SOHO market.

~~~
DavideNL
When you run DNS requests over VPN, you are sharing your "browsing history"
with (at least) 1 other third party: whoever runs the VPN server, and whoever
runs the (public) DNS server.

Your ISP can see the IPs you connect to regardless of whether you use your
ISPs DNS server or not (unless of course you tunnel ALL traffic of all clients
through the vpn as well.)

~~~
nly
It's low hanging fruit. Logging DNS queries is a lot cheaper for an ISP than
filtering out and logging SNI entries in TLS handshakes.

------
therealmarv
dingo - a Google DNS-over-HTTPS caching proxy in Go
[https://news.ycombinator.com/item?id=12514170](https://news.ycombinator.com/item?id=12514170)

------
aplorbust
"Do DNS resolves over HTTPS for privacy, performance and security. Also makes
it easier to use a name server of your choice _instead of the one configured
for your system_."

"A server that is acting both as a normal web server and a DNS API server is
in a position to choose which DNS names it forces a client to resolve (through
its web service) and also be the one to answer those queries (through its DNS
API service)."

[https://tools.ietf.org/html/draft-ietf-doh-dns-over-
https-02](https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-02)

How might this affect users who block ads via DNS?

What about users who want the system DNS settings they have configured (e.g.
/etc/resolv.conf) to be honoured?

I can clear browser DNS cache with a couple of keystrokes, but I am not using
Chrome, Firefox, IE/Edge, Safari, Brave, Opera, etc.

How easy is it for a user to clear the DNS cache in the popular browsers?

The best "privacy, performance and security" _for the user_ is achieved by
using /etc/hosts. HOSTS (i.e., no DNS) will beat DNS on all three, every time.
"Flexibility" was not mentioned as a criteria.

There is also the issue of "transparency" to consider. It is easy for the user
to check their HOSTS file to see what are the current name to address
mappings. How easy is it for the user to check what mappings are in the
browsers DNS cache?

Fact: Many/most of the names looked up by a user repeatedly every day do not
change by the hour, by the day, the week, month or even year.

As a user, I use HOSTS heavily, with appropriate ed scripts for fast automated
modification. I use HOSTS for the transparency, control and speed. Any privacy
or security benefit is a bonus.

Contrast:
[https://en.wikipedia.org/wiki/Fast_flux](https://en.wikipedia.org/wiki/Fast_flux)
(need DNS or perhaps "DOH" for this to work)

~~~
pas
> How might this affect users who block ads via DNS?

They should make sure to use a trusted DNS over HTTPS resolver.

------
kernelPan1c
Yes, greater for security but still depends upon reliability of certificate
authorities and ISPs. ISPs have the ability to issue the client a bogus
certificate while they hold the real one in order to decrypt traffic. Why
won't browsers allow the certificate's public key to be readable by javascript
so that the remote server can verify the client has the correct certificate?
This wouldn't be foolproof but it would significantly beef up security.

Similar to how tor hidden services get resolved, distributed hash tables seem
like the way to go. Take the ISPs and Cert Authorities out of the equation.

~~~
nly
Making the public key of the remote available to JS wouldnt help because if
you can't trust the identity of the remote server or integrity of the
connection then you can't trust the javascript.

Tor hidden services are secure because of the lack of human meaningful names.

See:
[https://en.wikipedia.org/wiki/Zooko%27s_triangle](https://en.wikipedia.org/wiki/Zooko%27s_triangle)

~~~
kernelPan1c
Yes, since you can't trust the JS, doing this would be an attempt at security
through obfuscation. I mostly just think it's strange that these keys aren't
accessible. If there were ever a mismatch detected, the server could at least
know with certainty that there's a bad actor on the connection.

Thanks for Zooko's Traingle wiki. Hadn't seen that one before.

------
vectorEQ
people invented other security things inside of dns protocol to avoid having
the added bandwidth. i dont think it's reasonable to say that everyone can
handle the increased load nowadays.

However, i've been thinking of this, for enterprise, you could build a dns
server which servers over TLS connections, and then put a local dns proxy on
clients which receives on 127.0.0.1 and sends out tls to the custom dns
server. That way any local network connections would be encrypted to passive
listeners on the network.

recursive queries would go onto the internet plaintext to 'normal' dns
servers.

~~~
Skunkleton
You can already do this with existing tech. When a DHCP lease is acquired, you
also get DNS server information. If you are concerned about the DNS packets
being encrypted on your local network, then you can do that already as well by
intercepting them with a local firewall and sending them across a tunnel.

IMO, the purpose of DOH is to address semi hostile environments like the free
Wifi at the Airport. It is kind of like a VPN for just your DNS traffic.

------
stock_toaster
Maybe someone people will "rediscover" dnscurve.

~~~
jedisct1
Which is completely unrelated

~~~
stock_toaster
It isn't completely unrelated.

DNSCurve secures the link between resolvers and authoritative servers.
DNSCrypt (based on DNSCurve) secures the link between clients and resolvers.

------
wannabeinggeek
I am just wondering why would you want DNS over https instead of something
like dnscrypt which would be dns over ssl ( I think opendns does this already)
?

~~~
icebraining
My guess is meddling corporate firewalls that spy on SSL/TLS traffic (using
custom certs installed on the machines) and block unrecognized traffic.

------
bandrami
Actual DNS servers and clients have supported TLS since the early years of
this decade. What's gained by adding HTTP transport overhead?

~~~
est
http is not overhead, http is the only transport that can go through middle
boxes.

~~~
skuzye
if the traffic is encrypted how can you tell whether it's http or plain dns?

~~~
jedisct1
Because the purpose of middle boxes is to log your traffic no matter what,
usually by installing a root certificate on your devices.

------
jedisct1
DoH's great.

I'm planning to write an Nginx module to support it soon.

------
hollander
OpenDNS used to offer a secure DNS-tool. I can't find it anymore. Maybe Cisco
removed it? Why can't we use something like that?

~~~
LogicX
You're thinking of DNSCrypt.

It unfortunately was recently abandoned by the original developer. Some folks
have mirrored it here:
[https://github.com/DNSCrypt](https://github.com/DNSCrypt)

------
fouc
I'm wondering if libcurl supporting custom DNS resolvers could make it easier
to explore alternative DNS systems like namecoin.

------
okneil
As a mac user, how can I set this up locally to run all my DNS over TLS?

------
kuschku
So what use does this have?

DNSSEC already gives us validation of the records, and thanks to SNI, this
doesn't give us any privacy.

It is more complex, more centralized, and ends up slower than using actual
DNS, and doesn't seem to provide any benefits.

Am I missing something?

~~~
kodablah
Easier to prevent censoring. DNSSEC doesn't hide the fact that you're making a
DNS call, correct? With HTTPS, censors/MITMs can only see the domain you go
to. The censor/MITM won't know whether I went to google.com to search or
perform DNS query. Plenty of countries have blocked DNS providers they don't
like, now that's harder w/out also blocking the site as a whole.

~~~
kuschku
Easier to prevent censoring from the ISP, but you're now just reliant on
another company's systems.

If you just want a solution for having a remote server execute DNS queries for
you, you can just use any of the existing VPN protocols purely for DNS
resolution, or even make a better performing version.

All that overhead HTTP adds is wasted for this.

~~~
kodablah
> All that overhead HTTP adds is wasted for this.

When you're in an area where your DNS provider is limited by the state, you
won't consider it wasted. But if you're not and you do consider it wasted,
don't use it. But saying it doesn't seem to provide any benefit is wrong and
just telling people to use a VPN for DNS resolution is also wrong (at least
until the ergonomics improve).

~~~
kuschku
It's more a question why a company like Google would pay several engineers who
are paid 6-digit sums to build this when they could build for the same or less
much more powerful solutions.

------
breatheoften
I hate the idea of ad networks using this ...

------
Zash
Must everything be over HTTPS? Must all diversity really be killed like this?
It saddens me.

------
sairamkunala
similar - stubby -
[https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+...](https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby)

------
zde
To understand DNS, you must first understand DNS.

~~~
chriszelazo
DNS is one of those things I have to reference every time. Definitely feels
like this.

------
tzahola
Isn’t this a chicken vs egg problem?

~~~
dyu
You can remember a small set of resolved hosts for this purpose, not unlike
remembering DNS servers or CAs to trust. A quick search online also says it's
possible to issue a cert to a public IP address, so you can also do HTTPS to a
numbered IP instead of a host name.

~~~
tzahola
I haven't heard of any respectable CAs that would issue certs for IP
addresses...

~~~
tialaramex
They're rare but they do exist. The CA needs to ensure you really have long
term control over the address.

Most people would never need one, but a few people have a real use for them.

------
averagewall
Where does the privacy advantage come from? Once you resolve a hostname
privately, don't you still need to use its IP address publicly for your
traffic to be routed there?

~~~
m_eiman
One case where it might help is shared hosting: you don't know which of the
domains hosted on that IP you're accessing. Narrows it down to just a few
though, so IMHO not a big improvement.

~~~
mschuster91
> One case where it might help is shared hosting: you don't know which of the
> domains hosted on that IP you're accessing.

That depends on your level of access/monitoring: if it's just a firewall log
that shows source/destination IP, then yes - but as soon as you have any kind
of packet monitoring, then the domain can be easily sniffed from the SNI
header.

