
DNS Queries over HTTPS - pierreneter
https://tools.ietf.org/html/rfc8484
======
LinuxBender
Please forgive me if this has been covered. AFAIK it has not.

Has anyone worked out how this will play nicely in corporate environments?
i.e. avoiding leaking even more internal names, resolving internal systems
first, etc? Or is it on IT departments to now customize the proxy settings for
all browsers and API clients on all operating systems? I ask, because I know
that most companies barely manage this on one browser, much less all of them.
I am not in IT, but I am occasionally required to assist them and sometimes
that requires capturing DNS requests for entire networks.

~~~
yjftsjthsd-h
Correct me if I'm wrong, but I'm pretty sure that this is in fact _designed_
to break that kind of arrangement. The problem is that the mechanics used for
corporate monitoring are almost exactly the same mechanics used for your ISP
spy on you or censor things. So yes, the end result is that we will need to
move monitoring (and potentially blocking if you're doing that) onto the
endpoints.

~~~
LinuxBender
You are correct and that is my point as well. I have yet to see a company that
manages all proxy settings for all browsers, operating systems, API clients,
etc. At least, not very well. Shops that are strictly windows can enforce this
from AD. Everyone else will have to shim something in. We are a mix of
Windows, Mac and Linux. Mostly Mac.

Without a decent path forward, I could imagine that many corporations may go
the heavy handed route of blocking all the known DoH resolvers. I envision IP
and DNS lists like firehol and various RBL databases to eventually contain
these if they do not already.

~~~
geocar
The place I work blocks all Internet access.

If you want to visit a webpage, you need to use the http (clear) proxy. Most
web pages are blocked, and if you need one unblocked you open a ticket and
wait a week (or escalate).

~~~
LinuxBender
I've seen that too. One of our partners has such a stringent policy that the
government of China allows them to entirely circumvent their "great firewall"
with their own dedicated circuits. They track metrics on every single packet
to and from anywhere. They essentially built their own world-wide ISP.

------
proaralyst
I'm kind of sad that we're using HTTPS as a transport though their use cases
make sense. It seems this is intended to exist alongside the existing & new
secure protocols? Is it foreseen that this will only be used by web apps?

~~~
dharmab
Yes. No.

See also DNS over QUIC.

~~~
groovybits
Somewhat tangential: HTTP/3, which will also be using QUIC

[https://tools.ietf.org/html/draft-ietf-quic-
http-13](https://tools.ietf.org/html/draft-ietf-quic-http-13)

~~~
judge2020
Isn't HTTP/3 just the name for IETF's QUIC?

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

~~~
groovybits
QUIC (Quick UDP Internet Connections) is a protocol derived from Google's
Speedy project. Another protocol would use QUIC to initiate a handshake
between server and client. The cool thing is that it only takes one UDP packet
to do what TCP does in the typical SYN/SYN-ACK/ACK.

~~~
jimktrains2
Well, it's not quite exactly the same thing as the 3-way handshake over a
single packet.

The 3-way handshake ensures that both ends are able to send traffic to their
counterpart. Just because i receive a packet doesn't mean I can send one back.

~~~
bluejekyll
Perhaps a better way to phrase it, is that the 3way handshake does not need to
be completed before sending data.

~~~
dcbadacd
Couldn't this mean massive amplification attacks?

------
simonpure
Google offers a similar service, but doesn't look to implement any official
spec [0].

I recently had a need to resolve DNS with http only and this came in handy.

[0] [https://developers.google.com/speed/public-dns/docs/dns-
over...](https://developers.google.com/speed/public-dns/docs/dns-over-https)

------
detaro
bunch of other large DoH discussions (sometimes about specific
implementations, but with generic commentary as well)

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

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

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

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

------
slim
It's 2019 and we have DNS over TCP and HTTP over UDP

~~~
wahern
DNS has always been available over TCP. The DNS packet header has a Truncated
(TC) bit that tells you when you should query over TCP, as UDP responses are
usually truncated at ~500 bytes.

DNS over TCP can often provide better throughput and lower latency, especially
on networks with a lot of packet loss (which can be _your_ network if you're,
say, batch resolving IP address PTR records from a log where your DNS UDP
requests overflow the kernel and NIC TX buffers).

------
AnaniasAnanas
DNS Queries over HTTPS.. which implies TCP. Weren't TCP DNS requests avoided
like the plague? And why wrap DNS in HTTPS instead of just TLS if you are
going down the TCP route? Why not DNSCrypt which is already supported by a lot
of servers? Or DNSCurve.. or DNS over QUIC.

~~~
Spivak
You do both. Both Google and Cloudflare run DNSoTLS on port 853 and DNSoHTTPS
on port 443. DNSoTLS and DNSoHTTPS in their short lives have already gained
more traction than DNSCrypt ever got.

DNSoQUIC is already in the pipeline.

~~~
jedisct1
> DNSoTLS and DNSoHTTPS in their short lives have already gained more traction
> than DNSCrypt ever got

I'm not convinced at all that this is true. Cisco, Comodo, Infoblox, Yandex,
support DNSCrypt only in their products. They have no reason to switch to
protocols that would require 10x more traffic.

OpenNIC secure resolvers are all DNSCrypt. Cleanbrowsing resolvers probably
get a lot of connections over DNSCrypt as well.

I run both public resolvers accessible over DoH and DNSCrypt, and the traffic
over DoH is negligible compared to the DNSCrypt one.

------
deaps
This would certainly be huge overhead at the dns server right? I'm curious if
anyone manages an authoritative DNS server? I currently manage four rather
large ones and the collective whole serves up between 400,000 and 900,000
responses _per second_.

~~~
londons_explore
1 Million responses per second on a 8 core 2 Ghz mahine means you have 16,000
clock cycles to formulate a response to each query.

Considering that [1] claims 1.43 cycles per byte for Chacha20, and assuming
requests & responses are typically 200 bytes (they will compress well with
HTTP header compression), the actual encryption part of https only consumes
1.43 * 200 = 286 cycles.

The remaining 15,716 clock cycles should be plenty to read the actual
responses from the cache and parse the HTTP/2 request bytes.

Obviously all of the above assumes you design your infrastructure purely for
performance. Writing everything in Python and NodeJS might suddenly burn up
all those 15,716 clock cycles!

[1]:
[https://eprint.iacr.org/2013/759.pdf](https://eprint.iacr.org/2013/759.pdf)

~~~
deaps
I checked the cpu stats - and what you describe is definitely accurate - these
boxes spend most of their clock ticks on idle...which is amazing. At 3 Ghz and
8 cores - we're talking 24,000 clock cycles to come up with a response.

------
sytse
'[RFC2818] defines how HTTPS verifies the DoH server's identity.' that RFC is
TLS over HTTP

How do you resolve the IP address of your DoH server? Is the answer to just
use an IP address? In that case does it have a certificate for the IP
addresses instead of for a FQDN?

~~~
callahad
> _In that case does it have a certificate for the IP addresses instead of for
> a FQDN?_

It can be both: If you look at [https://1.1.1.1/](https://1.1.1.1/), the
certificate is issued for *.cloudflare-dns.com, but it also contains the
alternative names 1.1.1.1 and 1.0.0.1.

------
tatoalo
I stumbled upon this when researching wether it was something to set up with
my pi as DSN resolver but it was kinda a pita, does implementing DoT would be
faster?

~~~
bluejekyll
All the major DoH providers appear to also support DoT, so DoT is a viable
option. Also it is easier to implement, as it can just be a abstraction of
existing implementations over DNS over TCP.

~~~
tatoalo
I've seen your trust-dns rust-based repo, raspian is supported, I'll give it a
try! Thanks

~~~
bluejekyll
Cool, let me know if there's anything there you'd like to see.

I'm in the process of working on a system resolver, but first have to refactor
a bunch of stuff. We'll see how that goes.

------
YouKnowBetter
This is the 12th time (see: past) that this subject has been linked.

The 3rd time this exact link (ietf.org) has been posted.

Except for emotions: do we realy expect a new and exciting discussion will
take place?

~~~
vntok
None of the previous conversations had any comment here.

~~~
gsich
They had:

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

